Anyone familiar with the systems management software formerly known as Systems Management Server (now Configuration Manager) probably remembers that permissions were usually granted to users or groups using their names rather than SIDs. This led to troublesome situations when, after changing the name of an object in AD, permissions "disappeared" from the users' point of view. What is the situation today?
When you look at the permissions stored in the Security tab of an object, you will notice there the names of the accounts and the permissions assigned to them, pertaining to the object.
Fig. 1. List of authorized object - SECURITY tab
Of course, permissions are actually stored in SQL database tables
Figure 2: List of administrative users, stored in the RBAC_ADMINS table
And here we have the first surprise. In addition to the name (LogonName field), we also have in hexadecimal form the SID of the account (AdminSID field). This allows us to assume that currently permissions are granted on the SID of the account, and not just on its name. A simple experiment allows us to verify this supposition. If the permission is bound only to the name of the account, then when the name is changed in AD, object permissions inside Configuration Manager will be lost; if the permission is bound to the SID, such a phenomenon will not occur
The new collection (TEST-PERM3) created in the console has permissions assigned to the JanTest user account.
Figure 3 Administrative account information
A JanTest user can launch the console and it shows TEST PERM3 as the only collection.
Fig. 4. The JanTest user sees one collection in the console for which he has permissions
Once the user is renamed to JohnChanged, he can run the administration console with the new credentials without any problems:
Fig. 5. Running the console on a user account (RUN AS)
The console continues to show the collection to which it has permissions:
So the permissions remain, although the Security tab preview continues to show the username before the renaming:
Figure 6: List of collection permissions
So the user no longer loses privileges as a result of renaming the account. You also don't need to take action on the Configuration Manager side after renaming an account in AD.
A patient administrator will notice that after a certain period of time, the information about an account with permissions will "switch" automatically to the new value. The SMS_HIERARCHY_MANAGER component service is responsible for this, checking the names of administrative users, updating the entries if necessary. The configuration parameter of this User Info Scan Interval service defaults to 86400 (a value in seconds, indicating the daily frequency).