Read AD Manager Attribute in DN format during AD Initial Load

[Former Member]

I have IdM 7.2 reading in all the AD users/attribute values at initial load and I want to read in the manager.  The manager here is stored in a attribute called "manager" but the value in AD looks like this:

CN=managerUserName, OU=Users,OU=ITSupport,OU=InfoTechServices,DC=domain,DC=com

What would be the recommended way to get the managerUserName out of the DN format so I can use it to assign to each user.

Any suggestions would be appreciated.

[Former Member · Accepted solution]

I worked it out.  Here's the code:

// Main function: z_setADManager

// This function reads in the manager attribute value from AD (which is in DN format) and strips out all but CN=<Manager Samaccountname>, it then strips the first three characters of THAT value and sends just the managers samaccountname back as the result.

function z_setADManager(Par){

//Example calling DSE internal function

//uStop("Terminated by user");

var mgr = "";

var result = "";

var arr = Par.split(',');

if (Par != null && Par != ""){

     mgr= arr[0].slice(3);

     result = mgr;

     }

     return result;

}

Please provide feedback.

Thanks,

[Former Member · Accepted solution]

Yeah - you have to be careful splitting on ',' - '\,' is an escaped comma in the DN.  That's why I tend to use a regex.

You can split on ',ou=' which will give you the components before the OU.  That should do it for you...

Peter

[terovirta · Accepted solution]

If the username is the same as the MSKEYVALUE then you could return "<userName>", which the toIdStore pass will interpret to MSKEY when it's writing the value to IdStore. No lookups needed in that case.

All of it depends on your data model and what is stored per user to IdStore.

regards, Tero

[Steffi_Warnecke · Accepted solution]

Hello Leonard,

my script looks like this:

//  Job:103621/'72 - ADS - 2 Update directReports mit Script (TEST)'
// Main function: isv_split_CN_DISPLAYNAME

function isv_split_CN_DISPLAYNAME(Par) {

// -----------------------------------------------------
// Steffi Warnecke 17.12.2013
//
// Script zum Splitten des CN zum Nutzen des Anzeigenamens
// -----------------------------------------------------

var arraygesamt = Par.split("|");

//zweifacher Split des Arrays, um an den Anzeigenamen zu kommen
     var gesamt = arraygesamt[0].split("CN=");
     var zwischenergebnis = gesamt[1];
     var result = zwischenergebnis.split(",OU");

     //uErrMsg(1, "isv_split_CN_DISPLAYNAME result: " + result[0]);

return result[0];
}

@Tero: It works great, too. BUT I want to use this for a multivalue-field, so I need to get this loop-thing going (which is a bit stubborn at the moment ^^).

But for Leonard this would be enough, since normally there is only one manager per employee. So no looping required.

I have tried to melt it down:

// Main function: isv_split_CN_DISPLAYNAME

function isv_split_CN_DISPLAYNAME(Par) {

var firstsplit = Par.split("CN=");
var result =  firstsplit[1].split(",OU");

 //uErrMsg(1, "isv_split_CN_DISPLAYNAME result: " + result[0]);

return result[0];
}

Regards,

Steffi.

[Former Member · Accepted solution]

Splitting out on ',OU=' didn't seem to get the split for the DC= at the end of the DN-styled attribute value.  Instead of just supplying the managers samaccountname, it supplied the following:

managerUserName, OU=Users

My initial code worked for me because it only provides the managerUserName.  This conversion from DN format to just managerUserName is done during initial load, so the table that has the AD information in it actually has the managerUserName in the manager attribute just like it has a samaccountname value in the sAMAccountName attribute.

Thanks,

[Former Member · Accepted solution]

Not sure I am following you here.  The record the conversion is being performed on is the user record so therefore the MSKEYVALUE of that record would be the user record's samaccountname.  In that users AD record, there is a manager attribute that is in DN format.  During initial load, this conversion converts the DN formated attribute value to a simple single value of managerUserName.

Doing this will require two steps in my mind.  First, during the to idStore pass, write all the AD users and their values into the id store.  Once that completes, I will then modify each record to pass the actual managerUserName (which now has its own unique record already in IdM).  If I passed the value at the time I was writing the initial users, if the managers record had not been created already, it could generate an error and an incomplete record.

[terovirta · Accepted solution]

You have a whitespace between comma and string "OU". Split with comma only.

[terovirta · Accepted solution]

You're correct about the sequence of passes in your job.

What I meant is that when you're using the script in "to Identity Store" pass you must return the MSKEY of the manager to the MX_MANAGER-attribute.

There is a built-in macro in IdM that returns a MSKEY when you refer the mskeyvalue like <MSKEYVALUE>, if you return the less/greater-than symbols around the variable result your script returns MSKEY.

Otherwise you would have to query for which MSKEY has this MSKEYVALUE/samAccountName.

Simplified example below without the script call in place:

regards, Tero

[Former Member · Accepted solution]

Tero,

When I try your method and add the following value to the MX_MANAGER:

{R}<%manager%>

I get this error:

putNextEntry failed storing USERSAMACCOUNTNAME

Exception from Add operation:com.sap.idm.ic.ToPassException:
ToIDStore.addEntry failed storing entry 'USERSAMACCOUNTNAME'. IDStore returned error message: " Referenced value does not exist:Attribute: MX_MANAGER" when storing
attribute 'MX_MANAGER=<MANAGERSAMACCOUNTNAME>'

Exception from Modify operation:com.sap.idm.ic.ToPassException:
ToIDStore.modEntry failed updating entry 'USERSAMACCOUNTNAME'. IDStore returned error message: "Entry does not exist" when fetching entry

