Let's improve LDAP Sync - a feature request

[stephan.steiner]

I'm currently designing an automated provisioning solution for a customer who wants to use AD integration.

Unfortunately, that's quite a pain. At the point where a user decides "let's open user xyz in the telephony system", the LDAP sync may not have run. Consequently, you could create devices, but you cannot make the association to the cucm enduser which is a must have for licensing purposes (and even more importantly when using jabber with telephony integration (so you can see the telephony state)).

I therefore propose an additional doSingleUserLdapSync

The command would take the the sama name/uuid combo to specify the ldap directory, and would take another parameter "userId" of type string. the ldap comonent would then look for just this samAccountName (on AD) and sync this user. Given that it is doing only one user (or none if the userid is not found), the command could run until the sync is done.

This should also be made available for CUPI (well.. the entire ldap thingie is missing there making directory integration and automated provisioning a major expectation mismatch (customer expects full automation at great speed, but we can only provide klunky workarounds)).

[dstaudt]

Just a quick test, but AXL did allow me to specify the LDAP source and userID for a new end user, and it shows up as 'Active LDAP Synchronized User' in the UCM end user web UI...

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/10.5">

  <soapenv:Header/>

  <soapenv:Body>

      <ns:addUser>

        <user>

            <lastName>test2</lastName>

            <userid>test2</userid>

          <ldapDirectoryName>ADFS</ldapDirectoryName>

            <userIdentity>test2@ds-adfs.sso.com</userIdentity>

        </user>

      </ns:addUser>

  </soapenv:Body>

</soapenv:Envelope>

I'm by no means sure that this is all that's required to do a roll your own one-user 'sync', but it might be a place to start...chances are good that you can update anything in the DB that the LDAP sync process does.

[stephan.steiner]

David

That sounds interesting. I'm on my way out the door but I'll definitely try this tomorrow.

[stephan.steiner]

I managed to successfully test it. Is that trick documented somewhere - especially which preconditions need to be fulfilled for it to work (I'm guessing the fields you specified are necessary but I wonder about lastName given that this is present in AD... and don't we have a data redundancy with userIdentity and userId, given that the former includes the latter and userId mapping is defined in the ldap directory)?

Also, are there any rules as to which properties you can specify upon creation? I noted you put lastName - and then my user did have the last name, but it didn't pick up the first name from my ldap directory.

@edit: I noted that my proposal still has merit. The addUser, even though it makes the ldap association, doesn't perform everything an ldap sync performs. Various fields remain empty (e.g. firstName), I didn't see any access control groups, and it seems my provided userId can get changed... I used uppper and lower case in my addUser whereas once I ran the full sync, it corrected the cucm user to match upper/lowercase of the AD user.

[dstaudt]

My recollection from the gui is that userid and lastname are the minimum required fields to add a user.  My guess would be that the LDAP sync process identifies a new user in LDAP, creates a new user by copying the designated LDAP primarykey to the userid field, and the LDAP last name field to lastname.  You can look at the UCM LDAP config screens to see how other fields may be mapped.

I would guess that the useridentity is the fully-qualified domain name from LDAP, and that the domain is truncated off to make the userid.

Assume that if the user has been added by you (without a first name) that the next time the LDAP sync process runs, it thinks the user is pre-existing (previously synced) and therefore skips it - not copying over any other fields, like first name.  Probably if your app is going to be doing its own mini LDAP sync process, it should replicate what the UCM LDAP sync process is doing as closely as possible - e.g. honoring the LDAP field import/mapping config.

[stephan.steiner]

I have a followup on this. Given that the userIdentity field in AXL maps to discoveryuseridentity in the database, and looking at the values of discoveryuseridentity in both my lab and productive system, it appears that in my lab the value is userid@domain, whereas in our productive system it is the user's email address. In the corresponding ldap profile, in my lab, directory uri is set to the msrctsip address (lync sip uri, but the users I'm synching have no lync), and it's set to none in our productive system. So, given that it seems I need to specify discoveryuseridentity in the <userIdentity> field for <addUser>, I'm wondering how I can figure out which AD field I need to copy there (for creating users where the ldap sync hasn't yet run). Instead of hardcoding this in some way, I'd rather do it properly so it will work in all environments.

@edit: I just had a look in our productive AD... it could well be that the field that goes into <userIdentity> and in discoveryuseridentity is the userPrincipalName from AD. Is that guess correct?