Skip to Content

Using modRDN with SAP NW IDM

One of the benefits of SAP NetWeaver IDM is how it embraces not only SAP Systems, but other systems that can be found in the typical enterprise IT department. In a previous post, I described how one can use the embedded IDM scripting functions to search for an entry in the LDAP. However there is more that you can do with LDAP besides searching. Probably one of the LDAP functions I use the most is called modRDN (Some detailed definitions and examples can be found here and here). In a nutshell, executing a modRDN operation allows for changes to be made in the Relative Domain Name. This is always a unique value in the DIT structure; and usually one that changes during the Stages of Identity. These changes usually take one of two forms which I have specified below:

  1. A change to the common name (cn) component of the distinguished name. The classic use case is the change of surname after a person gets married[1]: cn=Deanna Troi,ou=USS Enterprise,dc=StarFleet,dc=com becomes cn=Deanna Riker, ou=USS Enterprise,dc=StarFleet,dc=com. For our purposes, we’ll call this a name change.
  2. A change in the ou or container component of the distinguished name. This is usually a departmental or geographic change such as: cn=Deanna Riker,ou=USS Titan,dc=StarFleet,dc=com. For our purposes, we’ll call this an organizational change.

    Note: This process is also used frequently as part of the deprovisioning process. There is typically a requirement to move the newly separated used into a “holding container” for some period of time (usually 30-180 days) so as to keep access to linked email accounts, contact information or regulatory reasons.

It’s not too hard to see why this would be an important operation during IDM related operations. People change names with some frequency and will change departments, locations and other defining components with greater frequency. So let’s take a moment and describe how this happens in IDM:

Image 1.png

