Identity Awareness - Multiple Domains (on the same gateways)

[PetterD]

Hello,

Currently trying to figure out if Identity Awareness will work (Collector) with multiple domains at the same time on the same  gateways.

We have a customer who use Identity Collector/Identity Awareness to give access to various resources
through their Firewalls from Horizon VDI. This works fine since each virtual desktop has a dedicated IP.

The current domain is "olddomain.int" and the LDAP Account Unit and Identity Collector machines are configured for this domain.
Customers Firewalls (both Virtual Systems & other) connect to this LDAP Account Unit and we have many access roles defined.

Customer is migrating to "newdomain.int" on new domain controllers and want both domains to work, on the same Firewalls.
As far as I can see, Identity Collector supports multiple domains.

As far as I can see this will require a new LDAP Account Unit for the new domain and domain controllers
and new Access Roles connected to "newdomain.int"

However my concern is how the gateways will handle multiple domains and Account Units at the same time during such a migration? Is this supported / where can I find documentation and best practices on this type of setup?

[simonemantovani]

Identity Collector provides Login information from every Active Directiory you have; while configuring LDAP Account Unit for every domain will give you the opportunity to browse every Active Directory tree to create the needed Access Role.

Information about users are obtained from the Identity Collector, and comprared with the access role created browsing the several Active Directories you have.

[Vincent_Bacher]

This is a fully supported scenario and shouldn't cause any issues.

The Identity Collector supports multiple domains natively. You should configure your IDC instances to report login events from both "olddomain.int" and "newdomain.int" domain controllers to the same PDP. The PDP then distributes the identity mappings to the PEP on each gateway which is attached — or to the PEPD process on the same gateway as the receiving PDPD. The PEPD queries AD via the LDAP Account Units for the group memberships to verify the Access Roles matching.

All you need is a separate LDAP Account Unit for each domain — one for "olddomain.int" and one for "newdomain.int". Create new Access Roles referencing the new domain and duplicate your rules during migration so both old and new roles are present in the policy. Keep the old Account Unit and roles in place until all users have been fully migrated.

[PetterD]

Thanks for the reply!

How will the gateway handle queries for multiple Account Units when using SamAccountName for login, i guess it will then just query the first Account Unit for the username and if its not found query the next ? What happens if there are duplicate samAccountNames in both Account Units or does it require switching to UPN?  Do you know where I can find any documentation on the behaviour ?

I recall many years ago we had a real headache with multiple LDAP Account Units for VPN, randomly failing logins 🙂

[simonemantovani]

As reported in the previoust thread, LDAP Account Unit are used to browser your Active Directory tree to be able to create Access Role; all the information about users are received by the gateway through the Identity Collector (and Identity Collector obtain the login informaion directly from the Domain Controller of all the Domains configured).

You could also take a look at these videos from the great @Peter_Elmer:

https://community.checkpoint.com/t5/Firewall-and-Security-Management/Identity-Awareness-Best-Practic...

https://www.youtube.com/watch?v=tYeOHSbVVCY

[PetterD]

Thanks for the update!

As far as I can see, the gateway itself does ldap/ldaps connection back to the Domain Controllers to match the user with AD-groups / Access Roles, even though Identity Collector provides the username&ip ? Per the link it also says that?:

"Identity Collector only gets the users without information about groups. Groups are obtained from LDAP by the gateway. Both are required."

So my concern is if the gateway receives "samAccountnameUser1+IP" from Identity Collector for a user that logged on to "newdomain.int" after configuring Identity Collector to also read DC`es in the new domain, it could potentially have issues if it finds "SamAccountNameUser1" in the LDAP Account Unit of "olddomain.int" 

[simonemantovani]

Through Identity Collector it's collected the user and the domain, that will be used to match to the corresponding LDAP Account Unit and Access Role.

[Vincent_Bacher]

I am not really aware of IDC collecting sessions from AD as we use IDC for ISE only. But i guess, it should get the domain field as well and hopefully UPN also.
So if yes, this can be solved, i guess. When the gateway resolves the group membership of a given session, it uses SamAccountName per default for the query. But you can modify that using GUIdbedit to UPN.

Will have to install a new SmartConsole to make guidbedit work with our new auth mechanism and i lost admin privileges. So at the moment i cannot show that using screenshots.

[PetterD]

Thanks! I was a bit confused as the "pep show user query usr USERNAME" did not contain any domain information.

However "pdp monitor user USERNAME" do contain the "CN=USERNAME,OU=Users,OU=Company,DC=olddomain,DC=int" in the "Distinguished Name".

I also found sk149854 where it states "

"How can we know to which server(s) we should send the query? by the defined realm."

"In case the domain was received by the identity source, we will find the relevant LDAP Account Unit object for this domain and will send query to the defined servers:"

So hopefully this means that this is a non-issue, and that the gateway receives the neccessary domain name information from the Identity Collector and queries the correct Account Unit DC`s for this domain to receive the Access Roles/do the enforcement.

