Identity Engineering

In January last year, I wrote a (long) post detailing a curious behavior I stumbled across in Active Directory's LDAP interface. By providing a username, but leaving the password blank, you were authenticated as an 'anonymous user'. This is technically a valid LDAP behavior, and is known as an 'unauthenticated bind'. However it's obscure, not well known, and the cause of many security vulnerabilities . To recap, the LDAP RFC states the following; 5.1.2.  Unauthenticated Authentication  Mechanism of Simple Bind An LDAP client may use the unauthenticated authentication mechanism of the simple Bind method to establish an anonymous authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [ RFC4514 ] of non-zero length) and specifying the simple authentication choice containing a password value of zero length The RFC goes on to acknowledge this is an objectively terrible idea, and recommends that servers

Microsoft's Local Admin Password Solution (LAPS) is a very important tool that protects against the risk of lateral movement of threats between computers when the same local admin password is used on each machine. It is an agent that is deployed to each computer that randomises and rotates the local administrator password on each machine, and securely stores it in the Active Directory. While the LAPS mechanism itself is robust and does exactly what it needs to do, the process of accessing the LAPS passwords, and auditing that access is not so straight forward. Support staff out in the field may not have easy access to the tools required to get those passwords. You either need to use PowerShell, LAPS client, or another directory tool such as AD Users and Computers. Auditing access to LAPS passwords is a bit of a nightmare. It requires configuring audit policies on domain controllers for directory object access, which is a very board audit category and can be very noisy. You

You could walk into just about any organization today, and you’re bound to find an LDAP directory populated with its users. Look a bit further, and you’ll likely find one or more applications using that directory for ‘authentication’. I say 'authentication' with quotes, because LDAP authentication is something of a misnomer. LDAP is a directory access protocol, designed for reading, writing, and searching a directory service. It's not an authentication protocol. LDAP authentication typically refers to the part of the protocol (binding) that is meant to establish who you are in order to determine what privileges you have to the information in the directory.  Over time, it’s become a de facto authentication service. The wide-spread availability of LDAP services, such as Active Directory, has turned it into an easy win for software developers who are looking to build authentication into their products. LDAP client libraries are available for just about any framework, and