getLdapAuthentication is broken in 11.5

[Jonathan Els]

getLdapAuthentication is not working in 11.5.

The schema is really simple, and should work like getLDAPSystem:

<xsd:complexType name="GetLdapAuthenticationReq"/>
<xsd:element name="getLdapAuthentication" type="axlapi:GetLdapAuthenticationReq"/>

However, when you fire off this request, you're greeted with a delightful error message:

Request:

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

   <soapenv:Header/>

   <soapenv:Body>

      <ns:getLdapAuthentication/>

   </soapenv:Body>

</soapenv:Envelope>

Response:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

   <soapenv:Body>

      <soapenv:Fault>

         <faultcode>soapenv:Server</faultcode>

         <faultstring>Item not valid: The specified Ldap Authentication was not found</faultstring>

         <detail>

            <axlError>

               <axlcode>5007</axlcode>

               <axlmessage>Item not valid: The specified Ldap Authentication was not found</axlmessage>

               <request>getLdapAuthentication</request>

            </axlError>

         </detail>

      </soapenv:Fault>

   </soapenv:Body>

</soapenv:Envelope>

Clearly this is a defect.  It's reproducible even with SoapUI.

This is pure speculation based on no testing...  but I'm going to hazard a guess that this is caused by the new LdapSearch options.  For some reason, despite appearing as a singleton in the UI, it supports a list method, as if there is an intention to (at least at some stage) support multiple LDAPSearch options per cluster.

[npetrele]

What version are you using?  This is working fine for me on CUCM 11.5.1.10000-6.  Are you sure you have LDAP Authentication defined via your CUCM web UI?

[Jonathan Els]

Hmmm, let me check...  If it's working for you, might have derped this one.

[Jonathan Els]

Well, here is the differing behaviour, which to me, is a bug.  It's debatable.

For LdapSystem, it returns empty values, as it is expected to:

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
  <soap-env:Body>
    <ns0:getLdapSystem xmlns:ns0="http://www.cisco.com/AXL/API/11.5"/>
  </soap-env:Body>
</soap-env:Envelope>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <ns:getLdapSystemResponse xmlns:ns="http://www.cisco.com/AXL/API/11.5">
      <return>
        <ldapSystem>
          <syncEnabled>false</syncEnabled>
          <ldapServer>Microsoft Active Directory</ldapServer>
          <userIdAttribute>None</userIdAttribute>
        </ldapSystem>
      </return>
    </ns:getLdapSystemResponse>
  </soapenv:Body>
</soapenv:Envelope>

For LdapAuthentication, it just breaks:

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
  <soap-env:Body>
    <ns0:getLdapAuthentication xmlns:ns0="http://www.cisco.com/AXL/API/11.5"/>
  </soap-env:Body>
</soap-env:Envelope>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <soapenv:Fault>
      <faultcode>soapenv:Server</faultcode>
      <faultstring>Item not valid: The specified Ldap Authentication was not found</faultstring>
      <detail>
        <axlError>
          <axlcode>5007</axlcode>
          <axlmessage>Item not valid: The specified Ldap Authentication was not found</axlmessage>
          <request>getLdapAuthentication</request>
        </axlError>
      </detail>
    </soapenv:Fault>
  </soapenv:Body>
</soapenv:Envelope>

They are both singleton configs.

[npetrele]

This is how it works for me (you see I used 11.0, but 11.5 works, too):

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

   <soapenv:Header/>

   <soapenv:Body>

      <ns:getLdapAuthentication/>

   </soapenv:Body>

</soapenv:Envelope>

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

   <soapenv:Body>

      <ns:getLdapAuthenticationResponse xmlns:ns="http://www.cisco.com/AXL/API/11.0">

         <return>

            <ldapAuthentication uuid="{A8D94FF0-4627-EECC-0D8D-E2EE69123B32}">

               <authenticateEndUsers>true</authenticateEndUsers>

               <distinguishedName>my info</distinguishedName>

               <ldapPassword/>

               <userSearchBase>my search base</userSearchBase>

               <servers>

                  <server>

                     <hostName>my ldap ip</hostName>

                     <ldapPortNumber>389</ldapPortNumber>

                     <sslEnabled>false</sslEnabled>

                  </server>

               </servers>

            </ldapAuthentication>

         </return>

      </ns:getLdapAuthenticationResponse>

   </soapenv:Body>

