LDAP用户和Web应用程序

Question

We built a web application (running on our intranet) that relies on our LDAP directory (active directory) for it's users. Instead of 'syncing' the directory users with say a 'user' table in our application database (MySQL) we use the LDAP directory just like we use databases.

When creating a relation between an entity pulled from MySQL and an LDAP user we use the user GUID (which is a unique string).

Our directory will never have more than 300 users (never). We installed a dedicated DC (Domain Controller) to serve our application request. Network latency is not an issue.

In our code we could replace a few lines of code to switch from using LDAP to using MySQL and a 'user' table (data mappers are awesome)

Would you do this (no 'user' table syncing)? What are your arguments against this (way of doing it)?

edit

We do use a 'user' table but it's very simple so sql joins are not really a problem, we know it will have better perfomance with a full user table but are looking for other arguments against using LDAP

CREATE TABLE `user` (
    `_id` int(4) unsigned NOT NULL AUTO_INCREMENT,
    `guid` varchar(255) NOT NULL,
    PRIMARY KEY (`_id`)
);

Answer 1

I would not do it. I would sync the users data except for the password on every login. That way you have the current data of your application in its database and you can use your databases join features to get all the relevant information without going to query different systems. I'd only use LDAP for authentication and perhaps a model of LDAP-Group based authorization.

• That way you do not need to hassle with passwords and any password policies.
• And after login you are completely independent from the LDAP-server.
• A missing LDAP server won't affect already logged in users only new logins would not work.

And even though the objectGUID is unique it is unique throughout your LDAP and not necessarily your application.

We often have the issue that in LDAP a user us newly created instead of renamed when the users name changes (due to marriage or divorce fi). But you might not want to create a new user in that case in your app. With your own users table you can simply change the ObjectGUID for a user and the users app-internal id stays the same but links to a completely new user in LDAP.

Answer 2

I would definitely do that for authentication, the base user profile, and user status. The AD entry for the user is highly likely to me more current than the data you have for the user. It removes the need for you to manage passwords for users. You don't need to store them or provide a facility for changing them. When the user status is disabled in Active Directory your user won't be able to use your applications anymore. If the user's name, email, phone number changes in AD then you will always have the most up to date data and you don't have to provide a facility to manage it.

The objectGUID is perfect way to link your account as it is unique and immutable.