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:
- 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.
- 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:
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.
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.
Then 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:
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:
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 :grin:
- SAP Managed Tags:
29 Comments
