RE: [ActiveDir] Identity Management using AD

[Jackson Shaw]

Title: Message

It provides all of the LDAP capabilities of AD without the added baggage of things like DNS, DHCP etc etc – it’s a standalone LDAP directory with additional bells & whistles like:   -          doesn’t need to run on a DC -          multiple instances running on one machine -          instances are NT services so you can easily stop/start -          comes with a bunch of schema choices (i.e., inetOrgPerson) -          schema can be changed with re-booting the “server” -          runs on XP for development -          uses the same tools used for AD so mgmt is what you are used to -          same code base as AD so you get all of the replication and scalability capabilities that are already inherent   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Thursday, July 10, 2003 3:50 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Identity Management using AD   I wasn't thinking of what it required as much as what it provides. I'd assume[1] that it provided comparible functionality on a smaller scale, but apparently there's a reason they want you to deploy the real deal....     -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] Standard Disclaimers Apply -----Original Message----- From: Rick Kingslan [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 8:04 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD You're right - I can't keep up with the TLA's....   As to ADAM - it will run on XP/2003, but does not require that the domain be in native mode or forest functional as we're only hosting an AD environment for specific purposes - not a full functioning DS with every bell and whistle.   Rick Kingslan  MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Wednesday, July 09, 2003 9:48 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Identity Management using AD WRT = "with regards to" What's the matter? Can't keep up with all the TLA's?[1]   I haven't played with ADAM, but have done a bit of reading. I was assuming, probably incorrectly, that it would only function in the full native mode/2003 Forest mode. It doesn't seem to make sense for a product like this to be built to support downlevel DC's. -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. [1] Three Letter Acronyms -----Original Message----- From: Rick Kingslan [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 9:21 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD Roger,   I'm not sure that I follow......  Firstly, the acronym might have thrown me off - I haven't seen this one.....  'WRT H' means....?   And, to speculate, (seeing as I might be missing information with the WRT H thing and all.... ;-)  ) you've messaed around with ADAM, right?  Can be on WinXP, Server 2003 - create multiple instances of an AD structure, but more like an AD-lite?   Rick Kingslan  MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Wednesday, July 09, 2003 6:25 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Identity Management using AD WRT H, isn't ADAM an Win2k3 'forest'? If so, this isn't an issue, right?     -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. -----Original Message----- From: Rick Kingslan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 10:12 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD Glenn,   Interesting questions, and I'd like to take a shot at lending an opinion on some of these points.  Firstly, privacy seems to have become a trure art form in the States.  From Graham-Leach-Bliley to HIPPA, we're regulated to the n-th degree.  I'm not sure if it's good or bad - but it's something to be aware of.  Then, to the other extreme - the Higher Educational system where the 1st Amendment meets rational thought and security. ;-)   a) I agree 100%  I think AD is a very well designed store for this type of storage - given that triple-A is available out of the box (authorization, authentication, auditing) b) True - fairly static - not changing much.  Just enough to keep the Identity portion in place. c) Nope - see D d) ADAM - Active Directory Application Mode.  Synching available, greater level with MMS (MIIS??) multiple instances and truly designed for the application depository e) Joe is going to be the man to answer this - he's been doing the massive number management function - though I don't think to this number. ;-) f) Passport (and to some degree, rightly so) has been beat up pretty badly  However, in your environment, Passport may be more viable than how it is being leveraged by MS g)  Heh - layering these things is possible, though it can get hairy to manage.  Mapping of certs to names / objects, expansion of schema for new funtion to handle biometrics, and the smart card option is all pretty good - but smart card is going to leverage certs to some degree at some level  Not knowing what price level / sensitivity of data / regulations you are delaing with makes it a bit hard for me to suggest anything, but any layering is obviously going to raise the price becasue of the complexity / added hardware / software and added processor for keyed type solutions h) Can't say that I've run into any or know of anyone that has (well - not completely true I know Gary Olsen with HP, and he ran into the KCC issue mentioned in a moment) - obviously, they are there.  Microsoft claims to have tested to billions of objects - and I have no reason to not believe this to be true.  The KCC topology (KCC cannot work if (1 + #Domains) x sites^2 > 100,000) issue of Windows 2000 does indicate that there are issues here and there.  They get fixed, but usually are big fixes.  In the case of the KCC issue, it's fixed in Server 2003, but only once you get to 2003 Forest Functional mode.  That's a big move. i) Because it's there.....  Oh, wait!  That's for mountains.....  never mind.....   Rick Kingslan  MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn Corbett Sent: Tuesday, July 08, 2003 6:36 PM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] Identity Management using AD Thanks Todd.   At the moment, we arent hugely concerned about putting *some* privacy information into AD, as this instance of AD will only be for our external clients, and the attribute level ACL's provided by AD should provide enough security to stop certain applications / users from seeing this information.  That being said, we are looking into the appropiate laws / leglislation / statutes regarding privacy and the storage of personal information to make sure we are covered from that aspect.   I've done the required high level checking, and AD shouldnt have any trouble storing the amount and type of information we require (up to 6-8 million user objects, several thousand groups etc), its really down to the following questions:   a) Is AD an *appropiate* store for this sort of information (my answer would be yes, based on the Authentication / Authorisation provided by AD) b) What sorts of information should be stored in AD (I'll be pointing out the often read / rarely written aspects of AD) c) for application specific extensions, is this appropiate to store in AD (my current thinking is NO, as I'll end up with several hundred additional user properties, better to store them elsewhere and sync) d) in relation to c, if not in AD, then where, and how to keep these disprate databases in sync e) What management tools / processes are required to manage a 6-8 million user AD, and what are the associated security implications (eg exposing the admin interfaces to the internet, as opposed to just internal exposure) f) What other solutions are available that may be able to provide the Authentication / Authorisation that is required (mention has been made of Passport etc, and how would this tie in with AD - if at all) g) What additional authentication methods can be layered on AD to provide additional levels of authentication (Certifications, SmartCards, Biometrics etc) - I know AD can do all these, its really how to integrate them, and the associated security / management implications. h) What are some of the constraints on AD that could be an issue down the track (like the X users in a group problem under 2k). i) Why me ?? *grin*   I'm sure Murphy was the first one out with a book :P   Glenn   ----- Original Message ----- From: Myrick, Todd (NIH/CIT) To: '[EMAIL PROTECTED]' Sent: Wednesday, July 09, 2003 12:11 AM Subject: RE: [ActiveDir] Identity Management using AD   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