Account management tools
As seen earlier Windows Server supports a number of powerful new command-line tools. These tools are designed to make administration tasks easier. The tools are:
- Dsadd.exe: adds objects to the directory.
- Dsget.exe: displays or gets properties of objects in the directory.
- Dsmod.exe: modifies select attributes of an existing object in the directory.
- Dsmove.exe: moves an object from its current container to a new location.
- Dsrm.exe: removes an object or the complete subtree of an object.
- Dsquery.exe: queries Active Directory for objects that match specified search criteria.
You can also use the Active Directory Users and Computers Microsoft Management Console (MMC).
Under the Action button you have the option to delegate control. This is useful if you have independent departments and you want to give them control of their part of the company computer system. To do this, organise your users and computers into OUs (this makes it easier to administer). If you click on Delegate from the Action menu, this starts the Delegation of Control Wizard and you are prompted for who you want to delegate to. Choose the users and groups and then decide the tasks you want to delegate to them.
You can also design custom tasks here if you require them.
There is a Find option that enables you can search on the attributes of user, contacts or groups. This is therefore a very powerful tool
The Find option also includes fields from Microsoft Exchange Server, because when it is installed it extends the Active Directory Schema, so Exchange attributes (fields) are available to search on.
If you want to create new Active Directory User and Computer objects, click New from the Action menu and you get a number of options. If you click Properties, the properties you can change depend on what object you pick.
To change user or group properties, click Users on the right-hand pane, then Action and then Properties. You will see options displayed:
This is useful if you want to mail a group of people and saves you logging on to your mail system, because Exchange is integrated.
Another feature in Windows Server is the ability to run and save queries. You might want to query all your temporary employees and if they have user names prefixed with t_, you could set up your query and run when required, e.g. daily, weekly or monthly. To use Queries click Saved queries in the left hand pane and you will see a menu shown:
If you click New, you have the option to create a new query or a new folder. So if you have a lot of queries you can save them in appropriately named folders making administration easier. If you click New, Query Windows prompts you for a name and description for your query. If you make these relevant, it is easier to find and reuse your query. Then you can choose which container to query. If your query is only relevant to users, then there is no point in searching the whole of Active Directory. So, if you are searching only one container, check that box to speed up your queries/searches and uncheck the others.
When you have completed the query options and clicked OK, the query will run and you will see the results shown.
Another administrative tool that comes with Windows and is useful in group policy planning and troubleshooting is RSoP (Resultant Set of Policy). It lets you know exactly which group policy settings apply to a given user or computer. First you have to create a MMC, so enter MMC at the command prompt. Then go to the file and add a snap-in, choose Resultant Set of Policy and click Add. You now have a tool you can use in logging mode to check current settings for a user or computer, or in planning mode to see the effect of a potential policy change before you implement it. The screenshot below shows this in logging mode on a user:
Planning and troubleshooting user authentication
Once user accounts have been created in Active Directory, then the users can begin using them for authentication purposes to access network resources. User accounts represent a critical component of the authentication process; without them how can you identify individuals? There are other factors that also need to be considered. One of these is domain group policy settings which affect various elements of user authentication, such as password complexity requirements and account lockout settings. Also if your environment has users running down-level operating systems they need to be able to log on to a Windows Server domain for authentication and the services that are available to them will also depend on whether they have the Active Directory client software installed. There are different modes of authentication in addition to the usual username and password.
Some environments needing a higher level of security have implemented authentication using smart cards. Each of these factors needs to be considered when you are planning the authentication strategy on your network. They can also cause problems if not set up correctly, so you will have to address this when troubleshooting user authentication.
Authentication is required to minimise the security risks that exist in any network environment. Administrators need to be very careful when planning their security strategy. They need to look at not only how to secure resources but also access to user accounts. If an intruder is able to successfully authenticate against Active Directory by using a guessed or stolen username and password combination (hacking), sensitive data on the network can more easily be compromised (read/modified/deleted). To minimise this risk, Windows Server has the functionality to configure strict account policies that apply to all users within an Active Directory domain.
In Active Directory environments, account policy settings are implemented by the Group Policy object linked to the domain with the highest priority. With a default installation of Windows Server 2003, the Default Domain Policy controls the account policy settings for the domain. It would be possible to replace this Group Policy object, or to add a new Group Policy object linked to the domain with higher priority, and therefore override the Default Domain Policy. Microsoft recommends that the account policy settings are modified in the Default Domain Policy, and the Default Domain Policy is used only to control account policies.
Note: Although the Account Policies node is available when configuring Group Policy objects at all levels, only account policy settings configured at the domain level will actually apply to domain users. The three main areas within the Account Policies section of a Group Policy object include Password Policy, Account Lockout Policy, and Kerberos Policy. The policy settings configured in each of these areas affect all domain users and should be configured in line with the security objectives and requirements of your company
Even though it might initially seem like a good idea to configure all authentication security settings to the most secure levels possible, this can present its own set of problems. If you require users to use a 14-character password, which is definitely more secure than an eight-character password, many users would ultimately have a hard time remembering their password. This could lead to them writing their password down, which would make it less secure than an eight-character one they could memorise. It would also increase your workload resetting all the forgotten passwords! You want to implement a security system that is effective – and to be effective it has to be useable.
Account policy options
Enforce Password History
When this policy is enabled, Active Directory maintains a list of recently used passwords and will not allow a user to create a password that matches a password in that history. So, if Enforce Password History is set to 24, you can only reuse your password every 25th time, as it checks against the last 24 in memory. The policy is enabled by default, using the maximum value of 24.
Maximum Password Age
This policy determines how long a password remains valid. Once the maximum password age has elapsed, users are forced to change their password. The default value is 42 days. The longer you keep the same password, the more opportunity there is for someone to guess it and hack into the system, so to make the system more secure you would decrease the maximum password age. But if it is changed too often, users will have problems remembering it.
Minimum Password Age
When users are required to change their passwords even when a password history is enforced, they can simply change their passwords several times in a row, i.e. change it 24 times and go back to the original to get around password history requirements. The Minimum Password Age policy is designed to prevent this. The user must wait the specified number of days between password changes. An administrator or technical support person with sufficient permissions can reset a password at any time. The default value is 1 day.
Minimum Password Length
This policy specifies the minimum number of characters required in a password. The default in Windows Server is seven characters.
Passwords Must Meet This
This enforces complexity rules on new passwords. The default password filter in Windows Server (passfilt.dll) requires that a password:
- is not based on the user’s account name;
- is at least six characters long;
- contains characters from three of the following four character types:
- uppercase alphabet characters (A through Z)
- lowercase alphabet characters (a through z)
- arabic numerals (0 through 9)
- non-alphanumeric characters (for example, !, $, #, %).
This is the default setting on Windows Server.
Store Passwords Using Reversible Encryption
This option causes Active Directory to store user passwords without using the default non-reversible encryption algorithm. The policy is disabled by default, as it weakens password security. If you make any changes to Configuring password length and complexity requirements, this will not affect current passwords in use but when the user goes to change their password the new settings will be implemented. Any modifications made to password policy settings will affect new accounts as well as any changes to existing passwords after the policy is applied.
Account Lockout Policy
Password policy settings will help you to ensure that user passwords are changed regularly and meet minimum complexity requirements. Similarly, Account Lockout Policy settings are used to control what happens when any user attempts to log on using incorrect credentials. This could be someone trying to hack into your network or it could be a valid user with a typographical error. Through the configuration of account lock-out policy settings, an administrator can configure thresholds for invalid logon attempts that specify how many invalid attempts should result in an account being locked out, how long the lockout period should last, and whether locked-out accounts should be unlocked manually or automatically. This allows the ‘real’ user some attempts if they have mistyped their password, but once it gets above a certain level, which could be indicative of a hacking attempt, the account is locked until the administrator resets it.
Account Lockout Duration
This policy determines the period of time that must pass after a lockout before Active Directory will automatically unlock a user’s account. The policy is not enabled by default, as it is useful if it is used with a configured account lockout threshold. Although the policy accepts values ranging from 0 to 99999 minutes (about 10 weeks), a low setting (5 to 15 minutes) is usually sufficient to reduce security risks without unreasonably affecting ‘real’ users. A value of 0 requires the user to contact an administrator to unlock the account manually.
Account Lockout Threshold
This policy configures the number of invalid logon attempts that will trigger account lockout. The value can be in the range of 0 to 999. A value that is too low might cause lock-outs due to normal human error, and lock out ‘real’ valid users. A value of 0 (the default value) will result in accounts never being locked out
Reset Account Lockout
This setting specifies the time that must pass after an invalid Counter After logon attempt before the counter resets to zero. The range is 1 to 99999 minutes and must be less than or equal to the account lockout duration.
Windows Server provides the ability to track the success and failure of various authentication-related events by configuring Audit Policy settings. Windows Server domain controllers have a number of audit settings (including logon events) that are configured by default via the default domain controllers policy. This Group Policy object is applied to domain controllers automatically as part of the Active Directory installation process. See screenshot below for the settings:
Audit policy settings
When logon events specified in an audit policy occur, they are ultimately recorded in the security log, which can be accessed from Event Viewer, via Administrative Tools. This is shown in the screenshot below:
Keep in mind the difference between the default domain policy (which is linked to the domain and determines password, lockout, and Kerberos policies) and the default domain controller policy (which is linked to the Domain Controllers OU and is configured to enable security auditing by each of the domain controllers in the OU).
Audit policy settings are located in Computer Configuration\Windows Settings\Security Settings\Local Policies\Audit Policy. To audit logon events related to Active Directory authentication, you should configure settings in policies applied to the Domain Controllers OU, As shown earlier. But you can configure auditing for other domain computers, such as workstations or member servers, at any level to which group policy settings can normally be applied. The following list outlines the authentication-related audit policy settings available in Windows Server 2003. The results are viewed through Event Viewer as shown above.
Audit Account Logon Events
This setting audits each instance of user logon that involves domain controller authentication. For domain controllers, this policy is defined in the Default Domain Controllers Policy Group Policy object.
Note: This policy creates a security log entry on a domain controller each time a user logs on interactively or over the network by using a domain account. Also, remember that to fully evaluate the results of the auditing, you must examine the security logs on all domain controllers, because user authentication will be distributed among the various domain controllers in a site or domain. The default domain controllers policy has this setting configured to audit ‘success’ events by default. This means that a security log entry is created only when a domain controller successfully authenticates a user. You should also think about configuring this policy to record ‘failure’ events (this might give an indication of someone trying to hack in).
Audit Account Management
This setting configures auditing of activities including the creation, deletion, or modification of user, group, or computer accounts. This setting also includes configuring activities such as resetting passwords and is enabled by default in the Default Domain Controllers Policy for Success events.
Audit Logon Events Logon
These events include log on and log off, whether done interactively or through a network connection. If you have enabled the Audit Account Logon Events setting for successes on a domain controller, workstation logons will not generate logon audits. Only interactive and network logons to the domain controller itself generate logon events.
Account logon events are generated on the local computer for local accounts and on the domain controller for network accounts. Logon events are generated wherever the logon occurs. This setting is enabled by default in the Default Domain Controllers Policy for Success events. Once you have configured auditing settings for logon events, the security log in Event Viewer will begin to fill with messages according to the policy settings configured. You can view these messages by selecting Security from the Event Viewer and then double-clicking the event. If there is no room to write to the event log, the system hangs; make sure that you make your event log is big enough and that you delete/archive it on a regular basis to ensure it does not run out of space.
Common user administration tasks
Common User Administration tasks include:
- unlocking accounts;
- resetting passwords;
- deleting user accounts/objects.
Unlocking a user account
The Account Lockout Policy requires that when a user has exceeded the limit for invalid logon attempts, which the administrator specifies, the account is locked and no further logons can be attempted for a period of time that the administrator specifies, or until the administrator has unlocked the account. To unlock a user, open Active Directory Users and Computers, pick the user object and, from the Action menu, click Properties. Click the Account tab and uncheck the Account Is Locked Out check box.
Resetting user passwords
Click the user object in Active Directory Users and Computers, and select the Reset Password command. Enter the new password twice to confirm the change. If you select the User Must Change Password At Next Logon check box, you reduce the security risk, as only the user will then know their password.
Disabling and enabling user accounts
When a user does not require access to the network for an extended period of time, you should disable the account for security purposes. Then, when the user returns and needs access to the network again, enable the account. To perform either action, rightclick the account in Active Directory Users and Computers and then click Enable Account or Disable Account.
Deleting a user
When a user is no longer part of your company (e.g. they have resigned or retired) and their account is no longer required, you can delete it. Remember that by deleting a user, the associated SID is also deleted, meaning that rights and permissions associated with the account are also lost. If you create a new user object with the same name, it will have a different SID and you will have to reconfigure rights, permissions, and group membership information just as you would with any new account. So if there is any possibility they might come back, e.g. contract staff who are employed on an as needed basis, it might be easier to disable the account rather than delete it.
Renaming a user
User accounts can also be renamed rather than deleted when one user replaces another, which will reduce administrative effort (but you lose the audit trail). Deleting an existing user account and then creating one for the new user usually requires more effort than simply renaming the existing user account. Renaming maintains the user account SID and all the group membership settings, rights, and permissions of the old user. Renaming allows the new user to gain access to all the resources that the previous user required to do their job.
Troubleshooting user authentication problems
One of the most common problems is incorrect username and password combinations. If this is not the cause, then Windows Server has a number of utilities, including Event Viewer and Active Directory Users and Computers, that can be used to troubleshoot authentication problems.
When a user cannot be successfully authenticated during the logon process, refer to the key points for methods listed below for troubleshooting the problem. They start with the most common and easiest to fix and end with the less common and more timeconsuming to fix:
- Ensure that the user is attempting to log on using the correct username, password, and domain name. If this is not the case, get them to logon with the correct username, to the correct domain and reset their password if forgotten.
- If they have been trying to log on for a while, they could well have locked their account. Check to see if the account has been locked out or disabled and make sure it is re-enabled if disabled and unlocked if locked.
- If the user is logging on from a Client workstation,ensure that the configured time on that workstation is within the Maximum Tolerance For Computer Clock Synchronization value (default 5 minutes) specified in the domain Kerberos policy settings. Reset the workstation time and try again.
- Check that the TCP/IP settings of the client system are configured correctly,including the address of the DNS server that will be queried for the address of a domain controller. This can be done by entering Ipconfig /all at the command prompt. You can then use ping to check connectivity to you DNS Server(s)
- If the user is logging on to the domain for the first time in a multiple-domain environment, ensure that a global catalog server is available, as the user’s universal group membership information will be needed for the initial logon.
- If Audit Account Logon Events has been configured for Failure events in the Default Domain Controllers Policy, check the Security log in Event Viewer on domain controllers for messages that might help to explain why the logon attempt failed.
- If the user is attempting to log on to a domain controller, ensure that the user has been granted sufficient rights in the default domain controllers policy.
- If the user is attempting to log on using a UPN, ensure that a global catalog server is available to service the request.
- If the user cannot log on from certain workstations only, check the Log On To section of the Account tab in the user’s object properties to determine whether workstation restrictions have been configured. You can allow users to logon only from certain specified workstations.
- If the user cannot log on during certain times of the day, check the Logon Hours section of the Account tab in the user’s object properties to determine whether any logon hour restrictions have been configured. This is to prevent users trying to hack into the system outside the hours that they are supposed to be working.
This is a security feature, but if users start doing overtime or night shift, you might need to modify it.
- If the user cannot log on to a Terminal Server, ensure that the Allow Logon To Terminal Server check box is selected on the Terminal Services Profile tab in the properties of the user account.
- If the user cannot log on to the network remotely, ensure that the Dial-In tab in the properties of the user account is not configured to Deny Access in the Remote Access Permission section.
Resource access problems
Sometimes a user can successfully logon but they are unable to access the resources they require or they have insufficient permissions. These problems are caused by the following:
- The server or workstation hosting the resource is not available. You need to check whether the server or workstation hosting the resource is unavailable, or whether network settings are configured incorrectly.
- The user account does not have the correct permissions to access the resource. You need to check the access control lists associated with the resource that needs to be accessed to determine whether the user is a member of any group with sufficient permissions to access the resource. If not, add the user to a group with the appropriate permissions using Active Directory Users and Computers. Check the ACL of the object for any settings that might create a conflict, e.g. a user might be a member of one group that is allowed Read permission and a member of another group that is denied the same permission. Permissions explicitly denied override those explicitly allowed.
- The user does not have the right to carry out a task or tasks. Ensure that the user has sufficient rights to access servers and carry out tasks. For example, if a user should be able to back up and restore files and folders on a domain controller, you should add the user to the Backup Operators group. Also, you should use tools such as the Delegation Of Control Wizard in Active Directory Users and Computers to delegate the proper authority to users who need to perform tasks such as resetting passwords.