none
NTLM over LDAP against Active Directory RRS feed

  • Question

  • My Active Directory shows the following supported SASL mechs.

    supportedSASLMechanisms (4): GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5; 

    How can NTLM be enabled for support? 

    When sending:

    bindRequest(1) "NTLMSSP_AUTH" , NTLMSSP_AUTH, User: testuser

    or

    bindRequest(1) "NTLMSSP_AUTH" , NTLMSSP_AUTH, User: TESTDOMAIN\testuser1

    I either get:

    bindResponse(1) invalidCredentials (80090308: LdapErr: DSID-0C090671, comment: AcceptSecurityContext error, data 57, v23f0)

    OR 

    no response at all.

    The cred sent in the request is the NTLM type 3 message from the client.

    Does NTLM  need to be enabled in supportedSASLMechanisms ? If so, how?

    How can see LDAP related debug/events? 

    Wednesday, September 4, 2019 8:05 PM

All replies

  • GSSAPI; GSS-SPNEGO include NTLM and Kerberos. 
    Thursday, September 5, 2019 2:37 AM
  • yes, but I do not want want to complicate the client with those. 

    https://ldapwiki.com/wiki/NTLM%20SSP says that "NTLM SSP is a Security Support Provider as used in the Microsoft Active Directory Security Support Provider Interface"

    In openldap for example, the list is configurable: via "mech_list"

    and with a query:

    ldapsearch -x -h testing.com -s "base" -b "" supportedSASLMechanisms 

    can see:

    dn:
    supportedSASLMechanisms: DIGEST-MD5
    supportedSASLMechanisms: EXTERNAL
    supportedSASLMechanisms: CRAM-MD5
    supportedSASLMechanisms: NTLM
    supportedSASLMechanisms: PLAIN
    supportedSASLMechanisms: LOGIN

    Also, ldapsearch supports the ntlm mechanism.

    ldapsearch -Y ntlm

    So:

    Can supportedSASLMechanisms be updated on Active Directory to support ntlm?

    Given that the Active Directory sends a response like: invalidCredentials , what do the error codes mean? 

    bindResponse(1) invalidCredentials (80090308: LdapErr: DSID-0C090671, comment: AcceptSecurityContext error, data 57, v23f0)

    What is "data 57". I cannot find it documented anywhere?

    Is there any further debug/event logging I can enable on Active Directory side? 

    Thursday, September 5, 2019 8:26 AM
  • Hi,

    bindResponse(1) invalidCredentials (80090308: LdapErr: DSID-0C090671, comment: AcceptSecurityContext error, data 57, v23f0)

    According to my knowledge, I will suggest you check the CODE or try using UPN for authentication to see if it helps.

    Similar discussion for your reference:

    https://stackoverflow.com/questions/19785611/ldapexception-when-trying-to-connect-using-userprincipalname

    https://github.com/grafana/grafana/issues/3431

    https://community.arubanetworks.com/t5/Security/LDAP-For-Operators-login/td-p/70040

    In addition, we can enable NTLM audit for further troubleshooting.

    https://blogs.technet.microsoft.com/yuridiogenes/2008/03/09/when-security-in-mind-doesnt-match-with-the-applications-security/

    https://blogs.technet.microsoft.com/askds/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7/

    Best Regards,

    William


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Thursday, September 5, 2019 8:45 AM
  • Hello MooreNet,

    How are you constructing and sending the bind requests that you show? All of the Windows APIs that I can think of (ADSI, System.DirectoryServices, System.DirectoryServices.Protocols, WinLDAP) ultimately use the WinLDAP API and the routine ldap_bind/ldap_bind_s to perform binding; the fourth argument (ULONG method) specifies the authentication mechanism. The constants LDAP_AUTH_NTLM (0x1086), LDAP_AUTH_NEGOTIATE (0x486) or LDAP_AUTH_SICILY (0x286) would be possible choices, in your case.

    The list of mechanisms is a little opaque. DIGEST-MD5 is reasonably clear; EXTERNAL is the only mechanism explicitly defined in the SASL RFC (4422). GSSAPI is a little bit confusing - its name suggests an API rather than a protocol/mechanism; RFC 4752 says:

       The SASL mechanism name for the Kerberos V5 GSS-API mechanism
       [RFC4121] is "GSSAPI".  Though known as the SASL GSSAPI mechanism,
       the mechanism is specifically tied to Kerberos V5 and GSS-API's
       Kerberos V5 mechanism.

    That leaves just GSS-SPNEGO as a mechanism for NTLM authentication. This will negotiate a specific authentication protocol (typically supporting Kerberos and NTLM). Usually Kerberos will be negotiated if the client is able to obtain a Kerberos ticket for the LDAP service, otherwise NTLM is selected; one can arrange matters so that Kerberos is not an option (e.g. by referring to the LDAP server by address rather than by name), thus forcing NTLM.

    Even though not advertised in the list of supported SASL mechanisms, Microsoft LDAP servers support another mechanism called "Sicily" (see [MS-ADTS]), which typically results in NTLM being used; LDAP_AUTH_SICILY selects this mechanism, as does LDAP_AUTH_NTLM (but short-circuits the Sicily negotiation step). Sicily does not support Kerberos, so there is no need to worry about "defeating" use of Kerberos when using this mechanism.

    Gary

    Thursday, September 5, 2019 9:01 AM
  • Hello MooreNut,

    Sorry, your update arrived while I was still composing my reply. I am fairly sure that a plain "NTLM" SASL mechanism is not supported. The only options for using NTLM are via SASL GSS-SPNEGO and Sicily.

    Some of the numbers in the error message are hexadecimal numbers.

    (80090308: LdapErr: DSID-0C090671, comment: AcceptSecurityContext error, data 57, v23f0)

    0x80090308 = SEC_E_INVALID_TOKEN

    0x57 = ERROR_INVALID_PARAMETER

    0x0C090671 encodes a source file number and line.

    Gary



    Thursday, September 5, 2019 9:20 AM
  • Hi,

     

    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

     

    Best Regards,

    William


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, September 9, 2019 8:33 AM
  • Thank you very much for the info and insight.

    Is there anything more specific in relation to 

    0x80090308 = SEC_E_INVALID_TOKEN

    0x57 = ERROR_INVALID_PARAMETER

    Any indication as to what specifically they relate to?

    Basically I have a flow where bind is sent with the NTLMSSP and NEGOTIATE - this negotiate token is directly from the client. Client IE browser. 

    I get valid bindresponse from the AD with the Challenge which I relay back to the client.

    Client sends back in the NTLM 3 ( NTLM Response ) but the AD rejects it. With 80090308 and 57. 

    If I use the same credentials  ( user and password ) via ldp ldap client, the same flow happens and authentication is successful. 

    Any further thoughts? 

    Thank you. 

    Tuesday, September 10, 2019 6:13 PM
  • Thank you very much for the info and insight.

    Is there anything more specific in relation to 

    0x80090308 = SEC_E_INVALID_TOKEN

    0x57 = ERROR_INVALID_PARAMETER

    Any indication as to what specifically they relate to?

    Basically I have a flow where bind is sent with the NTLMSSP and NEGOTIATE - this negotiate token is directly from the client. Client IE browser. 

    I get valid bindresponse from the AD with the Challenge which I relay back to the client.

    Client sends back in the NTLM 3 ( NTLM Response ) but the AD rejects it. With 80090308 and 57. 

    If I use the same credentials  ( user and password ) via ldp ldap client, the same flow happens and authentication is successful. 

    Any further thoughts? 

    Thank you. 

    Tuesday, September 10, 2019 6:13 PM
  • Just to be clear, when I mention same credentials on the ldp client, NTLM is enabled, so the NTLMSSP is on the wire over LDAP to the Active Directory. 

    Tuesday, September 10, 2019 7:45 PM
  • Hello MooreNut,

    Thanks for trying to be clear but, even after some reflection, I am not completely clear about the situation. Is the following an accurate retelling of your situation:

    • Using the Windows ldp.exe program directly to AD, authentication succeeds.
    • Using Internet Explorer web browser to some intermediate system and forwarding the HTTP Authorization header to AD (using OpenLDAP) fails.

    A network trace of the LDAP connection establishment (between AD and the systems communicating directly with it) might be helpful...

    Gary

    Tuesday, September 10, 2019 8:20 PM
  • hello Gary

    Yes that is correct.

    I cannot attach trace?

    Here is capture: 

    For the bindRequest 61 and 62 and associated responses - these are for the ldp client program which has NTLM enabled. 

    For the bindRequest 1 and 2, they occur from the intermediate process that sits between the IE client and AD.


    So the Challenge is the NTLM type 2 message (generated on the AD), that is sent back to Client and Client comes back in with the type 3, which I pass on, but the AD does not like it.

    

    Tuesday, September 10, 2019 9:51 PM
  • Hello Gary.

    Interestingly, the flow works when using Firefox and AD response is appropriately correct for valid and invalid creds. ( ie. success or invalidCredentials respectively )

    But with IE. it always gives the invalidCredentials.

    Wednesday, September 11, 2019 3:30 PM
  • Hello MooreNut,

    Writing a web server application that manages its own HTTP 401 responses (including WWW-Authenticate and Authorization headers) testifies to a good level of know-how. Taking the HTTP base64 encoded raw authentication data and injecting it into an LDAP bind is even more impressive - it is difficult to know what I can usefully say.

    What I would do is trace/capture the packets in the LDAP bind. If one knows the account username and password, it should be possible to independently verify the validity of the data passed to the LDAP server - using either the NTLM specification (and MD4/DES APIs) or undocumented Windows routines (such as RtlCalculateNtOwfPassword and RtlCalculateNtResponse).

    If you want to share traces (e.g. the LPDAP bind sequence from both working (Firefox) and failing (IE) clients), then one can make the data available via OneDrive, Google Drive or similar.

    Gary

    Wednesday, September 11, 2019 7:01 PM
  • hello Gary

    is this an actual bug?

    I can now confirm that it fails to authenticate in all cases where the NTLM MIC (Message Integrity Code) is present.

    Any thoughts?

    Wednesday, September 11, 2019 9:54 PM
  • Capture showing 

    1 - successful handshake from FF.

    2 - failed handshake from IE

    - Note that the presence of the Version and MIC ( from IE ) in the failed case for the NTLMSSP_AUTH.

    Network Capture

    https://drive.google.com/file/d/1qOaA_jTFYYZn0TqGeU4sFtd9zYrGiXL0/view?usp=sharing

    Wednesday, September 11, 2019 10:39 PM
  • Hello MooreNut,

    Thanks for providing the traces - they show why the authentication is failing and the major hurdle to the approach you are taking.

    If you dig down deep enough in the AUTHENTICATE_MESSAGE (MessageType = 3) in the failing case, you should see this:

    The MsAvTargetName value ("HTTP/ntlm.esptest.local") makes clear that the authentication was intended for a different service, but this is not the actual problem. It is the MsvChannelBindings AV_PAIR that cause the problem - this ties the authentication data to a particular "channel" via a hash of things like IP addresses and TCP/UDP port numbers (in this case, the TCP connection between web browser and web server).

    One might be better advised to investigate "constrained delegation" possibly combined with "protocol transition" (NTLM to Kerberos) to achieve the desired effect.

    Gary

    Thursday, September 12, 2019 11:06 AM

  • Thank you Gary for the information.

    I can see the implications now.

    While I know it is not to be recommended, is there any way to negotiate down to not use the MIC? Or will IE always send it? What about the Always Sign and Sign negotiate flags? are they related? 

    Would a specific combination of negotiate flag(s) in the Challenge result in a client not incorporating the MIC?

    I dont know if it is a flag combination or limitation on firefox that results in MIC not being sent. 

    In this case, I could build the NTLM type 2 challenge myself and set limited flags, capture the NTLM type 3 from client and forward to AD.

    But if the Active Directory side is context and state driven, then I guess it may require the full handshake anyway?  

    ie. the negotiate, challenge and auth. 

    How is this supposed to work with compatibility for older clients? or clients that may not support the MIC?

    Appreciate your insight. 

    Thank you. 

    Thursday, September 12, 2019 5:05 PM
  • Hello MooreNut,

    Sorry, I was wrong to say "via a hash of things like IP addresses and TCP/UDP port numbers" - the connection from the web browser to the web server probably used TLS (https) and the "channel binding" information is derived from the TLS channel properties. You could try using plain HTTP (http) - Internet Explorer still adds a channel binding AV_PAIR but it contains only zeroes.

    The decision to use channel binding is in the hands of the client (it is not negotiated) - Internet Explorer chooses to perform it and Firefox seems not to. When channel binding is used, a MIC is needed to prevent tampering with the channel binding value.

    The signing flags (always/negotiate) are not relevant to this issue.

    Gary

    Thursday, September 12, 2019 6:20 PM