Link to home
Start Free TrialLog in
Avatar of ITdiamond
ITdiamondFlag for United States of America

asked on

Securing LDAP simple binds in Domain when one application does not support it

We recently upgraded our domain functional level to 2008 R2 since the decommissioning of the last 2003 DC a few weeks ago.  One of the events under Active Directory Domain Services that pops up on each of the 3 2008 R2 DC's is this:
Event ID: 2886
ActiveDirectory_DomainService
The security of this directory server can be significantly enhanced by configuring the server to reject SASL (Negotiate,  Kerberos, NTLM, or Digest) LDAP binds that do not request signing (integrity verification) and LDAP simple binds that  are performed on a cleartext (non-SSL/TLS-encrypted) connection.  Even if no clients are using such binds, configuring the server to reject them will improve the security of this server.
 
Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection, and will stop working if this configuration change is made.  To assist in identifying these clients, if such binds occur this  directory server will log a summary event once every 24 hours indicating how many such binds  occurred.  You are encouraged to configure those clients to not use such binds.  Once no such events are observed  for an extended period, it is recommended that you configure the server to reject such binds.


I did alter the logging and determined everything using cleartext LDAP.  We migrated some things over to SSL/TLS-encrypted ldaps, and they work.  However I have one applicaiton - a web based time clock, which the vendor totally does not support LDAPS.  I asked the vendor to include it on their product roadmap, but you know how that is...

The time clock is essential to our organization.  It's how people get paid.  It's how managers log in and create schedules, approve time off, etc...  It uses LDAP so when a user logs in, they can use the same Windows username and password.  This is preferred because of Active Directory password policies (complexity requirements, changing it every so often, etc...).

I was wondering if there was any way we can maybe tunnel this LDAP request to an OpenLDAP *nix based virtual machine.  Or even install OpenLDAP on the same application server that the time clock runs (Windows 2003 Svr).  I'm looking for a secure way where non-secure LDAP binds are NOT ALLOWED to any Domain Controller, but maybe a proxy with a well known IP address (the timeclock server) is the ONLY thing allowed.

Some ideas:
1. Some kind of OpenLDAP proxy where the back end is bind to AD via LDAPs but the front end will only accept cleartext LDAP from the IP address of the Timeclock.

2.  Anything we can do in Windows Firewall or IP Filtering on the Domain Controllers?  Keep policy to allow SASL and TLS, but use IP filtering or firewalling to only allow non-secure LDAP from the timeclock server.

3.  Access control lists on the switch.  We have a stack of Cisco 3750 switches which are in Layer 3 mode and we could possibly put some kind of access list on this?

Any great ideas out there would be welcome to suggestions!
 
A little bit about the timeclock application.
Server is 2003 SP2 running IIS.  It is a domain member server so it inherently trusts the domains.
We have PKI (2008 R2 server running our Enterprise Certification Authority)
It does use some ASP but also PHP.  This extention is loaded in php.ini:
extension=php_ldap.dll

They have a custom LDAP setting at the very bottom of the php.ini

;LDAP - 0-Off, 1-On
;Must enable the php_ldap.dll extension
te.ldap = 1
te.ldap_domain = "dc1.domain.com; dc2.domain.com; dc3.domain.com"
te.ldap_organization = @domain.com

The vendor stated that they do not support ldaps.  Though it's PHP I am wondering if I can work it in because there are PHP modules.
ASKER CERTIFIED SOLUTION
Avatar of Rich Rumble
Rich Rumble
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The default port for ldap is 389, while Secure LDAP binds on port 636.
Check if your applications can be changed to connect to port 636 instead.

You can confirm if port 636 is open by using ldp.exe or other similar ldap browsers/utilities.

I've never had to specifically configured any of my servers like this but then if I look at whats being done, I understand why. If you've setup PKI correctly then this should be SSL features should be enabled. Do you have an Internal CA configured and do your servers have Server certificates?
http://support.microsoft.com/kb/321051

Additional discussions about LDAPS.
http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

P.S. Port 389 and port 636 can be open at the same time if you other application cannot work on LDAPS.
@dvt_localboy it's the time software written in PHP that doesn't seem to support ldaps/sasl, the author has stated that all other applications that have been switched to ldaps/sasl are working.
-rich
Avatar of ITdiamond

ASKER

Ok here is what I tried, tell me if this sounds like it is working.
On each of the 3 domain controllers in Windows Firewall with Advanced Security, I created a connection security rule (server to server).  Endpoint 1 is the IP addresses of Domain Controllers.  Endpoint 2 is any.  Authentication mode is Request inbound and outbound.  I have my Enterprise Root CA certificate attached to this.  Everything else is ANY/ANY/ALL.

