Al Mulnick wrote:
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.
Well, it's really all one set of credentials in terms of which user object in AD is actually being used to logon. It's just that there's multiple naming attributes being used to identify which user object is to be used for authentication & logon.
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.
I understand the use of a GUID as a constant unique identifier that exists for the lifetime of the object regardless of whether it is renamed or moved to a new container. This is highly desirable when you need to maintain those external linkages with other repositories. If the GUID could readily be used with this particular application I would do so.
The fact that the UPN is optional, can be duplicated [with adverse affects] but should be unique, combined with the SAM account name being mandatory in older versions of AD but auto-generated in later versions of AD with the requirement that it be unique within a domain and preferrably unique in the tree/forest, makes is difficult to just pick the UPN over the SAM account name in terms of which one is used to link user objects to entries in external repositories.
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.
Beyond the obvious down-level API functions and things like the USERNAME environment variable, other more subtle issues exist, such as what names are displayed when using the Explorer to modify the NTFS permissions. The user object's display name is shown along with the UPN following it in parenthesis, but the SAM account name is not displayed. So, the GUI is at least aware that it's in an AD-enabled environment and it takes the time to convert backwards from a SID [in the DACL in the SD on the file] to the display name & UPN. The DsCrackNames() function is most likely being used to perform the name conversions
Are there any other options for the app?
I'll keep investigating it further. -- 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/
