Working with Group Policy Preferences: Interacting with Local Accounts

As you know, client-side extensions of Group Policy technology, such as preference elements, in effect, allow you to perform most of the various scenarios that you simply cannot implement using administrative templates or security settings. Due to the fact that the entire set of group policy preferences includes 21 client side extensions (including non-working elements of application preferences), it can be concluded that practically all those operations that were solved by means of scripts can be implemented through such CSE extensions.
One of these client-side extensions allows you to manage user accounts and groups that can be found on each machine while installing the operating system itself. Such accounts have to be encountered less often, but sometimes there may be situations when you have to perform some operations for their maintenance, and knowing how to perform such maintenance will be more convenient than ever.
That's just such accounts and scenarios for their service, we are with you and stop in this article. Next, you will learn about what kind of local user accounts there are, learn something about group accounts, and how you can manage such objects using the functionality of the group policy and the local users and groups preference item. And we will begin now with

Local Account Definitions

In any case, an integral part of the company is always employees who are called users in the IT infrastructure, and on each user's computer, even before he first logs on with a domain account that is a member of some domain groups, the user will necessarily perform Sign in with your local user account that belongs to a specific local group with the appropriate rights. In principle, there are two such user accounts, namely:

• The “Administrator” account , which provides full access to manage a client computer or a server and, if necessary, assign user rights and access control permissions. This record, in any case, should be used only for tasks that require administrative credentials and the administrative access token. A strong password is strongly recommended for this account.
• The Guest account is used by those who do not have a real account on the target computer. If the user account is disabled but not deleted, he can also use the Guest account. Account "Guest" does not require a password. By default, it is disabled, but you can always turn it on if necessary. The Guest account, like any other account, can be granted rights and permissions to access objects. By default, it is included in the default Guests group and allows the user to log in locally to the target computer. Additional rights, like any permissions, can be assigned to the Guests group by a member of the Administrators group . By default, this account is disabled, and it is often recommended to leave it in this position.

With local groups, in turn, everything is much more diverse and interesting. There are as many as 29 of them. The default local groups are created automatically when you install the client operating system, as well as any isolated or member server. Belonging to a local group provides the user with the rights and capabilities to perform various tasks on the local computer. It makes no sense to describe each group, since you know perfectly well about the appointment of most of the groups, and you can easily find their description in a matter of seconds.
But now, I think it's time to move on to the next element of preference, that is, to expand the client side “Local Users and Groups” .

Using the Local Users and Groups Group Policy Preference Element

By creating preference items with this client side extension, you can create, rename, delete local user accounts, change passwords, disable user accounts, and perform other actions. In addition, if you look at the second possibility of this CSE, you can still create, rename, delete, and also change the membership in local groups.
The following examples will run scripts that will create a new local account, change the password for the local administrator account, and add several user accounts to the Administrators group.
Since we will use the same GPO Editor node for each of these scenarios, preliminary steps will need to be taken before performing the step-by-step procedures. To do this, the Group Policy Management snap-in will create a new GPO called “Group Policy Preferences - 17” , and, despite the fact that all preference items will be created in the computer’s configuration node, for simplicity This GPO links to the entire domain. Now it only remains to select the newly created GPO object and open the Group Policy Management Editor for it from the context menu.
You can go to the scripts themselves.

Scenario 1

To begin, a new account will be created, and for this, in the displayed snap-in of the Group Policy Management Editor, go to Computer Configuration \ Settings \ Control Panel \ Local Users and Groups ( Computer Configuration \ Preferences \ Control Panel Setting \ Local Users and Groups ) . Being in this node, you should call the context menu in the details pane, and then, as can be seen in the following illustration, select the “ Create ” command and then “ New User” ( New> Local User) :
')

Fig. 1. Creating a local user group policy preference item

Unlike the dialog boxes of the properties of the majority of the preference elements considered earlier, it is immediately noticeable here that this dialog box is almost completely filled with various settings. Let's try gradually in the process of creating two elements of preferences to fully understand all these settings.
With the assignments of actions of the current preference item, I think everything is clear and without words, therefore, since in the first scenario a local user account will be created, the action “ Create ” is chosen. Concerning actions, one detail should be noted: when selecting the Update action ( Update ), the SID security identifier of the account being updated does not change, but if you replace the account, in this case the SID will be assigned a new one, since the account will be deleted first , and then such accounting will be created, the properties of which you will specify. At this you should definitely pay attention.
In the User name drop-down list, you can either select an account from the list of existing ones, which is convenient when updating, replacing or deleting an existing account, or to create a new account, you can simply enter the name of the new user, which is now and will be done. In the name of such an account let it be, say, “MBeasley” .
The Rename to text box allows you to change the name of the user account defined in the previous drop-down list to the one that will be displayed in the current text field. For obvious reasons, this field is available only for the Update action, and now it, as you will soon notice in the second illustration, is simply blocked.
As you can immediately guess, the text box "Full name" (Full name ) is intended to fill in the name of the user being created. To make the name of our user immediately clear, let's call him “Michael Beasley” . In the Description text box, you can add some additional information about the user being created or modified. Let it be written about this user, for example, "New Account" .
In the following two text fields - “ Password ” and “ Confirm Password ” - you need to specify and, of course, confirm the password for the account you are creating or changing. I’ll warn you right now that you don’t need to excel with password generation. Let me explain why. You set this password in a group policy object, and group policies are stored in the shared SYSVOL folder. Therefore, by localizing the desired GPO, you can calculate the password, which will in no way have a positive effect. By the way, how to decipher such passwords, you can read in the article by Sergey Marinichev “ Once again about passwords ”. Therefore, if you plan to change passwords for any vital accounts, refrain from using preference items, but implement it in some other way. For now, the standard password used for test purposes will be simply added, that is, P @ ssw0rd .
Also in the preference item, the checkbox is immediately checked on the option “Require password change on the next login to the system” ( User must change password at next logon ), and I recommend that this checkbox remain there. The user will not lose if he changes the password for his account when he first logs on. Of course, if such a password is not even more vulnerable.
We will consider almost all of the following options in the following example, but for now I would like to dwell on the option “ Account valid expires ”. If it is necessary for the account to be created to have a lifetime, you need to uncheck this box, and then specify the expiration date of the current account in the appropriate control component, for example, we will specify January 21, 2014. We will not add any targeting for this created user, but simply move on to the following example. Here it is worth paying attention to the fact that even if the preference item is saved, the Group Policy Management Editor warns you that this password can be easily detected, the main thing, as they say, would be the desire.
The dialog box with all previously defined settings can be seen in the following illustration:


