> 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.
