We archive inactive entries by removing them from the "active" part of the DIT and then recreating them in an "inactive" branch, where permissioning prevents all but a few administrative apps from seeing them. This allows us to prevent further use of the account while at the same time preserving information that might be helpful in an audit. If a user becomes active again (e.g. where an employee is rehired), we simply restore their entry to the active part of the tree. The two problems with this approach are accidental creation of duplicate entries (like when an employee returns after having a name change) and the fact that no off-the-shelf tool will do the archive/unarchive operation for you. I handle the former by yelling at HR alot and the latter by deploying some in-house created cgi scripts. The problem with using an "inactive" flag is that every COTS vendor who interfaces with LDAP has a different standard, and few are very customizable. Entrenched homegrown apps pose the same issue. Theoretically, the number of entries in a particular directory or directory container shouldn't be an issue. Unfortunately, many developers insist on treating LDAP like an RDMS, doing massive "data mining" queries and invoking Server Side Sort to boot. As a result, anything you can do to reduce the number of entries they can search through helps. -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
