SPS and Renaming AD Accounts
We've been seeing some strange behaviour after we rename
a group or user in the Active Directory:
When we go to the Site Settings to define site-wide
permissions, the old username is still displayed. If we
remove it and then add it again, we see the new name in
the Choose Group list - but after we add it, it's shown as
the old group. Humorous, but harmless.
The bigger problem is when you give such a group
permissions on a specific area or list. If we try to
remove the old name from the permissions list, we get an
ID Not Found error . When we try to add the new group to
the permissions list, we get a Group Not Found
error.
All this is caused by SPS storing user data in the
UserInfo table in the DB - it caches the old usernames,
and for some reason uses that as the key when trying to
add/remove groups to Areas, rather than the SID (which is
also saved for every entry).
The solution we found for this was to manually change the
UserInfo entry, or better yet - erase it and let SPS
recreate it when we add the group again. Naturally, it's
not something we want to be doing in a production DB.
Another minus is that the ACLs for various areas and lists
point to the UserInfo row, not directly to the AD. This is
a good thing generally, but means that once we erase the
old entry, it's erased from all ACLs - we have to go and
give that group/user permissions again. If this is a
working server, we probably don't want to do that, and
we'll just change the tp_Login field - leaving room for
typos and human error.
Anyone know why SPS doesn't re-cache the Username from
the AD when it changes? It DOES keep the SID for each
entry, so it does have the AD entity's unique key - it
should use this, and keep the Login name purely as a
cache.