Securing Accounts

Securing Accounts

Each user, computer, or group account is a security principal in Windows NT, Windows 2000, and Windows XP. Security principals receive permissions to access resources such as files and folders. User rights, such as interactive logons, are granted or denied to accounts directly or via membership in a group. The accumulation of these permissions and rights define what security principals can and cannot do when working on the network.

User accounts are either domain or local in scope. In Windows 2000, domain accounts are stored in the Active Directory directory service on domain controllers, while local accounts are stored in individual Security Accounts Manager (SAM) databases on the hard drives of workstations and member servers. In Windows NT, domain accounts are stored in a SAM database that is synchronized to all domain controllers in the domain by the primary domain controller (PDC), which holds the only writable copy of the database. Domain accounts can be used to authenticate to any machine in the forest and any domains that trust logons performed by the domain where the account exists, while local accounts are used to authenticate to the local computer only.

Understanding Security Identifiers

While users reference their accounts by the user name or universal principal name (UPN), the operating system internally references accounts by their security identifiers (SIDs). For domain accounts, the SID of a security principal is created by concatenating the SID of the domain with a relative identifier (RID) for the account. SIDs are unique within their scope (domain or local) and are never reused. This is an example of a SID:

S-1-5-21-833815213-1531848612-156796815-1105

SIDs have several components:

• Revision

  This value indicates the version of the SID structure used in a particular SID. The revision value is 1 in Windows NT, Windows 2000, and Windows XP.

• Identifier authority

  This value identifies the highest level of authority that can issue SIDs for this particular type of security principal. The identifier authority value in the SID for an account or group in Windows NT, Windows 2000, and Windows XP is 5 for the NT Authority.

• Subauthorities

  The most important information in a SID is contained in a series of one or more subauthority values. All values up to but not including the last value in the series collectively identify a domain in an enterprise. This part of the series is known as the domain identifier. The last value in the series identifies a particular account or group relative to a domain. This value is the RID. In the example just given, this value is 1105.

By default, several security principals are created during installation of the operating system or domain; the SIDs for these accounts are called well-known SIDs. Table 3-1 lists the well-known SIDs for Windows NT, Windows 2000, and Windows XP.

Table 3-1. Well-Known SIDs

Security Principal	SID
S-1-0	Null Authority
S-1-0-0	Nobody
S-1-1	World Authority
S-1-1-0	Everyone
S-1-2	Local Authority
S-1-3	Creator Authority
S-1-3-0	Creator Owner
S-1-3-1	Creator Group
S-1-3-2	Creator Owner Server (Windows NT only)
S-1-3-3	Creator Group Server (Windows NT only)
S-1-4	Nonunique Authority
S-1-5	NT Authority
S-1-5-1	Dialup
S-1-5-2	Network
S-1-5-3	Batch
S-1-5-4	Interactive
S-1-5-5-X-Y	Logon Session (X and Y values uniquely identify the logon session)
S-1-5-6	Service
S-1-5-7	Anonymous
S-1-5-9	Enterprise Controllers
S-1-5-10	Principal Self (or Self)
S-1-5-11	Authenticated Users
S-1-5-12	Restricted Code (Windows XP only)
S-1-5-13	Terminal Server Users (Windows 2000 only)
S-1-5-18	Local System
S-1-5-<domain SID>-500	Administrator
S-1-5-<domain SID>-501	Guest
S-1-5-<domain SID>-502	KRBTGT (Windows 2000 only)
S-1-5-<domain SID>-512	Domain Admins
S-1-5-<domain SID>-513	Domain Users
S-1-5-<domain SID>-514	Domain Guests
S-1-5-<domain SID>-515	Domain Computers
S-1-5-<domainSID>-516	Domain Controllers (Windows 2000 only)
S-1-5-<domain SID>-517	Cert Publishers (Windows 2000 only)
S-1-5-<root domain SID>-518	Schema Admins (Windows 2000 only)
S-1-5-<root domain SID>-519	Enterprise Admins (Windows 2000 only)
S-1-5-<domain SID>-520	Group Policy Creators (Windows 2000 only)
S-1-5-<domain SID>-553	RAS and IAS Servers (Windows 2000 only)
S-1-5-32-544	Administrators
S-1-5-32-545	Users
S-1-5-32-546	Guests
S-1-5-32-547	Power Users
S-1-5-32-548	Account Operators
S-1-5-32-549	Server Operators
S-1-5-32-550	Print Operators
S-1-5-32-551	Backup Operators
S-1-5-32-552	Replicators (Windows NT only)

