Share via

Domain Security Changes: Dealing With Legacy Applications

  • Article

[Note: This article was originally posted at http://blogs.technet.com/b/yuridiogenes/archive/2008/03/10/when-security-in-mind-doesn-t-match-with-the-application-s-security.aspx ]

1. Introduction

Scenario:  Security policies are applied without taking into consideration how applications will be affected by the security policies change

  • The company has an application that uses LDAP to send a query to Active Directory.
  • The user that uses this application tries to connect to Active Directory (using LDAP) uses his credentials to bind to the directory.
  • This application has worked fine for years.
  • Problem: After the company implemented some security policies this particular application stopped working.

2. Understanding the Environment

According to the company’s administrators, the only change was to login workstation restrictions, by limiting on which workstation the user can log in. We  can find this window on the user’s properties, as shown in the window below:


Figure 1 – Restricting what workstations the user can use to log in.

According to the administrator, the application that uses LDAP just works if he adds the domain controller to this list. 

3. Isolating the Problem

To validate if the issue was happening only with the third-party applications, we can use Microsoft LDAP (LDAP.EXE) utility, which is available via Windows Server 2003 Support Tools. After open the LDAP.EXE, on the screen below, add the username, the password and check NTLM:


Figure 2 – LDAP Tool’s authentication window.

For this particular scenario, the test succeeded, it worked fine. It worked without having to add the DC in the logon workstation’s list.

4. Narrowing Down

The better way to understand the difference between the two applications and how LDAP behaves in this scenario, use Network Monitor. Here an example of this trace:

Test 1 – Using Microsoft LDAP.EXE Tool

1. The client sends the request (TCP Port 389) and the 3-way handshake happens successfully:

 

192.1.16.15            192.7.11.12            TCP      4507 > ldap [SYN]

192.7.11.12            192.1.16.15            TCP      ldap > 4507 [SYN, ACK]

192.1.16.15            192.7.11.12            TCP      4507 > ldap [ACK]

 

 

2. The LDP Tool sends the “Bind Request” and the credentials are sent using NTLM:

 

192.1.16.15            192.7.11.12            LDAP     MsgId=13

Bind Request, DN=(null), NTLMSSP_AUTH, User: DOMAINNAME \TestUser

 

Lightweight Directory Access Protocol

    LDAP Message, Bind Request

        Message Id: 13

        Message Type: Bind Request (0x00)

        Message Length: 225

        Response In: 3175

        Version: 3

        DN: (null)

        Auth Type: SASL (0x03)

        Mechanism: GSS-SPNEGO

        GSS-API Generic Security Service Application Program Interface

            NTLMSSP

                NTLMSSP identifier: NTLMSSP

                NTLM Message Type: NTLMSSP_AUTH (0x00000003)

                Lan Manager Response:

F1DC6D4CFFCD04F900000000000000000000000000000000

                    Length: 24

                    Maxlen: 24

                    Offset: 134

                NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8

                    Length: 24

                    Maxlen: 24

                    Offset: 158

                Domain name: DOMAINNAME

                    Length: 18

                    Maxlen: 18

                    Offset: 72

                User name: TestUser

                    Length: 32

                    Maxlen: 32

                    Offset: 90

                Host name: COMPUTER1

                    Length: 12

                    Maxlen: 12

                    Offset: 122

                Session Key: 33724B7018EADC94650FCAAB1F6741EF

                    Length: 16

                    Maxlen: 16

                    Offset: 182

                Flags: 0xe2888215

 

 

3. Server answers saying that the bind was done successfully:

 

192.7.11.12            192.1.16.15            LDAP     MsgId=13 Bind Result

Lightweight Directory Access Protocol

    LDAP Message, Bind Result

        Message Id: 13

        Message Type: Bind Result (0x01)

        Message Length: 9

        Response To: 3174

        Time: 0.001953000 seconds

**        Result Code: success (0x00) <----------------------**

        Matched DN: (null)

        Error Message: (null)

 

Test 2 – Using Third Party LDAP Application 

1. Client sends the request (TCP Port 389) and the 3 way handshake happens successfully:

 

192.1.16.15            192.7.11.12            TCP      4507 > ldap [SYN]

192.7.11.12            192.1.16.15            TCP      ldap > 4507 [SYN, ACK]

192.1.16.15            192.7.11.12            TCP      4507 > ldap [ACK]

 

 

2. The LDAP Application sends the “Bind Request”, but now check the difference:

 

192.1.16.15            192.7.11.12            LDAP     MsgId=1 Bind Request, DN=CN=TestUser,OU=Test,DC=domainname,DC=local

Lightweight Directory Access Protocol

    LDAP Message, Bind Request

        Message Id: 1

        Message Type: Bind Request (0x00)

        Message Length: 83

        Response In: 998

        Version: 3

        DN: DN=CN=TestUser,OU=Test,DC=domainname,DC=local

**        Auth Type: Simple (0x00)** <---------------- Authentication Method

        Password: 12345678

 

 

4. Server answers with the error:

 

192.7.11.12            192.1.16.15            LDAP     MsgId=1 Bind Result, invalidCredentials

Lightweight Directory Access Protocol

    LDAP Message, Bind Result

        Message Id: 1

        Message Type: Bind Result (0x01)

        Message Length: 94

        Response To: 997

        Time: 0.001954000 seconds

**        Result Code: invalidCredentials (0x31) <-------------- ERROR**

        Matched DN: (null)

        Error Message: 80090308: LdapErr: DSID-0C090334, comment:

AcceptSecurityContext error, data 531, vece

 

 

The LDAP Protocol implemented by Microsoft can use the following methods:

Authentication Method

Description

 

 

LDAP_AUTH_SIMPLE

 

 

 Authentication with a simple clear-text password.
LDAP_AUTH_NTLM

Windows NT® LAN Manager

 

 
LDAP_AUTH_DPA

Distributed password authentication (used by Microsoft Membership System)

 

 

LDAP_AUTH_NEGOTIATE 

 

 

 Generic security services (GSS) (Snego). Does not provide any authentication services, instead chooses the most appropriate authentication method from a list of available services and passes all authentication information on to that service. Use with Windows® 2000

LDAP_AUTH_SSPI

 

 

This constant is obsolete and is included for backward compatibility only. Using this constant selects GSS (Snego) negotiation service.

 

 

Table extracted from the document Understanding LDAP.

 

Let’s see the authentication process on the third party LDAP Application:

 

1.

 

The application sends the authentication using LDAP_AUTH_SIMPLE. This method sends only the username and the password.

 

  •  

    When the DC receives the authentication requests it checks not only the user’s credential but also the User-Workstations attribute. This attribute contains a list of computers that the user can login.

     

  •  

    Since the application doesn’t send the location (domain or computer name) the DC uses his own name to check (DCNAME\User) to check that.

     

  •  

    DC checks if his own NetBIOS name is present on that list and since it is not it will refuse with an Access Denied.

     

     

    Now it makes sense that if we add the DC’s name to that list it will work. With the Microsoft LDP Tool, this doesn’t happen because we send the credential using LDAP_AUTH_NTLM. When we do this, the computer’s name is present in the request, as shown below: 

     

                    NTLM Response: F2988187EC1C67496EDF4F46313F401E08F688325DC541A8

                        Length: 24

                        Maxlen: 24

                        Offset: 158

    **                Domain name: DOMAINNAME**

                        Length: 18

                        Maxlen: 18

                        Offset: 72

    **                User name: TestUser**

                        Length: 32

                        Maxlen: 32

                        Offset: 90

    **                Host name: COMPUTER1**

                        Length: 12

                        Maxlen: 12

                        Offset: 122

                    Session Key: 33724B7018EADC94650FCAAB1F6741EF

                        Length: 16

                        Maxlen: 16

                        Offset: 182

                    Flags: 0xe2888215

     

     

    5. Conclusion

    The problem was not with the Microsoft LDAP Standard, neither was a security vulnerability in the system. The problem was on this particular LDAP Application that was using an unsecured authentication method. In this case there was an extreme concern about protecting the domain with security policies; however, the main company’s application was using clear text authentication method. This is an example that security is not only one piece when we think about security we have to cover all layers to reduce the attack surface. 

    This article was originally written by:

    Yuri Diogenes, Senior Technical Writer Windows Server iX | IT Pro Security Microsoft Corporation

    Yuri’s Blog:http://blogs.technet.com/yuridiogenes
    Team’s Blog:http://blogs.technet.com/b/securitycontent
    Twitter:http://twitter.com/yuridiogenes