Displayed account name and sAMAccountName

[Thierry Philipovitch]

Hi all,

We have a BIG problem with SharePoint Portal Server 2003.

here's the context:
- a sharepoint Portal server 2003 in a forest AD (Windows 2003)
- another forest, container of the users accounts. These accounts were
created using
a script where only the user's UPN was specified. The attribut
sAMAccountName is thus initialized by the OS
(Windows 2003). So it takes the form of a characters string like
$60E000-OGAC1M72NGAU.
This attribute was not initialized by the script so d'éviter with most
possible the conflicts of name (there are approximately 10000 users). UPN
corresponds to email, which is "localised" (a UPN by site), thus
reducing the conflicts in our case to nothing.
- There is a trust between the first and the second forest, which allows us
to register the users of the
second forest in the SharePoint Portal.

Here's the problem: SharePoint uses the sAMAccountName attribut as name of
account,
which makes some administration tasks very difficult (it is necessary to
find who is $60E000-OGAC1M72NGAU ! for example).
Another example: in the forum, if a user posts a message, it is his
sAMAccountName ($60E000-OGAC1M72NGAU)
which is displayed as author's name!

So my first is question:
How can we do so that Sharepoint uses the user's UPN rather than the
sAMAccountName attribut when displaying account name?

One could possibly make a script to change the sAMAccountName attribut of
already created users,
and match it to the UPN value for example, but we will certainly exceed the
20 characters limit
imposed by the SAM base.
So my second question is:
Within the framework of AD (there are only Windows 2003 Servers and XP
clients), can we use sAMAccountName of more than
20 characters (in AD, I believe the limit is 256 characters)? Which problem
that can generate ?

Thanks a lot in advance

[Mike Walsh]

This question has nothing to do with SharePoint Team Services which is a
completely different product.

Will people please remove the .teamservices newsgroup from their replies !

(This message follows up to all the SPS newsgroups listed, although I - as
an outsider to the SPS newsgroup structure - would say that only the main
SPS newsgroup is necessary for this question.)

Mike Walsh, Helsinki, Finland
STS FAQ at http://www.collutions.com/Lists/FAQ
WSS FAQ at http://wss.collutions.com
Please post questions to the newsgroup only.

Post by Thierry Philipovitch
Hi all,
We have a BIG problem with SharePoint Portal Server 2003.
- a sharepoint Portal server 2003 in a forest AD (Windows 2003)
- another forest, container of the users accounts. These accounts were
created using
a script where only the user's UPN was specified. The attribut
sAMAccountName is thus initialized by the OS
(Windows 2003). So it takes the form of a characters string like
$60E000-OGAC1M72NGAU.
This attribute was not initialized by the script so d'éviter with most
possible the conflicts of name (there are approximately 10000 users). UPN
corresponds to email, which is "localised" (a UPN by site), thus
reducing the conflicts in our case to nothing.
- There is a trust between the first and the second forest, which allows us
to register the users of the
second forest in the SharePoint Portal.
Here's the problem: SharePoint uses the sAMAccountName attribut as name of
account,
which makes some administration tasks very difficult (it is necessary to
find who is $60E000-OGAC1M72NGAU ! for example).
Another example: in the forum, if a user posts a message, it is his
sAMAccountName ($60E000-OGAC1M72NGAU)
which is displayed as author's name!
How can we do so that Sharepoint uses the user's UPN rather than the
sAMAccountName attribut when displaying account name?
One could possibly make a script to change the sAMAccountName attribut of
already created users,
and match it to the UPN value for example, but we will certainly exceed the
20 characters limit
imposed by the SAM base.
Within the framework of AD (there are only Windows 2003 Servers and XP
clients), can we use sAMAccountName of more than
20 characters (in AD, I believe the limit is 256 characters)? Which problem
that can generate ?
Thanks a lot in advance

[Burke]

