Designing an Authentication Strategy

Transcription

1 C H A P T E R 1 4 Designing an Athentication Strategy Most organizations need to spport seamless access to the network for mltiple types of sers, sch as workers in offices, employees who are traveling, and perhaps even bsiness partners and cstomers. At the same time, organizations need to protect network resorces from potential intrders. A well-designed strategy can help yo achieve this complex balance between providing reliable access for sers and strong network secrity for yor organization. In This Chapter Overview of the Athentication Strategy Design Process Creating a Fondation for Athentication Secring the Athentication Process Extending Yor Athentication Framework Enabling Spplemental Athentication Strategies Edcating Users Additional Resorces Related Information For more information abot the Kerberos version 5 protocol, see the Distribted Services Gide of the Microsoft Windows Server 2003 Resorce Kit (or see the Distribted Services Gide on the Web at For more information abot the Active Directory directory service logical strctre, see Designing the Active Directory Logical Strctre in this book. For more information abot pgrading from the Microsoft Windows NT version 4.0 operating system to the Microsoft Windows Server 2003 operating system, see Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory in this book.

2 654 Chapter 14 Designing an Athentication Strategy Overview of the Athentication Strategy Design Process One of the most fndamental elements of an organization s secrity strategy is verifying the identity of clients and granting them appropriate access to system resorces based on their identity. By creating an strategy for yor organization, yo can prevent attackers and malicios sers from accessing and tampering with sensitive information, consming compting power or other system resorces, and impersonating sers in order to send misleading or incorrect information. Athentication technology in the Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition operating systems allows yo to implement a variety of strategies based on the complexity of yor organization, the qality of a ser s credentials, the means by which sers access the network, and the clients they se to gain access. In addition, Windows Server 2003 technology allows yo to establish a fondation for more efficient management of sers, compters, and services on the network. Note For a list of the job aids that are available to assist yo in designing an strategy, see Additional Resorces later in this chapter.

3 Overview of the Athentication Strategy Design Process 655 Process for Designing an Athentication Strategy Designing an strategy involves evalating yor existing infrastrctre and creating acconts, establishing a means to secre the process, and establishing standards for network and time synchronization. Yo might also need to extend yor model to allow between forests or between other Kerberos realms, and to enable delegated in order to facilitate ser access to system resorces. Figre 14.1 shows the process for designing an strategy. Figre 14.1 Designing an Athentication Strategy Create a fondation for Secre the process Extend yor framework Enable spplemental strategies Edcate sers

4 656 Chapter 14 Designing an Athentication Strategy Athentication Backgrond Information Windows Server 2003 technology incldes a nmber of featres that provide soltions for a wide variety of bsiness needs. Central administration of acconts Administrators can create a single accont for each ser that allows the ser to access the appropriate network resorces. Users can log on at different desktops, workstations, or notebooks in the domain by sing the same ser name and a password or smart card. Single sign-on environment Users are reqired to enter a ser name and password or smart card only when first logging on to a Windows Server 2003 based compter. The Windows Server 2003 operating system atomatically athenticates the ser to the local compter, to the Active Directory domain, and to any other application or resorce server in the forest that reqires prior to access. When sers change passwords, the pdates are made to the ser acconts in Active Directory. The password changes apply atomatically to all resorces in the domain or forest. Compter acconts in Active Directory Compter acconts in Active Directory for all of the compters within a domain allow many of the Windows Server 2003 secrity featres that are designed for sers to be applied to compters as well. Compter acconts in Active Directory also allow yo to add application servers as member servers within yor trsted domains and to demand from the sers and other services that access these resorce servers. Service acconts in Active Directory The services rnning on resorce servers are athenticated atomatically if the servers are members of a domain that trsts the ser s accont domain. In Windows Server 2003, all of the domains in a forest atomatically have two-way transitive trst. Windows Server 2003 also spports transitive trst relationships between forests. In this way, when organizations add application servers to their domains, only athenticated sers and services can access them. Smart card spport Windows Server 2003 spports optional smart card. A smart card contains a processor chip that stores the ser s private key and pblic key certificate. The ser inserts the card into a smart card reader attached to the compter. The ser then types in a personal identification nmber (PIN) when reqested, to enable access to the keys stored on the smart card. Athentication proceeds when the correct PIN enables access to the private key and the certificate on the card, allowing the Active Directory service to verify the ser s identity. In this way, compters that store highly sensitive data can be secred from attack withot the need to store them in locked rooms. At the same time, athorized sers can access information stored on high-secrity compters.

5 Overview of the Athentication Strategy Design Process 657 Certification for Microsoft Windows Windows Server 2003 interoperates with third-party applications designed according to the Application Specification for Windows The Application Specification defines the technical reqirements for applications to earn the Certified for Microsoft Windows logo. Applications can carry the Certified for Microsoft Windows logo when they have passed compliance testing and have exected a logo license agreement with Microsoft. To pass compliance testing, a server application mst operate within the appropriate secrity context, redcing the risk posed by sccessfl attacks, and perform Kerberos-based mtal for all client reqests, ensring that clients know that the servers with which they are commnicating are the intended parties, and not attackers posing as the server. Aditing Windows Server 2003 provides secrity adit information to track attempts to log on to servers and workstations. This gives organizations the ability to detect nathorized attempts to access the system. Kerberos V5 protocol When a client attempts to connect to a resorce server, the Kerberos Key Distribtion Center (KDC), rnning on a domain controller, provides the client with a ticket to verify the ser s identity to the server, and a shared secret key. The ticket allows the server to validate the ser immediately and can be sed mltiple times. The shared secret key is passed to the server in encrypted form, allowing both compters to se the shared secret key to encrypt any network data they exchange. The Microsoft implementation of the Kerberos protocol is based on indstry standard specifications defined by the Internet Engineering Task Force (IETF). The Kerberos V5 protocol provides the following advantages: Efficient to servers. Becase takes place qickly, sers do not lose prodctive work time. Clients can obtain a ticket for a particlar server one time and rese the ticket for mltiple network sessions. Mtal. By means of the shared secret key, parties at both ends of a network connection can verify each other s identities. This is a change from NTLM, which allows only servers to verify the identities of their clients. Delegated. A service can impersonate a client when connecting to a network service, sch as a database. Delegated is not available in NTLM. Interoperability. Kerberos in Windows Server 2003 can interoperate with the implementation of Kerberos in other operating systems.

6 658 Chapter 14 Designing an Athentication Strategy Tools for Deploying Athentication The following tools are available to assist yo in deploying : Active Directory Users and Compters. A Microsoft Management Console (MMC) snapin that allows yo to create ser and compter acconts in the Active Directory. Grop Policy. An MMC snap-in that allows yo to apply Grop Policy, inclding Kerberos, aditing, and NTLM behavior. Certificate Services. An MMC snap-in sed to establish the certification athorities (CAs) and isse the certificates sed in pblic key. For more information abot these tools, see the Distribted Services Gide of the Windows Server 2003 Resorce Kit (or see the Distribted Services Gide on the Web at Creating a Fondation for Athentication When yo deploy Windows Server 2003, yo can create a fondation for secre of sers, compters, and services in yor organization by creating acconts in Active Directory for all entities that reqire athenticated access to resorces. Becase a nmber of factors impact the strategy that yo deploy, yo mst evalate the strctre of yor existing environment before yo create the fondation for yor strategy. For a worksheet to assist yo in creating a fondation for, see Athentication Strategy Planning (DSSAUT_1.doc) on the Microsoft Windows Server 2003 Deployment Kit companion CD (or see Athentication Strategy Planning on the Web at Figre 14.2 shows the process for creating a fondation for.

7 Creating a Fondation for Athentication 659 Figre 14.2 Creating a Fondation for Athentication Create a fondation for Secre the process Extend yor framework Enable spplemental strategies Evalate yor environment Create ser acconts Create a ser accont management plan Create a compter accont management plan Secre service acconts Edcate sers Apply policies to grops

8 660 Chapter 14 Designing an Athentication Strategy Evalating Yor Environment Before yo establish an strategy for yor organization, yo mst become familiar with yor crrent environment, inclding the strctre of yor organization; the sers, compters, and services in yor organization that reqire ; and the applications and services that are in se. Specifically, identify the following: The nmber of domain controllers in yor organization. Ensre that yo have enogh domain controllers in yor environment to accommodate yor sers reqests. If the nmber of domain controllers is insfficient, a large volme of client reqests can reslt in failed attempts. If yo determine that yo have an insfficient nmber of domain controllers, deploy more domain controllers to meet the logon needs of yor sers. The type of network connectivity between site locations in yor organization. Domain controllers mst be well connected to sers to ensre reliable access for. Clients that do not have access to local domain controllers might be nable to access resorces if the network connection is navailable. If the connectivity between domain controllers in remote sites is insfficient, deploy more domain controllers in those sites or improve the connectivity between the sites. The nmber of CAs that are available in yor organization and their locations. As with domain controllers, a sfficient nmber of CAs mst be available to handle client reqests and they mst be well connected in order to provide timely responses. For information abot creating a CA infrastrctre, see Designing a Pblic Key Infrastrctre in this book. The nmber of sers, grops, and compters in yor organization and where compters are located. This impacts the nmber of domain controllers and CAs that are reqired to ensre consistent. The nmber and locations of sers who access the network by means of RADIUS and RAS servers. Note Windows Server 2003 provides for remote ser by means of RADIUS and RAS servers. For more information abot sing RADIUS servers, see Deploying IAS in Deploying Network Services of this kit. For more information abot sing RAS servers, see Deploying Dial-Up and VPN Remote Access Servers in Deploying Network Services.

9 Creating a Fondation for Athentication 661 Whether yor organization incldes clients rnning versions of Windows earlier than the Microsoft Windows 2000 operating system or other non-native operating systems, or applications that reqire protocols other than the Kerberos V5 protocol or reqire special configration to interoperate with the Kerberos protocol. The operating systems and applications in se in yor environment impact the protocols that yo can enable by means of policy. For example, versions of Windows earlier than Windows 2000 reqire NTLM or anonymos access. If clients in yor environment are rnning these operating systems, yo mst configre the LAN Manager level policy to enable those clients to access resorces in yor system. Note When yo enable LAN Manager, yo cannot take advantage of all of the secrity benefits that are available in Windows Server Therefore, if yo do not need to spport versions of Windows earlier than Windows 2000, it is best to se the Kerberos protocol. The nmber and location of smart card sers in yor organization, if applicable, and any secrity-sensitive tasks or sers, sch as administrators, that might reqire smart cards in the ftre. The nmber of crrent and planned ftre smart card sers in yor organization impacts the nmber of CAs that yo reqire. Creating User Acconts User acconts are reqired for. Assign sers the appropriate permissions to access resorces by creating ser acconts in Active Directory and adding the acconts to the appropriate grops. Adding acconts to secrity grops and applying access control settings to resorces allows sers to tilize their athenticated identity to access resorces, and facilitates accont management. It is best to grant sers and grops access to only those resorces that are reqired for them to complete their job tasks. In this way, if any ser accont is compromised by a malicios ser, he or she has limited access to resorces, and therefore can case only minimal damage. For more information abot ser acconts and secrity grops, see Designing a Resorce Athorization Strategy in this book. Note Do not allow sers to share acconts or passwords or to se weak passwords. Shared acconts and weak passwords compromise the secrity of yor environment. For more information abot creating password policies, see Creating a Strong Password Policy later in this chapter. Creating ser acconts involves creating a plan for ser accont management in yor organization.

10 662 Chapter 14 Designing an Athentication Strategy Creating a User Accont Management Plan When yo deploy Windows Server 2003 and establish the appropriate ser acconts in Active Directory, yo need to create a plan for ser accont management. Creating a ser accont management plan involves determining which individals in yor organization have the right to create new ser acconts, and establishing a plan for the disabling of and resetting of ser acconts. Assign the User Accont Creation Right Assigning the right to create new ser acconts involves careflly balancing strong secrity and timely response to reqests to create new acconts. Becase misse of the ser accont creation right presents a secrity risk to yor organization, assign this right to trsted administrators only. For many organizations, it is sfficient to limit the ability to create new ser acconts to the members of the Domain Administrators grop. In large organizations or in sitations where administrators need to delegate tasks, yo might need to assign the right to create new ser acconts to another grop, sch as the IT staff or the Hman Resorces grop. Whoever yo designate to create ser acconts, a general gideline is to assign one individal the right to create new ser acconts for every 100 employees. However, yo might need to adjst this nmber based on the expected growth of yor organization. For example, if yor organization reglarly adds new divisions, acqires companies, or expands into other markets, yo need to plan for the creation of new ser acconts by assigning the right to create new ser acconts to the appropriate nmber of individals to meet the reqirements for yor anticipated growth. Establish a Plan for the Disabling of User Acconts Becase nsed bt active ser acconts are a common target for secrity attacks, yo mst establish a clear, consistent policy for disabling ser acconts. Yo can choose one of the following soltions for disabling active nsed ser acconts in yor organization: Inclde disabling ser acconts as part of the employee departre procedre. Establish a policy by which ser acconts are deleted from Active Directory when employees leave yor organization. Create scripts that search for ser acconts that have not been logged on to for a period of time or have not had their password changed, and delete the acconts that the script identifies. For example, yo might decide to create a script that identifies acconts that have not been logged on to for six weeks, or that have not had their passwords changed for twice the password lifetime prescribed by domain Grop Policy, and delete those acconts.

11 Creating a Fondation for Athentication 663 Establish a Plan for Resetting User Acconts When a ser forgets his or her password, the accont mst be reset before it can be sed. An effective way to enable the resetting of ser acconts in yor organization is to grant help desk staff the right to reset passwords. Delegate the right to reset passwords to help desk staff so that members of the Domain Administrators grop are not reqired to reset ser accont passwords. Creating a Compter Accont Management Plan Windows 2000 and Windows Server 2003 compters have acconts in Active Directory and are athenticated in a separate process that is transparent to the ser. Yo can se compter to apply niform secrity policies to grops of compters, sch as compters contained in a domain, a site, or an organizational nit (OU) based on how the compters are groped and which rights and policies are granted and applied to each grop. For example, yo can configre an OU for compters that are pblic kiosks on a retail floor and apply limited permissions to sers. Yo can configre another OU for a compter stored in a locked office and allow sers greater access to resorces. Evalate the secrity needs for different types of compters in yor organization. Determine which compters are more vlnerable to compromise and therefore reqire stronger secrity settings, and then apply policies to the domains, sites, and OUs as appropriate to yor secrity needs. For more information abot applying secrity policies, see Deploying Secrity Policy in Designing a Managed Environment in this kit. Managing Compter Acconts Yo also need to establish a plan for managing compter acconts, inclding: The creation of new acconts The deletion of old acconts Resetting of compter accont passwords. Becase new compter acconts are created atomatically whenever a compter is added to a domain, yo need to decide who has the right to add compters to domains. Yo can delegate this responsibility to an individal or grop in yor organization by adding them to the Add workstations to domain Grop Policy.

12 664 Chapter 14 Designing an Athentication Strategy Yo can choose to manage new compter accont creation in yor organization in one of the following ways: Allow athenticated sers to create new compter acconts. This approach might be desirable in organizations where sers can be largely trsted. However, if yo only want to trst a limited grop of sers, sch as developers, for example, to create new compter acconts, yo can control this by sing the Secrity Configration Manager to either assign or deny this right to sers. By defalt, athenticated sers are assigned the Add workstations to domain ser right on the Grop Policy object on domain controllers. This enables them to create p to 10 compter acconts in the domain by sing the Network Identification Wizard. The wizard reqests information abot the compter name, the domain or workgrop that the compter is joining, and the domain sers that are to be added to the local grops for local compter access, and ses this information and the credentials of the athenticated ser to create a new accont in Active Directory. Note After a compter accont is created, administrators mst ensre that the accont is a member of the appropriate grops, so that the appropriate Grop Policies are applied. IT staff joins each new compter to the domain individally dring installation. Althogh this approach can work for small organizations in which compter accont creation occrs infreqently, it is impractical for large organizations with a high volme of new compter acconts. IT staff ses scripts to create new acconts ahead of time, and assigns new compters to existing acconts dring installation. Yo can se an Active Directory Service Interfaces (ADSI) script to create compter acconts in advance of installing new compters. As new compters are broght online, their compter names mst match the names that yo have specified in the script. This approach works well for organizations in which many similar compters need to be added to a domain simltaneosly, sch as in a training lab or server farm. For more information abot sing scripts to create new compter acconts, see Windows Deployment and Resorce Kits at or see the MSDN Scripting Clinic link on the Web Resorces page at Note It is more secre to create new compter acconts from the compter itself, rather than creating the acconts remotely or by sing scripts. An attacker who gains access to some part of a domain can se existing scripts or remote accont creation processes to create acconts to frther compromise the system. Reqiring that new acconts be created from the new compter protects against sch attacks.

13 Creating a Fondation for Athentication 665 Yo can choose to delete compter acconts in yor organization in one of the following ways: Inclde deleting sers compter acconts as part of the employee departre procedre. When employees leave yor organization, establish a policy by which their compter acconts are deleted from Active Directory. Create scripts that search for compter acconts that have not been logged on to for a period of time or have not had their password changed, and delete those compter acconts. For example, yo might create a script that identifies acconts that have not been logged on to for six weeks or that have not had their passwords changed for twice the password lifetime as prescribed by domain Grop Policy, and delete those acconts. If a compter is nable to contact a domain controller to initiate a password change, the accont might become nsynchronized with the domain and reqire a password reset. An effective way to enable the resetting of compter acconts in yor organization is to assign help desk staff the right to reset passwords. Delegate the right to reset compter passwords to help desk staff so that members of the Domain Administrators grop are not reqired to reset compter accont passwords. Important If yo are migrating from Windows NT 4.0 domains, yo mst create a plan for the creation of new compter acconts. Compters rnning Windows NT 4.0 do not have compter acconts. Creating Service Acconts Like sers, services have acconts and athenticate to the network operating system. This ensres that only athorized services are able to complete tasks, and protects against attackers who create nathorized services to infiltrate network systems. Most service acconts are created atomatically when a service is installed. Similarly, applications that act as services, sch as print spoolers or messaging services, create acconts atomatically to complete their tasks. Therefore, in general, yo do not need to create or modify service acconts. However, if service acconts are deleted accidentally, yo mst recreate them manally. Creating service acconts is similar to creating ser acconts. The only additional configration step that is needed is to set the service principal name (SPN) for the accont. This needs to be done to ensre mtal. For example, in the case of a web server, a SPN of http/hostname might need to be set for the service accont. The SPN can be set for the accont by sing the Setspn tility. For more information abot Setspn, in Help and Spport Center for Windows.NET Server 2003, click Tools, and then click Windows Spport Tools.

14 666 Chapter 14 Designing an Athentication Strategy There are also bilt-in service acconts that se the compter accont credentials by defalt for network. These inclde the LocalSystem accont, which was already present in Windows However, LocalSystem is a privileged accont and shold be sed only when reqired. Windows Server 2003 incldes the following new secrity contexts to provide a means by which yo can frther secre network service acconts: LocalService. This context is intended for services that rn with limited access on local compters and do not reqire network. In this way, a compromised service can do limited damage to the local compter and no damage to network compters. NetworkService. This context is intended for services that need to complete tasks on the network, bt reqire only restricted local capabilities. Secring Service Acconts Most services have specific fnctions, so it is best to grant them only those rights that are reqired for the services to perform those fnctions. In this way, if attackers compromise a service accont, they have limited access and can do only a limited amont of damage. If a service accont has rights that extend beyond its specific fnction, an attacker who compromises the accont can do extensive damage. To ensre maximm secrity, avoid rnning services on domain controllers. For example, do not make yor domain controller a mail server, Web server, and file and print server. Adding mltiple services on a critical link sch as the domain controller is risky, becase it increases the complexity of the system and therefore increases the potential for compromise. A problem with a print server that might otherwise only give an attacker the ability to create nathorized print jobs can instead grant the attacker access to Active Directory, a critical data repository. The secrity benefits of sing separate compters for services otweigh the initial investment in hardware eqipment. Also, yo might need to reset service accont passwords. Do not modify service acconts nless a problem occrs that interferes with the fnctioning of a service. To reset service accont passwords 1. In Active Directory Users and Compters, right-click the ser s accont. 2. Click Reset Password. 3. Enter and confirm the new password. Yo mst ensre that the service ses the newly selected password before the service can take advantage of the reset password. Ensre that the password that the service ses and the password that yo reset the service accont to have are the same.

15 Creating a Fondation for Athentication 667 Applying Athentication Policies to Grops Yo can manage in yor organization by adding ser, compter, and service acconts to grops and then applying policies to those grops. For example, yo can apply the following policies to grops, based on their fnction in the organization: Log on locally Access this compter from the network Log on over network Reset acconts Create acconts If yo want to make a compter less accessible to others, inclding both legitimate sers and attackers, yo can se policies in the following ways to restrict access for less trsted grops (sch as Anonymos): Assign the Deny access to this compter from the network policy. Assign the Deny logon locally policy. Remove the Remove compter from docking station policy. Other policies that yo might assign or deny to sers can also increase secrity or maximize flexibility, sch as Deny logon as batch job or Log on as service. For more information abot Grop Policies that impact, see Deploying Secrity Policy in Designing a Managed Environment of this kit. Example: Creating a Fondation for Athentication An organization that incldes 2,100 sers and 3,700 compters created an strategy when they deployed Windows Server 2003 in their environment. Becase compters in their environment are rnning versions of the Windows operating system earlier than Windows 2000, they need to spport LAN Manager. They decided to make members of the help desk staff and the Administrators grop responsible for ser accont management, and delegated compter accont management to the help desk staff. The organization secred their service acconts by rnning only reqired services on domain controllers and restricting the nmber of individals who are able to administer services. They assigned the Log on locally, Access this compter from the network, and Log on over network rights to Domain Admins and Domain Users, bt not to Gest acconts, to protect the secrity of their system. They granted the Reset acconts and Create accont policies to help desk staff to redce the administrative brden on domain administrators.

16 668 Chapter 14 Designing an Athentication Strategy Figre 14.3 shows the worksheet that the organization created to docment their strategy plan. Figre 14.3 Example of an Athentication Strategy Planning Worksheet (contined)

17 Secring the Athentication Process 669 Figre 14.3 Example of an Athentication Strategy Planning Worksheet (contined) Secring the Athentication Process It is important to secre yor process to protect yor system against varios types of secrity threats, sch as password-cracking tools, brte-force or dictionary attacks, abse of system access rights, impersonation of athenticated sers, and replay attacks. In addition, if yo share resorces on yor network with other organizations, yo mst ensre that yor policies interoperate with the policies that are in place on other systems. For a worksheet to se in docmenting secrity policies, see Athentication Secrity (DSSAUT_2.doc) on the Windows Server 2003 Deployment Kit companion CD (or see Athentication Secrity on the Web at Figre 14.4 shows the process for secring.

18 670 Chapter 14 Designing an Athentication Strategy Figre 14.4 Secring Athentication Create a fondation for Secre the process Extend yor framework Enable spplemental strategies Create a strong password policy Establish an accont lockot policy Assign logon hors Create a ticket expiration policy Edcate sers Establish network standards Set clock synchronization tolerance to prevent replay attacks

19 Secring the Athentication Process 671 Creating a Strong Password Policy Given enogh encrypted data, time, and compting power, attackers can compromise almost any cryptographic system. Yo can prevent sch attackers from scceeding by making the task of cracking the password as difficlt as possible. Two key strategies to accomplish this are to reqire sers to set complex passwords and to reqire sers to change their passwords periodically, so that attackers do not have sfficient time to crack the complex encryption code. Complex Passwords Yo shold set password policy to reqire complex passwords, which contain a combination of ppercase and lowercase letters, nmbers, and symbols, and are typically a minimm of six characters long or more for all acconts, inclding administrative acconts, sch as local administrator, domain administrator, and enterprise administrator. In this way, when sers sbmit a new password, Windows Server 2003 password policy determines whether the password meets established complexity reqirements. Yo can set more complex password reqirements; however, sch password policies can increase costs to the organization if they obligate sers to select passwords that are difficlt to remember. Users might be forced to call the help desk if they forget their passwords, or they might write down their passwords, ths making them vlnerable to discovery. For this reason, when yo establish password policies, yo need to balance the need for strong secrity against the need to make the password policy easy for sers to follow. Earlier Client Operating Systems Versions of the operating system earlier than Windows Server 2003 cannot handle passwords that contain more than 14 characters. For example: Attempts to log on to a Windows 2000 based compter rnning Terminal Services by sing atomatic logon settings configred in Client Connection Manager fail if yor password is more than 14 characters long. Client Connection Manager has a 14-character limitation for passwords sed for atomatic logon. To work arond this problem, yo mst manally enter a password to be sed for the connection when prompted. Yo can prevent this by modifying the password sed in Client Connection Manager and on yor domain to be no more than 14 characters long. In versions 3.5 and 3.51 of the Microsoft Windows operating system, Rn.exe allows sers to start tilities. When sers start tilities, they can specify a ser accont and password to be sed to start the application. When the password parameter is sed, Rn.exe stores the vales in bffers limited to 14 characters. Passwords longer than 14 characters are trncated for storage and then passed to domain controllers in trncated form, casing failres. Yo can solve many of these problems by applying the latest service packs for operating systems. If yor organization incldes clients rnning versions of the operating system earlier than Windows Server 2003 that do not spport longer passwords, be sre to accont for this when yo set yor password policies.

20 672 Chapter 14 Designing an Athentication Strategy Selecting Password Policy Options Windows Server 2003 provides secrity policies that ensre that all sers select strong passwords. Creating a password policy involves setting the following options in the Defalt Domain Grop Policy object. These policies, with the exception of those settings related to password lifetime, are enforced on all sers in a domain. Maximm password age This setting determines the period of time (in days) that a password can be sed before the system reqires the ser to change it. The best defense against impersonation is to reqire that sers change their passwords reglarly. This redces the amont of time available for attackers to crack nknown passwords, and it periodically invalidates any password that has been stolen by other means. The defalt vale of 42 days is generally appropriate; however, some IT departments shorten this to 30 days. Enforce password history This setting determines the nmber of niqe new passwords that have to be associated with a ser accont before an old password can be resed. It also rejects new passwords that are too similar to previos passwords. This featre prevents sers from circmventing password lifetime restrictions by resing their old password. The defalt vale is 1. Most IT departments choose a vale greater than 10. Minimm password age This setting determines the nmber of days that mst pass before a ser can change his or her password. Defining a minimm password age prevents sers from circmventing the password history policy by defining mltiple passwords in rapid sccession ntil they can se their old password again. The defalt vale is 0, bt it is recommended that this be reset. A vale of a few days discorages rapid password recycling while still permitting sers to change their own passwords if desired. Note that setting this parameter to a vale higher than the maximm password age forces sers to call the IT department to change their passwords, which increases costs to the organization. Minimm password length The setting determines the minimm nmber of characters that a ser s password mst contain. It is recommended that yo change this setting from the defalt vale of 0. A minimm password length of seven characters is considered standard.

21 Secring the Athentication Process 673 Passwords mst meet complexity reqirements This setting enables Windows Server 2003 to verify that new passwords meet complexity reqirements. The defalt password filter (Passfilt.dll) inclded with Windows Server 2003 reqires that a password: Is not based on the ser s accont name. Contains at least six characters. Contains characters from three of the following for categories: Uppercase alphabet characters (A Z) Lowercase alphabet characters (a z) Arabic nmerals (0 9) Nonalphanmeric characters (for example,!$#,%) This policy is disabled by defalt. Enable it to secre yor passwords against cracking. Establishing an Accont Lockot Policy Yo need to establish an accont lockot policy at the same time that yo establish a password secrity policy. Accont lockot policies protect yor environment against brte-force or dictionary attacks. Given enogh tries, even complex passwords can be gessed. Accont lockot policies redce the nmber of gesses that an attacker can make. It is best to establish an accont lockot policy that is restrictive enogh to prevent attacks, while still allowing for the occasional ser error. An accont lockot policy that is too strict might increase the nmber of spport calls in yor organization as sers who type their passwords incorrectly are mistakenly locked ot. Creating an accont lockot policy involves setting the following options in the Defalt Domain Grop Policy object. Accont lockot threshold The accont lockot threshold limits the nmber of times that anyone can attempt to log on to a compter from a remote location. This prevents attackers from trying all possible passwords over the network. This setting is disabled by defalt in the Defalt Domain Grop Policy object. Yo can trn it on by setting the vale to a nmber within the accepted range of 1 throgh 999. Set the vale high enogh to ensre that occasional errors do not reslt in accont lockot. Note that this setting does not apply to attempts to log on at the console of a locked workstation or to attempts to nlock a screensaver. Locked workstations cannot be forced to rn passwordcracking programs.

22 674 Chapter 14 Designing an Athentication Strategy Accont lockot dration The accont lockot dration determines how long, in mintes, an accont that has exceeded the accont lockot threshold remains locked before it is atomatically nlocked. Valid settings range from 0 throgh 99,999 mintes, or abot 10 weeks. When the vale is set to 0, an administrator mst manally nlock the accont. Becase accont lockot policies are designed to protect against brte-force attacks, setting even a low vale for the accont lockot dration redces the nmber of possible attacks considerably. Note that setting a high vale for the accont lockot dration can increase help desk calls when legitimate sers are mistakenly locked ot, and aside from indicating that an attack was attempted, provides little additional protection. By defalt, this policy is not defined, becase it is only applicable when an accont lockot threshold is specified. Reset accont lockot conter after This setting determines the nmber of mintes that mst elapse after a failed logon attempt before the conter is reset to 0 bad logon attempts. The range is 1 throgh 99,999 mintes. This vale mst be less than or eqal to the accont lockot dration. Enforce ser logon restrictions When this option is enabled, the KDC validates every reqest for a session ticket by examining the ser rights policy on the target compter. The ser reqesting the session ticket mst be assigned the Log on locally policy (if the reqested service is rnning on the same compter) or the Access this compter from the network policy (if the reqested service is on a remote compter) to receive a session ticket. This option also serves as a means to ensre that the reqesting accont is still valid. Verification is optional becase the extra step takes time and might slow network access to services, bt if accont rights have changed or ser acconts have been disabled between the time when the initial ticket was issed and the time when a service ticket was reqested, these changes do not take effect. By defalt, the policy is enabled in the Defalt Domain Grop Policy object. If the policy is disabled, this check is not performed. For greater secrity in an environment in which ser acconts change freqently, enable this setting. For faster performance, particlarly in a more stable ser accont environment, disable this setting.

23 Secring the Athentication Process 675 Assigning Logon Hors Yo can assign logon hors as a means to ensre that employees are sing compters only dring specified hors. This setting applies both to interactive logon, in which a ser nlocks a compter and has access to the local compter, and network logon, in which a ser obtains credentials that allow him or her to access resorces on the network. Assigning logon hors is sefl for organizations in which some sers are less trstworthy than others or reqire spervision. For example, yo might want to restrict logon hors when: Logon hors are a condition for secrity certification, sch as in a government network. Yor organization incldes shift workers. In this case, allow shift workers to log on only dring their schedled hors. Yor organization incldes temporary employees. The logon schedle is enforced by the Kerberos Grop Policy setting Enforce User Logon Restrictions, which is enabled by defalt in Windows Server Whether sers are forced to log off when their logon hors expire is determined by the Atomatically log off sers setting. By defalt, all domain sers can log on at any time. Yo can se the following procedre to limit the logon hors of an individal domain ser. To restrict the logon hors of a domain ser 1. In Active Directory Users and Compters, right-click the ser s accont. 2. Click Properties, and click the Accont tab. 3. Click Logon Hors. In the Logon Hors dialog box, indicate the hors and/or days of the week in which yo are restricting the ser from logging on. When yo have set the logon hors for an individal, yo can copy that accont to apply the same settings to a new ser in the same department. To restrict the logon hors for mltiple sers in the same OU 1. In Active Directory Users and Compters, select the ser acconts, and then right-click any of the selected items. 2. Use the Properties of Mltiple Objects dialog box to alter the properties for all of the selected sers. When yo restrict logon hors, yo might also want to force sers to log off after a certain point. If yo apply this policy, sers cannot log on to a new compter, bt they can stay logged on even dring restricted logon hors. To force sers to log off when logon hors expire for their accont, apply the Network secrity: Force logoff when logon hors expire policy.

24 676 Chapter 14 Designing an Athentication Strategy Creating a Ticket Expiration Policy It is important to establish reasonable lifetimes for tickets in yor organization. Ticket lifetimes mst be short enogh to prevent attackers from cracking the cryptography that protects the ticket s stored credentials. However, ticket lifetimes mst also be long enogh to be convenient for sers and to ensre that reqests for new tickets do not overload the network. Creating a ticket expiration policy involves setting the following options in the Defalt Domain Grop Policy object. Maximm lifetime for ser ticket This setting indicates the amont of time for which a ticket is valid before it expires. Generally, it is best if the Maximm Lifetime for User Ticket setting reflects the average amont of time that sers access their compters in one day. This is set to 10 hors in the Defalt Domain Grop Policy object. At the end of the ticket lifetime, the ser either obtains a new ticket or renews the existing ticket. This process is performed transparently by the compter, bt each ticket reqest or renewal prodces network traffic and domain controller loading. A short maximm ticket lifetime provides greater secrity bt also increases network traffic. A long maximm ticket lifetime decreases network traffic bt does not provide the same level of secrity. Maximm lifetime for service ticket This setting sally matches the established ser ticket lifetime. It might be shorter, however, if there is a need in yor organization for secre to services beyond what is reqired for ser. It might be longer if sers reqire ninterrpted access to services for long periods of time. For example, yo might need to extend the ticket lifetime if yor sers rn jobs that have a dration that is longer than the dration of the ser ticket lifetime. If yo do not have any special reqirements for service ticket lifetime, do not extend the lifetime of the ticket. The maximm service ticket lifetime mst be greater than 10 mintes and less than or eqal to the Maximm Lifetime for User Ticket setting. By defalt, this vale is set to 600 mintes (10 hors) in the Defalt Domain Grop Policy object (GPO). Ongoing operations are not interrpted if the session ticket sed to athenticate the connection expires before the operation is complete. Maximm lifetime for ser ticket renewal This setting determines the period of time (in days) dring which a ser s ticket-granting ticket (TGT) can be renewed. By defalt, this is set to seven days in the Defalt Domain GPO. Shorter renewal times make it easier to reqire sers to reathenticate in the event that yo sspect that there has been a secrity breach. An attacker with a renewable ser ticket can contine to renew that ticket for as long as the policy allows. Shortening renewal times makes an attacker s task more difficlt, bt it also increases the load on domain controllers.

25 Secring the Athentication Process 677 Establishing Network Athentication Standards Windows Server 2003 allows for interoperability with earlier versions of Windows and other operating systems. Interoperating with other operating systems, however, can negatively impact yor network secrity. It is important, therefore, to establish standards for network to minimize the effect that this interoperability has on yor organization s secrity. Yo can do this by restricting LAN Manager and by restricting anonymos access. Yo mst also establish a plan for pgrading Windows NT 4.0 domain controllers to balance the Kerberos load in Windows Server 2003 and Windows 2000 domains. Restricting LAN Manager Athentication De to advances in cracking tools and hardware capabilities, LAN Manager encryption is more vlnerable to attack than newer forms of encryption. For this reason, it is important to restrict the se of LAN Manager whenever possible. Windows Server 2003 spports all versions of LAN Manager, inclding LM, NTLM, and NTLM version 2 (NTLMv2), to allow for compatibility with clients that do not spport newer protocols. If it is necessary in yor organization to spport LAN Manager, yo can increase secrity by enabling spport of NTLMv2 whenever possible. Redcing or eliminating the se of LAN Manager and NTLM version 1 (NTLMv1) removes password hash vales from the network, and therefore increases network secrity. Yo can enable NTLMv2 spport by doing the following: Upgrading to at least Service Pack 4 (SP4) on all Windows NT 4.0 based clients. Yo can download the service pack from the Microsoft Web site at Installing the directory services client on all client compters that are rnning the Microsoft Windows 95 or Windows 98 operating system Yo can install the directory services client from the Windows Server 2003 operating system CD. Tightening LAN Manager policies. If all clients spport NTLMv2, set Domain Grop Policy for LAN Manager Athentication Level to Send NTLMv2 response only\refse LM & NTLM. This policy is nder Compter Configration\Windows Settings\Secrity Settings\Local Policies\Secrity Options\. If some clients exist that do not spport NTLMv2, set the LAN Manager Athentication Level to Send NTLM response only. This redces the amont of ciphertext available to attackers. Note Clients that do not typically spport NTLMv2 inclde Macintosh and Windows Services for UNIX.

26 678 Chapter 14 Designing an Athentication Strategy Restricting Anonymos Access In Windows Server 2003, access that was available to Anonymos sers in Windows NT 4.0 is available only to Everyone and Gest acconts. However, in some of the following sitations yo might still need to allow Anonymos access to portions of yor network. Some of the services rnning versions of Windows earlier than Windows 2000 se anonymos access to reqest ser accont information from domain controllers and to list network shares on file servers and workstations. Yo also might need to allow Anonymos access when an administrator in the trsting domain of a one-way cross-forest trst relationship needs to list sers and shares in the trsted domain of another forest. In addition, the Windows NT Remote Access Service (RAS) ses anonymos logon to determine whether a ser has permission to establish a RAS connection. Anonymos access to Active Directory is sed to change passwords from earlier systems. This form of anonymos access is enabled by the Pre-Windows 2000 compatible access secrity grop, which is a local grop fond only on Windows 2000 and Windows Server 2003 domain controllers. By defalt, this grop has read access to ser and grop objects in Active Directory. If yo need to spport networks containing a mix of Windows NT 4.0, Windows 2000, and Windows Server 2003 desktops and servers, yo mst take into accont the new restrictions on anonymos access by doing the following: First determine which services and applications reqire anonymos access to network resorces, and identify the servers to which anonymos access is needed. Then decide whether to add the Anonymos Logon identity to specific access control lists (ACLs), or to make secrity policy changes that relax the restrictions that Windows Server 2003 places on anonymos access. Yo can reglate anonymos access by doing the following: Edit the ACLs of the resorces, adding the Anonymos Logon identity to the list of athorized sers. This approach is the most secre, bt reqires editing the ACLs of each resorce, which might be difficlt to manage or trobleshoot. Use the Do not allow anonymos enmeration of SAM acconts and shares policy Grop Policy object, which can be fond in Compter Configration/Windows Settings/Secrity Settings/Local Policies/Secrity Options, to prevent attackers from sing anonymos connections to obtain information abot acconts and shares on a compter. Preventing Secrity Acconts Manager (SAM) accont enmeration can help thwart attacks, bt also prevents legitimate sers in other domains from obtaining this information.