When I try your method and add the following value to the MX_MANAGER:

{R}%manager%

I get this error:

putNextEntry failed storing USERSAMACCOUNTNAME

Exception from Add operation:com.sap.idm.ic.ToPassException:
ToIDStore.addEntry failed storing entry 'USERSAMACCOUNTNAME'. IDStore returned error message: " Entry reference value is not numeric:Attribute: MX_MANAGER" when
storing attribute 'MX_MANAGER=MANAGERSAMACCOUNTNAME'

Exception from Modify operation:com.sap.idm.ic.ToPassException:
ToIDStore.modEntry failed updating entry 'USERSAMACCOUNTNAME'. IDStore returned error message: "Entry does not exist" when fetching entry

[Steffi_Warnecke · Accepted solution]

Hello Leonard,

did you try this in the inital job or in a new one after the inital load is completed? The errors look like you tried it in the initial load job, where your concern from the other post comes in play (that the manager is looked up in the IdM store before it's even created as an entry via the inital load).

If you tried this in a new job after the initial load job is finished, this would be confusing. ^^

Regards,

Steffi.

[terovirta · Accepted solution]

When I try your method and add the following value to the MX_MANAGER:

{R}%manager%

I get this error:

putNextEntry failed storing USERSAMACCOUNTNAME

Exception from Add operation:com.sap.idm.ic.ToPassException: 
ToIDStore.addEntry failed storing entry 'USERSAMACCOUNTNAME'. IDStore returned error message: " Entry reference value is not numeric:Attribute: MX_MANAGER" when 
storing attribute 'MX_MANAGER=MANAGERSAMACCOUNTNAME'

This means that you're assigning MSKEYVALUE (string) instead of MSKEY (numeric), when MSKEY is expected to establish the link between two MX_PERSONs. The MSKEY must naturally exist too.

In order to get the MSKEY out of MSKEYVALUE in the "to Id Store Pass" you must have the less/greater than brackets around the MSKEYVALUE.

[terovirta · Accepted solution]

Leonard Jennings wrote:

Tero,

When I try your method and add the following value to the MX_MANAGER:

{R}<%manager%>

I get this error:

putNextEntry failed storing USERSAMACCOUNTNAME

Exception from Add operation:com.sap.idm.ic.ToPassException: 
ToIDStore.addEntry failed storing entry 'USERSAMACCOUNTNAME'. IDStore returned error message: " Referenced value does not exist:Attribute: MX_MANAGER" when storing 
attribute 'MX_MANAGER=<MANAGERSAMACCOUNTNAME>'

Exception from Modify operation:com.sap.idm.ic.ToPassException: 
ToIDStore.modEntry failed updating entry 'USERSAMACCOUNTNAME'. IDStore returned error message: "Entry does not exist" when fetching entry

This means that the referred MSKEYVALUE (=user entry) does not exist. If you're assigning the manager in next pass after the you've created both the user and manager, this should not happen, unless the manager wasn't loaded from AD or the AD contains incorrect manager reference.

[Former Member · Accepted solution]

You are correct, I was just testing his method and should have created two passes instead of one.

[Former Member]

The last step is to create a pass that after I read in AD and all the existing test ABAP systems, pushes out the current records out to all the ABAP clients so they are updated with the AD information.

[Steffi_Warnecke]

Hmm... reading this I think I make my life harder than it needs to be, since I'm getting the managerUserName-part (to stay with this example) of the DN currently by using a split-script, that cuts away anything left and right from that part and returns the rest.

Maybe I should just use one of the lookup-scripts. oO

Thanks for the food for thought, guys!

Regards,

Steffi.

[Former Member]

Can you post your split script?  That would be most helpful to review.

[Steffi_Warnecke]

There is a splitby-function, that I use for that in my script. I can post it tomorrow, when I have access to my system (or you could check, if you find it in the IDM-help). Right now I couldn't write it down by memory. ^^

But it's really just a few lines of code in the script.

Regards,

Steffi.

[Former Member]

A regex works really well for DNs as they're in a defined format.  It makes it pretty easy to pull things out of a DN.

Peter

[terovirta]

Steffi Warnecke wrote:

Hmm... reading this I think I make my life harder than it needs to be, since I'm getting the managerUserName-part (to stay with this example) of the DN currently by using a split-script, that cuts away anything left and right from that part and returns the rest. 

Not necessarily, a look-up always means a DB query. If you have a bulletproof way of detecting the value in your script that's better option as the job will be faster to execute.

regards, Tero

[terovirta]

There are ways to achieve this and all depend on your AD vs IdM-attribute mapping. You must assign the MSKEY of the manager to the MX_MANAGER-attribute as the MX_MANAGER is reference attribute between two MX_PERSON entries

Do you store the DN of the AD user to any of the attributes in IdM? If you do you can query which user (which MSKEY) has the that particular DN in that attribute in script. Note that you can do this lookup after all the users are loaded/created to IdM.

If the DN is not stored in IdM and you have for example mapped the samAccountName to the ACCOUNT-attribute of the user you can still do the matching in the inbound interface from AD and do the query within the temp table you load all the AD entries. In this case you could have an additional "from Database" pass to load the samAccountName and manager's DN to another table with 3rd column that would have the manager's samAccountName. You would do the matching by which samAccountName has the manager's DN. When writing to IdM you then would query for the manager's MSKEY based on the manager's samAccountName in that temp table.

[former_member2987]

Also if you are bringing the DN into IDM as well you can search on the DN and return the MSKEY, as Tero says IDM will translate the MSKEY into the displayname via lookup.

[Former Member]

Tero,

Yes, I am bringing in the dn from AD and assigning it to a custom IdM attribute Z_DN