Re: Creating an AD integrated user on UC14 fails

stephan.steiner · ‎10-17-2023

Here we go again.. first UC14 project, managed to find a problem on the 1st try.

My CUCM Endusers are LDAP Integrated (Active Directory) integrated. My software is written so that if the AD sync has not yet run, it just configures all the necessary EndUser properties (LdapProfile, DirectoryUri, EndUserIdentity), adds the user, and the sync will eventually pick it up and complete the values from Active Directory. Been doing that since 2015 without a hitch.

Now I'm on 14.0.1.13900-155 and I'm trying to create this enduser:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/14.0"><soapenv:Header/><soapenv:Body><ns:addUser sequence="1"><user><firstName>Test44</firstName><lastName>Cisco</lastName><userid>ciscotest44@nxodev.intra</userid><displayName>ciscotest44@nxodev.intra</displayName><password>v4X@%KxX</password><pin>0268</pin><telephoneNumber>+41995557244</telephoneNumber><mailid>cisco.test44@nxodev.intra</mailid><directoryUri>cisco.test44@nxodev.intra</directoryUri><ldapDirectoryName>nxodev</ldapDirectoryName><userIdentity>ciscotest44@nxodev.intra</userIdentity><nameDialing></nameDialing></user></ns:addUser></soapenv:Body></soapenv:Envelope>

The response I'm getting is this:

<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body><soapenv:Fault><faultcode>soapenv:Client</faultcode><faultstring>Users added from corporate directory sync cannot be modified manually.</faultstring><detail><axlError><axlcode>4303</axlcode><axlmessage>Users added from corporate directory sync cannot be modified manually.</axlmessage><request>addUser</request></axlError></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>

But.. the user is still created properly.

May I suggest to revert the validation changes made for UC14 in this instance? things were fine before. Now now only are they not fine, the error is incorrect - I'm adding a user, the error says something about modifying a user.

Elliot Dierksen · ‎10-20-2023

I haven't worked with V14 yet, but my gut is that you would need to wait until the user exists from the LDAP sync before setting properties. Otherwise it seems like it would create a local user.

dstaudt · ‎10-20-2023

Testing with 14.0.1.10000-20, I'm not sure I can reproduce the problem, using a simplified <addUser>:
Prior to scenario: testldapuser4 does not exist in CUCM or AD

1. AXL <addUser>:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns="http://www.cisco.com/AXL/API/14.0">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:addUser sequence="1">
         <user>
            <firstName>Test</firstName>
            <lastName>LDAPUser4</lastName>
            <userid>testldapuser4</userid>
            <password>password</password>
            <pin>123456</pin>
            <ldapDirectoryName>ActiveDirectory</ldapDirectoryName>
            <userIdentity>testldapuser4</userIdentity>
         </user>
      </ns:addUser>
   </soapenv:Body>
</soapenv:Envelope>

* AXL returns a UUID - no error
* CUCM shows the user is Active LDAP User

2. Force an AD sync via CUCM admin

* CUCM shows user is Inactive LDAP User

3. Add user into AD

4. Force resync

* CUCM shows user is Active LDAP User

Trying similar scenarios:
* AD user created, no sync, AXL <addUser>: same as above
* AD user created, force sync, AXL <addUser): AXL error "Could not insert new row - duplicate value in a UNIQUE INDEX column" as perhaps expected

Can you spot a key difference in how I'm testing, or maybe provide additional repro steps? We are using different CUCM versions - if the issue is seen only on your version, then very likely TAC is going to need to be involved for logs/escalation.

stephan.steiner · ‎10-23-2023

@dstaudt : in your case, it is working as expected. Your steps #1-4 that's exactly how I know it to work on older releases.

The difference between my attempt and yours is that I'm also supplying mailId, telephoneNumber, directoryUri and nameDialing (not sure where nameDialing comes from.. have to investigate). Have you tried what happens if you fill out these fields as well?

In my scenario, the user is present on AD but the AD sync has not yet run. so when I add it as endUser, it shows up as activate LDAP integrated and cannot be modified (which is okay). I'm just giving it all the initial values since my app also has access to AD and thus has the values from there (my app can handle both cases... and is aware that it cannot update certain properties of an AD integrated user once created).

@edit: just tried adding another user with slightly less data - and that works:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:ns="http://www.cisco.com/AXL/API/14.0">
	<soapenv:Header/>
	<soapenv:Body>
		<ns:addUser sequence="1">
			<user>
				<firstName>Test47</firstName>
				<lastName>Cisco</lastName>
				<userid>ciscotest47@nxodev.intra</userid>
				<department>Development &amp; Testing</department>
				<directoryUri>cisco.test47@nxodev.intra</directoryUri>
				<ldapDirectoryName>nxodev</ldapDirectoryName>
				<userIdentity>ciscotest47@nxodev.intra</userIdentity>
			</user>
		</ns:addUser>
	</soapenv:Body>
</soapenv:Envelope>

So it seems to have something to do with the kind of properties I'm filling.

I then started filling value after value. added mailId: still OK. added telephoneNumber: still OK, added displayName: still ok. added nameDialing: still OK, added Password and PIN => error occurrs.Removed PIN again => error still happens. So it seems that when you send the password, it does something. also removed displayName and nameDialing => still NOK. removed department => still NOK. removed telephoneNumber and mailId => still NOK. removed Password => OK. So, drilling down for every field, it seems sending the password does something in my case.

Starting with your example, I can leave out pin and firstName and it still fails. Leave out password and I can send a lot more properties filled out. So it seems on my build, sending the password with an AD Integrated user causes a problem (returns an error but still creates the user). So as a workaround, I'm simply not filling out the password (doesn't make much sense anyway for an AD integrated user)

dstaudt · ‎10-23-2023

Interesting...and this did work prior to 14?

My guess would be that AXL is creating the user as an Active LDAP user, and then in a separate (internal) step attempts to update the password - this (assumedly) fails as there is a new check (theoretically) to see if the update is being attempting on an existing LDAP user (it existed for some milliseconds). That's a bunch of suppositions, but in the end the observed behaviour of returning an inapplicable error but successfully completing the operation (is the password you sent applied?) is a clear defect.
Agree supplying password/pin for an LDAP user is a bit odd - which probably explains why this issue wasn't covered/discovered during testing. I'm assuming they are using LDAP authentication, which should...work as expected(?) prior to the sync occurring? If not, what are the implications of having the account created/existing with empty password/pin for some hours before sync occurs..?