RE: [ActiveDir] Identity Management using AD
Title: Message Yes, this has been in the works for some time to say the least. Glad the release is out and we are just about finished here at the Catalyst conference where we showed off our IdM products in our suite last night to a great reception by attendees. I wasnt at that specific meeting I think I was meeting w/Gartner in Connecticut then From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Thursday, July 10, 2003 4:17 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD You're that sure, are you Jackson? ;-) I had this really interesting discussion with Kim, Chuck (Director of AD??) a number of developers and Program and Product Mgrs.in February at the MVP Summit. I'm absolutely floored that you folks moved that fast on the Identity Management, given the discussions that we had. Obviously, this has been in the works for some time for MMS to morph. I can't say that I remember - were you there for that meeting (about 12 Server MVP's and about 10 MS folks packed into a conference room)? 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 Jackson Shaw Sent: Thursday, July 10, 2003 1:32 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD Were going to make the MV writeable. J From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Thursday, July 10, 2003 10:26 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Identity Management using AD Meaning being able to make changes in the metaview to replicate out It has not been decided. Todd -Original Message- From: Jackson Shaw [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 8:18 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD We're going to make the MV writeable... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Tuesday, July 08, 2003 7:12 AM To: '[EMAIL PROTECTED]' 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
RE: [ActiveDir] Identity Management using AD
Title: Message 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 PMTo: [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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 9:48 AMTo: '[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 AMTo: [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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 6:25 AMTo: '[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 PMTo: [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 Educationalsystem 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 car
RE: [ActiveDir] Identity Management using AD
Title: Message It provides all of the LDAP capabilities of AD without the added baggage of things like DNS, DHCP etc etc its a standalone LDAP directory with additional bells whistles like: - doesnt 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 Educationalsystem 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
RE: [ActiveDir] Identity Management using AD
Title: Message Meaning being able to make changes in the metaview to replicate out It has not been decided. Todd -Original Message-From: Jackson Shaw [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 8:18 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Identity Management using AD We're going to make the MV writeable... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT)Sent: Tuesday, July 08, 2003 7:12 AMTo: '[EMAIL PROTECTED]'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 PMTo: '[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 AMTo: [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 o
RE: [ActiveDir] Identity Management using AD
Title: Message Were going to make the MV writeable. J From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Thursday, July 10, 2003 10:26 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Identity Management using AD Meaning being able to make changes in the metaview to replicate out It has not been decided. Todd -Original Message- From: Jackson Shaw [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 8:18 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD We're going to make the MV writeable... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Tuesday, July 08, 2003 7:12 AM To: '[EMAIL PROTECTED]' 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
RE: [ActiveDir] Identity Management using AD
Title: Message You're that sure, are you Jackson? ;-) I had this really interesting discussion with Kim, Chuck (Director of AD??) a number of developers and Program and Product Mgrs.in February at the MVP Summit. I'm absolutely floored that you folks moved that fast on the Identity Management, given the discussions that we had. Obviously, this has been in the works for some time for MMS to morph. I can't say that I remember - were you there for that meeting (about 12 Server MVP's and about 10 MS folks packed into a conference room)? Rick Kingslan MCSE, MCSA, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jackson ShawSent: Thursday, July 10, 2003 1:32 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Identity Management using AD Were going to make the MV writeable. J From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT)Sent: Thursday, July 10, 2003 10:26 AMTo: '[EMAIL PROTECTED]'Subject: RE: [ActiveDir] Identity Management using AD Meaning being able to make changes in the metaview to replicate out It has not been decided. Todd -Original Message-From: Jackson Shaw [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 8:18 PMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Identity Management using AD We're going to make the MV writeable... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT)Sent: Tuesday, July 08, 2003 7:12 AMTo: '[EMAIL PROTECTED]'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 PMTo: '[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 AMTo: [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 (
RE: [ActiveDir] Identity Management using AD
Title: Message I didn't read the entire post, got a new laptop and just scanning quickly so I won't feel guilty about my community helping while wiping XP Home and loading 2k3. e. Thanks for the nod Rick. Nope I don't do things to thisdegree but it shouldn't be overly difficult to manage if you have someone who can write web code and AD code (either ldap or ADSI). The big thing would be if you can subdelegate out management to lower levels like for instance if the people are all at different companies you give one or more people in that company the ability to do things based on business rules you set up in the web code. Note there is nothing really in the native environment to do this out of the box. You will be inventing something. I am not even aware of anything for sale like this though it could exist in niche pockets. I would really recommend figuring out how these ID's are going to be used if people are doing any kind of LDAP searches against them and come up with a good scheme for OU layering and indexed uniqque attributes as it would take a bit to do a poor search across several million user objects. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick KingslanSent: Tuesday, July 08, 2003 10:12 PMTo: [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 Educationalsystem 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. TheKCC 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn CorbettSent: Tuesday, July 08, 2003 6:36 PMTo: [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, andAD shouldnt have any trouble storing the amount and type
Re: [ActiveDir] Identity Management using AD
Title: Message Funny you should mention Higher Education. We are the Govt Dept that looks after the Federal Govt (Australian, not US) Policy on them :) Well, as a result of all of this process (had the discussion today), we are going down a similar path to what I original discussed (AD for basic client repository, SQL and ADAM for application extension information). The application team has a authentication / authorisation "shim", which currently talks to a SQL database to provide the functionality. They are going to make some minor modifications to use AD as the authentication / authorisation module for this shim, so should be smooth sailing (famous last words) on point a) auditing is one thing that I didnt think of at the time, but occured to me in the middle of the discussion. Another tick in the AD column *grin* on point e) it looks like we will end up with a number of different interfaces. MMC for general admins, customised apps for app owners, web interfaces for customer self-service. The delegation model is going to be a bit hairy, as they want to perform some level of seperation of client user bases, and do little or no sharing of information (at least initially). An OU and delegation for each application groupwill probably be the best bet. on point f) they do have an additional "shim" for this A/A abstraction layer that supports passport, however even they dont want to use it...not sure exactly what that says about passport (if anything). on point g) adding these levels of authentication really isnt a huge issue (from my perspective as the infrastructure guy), however the management interfaces will (most likely) need some serious retooling to cope with multiple authentication methods (passwords, smartcards, biometrics), as the current ones are only geared for the standard username / password combination. on point h) I agree, there are some sizing / performance limitations once you start getting up the big end of town, hopefully we will be able to either a) see them and work around them, or b) never hit them. I'm doing up some scripts atm to populate AD with a bunch of information and see what holes I can fall into. Now to do some sizing / performance testing, the first application they want to put on will have up to 800,000 user objects *yay* Thanks for everyones input. G. - Original Message - From: Rick Kingslan To: [EMAIL PROTECTED] Sent: Wednesday, July 09, 2003 12:12 PM 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 Educationalsystem 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. TheKCC 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
RE: [ActiveDir] Identity Management using AD
Title: Message 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 PMTo: [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 Educationalsystem 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. TheKCC 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn CorbettSent: Tuesday, July 08, 2003 6:36 PMTo: [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, andAD 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
RE: [ActiveDir] Identity Management using AD
Title: Message 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 6:25 AMTo: '[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 PMTo: [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 Educationalsystem 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. TheKCC 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn CorbettSent: Tuesday, July 08, 2003 6:36 PMTo: [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, andAD 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
RE: [ActiveDir] Identity Management using AD
In English: Roger is saying that since ADAM will obviously be in a Windows 2003 Forest, then your points at item H are moot. WRT = With Regards To Sincerely, Dèjì Akómöláfé, MCSE MCSA MCP+I www.akomolafe.com www.iyaburo.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: [EMAIL PROTECTED] on behalf of Rick Kingslan Sent: Wed 7/9/2003 6:20 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
RE: [ActiveDir] Identity Management using AD
Title: Message 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 AMTo: [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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 6:25 AMTo: '[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 PMTo: [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 Educationalsystem 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. TheKCC 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn CorbettSent: Tuesday, July 08, 2003 6:36 PMTo: [EMAIL PROTECTED]S
RE: [ActiveDir] Identity Management using AD
Title: Message http://irm.cit.nih.gov/policy/legislation.html Here is what we have to follow. Todd -Original Message-From: Rick Kingslan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 10:12 PMTo: [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 Educationalsystem 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. TheKCC 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn CorbettSent: Tuesday, July 08, 2003 6:36 PMTo: [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, andAD 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
RE: [ActiveDir] Identity Management using AD
Title: Message 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 9:48 AMTo: '[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 AMTo: [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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 6:25 AMTo: '[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 PMTo: [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 Educationalsystem 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. TheKCC topology(KCC cannot work if (1 + #Domains) x sites^2 100,000) issue of Windows 2000 does indicate that there are i
RE: [ActiveDir] Identity Management using AD
Title: Message Todd, And sorry for you, I am. I've had to look through much of this in my time, and - with all due respect - it is truly a wonder that this beautiful country of ours gets anything accomplished at all. Yes, Freedom does have its price - and its paid for in miles of red tape. Silly, quite actually. Rick Kingslan MCSE, MCSA, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT)Sent: Wednesday, July 09, 2003 10:39 AMTo: '[EMAIL PROTECTED]'Subject: RE: [ActiveDir] Identity Management using AD http://irm.cit.nih.gov/policy/legislation.html Here is what we have to follow. Todd -Original Message-From: Rick Kingslan [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 10:12 PMTo: [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 Educationalsystem 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. TheKCC 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn CorbettSent: Tuesday, July 08, 2003 6:36 PMTo: [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, andAD 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
RE: [ActiveDir] Identity Management using AD
Title: Message Were going to make the MV writeable From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Tuesday, July 08, 2003 7:12 AM To: '[EMAIL PROTECTED]' 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
Re: [ActiveDir] Identity Management using AD
Title: Message ADAM does not include a kerberos or NTLM subsystem, so security is limited. --Sent from my BlackBerry Wireless Handheld - Original Message - From: ActiveDir-owner Sent: 07/09/2003 08:03 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 9:48 AMTo: '[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 AMTo: [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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 6:25 AMTo: '[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 PMTo: [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 Educationalsystem 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 h
RE: [ActiveDir] Identity Management using AD
Title: Message I'm not sure that I would say that security is limited - authentication TO ADAM isa limited feature - supportspassword authentication to the user objects. You can bind as a Windows Principal or as an ADAM principal. Password and lockout policy will apply from the machine on which ADAM is installed. So ifpolicy isset at your Domain level and this is a member server, that's what applies. And, the connection for the bind has a signing option and an encryption option. Authorization is available on,and to objects using DSACLS for granting and denying permissions. Inheritance works, and the effective permissions can be viewed, again with DSACLS. So, on the surface, it might be easy toconclude that the security is limited, but in actuality - the only thing missing is Kerberos and NTLM - neither of which is really needed for what ADAM is intended for. Hence, AD-lite, not Security-lite. Rick Kingslan MCSE, MCSA, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]Sent: Wednesday, July 09, 2003 7:25 PMTo: ActiveDirSubject: Re: [ActiveDir] Identity Management using AD ADAM does not include a kerberos or NTLM subsystem, so security is limited. --Sent from my BlackBerry Wireless Handheld - Original Message - From: ActiveDir-owner Sent: 07/09/2003 08:03 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 9:48 AMTo: '[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 AMTo: [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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger SeielstadSent: Wednesday, July 09, 2003 6:25 AMTo: '[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 PMTo: [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 Educationalsystem 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, gre
RE: [ActiveDir] Identity Management using AD
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 PMTo: '[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 AMTo: [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
RE: [ActiveDir] Identity Management using AD
Title: Message I've been told that MIIS is really just MMS 3.0 renamed. The description of the software would seem to indicate so. Is this true? Mike Thommes Argonne National Laboratory -Original Message-From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED]Sent: Tuesday, July 08, 2003 9:12 AMTo: '[EMAIL PROTECTED]'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 PMTo: '[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 AMTo: [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
RE: [ActiveDir] Identity Management using AD
Title: Message Mike, You're basically correct, although the renaming of MMS is accompanied by a broader IM strategy incorporating other products, services, and partnerships. MSFT is going to spell it out at Catlyst this week (today I think). IM has become a strategic issue for MSFT, partly because IM provides a more sellable benefit that Active Directory can provide to customers. "Improved TCO" wasn't a strong enough reason for getting people to make the leap to AD. -gil -Original Message-From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 8:57 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Identity Management using AD I've been told that MIIS is really just MMS 3.0 renamed. The description of the software would seem to indicate so. Is this true? Mike Thommes Argonne National Laboratory -Original Message-From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED]Sent: Tuesday, July 08, 2003 9:12 AMTo: '[EMAIL PROTECTED]'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 PMTo: '[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 AMTo: [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
RE: [ActiveDir] Identity Management using AD
Title: Message Yes it is a new Architecture product from MMicrosoft. The next question should be does it use IIS? Todd -Original Message-From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 11:57 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Identity Management using AD I've been told that MIIS is really just MMS 3.0 renamed. The description of the software would seem to indicate so. Is this true? Mike Thommes Argonne National Laboratory -Original Message-From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED]Sent: Tuesday, July 08, 2003 9:12 AMTo: '[EMAIL PROTECTED]'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 PMTo: '[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 AMTo: [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
RE: [ActiveDir] Identity Management using AD
Title: Message According to the Technical Overview of Microsoft Identity Integration Server 2003 whitepaper, MIIS 2003 is the third major release of Microsoft's metadirectory product. This would mean that, yes; MIIS is indeed the next version of the MMS product. http://www.microsoft.com/windowsserver2003/techinfo/overview/miis.mspx -Original Message- From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 12:02 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Identity Management using AD Yes it is a new Architecture product from MMicrosoft. The next question should be does it use IIS? Todd -Original Message- From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 11:57 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Identity Management using AD I've been told that MIIS is really just MMS 3.0 renamed. The description of the software would seem to indicate so. Is this true? Mike Thommes Argonne National Laboratory -Original Message- From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 9:12 AM To: '[EMAIL PROTECTED]' 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
RE: [ActiveDir] Identity Management using AD
Title: Message My spell checker broke my joke... I ment to say Marchitecture. As in Marketing Architecture. I think the who IIS part is just a bad thing.. Todd -Original Message-From: Myrick, Todd (NIH/CIT) Sent: Tuesday, July 08, 2003 1:02 PMTo: '[EMAIL PROTECTED]'Subject: RE: [ActiveDir] Identity Management using AD Yes it is a new Architecture product from MMicrosoft. The next question should be does it use IIS? Todd -Original Message-From: Thommes, Michael M. [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 08, 2003 11:57 AMTo: [EMAIL PROTECTED]Subject: RE: [ActiveDir] Identity Management using AD I've been told that MIIS is really just MMS 3.0 renamed. The description of the software would seem to indicate so. Is this true? Mike Thommes Argonne National Laboratory -Original Message-From: Myrick, Todd (NIH/CIT) [mailto:[EMAIL PROTECTED]Sent: Tuesday, July 08, 2003 9:12 AMTo: '[EMAIL PROTECTED]'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 PMTo: '[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 AMTo: [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
Re: [ActiveDir] Identity Management using AD
Title: Message 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, andAD 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 PMTo: '[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 AMTo: [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, howeve
RE: [ActiveDir] Identity Management using AD
Title: Message 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 Educationalsystem 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. TheKCC 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, MCTMicrosoft MVP - Active DirectoryAssociate ExpertExpert Zone - www.microsoft.com/windowsxp/expertzone From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glenn CorbettSent: Tuesday, July 08, 2003 6:36 PMTo: [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, andAD 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
RE: [ActiveDir] Identity Management using AD
Title: Message 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 AMTo: [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
RE: [ActiveDir] Identity Management using AD
Title: Message A lot of new info on MIIS has been published since the announcements: www.microsoft.com/MIIS The RTM software will shortly be available for download from the MSDN Universal web site and on MSDN Universal CDs in September. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Monday, July 07, 2003 2: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
Re: [ActiveDir] Identity Management using AD
There is a MS moderated MMS mailing list on yahoo.It has no authentication service or directory of its own, so you will need to plan around that or perhaps use one of the planned ISV solutions.--Sent from my BlackBerry Wireless Handheld - Original Message - From: ActiveDir-owner Sent: 07/03/2003 10: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
[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
