SharePoint Account Management using SPUserUtil - Part 5 - Handling NT Login Name Changes

  • Article

SharePoint Account Management using SPUserUtil - Part 5 - Handling NT Login Name Changes

Originally Posted as: Using SPUserUtil to update accounts when the NT Login Name changes .Because of a ton of recent queries on this exact subject, I'm re-posting it but also re-titling it to include it in the "SharePoint Account Management using SPUserUtil..." series.

Note: SPUserUtil will mean either WSSUserUtil or SPSUserUtil respectively (WSSUserUtil is used to administer Windows SharePoint Sites on a standalone WSS Farm/Virtual server OR Windows SharePoint sites in the same virtual server of a SharePoint Portal Server 2003 site.) SPSUserUtil is a superset of WSSUserUtil, designed for working on SharePoint Portal Server Areas.

Consider the following:

  • We have an account named MYDOMAIN\margie.murphy.

  • This account has permissions on various SharePoint sites.

  • This accounts NT Login Name changes to MYDOMAIN\margie.richie for one of many different reasons (In our scenario, Margie married a really cool guy with the last name of Richie :))

The problem with this, is that the tp_Login column in the UserInfo table for every site collection in which Margie has permissions, is cached with her previous NT Login Name. There is also no way to update this information with a SPUser object from the SharePoint object model, and SharePoint does not synchronize this from Active Directory once the users is added to a web in the Site Collection. 

The only time that SharePoint will automatically update the tp_Login column, is if the users is completely removed from the site collection. The tp_Deleted column is then set for the user in that site collection. On the next occurrence of the user being added to a web, we gather the current information from the domain. You can however, re-sync SharePoint with the current information without removing them completely from the site collection by using SPUserUtil

To perform this action, following these steps:

  1. Prepare a SPUserUtil usermap file with a user element which has the loginname= and newloginname= attributes set accordingly.
    loginname= should be the old NT Login Name as reflected in sharepoint. newloginname= should be the new user NT Login Name.
    I actually recommend running a analyze of the site to get a complete list of all users. You can then use this file as a template.

    For example:

    WSSUserUtil –o analyze –url https://server/sites/site -usermap users.xml –asu

    Note: The –asu switch means Give me All Site Users associated on the site collection, regardless if they have any direct ACE entries on any webs.

    This will produce a listing of all users and generate the file users.xml. An additional file, users-webs.xml, will be generated that contains the web hierarchies and the location of user permissions on each web.

    Here is an example of the output (Of course, your results will be different :)).

    <?xml version="1.0" standalone="no"?>

    <!DOCTYPE SPUserUtilUserMapFile>

    <!--This file represents the user information generated and used by SPUserUtil-->

    <users>

      <user loginname="MYDOMAIN\margie.murphy" newloginname=""

            displayname="Margie Murphy" email="margie.murphy@MYDOMAIN.com"

            sid="S-1-5-21-5555555555-555555555-5555555555-1111" />

      <user loginname="MYDOMAIN\Administrator" newloginname=""

            displayname="" email=""

            sid="S-1-5-21-4444444444-555555555-5555555555-500" />

      <user loginname="MYPORTALSVR\administrator" newloginname=""

            displayname="MYPORTALSVR\administrator" email="administrator@MYDOMAIN.com"

            sid="S-1-5-21-3333333333-555555555-5555555555-500" />

    </users>

    Here is a version prepared to work on the user account in question.

    <?xml version="1.0" standalone="no"?>

    <!DOCTYPE SPUserUtilUserMapFile>

    <!--This file represents the user information generated and used by SPUserUtil-->

    <users>

      <user loginname="MYDOMAIN\margie.murphy" newloginname="MYDOMAIN\margie.richie" />

    </users>

     

  2. With this file prepared, we can utilize the -o migrate operation of SPUserUtil to update the users NT Login Name.

    Note: You are not truly migrating the user, but the MigrateUserAccount() functionality provided in Windows SharePoint Services SP2 and in the Post SP1 hotfix has a great side effect of being able to use it for NT Login Name updates. The LoginName field in the object model and in the SharePoint administration pages, is readonly. Using the MigrateUserAccount() api is the only supported way to update it.

    When running the -o migrate operation using WSSUserUtil, it will read in and process all the user elements found in the xml file.

    Note: You also have to specify the –ignoresidhistory option, otherwise the Migrate functionality will attempt to look at the target accounts SIDHistory attribute for the “source” accounts SID. This is a safety check when doing “Actual” user migrations. Since this is not a true User Migration, you'll want to specify -ignoresidhistory so this check is not performed.

    For Example:

    WSSUserUtil –o migrate –url https://myportalsvr/sites/site -usermap users.xml –ignoresidhistory

    The users NT Login Name is now updated.

Using STSADM to update accounts when the NT Login Name changes

You can also perform this same process for a SINGLE user at a time using STSADM. For SharePoint Portal Server 2003 sites, you will have to use SPSUserUtil or your own custom code, as Portal does not provide an executable to perform this feature. The Post SP1 hotfix nor the SharePoint Portal Server 2003 SP2 provide an executable to provide this functionality.

For Example:

STSADM –o migrateuser –oldlogin MYDOMAIN\margie.murphy –newlogin MYDOMAIN\margie.richie –ignoresidhistory

Now that you have the NT Login Name changed, you might want to consider updating the Display Name and Email addresses for the user in case they have changed. For this, see my follow up posting here:

If you need to do a batch of users, I personally think WSSUserUtil and SPSUserUtil is the way to go.

Hope this helps!!!

Keith Richie

Previous posts in this series:

SharePoint Account Management using SPUserUtil - Part 0 - Removing Accounts
https://blogs.msdn.com/krichie/archive/2006/05/17/600040.aspx

SharePoint Account Management using SPUserUtil - Part 1 - Cloning Accounts
https://blogs.msdn.com/krichie/archive/2006/05/17/600218.aspx

SharePoint Account Management using SPUserUtil - Part 2 - Adding Accounts
https://blogs.msdn.com/krichie/archive/2006/05/19/602057.aspx

SharePoint Account Management using SPUserUtil - Part 3 - Auditing Accounts
https://blogs.msdn.com/krichie/archive/2006/05/22/604021.aspx

SharePoint Account Management using SPUserUtil - Part 4 - Replaying Permissions and Moving Webs
https://blogs.msdn.com/krichie/archive/2006/08/03/687850.aspx

Additional Reference Material:

For more information in regards to the Schema of the Various SharePoint Tables, see the Databases section in the SharePoint Products and Technologies SDK at:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/SPPTWSSDatabases_SV01072208.asp

 

SPUserUtil is contained in the The SharePoint Utility Suite at:
https://www.microsoft.com/sharepoint/downloads/components/detail.asp?a1=724

 

For More information on the Windows SharePoint Services MigrateUserAccount() API:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/tsamSPGlobalAdminMigrateUserAccount_SV01234066.asp

 

For More information on the SharePoint Portal Server MigrateAccount() API:
https://msdn.microsoft.com/library/default.asp?url=/library/en-us/spptsdk/html/mPortalAccountMigManagerMigrateAccount2_SV01187841.asp

 

For more information on Windows SharePoint Services and SharePoint Portal Server 2003:
https://www.microsoft.com/sharepoint