</soapenv:Envelope>

Again, I have to ask, are you sure you defined LDAP Authenticatioin using the web GUI?  Also, I don't know why you're defining the namespace in the command, here:

<ns0:getLdapAuthentication xmlns:ns0="http://www.cisco.com/AXL/API/11.5"/>

[Jonathan Els]

That's being added by the soap library I'm using.  It's not resulting in an error in any other calls

Not sure why you're going on about defining in the GUI.  I shouldn't have to define it in the UI for the get to work on a singleton call.  It should return the element, or return nothing.  It should not raise an exception.  That's why I demonstrated the inconsistency between the two Reqs.

It works in the positive case.  It's the negative case where the bug is.

[dstaudt]

In general, a <getXXX> request should be intended to return a specific item, and if that item is not found, an error is returned:

* <getLdapSystem> will always return content, as the LDAP system settings are always present, even when disabled

* <getLdapSearch> returns an error similar to what you're seeing for <getLdapAuthentication> if no LDAP search sources have ever been configured.  Note, if an LDAP search source has been configured, but is disabled, then data is returned

* <getLdapAuthentication> returns the error described if no LDAP authentication source has ever been configured (similar to <getLdapSearch>).  If an LDAP authentication has ever been configured but is disabled, it is able to return data (which indicates the disabled state)

As there can only be one LDAP authentication target, having a <listLdapAuthentication> request would be superfluous.- there are <listLdapXXX> requests only for searches and directories, as those are the only entries with possible multiple items (note there is no <listLdapSystem> as that configuration item is always present.)

While there are a couple of things that make this overall situation a bit confusing, I'm not sure returning an empty object would be a better solution for <getLdapAuthentication>.  For example, <getPhone> for a phone that doesn't exist (or any other <getXXX> request) returns an error, vs. an empty phone object.

Is there a scenario or ambiguity that causes your application a problem with the current behaviour that can't be resolved by treating the currently returned error message as meaning 'no LDAP authentication target has been configured'..?

[Jonathan Els]

I can understand this reasoning for phones.  The use case for phones is different - the xsd explicitly requires a uuid or a name.

But this gets really confusing for singletons.  Here, I can send none, it's not validated in the schema but returns errors in some cases, and in others not.  So based on what you're saying, I now need to consider the scenario where ldapAuth was never configured, as only then will a get an error.  But you're also saying that it will return something (I haven't checked this) if there was a prior config, but it's disabled?  :/

If that's the expected behaviour distinguishing the two cases, then so be it.  Ultimately I want a reliable way to determine the UUID (if available) in all cases.  At least I understand it now... thanks!

[dstaudt]

Yep...in the case where a LDAP authentication configuration was ever done, but it is currently disabled, I get the below.  There doesn't appear to be a way (in the UI at least) to remove the config once made - only disable it:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
      <ns:getLdapAuthenticationResponse xmlns:ns="http://www.cisco.com/AXL/API/11.5">
        <return>
            <ldapAuthentication uuid="{A8D94FF0-4627-EECC-0D8D-E2EE69123B32}">
              <authenticateEndUsers>false</authenticateEndUsers>
              <distinguishedName>cn=administrator,cn=users,dc=ds-adfs,dc=sso,dc=com</distinguishedName>
              <ldapPassword/>
              <userSearchBase>cn=users,dc=ds-adfs,dc=sso,dc=com</userSearchBase>
              <servers>
                  <server>
                    <hostName>10.194.104.58</hostName>
                    <ldapPortNumber>389</ldapPortNumber>
                    <sslEnabled>false</sslEnabled>
                  </server>
              </servers>
            </ldapAuthentication>
        </return>
      </ns:getLdapAuthenticationResponse>
  </soapenv:Body>
</soapenv:Envelope>