Identity Awareness - Two different LDAP Account Units

[Simon_Macpherso]

Hello,

In Identity Awareness, users are successfully identified, but their groups and access roles are not correctly identified or enforced.

We have two different LDAP Account Units are configured with the same Domain.

This appears to be related to sk63943.

The SK states "When an access role is created, the user picker is tied to an Account Unit,
users picked must match the DN and the Account Unit."

Is it possible to associated an access rule to a specific account unit?

Regards,
Simon

[Sorin_Gogean]

Hello,

Are those "LDAP Account Units" assigned to the same GW or different GW's ?

We have 3 "LDAP Account Units" per each domain in our infrastructure, and those are assigned to a cluster out of the 3 we have , and we don't have any problem with AD Group mapping for users.

(so it's an one-to-one map LDAP Account Units to GW )

when we create an Identity based on AD group, or user, we do the LDAP mapping three times, addressing each "LDAP Account Units" that we have for that specific domain, so in your case, you should MAP the AD group based on a search done with LDAP AU A and with the LDAP AU B (hopefully you'll get it, otherwise I'll get screenshots....) 

Thank you,

PS: if I didn't understood it correctly, please provide more details

[Simon_Macpherso]

Hi @Sorin_Gogean 

Thanks for your reply.

I worked this out (what you mentioned - selecting the relevant LDAP AU when creating the access role). 

Regards,

Simon

[Sorin_Gogean]

Wonderful @Simon_Macpherso  .

PS: do some reading in regards to AD Global Catalog (sk134292)  as you might want to use that too....

[Simon_Macpherso]

Thanks @Sorin_Gogean 

This is out first AWS cloud deployment of the IA collector.

We created an additional LDAP AU for the same domain as a workaround to the issue outlined in sk26059. We did not want to modify the implied_rules.def to exclude LDAP traffic. 

 https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

There are no local AD servers in AWS so the collector is connecting back to 2 x AD on-premise.

We allocated 2 x external IPs and created 2 new host object using the external IPs, granted access to these these objects from the relevant gateway, and configured NAT to NAT the traffic through to the internal IPs of the 2 AD servers. We also created a new LDAP AU specifically for this use scenario - the AU is configured identically to the other LDAP AU (same domain, settings etc) the only difference being the configured servers.   

Re the global catalog option, do you use this in production? 

[Sorin_Gogean]

I supposed you had an tunnel or smth with AWS so you don't have to do the NAT part.

The Global Catalog, is needed for identifying/mapping AD Groups to machine or user account, in the case you have multiple domains that are interconnected - like we do .

Ty;

PS: Global Catalog is quite simple, you just change the LDAP object connect port from 389 (LDAP plain) / 636 (LDAP over SSL) to 3268 (GC plain) / 3269 (GC over SSL).