Use identifier other than DN for LDAP-Connector?

[lzimmerm]

Hi everyone,

we are facing a problem with our LDAP provisioning (to Microsoft AD). We have a quite diversified OU-structure in our AD, which unfortunately can change from time to time. New OUs or group names are of course not a problem, but name changes can occur as well.

With IDM using the DN of an identity or of a group as the unique identifier in the LDAP-connector, such changes will have huge impact on the IDM, because the DN will change and the IDM will no longer find the person/group in the active directory.

We have tried to use the samaccountname in the connector instead of the DN, but it does not work, IDM does not find the entry in the AD.

Does anyone know of another possibility to deal with this problem? Is there any way to adapt the connector in such a way that it can use e.g. the samaccountname or even better the guid as an identifier?

Thank you very much in advance,

best regards

Lisa

[former_member201064 · Accepted solution]

Hello Lisa,

unfortunately in the standard ToLDAP pass it's not possible to use anything other then the DN. In theory a VB script (like the one which sets the password) would be possible but that won't survive an 8.x migration. Another idea would be to write your own connector using a Java class and a ToCustom pass. Yet, I think these are no realistic options and there is a quite easy solution.

What we did:

We have a similar setup as you described. Four domains and ongoing migrations in our Group domain. As we started with 7.1, we have the DN<repName> attributes containing the DN. The ACCOUNT<repName> attributes contain the samAccountName. Standard in 7.1, I don't know why they changed that. In your case it would be the other way round. Leaving the DN in the ACCOUNT attributes and adding another attribute for each domain. Z_SAMACCOUNTNAME<repName> or whatever prefix instead of Z you use for your own attributes. The repName should be included if you have more than one domain

We use nightly load jobs which read out all domains. We have jobs with 22 passes active, including AD group handling with triggers and everything. In the passes for the users we set the DN to the the DN<repName> attribute. Matching to the identity (MSKEY/MSKEYVALUE) works using the ACCOUNT<repName> with a script. Query in the script:

var sql = "SELECT DISTINCT s1.mskey FROM IDMV_VALUE_EXT s1 with (nolock) JOIN IDMV_VALUE_EXT s2 with (nolock) ON s1.MSKEY = s2.MSKEY WHERE s2.Attrname = 'MX_ENTRYTYPE' AND s2.Searchvalue = 'MX_PERSON' AND s1.Attrname = 'ACCOUNT" + repName + "' AND s1.Searchvalue = '" + userid + "'";

repName and userid (=samAccountname) are the parameters of the script.

The change of the samAccountName has to be done in the IdM (we have a request for that). So not that much problems missing out samAccountName changes. Well, there are a lot of provisioning errors due to no DN or wrong DN. Luckily we don't have to care that much about that. If someone misses something, they will open an incident anyway. A bit mean though, but compared to the total user number we handle in the IdM and the total incident numbers, we don't have that much trouble.

What may come in handy for you:

