Skip to Content

Get objectSID from AD (LDAP)

Fellow experts,
I'm trying to create a From LDAP pass, or maybe even use the uGetUserSid internal function, to get the objectSID attribute from a given entry in my target repository. I'm not having any success with uGetUserSid but I was able to bring something back on the From LDAP pass method. Problem is, when I pull up the results that show up in the SQL temp table, it's all mumbo-jumbo. The attribute is stored in LDAP as a binary attribute so what comes into IDM isn't the pretty looking S-1-5-21-xxxxxx-xxxxx format you see when you look at the attribute in an LDAP browser or ADUC.

I looked through my environment to see if there was an SAP supplied global script that would convert the binary format to text but alas, nothing. Any suggestions?

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    Sep 25, 2017 at 05:44 PM

    To get the SID in plain text on the IDM side, you first need a From LDAP pass. When you bring in the objectSid from AD, you need to preface the source column with an exclamation point as seen here:

    Next, you see the script I have in this pass. Here's the text of that script:

    // Main function: z_custom_ad_convertObjectSID
    function z_custom_ad_convertObjectSID(Par){
    	// Input : {HEX}010500000000000515000000561400C443528306533A02202F970000
    	// Output : S-1-5-21-3288339542-109269571-537016915-38703
    	// Based on the algorithm of the link
    	// For easy tests on Object SiD conversion you can download this tool
    	var OutString = uHexToByte(Par);
    	var bSid=OutString;
        var binarySid = bSid;
    	if (bSid.length < 8) return "";
    	var revision = binarySid[0];
        var nrSubAuth = binarySid[1];
        var identifierAuth = binarySid[2] + binarySid[3] + binarySid[4] + binarySid[5] + binarySid[6] + binarySid[7];
        var returnString = "S-";
        returnString = returnString + revision + "-";
        returnString = returnString + identifierAuth;
        for (var subAuthCount = 0; subAuthCount < nrSubAuth; subAuthCount++) {
            var longInt = (getUnsignedByte(binarySid,7+(subAuthCount*4)+4) << 24) |(getUnsignedByte(binarySid,7+(subAuthCount*4)+3) << 16) |(getUnsignedByte(binarySid,7+(subAuthCount*4)+2) << 8)|(getUnsignedByte(binarySid,7+(subAuthCount*4)+1));
            if (longInt < 0) longInt += 4294967296;
                returnString = returnString + "-" + longInt
            return returnString;
    function getUnsignedByte(inputbSid,position) {
        var toReturn = inputbSid[position];
        if (toReturn < 0) {
                return (toReturn+256);
        } else {
            return toReturn;

    Now in your temp table, you'll have an SID that looks like it looks when you pull up the attribute in an LDAP browser like Softerra or ADUC. Any questions? :)

    Add comment
    10|10000 characters needed characters exceeded

  • Sep 21, 2017 at 12:25 PM


    I did a little googling and saw that the value is encoded. You might want to look at the functions for converting base64 strings and see if it is more direct. Otherwise I found the following links which may or may not be helpful.

    Mr. Google can be your friend!

    Good luck!




    Add comment
    10|10000 characters needed characters exceeded

  • Sep 21, 2017 at 09:04 PM

    With all respect and thanks to Matt Pollicove, fellow Inventy team members were able to get a script to me that was developed for a different client that does the job. I need to make sure that it's not something proprietary that I'll get in trouble for posting but if I'm given the green light, I'll post the script.

    Add comment
    10|10000 characters needed characters exceeded

    • The use case is simply that they want to use the SID as the account attribute in IDM. It's a unique, searchable attribute in AD and no matter the account's location in the OU structure, you can find the account via SID. Most companies I've worked with us the distinguishedName attribute and that's 90% OK to use but if an AD admin decided to move the account to another OU, that DN changes. SID will never change so IDM can never be detached from that account. That's the thinking anyway.