Understanding Access Tokens

When a user successfully logs on to the network, an access token is created. A copy of the access token is attached to every process and thread that executes on the user s behalf. The access token is used by the computer to determine whether the user has the appropriate authority to access information or to perform an action or operation. The contents of an access token include the following:

• Account SID

  The SID for the account.

• Group SIDs

  A list of SIDs for security groups that include the account. In a Windows 2000 native mode domain, this list also includes the SID that is stored in the account s SID-History attribute.

• Rights

  A list of rights and logon privileges that the accounts possess directly or through security group membership.

• Owner

  The SID for the user or security group who, by default, becomes the owner of any object that the user either creates or takes ownership of.

• Primary group

  The SID for the user s primary security group. This information is used by the POSIX subsystem when using the File Server for Macintosh or Print Server for Macintosh services to provide file and print services from Windows NT 4.0 or later servers to Macintosh clients. (For information on File Server for Macintosh and Print Server for Macintosh, see Chapter 8, Securing Services. )

• Source

  The process that caused the access token to be created, such as the Session Manager, LAN Manager, or remote procedure call (RPC) Server process.

• Type

  A value indicating whether the access token is a primary token or an impersonation token. A primary token is an access token that represents the security context of a process. An impersonation token is an access token that a thread within a service process can use to temporarily adopt a different security context, such as the security context for a client of the service.

• Impersonation level

  A value that indicates to what extent a service can adopt the security context of a client represented by this access token.

• Statistics

  Information about the access token itself. The operating system uses this information internally.

• Restricted SIDs

  An optional list of SIDs added to an access token by a process with authority to create a restricted token. Restricting SIDs can limit a thread s access to a level lower than that allowed to the user.

• Session ID

  A value that indicates whether the access token is associated with the Terminal Services client session.

You can see the details of your access token by using the Whoami.exe utility. Figure 3-1 shows the contents of an access token using Whoami.exe.

Figure 3-1. Viewing the contents of an access token using Whoami.exe

Whoami.exe is located in the Tools folder on the CD included with this book.

Configuring Account Security Options

User accounts are a core unit of network security. Consequently, you might want to secure user accounts to a greater degree than the default settings provide. Active Directory enables you to secure individual user accounts in several ways, including these options:

• Logon Hours

  Determines the days and times of the week, in one-hour periods, when a user can log on to the network. Group Policy provides a setting to forcibly log a user off the network when the allowed logon hours have expired.

• Logon Workstation

  Restricts accounts to interactively logging on to only certain computers on the network, specified by the computers NetBIOS name(s).

• User Must Change Password At Next Logon

  Forces the user to change his password at the next interactive logon.

• User Cannot Change Password

  This setting prevents users from changing their own passwords. This option is commonly used with shared accounts, such as those used on a kiosk PC.

• Password Never Expires

  Exempts the password from domain password expiration policy restrictions. You should use this option only when you have a clear business reason, such as for accounts that are not used interactively and thus would not receive a password expiration notification, including service accounts that must run in the domain context.

• Store Password Using Reversible Encryption

  Stores the password in such a way that it can be decrypted by the operating system to be compared with a plaintext password. This option is required when using legacy protocols such as Challenge Handshake Authentication Protocol (CHAP) or Shiva Password Authentication Protocol (SPAP) for authentication. When this option is selected, the next time the user changes his password, the new password will be stored using a reversible hash of the password that will be created. This hash is sent across the network for authentication purposes, then decrypted and matched to the plaintext copy of the password. You should set this option only for accounts that require the plaintext of the password to be known by the domain controller, such as those used in Microsoft Internet Information Services (IIS) digest authentication and authentication from Macintosh computers.

  You cannot set the following account options on the built-in Administrator account:

  • Password Never Expires

  • Store Password Using Reversible Encryption

  • Account Is Disabled

  • Smart Card Is Required For Interactive Logon

  • Account Is Trusted For Delegation

  • Account Is Sensitive And Cannot Be Delegated

  • Use DES Encryption Types For This Account

  • Do Not Require Kerberos Preauthentication