Fig. 2. Dialog box for creating a new local user account

Scenario 2

In this example, the password for the local administrator account will be changed. As you understand, it is not safe to create a permanent password using preference items, but now this is done solely for the purpose of demonstrating the functionality of group policy preferences. Now we need to create a new local user preference item where we need to select the “ Update ” action ( Update ). From the next drop-down list, select the built-in administrator account and proceed to the following fields. As you will see in the third illustration below, the Rename to text box has now become available for entering data, and we will definitely use this. Let's rename the account, say, to “TrueAdmin” and move on.
Now we will change the password for this user and to demonstrate the operation of the following options, uncheck the checkbox “ Require password change on next login ” ( User must change password at next logon ). Since the user will no longer need to change his password manually when logging in, the options “Prevent a user from changing the password” ( User password change ) and “ Password never expires ” have become available to change. You’ve probably already used these options more than one hundred times when creating domain user accounts, but (just in case) the first option prevents the user from changing their password, and he will have to live with the password you specified until you yourself Do not change, and the second removes restrictions from regular password changes. For example, set the checkbox only on the option “ Password never expires” .
If you need to disable an account of a user, for example, a guest account - no problem! Just select the checkbox for “ Disable account ” ( Account is disabled) . Also, we will not create any additional filtering, but simply click on “OK” twice to save the changes.


Fig. 3. Changing the built-in administrator account

Scenario 3

There is a third, final example in which several user accounts will be added to the “Administrators” group. In order to accomplish this task, we will use the second type of preference item from the current node - the “ Local Group ”. In the dialog box that appears, as will be seen in the illustration at the end of this scenario, there is no longer such a huge number of parameters, but there are some new controls that we will now deal with in just a few minutes.
First of all, let's consider four standard actions, where in the overwhelming majority of cases I recommend using the “ Update ” action, naturally, if you don’t need to create a new one or delete any existing local group. The action “ Replace ” ( Replace ) works by analogy with the elements of preference of local users, so before using it you should think three times whether this is necessary for you.
In the Group name drop-down list, as in the previous two examples, you can either select an existing group or create a new one. Since we need to add several users to the local admins group, we will focus on the existing groups and select the Administrators group .
If you want to give the existing group a new name, use the capabilities of the Rename to text box. It is always convenient if you have everything beautifully decorated and documented, so you can add a detailed description for your group in the corresponding text field. For example, in the description you can enter "Administrators have full, unrestricted access rights on the local computer . "
On each computer, groups of local administrators can include anything, because you cannot predict all the actions of your users. Especially for this, there are two great options: “Delete all member users for this group” ( Delete all member users ) and “ Delete all member groups for this group” ( Delete all member groups ). Using the first parameter, you delete all user accounts that belong to this group, and the second parameter, respectively, allows you to delete all groups. Naturally, both the first and second options will work out before adding members configured with this preference item.
In order to add new user and group accounts, you need to use the lowest controller, that is, the group members parameter group . This group must include both local and domain administrators, so if you deleted accounts using the appropriate checkboxes, you should click on the Add button and in the appropriate text box enter “Builtin \ Administrator” , after which click on the "OK" button . Repeat these steps with our TrueAdmin, and then add domain administrators. You can either select this group from the corresponding list, or press the F3 key and use the% DomainName% variable, then specify the name of the group, that is, the Domain Administrators , then you can save all the changes you have made. In the following illustration, you can see this dialog box:


Fig. 4. Changing Membership in the Local Administrators Group
After you have created all the required preference items, you can close the rest of the Group Policy Management Editor and update the Group Policy settings on the target computers.

Conclusion

In this article, you learned about the next Group Policy Preference Item, which allows you to work with local user and group accounts. Local user accounts that were editable were considered, and in the first two scenarios, examples of using these elements to create new and modify existing local user accounts were demonstrated.
In addition, the article also provided an example of using these Group Policy preference items in conjunction with local groups, which allows for changes in the membership of the existing local Administrators group. The most important thing when working with these elements of preference is not to forget that you need to use the password change feature with caution, since if you wish, any ill-wisher can locate such passwords.