Microsoft Active Directory is one of the most popular Identity management systems for storing employee records. It is a required component for any organization that uses Microsoft Windows domains and thus is ubiquitous in Microsoft shops. Typical information stored about employees include name, department number, user id, password, group membership, phone numbers, and addresses. Active Directory can be accessed by all Microsoft Products and most applications written under Microsoft Development Frameworks. It can also be accessed by many external application since it operations under the LDAP (Lightweight Directory Access Protocol) standard.
While very popular for storing employee records, Active Directory is not as popular for storing customer records. Reasons include:
Microsoft requires licensing for external users. Often a company may have a have a very large number of combined customers/partners/prospects whose numbers vary constantly.
Often, external customer profiles requires additional custom fields such as membership level, birthdate, picture of spouse, etc. Active Directory managers are often reluctant to extend AD since it is required for the proper functioning of the corporate network.
A company that has hundreds to thousands of employees but hundreds of thousands to millions of customers may not wish to extend their Active Directory infrastructure to that many users
Adding customers to the employee directory runs the risk of inadvertently granting unauthorized access to an external user.
For one or more of these reasons, companies often seek to segregate non-employees into a separate directory. Popular choices include custom databases, external Active Directory domains, and LDAP servers. Let’s look at each of these.
Probably the most popular option. Custom customer databases arise organically when a customer facing application is developed or purchased that requires database records for each users. In the best case, this database grows to be a central database for customers (system of record). In the worst case, multiple databases each containing overlapping customers sets emerge. Databases are easy to setup and understandable but the data format (schema) is proprietary and they must be manually integrated into new applications every time.
External Active Directory Domain
Companies can create a separate domain for customers. For example, if the company domain is coolco, they create another domain called coolcox-ext, this is established on domain servers reachable from outside the network usually via ADFS proxy. The coolco-ext domain will have a one-way trust established to the coolco domain so that externally, both customers and employees can login from the outside. This provides segregation protecting the corporate domain but does not address licensing or profile extension issues.
Companies that scale to handle high volumes of customers, often use a commercial or open-source LDAP server. These servers are meant for high capacity and can handle thousands of request per minute and scale to millions of servers. For many LDAP servers, licensing is either free or node-based so that users do not need to be licensed. Since the protocol for AD and LDAP servers are the same, applications do not need special customization. LDAP servers cannot establish one-way trusts to the internal active directory, however, many support authentication pass-through. When an employee logs in from the outside, the LDAP server recognizes that their password is really on the internal AD, and forwards the login request through. Coupled with user synchronization, this feature allows the same unified login experience for employees and customers.
Hybrid models via synchronization
It is usually impossible to change directories all at once. By syncing users between the internal active directory, legacy user database and the customer LDAP, new applications can have a comprehensive directory of all users while existing applications do not need to change.
As new applications come on board they use the consolidated directory. Users login can authenticate directory to the directory or can be passed through to the appropriate legacy directory. As application evolve, they can migrate from the legacy directories to the consolidated directory at their own pace.