• Account Is Disabled

  Prevents the account from being used, but does not delete the account. You commonly set this option when a user has been terminated, but items associated with user account might still be required, such as private keys or mailbox access.

• Smart Card Is Required For Interactive Logon

  Requires that a smart card be used for interactive logons, which include Terminal Services logons. Users with this option set on their accounts will not be allowed to log on interactively by using their user names and passwords. In Windows 2000, the password that was previously used for the account before setting this option is preserved. If you enable this setting, you should set the password to a random value to prevent the account from being used for other types of logons, such as network logons.

• Account Is Trusted For Delegation

  Enables the account to be used by processes and threads on the account s behalf. This option is available on both computer and user accounts and is commonly used with applications that run on Web servers, as well as on SQL and COM servers. You should set this option only if you know that it is required for proper functionality of a distributed application, such as on Web server accounts running applications that use Kerberos and Windows Integrated Security with IIS 5.0. Additionally, for users to use the encrypting file system (EFS) to encrypt files on remote servers, the server s account must be trusted for delegation so that it can retrieve the user s keys via Kerberos delegation and store them locally.

• Account Is Sensitive And Cannot Be Delegated

  Prevents an account from being delegated. If both the Account Is Trusted For Delegation and Account Is Sensitive And Cannot Be Delegated options are set, the latter will apply.

• Use DES Encryption Types For This Account

  Enables the account to use DES encryption, which supports multiple levels of encryption, for interoperability with Unix-based Kerberos realms, rather than the RC4 algorithm used by default in Windows 2000.

• Do Not Require Kerberos Preauthentication

  Disables Kerberos preauthentication, which is employed by default, for interoperability with MIT Kerberos v4 realms.

• Account Expiration

  Automatically disables an account on a specified date in the future. Often organizations will synchronize this setting with the employment duration of temporary, vendor, or intern employees to ensure that they do not have continued access to the network after their employment ends.

You can control Remote Access permissions for each user account by granting or allowing Remote Access privileges, as well as setting caller ID, callback, static IP addresses, and routes. Once you have converted your domain to native mode, you can configure Remote Access policies to control Remote Access permissions. Remote Access policies allow for much greater granular control of Remote Access permissions and are discussed in depth in Chapter 19, Implementing Security for Routing and Remote Access. You can also determine whether a user can use Terminal Services and how the terminal server session can be used by configuring Environment, Sessions, Remote Control, and Terminal Services Profile settings on a user account in Active Directory.

Securing Administrative Accounts

Regardless of the security deployed on a network, you will always have one collection of user accounts that are inherently trusted administrators. Administrators are granted rights and permissions that allow them to subvert nearly any security mechanism, through their innate rights, by elevation of privileges, or through physical compromise of the hardware. Although you might have thoroughly vetted administrators during the hiring process, the administrator account on most networks is only a password away. Once compromised, an administrator account is a passport to the entire network and all the data on it. Therefore, it is paramount to secure administrator accounts. In addition to applying account security options, consider the following best practices for administrator accounts:

• Minimize the number of accounts that are granted Administrator access.

  Windows 2000 enables you to delegate authority over nearly every object in Active Directory and the file system. Additionally, most services install special management groups. For example, when you install the Domain Name System (DNS) or Dynamic Host Configuration Protocol (DHCP) on Windows 2000, a domain local group is automatically created with permissions to manage the respective services. These built-in administrative groups are discussed later in this section in Built-In Domain Groups.

• Use Restricted Groups to control membership in administrative groups.

  Restricted Groups in Windows 2000 Group Policy enable you to control group membership automatically. Domain controllers refresh Group Policy every 5 minutes by default; thus, every 5 minutes, accounts that are not defined in the Restricted Groups policy settings are removed from the security group. If you audit account management events, enforcement of this policy will log an event to the security event log under the event ID 637. The Caller field in the error message will list the computer name of the domain controller computer that the change was made on instead of the user account name.

