Does anyone know off hand if there is a way in pdadmin (or policy administration, but I find pdadmin is way more powerful) to deal with users where a duplicate secDN gets created (because of some outside process)?

For example, we get this complaint from our account management folks quite a bit:
Error: HPDMG0752E More than one matching Distinguished Name (DN) was found. (status 0x14c012f0)

We have an external provisioning process that does not use the registry direct API but was custom coded that sometimes causes this issue, and it's a real pain to deal with as I have to get elevated rights on the directory to resolve it for the account team.  I wasn't sure if anyone knew if there was an easy way in pdadmin to resolve it, or if this was definitely something that can only be addressed with writes directly to the directory.

Thanks!

------------------------------
Matt
------------------------------

Hi Matt,

The pdadmin command does not offer any type of LDAP modification so to speak at the LDAP API level.  About the best you can do is delete the account and recreate.  This may not always be wise if the users have been directly placed on ACLs.  The best option is direct LDAP API calls to the LDAP server.

This is not uncommon when provisioning is done without using the ISVA APIs.  Best option is to add the necessary duplicate checks inside the provisioning.

------------------------------
Nick
IBM Security Verify Customer Support
------------------------------

Original Message:
Sent: Wed February 16, 2022 01:35 PM
From: Matt Jenkins
Subject: Dealing with duplicate secDNs

Does anyone know off hand if there is a way in pdadmin (or policy administration, but I find pdadmin is way more powerful) to deal with users where a duplicate secDN gets created (because of some outside process)?

For example, we get this complaint from our account management folks quite a bit:
Error: HPDMG0752E More than one matching Distinguished Name (DN) was found. (status 0x14c012f0)

We have an external provisioning process that does not use the registry direct API but was custom coded that sometimes causes this issue, and it's a real pain to deal with as I have to get elevated rights on the directory to resolve it for the account team.  I wasn't sure if anyone knew if there was an easy way in pdadmin to resolve it, or if this was definitely something that can only be addressed with writes directly to the directory.

Thanks!

------------------------------
Matt
------------------------------

If you create your own custom provisioning process, bypassing the API's provided by the target application, additional burden of validating the data is placed on that custom process.

Whenever provisioning using provided/supported API's, like RGY or Admin API with ISAM, you can mostly rely on the API's validating the data.

The only way to handle these issues is to correct the erroneous entries in the registry itself, as the custom process has basically breaks the registry consistency regarding that user, due to insufficient error handling.

The recommendation will be to build additional checks and validation on the custom provisioning interface, or more preferably change it to utilize RGY API, or change to provisioning process offered by a product that provides official adapter to interface with ISAM.

------------------------------
Aki Virtanen
Security Software Consultant
IBM Security Software Lab Services
------------------------------

Original Message:
Sent: Wed February 16, 2022 01:35 PM
From: Matt Jenkins
Subject: Dealing with duplicate secDNs

Does anyone know off hand if there is a way in pdadmin (or policy administration, but I find pdadmin is way more powerful) to deal with users where a duplicate secDN gets created (because of some outside process)?

For example, we get this complaint from our account management folks quite a bit:
Error: HPDMG0752E More than one matching Distinguished Name (DN) was found. (status 0x14c012f0)

We have an external provisioning process that does not use the registry direct API but was custom coded that sometimes causes this issue, and it's a real pain to deal with as I have to get elevated rights on the directory to resolve it for the account team.  I wasn't sure if anyone knew if there was an easy way in pdadmin to resolve it, or if this was definitely something that can only be addressed with writes directly to the directory.

Thanks!

------------------------------
Matt
------------------------------

Nick and Aki, thanks for the input.

I understand that handling these issues would be best, or simply using the RD API.  Unfortunately, I don't control the code that is causing this condition.  It was the result of another team.  I asked them to implement such checks a while back but they have yet to have time to do so.  They never thought it would be an issue but the order of timing because of user input error is what causes their code to make the mistake.  So myself being on the ISVA admin side of the house, I have to deal with it to resolve issues with user accounts.  I was hoping that maybe there was some trick in pdadmin that I was unaware of that would allow the second account with the duplicate secDN to be removed.  Seems that is not the case.

Thanks again.

------------------------------
Matt Jenkins
------------------------------

Original Message:
Sent: Fri February 18, 2022 03:53 AM
From: Aki Virtanen
Subject: Dealing with duplicate secDNs

