Identity Awareness - SID instead of DN for AD Users - Migration for existing objects

[Tobias_Moritz]

Hello community,

in R81, Check Point finally introduced the usage of SID instead of DN for referring LDAP (usually AD) objects in Identity Awareness.

While this feature was really appreciated (we asked for that already in R77 days), it is still disabled by default and has to be enabled per Gateway:

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_IdentityAwareness_AdminGuide...

But the real problem is the database for upgraded environments. All objects of type ad_users and ad_groups which are created in Check Point database after upgrade to R81 are having the sid attribute filled.

However, users or groups who where added to datebase (because used in some access roles) before the upgrade have an empty SID field.

So while the R81 upgrade extended the datebase scheme to support the sid field, there was no process to update existing objects.

Now to the question: If a customers has thousands of ad_user/group objects in Check Point database and wants to move from DN to SID because of the obvious benefits: How should it do this?

How can we update existing user or group objects with SID? Manually edditing the CP datebase or removing all users and groups from all access roles and re-add them does not sound like a good idea.

Does anyone has a better idea?

Is there any recommendation from Check Point side?

[G_W_Albrecht]

Found this https://support.checkpoint.com/results/sk/sk43874

[Tobias_Moritz]

Hello Günther,

thank you, but I think that sk does not match my topic.

That sk is for setting up an non-domain-admin account for legacy AD query and you need the SID of that account during the steps for rights adjustment.

I'm talking about ad_users or ad_groups objects in Check Point database.

If I missed something relevant in that sk, please drop me a hint, which section you meant.

Here you see two user objects in DB. First one was created in DB by adding it to an access role in SmartConsole picker before upgrade to R81+, second one after. First does not have SID field filled, second has.

> show generic-object uid 5c3fb0f1-ad6f-4ac5-8a0f-223036850a83
lastName: "User1"
samAccountName: "user1"
dn: "CN=Bob User1,OU=Users,DC=domain,DC=tld"
type: "ad_user"
userName: "User1"
sid: ""
folder: 
  uid: "8593a614-3f8e-43ea-b2ed-d40221ecd429"
  name: "Global Objects"
domain: 
  uid: "41e821a0-3720-11e3-aa6e-0800200c9fde"
  name: "SMC User"
  lastModifytime: 1678703835239
  creationTime: 1678703835239
_original_type: "CpmiAdUser"


> show generic-object uid 8c4e65cf-0d24-4107-872f-a3bf856acfed
lastName: "User2"
samAccountName: "user2"
dn: "CN=Simon User2,OU=Users,DC=domain,DC=tld"
type: "ad_user"
userName: "User2"
sid: "AQUAAAAAAAUVAAAAIjc9DKjHQ4gou0vN19gAAA=="
uid: "8c4e65cf-0d24-4107-872f-a3bf856acfed"
folder: 
  uid: "8593a614-3f8e-43ea-b2ed-d40221ecd429"
  name: "Global Objects"
domain: 
  uid: "41e821a0-3720-11e3-aa6e-0800200c9fde"
  name: "SMC User"
meta-info: 
  lastModifytime: 1697202257626
  creationTime: 1697202257626
_original_type: "CpmiAdUser"

[PhoneBoy]

I suspect you will have to delete and re-add the relevant objects.
Having said that, seeing that you can see the information with a generic-object API call, you might be able to set it.
@Omer_Kleinstern can it be done?

[ProxyOps]

Hi,

we did this via a large shell script that was provided by Check Point TAC. We had the exact same issue one or two years ago.

We executed the script in two Managements systems with hundrends of ad_groups and it worked really well. 

I am just a litle bit unsure if I can just sent you the scripts + the guide how to use it. Maybe a double check with TAC would be recommended, to ensure, that the script is still working etc. 

I don't know the policy here to be honest.

Best regards

[_Val_]

Hi @Tobias_Moritz 

After consulting with R&D guys, here is the what you need to do:

Please open a TAC case for this. Once you have an SR, please send it to me via PM. I will make sure the relevant R&D ppl will provide you with assistance through the official channels.

[Tobias_Moritz]

Just to update you folks, after a session with TAC (Debug) yesterday:

There is a component called SIDupdater nowadays which has the job to update all ad_user and ad_group objects with SID values, if they are empty. This component runs after upgrade to R81+. If it fails for whatever reason, it retries later three more times. After that, it gives up. You can see this in db table SidUpdaterRetriesCounter_data.

In our case, this job ran, but without success. We modified that table to reset the retry-counter and did a cprestart. Before that, we enabled debug logs for cpm->SIDupdater to see, what it is doing.

SIDupdater ran, found all affected ad_user and ad_group objects, aquired SIDs for them successfully but finally crashed with a NullPointerException before being able to push the updates to db.

R&D will now look at debug logs to understand, why it crashes.

I will update you again, when this issue is solved.

Thanks, Val, for routing that TAC case in the right direction 🙂

[_Val_]

I hope this will be resolved soon

[Tobias_Moritz]

I promised to update this thread when the issue is solved, so here I am:

We got a custom hotfix for this issue. It will be integrated in future jumbos, but this will take a while.

Bug ID: PRHF-31314

Hotfix: mgmt_wrapper_HOTFIX_R81_20_JHF_T26_309_MAIN_GA_FULL.tar (md5 330939DBA31DA9068C9FCB24698B759D)

Content: Fixed versions of ldap.jar and dleserver.jar support case insensitive between LDAP and management server.

[Gennady]

I have another update for the issue in case if someone has the same problem even after update to R81.20 take 70 or later.

I used results of the command " psql_client cpm postgres -c 'select * from SidUpdaterRetriesCounter_data' " as an entry point to create a TAC case. TAC engineer explained to me that the problem may occur even on the latest JHF takes if SIDUpdater had tried to update SIDs 5 times and failed. The result of the 5 attempts is stored in SidUpdaterRetriesCounter_data. SIDUpdater will not try to update SIDs until the table is reset.

TAC provided the following command to reset the table:

# psql_client cpm postgres -c "begin; alter table  SidUpdaterRetriesCounter_data disable trigger all; update SidUpdaterRetriesCounter_data set completed='f' where dlesession=0 and not deleted; update SidUpdaterRetriesCounter_data set retriescount=1 where dlesession=0 and not deleted; alter table  SidUpdaterRetriesCounter_data enable trigger all; commit;"

Then I did cprestart on the Management server and installed policy on the Identity Awareness related Security Gateways. This forced SIDUpdater to try to update SIDs again and it worked because the solution for PRHF-31314 had been already integrated into the latest JHF.