• Require multiple factor authentication.

  You can require smart card or other multiple factor authentications for accounts with administrative access, especially members of the Enterprise group or the Domain Administrators group. By doing this, you can avoid the risks associated with passwords and add an element of physical security to using administrator accounts. You can also require smart cards for Terminal Services logons.

• Restrict the use of administrator accounts to specific computers.

  Doing this can create management inconveniences. However, for high security requirements, you can use the Logon Workstation account option to restrict the interactive logon to certain computers for administrator accounts. By combining this setting with good physical security of the computers the account is restricted to, you greatly increase the security of the Administrator account.

• Do not use administrative accounts for routine activities.

  By not using administrative accounts for routine activities such as browsing the Internet, you can limit the damage that a virus or Trojan horse could do to a computer if compromised. Instead, use the secondary logon (RunAs) service. See the following sidebar for details of this service.

Using the RunAs Service

Windows 2000 and Windows XP include the RunAs service, although in Windows XP it is called the Secondary Logon service. This service allows an interactive user to use a different security context to run applications and utilities. You can use the RunAs service at the command line by pressing the Shift key while right-clicking on an application, or by creating a shortcut to an application and selecting the option to automatically invoke the Secondary Logon service. RunAs is not scriptable by any method other than keystroke passing utilities because the service requires that the password be typed interactively. If you are logging on to the RunAs service in Windows XP by using a privileged security context such as an Administrator account, you can create a restricted token for the secondary logon session. An access token will be created for the logged-on user that eliminates all users rights except Bypass Traverse Checking and restricts rights received by membership in the local Administrators group by creating a deny DACL, or discretionary access control list, on the access token for this group. Because Whoami.exe does not display deny DACLs, you will not see the Administrators group membership denied when inspecting a restricted token. In Windows XP, you can also use the RunAs service with smart cards.

• Do not allow users to be local administrators.

  Unless you have a clear business or technical reason for doing so, you should prohibit users from having local administrative privileges. Users who have local administrative privileges can reconfigure the computer and have unrestricted access to the operating system and registry. Not only could this lead to information disclosure if a user shares confidential data without proper security, but many virus and Trojan horses rely on this level of access to infect computers and spread to other machines. Additionally, users with local administrative access can exempt their machines from Group Policy and otherwise manipulate their computers to render security measures ineffective.

• Vet employees before granting them administrative access.

  You should work with your organization s HR department to evaluate network administrators during the hiring process to prevent granting access to potentially malicious or overly careless administrators.

• Lock servers and workstations.

  Locking unattended servers and workstations is especially important when using accounts with administrative access. An attacker might need only a few seconds at a computer that is logged on with administrative privileges to compromise the system. You can require smart cards for interactive logons, implement Group Policy to set the smart card removal behavior to lock the workstation when the smart card is removed, and require your administrators to carry their smart cards with them at all times.

Implementing Password Security

By default, the only protection accounts are given are user-chosen passwords. Users and for that matter, administrators historically have been poor generators of random passwords and even worse at keeping passwords secret. Your organization might have near-perfect security, but one weak password can cause the exposure of company secrets, be used to launch a successful denial-of-service attack, or sabotage the network. Unless you employ multifactor authentication methods for all users on your network, you should implement password security settings.

In Windows 2000, you can create password policies at the domain level for all domain accounts though Group Policy, or at the OU level for local accounts on Windows 2000 and Windows XP member computers. Table 3-2 lists password policies in Active Directory that you can set for all accounts in the domain. We will describe each of these policies momentarily.

Table 3-2. Default Password Policy Settings in Windows 2000 and Windows XP

Setting	Default Value	Range
Enforce Password History	One password remembered	0 to 24
Maximum Password Age	42 days	0 to 999
Minimum Password Age	0 days	0 to 999
Minimum Password Length	0 characters	0 to 14
Password Must Meet Complexity Requirements	Disabled	Enabled or disabled
Store Password Using Reversible Encryption For All Users In The Domain	Disabled	Enabled or disabled

