Introduction
Some might consider authentication to be the most important aspect in a Windows security audit. Others might think that the user account policies are the most important control point. You might think that resource access is the key. No matter where you stand on the most important aspect of the audit, everyone must agree that the user account properties and settings are essential for any audit of a network operating system.
When it comes to auditing the user accounts of an operating system, it is important to consider what possible settings exist for the operating system vendor and version. For a Windows Active Directory environment, the same rule applies. As a network architect, network administrator, consultant, author, and trainer, I am familiar with the unique details that must be considered to audit user accounts in a Windows Active Directory environment. This article exposes all of these user accounts details and will help you audit user accounts better in the future.
Basic User Account Properties to be Audited
Most auditing tools will dig out the basic user account information that needs to be included in the audit. These basic properties and settings are a great place to start with the audit and will typically include the following properties:
LogonScript – this is important if the logon script performs any tasks that might establish some security settings, copy key security files, or any other security related task. If the incorrect logon script is being applied, it could leave the computer less secure.
Workstations – this is an important setting if your company uses this setting to restrict user accounts to logon to only a single or few computers. Typically this setting is left for service accounts, not typically used for user accounts used by employees.
Last time password was set – this setting can help determine stale user accounts. If a user has not changed the password within the time frame dictated by the password policy for maximum time that the password is valid, then this might be an indication that the user account is no longer being used. Another important issue to always consider is a malicious administrator who does not have his user account configured to expire the password. In this instance, the administrator will toggle the user account to expire the password, run the report for the audit, then toggle the password not to expire. If the password has not been changed in a year, but the password policy requires that all passwords be changed every 30 days, it is clear the administrator is trying to fool the audit report.
Password is required – in a Windows Active Directory environment, it is not easily possible to configure one user to have a password that expires and another that does not. There are some user accounts that are configured to not require a password by default, which includes the Guest account and IWAM_{computername} account.
Password Expires – when a user account is configured to not have the password expire, the password is not under the same rules as the domain Password Policy. This allows the user to keep the same password for an unlimited time and potentially have a weak password. Of course, this is not desired and standard user accounts (including administrators and other IT staff) should have the password expire.
Password Expires Time – not only can you determine whether the password expires, you can also audit when the password will expire next. The key audit point here is to ensure that all users will have their password expire within the password policy which requires that the password be changed within a set number of days. If the password expiration time is outside this range, it means that there might be an error within the user property or someone has modified the property to make the password expire later than desired.
Account is Disabled – this is an important property to audit for accounts that have been disabled and might need to be deleted. Most companies have a standard policy for when to delete user accounts. This might be 6 months, one year, or longer after the account is disabled. The main reason for such a long time for deletion is that a user account can’t be recreated after it is deleted, it can only be recovered, which is not an easy process.
Last Logon Time – this setting will indicate a key aspect for each user account. It will indicate whether or not users are logging off at night, which is important to ensure that users change their passwords to adhere to Password Policy settings. If a user has not logged in for quite some time, it would be important to investigate whether the user account should be disabled, or why the user has not logged out in the recent past.
Advanced User Properties to be Audited
There are still other properties that need to be considered when performing an audit on user accounts. Some of these might be on your basic list, were others might be completely omitted. Regardless, you should consider including these in your next audit.
Remote Access – Both dial-up and virtual private network (VPN) access is controlled through Active Directory. The catch with Active Directory is whether the setting is configured for Allow, Deny, or Use Remote Access Policy. If set for the latter, then you will need to also investigate the Remote Access Policies configured on the RAS server or the RADIUS (Remote Authentication Dial-In User Service) server.
Terminal Service access – With Terminal Services being such an important aspect of Windows 2000/2003/XP, it is essential to audit whether users can logon using this service. With the Terminal Service access, you need to not only check the user property for this access, but also the user rights. For Windows 2000 the user right that must be audited is “Logon Locally.” For Windows XP and Server 2003, the user right that allows users to logon with Terminal Services is “Allow logon through Terminal Services.”
Tools for Auditing User Account Properties
All of the basic user account properties can be audited using DumpSec, which is a free tool provided by SomarSoft (www.somarsoft.com). The tool is an easy to install and easy to use way to gather all of the information that you need from Active Directory related to user accounts. Figure 1 illustrates the list of possible properties that can be audited regarding user accounts.
Figure 1: DumpSec can audit user account properties
For the advanced user account properties, DumpSec won’t do the job. It can indicate whether or not the user has dial-up permissions if they are set to allow or deny, but not for using Remote Access Policies. There is no tool that can decrypt the complex array of settings and possibilities that exist within a Remote Access Policy. This must be done manually. For Terminal Services, DumpSec can’t audit whether or not the user has the ability, nor the correct user right. To audit this, you will need to either manually audit the permission or create a script to pull out this information. For the user rights, it is best to use the Local Security Policy from the computer where the Terminal Service is enabled, as shown in Figure 2.
Figure 2: Terminal Service access requires either “Logon Locally” or “Allow logon through Terminal Services” user rights
Summary
When auditing user accounts there are many properties and aspects of the user account that need to be considered. The auditor must evaluate each property individually to make an evaluation as to whether the setting is within limits or not. The auditor must also make evaluations of how each property relates to the others. When auditing user accounts, it is important to consider both active and disabled accounts, since both can be potential points of attack for an intruder.
