Identity Awareness and Azure AD. Rules not hitting and not seeing identities in logs

[FrodeHK]

Hello,

We are in the process of setting up Identity Awareness with Azure AD. Earlier, we have used IA with AD on-prem with great success , but we have now "moved" many of our PCs and users to Azure AD. We have followed the admin-guide and this video: https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_IdentityAwareness_AdminGuide/Topic...

Unfortunately, we don't see any identities in the logs, and we are not able to get any hits on the access rules we are testing against.

We are using the same layered rule that we have used with IA and AD on-prem, and have added the access role group to the access rule/layer which contains our Azure AD group (and test user), but when testing from a computer, the layered access rule does not get any hits. 

The testuser within the access role group do not hit rule 38, but hits rule 39 further down:

 Rule 38 is supposed to allow the users in the access role group access to some external urls, while blocking the rest of the internet.

We have connection OK from Smart Console to Azure AD:

And we're able to pick both groups and users from Azure AD in our Access Role Group:

 

The admin guide didn't specify that we had to add users to the Enterprise Application i Azure AD, but we have also tested that in an effort to get this to work:

 

Any suggestions to what we might have missed during our setup?

(HTTPS inspection is enabled on the network we are testing from)

BR,

FrodeHK

[PhoneBoy]

Normally I'd point you here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
But I don't think there are any specific troubleshooting steps for Azure AD here.
@Royi_Priov can you or someone on your team suggest something?

[the_rock]

Hm, thats odd behavior. I worked with customer who has this set up in Azure and works fine. Can you confirm what pdp monitor user command shows for user in question? Just a guess, but maybe the firewall would show user belonging to access role thats not part of the right rule...just an educated guess.

[FrodeHK]

Thanks! Will try to test some more later today. I'm not that proficient with the CLI, but will see if I find something with pdp monitor user while generating some traffic with the test user.

FrodeHK

[the_rock]

Say if username is joejackson, all you would run on master firewall (if its a cluster) is pdp monitor user joejackson and it would show you all the details. That would definitely give you a clue!

[FrodeHK]

Hello,

Have now tested once again. Generated some traffic from user testelevfrode, then checked pdp monitor user:

(We tried the command with both username (pdp monitor user <username> and pdp monitor user <username@domain.com>)

Unfortunately, nothing shows. It seems like the FW doesn't see the the user at all? Do the user have to logon through captive portal before the firewall can see the users identity, or is Azure AD IA suppose to function just like AD on-prem IA? When using AD on-prem IA, our users do not need to logon through captive portal to hit the access rules which access role groups they belong to are set.

I should mention that we are in a hybrid environment where our users exists both in AD on-prem and in Azure AD. In addition, AD on-prem IA is also still functioning. When testing with an on-prem user, pdp monitor user shows the users id:

We also tried to add a non layered rule above the rule mention in the first post.

• Source: The access role group with the Azure AD group and the test user
• Destination: Any
• Services: http/https
• Action: Accept redirect to captive portal

That seemed to affect all our users, not just the users in the access role group. Very odd!

With regards to mentioning captive portal, when setting that,  the user gets redirected to an error page, not the Check Point Capitve Portal site -> "An unexpected error has occured. You may still be able to continue working normally. Please retry accessing the web page in a short while. (500)." Could there be some service that are not running on the firewall?

FrodeHK

[the_rock]

It shows role VPNadmin, so thats the actual access role its referencing. Does that access role belong to the right rule?

[FrodeHK]

I think that may be some default group or something? When checking that access role group in Smart Console, it says "Any network", "Any user", "Any machine" and "Any client". VPNadmin is not used in any policies:

Just to clarify, that role shows on the user I tested with that are still in AD on-prem, both user and the pc. So the firewall still can see identities from ad on-prem, but not from Azure AD. When issuing the command pdp monitor user testelevfrode, nothing shows from that user while generating traffic from Azure Ad joined device on our local network.

FrodeHK

[the_rock]

Ah, okay, not I get what you are saying...so here is an idea. Just wondering, is there a role that actually references users from Azure AD at all? Lets do remote session a bit later if you are free...Im in EST, so thats GMT-5. Just message me directly, I think we can figure something out here.

[FrodeHK]

We created the access role "AAD-WTC-IngenInternettTilgang" and could browse groups / users from Azure AD to add to that group:

FrodeHK

[andrewb]

Hi @FrodeHK , just to ask, how did you fix the issue, we are encountering the same - just on the VPN Remote access. 

[andrewb]

hi @FrodeHK , did you managed to resolved this? We are also encountering similar issue but on VPN.  thanks

[FrodeHK]

Hi @andrewb 

Unfortunately, we did not. We tried to upgrade fw to R81 tT44 (?), but the issue still persisted. Also noticed that our on-prem IA stopped working and that pdp caused one of the cpu cores to run at 100 %. To get the pdp to go down to normal, we had to disable IA rules, IA blade and reboot the fw. We opened a ticket with Check Point and the cause for the pdp to go to 100 % cpu at one of the cores seemed to be related to the Identity Awareness-Azure AD config. We removed all config related to IA-AAD and rebooted the fw. When we activated IA blade after that, IA on-prem was functioning againg. The suggestion from Check Point support was to try to add the IA-AAD config once more, and if pdp then caused one of the cpu cores to go to 100%, the next step was to install 'custom' patch we got from Check Point support or upgrade to R81.10 T30 before the next try,

Unfortunately, we have not managed to test these steps out yet.

FrodeHK

[FrodeHK]

Update: We have now performed a clean install to R81.10 with the latest hotfix. Followed the admin guides and setup Identity Awareness with Azure AD. The bug that caused pdp to go to 100 % cpu and IA Collector on-prem to stop is now gone. Unfortunately, we still can't see identities from Azure AD and the rules are still not hitting.

FrodeHK

[Davio]

Evening all

Apologies for the post on an old chain, however this, after a LOT of digging seems to be the closest match to what I’m trying to achieve for a customer.

Did you make any further headway @FrodeHK ? @TheRock I’d be interested to know if you still feel this should work?

Thanks team!

Dave

[the_rock]

See if this doc that my colleague and I made for a customer helps you @Davio 

Andy

[Davio]

Thanks for the swift reply - will check this over tomorrow 🙂

D

[the_rock]

Questions are free, responses may cost 😉

Jk...welcome mate 🙂

Andy