How secure and well managed are your LDAP services? Ever considered using a LDAP Proxy? Shouldn’t my dumb VIP be sufficient for load balancing?
In my past 18 years working with LDAP I have seen many neglected systems. I have seen systems that allow anonymous authentication, clear text over port 389, accessible scripts with user authentication information, application authentication IDs that have too many rights and a lack of auditing. You may have hundreds of applications authenticating into your LDAP directory.
How confident are you that you don’t have data oozing where it shouldn’t?
Enter MicroFocus/NetIQ LDAP Proxy
It is a middleware layer between LDAP clients and LDAP directory servers. It regulates requests and responses, and provides load balancing, failover, query filtering, data hiding, request denial, centralized auditing and monitoring as well as graphical trending of activities. It can work against any LDAP server, and has no requirements on other MicroFocus/NetIQ products.
The search restriction policy will allow you to limit given containers from being available to a search, restricting what attributes can be seen and restricting the search filter. Many times I see where scripts or applications will ask for all attributes. This will help limit what you don’t want sent for a given policy.
The operation Restriction Policy will allow you to restrict given operations such as Bind, Search, Add, Modify, Delete, Modify DN, and Compare.
The connection Route policy enables you to route an incoming connection to an appropriate back-end server and determines the identity of an incoming connection and applies the required policies prior to forwarding it on the associated directory servers.
Request Routing provides the latest data for any directory server. If replication is delayed where a given server doesn’t have the current value, the Proxy Server tracks the data modifications across the servers and provides the latest data.
Have your login name be hard to guess. Don’t have it be first initial + last name or another common format as this allows 1/2 of the needed information for authentication. Don’t allow LDAP searches to return the login id, where not needed.
Always use TLS. Don’t do anonymous binds or use port 389.
Take the time to plan your LDAP authentication needs across your environment just as you should maintain and manage your Unix/Linux authentications centrally (using something like Centrify or NetIQ’s Privileged Access Manager.) LDAP needs the same care and thought process. Too many systems are lax in monitoring their user IDs. If you are using scripts to do LDAP lookups, make sure the scripts are secure as well and don’t use clear text passwords. Change the passwords often for system accounts / applications. Too many security audits are focusing only on open ports and if TLS is used. More needs to be done.
Point the proxy auditing logs to a SIEM such as NetIQ Sentinel that provides real time threat analysis as an optional security add benefit. Sentinel threat analysis can see anomalies across the network that may coincide to a threat that hadn’t been considered in the environment. Maybe a given terminal is attempting 2 authentications for multiple accounts that normally don’t authenticate or haven’t had authentication failures for some time. An application that has a few failed authentication attempts where the majority of the attempts are working may indicate someone trying a system user to gain access. Or it may detect where an application bind request is coming from a given IP when all requests have always been from two servers on a given segment.
Having one source for LDAP management and auditing will give a consistent view for auditing to your SIEM.