Enforce Password History

You can force users to vary their passwords by setting the Enforce Password History option. When configuring this setting, you must define how many passwords will be retained in history. If you do not configure this setting, the user can reuse a password, even if it has expired, simply by changing the password to the previous password. Set this value to 24, the maximum.

Maximum Password Age

You can also configure how long users can use a password by configuring the Maximum Password Age setting. Users are forced to change their password when the password expires. By enabling this setting, you can avoid a situation in which a user or administrator uses the same password indefinitely. However, configuring passwords to expire too frequently can result in users incrementing passwords in an unsophisticated manner, such as changing WeakPass1 to WeakPass2, or writing the password in an obvious place, such as on a sticky note on their monitor.

The maximum length of time that a user can use a password should be in accordance with the time it would take to successfully issue a brute force attack against the password offline. Unfortunately, no magic calculation exists for this, given the continuing improvements in the hardware and software used to carry out these attacks.

Password Never Expires

The Maximum Password Age setting can be overridden on individual domain and local user accounts by setting the Password Never Expires option on the account. This is commonly used for service accounts, for which no interactive logon exists. Thus, no notification that the password is about to expire is needed.

Minimum Password Age

The Minimum Password Age setting prevents users from circumventing the enforcement of password history and password expiration. For example, if a minimum password age is not configured, at the expiration date of a password, a user could simply change her password to dummy values a sufficient number of times to reuse her previous password. This value should be set to at least two days to prevent users from utilizing this technique.

Minimum Password Length

The Minimum Password Length setting determines the minimum number of characters a user must use in his password. The longer a password is, the more difficult it generally is to compromise. However, one of the side effects of requiring long passwords is that users will choose passwords that are easy to guess or they will write them down. Part of the problem with users conception of passwords is the very word password, which implies that the secret information should be a single word. When implementing a long minimum password length (10 characters or more), it is essential to educate users on how to create good passwords.

A password of 20 or more characters can actually be set so that it is easier for a user to remember than an 8-character password. The following is a 36-character password: ThelastgoodbookIboughtcost$59.99, for example. It might be simpler for a user to remember a phrase such as this than to remember a shorter password such as P@sSw0rd.

Password Complexity Issues

Windows 2000 provides a built-in filter, Passfilt.dll, that requires passwords to contain characters of different types. By enabling this filter, you will increase the total keyspace for passwords. For example, without creating a password filter, a user could use only lowercase Roman letters in his password. The keyspace, or pool of available keys, for lowercase Roman letters is 26. Thus, a password of 8 characters would have 26^8 or 208,827,064,576 (2.089 x 10^11) possible combinations. On the surface, this might seem a mind-boggling number. However, at 1,000,000 attempts per second, a capability of many password-cracking utilities, it would take only 59 hours to try all possible passwords. If the keyspace included lowercase Roman letters, uppercase Roman letters, and numbers, it would contain 62 characters. An 8-character password would now have 218,340,105,584,896 (2.18 x 10^14) possible combinations. At 1,000,000 attempts per second, it would take 6.9 years to cycle through all possible permutations.

In practice, password keyspaces do not completely apply because humans rarely create passwords with a random distribution of characters. Brute force attacks and modified dictionary attacks often employ sophisticated logic to exploit known characteristics of human-created passwords, such as using the number 1 much more frequently than any other number or adding a number to a dictionary word. Although these calculations are important, you must use them carefully and underestimate the time that you think it will take to successfully perform a brute force attack on a password.

The built-in password complexity filter requires all passwords to be at least eight characters in length and include characters from three of these four categories:

• English uppercase letters (A, B, C, Z)

• English lowercase letters (a, b, c, z)

• Westernized Arabic numerals (0, 1, 2, 9)

