Managing Microsoft Windows User Passwords

This topic describes the standard operating procedure for managing Microsoft Windows user accounts in BMC Server Automation. This topic includes the packaging and deployment of local Windows users to update passwords, and the creation of compliance rules for monitoring whether or not a password is changed without approval.

This topic contains the following sections:

Before You Begin

The following sections assume you have a general knowledge of BMC Server Automation and that you are ready to perform bulk updates to the password of your local Administrator (or renamed equivalent) account.

Managing Windows user accounts in BMC Server automation

Depending on your environment, the solution outlined below may or may not work best for you. In an ideal world, your local administrator password updates happen once every 30-45 days. Using the steps outlined below, you can easily and quickly change your local administrator password and ensure that it does not get changed again until the next appointed timeframe. With the following process in place, the amount of time saved should greatly outweigh the effort.

The first step in preparing to manage a local Windows user account is to package up that user into a BLPackage. While only the password is modified in this example, any of the other attributes captured in the BLPackage can be modified and deployed as well.

Packaging a User Account

Locate the local user account you wish to manage under the Local Users server object in the Live view of a Windows server.
Right-click the user and select Add to Depot as > BLPackage.
Name the BLPackage after the account you are packaging.
Click the Browse ("...") button to specify a relevant place to save your user account BLPackage.
Verify the user account you are packaging.
Click Finish.

Modifying an Account Password

The following steps show how to modify the password of a local user with a BLPackage. While only the password field is modified, and of the other fields can be modified if additional changes are needed for the user. For example, you may want to add the user to a local group, update the full name, or specify a login script.

In the Depot, locate the user account you want to manage. Double-click the BLPackage to open it.
Because we are modifying an already existing account, change the Action from Add to Modify.
Ensure that the Boolean UpdatePassword field is set to 1, which specifies that you will be updating the password for this local user.
Double-click the Password field to reveal the browse ("...") button. Click the browse button to modify the user password.
Specify and confirm the password for this account. Optionally, you can select Enter user id/password property names, which allows you to specify an encrypted server property as the value. Click OK when finished.
Below the password field are fields for updating various user account information. Unless you want to update this information, change all of the Boolean values to 0.

The example shows the BuiltInAdmin account BLPackage
When finished, close your BLPackage.
Click Yes to save.

Deploying the User Account BLPackage

An important step in this process is to ensure that the user password gets updated within a small window of time. Using a Deploy job against a large number of servers we can quickly update the local user password and use our compliance rules to make sure that a password change has only happened between the start and end time of our deploy job.

Right-click the user account BLPackage and select Deploy.
Specify a relevant name, and optionally provide a description. For Save in, click the ellipse button and select an applicable Job Folder for the Deploy Job.
Verify that the BLPackage is being deployed and click Next.
Select the target servers where you want to update your user account password and click Next.
Select Execute job now and click Finish.

In this example, all of the Commit Options are deselected, because no rollback is possible for user password changes (previous user passwords are not stored on target hosts).
Click Finish.
Under Jobs, locate your Deploy Job to check its status.
In this example, the Deploy Job has failed against one of the target servers. In the Deploy Status window, click the red "x" to view any error messages.
Double-click any error messages under Log Messages to see a pop-up display of the message. In this case, the deployment failed against the win1 server because the password chosen in the BLPackage did not meet the minimum password policy requirements.
Locate and open your user account BLPackage in the depot and specify a password that meets your organization's password policy requirements. Re-deploy your user account deploy job and ensure successful deployment against all target servers.

The start time and end time of your job run is very important and will be used in other tasks described in the documentation. In particular, you might need to define compliance rules that state that user passwords must have a last change date between a certain timeframe. That timeframe is the start time and end time of your password update Deploy Job. After your compliance rules are in place, you will need to update them every time you re-execute this job to update the passwords on all of your Windows servers. Typically this activity should only take place every 30 - 45 days, depending on your company's security policies.

Creating Password Compliance Rules

The first step in creating compliance rules for local user passwords is to create a Component Template. This example uses this template to create a Component on each server of the local administrator account. While this is a simple example, the same ideas can easily be incorporated into a system or security policy already in place.

