| Author | Messages | |
AD000001239
Posts:0
 | | 08/25/2005 11:59 AM |
| Knowing that it is strongly recommended that the username portion of the UPN
and the SAM Account Name should be identical, what would be considered a
valid reason for having them be different? And, if they were deliberately
being set to different values, when it comes to naming a home directory for
the user, would you be more likely to name the home directory after the UPN
or the SAM Account Name?
My choice would be to key on the UPN, but I'm wondering if there's any
reason to do it a different way.
The reasoning behind the question... I'm monitoring changes to the UPN and
SAM Account Name attribute values on user objects for purposes of updating
user-specific storage on a server as well as updating other information
external to AD that is linked to the user. Given that the user's object DN
is irrelevant during a rename operation due to the fact that the "before"
value never gets reported with with "after" value, all I can key on for a
rename of a user object is the possibility that the UPN and/or the SAM
Account Name might get changed as part of the rename. The Display Name
isn't suitable for use in linking to the external information, and the
external information reposity can't really be modified to link via the user
object's GUID value, so using the UPN or SAM Account Name are really the
most viable options.
--
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/ | | | |
| listmail
Posts:822
| | 08/25/2005 3:09 AM |
| > 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.
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.
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Chuck Chopp
Sent: Thursday, August 25, 2005 7:59 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] UPN vs. SAM Account Name
Knowing that it is strongly recommended that the username portion of the UPN
and the SAM Account Name should be identical, what would be considered a
valid reason for having them be different? And, if they were deliberately
being set to different values, when it comes to naming a home directory for
the user, would you be more likely to name the home directory after the UPN
or the SAM Account Name?
My choice would be to key on the UPN, but I'm wondering if there's any
reason to do it a different way.
The reasoning behind the question... I'm monitoring changes to the UPN and
SAM Account Name attribute values on user objects for purposes of updating
user-specific storage on a server as well as updating other information
external to AD that is linked to the user. Given that the user's object DN
is irrelevant during a rename operation due to the fact that the "before"
value never gets reported with with "after" value, all I can key on for a
rename of a user object is the possibility that the UPN and/or the SAM
Account Name might get changed as part of the rename. The Display Name
isn't suitable for use in linking to the external information, and the
external information reposity can't really be modified to link via the user
object's GUID value, so using the UPN or SAM Account Name are really the
most viable options.
--
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/
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/ | | | |
| AD000001239
Posts:0
| | 08/25/2005 3:56 AM |
| 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/ | | | |
| Alm@xxxx.yyy
| | 08/25/2005 4:29 AM |
| ________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Chuck Chopp
Sent: Thu 8/25/2005 11:50 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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/
> | | | |
| AD000001239
Posts:0
| | 08/25/2005 6:02 AM |
| 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/ | | | |
| AD000001012
Posts:0
| | 08/25/2005 9:20 AM |
| Hi Chuck,
Some comments.
I would not think the SAM account name and UPN as "downlevel" and "new world", but rather a short logon name and a long logon name, even though the former one is called "pre-Windows 2000".
I like to have UPNs the same as e-mails firstname.lastname@etc., and the SAM account name could be LASTNFI2, for example. The first one is clear, but long to type (especially for juan.carlos.rodriquez@xxxxxxxxxxxxxxxxxxx). The second one is nice in profile and home folder names and short to type.
The SAM account name is mandatory in old and new AD, but the new has the option of auto-generation.
UPN is optional, although ADUC requires one if you create a user with it.
The SAM account name must be unique in a domain, UPN must be unique in a forest. You can violate this uniqueness, if you create two users at the same time (within replication latence) on two DCs. In that case, however, neither user can log on.
Even though the SAM account name is only unique in a domain, if you prepend the domain name, you obviously get wider uniqueness (the traditional DOMAIN\BillG format). Perhaps this works for your application? That gives uniqueness, but of course is not guaranteed to remain always the same (only the GUID does that).
If you remove the braces and dashes of the string rep of the GUID, it's just a string of numbers and letters. Would that work for your application?
The ACL Editor displays a different selection of names in each dialog box:
- If you add a trustee and type a name, which has more than one match, you can select the trustee in a list that shows the RDN/CN, SAM account name, and e-mail address of the users.
- After you pick one, the selected user is shown with his RDN/CN and UPN.
- If after a while, you open ACL Editor again to see the permission list, ACL Editor displays the display name and UPN, and not RDN/CN anymore.
Yours, Sakari
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Chuck Chopp
> Sent: Thursday, August 25, 2005 9:02 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] UPN vs. SAM Account Name
>
> 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/
>
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/ | | | |
| Alm@xxxx.yyy
| | 08/25/2005 12:19 PM |
| ________________________________
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Chuck Chopp
Sent: Thu 8/25/2005 7:59 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: [ActiveDir] UPN vs. SAM Account Name
Knowing that it is strongly recommended that the username portion of the UPN
and the SAM Account Name should be identical, what would be considered a
valid reason for having them be different? And, if they were deliberately
being set to different values, when it comes to naming a home directory for
the user, would you be more likely to name the home directory after the UPN
or the SAM Account Name?
My choice would be to key on the UPN, but I'm wondering if there's any
reason to do it a different way.
The reasoning behind the question... I'm monitoring changes to the UPN and
SAM Account Name attribute values on user objects for purposes of updating
user-specific storage on a server as well as updating other information
external to AD that is linked to the user. Given that the user's object DN
is irrelevant during a rename operation due to the fact that the "before"
value never gets reported with with "after" value, all I can key on for a
rename of a user object is the possibility that the UPN and/or the SAM
Account Name might get changed as part of the rename. The Display Name
isn't suitable for use in linking to the external information, and the
external information reposity can't really be modified to link via the user
object's GUID value, so using the UPN or SAM Account Name are really the
most viable options.
--
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/
> | | | |
|
|