• Nonalphanumeric characters (`~!@#$%^&*_-+= \{}[]:;" <>,.?/)

You also can use other ASCII characters in passwords, such as and (Alt+233 and Alt+189). Additionally, if your organization has its own password security requirements, you can create a custom password filter and install it on each domain controller. Creating your own password filter requires advanced knowledge of C++ programming and familiarity writing programs using Windows APIs.

Altchar.vbs is located in the Tools\Scripts folder on the CD included with this book that will display the character for an ASCII decimal value from the command line.

Store Passwords Using Reversible Encryption For All Users In The Domain

The setting to store passwords using reversible encryption for all users in the domain is required if the domain controller needs the ability to quickly decrypt the password to a plaintext form for use with certain authentication methods, including CHAP, and for use with some Macintosh computers. Setting this option greatly weakens the security of passwords and should be done only if required for the entire domain. This option can be set on individual user accounts rather than at the domain level if only some passwords need to be stored reversibly.

Although you will need to adjust the settings in Table 3-3 for your own organization, at a minimum, you should configure the password policy detailed in the table.

Table 3-3. Recommended Minimum Password Policy Settings

Setting	Value
Enforce Password History	24 passwords remembered
Maximum Password Age	42 days
Minimum Password Age	2 days
Minimum Password Length	8 characters
Password Must Meet Complexity Requirements	Enabled
Store Password Using Reversible Encryption For All Users In The Domain	Disabled

As a best practice, accounts with high levels of access, such as enterprise or domain administrators, should use passwords with at least 15 characters. This will prevent a LAN Manager password hash from being created. LAN Manager password hashes are explained later in this chapter, in the Securing Passwords section.

You can also set account lockout policies for the entire domain or for local accounts on individual computers by using security policies. You must configure three settings when implementing an account lockout policy, as Table 3-4 shows.

Table 3-4. Default Account Lockout Settings in Windows 2000 and Windows XP

Setting	Default Value	Range
Account Lockout Threshold	Not applicable	1 99,999 minutes (A value of 0 will never reset the number of failed attempts tracked in a given attempt to log on.)
Account Lockout Duration	0 attempts (disabled)	1 999 attempts
Reset Account Lockout Counter After	Not applicable	1 99,999 minutes (A value of 0 will require an administrator to unlock the account.)

Although account lockout settings are common, often they are the cause of numerous support calls to the help desk. If passwords are appropriate in length and complexity, this setting provides little additional security. On a similar albeit much more sinister note, an attacker could easily exploit an account lockout policy to carry out a denial-of-service attack by locking out all users. A better security approach is to educate users and administrators on how to create strong passwords, enable auditing of account logon events, and actively review audit log files for excessive failed logon attempts that might indicate a brute force or dictionary attack on an account. Doing this not only can greatly improve your security, it also can decrease your organization s support costs.

In Windows 2000, members of the Domain Administrators group are not affected by account lockout settings.

Creating stringent requirements for password length and complexity does not necessarily translate into users and administrators using strong passwords. For example, IceCream! meets the technical complexity requirements for a password defined by the system, but anyone who looks at the password can see that there is nothing complex about it. By knowing the person who created this password, you might be able to guess his password based on his favorite food. One strategy for educating users on choosing strong passwords is to create a poster describing poor passwords and display it in common areas, such as near the water fountain or copy machine. Guidelines for creating strong passwords include the following:

• Avoid using words, common or clever misspellings of words, and foreign words.

• Avoid incrementing passwords with a digit.

• Avoid using passwords that others can easily guess by looking at your desk (such as names of pets, sports teams, and family members).

• Avoid using words from popular culture.

• Avoid thinking of passwords as words per se think secret codes.

• Use passwords that require you to type with both hands on the keyboard.

• Use uppercase and lowercase letters, numbers, and symbols in all passwords.

• Use mnemonics, such as taking the first letter from each word in a sentence that only you would know. For example, I drink 10 cups of coffee every morning, before noon, becomes Id10coceAM,b12:00.

• Use space characters and characters that can be produced only by pressing the Alt key.

  In general, it is a good practice to regularly audit passwords to ensure that users and administrators are creating strong passwords. Before performing any type of audit on user passwords, you must get formal approval from your company s HR and legal departments. Privacy laws vary greatly from country to country and many countries and states specifically prohibit accessing this type of information.