sAMAccountName

  • Thread starter Thread starter Nick
  • Start date Start date
N

Nick

Why I can create a user with an ADSI script in a Server 2003 domain
WITHOUT specifying the sAMAccountName attribute?

Creating a user called User99 in this way, then checking the 'User Logon
Name (pre-Windows 2000)' with ADUC I see that the OS has defined
$9J2000-F2RTQRTA7C5F for the sAMAccountName. You can logon with this
name, but not apparently as User99.

The attribute is still described as Mandatory for the user class in the
Schema Manager, so presumably that's why the OS creates a value for it.

Yet you cannot create a user without specifying the User Logon Name
(pre-Windows 2000) with ADUC.

What is the rationale for this behaviour?

Nick
 
I don't know from where AD is creating that UserLogonName, just specify that
attrbute when using ADSI,
Alvaro N.
 
Win2K3 AD will create sAMAccountName for you if you don't specify it. Win2K
AD does not. However, if you don't like the name that it gives you, it is
probably a good idea to continue setting it explicitly.

Joe K.
 
Joe said:
Win2K3 AD will create sAMAccountName for you if you don't specify it. Win2K
AD does not. However, if you don't like the name that it gives you, it is
probably a good idea to continue setting it explicitly.

Joe K.
Click to expand...
Agreed. But why does ADSI allow me to even create the user without
specifying sAMAccountName?

Nick
 
This is a feature of Win2K3, so any API will allow you to do the same thing.
If you don't specify sAMAccountName, it is created for you by the directory.
In Win2K AD, an error is returned instead. The underlying ADSI API isn't
doing anything special though.

Am I answering your question?

Joe K.
 
Joe said:
This is a feature of Win2K3, so any API will allow you to do the same thing.
If you don't specify sAMAccountName, it is created for you by the directory.
In Win2K AD, an error is returned instead. The underlying ADSI API isn't
doing anything special though.

Am I answering your question?

Joe K.
Click to expand...

Yes Joe.

MSDN says...

"Beginning with Windows Server 2003, sAMAccountName is an optional
attribute. The server will create a random sAMAccountName value if none
is specified."

I still wonder why the schema shows the attribute as mandatory!

Cheers,

Nick vW
 
Because it's still mandatory. It's optional from the point of view that you
don't have to add it explicitly - but if you don't, you'll get a default
name ;-)


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


Joe said:
This is a feature of Win2K3, so any API will allow you to do the same
thing.
If you don't specify sAMAccountName, it is created for you by the
directory.
In Win2K AD, an error is returned instead. The underlying ADSI API isn't
doing anything special though.

Am I answering your question?

Joe K.
Click to expand...

Yes Joe.

MSDN says...

"Beginning with Windows Server 2003, sAMAccountName is an optional
attribute. The server will create a random sAMAccountName value if none
is specified."

I still wonder why the schema shows the attribute as mandatory!

Cheers,

Nick vW
 
There are a bunch of hard-coded rules in AD that are enforced to allow it to
work the way it needs to, and these often go beyond what the schema is
capable of expressing. For example, objectSID is required for all security
principals, but you don't set that yourself either.

Additionally, some of the attributes can only contain a narrow range of
values, but the schema itself can't express that. For example,
sAMAccountName has to be unique on the domain and is limited to 20
characters for users and 64 groups and very narrow range of characters, but
the schema suggests that it can be any string between 1 and 64 characters.

ADAM tends to be more "pure" with the schema, but it also does some things
like this under the hood to support the directory logic.

Joe K.
 
That's a damned side more comprehensive than my answer <g>

Excellent, informative answer.

--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


in message There are a bunch of hard-coded rules in AD that are enforced to allow it to
work the way it needs to, and these often go beyond what the schema is
capable of expressing. For example, objectSID is required for all security
principals, but you don't set that yourself either.

Additionally, some of the attributes can only contain a narrow range of
values, but the schema itself can't express that. For example,
sAMAccountName has to be unique on the domain and is limited to 20
characters for users and 64 groups and very narrow range of characters, but
the schema suggests that it can be any string between 1 and 64 characters.

ADAM tends to be more "pure" with the schema, but it also does some things
like this under the hood to support the directory logic.

Joe K.
 
Joe said:
There are a bunch of hard-coded rules in AD that are enforced to allow it to
work the way it needs to, and these often go beyond what the schema is
capable of expressing. For example, objectSID is required for all security
principals, but you don't set that yourself either.

Additionally, some of the attributes can only contain a narrow range of
values, but the schema itself can't express that. For example,
sAMAccountName has to be unique on the domain and is limited to 20
characters for users and 64 groups and very narrow range of characters, but
the schema suggests that it can be any string between 1 and 64 characters.

ADAM tends to be more "pure" with the schema, but it also does some things
like this under the hood to support the directory logic.

Joe K.
Click to expand...
Thank you Joe, NOW I understand.

Nick
 
Back
Top