Have you come across a solution to this issue yet? I may be having a similar
problem at a client site:
ForestB (SPS 2003) is used as an Extranet. There is a one way Trust that
allows ForestB to Trust ForestA. This is allowing internal users to
authenticate to the SPS server.. However, when we import users from ForestA
to the sites, only their login ID is carried over so we have to manually
enter their Display name and e-mail address. In addition to that, when that
users is given access to Sites on the SPS server, only their login ID is
carried over again??!! So we have to manually enter (again) the Display Name
and e-mail address. :(

-- Burke

Post by Thierry Philipovitch
Hi all,
We have a BIG problem with SharePoint Portal Server 2003.
- a sharepoint Portal server 2003 in a forest AD (Windows 2003)
- another forest, container of the users accounts. These accounts were
created using
a script where only the user's UPN was specified. The attribut
sAMAccountName is thus initialized by the OS
(Windows 2003). So it takes the form of a characters string like
$60E000-OGAC1M72NGAU.
This attribute was not initialized by the script so d'éviter with most
possible the conflicts of name (there are approximately 10000 users). UPN
corresponds to email, which is "localised" (a UPN by site), thus
reducing the conflicts in our case to nothing.
- There is a trust between the first and the second forest, which allows us
to register the users of the
second forest in the SharePoint Portal.
Here's the problem: SharePoint uses the sAMAccountName attribut as name of
account,
which makes some administration tasks very difficult (it is necessary to
find who is $60E000-OGAC1M72NGAU ! for example).
Another example: in the forum, if a user posts a message, it is his
sAMAccountName ($60E000-OGAC1M72NGAU)
which is displayed as author's name!
How can we do so that Sharepoint uses the user's UPN rather than the
sAMAccountName attribut when displaying account name?
One could possibly make a script to change the sAMAccountName attribut of
already created users,
and match it to the UPN value for example, but we will certainly exceed the
20 characters limit
imposed by the SAM base.
Within the framework of AD (there are only Windows 2003 Servers and XP
clients), can we use sAMAccountName of more than
20 characters (in AD, I believe the limit is 256 characters)? Which problem
that can generate ?
Thanks a lot in advance

[Mike Walsh]

Again, this is absolutely nothing to do with SharePoint Team Services

Follow-ups as before (with the same rider) with new messages requested to
exclude the STS newsgroup.

Mike Walsh, Helsinki, Finland
WSS FAQ at http://wss.collutions.com
Please post questions to the newsgroup only.

Post by Burke
Have you come across a solution to this issue yet? I may be having a similar
ForestB (SPS 2003) is used as an Extranet. There is a one way Trust that
allows ForestB to Trust ForestA. This is allowing internal users to
authenticate to the SPS server.. However, when we import users from ForestA
to the sites, only their login ID is carried over so we have to manually
enter their Display name and e-mail address. In addition to that, when that
users is given access to Sites on the SPS server, only their login ID is
carried over again??!! So we have to manually enter (again) the Display Name
and e-mail address. :(
-- Burke

Post by Thierry Philipovitch
Hi all,
We have a BIG problem with SharePoint Portal Server 2003.
- a sharepoint Portal server 2003 in a forest AD (Windows 2003)
- another forest, container of the users accounts. These accounts were
created using
a script where only the user's UPN was specified. The attribut
sAMAccountName is thus initialized by the OS
(Windows 2003). So it takes the form of a characters string like
$60E000-OGAC1M72NGAU.
This attribute was not initialized by the script so d'éviter with most
possible the conflicts of name (there are approximately 10000 users). UPN
corresponds to email, which is "localised" (a UPN by site), thus
reducing the conflicts in our case to nothing.
- There is a trust between the first and the second forest, which allows us
to register the users of the
second forest in the SharePoint Portal.
Here's the problem: SharePoint uses the sAMAccountName attribut as name of
account,
which makes some administration tasks very difficult (it is necessary to
find who is $60E000-OGAC1M72NGAU ! for example).
Another example: in the forum, if a user posts a message, it is his
sAMAccountName ($60E000-OGAC1M72NGAU)
which is displayed as author's name!
How can we do so that Sharepoint uses the user's UPN rather than the
sAMAccountName attribut when displaying account name?
One could possibly make a script to change the sAMAccountName attribut of
already created users,
and match it to the UPN value for example, but we will certainly exceed the
20 characters limit
imposed by the SAM base.
Within the framework of AD (there are only Windows 2003 Servers and XP
clients), can we use sAMAccountName of more than
20 characters (in AD, I believe the limit is 256 characters)? Which problem
that can generate ?
Thanks a lot in advance