Securing LDAP simple binds in Domain when one application does not support it
Posted on 2013-01-03
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
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.
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:
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.