On the application running the time clock, its Server 2003 so the whole firewall thing is completely different.  I was able to find IPSEC snap-in's via MMC and under IP Security Policies on Local Computer I created IPSEC Domain Controller Authentication.  In here I created an IP Filter list called Domain Controllers and LDAP and added the 3 IP addresses of our DC's.  Filter action is Request Security (I don't want to REQUIRE anything yet in case something goes wrong).  Authentication methods are tied to our Enterprise root CA.

Now on all 3 Domain Controllers in Windows Firewall with Advanced Security under Monitoring > Security Associations > Main Mode (and also Quick Mode), I see 3 entries.  The domain controller’s ip address is in the left hand column for all 3 entries, and in the next column under remote address I see two other DC's IP addresses and then also the IP Address of the time clock server.  The 2 2008R2 DC's show AES-CBC 128 for encryption and the 2003 server shows 3DES for the encryption.  1st Authentication method is "Computer Certificate".  2nd is no authentication.  Key Exchange is Diffie-Hellmen Group 2 for the Win 2003 server but none for the other DC's.

On the 2003 server running the application under the IP Security Monitor snap in, I also see the IP addresses of itself and the 3 DC's for both inbound and outbound.

In short I think that it's working.  I am still able to log in to the time clock application using my active directory credentials.  There was a slight delay the first time but ever since then it’s just as quick without this config.

Now I just winged this config so I can't tell you if this is super secure, good enough or has some room for improvement.  IPSEC seems like a good idea and I wonder what else I could apply it to?  Like could it be applied to SMB sessions and all other domain communications?  That would really secure our network in my opinion.

Back to the topic at hand...  I still can't disable non-secure / SASL LDAP binds because this application requires it.  However it seems this application is tunneling that traffic over IPSEC to each DC.  The concern was a man in the middle attack or a piece of malware that would interpret the communication and get the plaintext ldap credentials as they passed over the wire.  I would like to filter port 389 and I found the LDAP (TCP-In) firewall rule, but if I select Allow the connection if it is secure, all of the policies state compatible with Windows Vista or later.  Sure enough quickly trying this option breaks the LDAP connection with the 2003 server.

I guess I'm closer to having this secure now but would ultimately benefit from either the application 100% supporting LDAPS or upgrading and migrating the application to a new 2008 R2 virtual machine.

I'm curious to see any expert’s opinions.
You should get a sniffer setup and see if you can see if the data is actually tunneled and encrypted, because IPSEC can use "null" encryption. This feature of null encryption is useful on a few levels, it allows traffic to still be inspected on the network by IDS systems, as well as providing a second method of authentication and or authorization. Wireshark should be able to quickly show you if the traffic is encrypted between the LDAP <->TimeApp. I'm assuming that User -> Timeapp is https already.
(M$'s) IPSEC isn't an easy tool to use so I'd actually be surprised if you got it right the first time, it's really not easy to get right. You can look at the 3 default templates M$ ships with and see how the SECURE SERVER one looks. (secpol.msc will get you there quickly)
Personally I'd rather have SASL/LDAPS working, and if it's PHP those methods have been available in PHP since php 2 or 3 and they are currently on php5. The data that comes back from sasl/ldaps is no different than the basic connection as far as php is concerned.
-rich
Ok I actually have Packetyzer on the time app server and I'm looking at it now.

I see my IP to the Time App accessing the page, and then I see ESP (Encapsulating Security Protocol) to the IP address of one of the domain controllers when I put in my AD credentials to the time clock page.

So it looks like it is encrypted.  I see no sign of LDAP protocol anywhere as it must be encapsulated.

Surely using Group Policy to only allow secure ldap would be preferred.  That way no outside or future application can try to get anything out of a domain controller with standard ldap.  However I'm still looking for the code in the time app's php files that create the connection.

The only thing I have the "OK" to touch is the php.ini where the server names and domain name are entered.  So if I find one of their pages I'll be sure to back it up.  There are a lot of includes so theres many files nested and attached to other files.  This will take a little bit of reverse engineering, but at least for now it looks like this server autenticates to domain controllers securely.
Sorry guys, about earlier post, having a bad day at the office...dunno what I was reading earlier !
Slap@me
Well good on you then :) Your a better man than I, IPSEC is a pain for me :) It does however have a lot of good uses and very few admin's even know it's there. It does have some exceptions you should be aware of, however the way your using the IPSEC these exceptions do no affect you. If you use IPSEC as a firewall, blocking ports from being seen using the rules in IPSEC, that "firewall" can be bypassed by binding you scanner (nmap for example) to port 88 or port 500 (there are others too). In 2003 they created a way to overrule that exception (binding to port 88), but they don't recommend it. Windows current firewalls are better used than IPSEC, but it is possible to do some very complex "firewalling" using IPSEC nonetheless.
We use IPSEC as another authentication mechanism for our hosts in sensitive areas, while we don't encrypt the connections (so they can still be seen by IDS), we do have a very secure authorization mechanism by requiring the gre tunnels. Some hosts can get to some areas/servers and others can't.
As far as the PHP code you should be able to search for the string "ldap" or "389" within files and quickly find the area you need.
-rich
Thanks for the tip on IPSEC.  It seems to be encrypted to me and things are not broken.  Developer has no plans to work on LDAPS as of yet... so IPSEC it is.
They could do SASL at a minimum... add "encrypted= true" to the array of arguments they are already using... it'll bite them sooner or later. Nonetheless glad to be of service. As a bonus, have a read over this if your company ever has the crazy idea to use NAC/NAP
http://technet.microsoft.com/en-us/library/cc512611.aspx .
-rich