如何知道使用LDAP绑定成功进行身份验证的用户的objectGUID

Question

I have:

• a PHP application on a linux server
• a (windows server 2012) domain controller

I want to make it possible for AD users to log in the PHP application. The PHP application will associate data to the user, so i need to create the user in my database.

When a new user is created in the PHP application, the administrator chooses from a list of the userPrincipalName of the AD users. When a userPrincipalName is chosen, the PHP gets the objectGUID of this user and stores it in the database. Indeed, as the UPN could change, i can not rely on that to uniquely identify the user. Also, i want that if the UPN changes, the user can sill log in seamlessly to the PHP application, with his new UPN.

When a user wants to log in my application, the PHP receives a username and a password, and pass them to ldap_bind to check if the credentials are valid. The problem at that point is that ldap bind gives no clue of what user he actually identified (ldap_bind has a complicated logic of validating a login/password ( https://msdn.microsoft.com/en-us/library/cc223499.aspx )).

The most atomic (and hence, reliable) way of doing it would be if ldap bind was returning the objectGUID... But it doesn't, and i won't code the logic of ldap bind in PHP to find which user he has actually identified (it would be buggy anyway because of race condition if the directory change between the ldap bind and my "manual" search)

So what should i do to authenticate AND identify the LDAP user from PHP, if possible, in a single request to the domain controller (to get atomicity) ?

Answer 1

At some point in the process you need to have logic that searches for the UPN being used for the username in the login, obtain its objectGuid, and search for that objectGuid in the database. There is no other way to get that information.

If you're worried about a potential race condition (which seems like quite the edge case, given the timing between the bind and the search would be extremely tight), you could use a separate AD service account that searches for the account by UPN prior to the bind. Then in the ldap_bind for checking the user's credentials you could even use the objectGuid from the account you searched for to do the login, as that's a valid "username" for an AD bind (the GUID with curly braces around it that is).