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

Identity awareness access group problem


We have Identity Awareness implemented for a lot of stuff, but it seems now that it got broken for one specific access rule.

RDP access to certain servers is controlled via IA and the access role is configured with a specific AD group, for which users in this group have access.

All of the sudden, it stopped working and users cannot RDP to these servers anymore.

Weird thing is that it was perfectly working before.

When basic troubleshooting this and removing the group access but adding the users separately, this works again and RDP is working fine again.

I'm fairly new to Checkpoint firewalls so any guidance how to pinpoint what the exact problem is would be highly appreciated.


0 Kudos
9 Replies

You could try to remove publish and again add the group into the access role and publish and install.
Regards, Maarten
0 Kudos

Hi Dave,

To assist you fully, could you provide the following information please:

1) What is the version of your management server and that of your gateway?

2) What is the time stamp of when the issue first occurred?

3) What is the identity acquisition method used?

4) How many domain controllers does the gateway communicate with?

Thanks Dave.

0 Kudos

Hi Nick,

1) mgmt and gateway are both running on R80.20

2)first occurence 4th of July

3)policy rule with access role used, where a nested AD group needs to be consulted, but only 2 deep and actual users are member of 3 different groups
Access role group name -> specific group added to grant access -> AD group

We got 4 DC but i'm not sure if all are used to communicate with the gateways.

Strange thing is that we have a bunch of other similar access roles set up also which do still work, only with this particular one we have a problem.
Also when i remove the AD group from the access role and add just the specific users, it just works....


Hope this helps, as i said, i'm fairly new into the game

Thanks a lot!

0 Kudos

You can always do basic checks that user/IP is actually assicoated with the role.

You can do it in both - SmartLog (use filter blade:"Identity Awareness" and IP / uername then look for log-in type event and see what role is associated with the user) or expert CLI

pep s u q cid x.x.x.x

pep s u q usr USERNAME

We had small issue after upgrade to R80.10 (from R77.30) - roles that had used both usernames and machine ID's in the same role stopped working, so we had to create two seperate roles - one for machine IDs and one for usernames


0 Kudos

The access role we are using only has one specific AD group assigned, and for some reason this access roles stopped working.

I did check IA via smartlog the way you described it and for this particular user, and when i correlate it with the access logs, i see a lot of Access Roles updates where it seems like the user sometimes is not part of the needed Access Role anymore.

Those were probably the moments i was playing with the config.

As a test, I created a new AD group, not nested with other permission groups but it only had 2 users in it.
When adding this new test group to a new test Access Role i created, the rule worked perfectly and the user could access the needed recources.

That leads me to believe there is only a problem for with a specific nested AD group, and it's only for this specific policy rule using the troublesome Access Role.
We use a lot of other Access Roles with nested AD groups and without issues.

I wonder how to get this working again. I'm puzzled.

0 Kudos

Did the DN of the problematic group get changed in AD?  Perhaps renamed or nested under a different OU?


R80.40 addendum for book "Max Power 2020" now available
for free download at
0 Kudos

you can check how deep gateway will dig using this command below

pdp nested status
Enabled - recursive. Depth: 20

0 Kudos

To come back to this, it was a problem in R80.20 for which a hotfix needed to be installed in order to get a whole bunch of other stuff resolved as well.

With the R80.20 Jumbo HotFix - General Availability Take 87 installed, nested AD groups don't pose any problem no more ... for now 🙂


0 Kudos