VPN users, SAML and IPassignments

[StevePearson]

I'm currently investigating the way VPN users are identified when they connect and authenticate with SAML against 365. Employees are sync'ed from Local AD but other users are only defined in 365. Identity collector is deployed on the local AD servers. Users connect using the either the Remote Access Client or the Endpoint Security Client, but the effect is the same in both.

If the user is identified by SAML but not known in local AD then I believe that the “Username” is returned as the email address so user.name@mydomain.co.uk. This is then matched in ipassignments.conf to give the user an IP address. (assuming that there is an entry for user.name@mydomain.co.uk obviously) But as the user is not known in local AD, the ID Awareness obviously doesn't have any group membership details for the user, so the user won't match any Access Roles.

If the user is identified by SAML and is known in local AD then I believe that the “Username” is returned as the first part of the email address only so user.name. This however is NOT matched in ipassignments.conf so the user gets an IP address from the DHCP pool. (even if there is an entry in ipassignments.conf for user.name) However this time, as the user IS known in local AD, the ID Awareness does have the group membership details for the user, so the user will match Access Roles.

What I don't understand is why the identified users are not matching in the ipassignments.conf file. Am I missing something here? I don't have a suitable lab environment to be able to test this unfortunately.

[PhoneBoy]

The Entra ID groups should be passed as part of the SAML Assertion.
You also need to create local versions of said groups.
See: https://support.checkpoint.com/results/sk/sk177267 

[fabionfsc]

Usually, when I deploy Microsoft Authenticator + Entra ID for VPN authentication, I also perform verification via Local AD, because our customers have a license that, when creating a user in Azure, it is replicated in Local AD and vice-versa. But when this scenario does not occur, it is complicated... The Access Role rules never match. I know there is a solution for this, which is to create empty groups with EXT_*, but honestly I have never tested it.

That said, when authentication is done via Entra ID, Check Point does not receive the username, but rather the UPN (userPrincipalName), which is user@domain.com, but this also depends on how the Enterprise Application was configured, and how the user will be identified in the metadata.

I have a test environment where we can test some configurations, including ipassignment.conf. In my tests, even using common authentication by username and password, I was only able to make it work by defining the DN (Distinguished Name) of the users in the ipassignment.conf file.