This screenshot comes from the IDM Job Wizard, which can be accessed after creating a new active task under any workflow task node (New->Job Wizard->Identity Center->Jobs->Active Directory->Modify RDN Active Directory.

Image 2.png

You’ll notice that this is a pretty generic setup as with most of the included IDM templates. Before using the modRDN enabled task for the first time, make sure you set the correct repository (It is supposed to be set during the Wizard, but did not for me in a To LDAP pass using SAP IDM 7.2, SP4) and that your starting point is correct as the Wizard takes a slight Active Directory bias by defaulting to cn=users. 

Image 3.pngThen all that needs to be done is setting up for your use case, name  change or organizational change. Let’s take a look at the name change  scenario setup:

Image 1a.png

So what do we have?

  • We have to specify the dn of the user in the directory. Don’t forget to make sure that the cn component is correctly specified. This might be MSKEYVALUE, it might be firstname.sn, it might be first initial, last name, or it might be anything, so make sure you know for sure!
  • The changetype is specified next which, as we know, is modrdn, and is not case sensitive.
  • The newrdn will tell us what we are changing in this entry. This value must be unique within the directory.
  • Since this operation creates a new RDN, we should get rid of the old one. By setting deleteoldrdn to 1 we will remove the old RDN that exists in the directory.
  • Finally we’ll set the new (if any) balance of the RDN through the newsuperior value. In this case we are not since this is a name change only.

This brings up a couple of other points that we should make about the modRDN function as it pertains to the Directory Service and to SAP IDM in general. First off, this process will not change the MSKEYVALUE or any other IDM attribute in your Identity Store. If you want that done, it will have to happen in subsequent passes / tasks. Nor will this process change other Directory Service attributes such as the Active Directory sAMAccountName. If there is a need to change the MSKEYVALUE, information can be found here; similarly if the sAMAccountName needs to be changed, that information can be found here. Also it’s a good idea to make sure that you update your IDM attribute that holds the dn with the new value (ACCOUNT$rep.$NAME).

Now if you need to make an organizational change, it would look like this:

  Image 2a.png

Everything is pretty much the same here except for the newsuperior value which now reflects Will Riker’s transfer. Incidentally, I guess standards are different on the new ship since he also has a changed cn as well.  This also shows that we can change multiple parts of the RDN in the same modRDN operation.

I hope that during this article I’ve been able to shed a little light on some things that you can do with your IDM and a connected Directory Service. 

 


  • [1] This is not my favorite Star Trek series or character for that matter, but it serves as an example. Please don’t ask where I would have placed Wesley  ๐Ÿ˜€
23 Comments
You must be Logged on to comment or reply to a post.
  • Hi Matt,

    Excellent!.

    I am using this functionality to move users in the same domain but since a short time we started to get the following LDAP error:

    Exception from Modify operation:javax.naming.NameNotFoundException: [LDAP: error code 32 – 0000208D: NameErr: DSID-0310020A, problem 2001 (NO_OBJECT), data 0,

    Everything match and the user is moved to the new OU but we still see errors in the job. Any idea what the cause(s) could be for this behavior?

    Regards,

    Ridouan

    • Ridouan,

      Glad you were able to get something from the article.

      LDAP Error 32, as you probably have already discovered, means that the object cannot be found or does not exist.  I’ve also seen this happen from time to time due to insufficient rights given to the service account that is linked to the IDM Dispatcher Service.

      Therefore, I’d start by checking:

      1. Is the target DN correct? The easiest way to check on this is to create a test user in the “New OU” and then check its DN via an LDAP browser (if you’re using AD 2008, the Attribute Editor works just fine). You might also want to send the “new OU” to the Job Log via uWarning as a way of checking things as well.  A malformed DN could also be the cause of your problems.

      2. It’s probably also a good idea to check the “source” DN as well.Make sure that your task is correctly interpreting it. (You can double check the DN via the ACCOUNT$rep.NAME$ (DN%$rep.$NAME%) attribute for your LDAP repository.

      3. Check the Service account.  Have the rights to this account been changed?

      You seem to indicate that this is something that was working for a while and then stopped.  This gives me the feeling that it’s something infrastructure related.

      Regards,

      Matt

    • Hi Ridouan,

      I had exactly the same issue and the problem was caused, because the task was executed twice. If you take a closer look at tasks results you’ll probably see that task was executed twice. Frist time the rename was successful and that is why second time it fails (The person is in another location already ๐Ÿ™‚ )

      At least this was the case in my scenario and your explanation fits it best.

      Hope I’ve been helpful.

      Best regards,

      Ivan

  • Hi Matt,

    Great blog, and just to add one common misconception. This does not create a new AD account and delete the old one, as perhaps suggested by deleteoldrdn, it only deletes the old DN value on the account. This means that anything on the AD account that IdM doens’t know about is left unchanged.

    Thanks again for sharing,

    Ian

    • Ian, very true.  I don’t recall if I noted it but ModRDN stands for Modify Relative Distinguished Name which is clearly not a deletion.  The beauty of this operation is that one does not have to delete anything in order to make changes.  Thanks for bringing up the point, it’s an excellent clarification!

      • Some LDAP server (not ADS) documentation says something to the effect of deleteoldrdn defines the action to be taken with the original DN following a modrdn. 0 (false) the original entry is retained or 1 in which case the original entry is deleted.

        ADS refuses to work with anything but deleteoldrdn=1 if I recall correctly, while some other LDAP server refuses any other values than true or false.

        Everone has their own LDAP standard…

  • Hello Matt,

    Wesley’s probably back on time traveling. He just visited for the wedding. ^^

    Thank you for the blog. You have a great way of making these complicated things very good to understand. I like the way you write, it’s fun, but at the same time full of info and that suits me a lot. ๐Ÿ™‚

    Regards,

    Steffi.

  • I did just notice one thing about this entry that kind of disturbs me.  During the ModRDN I’m using the DN as the unique identifier which is ok, but doesn’t really work so well if you’re changing the cn component of the DN (e.g., Deanna Troi –> Deanna Riker) in this case, the AD GUID should be used.  This is something that can be obtained in the workflow or as part of a scheduled reconciliation task.  If there’s interest, I’ll be happy to update or write a new blog reflecting this.

    • Hi Matt,

      Well I’m not sure how valid is the case you are talking about.

      Changing the CN for me means just a different user. There shouldn’t be change of CN for one and the same user.

      If you are referring the case with the change of the name, because of marriage or something, this should not bring the change of the CN, but only a change of name.

      It is the same like if you build up the MSKEYVALUE with the names of the user. Than if the user has changed his name you do not change the MSKEYVALUE, but only the user names.

      Best regards,

      Ivan

      • Well Ivan, it all depends on the use case.  For environments where name change affects CN (or mskeyvalue, or sAMAccountname) these changes will need to be made. In this scenario, referencing ModRDN using the DN can cause issues, which is why using the GUID makes more sense.

        Regards,

        Matt

        • Well Matt,

          You know that MSKEYVALUE is a key field according IDM documentation (I’m well aware that actually it isn’t), so there shouldn’t be a scenario in which you should change it ๐Ÿ™‚

          It looks to me like a bad design instead of real case scenario.

          But you know, what is bad for me is might be good for someone else.

          Please do the blog, you’ve got my interest ๐Ÿ™‚

          Best regards,

          Ivan

          • Ivan,

            I’m not a fan of doing this either, but at the end of the day, I’m a consultant, and if that’s what the customer wants, that’s what they get. 

            I originally wrote this blog a few years ago regarding the renaming of MSKEYVALUE based on such a use case from a customer where they wanted sequentially generated MSKEYVALUES, and the topic has come up from time to time here on SCN.

            While MSKEYVALUE is a key, it’s not quite as important as MSKEY which is the key used for all internal relations, and you’ll never see that tampered with.  The IDM developers knew there would be potential need for changing the LoginID value.

            Matt

          • Hi Matt,

            Thanks for the link, but you got me wrong. I know how to change MSKEYVALUE and I’ve done it several times, as you said the Client is the important one ๐Ÿ™‚

            I’m more interested in the AD and GUID blog, this is where you get my interest, although I never had such case till today, you never know what is waiting for you tomorrow ๐Ÿ™‚

            Best regards,

            Ivan

  • Great blog!

    Just realised that deleteoldrdn will control if the old cn will be deleted from the LDAP account or not. So it seems always be good to have this in the pass like shown above.

    Cheers, Jannis

  • Hello,

    I love this blog and already used it quite a few times, usually to move users to a “toDelete” OU or something of the kind.

    This time, I’m faced with something different and I have trouble with the user’s group membership. Groups are not managed by IDM, we only create the users. For some, we need to rename them using modrdn. On the user, the attribute memberOf is well replicated. On the group, the attribute uniquemember is still linked to the old DN.

    Is there a way to easily refresh it? Have you ever encountered this issue?

    Thanks a lot,

    Clotilde

  • Hello Matt, dear experts,

     

    One quick question : If I only want to change the OU, is it mandatory to give the ‘newRDN’ in the pass ?

     

    And, what happen if the newRDN = actual one ?

     

    I’m trying (on IDM 8 sp06) to manage department changes for a client.

     

    I set up a ToLDAP action task in a process (second action task is to update the ACCOUNT attribute). My values are :

    – dn : ACCOUNT$rep.NAME$

    – changetype : modrdn

    – deleteoldrdn : 1

    – newsuperior : [calculation of new OU],LDAP_STARTING_POINT

     

    And the process give me the folowing error : “Put Next entry failed storing : [old dn]”

     

    Any ideas of what I’ve done wrong ?

     

    • Hello Matt,

       

      It’s one of your sentence that put me into the wall :

      • Theย newrdnย will tell us what we are changing in this entry. This value must be unique within the directory.

      I understood that to set it, the rdn must not be the same. In my scenario, it is. So I desactivate the attribute.

       

      Now, I reactivate the attribute in the pass, and it works fine. The ACCOUNT is then updated with the new value. Just need to enable the user afterwards and all will be fine.

       

      Thanks a lot !