Description:
I have a large eDirectory environment with many replica servers and partitions. LDAP operations are distributed among several data center servers and a server sitting at the local site. Our tech support staff frequently deal with user password issues, and since they are on a phone helpdesk there is an element of time sensitivity.
The problem is that the techs may change a user password (or the users might self-service using the IDM User Application) but the password is changed on one server and takes a few minutes to replicate to the other servers -- including, perhaps, the LDAP server for the application whose incorrect logins led to awareness of a password problem.
I am writing an internal application that will, among other things, report the password change time for a given user on all of the main eDirectory servers. However, there may be others servers holding a copy of the user and I would like my application to show the status of those servers as well. Specifically, every site has a server that only holds the replica for that site and so the final server to be checked will be different across the user base.
Proposed Solution:
I would like a solution that neither routinely bogs down the LDAP server nor which requires additional installations beyond the common LDAP libraries found in many programming languages -- for example, the solution should not require modification to PHP's current LDAP functionality (this example being the platform I am using).
I therefore propose the following solution: A special LDAP attribute that is only returned when specifically requested (i.e. it does not show up when all attributes are requested). This attribute would return a list of all servers holding a real (i.e. not a subordinate or backlink) copy of the object requested.
It does not matter whether the return is the DN of the servers or the network addresses as from either of these I can found other information about the server. DN would probably be the best form, since this is LDAP and both NAT and IPv6 could complicate a network address return.
To my knowledge, none of the existing LDAP extensions to eDirectory would solve the problem as noted above.
Value Proposition:
Generally:
LDAP applications could determine all the places a user's record might need to be checked in a diagnostic situation.
My Specific Needs:
I could give my lower-level techs information about password change propagation (and other attributes) without having to teach them about the entire eDirectory infrastructure.
by: Johnnie O. | over a year ago | eDirectory
Comments
We are depending on LDAP more and more. I am in 100% agreement of these modifications.