Skip to Content

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  😀
To report this post you need to login first.

18 Comments

You must be Logged on to comment or reply to a post.

  1. Ridouan Taibi

    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

    (0) 
    1. Matt Pollicove Post author

      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

      (0) 
    2. Ivan Petrov

      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

      (0) 
  2. Ian Daniel

    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

    (0) 
    1. Matt Pollicove Post author

      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!

      (0) 
      1. Per Krabsetsve

        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…

        (0) 
  3. Steffi Warnecke

    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.

    (0) 
  4. Matt Pollicove Post author

    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.

    (0) 
    1. Ivan Petrov

      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

      (0) 
      1. Matt Pollicove Post author

        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

        (0) 
        1. Ivan Petrov

          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

          (0) 
          1. Matt Pollicove Post author

            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

            (0) 
            1. Ivan Petrov

              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

              (0) 
  5. Jannis Rondorf

    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

    (0) 

Leave a Reply