none
[MS-WSDS] xml specification not complete RRS feed

  • Question

  • Hi,

    Here is a set of remark when implementing [MS-WSDS] (Active Directory Web Service enumeration)

    7. annex B

    xs and xsd tag are mixed making the xsd file incorrect.

    The root cause is that the namespace declared at the beginning of your xsd is xsd while the ws-enumeration use xs.

    Example:

    <xsd:element name="Enumerate">

    <xsd:complexType>

    <xsd:sequence>

    <xsd:element name="EndTo" type="wsa:EndpointReferenceType" minOccurs="0" />

    <xsd:element name="Expires" type="wsen:ExpirationType" minOccurs="0" />

    <xs:element name="Filter" type="wsen:FilterType" minOccurs="0" maxOccurs="1" />

    <xsd:element ref="ad:Selection"

    minOccurs="0" maxOccurs="1" />

    <xsd:element ref="ad:Sorting"

    minOccurs="0" maxOccurs="1" />

    </xsd:sequence>

    </xsd:complexType>

    </xsd:element>

    Some xsd are incorrect. For example, the selectionproperty is not an xsd:string but a xsd:QName (qualified namespace)

    <xsd:element name="SelectionProperty" type="xsd:string" minOccurs="1"

    maxOccurs ="unbounded" />

    Example for your own documentation:

    <ad:SelectionProperty>

    ad:container-hierarchy-parent

    </ad:SelectionProperty>

    <ad:SelectionProperty>

    addata:relativeDistinguishedName

    </ad:SelectionProperty>

    Fault schema when calling the method are not defined in this specification (but can be reversed when retrieving the wsdl from the webservice)

    regards,

    Vincent LE TOUX

    Friday, March 18, 2016 2:42 PM

