Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
FrodeHK
Participant

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

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:

rules.png

 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:

connectionOK.png

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

user-group.png

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:

AAD-usersAndGroups.png

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

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

BR,

FrodeHK

13 Replies
PhoneBoy
Admin
Admin

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
Legend
Legend

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
Participant

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
Legend
Legend

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
Participant

Hello,

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

AAD-pdp-monitor-user.png

(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:

AD-pdp-monitor-user.png

 

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
Legend
Legend

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

0 Kudos
FrodeHK
Participant

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:

VPNadmin.png

 

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

0 Kudos
the_rock
Legend
Legend

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.

0 Kudos
FrodeHK
Participant

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

AccessRoleGroup.png

 

FrodeHK

0 Kudos
andrewb
Participant

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

0 Kudos
andrewb
Participant

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

0 Kudos
FrodeHK
Participant

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

0 Kudos
FrodeHK
Participant

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events