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.