Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Simon_Macpherso
Advisor

Identity Awareness - Two different LDAP Account Units

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

0 Kudos
5 Replies
Sorin_Gogean
Advisor

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

0 Kudos
Simon_Macpherso
Advisor

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

 

 

 

0 Kudos
Sorin_Gogean
Advisor

Wonderful @Simon_Macpherso  .

 

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

0 Kudos
Simon_Macpherso
Advisor

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? 

0 Kudos
Sorin_Gogean
Advisor

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).

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events