Domain Security Changes: Dealing With Legacy Applications

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

Company has an application that uses LDAP to send 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 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.

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 application, 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 user name, 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 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:

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.

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:

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 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.