AD changes should update instantly in checkpoint rules

[Edi]

Hello Mates,

We have identity awareness working already (R80.30) and for compliance purposes we must move some user/groups in the active directory server. We already made the change and when we search for the user/group we see the correct AD path for the user/groups we move, but in the rules when they were configured before they remain with the old AD path.

- Is this a normal behavior and we should create new access role objects or it should update automatically?

- in case we must change the rules manually, it's possible to just edit the current object with the new path or is necessary to create new objects?

Thanks in advance for your help and I look forward to your comments,

Kind regards,

Edi.

[PhoneBoy]

We have zero visibility into when you move a group into a different part of the AD structure.
As such, the existing Access Roles and/or LDAP Groups would need to be updated with the new path. 

[the_rock]

My experience is very mixed with this...sometimes it gets updated right away, sometimes we have to push the policy, so needless to say, its very inconsistent. I dont even want to waste my time opening case for it, since multiple people in TAC I asked about this told me they are not sure how this is supposed to work and no document states clearly either.

Andy

[Tobias_Moritz]

I think I can answer this from my expirience: "It depends" 🙂

If you "move" AD users or groups by putting them into different AD groups than before without changing their "position" in AD tree (changing OU), then you do not have to re-add the access rules members if your filter definition is still valid. You just have to wait until group memberships are recalculated which is done automatically (when exactly is version and setting dependend).

But I think with "moving" you mean moving objects to a different position in AD tree by changing the OU. And there you have a problem with R80.40 or older. The reason: Check Point DEVs created Identity Awareness as an feature with LDAP support in mind, not directly Active Dictory. They needed a primary key for storing selected LDAP Objects in Picker (the one where you select AD objects in SmartDashboard / SmartConsole) in CP database. And they choose the LDAP DN attribute. This attributes is a string which includes the whole position in LDAP tree and the object name. Thats the reason why moving objects around (OU change) and also renaming of objects (CN) in AD forest results in unmatching Access Roles on Check Point side - the DN does not match anymore. You had to delete the objects from the roles and add them back again using the picker so they are re-added to the CP database with the new DN. Followed by a policy installation on the relevevant gateways with PDP role.

I guess 99% of CP IDA environments are MS AD and not other LDAP services and so choosing DN as primary attribute was not the best decision looking from today. MS uses SID as primary key which makes much more sense. The SID of an object in MS AD never changes during its lifetime regardless of state, name or position in forest.

After many years, it looks like CP DEVs thought it the same way and with R81 they introduced the optional switch from DN to SID.

See here:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_IdentityAwareness_AdminGuide/Topic...

[Tiago_Cerqueira]

Hi guys,

I also encountered this issue on R80.40. Does anyone know if there is a quick and easy way to perform this update? So far, I'm stuck with deleting and re-creating the user roles for this.

Thanks!

[Tobias_Moritz]

What do you mean with "this issue"? I talked about two different problems.

If you meant the one with the DN-Change: Upgrade to R81 and reconfigure Identity Awareness to use SID instead of DN like described in the link I posted above. If you cannot or do not want to upgrade to R81, you have no other option than to remove the problematic objects from access rules and add them back in using the picker. No need to delete and recreate the role objects. In case you changed the DN for a large number of objects, you could manipulate CP database directly (CPMI) and overwrite the old DNs with the new ones to save time for manual work.

[Tiago_Cerqueira]

Hi,

My apologies for this, I was typing while on a meeting. Yes, I was referring to the DN change part and you've answered it: there's no need to recreate the role, but I'll have to update the role by adding the "new users". There is no edit or batch option to do this (I suppose a script could be wipped up to do it), but there isn't one out of the box

My apologies for the misunderstanding

[Tobias_Moritz]

Sorry for the harsh wording.

You can automate this by either using the modern API (REST) or the old dbedit approach (CPMI). Unfortunatly, I'm also not aware of any out of the box script to do this.