Cool. Didn't mean to imply that you were slacking in your reading duties :)
Some thoughts that come to mind with this: Some methods I've seen or considered using to deal with a multiple identity store infrastructure (AD or other) that are used in the same organization where unique identification is a good idea. I see this is as a requirement in environments where people move around and where you would need to track this identity at a later time either for historical or compliance reasons or possibly some other reason. 1) Using a pseudo-random-generated-unique id and maintain that db for the life of the systems in place Pros: All systems that use this will have unique ids, and there will be an easier time of deploying simplified sign-on later Cons: Could become a large db and application itself. It's difficult to maintain an id that works across all systems. I.e. some authentication systems have character limitations for legacy reasons etc. 2) Using AD's ObjectGUID. Put another way, using one directory as the authoritative source for a unique identifier and letting that information flow to the rest of the identity stores Pros: let's you maintain uniqueness to identify users across identity boundaries Cons: With just this as a solution, you lose historical data if the user leaves. If you base your solution on this attribute, because it is system generated, if the user leaves and returns, or just changes id's in any way, then you lose that as your key. You could shove it into another attribute, but now your logic becomes much more complex as you try to determine which attribute uniquely identifies that user AND you have to maintain that GUID somewhere in a second location to be able to persist over time. Some systems won't be able to handle the size and type of data (128-bit size is not going to fit in all identity stores by default). For a lot of people AD came later. They already have a directory service that's authoritative for their environment before AD showed up. 3) Using mail address as the unique identifier across identity stores Pros: This is expected to be unique globally (literally) with no two being identical for functioning mail domains. Cons: Still needs to be recorded somewhere as in #1 and #2. Not all identity and authentication systems can handle storing the mail addresses; modification to existing systems may have to occur. It's possible to have duplicate mail addresses, although they won't function in a mail system the way you intend them to. (There can't be two [EMAIL PROTECTED] 's if we expect for the mail to make it to the intended destination.) Not all users do nor should receive an email address. Email addresses are sometimes reused in some domains, so this would require a change in the process, behavior and expectations. With all the fuss about compliance issues in the US, Canada, and EuroUnion, why is it that companies don't make an id manufacturing program that's vendor-agnostic, unique across it's defined realm (the organization), stores 100 years of id's, and ties in with leading HR and ERP packages? Is it because such things are considered in place already? Too difficult? I'm sure a metadirectory eco-system could be used to help smooth this out, but the unique seed is still left to be built for some reason. My thoughts anyway. I'd appreciate it if somebody would blow holes in those thoughts :) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 04, 2005 9:36 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question You guys make it sound like I pop in and out of this list. I read religiously. :) Thanks again... I do have multiple identity stores, most of which is kept in sync by MIIS and force-fed to AD. However, in this unique instance, we're using keeping a few attributes of each user object in sync between directories. Problem is their directory is flat and doesn't work very well in multiple domain scenarios so really the whole problem is their directory can't handle the duplication of samAccountName. This is problematic if they present a logon dialog to the user (directory handles permissions for other applications). Since they want to try to maintain that one logon type of goal (lofty in this case) they were hoping that samAccountName was unique even though I told them many, many, many times that it was not. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 4:48 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question I think you interpreted it better than I did. He wrote back and said he was going to investigate the objectGUID path. I read it that he had multiple identity stores and need a global solution. He'll still need a way to record user habits i.e. a user leaves and returns and gets the same account issued, historical archiving of account data, etc. Either way, I hope it works out for him. -ajm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Friday, March 04, 2005 4:35 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question <snip> Some background... in all this madness to bring single-sign-on to fruition, we're running into problems finding a unique value that can be used to tie AD to other directories when extracting information from a forest. We were keying off samAccountName but found too many identical names from domain to domain. </snip> I read this as meaning that they want to find a unique id in AD that can be stored/referenced in other directories. objectGuid should work fine, assuming the "other directories" can store either the 16 bytes of guid or the string representation of it. -gil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 11:23 AM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question Good catch :) In a multiple forest scenario it would likely work. In a multiple identity store scenario (i.e. not all AD technology), likely not. It won't necessarily exist in those other stores driving you to need another unique identifier. Unless you had something else in mind that might help him? -ajm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Friday, March 04, 2005 1:13 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question Why wouldn't objectGuid be appropriate? AD generates the objectGuid attribute using UuidCreate() (or some variation) that is guaranteed with reasonable certainty to generate values that are unique across all machines, not just DCs in the forest. If you need a globally unique, immutable identifer, the objectGuid attribute should do the trick. -gil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 10:53 AM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question GUID is likely NOT an option in a multiple forest scenario or multiple identity stores. But the concept can be applied to the sphere of identity stores you have responsibility for. It's just that the system won't do it for you out of the box. So one thought that comes to mind is to inject a Cox-specific GUID into each identity store from the authoritative source(s) and then use that to find what you need programmatically. That's a bigger undertaking than you may be able to go after, but it ultimately solves the issues that are so troublesome. Some where, you have to have a unique identifier that identifies consumers of your systems. Even if it's pay codes and PO numbers (non-employees), something will need to exist at some point in the lifecycle to identify the objects uniquely. That make sense or am I way off base in understanding your problem? Al -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 04, 2005 12:37 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question Thanks for the responses guys. I wonder if using GUID is an option. :/ marcus c. oh \\.\core technologies\cox communications, inc. \\.\mvp\windows server systems\management [v] 404.847.6117 [c] 404.391.7097 ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, March 03, 2005 10:34 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question LOL. Yeah this is my life lately. :oP I actually just submitted a couple of bugs over legacyExchangeDN uniqueness possible issues with ADUC and a bug with one of the major tool makers as well which has a similar issue. The issues are unlikely but if you have enough mailboxes, the chances are you will hit issues that are simply improbable. One customer of mine did in in fact hit a dupe from something that is simply improbable. It is kind of silly because the value was never tested for uniqueness, it was just assumed because it was an unusual value. Mailbox enable a user in ADUC and set your mailNickname (alias) to something with a $ in it or any of the following chars - $^#\;/= -, you will notice that the legacyExchangeDN will have a value of blahblah/cn=userxxxxxxxx. The xxxxxxxx is a random number, user is the word user. ADUC never checks that value for uniqueness. There is another case where this occurs as well and involved when it does do a ledn uniqueness check and fails and generates a new ledn. joe ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Thursday, March 03, 2005 10:04 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question Right, and although it's possible that cdoexm has some of this built in, it's not likely (and not something I've seen in there before, although I could have missed it). As for uniqueness, the only value that's guaranteed to be unique in a forest is the GUID. If you're stepping outside of the forest boundaries, there is nothing that is "guaranteed" to be unique unless you made it that way via process and code. SMTP address should be unique, but it's not guaranteed that it will be when you try to sync, just that you'll know because you'll have a non-functioning SMTP recipient if it is non-unique. If you need to find something to use to sync with, you'll have to analyze all of the directory data in your scope and either pick something or modify some of the directories and processes to uniquely identify the wetware. Joe's up on all of this Exchange directory stuff, he should be weighing in shortly I would imagine ;) ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, March 03, 2005 9:34 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question I haven't read the blog yet - I will - but uniqueness is enforced by ADUC (or any other provisioning mechanism that has the intelligence built into it). You can certainly shove colliding values into this attribute by other means. Deji ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, March 03, 2005 5:58 PM To: [email protected] Subject: [ActiveDir] LDAP and related Exchange question I was going through the You Had Me At Ehlo blog and ran across the most recent post which describes in some detail about how uniqueness is maintained in the proxyAddresses attribute. I'm curious though... does this only apply for changes made through ADUC or does it apply to changes made through any mechanism (e.g. scripts, ldp, etc)? Here's the link: http://blogs.msdn.com/exchange/archive/2005/01/10/350132.aspx <http://blogs.msdn.com/exchange/archive/2005/01/10/350132.aspx> . Some background... in all this madness to bring single-sign-on to fruition, we're running into problems finding a unique value that can be used to tie AD to other directories when extracting information from a forest. We were keying off samAccountName but found too many identical names from domain to domain. marcus c. oh \\.\core technologies\cox communications, inc. \\.\mvp\windows server systems\management [v] 404.847.6117 [c] 404.391.7097 List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