[Vincent_Bacher]

OK, from your output of the `pdp mon` command, we can see that the domain is reaching the gateway, so this should work, as the domain is defined in the AU and the gateway then queries the user there accordingly, or checks their group memberships.

In short: as far as I can see, there shouldn’t be any issue.

[Peter_Elmer]

Hello @PetterD 

sorry for not responding earlier when @simonemantovani made me aware of your question. It's been one of these weeks 🙂

Reading your initial request: Identity Awareness is made to handle this use case.

Not sure you came across sk179544. It contains videos explaining the flow "what happens if" for Identity Awareness use cases. I apologize for not yet having updated diagrams and icons but the information still applies to R82 and  R82.10.

Your Identity Collector receives the Login Event from the old and new AD Domain Controllers and forwards those to the ID Collector. From here the information is forwarded to the PDP instance on the firewall. The firewall will query all AD Servers  - referenced in all LDAP Account Unit Object referenced in the gateway object > Identity Awareness > Identity Collector > Authentication section. The PDP aims finding group membership in the directory for the user mentioned in the login event message it has received from the ID Collector. In case the PDP finds group information it then searches for a matching Access Role object and create an Identity Session. 

You can see the content of the PDP Identity Session table using "pdp monitor". The PDP maintains a table of all networks it has learned login events about. The PDP makes this table/list available to all other firewalls running PEP (policy enforcement) - even to PEPs running on remote firewalls. This is the concept of Identity Sharing, where you configure a firewall "learn identities from" (ID Sharing) . You can see the list of networks on the PEP running "pep show network pdp". 

In case a PEP instance runs on the same firewall like the PDP, the PDP instantly "shares" all Identity Sessions with the PEP instance. As soon as a packet sourced from a network the firewall has learned login events from, the firewall consults the identity session table to find the right Access Role object and related firewall rule matching for this traffic.  You can see if such traffic will be handled by the PEP using 'pep show user' commands.

What happens if Alice/Bob are logging on to "new" and "old" domain using the same PC (== Src IP)?

We need to know the details how Identity Sharing is configured i.e. if you have PDP and PEP on the same machine or using remote ID Sharing  - see sk179544. Let's say, you have one firewall running PDP and PEP.

At 9:00am Alice is logging on to her PC 10.1.1.1 to domain "old". You have an LDAP Account Unit for 'old-domain' on the firewall and an ID Session is created related to IP 10.1.1.1 for alice[@]old-domain . The PEP local to the PDP will have an ID session and all rules with Access Role "User > alice[@]old-domain" will match.

At 9:30am Alice needs to work on the new domain and performs a login to "new" domain. The PDP will get notified, query group membership against "new" as there is an LDAP Account Unit object, find the groups and an Access Role object with "alice[@]new" and creates a new ID Session for IP 10.1.1.1.

If the you leave default configuration at the same time the old ID Session will be removed. You can control this behavior using the command "pdp conciliation idc_multiple_users" : by default only one IP can be learned per user for the identity source "ID Collector". 

I could not create a video on this scenario to explain it better, sorry, but hope the above is helping a bit.

greetings from Milano

pelmer

[tankp]

Q: What happens if there are duplicate samAccountNames in both Account Units or does it require switching to UPN?

>>> We may see "A secondary session request was received from the same IP. This caused logout of the current session" SmartConsole logs per sk131792.

If UPN is the unique AD user attribute, configure "UserLoginAttr" to UPN per sk110858.