Under Component Templates, locate a folder in which to create your new Password Management Component Template. Right-click and select New > Component Template.
Give your Template a relevant name. Ensure that Discover and Compliance are selected. In this example you will not need Discover, Snapshot/Audit, or Remediation.
In the Parts window, click the green + to add the user account that you want to manage. Locate and select the user that you want to manage and move it to the Selected Parts area by clicking the arrow button.
Under Options, you do not need to select any of the checkboxes unless you are running Audit Jobs against your Template. At this point, since you are only performing Compliance, you do not need to select any of the boxes under Options. Click Finish.
Click Yes to edit your Component Template. Under Discover, click the Add Property Conditions icon.
Add the condition TARGET.OS equals Windows. Click OK.

Note

By adding this Discover Signature Condition, you ensure that this template will never be associated with any non-Windows servers. Optionally you could add a Part Condition that states that the BuiltInAdmin account (or any other account that you are managing) must exist. Since the BuiltInAdmin account exists on all servers in this example, do not add this condition.
Under the Compliance section, click the Add New Compliance Rule icon.
Specify a Name, Description (optional), Reference Number (optional), and any Notes (optional) related to this rule (to explain what this compliance rule is checking). Click Next.
Click Add Server Object Condition to add a condition for the BuiltInAdmin user.
Under Selection Criteria, select Local User.
Under Wildcarded Path, click the browse ("...") button and select the BuiltInAdmin user. Click OK.
Under Compliance Conditions, select the third option, At least ONE object must exist AND all objects must match the additional criteria below. For the option itself, select Last Password Change - between - <date 1> and - <date 2>, where <date 1> is the start time of your Deploy Job that updated your BuiltInAdmin user passwords and <date 2> is the end time of the Deploy Job. Click OK.
In this example, the password compliance rule will only apply to Development servers. Click the Add Property Condition button. Perform these steps if you want to limit this check to a specific group of servers based on a server property.
Select TARGET.ENVIRONMENT equals Development.

The rule now states that the BuiltInAdmin account must exist and its password must have changed within a certain timeframe and the target server must be a development server.
You can add additional rules depending on the environment. For example, if you run an Update Password Deploy Job against Development at a different time than your Production servers, you can specify the different times for each environment, as in the conditions in the following figure.

Be aware of the additional opening and closing condition brackets and the OR condition between each section.
Optionally, update your General information to reflect all of the conditions applied to this rule.

The Compliance parts and related Rule:
Close the Component Template and click Yes to save.

Component Discovery

To run a Compliance Job, you must first associate the Component Template with each Windows server by executing a Component Discovery Job. This job will use the signature defined in the Template to decide whether or not to create a Component on a server.

Right-click your user compliance Component Template and select Discover.
Specify a relevant name, and optionally provide a description. Click the browse button to specify a Job Group to save your Discovery Job. Click Next.
Verify the Component Template being used in your Discovery Job. Click Next.
Select the servers or server groups to run your Discovery Job against. Keep in mind that the Discovery condition (TARGET.OS equals Windows) will filter out any inapplicable servers. Click Next.
Optionally, add a recurring schedule by clicking the green + button. Select Execute job now and click Finish.
Once your Discovery Job completes, you should see Components for all of the Windows servers that you selected as target servers under your Component Template. (You will probably need to refresh your Component Template to see the new Components.)

In this example, you created a Component Smart Group for the BuiltInAdmin account with the condition NAME begins with BuiltInAdmin Account.

Managing Password Compliance

To create a new Compliance Job for your Component Template, right-click your Component Template and select Compliance.
Specify a relevant name and optionally provide a description. Click the ellipse button next to Save in and choose a location to save your job. Click Next.
Verify the selected Component Template and click Next.
Using the Component Smart Group that you created, add it to the list of Selected Components. You could optionally add the Components manually by browsing to the Component Template, but by adding a Smart Group you are ensuring that all Components will be analyzed by the Compliance Job. Click Next.
Optionally, add a re-occurring schedule by clicking the green + button. Select Execute job now and click Finish.
Under Jobs, locate the completed Job Run and drill down to the Server View to view compliance details on a server by server basis.

While this particular server did not pass two of our compliance rules (stating that the password must have changed within a certain timeframe if it is a Prod server), the server is compliant because of the OR condition in our rule condition logic.

The following server does not pass the test. While it is a production server, its password was not changed within the timeframe allowed.
At this point you can do one of two things:
- Add an exception to this server.
- Re-execute the Password Update Deploy Job and fix the Compliance Rule to reflect the new after and before dates.