[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 after the security policies change
2. Understanding the Environment
According to the company’s administrator, the only change was to logon workstation restrictions, by limiting on which workstation the user can logon. You can find this window on the user’s properties, as show in the window below: Figure 1 – Restricting what workstations the user can use to logon.
3. Isolating the Problem
Figure 2 – LDAP Tool’s authentication window.
For this particular scenario, the test succeeded, it worked fine. It worked without have 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. 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
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
LDAP Message, Bind Result
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
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
Message Id: 1
Message Length: 83
Response In: 998
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
Message Length: 94
Response To: 997
Time: 0.001954000 seconds
Result Code: invalidCredentials (0x31) <-------------- ERROR
Error Message: 80090308: LdapErr: DSID-0C090334, comment:
AcceptSecurityContext error, data 531, vece
The LDAP Protocol implemented by Microsoft can use the following methods:
Description
LDAP_AUTH_SIMPLE
Windows NT® LAN Manager
Distributed password authentication (used by Microsoft Membership System)
LDAP_AUTH_NEGOTIATE
LDAP_AUTH_SSPI
This constant is obsolete and is included for backward compatibility only. Using this constant selects GSS (Snego) negotiation service.
Let’s see the authentication process on the third party LDAP Application:
The application sends the authentication using LDAP_AUTH_SIMPLE. This method sends only the user name 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 list of computers that the user can logon.
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 showed below:
5. Conclusion
The problem was not with the Microsoft LDAP Standard, neither was security vulnerability in the system. The problem was on this particular LDAP Application that was using an unsecure 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
Ed Price - MSFT edited Revision 7. Comment: TOC
Yuri Diogenes [MSFT] edited Revision 5. Comment: Fixing hyperlink
Yuri Diogenes [MSFT] edited Revision 4. Comment: Adding new tag to reflect on Security Tech Center
Yuri Diogenes [MSFT] edited Revision 3. Comment: minor changes
Yuri Diogenes [MSFT] edited Revision 2. Comment: Fixing a typo on item 4
Ed Price MSFT edited Revision 1. Comment: Updated title case and font to Segoe UI.