If you create your own custom provisioning process, bypassing the API's provided by the target application, additional burden of validating the data is placed on that custom process.

Whenever provisioning using provided/supported API's, like RGY or Admin API with ISAM, you can mostly rely on the API's validating the data.

The only way to handle these issues is to correct the erroneous entries in the registry itself, as the custom process has basically breaks the registry consistency regarding that user, due to insufficient error handling.

The recommendation will be to build additional checks and validation on the custom provisioning interface, or more preferably change it to utilize RGY API, or change to provisioning process offered by a product that provides official adapter to interface with ISAM.

------------------------------
Aki Virtanen
Security Software Consultant
IBM Security Software Lab Services

Original Message:
Sent: Wed February 16, 2022 01:35 PM
From: Matt Jenkins
Subject: Dealing with duplicate secDNs

Does anyone know off hand if there is a way in pdadmin (or policy administration, but I find pdadmin is way more powerful) to deal with users where a duplicate secDN gets created (because of some outside process)?

For example, we get this complaint from our account management folks quite a bit:
Error: HPDMG0752E More than one matching Distinguished Name (DN) was found. (status 0x14c012f0)

We have an external provisioning process that does not use the registry direct API but was custom coded that sometimes causes this issue, and it's a real pain to deal with as I have to get elevated rights on the directory to resolve it for the account team.  I wasn't sure if anyone knew if there was an easy way in pdadmin to resolve it, or if this was definitely something that can only be addressed with writes directly to the directory.

Thanks!

------------------------------
Matt
------------------------------

Hi Matt,
I've just had a similar issue while using the API. The code doing the provisioning used a ISAM Account which had a password policy and the password needs to be changed. As WebSEAL always (correctly) returns HTTP 200, they didn't catch the failure. So they created the user object but the registry object. Just did a script to find which users are affected as this is causing some trouble with customers trying to register. As you see there are a couple of issues with or without API. Provisioning is a process which needs a lot of attention.

------------------------------
Jens Petersen
------------------------------

Original Message:
Sent: Tue February 22, 2022 10:09 AM
From: Matt Jenkins
Subject: Dealing with duplicate secDNs

Nick and Aki, thanks for the input.

I understand that handling these issues would be best, or simply using the RD API.  Unfortunately, I don't control the code that is causing this condition.  It was the result of another team.  I asked them to implement such checks a while back but they have yet to have time to do so.  They never thought it would be an issue but the order of timing because of user input error is what causes their code to make the mistake.  So myself being on the ISVA admin side of the house, I have to deal with it to resolve issues with user accounts.  I was hoping that maybe there was some trick in pdadmin that I was unaware of that would allow the second account with the duplicate secDN to be removed.  Seems that is not the case.

Thanks again.

------------------------------
Matt Jenkins

Original Message:
Sent: Fri February 18, 2022 03:53 AM
From: Aki Virtanen
Subject: Dealing with duplicate secDNs

If you create your own custom provisioning process, bypassing the API's provided by the target application, additional burden of validating the data is placed on that custom process.

Whenever provisioning using provided/supported API's, like RGY or Admin API with ISAM, you can mostly rely on the API's validating the data.

The only way to handle these issues is to correct the erroneous entries in the registry itself, as the custom process has basically breaks the registry consistency regarding that user, due to insufficient error handling.

The recommendation will be to build additional checks and validation on the custom provisioning interface, or more preferably change it to utilize RGY API, or change to provisioning process offered by a product that provides official adapter to interface with ISAM.

------------------------------
Aki Virtanen
Security Software Consultant
IBM Security Software Lab Services

Original Message:
Sent: Wed February 16, 2022 01:35 PM
From: Matt Jenkins
Subject: Dealing with duplicate secDNs

Does anyone know off hand if there is a way in pdadmin (or policy administration, but I find pdadmin is way more powerful) to deal with users where a duplicate secDN gets created (because of some outside process)?

For example, we get this complaint from our account management folks quite a bit:
Error: HPDMG0752E More than one matching Distinguished Name (DN) was found. (status 0x14c012f0)

We have an external provisioning process that does not use the registry direct API but was custom coded that sometimes causes this issue, and it's a real pain to deal with as I have to get elevated rights on the directory to resolve it for the account team.  I wasn't sure if anyone knew if there was an easy way in pdadmin to resolve it, or if this was definitely something that can only be addressed with writes directly to the directory.

Thanks!

------------------------------
Matt
------------------------------