In the plugin (use your own plugin, modifying the SAP one isn't recommended) add another task / job with a ToGeneric pass. In that script use

var ldapEntry = uLDAPGetEntry(searchString, "%$rep.LDAP_LOGIN%", "%$rep.LDAP_PASSWORD%")

to search for the user using the samAccountName. Something like this should work for the searchstring:

var searchString = LDAP://%$rep.LDAP_HOST%:%$rep.LDAP_PORT%/??BASE?(samaccountname=<username>)

After that you can retrieve the dn using ldapEntry.get("distinguishedName"). At least I hope the uLDAPGetEntry function is capable of generic LDAP searching, haven't tried it out without the DN though.

I use with the DN to search for the homeMDB attribute, which determines if a user has a mailbox maintained by us. Depending on that I have a task with and a task without the mail attribute. You could do something similar and set the DN attribute with a uIS_SetValue before executing the ToLDAP. That would also be possible as a Source tab Entry script so you wouldn't have to add another task.

Best regards

Dominik

[lzimmerm · Accepted solution]

Hi Dominik,

thank you so much for your detailed instructions and sorry for my very delayed reply, but we've been busy in setting up our productive system.

I will look into both solutions and try them out, and I'll let you know how it goes

Cheers

Lisa

[lzimmerm · Accepted solution]

Hi Dominic,

it's been a while, but I finally had enough time to test around a bit. I am now able to read out the DN of a user using a script with an LDAP searchstring and the user's samaccountname. Actually I took it up a notch and am now use the objectGUID from the active directory, as this will not change for sure. This works fine, although the objectGUID has to be decoded first, so that the LDAP search string can read it.

Now I am thinking about how to implement this in our processes. And my idea would be to implement the look up script in the modify ADS user pass of the AD connector, so that each time a user is provisioned a new AD privilege, the user's DN will be looked up first in the AD, then his/her's account attribute will be updated and then the provisioning can take place.

We actually already do a similar update of the account attribute right now, but only because a user's AD OU could have been changed via the IDM and then we need to put together a new account attribute so that the user gets put into the right AD OU. Or, in case the DN of an AD OU has changed, then we have to update our OU list in the IDM first, and then the DNs of users from that OU need to be renewed as well.

So, we have a workaround for users, but the lookup of the DN would still be a safer way to go.

Nevertheless, my second even bigger problem is, if the name of an AD group changes (either because it is renamed, or the name of its OU changes). I think I could use the DN lookup here as well and solve our problems, but in our initial load the MSKEYVALUE of a group privilege is set including the DN of the group. Meaning, a change of the DN of a group will lead to a new privilege in IDM, so all the privilege and role references will then be wrong.

I am thinking now, that using the objectGUID for the MSKEYVALUE of the group privileges could solve this problem, as the privileges would be robust against DN changes. Only the account attribute would then be equal to the DN and could be updated through lookups before being provisioned to a user.

Is it duable to use the objectGUID instead of the DN for the creation of MSKEYVALUES of group privileges? Or could it have negative consequences?

I am sorry for the long pretext, but the subject is quite complicated and when it comes to manipulating the connectors or such basic things as naming conventions for priviliges, I want to be very careful not to overlook anything.

Thank you and cheers

Lisa

[brandonbollin · Accepted solution]

Make sure to mark Dominik's answer as, "helpful". He definitely deserves points for that level of detail! 

[lzimmerm · Accepted solution]

Your're right, of course!

Sorry, Dominic, I am still a bit new to this, but I marked your answer as helpful!

Cheers

Lisa

[former_member201064 · Accepted solution]

Lisa Zimmermann wrote:


Is it duable to use the objectGUID instead of the DN for the creation of MSKEYVALUES of group privileges? Or could it have negative consequences?

Well, it is possible and as you already mentioned, it has to be done carefully and with planning.

You have to adapt the hook tasks for assign and remove of the groups. If you haven't already done this, copy the existing SAP plugins into your own provisioning folder. There I differentiated CORE and CONNECTOR like the SAP did (including a numbering system ). Have I ever used the standard hook tasks (several projects when I was a consultant)? Nope, I always copied the tasks into the own built folder. Actually the tasks configuration for the companies where I work now is identical to the SAP delivered one, but I like to have them all in one place. Back to the topic.

You can store the MSKEYVALUE with anything, including the objectGUID. I don't know by heart what is used in the plugins 4 and 5, MSKEYVALUE or the ACCOUNT attribute. As I somehow remember that the PRIV:GROUP:<repName>: is removed in the plugins, I guess that's the case.

Don't forget that the update job has to be adapated to match objectGUID onto the MSKEYVALUE and set the rest of the attributes accordingly.

Your way of setting up the provisioning is tough but I guess it's worth it as it seems to be the most perfect one I have heard of. I only do add and remove in my nightly sync jobs to ensure that AD and IdM are identical. Or at least up to 96% as I measured some weeks ago. I tried to improve the removing of groups but I messed up the query and it runs forever.

[former_member2987 · Accepted solution]

Using GUID is always my preference for AD operations as it never changes, however using the DN is good just because it is more "readable"

[lzimmerm]

Hi Dominic, hi Matt,

I have not yet set up the GUID for creation of MSKEYVALUEs, I am still cautious to implement my idea, and we are now going from 7.2 to 8.0, so I will wait until that is finished anyway. Afterwards I still have my 7.2 test machine though and I guess I'll give it a try there first.

Thank you for your help so far and I will update the post again as soon as I continue my work in this area.

Cheers
Lisa

[Chenyang]

Hi Lisa,

I thin you can also use SAMAccountName as unique identifier in your case. It should be possible to handle in standard way.

Suppose you have a AD structure like below

ROOT

       -- OU=GROUP CONTAINER

                -- CN=GROUP1

                -- CN=GROUP2

       -- OU=USER CONTAINER

               -- CN=USER1

               --CN=USER2

Then it is changed to

ROOT

       -- OU=GROUP CONTAINER_NEW

                -- CN=GROUP1

                -- CN=GROUP2

       -- OU=USER CONTAINER_NEW

               -- CN=USER1

               --CN=USER2

In a standard LDAP Initial load job, there are read passes and write passes. You just need to make sure you always read from the ROOT, so that all the groups/users are loaded into a temp table in IdM.

Then you can use the unique identifier to distinguish the same group / user. The identifier can be as you said objectGUID, or you can also use SAMAccountName, because it cannot be changed once created. then I think the rest should be standard.

Once everything is loaded into a table, you shall have chance to determine whether is a new group/user or a DN update for existing group/user.

The better way (if feasible) to handle this might be that you track the update of the container update periodically. Once the container updates, everything beneath it should be updated accordingly. You can load the AD container into a custom entry type and setup a event trigger to update the user/group's DN.

That's my 2 cents.

Chenyang