RE: [ActiveDir] Identity Management using AD

[Myrick, Todd (NIH/CIT)]

Title: Message

We are in the process of evaluating MIIS here, and AD is currently our source for authentication information, for Enterprise application, we are using a custom database running on Critical Path to sync with other application directories, and get a metaview of the information for identity management.  Currently no one allows the metaview write access anywhere.   I hope our testing and subsequent deployment will allow for a more standardized approach like what was described below.   To build on what Gil wrote,  The reason why SQL server was used to store identity information, was probably because it was a metaview of all the relevant data needed to construct an employee including privacy information.  Active Directory doesn't need access to privacy information (SSN#, DOB, etc) nor do many LDAP applications.  The nice thing about MIIS, is that it can create that metaview for you and store it in a SQL server.  So if your privacy information is only stored in the HR system, and Payroll, Then you can set ACL's on the info so only those systems get that info.   If you are getting into directories for both network access and Enterprise Resource and Application use, I suggest subscribing to the Burton Group papers on Enterprise directory, and constructing your architecture based on some of their principals.  Now if we could only find a group willing to figure out the Laws of directories we would be golden... Maybe Murphy is already doing them.   Todd -----Original Message----- From: Gil Kirkpatrick [mailto:[EMAIL PROTECTED] Sent: Monday, July 07, 2003 5:30 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Identity Management using AD MSFT internally uses SQL Server as the authoritative store for identity information, and populates AD from that. -----Original Message----- From: Glenn Corbett [mailto:[EMAIL PROTECTED] Sent: Thursday, July 03, 2003 7:00 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Identity Management using AD All,   We are in the process of redefining our Internet-enabled applications with a view to a centralised customer/client database.  There has been quite a bit of discussion regarding using AD as this "customer store", since AD will already be in this environment.   I'm a bit hesitant to recommend "vanilla" AD for this task, however I can see a number of benefits to this approach, as the support monkeys can manage the entire environment using the same tools they use to manage the production environment (ADUC etc).   I've been reading up on the information regarding MIIS (what little there is), and can see some potential for a configuration such as this, eg:   - Use AD to store the "core" customer information (user name, password, basic details) - Use ADAM or SQL (or whatever) for each application to store application specific extensions (so I don't end up with a blown out schema in AD with thousands of additional props for user objects) - Use MIIS as the Authentication / Identity management front end, and use it to sync these disparate databases to ensure some semblance of "sameness" between them. - Also use some of the MIIS features such as provisioning etc to ease the management overhead.   Applications could use AD to authenticate the customer coming in, and then use their ADAM database to house the application specific information they need.   We could possibly then use MIIS to "backchannel" into the production AD system, so that corporate users can gain access to these Internet applications without requiring multiple accounts.   This is all just brainstorming at the moment, however (as usual), I need to come up with some sort of design by next week (gotta love being given lots of time *grin*).  Having not actually got my hands on MIIS, this could be completely unfeasible.  Other options are a custom database for the "customer store", or some other existing product.   Has anyone been down this road before, and could share some insights / resources ?   Thanks   Glenn