addUser - ldap integrated user add is successful but returns error if password is set

[stephan.steiner]

Hi

I found an interesting one today. We've established that you can create an LDAP integrated user even if the LDAP sync hasn't run yet. All it takes is filling the UserIdentity and LdapDirectoryName fields then calling addUser.

So today I created such a user as follows:

<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 sequence="1"> <user><firstName>ata</firstName><lastName>test</lastName><userid>device_ata</userid><password>bbraun01</password><telephoneNumber>415004</telephoneNumber><mailid>device_ata@nxodev.intra</mailid><mobileNumber></mobileNumber><ldapDirectoryName>LUPS_numberlookup</ldapDirectoryName><userIdentity>device_ata@nxodev.intra</userIdentity></user></ns:addUser></soapenv:Body></soapenv:Envelope>

The response I get 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:Server</faultcode><faultstring>LDAP authentication enabled. UpdateCredential failure</faultstring><detail><axlError><axlcode>18</axlcode><axlmessage>LDAP authentication enabled. UpdateCredential failure</axlmessage><request>addUser</request></axlError></detail></soapenv:Fault></soapenv:Body></soapenv:Envelope>

That's fine, an error that tells you what is going wrong. However, it appears the user is still created. And that causes a problem... I might accept that there's a partial success for an add (never encountered it but okay.. not everything in AXL is fully documented as we know) - however, if partial success is something that exists, we still need to get the object's uuid back as you get for any other add. And that seems to conflict with the definition of an add response (which either gets you a uuid of the object created or an axl error). So I think in this case, input validation isn't being done properly and the user should never be created in the first place.

This is on a CUCM 10.5.2.11900-3.

If I leave out the password field, things are fine so that's my "workaround" - but I think this case needs more input validation.

[npetrele]

If you're using ldap for login authentication, then I would assume you don't want to include a password.  The password field is for storing a local user password. 

[stephan.steiner]

Of course the field shouldn't be used.. the point is, you do something that shouldn't be done, you get an error as expected, but things are still done so something is wrong. Either do it all the way or don't do it at all.

[npetrele]

Yes, I agree that it either shouldn't create a user, or create a user with an error message that says the password was ignored. I'm filing a request for this to be changed.

My point, however, was that if you fix your code to not use a password for LDAP users, you won't need to worry about how AXL responds.

[stephan.steiner]

I already had the fix before I posted - I merely wanted to mention that something is wrong so it gets targeted for a fix in the future