Domain Security Changes: Dealing With Legacy Applications
[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