SY0-501 Section 5.3 Install and configure security controls when performing account management, based on best practices.

Mitigate issues associated with users with multiple account/roles and/or shared accounts

Account policy enforcement

Policy enforcement is the manner in which the Server allows or disallows accounts that violate provisioning policies. When policy, person, or account data is changed, an account that was originally compliant with a provisioning policy can become noncompliant. Policy enforcement can be configured globally or for a specific service. Policy enforcement occurs whenever it is necessary in the server business process to ensure system integrity and perform appropriate actions. A provisioning policy governs the access rights for users for specific services, thus provisioning enforcement is incorporated into all server business processes that manage a user’s identity and access rights on a managed resource. All services except a few like IBM’s DSML Identity Feed services have policy enforcement available. A service’s policy enforcement can be modified at any time. When the change is made, policy enforcement will be scheduled. Note that changes made to policy enforcement action might trigger a chain of events as result of the change

Password complexity

Most users log on to their local computer and to remote computers by using a combination of their user name and a password typed at the keyboard. Although alternative technologies for authentication, such as biometrics, smartcards, and one-time passwords, are available for all popular operating systems, most organizations still rely on traditional passwords and will continue to do so for years to come. Therefore it is very important that organizations define and enforce password policies for their computers that include mandating the use of strong passwords. Strong passwords meet a number of requirements for complexity – including length and character categories – that make passwords more difficult for attackers to determine. Establishing strong password policies for your organization can help prevent attackers from impersonating users and can thereby help prevent the loss, exposure, or corruption of sensitive information. Depending on whether the computers in your organization are members of an Active Directory domain, stand-alone computers, or both, to implement strong password policies you will need to perform one or both of the following tasks:

– Configure password policy settings in an Active Directory Domain.

– Configure password policy settings on stand-alone computers.

Once you have configured the appropriate password policy settings, users in your organization will be able to create new passwords only if the passwords meet the length and complexity requirements for strong passwords, and users will not be able to immediately change their new passwords. For Windows 2000, Windows XP, and Windows Server 2003 and Windows Server 2008 there are five settings you can configure that relate to password characteristics: Enforce password history, Maximum password age, Minimum password age, Minimum password length, and Passwords must meet complexity requirements. 

– Enforce password history determines the number of unique new passwords a user must use before an old password can be reused. The value of this setting can be between 0 and 24; if this value is set to 0, enforce password history is disabled. For most organizations, set this value to 24 passwords.

– Maximum password age determines how many days a password can be used before the user is required to change it. The value of this between 0 and 999; if it is set to 0, passwords never expire. Setting this value too low can cause a frustration for your users; setting it too high or disabling it gives potential attackers more time to determine passwords. For most organizations, set this value to 42 days.

– Minimum password age determines how many days a user must keep new passwords before they can change them. This setting is designed to work with the Enforce password history setting so that users cannot quickly reset their passwords the required number of times and then change back to their old passwords. The value of this setting can be between 0 and 999; if it is set to 0, users can immediately change new passwords. It is recommended that you set this value to 2 days.

– Minimum password length determines how short passwords can be. Although Windows 2000, Windows XP, and Windows Server 2003 support passwords up to 28 characters, the value of this setting can be only between 0 and 4 characters. If it is set to 0, users are allowed to have blank passwords, so you should not use a value of 0. It is recommended that you set this value to 8 characters.

– Passwords must meet complexity requirements determines whether password complexity is enforced. If this setting is enabled, user passwords meet the following requirements:

– The password is at least six characters long.

– The password contains characters from at least three of the following five categories:

– English uppercase characters (A – Z)

– English lowercase characters (a – z)

– Base 10 digits (0 – 9)  Non-alphanumeric (For example: !, $, #, or %)

– Unicode characters

– The password does not contain three or more characters from the user’s account name.

If the account name is less than three characters long, this check is not performed because the rate at which passwords would be rejected is too high. When checking against the user’s full name, several characters are treated as delimiters that separate the name into individual tokens: commas, periods, dashes/hyphens, underscores, spaces, pound-signs and tabs. For each token that is three or more characters long, that token is searched for in the password; if it is present the password change is rejected. For example, the name “Erin M. Hagens” would be split into three tokens: “Erin,” “M,” and “Hagens.” Because the second token is only one character long, it would be ignored. Therefore, this user could not have a password that included either “erin” or “hagens” as a substring anywhere in the password. All of these checks are case insensitive. These complexity requirements are enforced upon password change or creation of new passwords. It is recommended that you enable this setting.

Password Account Lockout

Given enough time and potential to try multiple username and password combinations an attacker might eventually succeed in compromising the security of a server or other computer. Account lockout policies allow you to set thresholds to automatically shut down an account if too many incorrect username and password combinations are attempted in order to protect the machine.

Sometimes you, or other users of a server or workstation, have a hard time remembering the correct username and password. It may be from a simple typo while entering the information or it may be a result of having too many different usernames and passwords to remember. Whatever the reason, there are times when incorrect authentication information will be entered when someone is trying to log in. You don’t need to be alarmed by a single failed attempt. You probably don’t even need to be concerned about two or three attempts. At some point though you have to figure that it is no longer an honest mistake and is either a program or individual systematically trying to guess different username or password combinations to gain unauthorized access to the machine. Windows offers a way to protect the machine from such attempts through the Account Lockout Policies. By configuring the operating system to lock the account and bar access after a certain number of failed login attempts you allow the system to proactively block such attempts.

Privileges

To ease the task of user account administration, you should assign privileges primarily to group accounts, rather than to individual user accounts. When you assign privileges to a group account, users are automatically assigned those privileges when they become a member of that group. This method of administering privileges is far easier than assigning individual privileges to each user account when the account is created.

User assigned privileges

Two methods of privilege assignment prevalent today are group-based and user-assigned. As the name implies, group-based privileges are those acquired as a result of belonging to a group. User-assigned privileges are those that can be assigned by the user. For example, when you create a file in most operating systems, you can change the permissions associated with that file. It is possible, for example, to give others the privilege of only being able to read it, or to read and write to it.

User access reviews

In addition to assigning user access properly, it is important to review that access periodically. Access review is a process to determine whether a user’s access level is still appropriate. People’s roles within an organization can change over time. It is important to review user accounts periodically and determine if they still require the access they currently have. An example of such a scenario would be a network administrator who was responsible for the domain controller but then moved over to administer the remote access servers. The administrator’s access to the domain controller should now be terminated. This concept of access review is closely related to the concept of least privileges. It is important that users do not have “leftover” privileges from previous job roles.

Continuous monitoring

Another closely related topic is continuous monitoring. Continuous monitoring implies an ongoing audit of what resources a user actually accesses. This can be critical for stop- ping insider threats. For example, a human resources employee would need access to employee files. However, if that employee is accessing a given employee’s file without a valid workrelated reason, this is a security breach. Only by continuously monitoring access can you detect such breaches.