Flexibility often is annoying. However, the concept is not new, and is useful for several scenarios that require one set of credentials vs. the other. Like I mentioned earlier, your logon credentials will be reported a certain way depending on the app. If the app needs samaccountname, then that's what you'll have to give it else re-write the app. Even in NT 3-4x I could rename the samaccountname; that's not new. What is new is a way to uniquely identify identities across multiple federated security domains unlike in NT4 where you had to ensure that via your naming standards etc. Most of the workstation variables will pull the downlevel version of the logon credentials and rightfully so as they have no idea if they're in a mixed or other type of domain. Are there any other options for the app?
________________________________ From: [EMAIL PROTECTED] on behalf of Chuck Chopp Sent: Thu 8/25/2005 11:50 AM To: [email protected] Subject: Re: [ActiveDir] UPN vs. SAM Account Name joe wrote: >>what would be considered a valid reason for having them be different? > > > The fact that they are different is a valid reason. Someone decided they > wanted them to be different. Making them the same is more of a convenience > and to reduce confusion. By default, no UPN is set when creating a user > object. Some tools will force the population of the attribute. If it isn't > specifically populated, it is still available though. > > Also note that with K3 AD, you do not have to specify the sAMAccountName and > AD will autogenerate one. At that point, you better have a different easier > to recall UPN because the sAMAccountName isn't something you will want to > type in all the time. Interesting. I need to do some more testing with the AD tree at various functional levels. Right now, if I logon to my test 2K3 DC [only DC for the test tree, set to Win2K native mode], regardless of whether I use the SAM account name or the UPN, all of the downl-level API functions report my username as being the SAM account name, which is as expected. The USERNAME environment variable is also set to the SAM account name. I'll test with it set to 2K3 Native mode and see how the SAM account name is used and whether it or the base portion of the UPN gets returned by any of the down-level API functions. It's somewhat annoying to have multiple account naming attributes that can be used in terms of how the user identifies themselves at logon time. If a UPN isn't mandatory and uniqueness of UPN values is not enforced by AD itself, and the SAM account name attribute is only forced to be unique within a domain, it makes it difficult to figure out which one of these naming attributes' values should be used when linking to an external system. > > Why can't the external repository link via the GUID? It doesn't store binary > or can't convert to the GUID binary format when looking back? If that is the > case, add a custom attribute and populate it with the text form of the GUID > and link on that. Using the GUID may not be an option. This isn't a restriction that I've imposed, it's a restriction on the external system itself. It pre-dates the use of a GUID to uniquely identify a user account and may not be customizable. -- Chuck Chopp ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com RTFM Consulting Services Inc. 864 801 2795 voice & voicemail 103 Autumn Hill Road 864 801 2774 fax Greer, SC 29651 Do not send me unsolicited commercial email. 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/
<<winmail.dat>>
