AD, LDS and LDAP unauthenticated binds: A series of unfortunate security events
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifFCEUag4VEq9DKlyPb6xPpNkf1r-ybJmeWxiJBy5uqHmOjytbkjQ4g2IS7uYycoqrZdyDN79z_bhfu62hznudLk1LcbLKHYvY2XoRsicqLWtC-acv0Kxiq1lEQOrEQml2z2Q-VH_Faw9X/s1600/maxwell_smart__confused.gif)
Update: December 2018: Microsoft have provided an option to disable unauthenticated binds in Windows Server 2019 A caution to anyone that uses applications that rely on LDAP authentication against Active Directory, or Active Directory Lightweight Directory Services to do so. Both services will appear to accept a blank password for any users when performing a simple bind. While behind the scenes, that's not what is happening, if your application doesn't check for and reject a logon attempt with the blank password itself, it might incorrectly assume a successful authentication against LDAP. This post details how I came to learn about this behaviour, how wide spread the problem is, and what can be done about it. The discovery A few weeks ago, I was at my desk, enjoying my lunch, when I received a call from a customer in a panic. He told me that our AD LDS server was allowing people to access his application without typing in a password. I assumed he was talking about anonymo