All replies

  • Hello Vincent :

    Thank you for contacting Microsoft Support. A support engineer will be in touch to assist further.

    Regards


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Friday, March 18, 2016 3:23 PM
  • Hello Vincent,

    Thank you for reporting this issue.  I'll research this for you and reply soon.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, March 18, 2016 3:30 PM
    Moderator
  • Vincent,

    Let me confirm with you that you are not presently blocked; you resolved your issue.  Let me also verify that the only issues you discovered are the ones you highlighted.

    As for 'selectionproperty', in the context of [MS-WSDS], I believe that String is correct, however, take notice of behavior note <8> that points to [MS-ADDM] 2.4 "XPath 1.0-Derived Selection Language"


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, March 22, 2016 9:01 PM
    Moderator
  • Hi,

    Hoppefully dotnet can be reversed quite easily and I studied the implementation you made.

    => I fixed the problems myself

    2 issues were discovered in the documentation

    1) the first one you highlighted.

    For me, the note <8> doesn't specify that. Because the xsd is used by svcutil.exe to build a wcf service, the fact that the xsd schema is incorrect prohibit the use of properties other than distringuishedname (which is in the ad namespace while other are referenced in the addata namespace)

    2) in the section B, the note suggest the replacement of the xsd / wsdl of ws-enumerate.

    However the xsd declaration (following "<!--Extended [WSENUM] Schema-->") define only the namespace xsd (not xs). Every <xs: </xs: should be replaced by <xsd: </xsd:

    My suggestion would be to replace <xsd by <xs everytime because this is this namespace which is defined in the current ws-enumeration xsd.

    regards,

    Vincent

    Tuesday, March 22, 2016 10:48 PM
  • Thank you Vincent for reporting this issue.

    I reported this issue to the owner of [MS-WSDS] by filing a bug against the document.  When the section is updated, I'll post the outcome here.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Wednesday, March 23, 2016 3:03 PM
    Moderator
  • Hi,

    I found something not documented which can quite difficult to find.

    Some attribute like the ntsecuritydescriptor cannot be queried directly by LDAP and a flag need to be passed like LDAP_SERVER_SD_FLAGS_OID (value 1.2.840.113556.1.4.801)

    If the attribute ntsecuritydescriptor is queried but the flag not set, the attribute is not returned.

    I discover that a pull request can have an undocumented parameter to push flags like that.

    Here is an exemple issued from a running capture:

    <wsen:Enumerate>
    <wsen:Filter Dialect="http://schemas.microsoft.com/2008/1/ActiveDirectory/Dialect/LdapQuery">
    <adlq:LdapQuery>
    <adlq:Filter>(&(sAMAccountName=adiant)(objectClass=user)(objectCategory=person))</adlq:Filter>
    <adlq:BaseObject>DC=test,DC=mysmartlogon,DC=com</adlq:BaseObject>
    <adlq:Scope>Subtree</adlq:Scope>
    </adlq:LdapQuery>
    </wsen:Filter>
    <ad:Selection Dialect="http://schemas.microsoft.com/2008/1/ActiveDirectory/Dialect/XPath-Level-1">
    <ad:SelectionProperty>ad:distinguishedName</ad:SelectionProperty>
    <ad:SelectionProperty>addata:name</ad:SelectionProperty>
    <ad:SelectionProperty>addata:objectClass</ad:SelectionProperty>
    <ad:SelectionProperty>addata:objectGUID</ad:SelectionProperty>
    <ad:SelectionProperty>addata:ntsecuritydescriptor</ad:SelectionProperty>
    <ad:SelectionProperty>addata:givenName</ad:SelectionProperty>
    <ad:SelectionProperty>addata:sn</ad:SelectionProperty>
    <ad:SelectionProperty>addata:userPrincipalName</ad:SelectionProperty>
    <ad:SelectionProperty>addata:userAccountControl</ad:SelectionProperty>
    <ad:SelectionProperty>addata:msDS-User-Account-Control-Computed</ad:SelectionProperty>
    <ad:SelectionProperty>addata:sAMAccountName</ad:SelectionProperty>
    <ad:SelectionProperty>addata:objectSid</ad:SelectionProperty>
    </ad:Selection>
    </wsen:Enumerate>

    <wsen:EnumerateResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsen="http://schemas.xmlsoap.org/ws/2004/09/enumeration">
    <wsen:Expires>2016-04-21T17:00:11.7258885Z</wsen:Expires>
    <wsen:EnumerationContext>6ab72884-0202-40ef-848c-d236fcc6243b</wsen:EnumerationContext>
    </wsen:EnumerateResponse>

    <wsen:Pull>
    <wsen:EnumerationContext>6ab72884-0202-40ef-848c-d236fcc6243b</wsen:EnumerationContext>
    <wsen:MaxElements>2</wsen:MaxElements>
    <ad:controls>
    <ad:control type="1.2.840.113556.1.4.801" criticality="true">
    <ad:controlValue xsi:type="xsd:base64Binary">MIQAAAADAgEH</ad:controlValue>
    </ad:control>
    </ad:controls>
    </wsen:Pull>

    => you'll see that there is a section ad:controls which is not referenced anywhere in the documentation.

    (pull is defined at 3.1.4.2 wsen:Pull and there is nothing here nor in the xsd section)

    Thursday, April 21, 2016 5:12 PM
  • Hi vletoux2,

    Thank you for your question. One of our protocols engineers will respond.


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Thursday, April 21, 2016 5:37 PM
    Moderator
  • Hi vletoux2,

    I can review this for you.  To verify: are you presently blocked on this question or are you just reporting this issue?  It appears that you are just reporting the issue so that we can update our specification.  Please confirm that that is true.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, April 21, 2016 7:48 PM
    Moderator
  • Hi Bryan,

    I was blocked until then.

    Here is the xsd I made:

      <xs:element name ="controls">
        <xs:complexType>
          <xs:sequence>
            <xs:element name="control" minOccurs="1"
                         maxOccurs ="unbounded">
              <xs:complexType>
                <xs:sequence>
                  <xs:element name="controlValue" type="xs:string">
                  </xs:element>
                </xs:sequence>
                <xs:attribute name="type" type="xs:string"/>
                <xs:attribute name="criticality" type="xs:boolean"/>
              </xs:complexType>
            </xs:element>
          </xs:sequence>
        </xs:complexType>
      </xs:element>

    Thursday, April 21, 2016 8:26 PM
  • Hi,

    You should add a new comment to the renew method of [MS-WSDS].

    Indeed, I'm trying to retrieve lot of objects (> 500 000) over a VPN connection. It is taking much than 30 minutes and fail with the error "A connection to the directory on which to process the request was unavailable. This is likely a transient condition"

    Ok, I was reaching the timeout of the enumeration operation. So My program now calls renew 5 minutes before the enumeration expiration and extend it to 20 minutes after the expiration. But the program stills end with the same error message at 30 minutes.

    I made an analysis of the code.

    The message indeed expand the expiration time of the enumeration context.

    ActiveDirectoryWebService.Renew(Messsage)
    EnumerationContextCache.UpdateEntryExpiration(Guid enumContext, DateTime newExpiration)

    But the message is caused by the exception

    GenerateEndpointUnavailableFault(NoConnectionAvailableException e)

    This NoConnectionAvailableException is triggered by GetNextPageSearchResults by the fact that the ldap session is not valid anymore (ldap session <> enumeration context).

    This ldap session timeout is defined by the parameter MaxEnumContextExpiration set in Microsoft.ActiveDirectory.WebServices.exe.config and its default value is 30 minutes.

    => a renew operation cannot go over the limit set in the configuration file of ADWS

    regards,

    Vincent

    Sunday, April 24, 2016 8:50 AM
  • Follow-up to forum:

    Both new issues (21 & 24 April 2016) have been filed against [MS-WSDS]


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Tuesday, May 17, 2016 8:32 PM
    Moderator