Understood. I'm just asking questions actually. I've worked for some companies that had a unique db, similar to what Joe is talking about for linking ID's etc. Worked fine for 100K + users, but could easily become an animal in its own right. I've also worked in some companies where there were far fewer consumers, but many systems that had a much harder time dealing with the situation. Not technical, but more of a layer-8 issue.
In Marcus' case, it still boils down to a unique and authoritative identifier, which it sounds like he doesn't have. It also has to flow back up to the MAD process (mergers, acquisitions, and divestitures) to make sure that those processes can absorb the process. I would expect that it would be more for the mergers/acquisitions, and divestitures would cause the unique id's to be archived permanently. This allows for searches etc at a later time as well as users coming back onto the mother ship. It boils down to a unique identifier to represent wetware whether FTE, contract, or other cases not covered that persists and transcends name changes, job changes, and so on. In a mixed environment, AD GUID won't always work in some cases (field's too long for some systems oddly enough and may require a lot of reworking of code to make it work.) Tougher to deal with if that process infrastructure is not in place and you already have many identity stores. Doesn't help if your process is whacked as well, trust me :| Interesting thread... -ajm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Renouf, Phil Sent: Friday, March 04, 2005 1:59 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question One of the companies that I worked at in the not too distant past keyed all of that off the Employee number. When they created accounts in AD the EmployeeID was included somewhere in the user setup so that it was veiwable in the ADUC GUI and was queryable using management tools. It didn't matter what the user changed their name to everything went back to the HR database which held the employee number. This also let them update the information in various repositories based on the UserID (including AD), but it meant that the provisioning process required a valid EmployeeID in order for an account to be setup. That also meant that there was an EmployeeID scheme for Contractors and other non-permanent employees was devised. Not a bad approach, it worked fairly well and like Joe's company this was a fairly large employee base (>60k) so it should work ok in other companies. Phil -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Friday, March 04, 2005 1:41 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question How did they handle people changing their names? I see the ID, but does that ID make sense when the user changes their name from Joe to 'They' or something along those lines? That goes back to the idea of coming up with a unique identifier that expands the horizon beyond the AD forest(s) and into the rest of the realm. I maintain that at some point in just about every country and every company, there is a unique identifier that ensures that person gets their proper compensation. Not that it couldn't be messed up, but you'd know quickly if your paycheck were lower than expected or paid to you in Yuan vs. Rubles if that's what you expected. This needs to stretch beyond AD from what I can tell. Is that an incorrect assumption Marcus? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, March 04, 2005 1:27 PM To: [email protected] Subject: RE: [ActiveDir] LDAP and related Exchange question I would tend to agree, I think objectGUID would be fine though it is a pain to deal with since it is binary. Another thing to consider is to stop the random wonton creation of samaccountnames. When someone gets hired, they get assigned from one source their ID for use within the company. That ID is used everywhere and forever identifies that person and is never reused anywhere else in that company. Someother company gets merged in, everyone gets new SAM IDs from the same source. One company I worked for I am the only and will always be the only jricha34 to ever be there. If I somehow for some reason go work on that network again I will get spun up a jricha34 ID for use. This is a company with hundreds of thousands of users and huge turnover every year and they still maintain all of those unique identifiers even if the actual NT or mainframe IDs are deleted so I know it is feasible for smaller companies. There was another single source for UIDS if you needed them and if you lost and got access to UNIX again, it would be with the same UID. joe -----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/
