Azure AD for VPN - Not matching users

[madu1]

I've seen several posts regarding Azure AD for remote access including these:

https://community.checkpoint.com/t5/General-Topics/Remote-access-community-participating-group-using...

https://community.checkpoint.com/t5/Remote-Access-VPN/Azure-AD-connection-R81-10/m-p/166488#M8301

The "old" documented method using the "EXT_ID_" groups works great, no problems at all there.

But what about picking users/groups directly from Azure? This is where I'm getting really mixed results and need some guidance. I've had a case open with TAC for ages about this and they keep telling me it is not documented or supported, which I'm struggling to believe. It allows me to pick users directly from Azure AD but then CP are telling me those Access Roles won't work because it isn't supported?  So what's the point of having the functionality baked in then if it does nothing?

So, I have IDP set up for SAML.
I've ALSO got Azure AD set up. In an Access Role I can browse my entire Azure AD and pick users/groups straight from there - i.e. no need to use the empty EXT_ID_ local groups.

I have played around a lot lot lot with this and on two different R81.20 gateways I have it working - VPN users log in and get matched to the correct Access Role.  But on other gateways it just doesn't work. Has anyone else figured out the magic trick to make this work? I've checked gateway and Azure settings between the working and non-working gateways and there are no obvious differences.

sk179788 is key to this working - which also surely implies that it should work?  So why am I being told it isn't a supported method?  The SK gives the cop-out answer at the end that if it doesn't work, just use EXT_ID_ and move on...

Taking a working system, I've then gone to the gateway that doesn't work and set it up to the same Azure app (using the same tenant & app ID, secret, etc) as the working one, so I know the Azure end is fine. That gateway still doesn't work, which tells me the problem lies on the gateway. But I just can't figure out why. The gateway can browse Azure AD and populate the Access Role with users directly from Azure, but when a user logs in it just doesn't match the Access Role so the traffic drops on cleanup.

Why does this work perfectly on some gateways but not others when all of the settings are the same, including the sk179788 hack?  Has anyone figured out what is needed to make this work consistently?  Or what is the point of Azure AD to populate Access Roles if CP say the gateway will ignore it so don't bother using it?

[PhoneBoy]

Are the gateways it's working on fresh installed or were they upgraded from a previous release?
I'd review the GUIdbedit settings for the different gateways to see if they show any differences in realms_for_blades and fetch_options: https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_RemoteAccessVPN_AdminGuide/C.... 

[AndréTinoco]

Hello Madu,

It should work if you implement everything according to the docs. After authentication, you can check the "Identity Propagation" logs to see if the user was matched on a "aad_" user. If it is not being matched, then check:

- GuiDBEdit Settings (Network Object > network_objects > GWobjectName > realms_for_blades (not "multi_realms_for_blades") > VPN > fetch_type > Change value from "all" to "fetch_options".  Then change the "do_ldap_fetch" from false to true.

- Second and crucial, make sure you've edited the file "$CPDIR/conf/DataCenterServicesRealms.conf" on all gateways of the cluster and added a line with "vpn_<SAML REALM NAME>". The SAML_REALM_NAME is the name you gave your Authentication method on SmartConsole.

We have this working on multiple customers with no issues.

Hope it helps.