Hi Folks,
Please point me to the correct place to ask my query if this is not where I should be doing so.
History: We have a series of Drupal based web sites that we are working towards creating a single sign-on setup using LDAP and the Drupal LDAP modules. This all works fine and this is not a Drupal question. . .
We are in a department at a university where there is a centrally managed LDAP server that we can query against. We would like to allow some users of our who are not part of the university (they are not staff, students, or faculty) and the central IT guys do not want to add non-university members to their LDAP directory. Makes sense and is completely fair.
We thought that we would setup our own LDAP server to query against. We can set up Drupal to query multiple LDAP servers. So we could set it to request information from our LDAP server and if it does not find a match, then it can look to the university's server and return log in credentials.
Problem: Some of the users who are in the university's LDAP server may require to have other attributes assigned to them that only we are aware of. We do not want multiple accounts (ie userA on our server and userA on the university's server) just to assign more attributes to the user.
We thought that a translucent overlay in our LDAP server might be our solution, but it seems that we would not be able to create our own users on this server, but only assign the added attributes...
Question: Is there a way that we can setup an LDAP server to allow us to have our own accounts as well as look upstream to the master server and return log in credentials with some of our own attributes assigned if it does not find a local account? It would, of course, have to not allow log in if the account is not present in either server.
Setup: a) a local database b) another local database, with slapo-translucend
store in (a) local-only users; use (b) to add local attributes to remote users. Glue (a) and (b) together; for example,
# local users database hdb suffix "ou=local,dc=example,dc=com" subordinate # ...
# remote users with local attrs database hdb suffix "dc=example,dc=com" # ... overlay translucent # ...
Requests for "ou=local,dc=example,dc=com" will be dealt with locally; requests for "dc=example,dc=com" will be dealt with by both databases seamlessly, in a single operation.
p.