Windows Server 2003 Security Guide

Microsoft Solutions for Security and Compliance
Windows Server 2003 Security Guide
2006 Microsoft Corporation. This work is licensed under the Creative Commons Attribution- on Commercial !icense. To view a cop" of this license# visit http$%%creativecommons.or&%licenses%b"-nc%2.'% or send a letter to Creative Commons# '() *oward +treet# 'th ,loor# +an ,rancisco# California# -(.0'# /+A.
Table of Contents
iii
Contents
,eedback......................................................................................0vi Chapter 1: Introduction to the Windows Server 2003 Security Guide. .1 1verview.......................................................................................... 20ecutive +ummar"........................................................................... 3ho +hould 4ead This 5uide..............................................................2 +cope of this 5uide...........................................................................2 Chapter +ummaries..........................................................................) Chapter .$ 6ntroduction to the 3indows +erver 200) +ecurit" 5uide. .( Chapter 2$ 3indows +erver 200) *ardenin& Mechanisms..................( Chapter )$ The 7omain 8olic".......................................................( Chapter ($ The Member +erver 9aseline 8olic"................................( Chapter '$ The 7omain Controller 9aseline 8olic"............................' Chapter 6$ The 6nfrastructure +erver 4ole......................................' Chapter :$ The ,ile +erver 4ole.....................................................' Chapter ;$ The 8rint +erver 4ole...................................................' Chapter -$ The 3eb +erver 4ole....................................................' Chapter .0$ The 6A+ +erver 4ole...................................................6 Chapter ..$ The Certificate +ervices +erver 4ole.............................6 Chapter .2$ The 9astion *osts 4ole...............................................6 Chapter .)$ Conclusion................................................................6 Appendi0 A$ +ecurit" Tools and ,ormats.........................................: Appendi0 9$ <e" +ettin&s to Consider............................................: Appendi0 C$ +ecurit" Template +ettin& +ummar".............................: Appendi0 7$ Testin& the 3indows +erver 200) +ecurit" 5uide...........: Tools and Templates....................................................................: +kills and 4eadiness..........................................................................; +oftware 4e=uirements.....................................................................; +t"le Conventions.............................................................................; +ummar"........................................................................................More 6nformation........................................................................Chapter 2: Windows Server 2003 Hardening Mechanis s..................10
1verview........................................................................................0 *ardenin& with the +ecurit" Confi&uration 3i>ard.................................0 Creatin& and Testin& 8olicies......................................................... 7eplo"in& 8olicies.......................................................................2 Appl" the 8olic" with the +C3 5/6..........................................2
iv
3indows +erver 200) +ecurit" 5uide
Appl" the 8olic" with the +cwcmd Command-line Tool................2 Convert the +C3 8olic" to a 5roup 8olic" 1b?ect.......................2 *ardenin& +ervers with Active 7irector" 5roup 8olic"............................) Active 7irector" 9oundaries.........................................................) +ecurit" 9oundaries..............................................................) Administrative 9oundaries......................................................( Active 7irector" and 5roup 8olic".................................................6 7ele&atin& Administration and Appl"in& 5roup 8olic".................6 Administrative 5roups...........................................................6 5roup 8olic" Application.........................................................: Time Confi&uration................................................................; +ecurit" Template Mana&ement..............................................+uccessful 581 Application 2vents.........................................20 +ever 4ole 1r&ani>ational /nits.............................................20 1/# 581# and 5roup 7esi&n........................................................2( 8rocess 1verview............................................................................2( Create the Active 7irector" 2nvironment.......................................2' Confi&ure Time +"nchroni>ation...................................................2' Confi&ure the 7omain 8olic".......................................................26 Create the 9aseline 8olicies Manuall" /sin& +C3...........................2: Test the 9aseline 8olicies /sin& +C3............................................2Convert the 9aseline 8olicies to 581s...........................................2Create the 4ole 8olicies /sin& +C3..............................................)0 Test the 4ole 8olicies /sin& +C3..................................................)0 Convert the 4ole 8olicies to 581s................................................). +ummar"......................................................................................). More 6nformation......................................................................)2 Chapter 3: !he "o ain #o$icy...........................................................33
1verview.......................................................................................)) 7omain 8olic"................................................................................)) 7omain 8olic" 1verview.............................................................)( Account 8olicies..............................................................................)( 8assword 8olic"..............................................................................)( 8assword 8olic" +ettin&s............................................................)' 2nforce password histor"......................................................)6 Ma0imum password a&e........................................................)6 Minimum password a&e........................................................): Minimum password len&th.....................................................):
Table of Contents
8assword must meet comple0it" re=uirements.........................); +tore password usin& reversible encr"ption.............................)*ow to 8revent /sers from Chan&in& a 8assword 20cept 3hen 4e=uired..................................................................................)Account !ockout 8olic"....................................................................(0 Account !ockout 8olic" +ettin&s...................................................(0 Account lockout duration.......................................................(0 Account lockout threshold.....................................................(. 4eset account lockout counter after........................................(2 <erberos 8olicies.............................................................................(2 +ecurit" 1ptions.............................................................................(2 +ecurit" 1ptions +ettin&s...........................................................() Microsoft network server$ 7isconnect clients when lo&on hours e0pire................................................................................() etwork Access$ Allow anon"mous +67% AM2 translation..........() etwork +ecurit"$ ,orce !o&off when !o&on *ours e0pire..........(( +ummar"......................................................................................(( More 6nformation......................................................................(' Chapter %: !he Me &er Server 'ase$ine #o$icy..................................%(
1verview.......................................................................................(6 3indows +erver 200) 9aseline 8olic".................................................(Audit 8olic"....................................................................................(Audit account lo&on events.........................................................'. Audit account mana&ement........................................................'2 Audit lo&on events.....................................................................') Audit ob?ect access....................................................................'' Audit polic" chan&e...................................................................': Audit process trackin&................................................................'Audit s"stem events..................................................................60 /ser 4i&hts Assi&nments..................................................................6. Access this computer from the network........................................6( Act as part of the operatin& s"stem..............................................6( Ad?ust memor" =uotas for a process............................................6' Allow lo& on locall"....................................................................6' Allow lo& on throu&h Terminal +ervices.........................................6' 9ack up files and directories........................................................6' 9"pass traverse checkin&...........................................................6' Chan&e the s"stem time.............................................................66 Create a pa&efile.......................................................................66
vi
Create a token ob?ect.................................................................66 Create &lobal ob?ects.................................................................66 Create permanent shared ob?ects................................................66 7ebu& pro&rams.......................................................................6: 7en" access to this computer from the network.............................6: 7en" lo& on as a batch ?ob.........................................................6: 7en" lo&on as a service..............................................................6; 7en" lo&on locall".....................................................................6; 7en" lo& on throu&h Terminal +ervices.........................................6; 2nable computer and user accounts to be trusted for dele&ation......6; ,orce shutdown from a remote s"stem.........................................65enerate securit" audits.............................................................66mpersonate a client after authentication......................................66ncrease schedulin& priorit"........................................................6!oad and unload device drivers...................................................6!ock pa&es in memor"...............................................................:0 !o& on as a service....................................................................:0 Mana&e auditin& and securit" lo&.................................................:0 Modif" firmware environment values............................................:0 8erform volume maintenance tasks..............................................:. 8rofile sin&le process.................................................................:. 8rofile s"stem performance.........................................................:. 4emove computer from dockin& station........................................:. 4eplace a process level token......................................................:. 4estore files and directories........................................................:2 +hut down the s"stem...............................................................:2 +"nchroni>e director" service data...............................................:2 Take ownership of files or other ob?ects........................................:2 +ecurit" 1ptions.............................................................................:2 Accounts +ettin&s......................................................................:) Accounts$ Administrator account status...................................:) Accounts$ 5uest account status.............................................:) Accounts$ !imit local account use of blank passwords to console lo&on onl"...........................................................................:( Audit +ettin&s...........................................................................:( Audit$ Audit the access of &lobal s"stem ob?ects.......................:( Audit$ Audit the use of 9ackup and 4estore privile&e.................:( Audit$ +hut down s"stem immediatel" if unable to lo& securit" audits................................................................................:'
Table of Contents
vii
7evices +ettin&s.......................................................................:' 7evices$ Allow undock without havin& to lo& on........................:' 7evices$ Allowed to format and e?ect removable media.............:' 7evices$ 8revent users from installin& printer drivers................:6 7evices$ 4estrict C7-41M access to locall" lo&&ed-on user onl"..:6 7evices$ 4estrict flopp" access to locall" lo&&ed-on user onl".....:6 7evices$ /nsi&ned driver installation behavior..........................:6 7omain Member +ettin&s...........................................................:: 7omain member$ 7i&itall" encr"pt or si&n secure channel data @alwa"sA.............................................................................:: 7omain member$ 7i&itall" encr"pt secure channel data @when possibleA.............................................................................:: 7omain member$ 7i&itall" si&n secure channel data @when possibleA.............................................................................:; 7omain member$ 7isable machine account password chan&es. . .:; 7omain member$ Ma0imum machine account password a&e......:; 7omain member$ 4e=uire stron& @3indows 2000 or laterA session ke"....................................................................................:; 6nteractive !o&on +ettin&s..........................................................:6nteractive lo&on$ 7ispla" user information when the session is locked................................................................................:6nteractive lo&on$ 7o not displa" last user name......................;0 6nteractive lo&on$ 7o not re=uire CT4!BA!TB72!.....................;0 6nteractive lo&on$ Messa&e te0t for users attemptin& to lo& on. . .;0 6nteractive lo&on$ Messa&e title for users attemptin& to lo& on. . .;0 6nteractive lo&on$ umber of previous lo&ons to cache @in case domain controller is not availableA..........................................;. 6nteractive lo&on$ 8rompt user to chan&e password before e0piration...........................................................................;. 6nteractive lo&on$ 4e=uire 7omain Controller authentication to unlock workstation...............................................................;. 6nteractive lo&on$ 4e=uire smart card.....................................;. 6nteractive lo&on$ +mart card removal behavior.......................;2 Microsoft etwork Client +ettin&s................................................;2
Microsoft network client$ 7i&itall" si&n communications @alwa"sA ;2 Microsoft network client$ 7i&itall" si&n communications @if server a&reesA..............................................................................;) Microsoft network client$ +end unencr"pted password to thirdpart" +M9 servers................................................................;) Microsoft etwork +erver +ettin&s...............................................;)
Microsoft network server$ Amount of idle time re=uired before suspendin& session..............................................................;)
viii
Microsoft network server$ 7i&itall" si&n communications @alwa"sA .........................................................................................;( Microsoft network server$ 7i&itall" si&n communications @if client a&reesA..............................................................................;( Microsoft network server$ 7isconnect clients when lo&on hours e0pire................................................................................;( etwork Access +ettin&s............................................................;' etwork access$ Allow anon"mous +67%name translation...........;6 etwork access$ 7o not allow anon"mous enumeration of +AM accounts.............................................................................;6 etwork access$ 7o not allow anon"mous enumeration of +AM accounts and shares.............................................................;6 etwork access$ 7o not allow stora&e of credentials or . 2T 8assports for network authentication......................................;: etwork access$ !et 2ver"one permissions appl" to anon"mous users.................................................................................;: etwork access$ amed 8ipes that can be accessed anon"mousl" .........................................................................................;: etwork access$ 4emotel" accessible re&istr" paths..................;; etwork access$ 4emotel" accessible re&istr" paths and sub-paths .........................................................................................;; etwork access$ 4estrict anon"mous access to amed 8ipes and +hares...............................................................................;; etwork access$ +hares that can be accessed anon"mousl".......;etwork access$ +harin& and securit" model for local accounts...;etwork +ecurit" +ettin&s..........................................................;etwork securit"$ 7o not store !A Mana&er hash value on ne0t password chan&e.................................................................-0 etwork securit"$ !A Mana&er authentication level.................-0
etwork securit"$ !7A8 client si&nin& re=uirements..................-. etwork securit"$ Minimum session securit" for T!M ++8 based @includin& secure 48CA clients................................................-. etwork securit"$ Minimum session securit" for T!M ++8 based @includin& secure 48CA servers...............................................-2 4ecover" Console +ettin&s..........................................................-2 4ecover" console$ Allow automatic administrative lo&on............-2 4ecover" console$ Allow flopp" cop" and access to all drives and all folders...........................................................................-2 +hutdown +ettin&s....................................................................-) +hutdown$ Allow s"stem to be shut down without havin& to lo& on .........................................................................................-) +hutdown$ Clear virtual memor" pa&e file...............................-) +"stem Cr"pto&raph" +ettin&s....................................................-(
Table of Contents
i0
+"stem cr"pto&raph"$ ,orce stron& ke" protection for user ke"s stored on the computer........................................................-( +"stem cr"pto&raph"$ /se ,68+ compliant al&orithms for encr"ption# hashin&# and si&nin&............................................-( +"stem 1b?ects +ettin&s.............................................................-( +"stem ob?ects$ 7efault owner for ob?ects created b" members of the Administrators &roup......................................................-' +"stem ob?ects$ 4e=uire case insensitivit" for non-3indows subs"stems.........................................................................-' +"stem ob?ects$ +tren&then default permissions of internal s"stem ob?ects @e.&. +"mbolic !inksA.................................................-' +"stem +ettin&s........................................................................-' +"stem settin&s$ 1ptional subs"stems....................................-6 +"stem settin&s$ /se Certificate 4ules on 3indows 20ecutables for +oftware 4estriction 8olicies..................................................-6 2vent !o&......................................................................................-6 Ma0imum application lo& si>e......................................................-: Ma0imum securit" lo& si>e..........................................................-: Ma0imum s"stem lo& si>e...........................................................-: 8revent local &uests &roup from accessin& application lo&...............-; 8revent local &uests &roup from accessin& securit" lo&....................-; 8revent local &uests &roup from accessin& s"stem lo&....................-; 4etention method for application lo&............................................-; 4etention method for securit" lo&................................................-4etention method for s"stem lo&.................................................-Additional 4e&istr" 2ntries...............................................................-+ecurit" Consideration for etwork Attacks..................................00
1ther 4e&istr" 2ntries...............................................................00 Confi&ure et961+ ame 4elease +ecurit"$ Allow the computer to i&nore et961+ name release re=uests e0cept from 36 + servers ........................................................................................02 7isable Auto 5eneration of ;.) ,ile ames$ 2nable the computer to stop &eneratin& ;.) st"le filenames........................................02 7isable Autorun$ 7isable Autorun for all drives........................02 Make +creensaver 8assword 8rotection 6mmediate$ The time in seconds before the screen saver &race period e0pires @0 recommendedA...................................................................02 +ecurit" !o& ear Capacit" 3arnin&$ 8ercenta&e threshold for the securit" event lo& at which the s"stem will &enerate a warnin&. .0) 2nable +afe 7!! +earch 1rder$ 2nable +afe 7!! search mode @recommendedA..................................................................0) Automatic 4eboot$ Allow 3indows to automaticall" restart after a s"stem crash......................................................................0(
Automatic !o&on$ 2nable Automatic !o&on..............................0( Administrative +hares$ 2nable Administrative +hares...............0( 7isable +aved 8asswords$ 8revent the dial-up password from bein& saved........................................................................0( 2nable 68+ec to protect <erberos 4+C8 Traffic$ 2nable o7efault20empt for 68+ec ,ilterin&.......................................0' 4estricted 5roups...........................................................................0' +ecurin& the ,ile +"stem.................................................................0' Additional +ecurit" +ettin&s.............................................................06 Manual *ardenin& 8rocedures.....................................................0: Manuall" Addin& /ni=ue +ecurit" 5roups to /ser 4i&hts Assi&nments.......................................................................0: +ecurin& 3ell-<nown Accounts..............................................0; +ecurin& +ervice Accounts....................................................0T,+.................................................................................0Terminal +ervices +ettin&s....................................................02rror 4eportin&.........................................................................0 2nable Manual Memor" 7umps...............................................0 Creatin& the 9aseline 8olic" /sin& +C3......................................... Test the 8olic" /sin& +C3...........................................................2 Convert and 7eplo" the 8olic".....................................................) +ummar".......................................................................................) More 6nformation.......................................................................) Chapter ): !he "o ain Contro$$er 'ase$ine #o$icy...........................11(
1verview.......................................................................................6 7omain Controller 9aseline 8olic"................................................6 Audit 8olic" +ettin&s........................................................................: Audit director" service access......................................................: /ser 4i&hts Assi&nment +ettin&s.......................................................; Access this computer from the network.........................................; Add workstations to domain........................................................Allow lo& on locall"....................................................................Allow lo& on throu&h Terminal +ervices........................................20 Chan&e the s"stem time............................................................20 2nable computer and user accounts to be trusted for dele&ation......2. !oad and unload device drivers...................................................2. 4estore files and directories.......................................................2. +hutdown the s"stem................................................................22 +ecurit" 1ptions............................................................................22
Table of Contents
0i
7omain Controller +ettin&s........................................................22 7omain controller$ Allow server operators to schedule tasks......22 7omain controller$ !7A8 server si&nin& re=uirements...............2) 7omain controller$ 4efuse machine account password chan&es. .2) etwork +ecurit" +ettin&s..........................................................2) etwork securit"$ 7o not store !A Mana&er hash value on ne0t password chan&e......................................................................2) 2vent !o& +ettin&s.........................................................................2( 4estricted 5roups...........................................................................2( Additional +ecurit" +ettin&s.............................................................2' Manuall" Addin& /ni=ue +ecurit" 5roups to /ser 4i&hts Assi&nments .............................................................................................2' 7irector" +ervices....................................................................26 4elocatin& 7ata D Active 7irector" 7atabase and !o& ,iles........26 4esi>in& Active 7irector" !o& ,iles.........................................26 /sin& +"ske"......................................................................2: Active 7irector"-6nte&rated 7 +.................................................2; 8rotectin& 7 + +ervers........................................................2; Confi&urin& +ecure 7"namic /pdates.....................................2!imitin& Eone Transfers to Authori>ed +"stems........................24esi>in& the 2vent !o& and 7 + +ervice !o&...........................)0 +ecurin& 3ell-<nown Accounts...................................................)0 +ecurin& +ervice Accounts.........................................................)0 Terminal +ervices +ettin&s.........................................................). 2rror 4eportin&........................................................................)2 Creatin& the 8olic" /sin& +C3.........................................................)2 Test the 8olic" /sin& +C3..........................................................)) Convert and 7eplo" the 8olic"....................................................)( +ummar"......................................................................................)( More 6nformation......................................................................)' Chapter (: !he In*rastructure Server +o$e.......................................13( 1verview......................................................................................)6 /ser 4i&hts Assi&nment +ettin&s......................................................): +ecurit" 1ptions............................................................................): 2vent !o& +ettin&s.........................................................................): Additional +ecurit" +ettin&s.............................................................): Confi&ure 7*C8 !o&&in&............................................................): 8rotect A&ainst 7*C8 7enial of +ervice Attacks.............................); +ecurin& 3ell-<nown Accounts...................................................);
0ii
+ecurin& +ervice Accounts.........................................................)Creatin& the 8olic" /sin& +C3.........................................................)Test the 8olic" /sin& +C3..........................................................(0 Convert and 7eplo" the 8olic"....................................................(. +ummar"......................................................................................(. More 6nformation......................................................................(2 Chapter ,: !he -i$e Server +o$e.......................................................1%3 1verview......................................................................................() Audit 8olic" +ettin&s.......................................................................() /ser 4i&hts Assi&nments.................................................................(( +ecurit" 1ptions............................................................................(( 2vent !o& +ettin&s.........................................................................(( Additional +ecurit" +ettin&s.............................................................(( +ecurin& 3ell-<nown Accounts...................................................(( +ecurin& +ervice Accounts.........................................................(' Creatin& the 8olic" /sin& +C3.........................................................(' Test the 8olic" /sin& +C3..........................................................(6 Convert and 7eplo" the 8olic"....................................................(: +ummar"......................................................................................(: More 6nformation......................................................................(: Chapter .: !he #rint Server +o$e.....................................................1%. 1verview......................................................................................(; Audit 8olic" +ettin&s.......................................................................(/ser 4i&hts Assi&nments.................................................................(+ecurit" 1ptions............................................................................(Microsoft network server$ 7i&itall" si&n communications @alwa"sA....(2vent !o& +ettin&s.........................................................................'0 Additional +ecurit" +ettin&s.............................................................'0 +ecurin& 3ell-<nown Accounts...................................................'0 +ecurin& +ervice Accounts.........................................................'0 Creatin& the 8olic" /sin& +C3.........................................................'. Test the 8olic" /sin& +C3..........................................................'2 Convert and 7eplo" the 8olic"....................................................'2 +ummar"......................................................................................') More 6nformation......................................................................') Chapter /: !he We& Server +o$e......................................................1)% 1verview......................................................................................'( Anon"mous Access and the ++!, +ettin&s.........................................''
Table of Contents
0iii
Audit 8olic" +ettin&s.......................................................................'' /ser 4i&hts Assi&nments.................................................................'6 +ecurit" 1ptions............................................................................'6 2vent !o& +ettin&s.........................................................................'6 Additional +ecurit" +ettin&s.............................................................'6 6nstallin& 1nl" ecessar" 66+ Components...................................'6
2nablin& 1nl" 2ssential 3eb +ervice 20tensions............................6( 8lacin& Content on a 7edicated 7isk Colume.................................6' +ettin& T,+ 8ermissions..........................................................66
+ettin& 66+ 3eb +ite 8ermissions................................................66 Confi&urin& 66+ !o&&in&.............................................................6: Manuall" Addin& /ni=ue +ecurit" 5roups to /ser 4i&hts Assi&nments .............................................................................................6; +ecurin& 3ell-<nown Accounts...................................................6+ecurin& +ervice Accounts.........................................................:0 Creatin& the 8olic" /sin& +C3.........................................................:0 Test the 8olic" /sin& +C3..........................................................:. Convert and 7eplo" the 8olic"....................................................:. +ummar"......................................................................................:2 More 6nformation......................................................................:2 Chapter 10: !he I0S Server +o$e.....................................................1,3 1verview......................................................................................:) Audit 8olic"...................................................................................:) /ser 4i&hts Assi&nments.................................................................:( +ecurit" 1ptions............................................................................:( 2vent !o&.....................................................................................:( Additional +ecurit" +ettin&s.............................................................:( +ecurin& 3ell-<nown Accounts...................................................:( +ecurin& +ervice Accounts.........................................................:' Creatin& the 8olic" /sin& +C3.........................................................:' Test the 8olic" /sin& +C3..........................................................:6 Convert and 7eplo" the 8olic"....................................................:: +ummar"......................................................................................:: More 6nformation......................................................................:; Chapter 11: !he Certi*icate Services Server +o$e.............................1,/ 1verview......................................................................................:Audit 8olic" +ettin&s.......................................................................;0 /ser 4i&hts Assi&nments.................................................................;0
0iv
+ecurit" 1ptions............................................................................;0 +"stem cr"pto&raph"$ /se ,68+ compliant al&orithms for encr"ption# hashin&# and si&nin&.................................................................;. 2vent !o& +ettin&s.........................................................................;. Additional 4e&istr" 2ntries...............................................................;. Additional +ecurit" +ettin&s.............................................................;2 ,ile +"stem AC!s......................................................................;2 +ecurin& 3ell-<nown Accounts...................................................;) +ecurin& +ervice Accounts.........................................................;( Creatin& the 8olic" /sin& +C3.........................................................;( Test the 8olic" /sin& +C3..........................................................;' Convert and 7eplo" the 8olic"....................................................;6 +ummar"......................................................................................;6 More 6nformation......................................................................;6 Chapter 12: !he 'astion Host +o$e..................................................1., 1verview......................................................................................;: 9astion *ost !ocal 8olic"............................................................;: Audit 8olic" +ettin&s.......................................................................;; /ser 4i&hts Assi&nments.................................................................;; 7en" access to this computer from the network............................;; +ecurit" 1ptions............................................................................;; 2vent !o& +ettin&s.........................................................................;Additional +ecurit" +ettin&s.............................................................;Manuall" Addin& /ni=ue +ecurit" 5roups to /ser 4i&hts Assi&nments .............................................................................................;+ecurin& 3ell-<nown Accounts...................................................-0 2rror 4eportin&........................................................................-0 Creatin& the 8olic" /sin& +C3.........................................................-. Test the 8olic" /sin& +C3..........................................................-2 6mplement the 8olic"................................................................-2 +ummar"......................................................................................-) More 6nformation......................................................................-) Chapter 13: Conc$usion...................................................................1/% More 6nformation......................................................................-' 0ppendi1 0: Security !oo$s and -or ats..........................................1/(
+ecurit" Tools................................................................................-6 +ecurit" Confi&uration 3i>ard.....................................................-6 +ecurit" Confi&uration 2ditor......................................................-6 Active 7irector" /sers and Computers.........................................-:
Table of Contents
0v
5roup 8olic" Mana&ement Console..............................................-: +ecurit" ,ile ,ormats......................................................................-: +C3 8olic" @.0mlA.....................................................................-: 8olic" Template @.infA................................................................-; 5roup 8olic" 1b?ects.................................................................-; 0ppendi1 ': 2ey Settings to Consider..............................................200 0ppendi1 C: Security !e p$ate Setting Su ary............................202
0ppendi1 ": !esting the Windows Server 2003 Security Guide........20% 1verview.....................................................................................20( +cope....................................................................................20( Test 1b?ectives........................................................................20( Test 2nvironment..........................................................................20' Testin& Methodolo&"......................................................................20: 8hases in a Test 8ass...............................................................20; Test 8reparation 8hase........................................................20; +ecurit" Confi&uration 9uild 8hase........................................20; Test 20ecution 8hase..........................................................2.. T"pes of Tests.........................................................................2.. Client +ide Tests ...............................................................2.. 7ocumentation 9uild Tests...................................................2.2 +cript Tests ......................................................................2.2 +erver +ide Tests ..............................................................2.2 8ass and ,ail Criteria................................................................2.2 4elease Criteria.......................................................................2.2 9u& Classification....................................................................2.) +ummar".....................................................................................2.( Acknowled&ments.........................................................................2.' Authors............................................................................2.' Content Contributors..........................................................2.' 8ro&ram Mana&ers.............................................................2.' 2ditors..............................................................................2.' 4elease Mana&ers..............................................................2.' Testers.............................................................................2.' 4eviewers.........................................................................2.' 1ther Contributors.............................................................2.6
,eedback
0vi
Feedback
The Microsoft Solutions for Security and Compliance team would appreciate your thoughts about this and other security solutions. Have an opinion? Let us know on the secguide s !ebLog at http"##blogs.technet.com#secguide. $r e%mail your feedback to the following address" secwish&microsoft.com. !e look forward to hearing from you.
Chapter 1: Introduction to the Windows Server 2003 Security Guide

Overview
!elcome to the Windows Server 2003 Security Guide. This guide is designed to provide you with the best information available to assess and counter security risks in your organi'ation that are specific to Microsoft( !indows Server) *++, with Service -ack . /S-.0. The chapters in this guide provide detailed guidance about how to enhance security setting configurations and features in !indows Server *++, with S-. wherever possible to address threats that you have identified in your environment. This guide was created for systems engineers1 consultants and network administrators who work in a !indows Server *++, with S-. environment. This guide was reviewed and approved by Microsoft engineering teams1 consultants1 support engineers1 as well as customers and partners. Microsoft worked with consultants and systems engineers who have implemented !indows Server *++,1 !indows( 2-1 and !indows *+++ in a variety of environments to help establish the latest best practices to secure these servers and clients. This best practice information is described in detail in this guide. The companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2- /available at http"##go.microsoft.com#fwlink#? Link3d4.5.5601 provides a comprehensive overview of all of the ma7or security settings that are present in !indows Server *++, with S-. and !indows 2- with S-*. Chapters * through .* of this guide include step%by%step security prescriptions1 procedures1 and recommendations to provide you with task lists that will help you achieve an elevated level of security for those computers that run !indows Server *++, with S-. in your organi'ation. 3f you want more in%depth discussion of the concepts behind this material1 refer to resources such as the Microsoft Windows Server 2003 Resource Kit1 the Microsoft Windows XP Resource Kit1 the Microsoft Windows 2000 Security Resource Kit1 and Microsoft Tech8et.
!ecutive Su""ary
!hatever your environment1 you are strongly advised to be serious about security issues. Many organi'ations underestimate the value of their information technology /3T0 environment1 often because they e9clude substantial indirect costs. 3f an attack on the servers in your environment is severe enough1 it could significantly damage the entire organi'ation. :or e9ample1 an attack in which your organi'ation;s !eb site is brought down could cause a ma7or loss of revenue or customer confidence1 which could affect your organi'ation;s profitability. !hen you evaluate security costs1 you should include the indirect costs that are associated with any attack in addition to the costs of lost 3T functionality. <ulnerability1 risk1 and e9posure analysis with regard to security informs you of the tradeoffs between security and usability that all computers are sub7ect to in a networked
environment. This guide documents the ma7or security countermeasures that are available in !indows Server *++, with S-.1 the vulnerabilities that they address1 and the potential negative conse=uences /if any0 of each countermeasure s implementation. The guide then provides specific recommendations about how to harden computers that run !indows Server *++, with S-. in three distinct enterprise environments. The Legacy Client /LC0 environment must support older operating systems such as !indows 6>. The ?nterprise Client /?C0 environment is one in which !indows *+++ is the earliest version of the !indows operating system in use. The third environment is one in which concern about security is so great that significant loss of client functionality and manageability is considered an acceptable tradeoff to achieve the highest level of security. This third environment is known as the Speciali'ed Security @ Limited :unctionality /SSL:0 environment. ?very effort has been made to make this information well organi'ed and easily accessible so that you can =uickly find and determine which settings are suitable for the computers in your organi'ation. Although this guide is targeted at the enterprise customer1 much of it is appropriate for organi'ations of any si'e. To get the most value out of the material1 you will need to read the entire guide. Bou can also refer to the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 at http"##go.microsoft.com#fwlink#?Link3d4.5.56. The team that produced this guide hopes that you will find the material covered in it useful1 informative1 and interesting.
Who Shou#d $ead %his Guide

This guide is primarily intended for consultants1 security specialists1 systems architects1 and 3T professionals who plan application or infrastructure development and the deployment of !indows Server *++,. These roles include the following common 7ob descriptions" Architects and planners who drive the architecture efforts for the clients in their organi'ations. 3T security specialists who are focused purely on how to provide security across the platforms within their organi'ations. Cusiness analysts and business decision makers /CDMs0 with critical business ob7ectives and re=uirements that depend on client support. Consultants from both Microsoft Services and partners who need detailed resources of relevant and useful information for enterprise customers and partners.
Scope o& this Guide

This guide focuses on how to create and maintain a secure environment for computers that run !indows Server *++, with S-. in your organi'ation. The guidance e9plains the different stages of how to secure the three environments that are defined in the guide1 and what each prescribed server setting addresses in terms of client dependencies. The three environments are described as follows" The Legacy Client /LC0 environment consists of an Active Directory( directory service domain with member servers and domain controllers that run !indows Server *++, and some client computers that run Microsoft !indows 6> and !indows 8T( E.+. Computers that run !indows 6> must have the Active Directory Client ?9tension /DSCLient0 installed. More information is available in the Microsoft Fnowledge Case article GHow to install the Active Directory client e9tensionG at http"##support.microsoft.com#kb#*>>,5>.
Chapter .$ 6ntroduction to the 3indows +erver 200) +ecurit" 5uide
The ?nterprise Client /?C0 environment consists of an Active Directory domain with member servers and domain controllers that run !indows Server *++, with S-. and client computers that run !indows *+++ and !indows 2-. The Speciali'ed Security @ Limited :unctionality /SSL:0 environment also consists of an Active Directory domain with member servers and domain controllers that run !indows Server *++, with S-. and clients that run !indows *+++ and !indows 2-. However1 the Speciali'ed Security @ Limited :unctionality settings are so restrictive that many applications may not function. :or this reason1 the servers; performance may be affected1 and it will be more of a challenge to manage the servers. Also1 client computers that are not secured by the SSL: policies could e9perience communication problems with client computers and servers that are secured by the SSL: policies. See the Windows XP Security Guide for information about how to secure client computers with SSL:%compatible settings.
Huidance about ways to harden computers in these three environments is provided for a group of distinct server roles. The countermeasures that are described and the tools that are provided assume that each server will have a single role. 3f you need to combine roles for some of the servers in your environment1 you can customi'e the security templates that are included in the download that accompanies this guide to create the appropriate combination of services and security options. The roles that are described in this guide include" Domain controllers 3nfrastructure servers :ile servers -rint servers 3nternet 3nformation Services /33S0 servers 3nternet Authentication Services /3AS0 servers Certificate Services servers Castion hosts
The recommended settings in this guide were tested thoroughly in lab environments that simulated the previously described Legacy Client1 ?nterprise Client1 and Speciali'ed Security @ Limited :unctionality environments. These settings were proven to work in the lab1 but it is important that your organi'ation test these settings in your own lab that accurately represents your production environment. 3t is likely that you will need to make some changes to the security templates and the manual procedures that are documented within this guide so that all of your business applications continue to function as e9pected. The detailed information that is provided in the companion guide1 Threats and Countermeasures Security Settin!s in Windows Server 2003 and Windows XP1 provides the information that you need to assess each specific countermeasure and to decide which of them are appropriate for your organi'ation s uni=ue environment and business re=uirements.
Chapter Su""aries
The Windows Server 2003 Security Guide consists of ., chapters. ?ach chapter builds on the end%to%end solution process that is re=uired to implement and secure !indows Server *++, with S-. in your environment. The first few chapters describe how to build a foundation that will allow you to harden the servers in your organi'ation1 and the rest of the chapters document the procedures that are uni=ue to each server role.
Chapter 1: Introduction to the Windows Server 2003 Security Guide

This chapter introduces the Windows Server 2003 Security Guide and includes a brief overview of each chapter. 3t describes the Legacy Client1 ?nterprise Client1 and Speciali'ed Security @ Limited :unctionality environments and the computers that run in them.
Chapter 2: Windows Server 2003 'ardenin( )echanis"s

This chapter provides an overview of the main mechanisms that are used to harden !indows Server *++, S-. in this guideIthe Security Configuration !i'ard /SC!0 and Active Directory Hroup -olicy. 3t e9plains how SC! provides an interactive framework to create1 manage1 and test security policies for !indows servers that serve in different roles. 3t also evaluates the capabilities of SC! within the conte9t of the three environments that are described in Chapter .. The ne9t part of this chapter provides high%level descriptions of Active Directory design1 organi'ational unit /$J0 design1 Hroup -olicy $b7ects /H-$s01 administrative group design1 and domain policy. These topics are discussed in the conte9t of the three environments that are described in Chapter . to provide a vision of an ideal secure end% state environment. This chapter concludes with a detailed e9amination of how this guide combines the best features of SC! and traditional H-$%based approaches to harden !indows Server *++, with S-..
Chapter 3: %he *o"ain +o#icy

This chapter e9plains security template settings and additional countermeasures for the domain%level policies in the three environments that are described in Chapter .. The chapter does not focus on any specific server role1 but on the specific policies and settings that are useful for top%level domain policies.
Chapter ,: %he )e"ber Server -ase#ine +o#icy

This chapter e9plains security template settings and additional countermeasures for the different server roles in the three environments that are described in Chapter .. The chapter focuses on how to establish a Member Server Caseline -olicy /MSC-0 for the server roles that are discussed later in the guide. The recommendations in this chapter are designed to allow organi'ations to safely deploy setting configurations for both e9isting and new deployments of !indows Server *++, with S-.. The default security configurations within !indows Server *++, S-. were researched and tested1 and the recommendations in this chapter were determined to provide greater security than the default operating system settings. $ccasionally1 a less restrictive setting is suggested than the one that is present in the default installation of !indows Server *++, with S-. to provide support for Legacy Client environments.
'
Chapter .: %he *o"ain Contro##er -ase#ine +o#icy

The domain controller server role is one of the most important roles to secure in any Active Directory environment with computers that run !indows Server *++, with S-.. Any loss or compromise of a domain controller could seriously affect client computers1 servers1 and applications that rely on domain controllers for authentication1 Hroup -olicy1 and a central lightweight directory access protocol /LDA-0 directory. This chapter describes the need to always store domain controllers in physically secure locations that are accessible only to =ualified administrative staff. The ha'ards of domain controllers in unsecured locations such as branch offices are addressed1 and a significant portion of the chapter is devoted to an e9planation of the security considerations that are the basis for the recommended Domain Controller Hroup -olicy. Active Directory domain controllers re=uire a stable1 properly configured D8S service. Cy default1 !indows Server *++, with S-. integrates D8S 'ones into Active Directory1 which allows domain controllers to run the D8S service and answer D8S re=uests for clients in the Active Directory domain. This chapter assumes that the domain controller will also provide D8S service and provides the appropriate guidance.
Chapter /: %he In&rastructure Server $o#e

3n this chapter1 the infrastructure server role is defined as either a DHC- server or a !38S server. Details are provided about how the !indows Server *++, with S-. infrastructure servers in your environment can benefit from security settings that are not applied by the Member Server Caseline -olicy /MSC-0. This chapter does not include configuration information for the D8S service1 which is included in the domain controller role.
Chapter 0: %he Fi#e Server $o#e

This chapter focuses on the :ile server role and the difficult aspects of how to harden such servers. The most essential services for file servers re=uire use of !indows 8etC3$S%related protocols and the SMC and C3:S protocols. The Server Message Clock /SMC0 and Common 3nternet :ile System /C3:S0 protocols are typically used to provide access for authenticated users1 but when improperly secured they can also disclose rich information to unauthenticated users or attackers. Cecause of this threat1 these protocols are often disabled in high%security environments. This chapter describes how file servers that run !indows Server *++, with S-. can benefit from security settings that are not applied by the MSC-.
Chapter 1: %he +rint Server $o#e

This chapter focuses on print servers. Like file servers1 the most essential services for print servers re=uire use of !indows 8etC3$S%related protocols and the SMC and C3:S protocols. As stated earlier1 these protocols are often disabled in high%security environments. This chapter describes how !indows Server *++, with S-. print server security settings can be strengthened in ways that are not applied by the MSC-.
Chapter 2: %he Web Server $o#e

This chapter describes how comprehensive security for !eb sites and applications re=uires an entire 33S server /including each !eb site and application that runs on the 33S server0 to be protected from client computers in its environment. !eb sites and
applications also must be protected from other !eb sites and applications that run on the same 33S server. -ractices to ensure that these measures are achieved by the 33S servers that run !indows Server *++, with S-. in your environment are described in detail in this chapter. 33S is not installed on members of the Microsoft !indows Server System) family by default. !hen 33S is initially installed1 it is in a highly secure GlockedG mode. :or e9ample1 the default settings only allow 33S to serve static content. :eatures such as Active Server -ages /AS-01 AS-.8?T1 Server%Side 3ncludes1 !ebDA< publishing1 and Microsoft :ront-age( Server ?9tensions must be enabled by the administrator through the !eb Service ?9tensions node in 3nternet 3nformation Services Manager /33S Manager0. Sections in this chapter provide details about a variety of settings you can use to harden the 33S servers in your environment. The need to monitor1 detect1 and respond to security issues is emphasi'ed to ensure that the servers stay secure. This chapter focuses on 33S !eb protocols and applications1 such as HTT-1 and does not include guidance on the other protocols that 33S can provide1 such as SMT-1 :T-1 and 88T-.
Chapter 10: %he I3S Server $o#e

3nternet Authentication Servers /3AS0 provide Kemote Authentication Dial%3n Jser Services /KAD3JS01 a standards%based authentication protocol that is designed to verify the identity of clients who access networks remotely. This chapter describes ways in which 3AS servers that run !indows Server *++, with S-. can benefit from security settings that are not applied by the MSC-.
Chapter 11: %he Certi&icate Services Server $o#e

Certificate Services provide the cryptographic and certificate management services that are needed to build a public key infrastructure /-F30 in your server environment. This chapter describes ways in which Certificate Services servers that run !indows Server *++, with S-. will benefit from security settings that are not applied by the MSC-.
Chapter 12: %he -astion 'osts $o#e

Castion host servers are accessible to client computers from the 3nternet. 3n this chapter1 it is e9plained how these publicly e9posed computers are susceptible to attack from a large number of users who can remain completely anonymous if they wish. Many organi'ations do not e9tend their domain infrastructure to the 3nternet. :or this reason1 this chapter content focuses on how to harden stand%alone computers. Details are provided about ways in which bastion hosts that run !indows Server *++, with S-. can benefit from the security recommendations in this guide for computers that are not members of an Active Directory@based domain.
Chapter 13: Conc#usion

The concluding chapter of this guide reviews the important points of the material that was presented in the previous chapters.
3ppendi! 3: Security %oo#s and For"ats

Although this guide focuses on how to use SC! to create policies which are then converted to security templates and Hroup -olicy ob7ects1 there are a variety of other tools and file formats that can be used to augment or replace this methodology. This appendi9 provides a short list of these tools and formats.
3ppendi! -: 4ey Settin(s to Consider

This guide discusses many security countermeasures and security settings1 but it is important to understand a small number of them are particularly important. This appendi9 discusses the settings that will have the biggest impact on security of computers that run !indows Server *++, with S-..
3ppendi! C: Security %e"p#ate Settin( Su""ary

This appendi9 introduces the Microsoft ?9cel( workbook G!indows Server *++, Security Huide Settings1G which is included with the tools and templates in the downloadable version of this guide at http"##go.microsoft.com#fwlink#?Link3d4.E>EL. This spreadsheet provides a comprehensive master reference in a compact1 usable form of all of the recommended settings for the three environments that are defined in this guide.
3ppendi! *: %estin( the Windows Server 2003 Security Guide

This guide provides a significant amount of information about how to harden servers that run !indows Server *++, with S-.1 but the reader is constantly cautioned to test and validate all settings before they implement any settings in a production environment. This appendi9 provides guidance about how to create a suitable test lab environment that can be used to help ensure successful implementation of the recommended settings in a production environment. 3t helps users to perform necessary validation and minimi'es the amount of resources that are needed to do so.
%oo#s and %e"p#ates

A collection of security templates1 scripts1 and additional tools are included with the downloadable version of this guide to help your organi'ation to evaluate1 test1 and implement the recommended countermeasures. The security templates are te9t files that can be imported into domain@based Hroup -olicies or applied locally with the Microsoft Management Console /MMC0 Security Configuration and Analysis snap%in. These procedures are detailed in Chapter *1 G!indows Server *++, Hardening Mechanisms.G The scripts that are included with this guide include scripts to create and link Hroup -olicy ob7ects as well as test scripts that are used to test the recommended countermeasures. Also included is the ?9cel workbook that summari'es the security template settings /referenced in the earlier GAppendi9 CG section0.
The files that accompany this guide are collectively referred to as tools and templates. These files are included in a .msi file within the self%e9tracting !inMip archive that contains this guide1 which is available on the Microsoft Download Center at http"##go.microsoft.com#fwlink#?Link3d4.E>EL. !hen you e9ecute the .msi file1 the following folder structure will be created in the location you specify" \Windows Server 2003 Security Guide Tools and Templates\Security Templates. This folder contains all security templates that are discussed in the guide. \Windows Server 2003 Security Guide Tools and Templates\Test Tools. This folder contains various files and tools that relate to GAppendi9 D" Testing the !indows Server *++, Security Huide.G
Ski##s and $eadiness

3T professionals who develop1 deploy1 and secure installations of !indows Server *++, and !indows 2- in an enterprise environment re=uire the following knowledge and skills" MCS? *+++ or *++, certification with more than two years of security%related e9perience. 3n%depth knowledge of organi'ational domain and Active Directory environments. Jse of management tools1 including the Microsoft Management Console /MMC01 Secedit1 Hpupdate1 and Hpresult. ?9perience in the administration of Hroup -olicy. ?9perience in the deployment of applications and workstation computers in enterprise environments.
So&tware $e5uire"ents
The software re=uirements for the tools and templates that are documented in this guide are" !indows Server *++, Standard ?dition with S-.1 !indows Server *++, ?nterprise ?dition with S-.1 or !indows Server *++, Datacenter ?dition with S-.. A !indows Server *++,@based Active Directory domain. Microsoft ?9cel *+++ or later.
Sty#e Conventions
This guide uses the following style conventions and terminology. Table 1 1 Style Conventions !lement #old font Meanin" Signifies characters typed e9actly as shown1 including commands1 switches1 and file names. Jser interface elements also appear in bold. Titles of books and other substantial publications appear in italic.
"ta#ic font
!lement $"ta#ic% Monospace font

3ote I portant
Meanin" -laceholders set in italic and angle brackets $fi#e name% represent variables. Defines code and script samples. Alerts the reader to supplementary information. Alerts the reader to essential supplementary information.
Su""ary
This chapter provided an overview of the primary factors that are involved to secure computers that run !indows Server *++, with S-.1 which are considered and discussed in greater detail in the rest of the guide. 8ow that you understand how this guide is organi'ed1 you can decide whether to read it from beginning to end or select only those sections that interest you. However1 it is important to remember that effective and successful security operations re=uire improvements in all of the areas that are discussed in this guide1 not 7ust a few. :or this reason1 Microsoft recommends that you read the entire guide to take full advantage of all the information it contains to secure computers that run !indows Server *++, with S-. in your organi'ation.
)ore In&or"ation
The following links provide additional information about topics that relate to security and !indows Server *++, with S-.. :or more information about security at Microsoft1 see the Trustworthy Computing page at www.microsoft.com#mscorp#twc#default.msp9. :or more details about how M$: can assist in your enterprise1 see the Microsoft $perations :ramework page at www.microsoft.com#technet#itsolutions#cits#mo#mof#default.msp9. :or information about Microsoft security notifications1 see the Microsoft Security Culletin Search page at www.microsoft.com#technet#security#current.asp9.
Chapter 2: Windows Server 2003 'ardenin( )echanis"s

Overview
This chapter introduces the mechanisms that can be used to implement security settings on Microsoft( !indows Server) *++,. Service -ack . /S-.0 of !indows Server *++, provides the Security Configuration !i'ard /SC!01 a new role%based tool you can use to make your servers more secure. !hen used in con7unction with Hroup -olicy ob7ects /H-$s01 SC! allows greater control1 fle9ibility1 and consistency in the hardening process. This chapter focuses on the following topics" How SC! is used to create1 test1 and deploy role%based hardening policies. How the Active Directory( directory service facilitates consistent enterprise hardening through the use of H-$s. How the Active Directory domain design1 the organi'ational unit /$J0 design1 Hroup -olicy design1 and administrative group design affect security deployments. How to use both SC! and Hroup -olicy to create a manageable1 role%based approach to harden servers that run !indows Server *++, with S-..
This information provides a foundation and a vision that you can use to evolve from a Legacy Client /LC0 environment to a Speciali'ed Security @ Limited :unctionality /SSL:0 environment within a domain infrastructure.
'ardenin( with the Security Con&i(uration Wi6ard

The purpose of SC! is to provide a fle9ible1 step%by%step process to reduce the attack surface on servers that run !indows Server *++, with S-.. SC! is actually a collection of tools that is combined with an 2ML rules database. 3ts purpose is to help administrators =uickly and accurately determine the minimum functionality that is re=uired for the roles that specific servers must fulfill. !ith SC!1 administrators can author1 test1 troubleshoot1 and deploy security policies that disable all non%essential functionality. 3t also provides the ability to roll back security policies. SC! provides native support for security policy management on single servers as well as groups of servers that share related functionality. SC! is a comprehensive tool that can help you accomplish the following tasks" Determine which services must be active1 which services need to run when re=uired1 and which services can be disabled. Manage network port filtering in combination with !indows :irewall. Control which 33S !eb e9tensions are allowed for !eb servers.
Chapter 2$ 3indows +erver 200) *ardenin& Mechanisms
..
Keduce protocol e9posure to the server message block /SMC0%based protocols1 8etC3$S1 Common 3nternet :ile System /C3:S01 and Lightweight Directory Access -rotocol /LDA-0. Create useful Audit policies that capture the events of interest.
Detailed instructions about how to install1 use1 and troubleshoot SC! are available in a downloadable version of the Security Configuration !i'ard Documentation at www.microsoft.com#downloads#details.asp9?:amily3D46+,fdE6L%6eb6%EaE5%aa++% ,f*f*+fdL.N.Odisplaylang4en.
3ote: +C3 can onl" be used with 3indows +erver 200) with +8.. 6t cannot be used to create policies for 3indows 2000 +erver# 3indows F8# or 3indows +mall 9usiness +erver 200). To harden si&nificant numbers of computers that run these operatin& s"stems# "ou will need to take advanta&e of the 5roup 8olic"Dbased hardenin& mechanisms described later in this chapter.
Creatin( and %estin( +o#icies

Bou can use SC! to rapidly create and test security policies for multiple servers or groups of servers from a single computer. This capability allows you to manage policies throughout the enterprise from a single location. These policies provide consistent1 supported hardening measures that are appropriate for the functions that each server provides within the organi'ation. 3f you use SC! to create and test policies1 you should deploy SC! to all targeted servers. Although you create the policy on a management station1 SC! will attempt to communicate with the target servers to inspect their configuration and fine%tune the resulting policy. SC! is integrated with the 3-sec and !indows :irewall subsystems and will modify those settings accordingly. Jnless prevented1 SC! will configure the !indows :irewall to permit inbound network traffic to important ports that are re=uired by the operating system as well as listening applications. 3f additional port filters are re=uired1 SC! can create them. As a result1 policies that are created by SC! address the need for custom scripts to set or modify 3-sec filters to block unwanted traffic. This capability simplifies the management of network hardening. The configuration of network filters for services that make use of K-C or dynamic ports can also be simplified. SC! also provides the capability to significantly customi'e the policies that you create. This fle9ibility helps you create a configuration that permits necessary functionality but also helps to reduce security risks. 3n addition to the baseline behaviors and settings1 you can override SC! in the following areas" Services 8etwork ports !indows :irewall%approved applications Kegistry settings 33S settings 3nclusion of pre%e9isting security templates /.inf files0
SC! advises the administrator about some of the most important registry settings. To reduce the comple9ity of the tool1 the designers chose to only include those settings that have the greatest impacts on security. However1 this guide discusses many more registry settings. To overcome the limitations of SC!1 you can combine security templates with the results of SC! to create a more complete configuration. !hen you use SC! to create a new policy1 it uses the current configuration of a server as an initial configuration. Therefore1 you should target a server of the same type as the servers on which you intend to deploy the policy so that you can accurately describe the configuration of the server s roles. !hen you use the SC! graphical user interface /HJ30
.2
to create a new policy1 it creates an 2ML file and saves it in the $systemdir $\security\msscw\%olicies folder by default. After you create your policies1 you can use either the SC! HJ3 or the Scwcmd command%line tool to apply the policies to your test servers. !hen you test the policies1 you may need to remove a policy that you deployed. Bou can use either the HJ3 or the command%line tool to roll back the last policy you applied to a server or group of servers. SC! saves the previous configuration settings in 2ML files. :or organi'ations that have limited resources to design and test security configurations1 SC! may be sufficient. Those organi'ations that lack such resources should not even attempt to harden servers1 because such efforts often result in une9pected problems and lost productivity. 3f your organi'ation does not have the e9pertise and time available to deal with these types of issues1 then you should focus on other important security activities such as application and operating system upgrades to current versions and update management.
*ep#oyin( +o#icies
There are three different options you can use to deploy your policies" Apply the policy with the SC! HJ3 Apply the policy with the Scwcmd command%line tool Convert the SC! policy to a Hroup -olicy ob7ect and link it to a domain or $J
?ach option has its own advantages and drawbacks1 which are described in the following subsections.
&pply t'e %olicy wit' t'e SCW G()

The main advantage of the SC! HJ3 option is simplicity. The HJ3 permits administrators to easily select a predefined policy and apply it to a single computer. The disadvantage of the SC! HJ3 option is that it only permits application of policies to a single computer at a time. This option does not scale for large environments1 and this guide does not use this method.
&pply t'e %olicy wit' t'e Scwcmd Command*line Tool

$ne way to apply native SC! policies to multiple computers without Active Directory is to use the Scwcmd tool. Bou can also combine the use of Scwcmd with scripting technologies to provide a degree of automated policy deployment1 perhaps as part of an e9isting process that is used to build and deploy servers. The main disadvantage of the Scwcmd option is that it is not automatic. Bou have to specify the policy and target server1 either manually or through some scripting solution1 which means there are multiple chances to push the wrong policy to the wrong computer. 3f you have servers in a group with slightly different configurations1 you will need to craft a separate policy for each of those computers and apply them separately. Cecause of these limitations1 this guide does not use this method.
Convert t'e SCW %olicy to a Group %olicy +b,ect

The third option for SC! policy deployment is to use the Scwcmd tool to convert the 2ML%based policy into a Hroup -olicy ob7ect /H-$0. Although at first this conversion might seem to be an unnecessary step1 its advantages include the following"
.)
-olicies are replicated1 deployed1 and applied with familiar Active Directory@based mechanisms. Cecause they are native H-$s1 policies can be used with $Js1 policy inheritance1 and incremental policies to fine%tune the hardening of servers that are configured similarly but not e9actly the same as other servers. !ith Hroup -olicy1 you put these servers in a child $J and apply an incremental policy1 whereas with SC! you would need to create a new policy for each uni=ue configuration. -olicies are automatically applied to all servers that are placed in the corresponding $Js. 8ative SC! policies must be either manually applied or used in con7unction with some custom scripting solution.
'ardenin( Servers with 3ctive *irectory Group +o#icy

Active Directory enables applications to find1 use1 and manage directory resources in a distributed computing environment. Although detailed information about how to design an Active Directory infrastructure could fill an entire book1 this section briefly discusses these concepts to establish a conte9t for the rest of the guide. This design information is necessary to provide insight into the use of Hroup -olicy to securely administer your organi'ation s domains1 domain controllers1 and specific server roles. 3f your organi'ation already has an Active Directory design1 this chapter may provide insight into some of its security benefits or potential issues. This guide does not offer any specific guidance about how to secure the Active Directory database. :or such guidance1 see the GCest -ractice Huide for Securing Active Directory 3nstallationsG at www.microsoft.com#downloads#details.asp9?:amily3D4EeN,E+L5%,f.>% E>>a%be.e%f+,,6+ec5f6.O. !hen you create an Active Directory infrastructure1 you must carefully consider the environment s security boundaries. 3f you ade=uately plan an organi'ation s security delegation and implementation schedule1 the result will be a more secure Active Directory design for the organi'ation. Bou should only need to restructure the design for ma7or changes to the environment1 such as an ac=uisition or reorgani'ation.
3ctive *irectory -oundaries

There are several different types of boundaries within Active Directory. These boundaries define the forest1 the domain1 the site topology1 and permission delegation1 and they are automatically established when you install Active Directory. However1 you must ensure that permission boundaries incorporate organi'ational re=uirements and policies. Administrative permissions delegation can be =uite fle9ible to accommodate different organi'ations re=uirements. :or e9ample1 to maintain a proper balance between security and administrative functionality1 you can divide the permission delegation boundaries between security boundaries and administrative boundaries.
Security #oundaries
Security boundaries help define the autonomy or isolation of different groups within an organi'ation. 3t is difficult to balance the tradeoffs between ade=uate security /based on how the organi'ation;s business boundaries are established0 and the need to maintain a consistent level of base functionality. To successfully achieve this balance1 you must weigh the threats to your organi'ation against the security implications of delegated administration permissions and other choices that involve your environment s network architecture.
.(
The forest is the true security boundary of your network environment. This guide recommends that you create separate forests to keep your environment secure from potential compromise by administrators of other domains. This approach also helps ensure that the compromise of one forest does not automatically lead to the compromise of the entire enterprise. A domain is a management boundary of Active Directory1 not a security boundary. !ith an organi'ation of well%intentioned individuals1 a domain boundary will provide autonomous management of services and data within each domain of the organi'ation. Jnfortunately1 with regard to security1 isolation is not so simple to achieve. A domain1 for e9ample1 will not completely isolate an attack from a rogue domain administrator. This level of separation can only be achieved at the forest level. !ithin the domain1 the organi'ational unit /$J0 provides another level of management boundary. $Js provide a fle9ible way to group related resources and delegate management access to the appropriate personnel without providing them the ability to manage the entire domain. Like domains1 $Js are not a true security boundary. Although you can assign permissions to an $J1 all $Js in the same domain authenticate resources against the domain and forest resources. Still1 a well%designed $J hierarchy will aid the development1 deployment1 and management of effective security measures. Bour organi'ation may need to consider divided administrative control of services and data within the current Active Directory design. ?ffective Active Directory design re=uires that you completely understand your organi'ation s re=uirements for service autonomy and isolation as well as for data autonomy and isolation.
&dministrative #oundaries
Cecause of the potential need to segment services and data1 you must define the different administration levels that are re=uired. 3n addition to administrators who may perform uni=ue services for your organi'ation1 this guidance recommends that you consider the following types of administrators.
Service Administrators
Active Directory service administrators are responsible for the configuration and delivery of the directory service. :or e9ample1 service administrators maintain domain controller servers1 control directory%wide configuration settings1 and ensure service availability. Bou should consider the Active Directory administrators in your organi'ation to be your service administrators. The Active Directory service configuration is often determined by attribute values. These attribute values correspond to settings for their respective ob7ects1 which are stored in the directory. Conse=uently1 service administrators in Active Directory are also data administrators. Bour organi'ational needs may re=uire you to consider other service administrator groups for your Active Directory service design. Some e9amples include" A domain administration group that is primarily responsible for directory services. The forest administrator chooses the group to administer each domain. Cecause of the high%level access that is granted to the administrator for each domain1 these administrators should be highly trusted individuals. The domain administrators control the domains through the -omain &dministrators group and other built%in groups. Hroups of administrators who manage D8S. The D8S administrator group completes the D8S design and manages the D8S infrastructure. The D8S administrator manages the D8S infrastructure through the -.S &dministrators group. Hroups of administrators who manage $Js.
.'
The $J administrator designates a group or individual as a manager for each $J. ?ach $J administrator manages the data that is stored within the assigned Active Directory $J. These groups can control how administration is delegated1 and how policy is applied to ob7ects within their $Js. $J administrators can also create new subtrees and delegate administration of the $Js for which they are responsible. Hroups of administrators who manage infrastructure servers. The group that is responsible for infrastructure server administration manages !38S1 DHC-1 and potentially the D8S infrastructure. 3n some cases1 the group that handles domain management will manage the D8S infrastructure because Active Directory is integrated with D8S and is stored and managed on the domain controllers.
Data Administrators
Active Directory data administrators manage data that is stored in Active Directory or on computers that are 7oined to Active Directory. These administrators have no control over the configuration or delivery of the directory service. Data administrators are members of a security group that is created by your organi'ation. Sometimes the default security groups in !indows do not make sense for all situations in the organi'ation. Therefore1 organi'ations can develop their own security group naming standards and meanings to best fit their environment. Some of the data administrators daily tasks include" Control a subset of ob7ects in the directory. Through inheritable attribute%level access control1 data administrators can be granted control of very specific sections of the directory but no control over the configuration of the service itself. Manage member computers in the directory and the data that is on those computers.
3ote$ 6n man" cases# attribute values for ob?ects that are stored in the director" determine the director"Gs service confi&uration.
To summari'e1 before the owners of Active Directory service and directory structures are allowed to 7oin a forest or domain infrastructure1 the organi'ation must trust all service administrators in the forest and all domains. Also1 enterprise security programs must develop standard policies and procedures that perform appropriate background checks for the administrators. 3n the conte9t of this security guide1 to trust service administrators means to" Keasonably believe that service administrators will primarily concern themselves with the organi'ation s best interests. $rgani'ations should not elect to 7oin a forest or domain if the owners of that forest or domain might have legitimate reasons to act maliciously against the organi'ation. Keasonably believe that service administrators will follow best practices and restrict physical access to the domain controllers. Jnderstand and accept the risks to the organi'ation that include the possibility for" /o"ue administrators. Trusted administrators might become rogue administrators and abuse the privileges they have on the network. A rogue administrator within a forest could easily look up the security identifier /S3D0 for another administrator from another domain. The rogue administrator could then use an application programming interface /A-30 tool1 disk editor1 or debugger to add the stolen S3D to the S3D History list of an account within their own domain. !ith the stolen S3D added to the user s S3D History1 the rogue administrator would have administrative privileges in the stolen S3D s domain as well as their own domain. Coerced administrators. A trusted administrator might be coerced or compelled to perform operations that breach the security of a computer or the network. A user or administrator may use social engineering techni=ues or threats of
.6
physical or other harm on legitimate administrators of a computer to obtain the information that is needed to gain access to the computer. Some organi'ations might accept the risk of a security breach by a rogue or a coerced service administrator from another part of the organi'ation. Such organi'ations might determine that the collaborative and cost%saving benefit of participating in a shared infrastructure outweighs this risk. However1 other organi'ations might not accept the risk because the potential conse=uences of a security breach are too severe.
3ctive *irectory and Group +o#icy

Although $Js offer an easy way to group computers1 users1 groups1 and other security principals1 they also provide an effective way to segment administrative boundaries. Additionally1 $Js provide a crucial structure for the deployment of Hroup -olicy ob7ects /H-$s0 because they can segment resources by security need and allow you to provide different security to different $Js. The use of $Js to manage and assign security policies based on server role is an integral piece of the overall security architecture for the organi'ation.
-ele"atin" &dministration and &pplyin" Group %olicy

$Js are containers within the directory structure of a domain. These containers can hold any security principal in the domain1 although they are usually used to hold ob7ects of one specific type. To grant or revoke $J access permissions to a group or individual user1 you can set specific access control lists /ACLs0 on the $J and the permissions will be inherited by all of the ob7ects within the $J. Bou can use an $J to provide role%based administrative capabilities. :or e9ample1 one group of administrators could be responsible for the user and group $Js while another group could manage the $Js that contain the servers. Bou can also create an $J to contain a group of resource servers to be administered by other users through a process called delegation of control. This approach provides the delegated group with autonomous control over a particular $J but does not isolate them from the remainder of the domain. Administrators that delegate control over specific $Js are likely to be service administrators. At a lower level of authority1 users that control the $Js are usually data administrators.
&dministrative Groups
Administrators can create administrative groups to segment clusters of users1 security groups1 or servers into containers for autonomous administration. :or e9ample1 consider the infrastructure servers that reside in a domain. 3nfrastructure servers include all of the non%domain controllers that run basic network services1 including servers that provide !38S and DHC- services. $ftentimes an operations group or an infrastructure administration group maintains these servers. Bou can use an $J to easily provide administrative capabilities to these servers. The following illustration provides a high%level view of such an $J configuration.
.:
0i"ure 2 1 +( dele"ation of administration !hen the )nfrastructure &dmin group is delegated control of the 3nfrastructure $J1 the members of this group will have full control of the 3nfrastructure $J and all servers and ob7ects within the $J. This capability allows members of the group to secure the server roles with Hroup -olicy. This approach is only one way that $Js can be used to provide administrative segmentation. :or more comple9 organi'ations1 see the GMore 3nformationG section at the end of this chapter.
3ote: 9ecause Active 7irector" depends so heavil" on 7 +# it is common practice to run the 7 + service on domain controllers. 7omain controllers are placed in the built-in 7omain Controllers 1/ b" default. The e0amples in this &uide follow this practice# so the infrastructure server role does not include the 7 + service.
Group %olicy &pplication

Jse Hroup -olicy and delegate administration to apply specific settings1 rights1 and behavior to all servers within an $J. !hen you use Hroup -olicy instead of manual steps1 it is simple to update multiple servers with any additional changes that might be re=uired. Hroup -olicies are accumulated and applied in the order that is shown in the following illustration.
.;
0i"ure 2 2 G%+ application 'ierarc'y As seen in the illustration1 policies are applied first at the local policy level of the computer. After that1 any H-$s are applied at the site level1 and then at the domain level. 3f the server is nested in several $Js1 H-$s that e9ist at the highest level $J are applied first. The H-$ application process continues down the $J hierarchy. The final H-$ to be applied is at the child $J level that contains the server ob7ect. The order of precedence for processing Hroup -olicy e9tends from the highest $J /farthest from the user or computer account0 to the lowest $J /the one that actually contains the user or computer account0. Kemember the following basic considerations when you apply Hroup -olicy" Bou must set the H-$ application order for Hroup -olicy levels with multiple H-$s. 3f multiple policies specify the same option1 the last one that is applied will take precedence. Bou must configure a Hroup -olicy with the .o +verride option if you do not want other H-$s to override it. 3f you use the Hroup -olicy Management Console /H-MC0 to manage your H-$s1 the name of this option is !nforced.
Time Confi"uration
Many security services1 especially authentication1 rely on an accurate computer clock to perform their 7obs. Bou should ensure computer time is accurate and that all servers in your organi'ation use the same time source. The !indows Server *++, !,*Time service provides time synchroni'ation for !indows Server *++, and Microsoft !indows 2-@based computers that run in an Active Directory domain. The !,*Time service synchroni'es the clocks of !indows Server *++,@based computers with the domain controllers in a domain. This synchroni'ation is necessary for the Ferberos protocol and other authentication protocols to work properly. To function correctly1 a number of !indows Server family components rely on accurate and synchroni'ed time. 3f the clocks are not synchroni'ed on the clients1 the Ferberos authentication protocol might deny access to users.
.-
Another important benefit that time synchroni'ation provides is event correlation on all of the clients in your enterprise. Synchroni'ed clocks on the clients in your environment ensure that you can correctly analy'e events that take place in uniform se=uence on those clients throughout the organi'ation. The !,*Time service uses the 8etwork Time -rotocol /8T-0 to synchroni'e clocks on computers that run !indows Server *++,. 3n a !indows Server *++, forest1 time is synchroni'ed by default in the following manner" The primary domain controller /-DC0 emulator operations master in the forest root domain is the authoritative time source for the organi'ation. All -DC operation masters in other domains in the forest follow the hierarchy of domains when they select a -DC emulator with which to synchroni'e their time. All domain controllers in a domain synchroni'e their time with the -DC emulator operations master in their domain as their inbound time partner. All member servers and client desktop computers use the authenticating domain controller as their inbound time partner.
To ensure that the time is accurate1 the -DC emulator in the forest root domain can be synchroni'ed to an authoritative time source1 such as a reliable 8T- source or a highly accurate clock on your network. 8ote that 8T- synchroni'ation uses JD- port .*, traffic. Cefore you synchroni'e with an e9ternal server1 you should weigh the benefits of opening this port against the potential security risk. Also1 if you synchroni'e with an e9ternal server that you do not control1 you risk configuring your servers with the incorrect time. The e9ternal server could be compromised or spoofed by an attacker to maliciously manipulate the clocks on your computers. As e9plained earlier1 the Ferberos authentication protocol re=uires synchroni'ed computer clocks. 3f they are not synchroni'ed1 a denial of service may occur.
Security Template Mana"ement

Security templates are te9t@based files that you can use to apply a security configuration to a computer. Bou can modify security templates with the Microsoft Management Console /MMC0 Security Templates snap%in or with a te9t editor such as 8otepad. Some sections of the template files contain specific ACLs that are written in the Security Descriptor Definition Language /SDDL0. Bou can find more information about how to edit security templates and SDDL on the GSecurity Descriptor Definition LanguageG page on Microsoft MSD8( at http"##msdn.microsoft.com#library# en%us#secauth'#security#securityPdescriptorPdefinitionPlanguage.asp. Cy default1 authenticated users have the right to read all settings in a Hroup -olicy ob7ect. Therefore1 it is very important to store security templates for a production environment in a secure location that only administrators who implement Hroup -olicy can access. The purpose is not to prevent Q.inf files from being viewed1 but rather to prevent unauthori'ed changes to the source security templates. All computers that run !indows Server *++, store security templates in their local $System/oot$\security\templates folder. This folder is not replicated across multiple domain controllers1 so you will need to designate one location to hold the master copy of the security templates to prevent version control problems with the templates. After the centrally%located template is modified1 it can be redeployed to the appropriate computers. This approach will ensure that you always modify the same copy of the templates.
20
Successful G%+ &pplication !vents

Although an administrator can manually check all of the settings to ensure that they have been appropriately applied to the servers in your organi'ation1 an event should also appear in the event log to inform the administrator that the domain policy was successfully downloaded to each of the servers. An event similar to the following should display in the Application log with its own uni=ue ?vent 3D number" Type" 3nformation Source )-" SceCli !vent )-" .N+E -escription" Security policy in the Hroup -olicy ob7ects has been applied successfully. Cy default1 the security settings are refreshed every 6+ minutes on a workstation or server and every 5 minutes on a domain controller. Bou will see this type of event if any changes occurred during these intervals. Also1 the settings are refreshed every .L hours1 regardless of whether any changes were made. Bou can also manually force Hroup -olicy settings to update using the procedure that is described later in this chapter.
Sever /ole +r"ani1ational (nits

The previous e9ample showed a way to manage an organi'ation s infrastructure servers. This method can be e9tended to encompass other servers and services in an organi'ation. The goals are to create a seamless Hroup -olicy for all servers and to ensure that the servers that reside within Active Directory meet the security standards for your environment. This type of Hroup -olicy forms a consistent baseline of standard settings for all of the servers in your organi'ation. Also1 the $J structure and the application of Hroup -olicies must provide a detailed design to provide security settings for specific types of servers in an organi'ation. :or e9ample1 3nternet 3nformation Server /33S01 file1 print1 3nternet Authentication Server /3AS01 and Certificate Services are a few of the server roles in an organi'ation that may re=uire uni=ue Hroup -olicies.
I portant$ ,or simplicit"# the e0amples in this chapter assume the use of the 2nterprise Client environment. 6f "ou use one of the other two environments# substitute the appropriate file names. The differences between the three environments and their functionalit" are discussed in Chapter .# H6ntroduction to the 3indows +erver 200) +ecurit" 5uide.H
Member Server Baseline Policy

The first step in the establishment of server role $Js is to create a baseline policy. To create such a policy1 you can use SC! on a standard member server to create a Member Servers Caseline.9ml file. As part of the 2ML creation1 use SC! to include one of the supplied Member Server Caseline security templates /LC%Member Server Caseline.inf1 ?C%Member Server Caseline.inf1 or SSL:%Member Server Caseline.inf0. After you generate the SC! policy1 it is converted into a H-$ and linked with the Member Servers $J. This new baseline H-$ will apply the settings of the baseline Hroup -olicy to any servers in the Member Servers $J1 as well as any servers in child $Js. The Member Server Caseline -olicy is discussed in Chapter E1 GThe Member Server Caseline -olicy.G Bou should define the desired settings for most of the servers in your organi'ation in the baseline Hroup -olicy. Although there may be some servers that should not receive the baseline policy1 these should not be many. 3f you create your own baseline Hroup -olicy1
2.
make it as restrictive as possible and segment any servers that need to differ from this policy into separate server%specific $Js.
Server Role Types and Organizational Units

?ach identified server role re=uires an additional SC! policy1 security template1 and $J in addition to the baseline $J. This approach permits the creation of separate policies for the incremental changes that are re=uired by each role. 3n a previous e9ample1 the infrastructure servers were placed into the 3nfrastructure $J1 which is a child of the Member Servers $J. The ne9t step is to apply the appropriate configuration to these servers. Three security templates are provided with this solution1 one for each security environment" LC%3nfrastructure Server.inf1 ?C%3nfrastructure Server.inf1 and SSL:%3nfrastructure Server.inf. !hen used together with SC!1 these security templates will help you create a security policy that contains the specific ad7ustments that are re=uired by DHC- and !38S. The resultant policy is then converted into a new H-$ and linked to the 3nfrastructure $J. This H-$ uses the /estricted Groups setting to add the following three groups to the 2ocal &dministrators group of all servers in the 3nfrastructure $J" -omain &dministrators !nterprise &dministrators )nfrastructure &dministrators
As mentioned earlier in this chapter1 this approach is only one of many ways to create an $J structure that you can use to deploy H-$s. :or more information about how to create $Js for Hroup -olicy implementation1 see GDesigning the Active Directory StructureG and related topics at www.microsoft.com#resources#documentation#!indows#*+++#server# reskit#en%us#deploy#dgbdPadsPhe=s.asp?frame4true. The following table lists the !indows Server *++, server roles and corresponding template files that are defined in this guide. The security template file names are prefi9ed with the $&nv% variable1 which would be replaced by LC /for Legacy Client01 ?C /for ?nterprise Client01 or SSL: /for Speciali'ed Security @ Limited :unctionality0 as appropriate. Table 2 1 Windows Server 2003 Server /oles Server role Member server -escription Security template file name
All servers that are members of $&nv%'Member Server the domain and reside in or Caseline.inf below the Member Servers $J. All Active Directory domain controllers. These servers are also D8S servers. All locked down !38S and DHC- servers. All locked down file servers. All locked down print servers. All locked down 33S web servers. All locked down 3AS servers. $&nv%'Domain Controller.inf
Domain controller
3nfrastructure server :ile server -rint server !eb server 3AS server
$&nv%'3nfrastructure Server.inf $&nv%':ile Server.inf $&nv%'-rint Server.inf $&nv%'!eb Server.inf $&nv%'3AS Server.inf
22
Server role Certificate Services server Castion host
-escription All locked down Certification Authority /CA0 servers. All 3nternet%facing servers.
Security template file name $&nv%'CA Server.inf $&nv%'Castion Host.inf
All template files e9cept those for the bastion host servers are applied to the corresponding child $Js. ?ach of these child $Js re=uire that you apply the specific configuration to define the role that each computer will fulfill in the organi'ation. The security re=uirements for each of these server roles are different. Appropriate security settings for each role are discussed in detail in later chapters. 8ote that not all roles have templates that correspond to all environments. :or e9ample1 the bastion host role is always considered to be in the SSL: environment.
I portant$ This &uide assumes that computers that run 3indows +erver 200) will perform specificall" defined roles. 6f the servers in "our or&ani>ation do not match these roles# or if "ou have multipurpose servers# use the settin&s that are defined here as &uidelines for "our own securit" templates. *owever# remember that the more functions that each of "our servers perform# the more vulnerable the" are to attack.
An e9ample of the final $J design to support these defined server roles in the ?C environment is shown in the following illustration.
2)
0i"ure 2 3 +( desi"n e3ample
2(
O78 G+O8 and Group *esi(n

The recommended $Js and policies that were discussed in the previous section create a baseline or new environment to restructure an organi'ation s e9isting $J structure for computers that run !indows Server *++,. Administrators use their predefined administration boundaries to create their respective administrative groups. An e9ample of the correlation of these groups to the $Js they manage is shown in the following table. Table 2 2 +(s and &dministrative Groups +( name Domain Controllers Member Servers 3nfrastructure :ile -rint 3AS !eb CA &dministrative "roup Domain ?ngineering Domain ?ngineering 3nfrastructure Admins 3nfrastructure Admins 3nfrastructure Admins Domain ?ngineering !eb Services ?nterprise Administrators
?ach administrative group was created as a global group within the domain by the -omain !n"ineerin" members1 who are responsible for Active Directory infrastructure and security. They used the corresponding H-$ to add each of these administrative groups to the appropriate restricted group. The administrative groups that are listed in the table will only be members of the 2ocal &dministrators group for the computers that are located in the $Js that specifically contain computers that are related to their 7ob functions. :inally1 the -omain !n"ineerin" members set permissions on each H-$ so that only administrators in their group are able to edit them. 8ote that the creation and configuration of these groups is a part of your overall Active Directory design and implementation process. 3t is not part of this guide.
+rocess Overview
This guide combines the strengths of the SC!%based and Hroup -olicy%based approaches. This hybrid approach allows you to create and test security configurations more easily1 but still provides the fle9ibility and scalability that is re=uired in large !indows networks. The process that is used to create1 test1 and deploy the policies is as follows" .. Create the Active Directory environment1 including groups and $Js. Bou should create the appropriate administrative groups and delegate $J permissions to the corresponding groups. *. Configure time synchroni'ation on the domain controller that hosts the -DC ?mulator :SM$. ,. Configure the domain policies. E. Create the baseline policies with SC!.
2'
5. Test the baseline policies with SC!. L. Convert the baseline policies to H-$s and link them to the appropriate H-$s. N. Create the role policies with SC! and the included security templates. >. Test the role policies with SC!. 6. Convert the role policies to H-$s and link them to the appropriate H-$s. The following sections describe these steps in greater detail.
3ote$ ,or simplicit"# the e0amples in this section assume the use of the 2nterprise Client @2CA environment. 6f "ou use one of the other two environments# substitute the appropriate file names. The differences between the three environments and their functionalit" are discussed in Chapter .# H6ntroduction to the 3indows +erver 200) +ecurit" 5uide.H
Create the 3ctive *irectory
nviron"ent
Cefore you can begin the hardening process1 you must have an appropriate Active Directory domain and $J structure in place. The following procedure lists the steps that you will use to create the $Js and groups that are used in this guide and configure them for the appropriate administrative access. .. $pen the MMC Active Directory Jsers Computers snap%in /Dsa.msc0. *. 3n the root of the domain ob7ect1 create an $J called Member Servers. ,. 8avigate to this new $J and create a child $J within it called 3nfrastructure. E. Move all !38S and DHC- servers into the 3nfrastructure $J. 5. Create a global security group called )nfrastructure &dmins and add the appropriate domain accounts to it. L. Kun the Delegation of Control !i'ard to provide the )nfrastructure &dmins group with :ull Control of the $J. N. Kepeat steps , through L for the file server1 print server1 web server1 3AS server1 and Certificate Services server roles. Jse the information in Table *.* for the appropriate $J and group names.
Con&i(ure %i"e Synchroni6ation

The following procedure ensures that the domain controllers and member servers are synchroni'ed with an e9ternal time source. This synchroni'ation will help ensure that Ferberos authentication works properly and allow you to keep your Active Directory domain synchroni'ed with any e9ternal computers that you may have. .. $n the domain controller with the -DC ?mulator :SM$1 open a command prompt and e9ecute the following command1 where $Peer(ist% is a comma%separated list of D8S names or 3- addresses for the desired time sources" w32tm /config /syncfromflags:manual /manualpeerlist:<PeerList> *. To update the configuration1 e9ecute the following command" w32tm /config /update ,. Check the event log. 3f the computer cannot reach the servers1 the procedure will fail and an entry will be written to the event log. The most common use of this procedure is to synchroni'e the internal network s authoritative time source with a very precise e9ternal time source. However1 this procedure can be run on any computer that runs !indows 2- or member of the !indows Server *++, family. 3t is not usually necessary to synchroni'e all servers time
26
clocks with an e9ternal source if they are synchroni'ed with the same internal source. Cy default1 member computers always synchroni'e their clocks with domain controllers.
3ote$ ,or accurate lo& anal"sis# "ou should also s"nchroni>e the clocks of network computers that run operatin& s"stems other than 3indows to the 3indows +erver 200) 87C emulator or to the same time source for that server.
Con&i(ure the *o"ain +o#icy

The following procedure imports the security templates that are provided with this guide for the domain%level policy. This policy is provided as a security template1 because SC! does not address domain%level policies. Cefore you implement the following procedure1 the specific policy /.inf0 file must be located on your computer.
Warning$ The securit" templates in this &uide are desi&ned to increase securit" in "our environment. 6t is =uite possible that their installation could cause some functionalit" in "our environment to be lost# and mission critical applications could fail. 6t is essentia$ that "ou thorou&hl" test these settin&s before "ou deplo" them in a production environment. 9ack up each domain controller and server in "our environment before "ou appl" an" new securit" settin&s. 2nsure the s"stem state is included in the backup# which will enable re&istr" settin&s and Active 7irector" ob?ects to be restored if necessar".
To import t'e -omain %olicy security templates .. 3n Active Directory Jsers and Computers1 right%click the domain1 and then select %roperties. *. $n the Group %olicy tab1 click .ew to add a new H-$. ,. Type !C*-omain %olicy1 and then press ?8T?K. E. Kight%click !C*-omain %olicy1 and then select .o +verride. 5. Select !C*-omain %olicy1 and then click !dit. L. 3n the Hroup -olicy $b7ect ?ditor window1 click Computer Confi"uration\Windows Settin"s. Kight%click Security Settin"s1 and then select )mport %olicy. N. 3n the )mport %olicy 0rom dialog bo91 navigate to 4\Tools and Templates\Security Guide\Security Templates4 and then double%click !C*-omain inf. >. Close the Hroup -olicy that has been modified. 6. Close the -omain %roperties window. .+. 3f you do not want to wait for scheduled Hroup -olicy application1 you can initiate the process manually. $pen a command prompt1 type "pupdate 50orce and press ?8T?K. ... <erify in the event log that the Hroup -olicy downloaded successfully and that the server can communicate with the other domain controllers in the domain.
Warning$ 3hen "ou create the 2C-7omain 8olic"# ensure that the 3o 4verride option is enabled to enforce this polic" throu&hout the domain. This 5roup 8olic" is the onl" one in this &uide in which the 3o 4verride option must be enabled. 7o not enable this option in an" of the other 5roup 8olicies that are specified in this &uide. Also# do not modif" the 3indows +erver 200) default domain polic"Iin case "ou need to return to its default settin&s.
To ensure that this new Hroup -olicy has precedence over the default policy1 position it to have the highest priority among the H-$ links.
I portant$ Jou should import this 5roup 8olic" into an" additional domains in the or&ani>ation to ensure consistent application of password polic". *owever# it is not uncommon to find environments in which the root domain password polic" is much stricter than an" of the other domains. Jou should also ensure that an" other domains that will use this same polic" have the same business re=uirements. 9ecause the password polic" can onl" be set at the domain level# there ma" be business or le&al re=uirements that se&ment some users into a separate domain simpl" to enforce the use of a stricter password polic" on that &roup.
2:
To clear t'e &llow )n'eritable %ermissions option Cy default1 the new $J structure inherits many security settings from its parent container. :or each $J1 clear the check bo9 for &llow in'eritable permissions from parent to propa"ate to t'is ob,ect and all c'ild ob,ects. .. $pen Active Directory Jsers and Computers. *. Click 6iew and then &dvanced 0eatures to select the Advanced view. ,. Kight%click the appropriate $J1 and then click %roperties. E. Click the Security tab1 and then click &dvanced. 5. Clear the &llow in'eritable permissions from parent to propa"ate to t'is ob,ect and all c'ild ob,ects )nclude t'ese wit' entries specifically defined 'ere checkbo9. Kemove any unnecessary groups that were previously added by administrators1 and add the domain group that corresponds to each server role $J. Ketain the 0ull Control setting for the -omain &dministrators group.
Create the -ase#ine +o#icies )anua##y 7sin( SCW

The ne9t step is to use SC! to create the member server baseline policy. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should use hardware that is similar to the hardware that you will use in your deployment1 which will help ensure as much compatibility as possible. The new installation is called a reference com)uter. During the member server baseline policy /MSC-0 creation steps1 note that you remove the :ile server role from the list of detected roles. This role is commonly configured on servers that do not re=uire it and could be considered a security risk. To enable the :ile server role for servers that re=uire it1 you can apply a second policy later in this process. To create t'e Member Server #aseline %olicy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain. E. 3nstall only the mandatory applications that should be on every server in your environment. ?9amples include your software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch SC!1 select Create new policy1 and point it to the reference computer. L. Kemove the :ile server role from the listed of detected roles. N. ?nsure that the detected client features are appropriate for your environment. >. ?nsure that the detected administrative options are appropriate for your environment. 6. ?nsure that any additional services that re=uired by your baseline1 such as backup agents or antivirus software1 are detected.
2;
.+. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. ... Keview the network settings and ensure that the appropriate ports and applications have been detected and will be configured as e9ceptions for the !indows :irewall. .*. Skip the GKegistry SettingsG section. .,. Skip the GAudit -olicyG section. .E. 3nclude the appropriate security template /for e9ample1 ?C%Member Server Caseline.inf0. .5. Save the policy with an appropriate name /for e9ample1 Member Server Caseline.9ml0. To create t'e -omain Controller policy Bou must use a computer that is configured as a domain controller to create the Domain Controller policy. Bou can use either an e9isting domain controller or create a reference computer and use the Dcpromo tool to make the computer a domain controller. However1 most organi'ations do not want to add a domain controller to their production environment because it may violate their security policy. 3f you use an e9isting domain controller1 make sure that you do not apply any setting to it with SC! or modify its configuration. .. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. *. 3nstall only the mandatory applications that should be on every server in your environment. ?9amples include your software and management agents1 tape backup agents1 and antivirus or antispyware utilities. ,. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. E. ?nsure that the detected roles are appropriate for your environment. 5. ?nsure that the detected client features are appropriate for your environment. L. ?nsure that the detected administrative options are appropriate for your environment. N. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. >. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network1 because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. 6. Keview the network settings and ensure that the appropriate ports and applications have been detected and will be configured as e9ceptions for the !indows :irewall. .+. Skip the GKegistry SettingsG section. ... Skip the GAudit -olicyG section. .*. 3nclude the appropriate security template /for e9ample1 ?C%Domain Controller.inf0. .,. Save the policy with an appropriate name /for e9ample1 Domain Controller.9ml0.
2-
%est the -ase#ine +o#icies 7sin( SCW

After you create and save the baseline policies1 Microsoft strongly recommends that you deploy them to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policies. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push policies to a single server at a time1 or use Scwcmd to push them to a group of servers. The native deployment method offers the advantage of the ability to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the testing process. The policies are tested to ensure that their application to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more detailed information about how to test SC! policies1 see GDeployment Huide for the Security Configuration !i'ardG at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the downloadable version of the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.
Convert the -ase#ine +o#icies to G+Os

After you thoroughly test the baseline policies1 complete the following steps to convert them into H-$s and link them to the appropriate $Js" .. At a command prompt1 type the following" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure !ml" /g:"Infrastructure Policy"
3ote$ The information to be entered at the command prompt shows on more than one line here because of displa" limitations. This information should all be entered on one line.
*. Jse the Hroup -olicy Management Console to link the newly created H-$ to the appropriate $J. 8ote that if the SC! security policy file contains !indows :irewall settings1 !indows :irewall must be active on the local computer for this procedure to complete successfully. To verify that !indows :irewall is active1 open Control -anel and then double%click Windows 0irewall. Bou should now perform a final test to ensure that the H-$ applies the desired settings. To complete this procedure1 confirm that the appropriate settings were made and that functionality is not affected.
)0
Create the $o#e +o#icies 7sin( SCW

The ne9t step is to use SC! to create the role policies for each server role. The steps to create the role%specific policies are similar to the steps you followed when you created the MSC-. Bou should once again use a reference computer to help ensure that there are no legacy settings or software from previous configurations. To create t'e role policies .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the new server to the domain. E. 3nstall the mandatory applications that should be on every server in your environment. ?9amples include your software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Configure the appropriate roles for the computer. :or e9ample1 if your target servers will run DHC- and !38S1 install those components. They do not need to be configured e9actly the same as the deployed servers1 but the roles must be installed. L. Launch SC!. N. Select Create new policy and point it to the reference computer. >. ?nsure that the detected roles are appropriate for your environment. 6. ?nsure that the detected client features are appropriate for your environment. .+. ?nsure that the detected administrative options are appropriate for your environment. ... ?nsure that any additional services re=uired by your baseline1 such as backup agents or antivirus software1 are detected. .*. Decide how to handle unspecified services in your environment. :or stronger security /and reduced functionality0 you may wish to configure this policy setting to -isable1 which will disable any new service that was not e9plicitly allowed through SC!. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. .,. Confirm all service changes that are listed. .E. Keview the network settings and ensure that SC! detected the appropriate ports and applications to configure as e9ceptions for the !indows :irewall. .5. Skip the GKegistry SettingsG section. .L. Skip the GAudit -olicyG section. .N. 3f the server is configured with the !eb server role1 complete the steps in the S3nternet 3nformation ServicesT section to ensure that SC! is configured to support the necessary 33S features. .>. Click )nclude Security Templates to add the appropriate security template. .6. Save the policy with an appropriate name.
%est the $o#e +o#icies 7sin( SCW

As with the baseline policies1 there are two different ways to test the policies. Bou can use the native SC! deployment facilities1 or you can deploy the policies through H-$s.
).
Again1 Microsoft strongly recommends that you deploy your role policies in a test environment before you use them in production. This approach will help minimi'e downtime and failures in your production environment. After you thoroughly test the new configuration1 you can convert the policies into H-$s as shown in the following procedure and apply them to the appropriate $J.
Convert the $o#e +o#icies to G+Os

After you thoroughly test the role policies1 complete the following steps to convert them into H-$s and link them to the appropriate $Js" .. At a command prompt1 type the following" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure !ml" /g:"Infrastructure Policy"
*. Jse the Hroup -olicy Management Console to link the newly created H-$ to the appropriate $J1 and make sure to move it above the Default Domain Controllers -olicy so that it receives the highest priority. 8ote that if the SC! security policy file contains !indows :irewall settings1 !indows :irewall must be active on the local computer for this procedure to complete successfully. To verify that !indows :irewall is active1 open Control -anel and then double%click !indows :irewall.
Su""ary
Security administrators need to understand the strengths and weaknesses of SC! compared to conventional Hroup -olicy%based hardening methods so that they can choose the right methodology for their environment. SC! and Hroup -olicy can be used together to gain the ability to rapidly and consistently prototype policies that SC! provides together with the scalable deployment and management capabilities of Hroup -olicy. Several design considerations are involved when forest1 domain1 and $J designs are reviewed to secure an environment. 3t is important to research and document any specific autonomy and isolation re=uirements for the organi'ation. -olitical autonomy1 operational isolation1 and legal or regulatory isolation are all valid reasons to consider comple9 forest designs. 3t is important that you understand how to control service administrators. Malicious service administrators can present a great risk to an organi'ation. At a lower level1 malicious domain administrators can access data in any domain in the forest. Although it may not be easy to change the forest or domain design in an organi'ation1 it may be necessary to remediate some security risks. 3t is also important to plan the $J deployment in the organi'ation to accommodate the needs of both service administrators and data administrators. This chapter provided detailed information about how to create an $J model that will support the use of H-$s for the ongoing management of different server roles in the organi'ation.
)2
)ore In&or"ation
The following links provide additional information about topics that relate to hardening servers that run !indows Server *++, with S-.. :or more information about security and privacy at Microsoft1 see the Trustworthy Computing" Security page at www.microsoft.com#mscorp#twc#default.msp9. :or sound security guidelines1 see STen 3mmutable Laws of SecurityT at www.microsoft.com#technet#archive#community#columns#security#essays#.+imlaws.m sp9. :or guidance about how to secure the Active Directory database1 see SCest -ractice Huide for Securing Active Directory 3nstallationsT at www.microsoft.com#downloads#details.asp9?:amily3D4EeN,E+L5%,f.>%E>>a%be.e% f+,,6+ec5f6.O. :or information about Active Directory design considerations1 see SDesign Considerations for Delegation of Administration in Active DirectoryT at www.microsoft.com#technet#prodtechnol#windows*+++serv#technologies#activedirecto ry#plan#addeladm.msp9. :or information about how to configure a time server1 see the Microsoft Fnowledge Case article GHow to configure an authoritative time server in !indows *+++G at http"##support.microsoft.com#?kbid4*.LN,E. :or information about network ports that are used by Microsoft applications1 see the Microsoft Fnowledge Case article GService overview and network port re=uirements for the !indows Server systemG at http"##support.microsoft.com#kb#>,*+.N.
Chapter 3: %he *o"ain +o#icy

Overview
This chapter uses the construction of a domain environment to demonstrate ways to address security within a Microsoft( !indows Server) *++, with Service -ack . /S-.0 infrastructure. This chapter focuses on the following topics" Security settings and countermeasures at the domain level. How to secure a !indows Server *++, domain for the Legacy Client /LC01 ?nterprise Client /?C01 and Speciali'ed Security @ Limited :unctionality /SSL:0 environments that are defined in Chapter .1 G3ntroduction to the !indows Server *++, Security Huide.G
This information provides a foundation and a vision for how to evolve from an LC environment to an SSL: environment within a domain infrastructure. !indows Server *++, with S-. ships with default values that are set to a known1 highly secure state. To improve the usability of this material1 this chapter only discusses those settings that have been modified from the default values. :or information about all default settings1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
*o"ain +o#icy
Bou can apply Hroup -olicy security settings at several different levels in an organi'ation. The baseline environment that is discussed in Chapter *1 G!indows Server *++, Hardening MechanismsG used Hroup -olicy to apply settings at the following three hierarchy levels in the domain infrastructure" -omain 2evel. Settings at this level address common security re=uirements1 such as account and password policies that must be enforced for all servers in the domain. #aseline 2evel. Settings at this level address specific server security re=uirements that are common to all servers in the domain infrastructure. /ole*Specific 2evel. Settings at this level address security re=uirements for specific server roles. :or e9ample1 the security re=uirements for infrastructure servers differ from those for servers that run Microsoft 3nternet 3nformation Services /33S0.
The following sections of this chapter will only discuss the Domain Level policy in detail. Most of the domain security settings that are addressed are for user accounts and passwords. !hen you review these settings and recommendations1 remember that all settings apply to every user in the domain boundary.
)(
*o"ain +o#icy Overview

Hroup -olicy is e9tremely powerful because it allows an administrator to create a standard network computer configuration. Hroup -olicy ob7ects /H-$s0 can provide a significant portion of a configuration management solution for any organi'ation1 because they allow administrators to make security changes simultaneously on all computers in the domain or subsets of the domain. The following sections provide detailed information about the security settings that you can use to enhance the security of !indows Server *++, with S-.. Tables are provided that summari'e the settings1 and detailed descriptions of how to achieve the security ob7ectives for each setting are also provided. The settings are divided into categories that correspond to their presentation in the !indows Server *++, Security Configuration ?ditor /SC?0 user interface. Bou can simultaneously apply the following types of security changes through Hroup -olicy" Modify permissions on the file system. Modify permissions on registry ob7ects. Change settings in the registry. Change user rights assignments. Configure system services. Configure audit and event logs. Set account and password policies.
This guide recommends that you create a new Hroup -olicy at the domain root to apply the domain%wide policies that are discussed in this chapter. This approach will make it easier for you to test or troubleshoot the new Hroup -olicy1 because if you need to roll back changes you can simply disable it. However1 some applications that are designed to work with Active Directory make changes to the built%in Default Domain -olicy. These applications are not going to be aware of the new Hroup -olicy you implemented if you follow the recommendations in this guide. Cefore you deploy new enterprise applications1 be sure to test them thoroughly. 3f you encounter problems1 check to see whether the application has modified account policies1 created new user accounts1 modified user rights1 or made other changes to the Default Domain -olicy or local computer policies.
3ccount +o#icies
Account policies1 which include password policy1 account lockout policy1 and Ferberos policy security settings1 are only relevant in the domain policy for all three environments that are defined in this guide. -assword policy provides a way to set comple9ity and change schedules for high security environments. Account lockout policy allows tracking of unsuccessful password logon attempts to initiate account lockouts if necessary. Ferberos policies are used for domain user accounts1 and determine settings that relate to the Ferberos authentication protocol1 such as ticket lifetimes and enforcement.
+assword +o#icy
Comple9 passwords that are changed on a regular basis reduce the likelihood of a successful password attack. -assword policy settings control the comple9ity and lifetime for passwords. This section discusses each specific password policy setting and how
Chapter )$ The 7omain 8olic"
)'
they relate to each of the three environments that are defined in this guide" Legacy Client1 ?nterprise Client1 and Speciali'ed Security @ Limited :unctionality. Strict re=uirements for password length and comple9ity do not necessarily mean that users and administrators will use strong passwords. Although password policy may re=uire users to comply with technical comple9ity re=uirements1 additional strong security policy is needed to ensure that users create passwords that are hard to compromise. :or e9ample1 CreakfastU might meet all password comple9ity re=uirements1 but it is not a very difficult password to crack. 3f you know certain facts about the person who creates a password1 you might be able to guess their password if it is based on their favorite food1 car1 or movie. $ne strategy of organi'ational security programs that seek to educate users about strong passwords is to create a poster that describes poor passwords and display it in common areas1 such as near a water fountain or copy machine. Bour organi'ation should set strong password creation guidelines that include the following" Avoid the use of words from a dictionary in any language1 including common or clever misspellings of words. Do not create a new password that simply increments a digit in your current password. Avoid the use of passwords that begin or end with a numeral because they can be guessed easier than passwords that have a numeral in the middle. Avoid the use of passwords that others can easily guess by looking at your desk /such as names of pets1 sports teams1 and family members0. Avoid the use of words from popular culture. ?nforce the use of passwords that re=uire you to type with both hands on the keyboard. ?nforce the use of uppercase and lowercase letters1 numbers1 and symbols in all passwords. ?nforce the use of space characters and characters that can be produced only by pressing the ALT key.
Bou should also use these guidelines for all service account passwords in your organi'ation.
+assword +o#icy Settin(s

The following table includes the password policy setting recommendations for all three environments that are defined in this guide. Bou can configure the password policy settings in the following location in the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\ &ccount %olicies\%assword %olicy Additional information for each setting is provided in the subsections that follow the table.
)6
Table 3 1 %assword %olicy Settin" /ecommendations Settin" ?nforce password history Ma9imum password age Minimum password age Minimum password length -assword must meet comple9ity re=uirements Store password using reversible encryption 2e"acy Client *E passwords remembered E* days . day > characters ?nabled !nterprise Client *E passwords remembered E* days . day > characters ?nabled Speciali1ed Security 7 2imited 0unctionality *E passwords remembered E* days . day .* characters ?nabled
Disabled
Disabled
Disabled
!nforce password 'istory

This policy setting determines the number of uni=ue new passwords that must be associated with a user account before it is possible to reuse an old password. The value can be set between + and *E passwords. The default value for the !nforce password 'istory setting in !indows Server *++, with S-. is the ma9imum1 *E passwords. Microsoft recommends this value for all three environments because it helps ensure that old passwords are not continually reused1 because common vulnerabilities are associated with password reuse1 and because a low number for this setting will allow users to continually recycle a small number of passwords repeatedly. Also1 there are no known issues with this recommendation for environments that include legacy clients. To enhance the effectiveness of this policy setting1 you may also configure the Minimum password a"e setting so that passwords cannot be changed immediately. This combination makes it difficult for users to reuse passwords1 either accidentally or on purpose.
Ma3imum password a"e

This policy setting defines the period in which an attacker who has cracked a password may use it to access a computer on the network before the password e9pires. The range of values for this policy setting is from . to 666 days. Bou can configure the Ma3imum password a"e setting so that passwords e9pire as often as necessary for your environment. The default value for this setting is E* days. Kegular password changes can help prevent passwords from being compromised. Most passwords can be cracked if an attacker has enough time and computing power. The more fre=uently the password changes1 the less time an attacker has to crack it. However1 the lower this value is set1 the greater the potential for an increase in calls to help desk support. Microsoft recommends that the Ma3imum password a"e setting be left at the default value of E* days for all three environments that are defined in this guide. This configuration ensures that passwords are changed periodically but does not re=uire users
):
to change their password so often that they cannot remember what it is. To balance the needs of security and usability1 you can increase the value for this policy setting in the Legacy Client and ?nterprise Client environments.
Minimum password a"e

This policy setting determines the number of days that a password must be used before a user can change it. The range of values for the Minimum password a"e setting is between + and 666 daysV a value of + allows the password to be changed immediately. The default value for this policy setting is . day. The Minimum password a"e setting must be less than the Ma3imum password a"e setting1 unless the Ma3imum password a"e setting is configured to 0 /which means that passwords would never e9pire0. Configure the Minimum password a"e to be greater than + if you want the !nforce password 'istory setting to be effective. !ithout a minimum password age1 users can cycle through passwords repeatedly until they can reuse an old favorite. Microsoft recommends that you enforce the Minimum password a"e default value of . day for all three environments that are defined in this guide. !hen this setting is used in con7unction with a similar low value in the !nforce password 'istory setting1 users can recycle the same passwords again and again. :or e9ample1 if Minimum password a"e is configured to . day and !nforce password 'istory is configured to * passwords1 users would only have to wait * days before being able to reuse an old favorite password. However1 if Minimum password a"e is configured to . day and !nforce password 'istory to *E1 users would need to change their password every day for at least *E days before they could reuse a passwordIwhich is unlikely.
Minimum password len"t'

This policy setting ensures that passwords have at least a specified number of characters. Long passwordsIeight or more charactersIare usually stronger than short ones. !hen the Minimum password len"t' setting is used1 users cannot use blank passwords and they must create passwords with a specific number of characters. The default value for this setting is seven characters. This guide recommends that you configure the Minimum password len"t' setting to eight characters for the Legacy Client and ?nterprise Client environments. This configuration is long enough to provide some level of security but still short enough for users to easily remember. Also1 this configuration provides a reasonably strong defense against the commonly used dictionary and brute force attacks. /Dictionary attacks use word lists to obtain a password through trial and error. Crute force attacks try every possible password or encrypted te9t value. The likelihood of a successful brute force attack depends on the length of the password1 the si'e of the potential character set1 and the computational power that is available to the attacker.0 This guide recommends that you configure the Minimum password len"t' setting to .* characters for the Speciali'ed Security @ Limited :unctionality environment. ?ach additional character in a password increases its comple9ity e9ponentially. :or e9ample1 a seven%character password would have *LN1 or . 9 .+N1 possible combinations. A seven%character case%sensitive alphabetic password has 5*N combinations. A seven% character case%sensitive alphanumeric password without punctuation has L*N combinations. At .1+++1+++ attempts per second1 it would take appro9imately E+ days to crack. An eight%character password has *L>1 or * 9 .+..1 possible combinations. Although this might seem to be an overwhelmingly large number1 at .1+++1+++ attempts per second /a capability of many password%cracking utilities0 it would take only 56 hours to try
);
all possible passwords. Kemember1 these times will significantly increase for passwords that use ALT characters and other special keyboard characters1 such as U or &. -asswords are stored in the Security Accounts Manager /SAM0 database or Active Directory after they are passed through a one%way /non%reversible0 hash algorithm. Therefore1 the only known way to tell if you have the right password is to run it through the same one%way hash algorithm and compare the results. Dictionary attacks run entire dictionaries through the encryption process1 looking for matches. They are a simplistic yet very effective approach to determine who uses common words like GpasswordG or GguestG as their account passwords. $lder versions of !indows used a specific type of hashing algorithm known as the LA8 Manager Hash /LMHash0. This algorithm breaks up the password into blocks of seven or fewer characters and then calculates a separate hash value for each block. Although !indows *+++ Server1 !indows 2-1 and !indows Server *++, all use a newer hashing algorithm1 they may still calculate and store the LMHash for backward compatibility. !hen the LMHash values are present1 they present a shortcut for password crackers. 3f a password is seven characters or less1 the second half of the LMHash resolves to a specific value that can inform a cracker that the password is shorter than eight characters. -asswords of at least eight characters strengthen even the weaker LMHash1 because the longer passwords re=uire crackers to decrypt two portions of each password instead of only one. 3t is possible to attack both halves of an LMHash in parallel1 and the second half of the LMHash is only . character longV it will succumb to a brute%force attack in milliseconds. Therefore it is not really beneficial unless it is part of the ALT character set. :or these reasons1 the use of shorter passwords in place of longer ones is not recommended. However1 minimum length re=uirements that are too long may cause more mistyped passwords1 which can cause an increase in locked out accounts and help desk calls. Also1 e9tremely long password re=uirements can actually decrease the security of an organi'ation because users may be more likely to write their passwords down so that they do not forget them.
%assword must meet comple3ity re8uirements

This policy setting checks all new passwords when they are created to ensure that they meet comple9ity re=uirements. The !indows Server *++, policy rules cannot be directly modified. However1 you can create a new version of the -assfilt.dll file to apply a different set of rules. :or more information about creating a custom -assfilt.dll file1 see the MSD8( article GSample -assword :ilterG at http"##msdn.microsoft.com#library#default.asp?url4#library#en%us#secmgmt# security#samplePpasswordPfilter.asp. A password of *+ or more characters can actually be set so that it is easier for a user to rememberIand more secureIthan an eight%character password. Consider the following *N%character passwordI) love c'eap tacos for 9 ::. This type of password /really a pass phrase0 might be simpler for a user to remember than a shorter password such as %;<<w0rd. !hen combined with a Minimum password len"t' of >1 this setting makes it very difficult to mount a brute force attack. 3f you include upper and lower case letters and numbers in the keyspace1 the number of available characters increases from *L to L* characters. An eight%character password then has *..> 9 .+.E possible combinations. At .1+++1+++ attempts per second1 it would take L.6 years to cycle through all possible permutations.
)-
:or these reasons1 Microsoft recommends that the %assword must meet comple3ity re8uirements setting be configured to !nabled for all three environments that are defined in this guide.
Store password usin" reversible encryption

This policy setting determines whether the operating system uses reversible encryption to store passwords. 3t supports applications that use protocols that re=uire user passwords for authentication purposes. -asswords that are stored with an encryption method that can be reversed can be retrieved more easily than passwords that are stored with non%reversible encryption. 3f this setting is enabled1 vulnerability is increased. :or this reason1 Microsoft recommends that you configure the Store password usin" reversible encryption setting to -isabled unless application re=uirements outweigh the need to protect password information. Also1 environments that deploy the Challenge% Handshake Authentication -rotocol /CHA-0 through remote access or 3AS and environments that use digest authentication for 3nternet 3nformation Services /33S0 re=uire this policy setting to be enabled.
'ow to +revent 7sers &ro" Chan(in( a +assword !cept When $e5uired

Although the password policy settings that are described in the previous section provide a range of options1 some organi'ations re=uire centrali'ed control over all users. This section describes how to prevent password changes by users e9cept when changes are re=uired. Centrali'ed control of user passwords is a cornerstone of a well%crafted !indows Server *++, security scheme. Bou can use Hroup -olicy to set minimum and ma9imum password ages as discussed earlier1 but remember that fre=uent password change re=uirements can enable users to circumvent the password history setting for your environment. Ke=uirements for passwords that are too long may also lead to more calls to the help desk from users who forget their passwords. Jsers can change their passwords during the period between the minimum and ma9imum password age settings. However1 the Speciali'ed Security @ Limited :unctionality environment design re=uires that users change their passwords only when the operating system prompts them to do so after the Ma3imum password a"e setting of E* days. To prevent password changes /e9cept when re=uired01 you can disable the C'an"e %assword option in the Windows Security dialog bo9 that appears when you press CTKLWALTWD?L?T?. 8ote that security%conscious users may want to change their passwords more often and will have to contact an administrator to do so1 which will increase support costs. Bou can implement this configuration for an entire domain through Hroup -olicy1 or you can edit the registry to implement it for one or more specific users. :or more detailed instructions about this configuration1 see the Microsoft Fnowledge Case article GHow To -revent Jsers from Changing a -assword ?9cept !hen Ke=uired in !indows Server *++,G at http"##support.microsoft.com#?kbid4,*ENEE.
(0
3ccount 9ockout +o#icy

Account lockout policy is a !indows Server *++, with S-. security feature that locks a user account after a number of failed logon attempts occur within a specified time period. The number of attempts that are allowed and the time period are based on the values that are configured for the policy. !indows Server *++, with S-. tracks logon attempts1 and the server software can be configured to disable accounts after a preset number of failed logins as a response to potential attacks. These policy settings help protect user passwords from attackers who guess passwords1 and they decrease the likelihood of successful attacks on your network. However1 you will likely incur higher support costs if you enable account lockout policy1 because users who forget or mistype their passwords repeatedly will need assistance. Cefore you enable the following settings1 ensure that your organi'ation is prepared for this additional overhead. :or many organi'ations1 an improved and less%costly solution is to automatically monitor the Security event logs for domain controllers and generate administrative alerts when apparent attempts to guess passwords for user accounts occur. See Chapter *1 GDomain Level -olicies1G of the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2- at http"##go.microsoft.com#fwlink# ?Link3d4.5.561 for additional discussion of these settings and how they interact.
3ccount 9ockout +o#icy Settin(s

The following table summari'es the recommended account lockout policy settings. Bou can use the Hroup -olicy $b7ect ?ditor to configure these settings in the Domain Hroup -olicy at the following location" Computer Confi"uration\Windows Settin"s\Security Settin"s\ &ccount %olicies\&ccount 2oc=out %olicy Additional information for each setting is provided in the subsections that follow the table. Table 3 2 &ccount 2oc=out %olicy Settin"s Settin" Account lockout duration Account lockout threshold Keset account lockout counter after 2e"acy Client ,+ minutes !nterprise Client ,+ minutes Speciali1ed Security 7 2imited 0unctionality .5 minutes .+ invalid login attempts .5 minutes
5+ invalid 5+ invalid login login attempts attempts ,+ minutes ,+ minutes
&ccount loc=out duration

This policy setting determines the length of time before an account is unlocked and a user can try to log on again. 3t specifies the number of minutes a locked out account will remain unavailable. 3f you set the &ccount loc=out duration value to +1 accounts will remain locked out until an administrator unlocks them. The !indows Server *++, with S-. default value for this policy setting is .ot -efined. Although it may seem like a good idea to configure the &ccount loc=out duration setting to never automatically unlock1 such a configuration may increase the number of calls the help desk receives to unlock accounts that were locked by mistake. This guide recommends that you configure the &ccount loc=out duration setting to 30 minutes for Legacy Client and ?nterprise Client environments and to 1< minutes for
(.
Speciali'ed Security % Limited :unctionality environments. This configuration decreases the amount of operation overhead during a denial of service /DoS0 attack. 3n a DoS attack1 an attacker maliciously performs a number of failed logon attempts on all users in the organi'ation1 which locks out their accounts. The recommended settings give locked out users the chance to log on again in a reasonable amount of time without the need for assistance from the help desk. However1 information about this setting value needs to be communicated to users.
&ccount loc=out t'res'old

This policy setting determines the number of attempts that a user can make to log on to an account before it is locked. Authori'ed users can lock themselves out of their accounts in different ways. They can incorrectly enter their password or they can change their password on one computer while logged on to another computer. The computer with the incorrect password may continuously try to authenticate the user1 and because the password it uses to authenticate is incorrect1 the user account will eventually be locked out. To avoid lockout of authori'ed users1 configure the &ccount loc=out t'res'old setting to a high number. Cecause vulnerabilities can e9ist when the &ccount loc=out t'res'old setting is configured and when it is not1 distinct countermeasures for each of these possibilities are defined. Bour organi'ation should weigh the choice between the two based on the identified threats and the risks that you are trying to mitigate. To prevent account lockouts1 set the value for &ccount loc=out t'res'old setting to +. This configuration helps reduce help desk calls because users cannot accidentally lock themselves out of their accounts. Also1 DoS attacks that try to intentionally lock out accounts in your organi'ation will not succeed. Cecause it will not prevent a brute force attack1 choose this setting only if both of the following criteria are e9plicitly met" The password policy re=uires all users to have comple9 passwords that consist of eight or more characters. A robust audit mechanism is in place that can alert administrators when a series of account logon failures occur in the environment. :or e9ample1 the audit mechanism should monitor for security event 5,61 which is GLogon failure. The account was locked out at the time the logon attempt was made.G This event means that the account was locked out at the time the logon attempt threshold was reached. However1 event 5,6 only shows an account lockout1 not a failed password attempt. Therefore1 your administrators should also monitor for a series of bad password attempts.
3f these criteria are not met1 the second option is to configure the &ccount loc=out t'res'old setting to a high enough value that will provide users with the ability to accidentally mistype their password several times and not lock themselves out of their accounts. However1 the value should help ensure that a brute force password attack will still lock out the account.
This guide recommends that you configure the &ccount loc=out t'res'old setting value to <0 for the Legacy Client and ?nterprise Client environments1 which should provide ade=uate security and acceptable usability. This value will prevent accidental account lockouts and reduce help desk calls1 but will not prevent a DoS attack as described earlier. However1 this guide recommends that you configure this policy setting value to 10 for Speciali'ed Security % Limited :unctionality environments.
(2
/eset account loc=out counter after

This policy setting determines the length of time before the &ccount loc=out t'res'old resets to + and the account is unlocked. 3f you define an &ccount loc=out t'res'old1 then this reset time must be less than or e=ual to the value for the &ccount loc=out duration setting. The /eset account loc=out counter after setting works in coordination with other settings. 3f you leave this policy setting at its default value or configure it to an interval that is too long1 you could make your environment vulnerable to an account lockout DoS attack. !ithout a policy setting to reset the account lockout1 administrators would have to manually unlock all accounts. Conversely1 if there is a reasonable time value for this setting1 users would be locked out for a set period until all of the accounts are unlocked automatically. This guide recommends that you configure the /eset account loc=out counter after setting to ,+ minutes for the Legacy Client and ?nterprise Client environments. This configuration defines a reasonable time period that users are more likely to accept without the need for assistance from the help desk. However1 this guide recommends that you configure this policy setting to .5 minutes for Speciali'ed Security @ Limited :unctionality environments.
4erberos +o#icies
Ferberos policies are used for domain user accounts. These policies determine settings that relate to the Ferberos version 5 authentication protocol1 such as ticket lifetimes and enforcement. Ferberos policies do not e9ist in the local computer policy. 3f you reduce the lifetime of Ferberos tickets1 the risk of an attacker who attempts to steal passwords to impersonate legitimate user accounts is decreased. However1 the need to maintain these policies increases the authori'ation overhead. 3n most environments1 the default values for these policies should not be changed. Cecause the Ferberos settings are included in the default domain policy and enforced there1 this guide does not include them in the security templates that accompany this guide. This guide recommends that no changes be made to the default Ferberos policies. :or more information about these policy settings1 refer to the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
Security Options
The three different types of account policies that are discussed earlier in this chapter are defined at the domain level and are enforced by all of the domain controllers in the domain. A domain controller always obtains the account policy from the Default Domain -olicy H-$1 even if there is a different account policy applied to the $J that contains the domain controller. There are three security options settings that are similar to account policies. Bou should apply these settings at the level of the entire domain and not within individual $Js. Bou can configure these settings in the Hroup -olicy $b7ect ?ditor at the following location" Computer Confi"uration\Windows Settin"s\Security Settin"s\ 2ocal %olicies\Security +ptions
()
Security Options Settin(s

The following table summari'es the recommended security options settings. Additional information for each setting is provided in the subsections that follow the table. Table 3 3 Security +ptions Settin"s Settin" Microsoft network server" Disconnect clients when logon hours e9pire 8etwork Access" Allow anonymous S3D#8AM? translation 8etwork Security" :orce Logoff when Logon Hours e9pire 2e"acy Client ?nabled !nterprise Client ?nabled Speciali1ed Security 7 2imited 0unctionality ?nabled
Disabled
Disabled
Disabled
?nabled
?nabled
?nabled
Microsoft networ= server> -isconnect clients w'en lo"on 'ours e3pire

This policy setting determines whether to disconnect users who are connected to the local computer outside their user account s valid logon hours. This policy setting affects the server message block /SMC0 component. !hen it is enabled1 client sessions with the SMC service are forcibly disconnected when the client s logon hours e9pire. 3f it is disabled1 an established client session is allowed to be maintained after the client s logon hours have e9pired. 3f you enable this policy setting1 you should also enable the .etwor= security> 0orce lo"off w'en lo"on 'ours e3pire setting. 3f your organi'ation has configured logon hours for users1 then it makes sense to enable the Microsoft networ= server> -isconnect client w'en lo"on 'ours e3pire setting. $therwise1 users who should not have access to network resources outside of their logon hours may actually be able to continue to use those resources with sessions that were established during allowed hours. This guide recommends that you configure the Microsoft networ= server> -isconnect client w'en lo"on 'ours e3pire settin" to !nabled for the three environments that are defined in the guide. 3f logon hours are not used1 this policy setting will have no impact.
.etwor= &ccess> &llow anonymous S)-5.&M! translation

This policy setting determines if an anonymous user can re=uest the S3D for another user. 3f the .etwor= &ccess> &llow anonymous S)-5.&M! translation setting is enabled on a domain controller1 a user who knows an administrator s standard well%known S3D attributes could contact a computer that also has this policy enabled and use the S3D to obtain the administrator s name. That person could then use the account name to initiate a password guessing attack. Cecause the default configuration for the .etwor= &ccess> &llow anonymous S)-5.&M! translation setting is -isabled on member computers1 they will not be affected by this policy setting. However1 the default configuration for domain controllers is !nabled. 3f you disable this policy setting1 computers that run older operating systems
((
may not be able to communicate with domains that are based on !indows Server *++, with S-.. ?9amples of such computers include" !indows 8T( E.+@based Kemote Access Service servers. Microsoft SXL Servers) that run on !indows 8T ,.9@based or !indows 8T E.+@ based computers. Kemote Access Service servers that run on !indows *+++@based computers that are located in !indows 8T ,.9 domains or !indows 8T E.+ domains.
This guide recommends that you configure the .etwor= &ccess> &llow anonymous S)-5.&M! translation setting to -isabled for the three environments that are defined in the guide.
.etwor= Security> 0orce 2o"off w'en 2o"on ?ours e3pire

This policy setting determines whether to disconnect users who are connected to a local computer outside their user account s valid logon hours. This setting affects the SMC component. 3f you enable the .etwor= Security> 0orce 2o"off w'en 2o"on ?ours e3pire setting1 client sessions with the SMC server will be forcibly disconnected when the user s logon hours e9pire. The user will be unable to log on to the computer until their ne9t scheduled access time. 3f you disable this policy setting1 users will be able to maintain an established client session after their logon hours e9pire. To affect domain accounts1 this setting must be defined in the Default Domain -olicy. This guide recommends that you configure the .etwor= Security> 0orce 2o"off w'en 2o"on ?ours e3pire setting to !nabled for the three environments that are defined in the guide.
Su""ary
This chapter discussed the need to review all domain%wide settings in the organi'ation. $nly one set of password1 account lockout1 and Ferberos version 5 authentication protocol policies can be configured for each domain. $ther password and account lockout settings will only affect the local accounts on member servers. -lan to configure settings that will apply to all member servers of the domain1 and ensure that these settings provide an ade=uate level of security across your organi'ation.
('
)ore In&or"ation
The following links provide additional information about topics that relate to domain policy for servers that run !indows Server *++, with S-.. :or information about the ability of anonymous users to re=uest security identifier attributes for other users1 see the 8etwork access" Allow anonymous S3D#name translation page at http"##technet*.microsoft.com#!indowsServer#en#Library#*66>+,be%+e>5%EcL+%b+b5% .bLEE>L556b,.+,,.msp9. :or information about network security and how to force logoff when logon hours e9pire1 see SThe Mole Y,*" Technical Answers from 3nside Microsoft % Moving Jsers1 Sharing -rinters1 Two -DCs1 Logoff1 CackTalkT at www.microsoft.com#technet#archive#community#columns#inside#techan,*.msp9. Also1 see the Microsoft Fnowledge Case article SHuest Account Cannot be Jsed !hen Anonymous Access 3s DisabledT at http"##support.microsoft.com#? kbid4*5..N..
Chapter ,: %he )e"ber Server -ase#ine +o#icy

Overview
This chapter documents the configuration re=uirements to manage a baseline security template for all servers that run Microsoft( !indows Server) *++, with Service -ack . /S-.0. The chapter also provides administrative guidance for the setup and configuration of a secure !indows Server *++, with S-. configuration in three distinct environments. The configuration re=uirements in this chapter form the baseline for all of the procedures that are described in later chapters of this guide. These chapters describe how to harden specific server roles. The setting recommendations in this chapter will help establish security at the foundation of business application servers in an enterprise environment. However1 you must comprehensively test the coe9istence of these security configurations with your organi'ation s business applications before you implement them in production environments. The recommendations in this chapter are suitable for most organi'ations and may be deployed on either e9isting or new computers that run !indows Server *++, with S-.. The default security configurations within !indows Server *++, with S-. were researched1 reviewed1 and tested by the team that created this guide. :or information about all default settings and a detailed e9planation of each of the settings that are discussed in this chapter1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56. Henerally1 most of the following configuration recommendations provide greater security than the default settings. The security settings that are discussed in this chapter relate to the following three environments" 2e"acy Client @2CA. This environment includes computers that run !indows 8T( E.+ and Microsoft !indows( 6>1 which are sometimes referred to as #e!acy operating systems. Although this environment provides ade=uate security1 it is the least secure of the three environments that are defined in this guide. To provide stronger security1 organi'ations may choose to migrate to the more secure ?nterprise Client environment. 3n addition to the referenced legacy operating systems1 the LC environment includes !indows *+++ -rofessional and !indows 2- -rofessional workstations. This environment only contains !indows *+++ or !indows Server *++, domain controllers. There are no !indows 8T E.+ domain controllers in this environment1 but !indows 8T member servers may e9ist. !nterprise Client @!CA. This environment provides solid security and is designed for more recent versions of the !indows operating system. The ?C environment includes client computers that run !indows *+++ -rofessional and !indows 2-rofessional. Most of the work that is re=uired to migrate from the LC environment to the ?C environment involves upgrades of legacy clients such as !indows 6> and !indows 8T E.+ !orkstation to !indows *+++ or !indows 2-. All domain
Chapter ($ The Member +erver 9aseline 8olic"
(:
controllers and member servers in this environment run !indows *+++ Server or !indows Server *++,. Speciali1ed Security 7 2imited 0unctionality @SS20A. This environment provides much stronger security than the ?C environment. Migration from the ?C environment to the Speciali'ed Security @ Limited :unctionality /SSL:0 environment re=uires compliance with stringent security policies for both client computers and servers. This environment includes client computers that run !indows *+++ -rofessional and !indows 2- -rofessional1 and domain controllers that run !indows *+++ Server or !indows Server *++,. 3n the SSL: environment1 security concerns are so great that significant loss of client functionality and manageability is considered an acceptable tradeoff if the highest levels of security can be achieved. Member servers in this environment run !indows *+++ Server or !indows Server *++,.
Bou will notice that in many cases the SSL: environment will e9plicitly set the default value. Bou should assume that this configuration will affect compatibility1 because it may cause applications that attempt to ad7ust some settings locally to fail. :or e9ample1 some applications need to ad7ust user rights assignments to grant their service account additional privileges. Cecause Hroup -olicies take precedence over local machine policy1 these operations will fail. Bou should thoroughly test all applications before you deploy any of the recommended settings to your production computersIespecially SSL: settings. The following figure shows the three security environments and the clients that are supported in each.
0i"ure B 1 !3istin" and planned security environments $rgani'ations that want to secure their environments by means of a phased approach may choose to start at the Legacy Client environment level and then gradually migrate to more secure environments as they upgrade and test their applications and client computers with tightened security settings. The following figure shows how the .inf file security templates are used as a foundation for the ?nterprise Client @ Member Server Caseline -olicy /MSC-0. The figure also shows one possible way to link this policy and apply it to all servers in an organi'ation. !indows Server *++, with S-. ships with default setting values that are configured to create a secure environment. 3n many instances1 this chapter prescribes settings that are different than the default values. The chapter also enforces specific defaults for all three
(;
environments. :or information about all default settings1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2- at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
0i"ure B 2 T'e !C*Member Server #aseline inf security template is imported into t'e MS#%C w'ic' is t'en lin=ed to t'e Member Servers or"ani1ational unit @+(A -rocedures to harden specific server roles are defined in the remaining chapters of this guide. The primary server roles that are discussed in this guide include" Domain controllers that include D8S services 3nfrastructure servers that include !38S and DHC- services :ile servers -rint servers !eb servers that run 3nternet 3nformation Services /33S0 Microsoft 3nternet Authentication Server /3AS0 servers Certificate Services /CA0 servers Castion hosts
Many of the following settings that appear in the ?nterprise Client MSC- also apply to these server roles in the three environments that are defined in this guide. The security templates are uni=uely designed to address the security needs of each particular environment. The following table shows the names of the baseline security templates for the three environments.
(-
Table B 1 #aseline Security Templates for &ll T'ree !nvironments 2e"acy Client LC%Member Server Caseline.inf !nterprise Client ?C%Member Server Caseline.inf Speciali1ed Security 7 2imited 0unctionality SSL:%Member Server Caseline.inf
The security settings that are common to all three environments and therefore all Member Server #aseline security templates are described throughout the rest of this chapter. The baseline security templates are also the basis for the domain controller security templates that are defined in Chapter 51 GThe Domain Controller Caseline -olicy.G The -omain Controllers /ole security templates include baseline settings for the Domain Controllers Hroup -olicy H-$1 which is linked to the Domain Controllers $J in all three environments. Step%by%step instructions for how to create the $Js and Hroup -olicies and then import the appropriate security template into each H-$ are provided in Chapter *1 G!indows Server *++, Hardening Mechanisms.G
3ote$ +ome procedures that are used to harden servers cannot be automated b" means of 5roup 8olic". These procedures are described in the KAdditional +ecurit" +ettin&sL section of this chapter.
Windows Server 2003 -ase#ine +o#icy

Settings at the Member Server $J level define the common settings for all member server roles that are discussed in this guide. To apply these settings1 you can create a H-$ that is linked to the Member Server $J1 which is known as a baseline policy. The H-$ automates the configuration of specific security settings on each server. Bou will have to move the server accounts to the appropriate child $Js of the Member Server $J based on each server s role. The following settings are described as they appear in the user interface /J30 of the Microsoft Management Console /MMC0 Security Configuration ?ditor /SC?0 snap%in.
3udit +o#icy
Administrators should create an Audit policy that defines which security events get reported1 and that records user or computer activity in specified event categories. Administrators can monitor security%related activity1 such as who accesses an ob7ect1 if a user logs on to or off from a computer1 or if changes are made to an Audit policy setting. Cefore you implement an Audit policy1 you must decide which event categories to audit for the environment. The audit settings that an administrator chooses for the event categories define the organi'ation s Audit policy. !hen audit settings for specific event categories are defined1 administrators can create an Audit policy that suits the security needs of the organi'ation. 3f no Audit policy e9ists1 it will be difficult or impossible to determine what took place during a security incident. However1 if audit settings are configured so that many authori'ed activities generate events1 the Security log will fill up with useless data. The following recommendations and setting descriptions are provided to help you determine what to monitor so that the collected data is relevant. $ftentimes1 failure logs are much more informative than success logs because failures typically indicate errors. :or e9ample1 successful logon to a computer by a user would
'0
typically be considered normal. However1 if someone unsuccessfully tries to log on to a computer multiple times1 it may indicate an attempt to break into the computer with someone else s account credentials. The event logs record events on the computer. 3n Microsoft !indows operating systems1 there are separate event logs for applications1 security events1 and system events. The Security log records audit events. The event log container of Hroup -olicy is used to define attributes that are related to the Application1 Security1 and System event logs1 such as ma9imum log si'e1 access rights for each log1 and retention settings and methods. Cefore an Audit policy implementation1 organi'ations should determine how they will collect1 organi'e1 and analy'e the data. Large volumes of audit data have little value if there is no plan to e9ploit it. Also1 performance may be affected when computer networks are audited. The impact for a given combination of settings may be negligible on an end% user computer but =uite noticeable on a busy server. Therefore1 you should test whether performance will be affected before you deploy new audit settings in your production environment. The following table includes the Audit policy setting recommendations for all three environments that are defined in this guide. Bou may notice that the settings for most values are similar for all three environments. Additional information about each setting is provided in the subsections that follow the table. Bou can configure the Audit policy setting values in !indows Server *++, with S-. at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\ 2ocal %olicies\&udit %olicy :or a summary of the prescribed settings in this section1 see the Microsoft ?9cel( workbook G!indows Server *++, Security Huide Settings1G which is included with the downloadable version of this guide. :or more information about the default settings and a detailed e9planation of each of the settings that are discussed in this section1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#? Link3d4.5.56. Table B 2 &udit %olicy Settin"s Settin" Audit account logon events Audit account management Audit logon events Audit ob7ect access Audit policy change Audit privilege use Audit process tracking Audit system events 2e"acy Client Success Success Success 8o Auditing Success 8o Auditing 8o Auditing Success !nterprise Client Success Success Success 8o Auditing Success 8o Auditing 8o Auditing Success Speciali1ed Security 7 2imited 0unctionality Success :ailure Success :ailure Success :ailure :ailure Success :ailure 8o Auditing Success
'.
3udit account #o(on events

This policy setting determines whether to audit each instance of a user who logs on to or off from another computer that validates the account. Authentication of a domain user account on a domain controller generates an account logon event that is logged in the domain controller s Security log. Authentication of a local user on a local computer generates a logon event that is logged in the local Security log. 8o account logoff events are logged. The &udit account lo"on events setting is configured to log Success values for the LC and ?C baseline policies1 and to log both Success and 0ailure events for the SSL: baseline policy. The following table includes the important security events that this policy setting logs in the Security log. These event 3Ds can be useful when you want to create custom alerts to monitor any software suite1 such as Microsoft $perations Manager /M$M0. Table B 3 &ccount 2o"on !vents !vent )LN* !vent description An authentication service /AS0 ticket was successfully issued and validated. 3n !indows Server *++, with S-.1 the type of this event will be Success Audit for successful re=uests or :ailure Audit for failed re=uests. A ticket granting service /THS0 ticket was granted. A THS is a ticket that is issued by the Ferberos version 5 THS that allows a user to authenticate to a specific service in the domain. !indows Server *++, with S-. will log successes and failures for this event type. A security principal renewed an AS ticket or a THS ticket. -re%authentication failed. This event is generated on a Fey Distribution Center /FDC0 when a user enters an incorrect password. Authentication ticket re=uest failed. This event is not generated by !indows Server *++, with S-.. $ther !indows versions use this event to indicate an authentication failure that was not due to incorrect credentials. A THS ticket was not granted. This event is not generated by !indows Server *++, with S-.1 which uses a failure audit event with 3D LN* for this case. An account was successfully mapped to a domain account. Logon failure. A domain account logon was attempted. This event is only generated by domain controllers. A user has reconnected to a disconnected Terminal Server session. A user disconnected a Terminal Server session but did not log off.
LN,
LNE LN5 LNL
LNN
LN> L>. L>* L>,
'2
3udit account "ana(e"ent

This policy setting determines whether to audit each account management event on a computer. ?9amples of account management events include" A user account or group is created1 changed1 or deleted. A user account is renamed1 disabled1 or enabled. A password is set or changed.
$rgani'ations need to be able to determine who creates1 modifies1 or deletes both domain and local accounts. Jnauthori'ed changes could indicate mistaken changes made by an administrator who does not understand how to follow organi'ational policies1 but could also indicate a deliberate attack. :or e9ample1 account management failure events often indicate attempts by a lower%level administratorIor an attacker who has compromised a lower%level administrator s account Ito elevate their privileges. The logs can help you determine which accounts an attacker has modified and created. The &udit account mana"ement setting is configured to log Success values for the LC and ?C baseline policies1 and to log both Success and 0ailure values for the SSL: baseline policy. The following table includes the important security events that this policy setting records in the Security log. These event 3Ds can be useful when you want to create custom alerts to monitor any software suite1 such as M$M. Most operational management software can be customi'ed with scripts to capture or flag events that are based on these event 3Ds. Table B B &ccount Mana"ement !vents !vent )- !vent description L*E L*N L*> L,+ L,. L,* L,, L,E L,5 L,L L,N L,> L,6 LE. LE* LE, LEE A user account was created. A user password was changed. A user password was set. A user account was deleted. A global group was created. A member was added to a global group. A member was removed from a global group. A global group was deleted. A new local group was created. A member was added to a local group. A member was removed from a local group. A local group was deleted. A local group account was changed. A global group account was changed. A user account was changed. A domain policy was modified. A user account was automatically locked.
')
!vent )- !vent description LE5 LEL LEN LE> A computer account was created. A computer account was changed. A computer account was deleted. A local security group with security disabled was created.
3ote$ +2C/46TJM76+A9!27 in the formal name means that this &roup cannot be used to &rant permissions in access checks.
LE6 L5+ L5. L5* L5, L5E L55 L5L L5N L5> L56 LL+ LL. LL* LL, LLE LL5 LLL LLN LL> L>E
A local security group with security disabled was changed. A member was added to a security%disabled local security group. A member was removed from a security%disabled local security group. A security%disabled local group was deleted. A security%disabled global group was created. A security%disabled global group was changed. A member was added to a security%disabled global group. A member was removed from a security%disabled global group. A security%disabled global group was deleted. A security%enabled universal group was created. A security%enabled universal group was changed. A member was added to a security%enabled universal group. A member was removed from a security%enabled universal group. A security%enabled universal group was deleted. A security%disabled universal group was created. A security%disabled universal group was changed. A member was added to a security%disabled universal group. A member was removed from a security%disabled universal group. A security%disabled universal group was deleted. A group type was changed. The security descriptor of administrative group members was set.
3ote$ 2ver" 60 minutes on a domain controller# a back&round thread searches all members of administrative &roups @such as domain# enterprise# and schema administratorsA and applies a fi0ed securit" descriptor on them. This event is lo&&ed.
L>5
8ame of an account was changed.
3udit #o(on events

This policy setting determines whether to audit each instance of user logon and logoff from a computer. The &udit lo"on events setting generates records on domain controllers to monitor domain account activity and on local computers to monitor local account activity.
'(
3f you configure the &udit lo"on events setting to .o auditin"1 it is difficult or impossible to determine which users have either logged on or attempted to log on to computers in the organi'ation. 3f you enable the Success value for the &udit lo"on events setting on a domain member1 an event will be generated each time that someone logs on to the network1 regardless of where the accounts reside on the network. 3f the user logs on to a local account and the &udit account lo"on events setting is !nabled1 the user logon will generate two events. ?ven if you do not modify the default values for this policy setting1 no audit record evidence will be available for analysis after a security incident takes place. The &udit lo"on events setting is configured to log Success values in the LC and ?C baseline policies and to log both Success and 0ailure values for the SSL: policy. The following table includes the important security events that this policy setting records in the Security log. Table B < &udit 2o"on !vents !vent )- !vent description 5*> 5*6 5,+ 5,. 5,* 5,, 5,E 5,5 5,L 5,N 5,> 5,6 5E+ 5E. A user successfully logged on to a computer. Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password. Logon failure. A logon attempt was made outside the allowed time. Logon failure. A logon attempt was made using a disabled account. Logon failure. A logon attempt was made using an e9pired account. Logon failure. A logon attempt was made by a user who is not allowed to log on at the specified computer. Logon failure. The user attempted to log on with a password type that is not allowed. Logon failure. The password for the specified account has e9pired. Logon failure. The 8et Logon service is not active. Logon failure. The logon attempt failed for other reasons.
3ote$ 6n some cases# the reason for the lo&on failure ma" not be known.
The logoff process was completed for a user. Logon failure. The account was locked out at the time the logon attempt was made. A user successfully logged on to a network. Main mode 3nternet Fey ?9change /3F?0 authentication was completed between the local computer and the listed peer identity /establishing a security association01 or =uick mode has established a data channel. A data channel was terminated. Main mode was terminated.
3ote$ This mi&ht occur because the time limit on the securit" association e0pired @the default is ei&ht hoursA# because of polic" chan&es# or peer termination.
5E* 5E,
5EE
Main mode authentication failed because the peer did not provide a valid certificate or the signature was not validated.
''
!vent )- !vent description 5E5 5EL Main mode authentication failed because of a Ferberos authentication protocol failure or a password that is not valid. 3F? security association establishment failed because the peer sent a proposal that is not valid. A packet was received that contained data that is not valid. A failure occurred during an 3F? handshake. Logon failure. The security identifier /S3D0 from a trusted domain does not match the account domain S3D of the client. Logon failure. All S3Ds corresponding to untrusted namespaces were filtered out during an authentication across forests. 8otification message that could indicate a possible denial%of%service /DoS0 attack. A user initiated the logoff process. A user successfully logged on to a computer with e9plicit credentials while already logged on as a different user. A user has reconnected to a disconnected terminal server session. A user disconnected a terminal server session but did not log off.
3ote$ This event is &enerated when a user is connected to a terminal server session over the network. 6t appears on the terminal server.
5EN 5E> 5E6 55+ 55. 55* L>* L>,
3udit ob:ect access

Cy itself1 this policy setting will not cause any events to be audited. The &udit ob,ect access setting determines whether to audit the event when a user accesses an ob7ectI for e9ample1 a file1 folder1 registry key1 or printerIthat has a specified system access control list /SACL0. A SACL is comprised of access control entries /AC?0. ?ach AC? contains three pieces of information" The security principal /user1 computer1 or group0 to be audited. The specific access type to be audited /called an access mask0. A flag to indicate whether to audit failed access events1 successful access events1 or both.
3f you configure the &udit ob,ect access setting to log Success values1 an audit entry will be generated each time that a user successfully accesses an ob7ect with a specified SACL. 3f you configure this policy setting to log 0ailure values1 an audit entry will be generated each time that a user unsuccessfully attempts to access an ob7ect with a specified SACL. $rgani'ations should define only the actions they want enabled when SACLs are configured. :or e9ample1 you might want to enable the Write and &ppend -ata audit setting on e9ecutable files to track when they are changed or replaced1 because computer viruses1 worms1 and Tro7an horses typically target e9ecutable files. Similarly1 you might want to track when sensitive documents are accessed or changed.
'6
The &udit ob,ect access setting is configured to the default value of .o auditin" in the baseline policy for the LC and ?C environments. However1 this policy setting is configured to log 0ailure values in the baseline policy for the SSL: environment. The following table includes the important security events that this policy setting records in the Security log. Table B D +b,ect &ccess !vents !vent )- !vent description 5L+ 5L* 5L, Access was granted to an already e9isting ob7ect. A handle to an ob7ect was closed. An attempt was made to open an ob7ect with the intent to delete it.
3ote$ This event is used b" file s"stems when the ,6!2M72!2T2M1 MC!1+2 fla& is specified in Createfile@A.
5LE 5L5 5LN
A protected ob7ect was deleted. Access was granted to an ob7ect type that already e9ists. A permission associated with a handle was used.
3ote$ A handle is created with certain &ranted permissions @such as 4ead and 3riteA. 3hen the handle is used# up to one audit is &enerated for each of the permissions that were used.
5L> 5L6 5N+ 5N. 5N* NN* NN, NNE NN5 NNL NNN NN> NN6 N>+ N>. N>* N>, N>E
An attempt was made to create a hard link to a file that is being audited. The resource manager in Authori'ation Manager attempted to create a client conte9t. A client attempted to access an ob7ect.
3ote$ An event will be &enerated for ever" attempted operation on the ob?ect.
The client conte9t was deleted by the Authori'ation Manager application. The Administrator Manager initiali'ed the application. The Certificate Manager denied a pending certificate re=uest. Certificate Services received a resubmitted certificate re=uest. Certificate Services revoked a certificate. Certificate Services received a re=uest to publish the certificate revocation list /CKL0. Certificate Services published the CKL. A certificate re=uest e9tension was made. $ne or more certificate re=uest attributes changed. Certificate Services received a re=uest to shut down. Certificate Services backup started. Certificate Services backup completed. Certificate Services restore started. Certificate Services restore completed. Certificate Services started.
':
!vent )- !vent description N>5 N>L N>N N>> N>6 N6+ N6. N6* N6, N6E N65 N6L N6N N6> N66 >++ >+. Certificate Services stopped. The security permissions for Certificate Services changed. Certificate Services retrieved an archived key. Certificate Services imported a certificate into its database. The audit filter for Certificate Services changed. Certificate Services received a certificate re=uest. Certificate Services approved a certificate re=uest and issued a certificate. Certificate Services denied a certificate re=uest. Certificate Services set the status of a certificate re=uest to pending. The certificate manager settings for Certificate Services changed. A configuration entry changed in Certificate Services. A property of Certificate Services changed. Certificate Services archived a key. Certificate Services imported and archived a key. Certificate Services published the certification authority /CA0 certificate to Active Directory. $ne or more rows have been deleted from the certificate database. Kole separation enabled.
3udit po#icy chan(e

This policy setting determines whether to audit every incident of a change to user rights assignment policies1 trust policies or the Audit policy itself. 3f you configure the &udit policy c'an"e setting to log Success values1 an audit entry will be generated for each successful change to user rights assignment policies1 trust policies1 or Audit policies. 3f you configure this policy setting to log 0ailure values1 an audit entry will be generated for each failed change to user rights assignment policies1 trust policies1 or Audit policies. The recommended settings would allow you to you see any account privileges that an attacker attempts to elevateIfor e9ample1 if they tried to add the -ebu" pro"rams privilege or the #ac= up files and directories privilege. The &udit policy c'an"e setting is configured to log Success values in the baseline policy for all three environments that are defined in this guide. Currently1 the 0ailure setting value does not capture meaningful events. The following table includes the important security events that this policy setting records in the Security log.
';
Table B E &udit %olicy C'an"e !vents !vent )- !vent description L+> L+6 L.+ L.. L.* L., L.E L.5 L.L L.N L.> L*+ L*. L** L*, L*5 NL> A user right was assigned. A user right was removed. A trust relationship with another domain was created. A trust relationship with another domain was removed. An audit policy was changed. An 3nternet -rotocol security /3-sec0 policy agent started. An 3-sec policy agent was disabled. An 3-sec policy agent changed. An 3-sec policy agent encountered a potentially serious failure. A Ferberos version 5 policy changed. ?ncrypted Data Kecovery policy changed. A trust relationship with another domain was modified. System access was granted to an account. System access was removed from an account. Audit policy was set on a per%user basis Audit policy was refreshed on a per%user basis. A collision was detected between a namespace element in one forest and a namespace element in another forest.
3ote$ 3hen a namespace element in one forest overlaps a namespace element in another forest# name resolution ambi&uit" for namespace elements can result. This overlap is also called a collision. ot all parameters are valid for each entr" t"pe. ,or e0ample# fields such as 7 + name# et961+ name# and +67 are not valid for an entr" of t"pe GTop!evel ame.G
NL6
Trusted forest information was added.

3ote$ This event messa&e is &enerated when forest trust information is updated and one or more entries are added. 1ne event messa&e is &enerated for each added# deleted# or modified entr". 6f multiple entries are added# deleted# or modified in a sin&le update of the forest trust information# all the &enerated event messa&es are assi&ned a sin&le uni=ue identifier called an operation 67. This functionalit" allows "ou to determine that the multiple &enerated event messa&es are the result of a sin&le operation. ot all parameters are valid for each entr" t"pe. ,or e0ample# parameters such as 7 + name# et961+ name and +67 are not valid for an entr" of t"pe HTop!evel ame.H
NN+ NN. >+5
Trusted forest information was deleted.

3ote$ +ee event description for event :6-.
Trusted forest information was modified.

3ote$ +ee event description for event :6-.
The event log service read the Security log configuration for a session.
'-
3udit privi#e(e use

This policy setting determines whether to audit each e9ercise of a user right. 3f you configure the &udit privile"e use setting to log Success values1 an audit entry will be generated each time that a user right is e9ercised successfully. 3f you configure this policy setting to log 0ailure values1 an audit entry will be generated each time that a user right is e9ercised unsuccessfully. Audits are not generated when the following user rights are e9ercised1 even if you configure the &udit privile"e use setting1 because these user rights generate many events in the Security log. -erformance of your computers would likely be affected if these user rights were audited" Cypass traverse checking Debug programs Create a token ob7ect Keplace process level token Henerate security audits Cack up files and directories Kestore files and directories
3ote$ 6f "ou wish to audit these user ri&hts# "ou must enable the 0udit: 0udit the use o* 'ac5up and +estore privi$ege securit" option in 5roup 8olic".
The &udit privile"e use setting is left at the default value of .o auditin" in the baseline policy for the LC and ?C environments. However1 this policy setting is configured to log 0ailure values in the baseline policy for the SSL: environment. :ailed use of a user right is an indicator of a general network problem1 and can often indicate an attempted security breach. $rgani'ations should configure the &udit privile"e use setting to !nable only if there is a specific business reason to do so. The following table includes the important security events that this setting records in the Security log. Table B F %rivile"e (se !vents !vent )- !vent description 5NL 5NN 5N> Specified privileges were added to a user s access token.
3ote$ This event is &enerated when the user lo&s on.
A user attempted to perform a privileged system service operation. -rivileges were used on an already open handle to a protected ob7ect.
3udit process trackin(

This policy setting determines whether to audit detailed tracking information for events such as program activation1 process e9it1 handle duplication1 and indirect ob7ect access. 3f you configure this policy setting to log Success values1 an audit entry is generated each time that the process that is being tracked succeeds. 3f you configure this policy setting to log 0ailure values1 an audit entry is generated each time that the process that is being tracked fails. The &udit process trac=in" setting will generate a large number of events1 so it is typically configured to .o auditin"1 as it is in the baseline policy for all three
60
environments that are defined in this guide. However1 this policy setting can be very helpful during an incident response because it provides a detailed log of the processes that are started and the time when each one was launched. The following table includes the important security events that this setting records in the Security log. Table B : %rocess Trac=in" !vents !vent )- !vent description 56* 56, 56E 565 56L A new process was created. A process e9ited. A handle to an ob7ect was duplicated. 3ndirect access to an ob7ect was obtained. A data protection master key was backed up.
3ote$ The master ke" is used b" the Cr"pt8rotect7ata and Cr"pt/nprotect7ata routines# and 2ncr"ptin& ,ile +"stem @2,+A. The master ke" is backed up each time a new one is created. @The default settin& is -0 da"s.A The ke" is usuall" backed up b" a domain controller.
56N 56> 566 L++ L+. L+*
A data protection master key was recovered from a recovery server. Auditable data was protected. Auditable data was unprotected. A process was assigned a primary token. A user attempted to install a service. A scheduler 7ob was created.
3udit syste" events

This policy setting determines whether to audit when a user restarts or shuts down a computer or when an event occurs that affects either the computer;s security or the Security log. 3f you configure this policy setting to log Success values1 an audit entry is generated when a system event is e9ecuted successfully. 3f you configure this policy setting to log 0ailure events1 an audit entry is generated when a system event is attempted unsuccessfully. The following table includes the most useful successful events for this setting. Table B 10 System !vent Messa"es for &udit System !vents !vent )- !vent description 5.* 5., 5.E 5.5 5.L !indows is starting up. !indows is shutting down. An authentication package was loaded by the Local Security Authority. A trusted logon process has registered with the Local Security Authority. 3nternal resources that were allocated to =ueue of security event messages have been e9hausted1 and the loss of some security event messages has occurred.
6.
!vent )- !vent description 5.N 5.> 5.6 The audit log was cleared. A notification package was loaded by the Security Accounts Manager. A process is using an invalid local procedure call /L-C0 port in an attempt to impersonate a client and reply or read from or write to a client address space. The system time was changed.
3ote$ This audit t"picall" appears twice.
5*+
7ser $i(hts 3ssi(n"ents

Jser rights assignments provide users and groups with logon rights or privileges on the computers in your organi'ation. An e9ample of a logon right is the right to log on to a computer interactively. An e9ample of a privilege is the right to shut down the computer. Coth types are assigned by administrators to individual users or groups as part of the security settings for the computer.
3ote$ Throu&hout this section# H ot definedH applies onl" to usersN Administrators still have the user ri&ht. !ocal administrators can make chan&es# but an" domain-based 5roup 8olic" settin&s will override them the ne0t time that the 5roup 8olicies are refreshed or reapplied.
Bou can configure the user rights assignment settings in !indows Server *++, with S-. at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\ 2ocal %olicies\(ser /i"'ts &ssi"nment The default user rights assignments are different for the various types of servers in your organi'ation. :or e9ample1 !indows Server *++, assigns different rights to built%in groups on member servers and domain controllers. /Similarities between built%in groups on different server types are not documented in the following list. Member Servers %ower (sers. -ossess most administrative powers with some restrictions. -ower Jsers can run legacy applications in addition to applications that are certified for !indows Server *++, with S-. or !indows 2-. ?elpServicesGroup. The group for the Help and Support Center. SupportP,>>6E5a+ is a member of this group by default. TelnetClients. Members of this group have access to the Telnet server on the network. Server +perators. Members of this group can administer domain servers. Terminal Server 2icense Services. Members of this group have access to Terminal Server License Servers on the network. Windows &ut'ori1ation &ccess Group. Members of this group have access to the computed tokenHroupsHlobalAndJniversal attribute on user ob7ects.
-omain Controllers
The Guests group and the user accounts Huest and SupportP,>>6E5a+ have uni=ue S3Ds between different domains. Therefore1 this Hroup -olicy for user rights assignments may need to be modified on a computer on which only the specific target group e9ists. Alternatively1 the policy templates can be edited individually to include the appropriate
62
groups within the .inf files. :or e9ample1 a domain controller Hroup -olicy could be created on a domain controller in a test environment.
3ote$ 9ecause of the uni=ue +67s that e0ist between members of the Guests &roup# +upportM);;-('a0# and 5uest# some settin&s that are used to harden servers cannot be automated b" means of the securit" templates that are included with this &uide. These settin&s are described in the HAdditional +ecurit" +ettin&sH section later in this chapter.
This section provides details about the prescribed MSC- user rights assignment settings for all three environments that are defined in this guide. :or a summary of the prescribed settings in this section1 see the Microsoft ?9cel workbook G!indows Server *++, Security Huide Settings1G which is included with the downloadable version of this guide. :or information about the default settings and a detailed e9planation of each of the settings that are discussed in this section1 see the companion guide1 Threats and Countermeasures Security Settin!s in Windows Server 2003 and Windows XP. The following table includes the user rights assignments setting recommendations for all three environments that are defined in this guide. Additional information about each setting is provided in the subsections that follow the table. Table B 11 (ser /i"'ts &ssi"nments Settin" /ecommendations Settin" 2e"acy Client !nterprise Client Speciali1ed Security 7 2imited 0unctionality Administrators1 Authenticated Jsers1 ?8T?K-K3S? D$MA38 C$8TK$LL?KS 8o one Administrators1 8?T!$KF S?K<3C?1 L$CAL S?K<3C? Administrators
Access this computer 8ot defined from the network
8ot defined
Act as part of the operating system Ad7ust memory =uotas for a process Allow log on locally
8ot defined 8ot defined
Administrators1 Cackup $perators1 -ower Jsers Administrators and Kemote Desktop Jsers 8ot defined 8ot defined 8ot defined 8ot defined
Administrators1 Cackup $perators1 -ower Jsers Administrators and Kemote Desktop Jsers 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined
Allow log on through Terminal Services Cack up files and directories Cypass traverse checking Change the system time Create a pagefile
Administrators
Administrators Authenticated Jsers Administrators1 L$CAL S?K<3C? Administrators 8o one Administrators1 S?K<3C?
Create a token ob7ect 8ot defined Create global ob7ects 8ot defined
6)
Settin"
2e"acy Client
!nterprise Client
Speciali1ed Security 7 2imited 0unctionality 8o one 8o one A8$8$BM$JS L$H$8V HuestsV SupportP,>>6E5a+V all 8$8%$perating System service accounts HuestsV SupportP,>>6E5a+V 8o one HuestsV SupportP,>>6E5a+V Huests Administrators
Create permanent shared ob7ects Debug programs Deny access to this computer from the network
8ot defined 8ot defined A8$8$BM$JS L$H$8V HuestsV SupportP,>>6E5a +V all 8$8% $perating System service accounts HuestsV SupportP,>>6E5a + 8ot defined 8ot defined Huests
8ot defined Administrators A8$8$BM$JS L$H$8V HuestsV SupportP,>>6E5a +V all 8$8% $perating System service accounts HuestsV SupportP,>>6E5a + 8ot defined 8ot defined Huests 8ot defined
Deny logon as a batch 7ob Deny logon as a service Deny logon locally Deny logon through Terminal Services
?nable computer and 8ot defined user accounts to be trusted for delegation :orce shutdown from 8ot defined a remote system Henerate security audits 3mpersonate a client after authentication 3ncrease scheduling priority Load and unload device drivers Lock pages in memory Log on as a service Manage auditing and security log Modify firmware environment values -erform volume maintenance tasks 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined
8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined
Administrators 8?T!$KF S?K<3C?1 L$CAL S?K<3C? Administrators1 S?K<3C? Administrators Administrators 8o one 8ot defined 8?T!$KF S?K<3C? Administrators Administrators Administrators
Log on as a batch 7ob 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined
6(
Settin"
2e"acy Client
!nterprise Client
Speciali1ed Security 7 2imited 0unctionality Administrators Administrators Administrators L$CAL S?K<3C?1 8?T!$KF S?K<3C? Administrators Administrators 8o one Administrators
-rofile single process 8ot defined -rofile system performance Kemove computer from docking station Keplace a process level token Kestore files and directories Shut down the system 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined
8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined 8ot defined
Synchroni'e 8ot defined directory service data Take ownership of files or other ob7ects 8ot defined
3ccess this co"puter &ro" the network

This policy setting determines which users and groups are allowed to connect to the computer over the network. 3t is re=uired by a number of network protocols1 including server message block /SMC0%based protocols1 8etC3$S1 Common 3nternet :ile System /C3:S01 HTT-1 and Component $b7ect Model -lus /C$MW0. The &ccess t'is computer from t'e networ= setting is configured to .ot defined for the LC and ?C environments. However1 although permissions that are assigned to the !veryone security group in !indows Server *++, with S-. no longer provide access to anonymous users1 guest groups and accounts can still be assigned access through the !veryone security group. :or this reason1 the !veryone security group is denied the &ccess t'is computer from t'e networ= user right in the SSL: environment1 which helps guard against attacks that target guest access to the domain. $nly the &dministrators1 &ut'enticated (sers1 and !.T!/%/)S! -+M&). C+.T/+22!/S groups are assigned this user right in the SSL: environment.
3ct as part o& the operatin( syste"

This policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authori'ed to access. Typically1 only low%level authentication services re=uire this user right. The &ct as part of t'e operatin" system user right is configured to .ot defined for the LC and ?C environments. However1 for the SSL: environment this policy setting is configured to a null value or blank1 which denies this user right to all security groups and accounts.
6'
3d:ust "e"ory 5uotas &or a process

This policy setting determines whether users can ad7ust the ma9imum amount of memory that is available to a process. 3t is useful for computer tuning purposes1 but it can be abused. An attacker could e9ploit this user right to launch a DoS attack. The &d,ust memory 8uotas for a process setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned to the &dministrators group1 8?T!$KF S?K<3C?1 and L$CAL S?K<3C? for the SSL: environment.
3##ow #o( on #oca##y

This policy setting determines which users can log on interactively to the specified computer. Logons that are initiated with the CTKLWALTWD?L key combination on the keyboard re=uire the user to have this user right. Any account with this user right could be used to log on to the computer;s local console. The &llow lo" on locally user right is restricted to the &dministrators1 #ac=up +perators1 and %ower (sers groups for the LC and ?C environments1 which helps prevent logon by unauthori'ed users who may want to elevate their privileges or introduce viruses into the environment. This user right is assigned to only the &dministrators group for the SSL: environment.
3##ow #o( on throu(h %er"ina# Services

This policy setting determines which users or groups have permission to log on as a Terminal Services client. :or the LC and ?C environments1 the &llow lo" on t'rou"' Terminal Services user right is restricted to the &dministrators and /emote -es=top (sers groups. :or the SSL: environment1 only members of the &dministrators group are assigned this user right.
-ack up &i#es and directories

This policy setting determines whether users can circumvent file and directory permissions to back up the computer. 3t is used only when an application attempts access through the 8T:S backup application programming interface /A-30 with a backup utility such as 8TCACFJ-.?2?. $therwise1 normal file and directory permissions apply. The #ac= up files and directories setting is configured to .ot defined for the LC and ?C environments. This user right is assigned to only the &dministrators group for the SSL: environment.
-ypass traverse checkin(

This policy setting determines whether users can pass through folders without being checked for the special STraverse :olderT access permission when they navigate an ob7ect path in the 8T:S file system or in the registry. The user right does not allow the user to list the contents of a folderV it only allows the user to traverse its directories. The #ypass traverse c'ec=in" setting is configured to .ot defined for the LC and ?C environments. This user right is assigned to only the &ut'enticated (sers group for the SSL: environment.
66
Chan(e the syste" ti"e

This policy setting determines which users can change the time and date on the internal clock of the computer. Jsers who are assigned this user right can affect the appearance of event logs1 which are time stamped by the computer s internal clock. 3f the computer;s time is changed1 the logs will not reflect the actual time that events occurred. The C'an"e t'e system time setting is configured to .ot defined for the LC and ?C environments. This user right is assigned to only the &dministrators group and the 2ocal Service account for the SSL: environment.
3ote$ 7iscrepancies between the time on the local computer and on the domain controllers ma" cause problems for the <erberos authentication protocol# which could make it impossible for users to lo& on to the domain or to obtain authori>ation to access domain resources after the" lo& on.
Create a pa(e&i#e
This policy setting determines whether users can create and change the si'e of pagefiles. To perform this task1 the user specifies a page file si'e for a particular drive in the %erformance +ptions bo9 that is located on the &dvanced tab of the System %roperties dialog bo9. The Create a pa"efile setting is configured to .ot defined for the LC and ?C environments1 This user right is assigned to only the &dministrators group for the SSL: environment.
Create a token ob:ect

This policy setting determines whether a process can create a token1 which the process can then use to gain access to any local resources when it uses 8tCreateToken/0 or other token%creation A-3s. The Create a to=en ob,ect setting is configured to .ot defined for the LC and ?C environments. However1 for the SSL: environment this policy setting is configured to a null value or blank1 which means no security group or account will have this user right.
Create (#oba# ob:ects

This policy setting allows users to create global ob7ects that are available to all sessions. Jsers can still create ob7ects that are specific to their own session without being assigned this user right. The Create "lobal ob,ects setting is configured to .ot defined for the LC and ?C environments. :or the SSL: environment1 this user right is only assigned to the S!/6)C! and &dministrators groups.
Create per"anent shared ob:ects

This policy setting determines whether users can create directory ob7ects in the ob7ect manager1 which means that they can create shared folders1 printers1 and other ob7ects. 3t is useful to kernel%mode components that e9tend the ob7ect namespace1 and such components have this user right inherently. Therefore1 it is typically not necessary to specifically assign this user right to users. The Create permanent s'ared ob,ects setting is configured to .ot defined for the LC and ?C environments. However1 for the SSL: environment this policy setting is
6:
configured to a null value or blank1 which means no security group or account will have this user right.
*ebu( pro(ra"s
This policy setting determines which users can attach a debugger to any process or to the kernel. 3t provides complete access to sensitive and critical operating system components. -rograms should not be debugged in production environments e9cept in e9treme circumstances1 such as when there is a need to troubleshoot a business%critical application that cannot be effectively assessed in the test environment. The -ebu" pro"rams setting is configured to .ot defined for the LC environment. :or the ?C environment1 this user right is assigned only to the &dministrators group. However1 for the SSL: environment this policy setting is configured to a null value or blank1 which means no security group or account will have this user right.
3ote$ 1n 3indows +erver 200) with +8.# removal of the "e&ug progra s user ri&ht ma" result in an inabilit" to use the 3indows /pdate service. *owever# patches can still be manuall" downloaded and installed or applied throu&h other means. 4emoval of this user ri&ht ma" also interfere with the Cluster +ervice. ,or more information# see the Microsoft <nowled&e 9ase article H*ow to appl" more restrictive securit" settin&s on a 3indows +erver 200)-based cluster serverH at http$%%support.microsoft.com%OkbidP;-.'-:.
*eny access to this co"puter &ro" the network

3ote$ A 1 1JM1/+ !151 # 9uilt-in Administrator# +upportM);;-('a0# 5uest# and all 1 operatin& s"stem service accounts are not included in the .inf securit" template. These accounts and &roups have uni=ue +67s for each domain in "our or&ani>ation. Therefore# the" must be added manuall". ,or more information# see the KManual *ardenin& 8roceduresL section near the end of this chapter.
This policy setting determines which users will not be able to access a computer over the network. 3t denies a number of network protocols1 including SMC%based protocols1 8etC3$S1 C3:S1 HTT-1 and C$MW. This policy setting supersedes the &ccess t'is computer from t'e networ= user right when a user account is sub7ect to both settings. :or all three environments that are defined in this guide1 the -eny access to t'is computer from t'e networ= user right is assigned to the Guests group1 A8$8$BM$JS L$H$81 SupportP,>>6E5a+1 and all service accounts that are not part of the operating system. Configuration of this policy setting for other groups could limit the abilities of users who are assigned to specific administrative roles in your environment. Bou should verify that delegated tasks will not be negatively affected.
*eny #o( on as a batch :ob

This policy setting determines which accounts will not be able to log on to the computer as a batch 7ob. A batch 7ob is not a batch /.bat0 file1 but rather a batch%=ueue facility. Accounts that use the Task Scheduler to schedule 7obs need this user right. The -eny lo" on as a batc' ,ob user right overrides the 2o" on as a batc' ,ob user right1 which could be used to allow accounts to schedule 7obs that consume e9cessive
6;
system resources. Such an occurrence could cause a DoS condition. :or this reason1 the -eny lo" on as a batc' ,ob user right is assigned to the Guests group and the SupportP,>>6E5a+ user account in the baseline policy for all three environments that are defined in this guide. :ailure to assign this user right to the recommended accounts can be a security risk.
*eny #o(on as a service

This policy setting determines whether services can be launched in the conte9t of the specified account. The -eny lo"on as a service setting is configured to .ot defined for the LC and ?C environments. However1 for the SSL: environment this policy setting is configured to a null value or blank1 which means no security group or account will have this user right.
*eny #o(on #oca##y

This policy setting determines whether users can log on directly at the computer s keyboard. The -eny lo"on locally setting is configured to .ot defined for the ?C and LC environments. However1 this user right is assigned only to the Guests group and the SupportP,>>6E5a+ user account for the SSL: environment. :ailure to assign this user right to the recommended accounts can be a security risk.
*eny #o( on throu(h %er"ina# Services

This policy setting determines whether users can log on as Terminal Services clients. After the baseline member server is 7oined to a domain environment1 there is no need to use local accounts to access the server from the network. Domain accounts can access the server for administration and end%user processing. :or all three environments that are defined in this guide1 the Guests group is assigned the -eny lo" on t'rou"' Terminal Services user right so that they cannot log on through Terminal Services.
nab#e co"puter and user accounts to be trusted &or de#e(ation

This policy setting determines whether users can change the Trusted for -ele"ation setting on a user or computer ob7ect in Active Directory. Jsers or computers that are assigned this user right must also have write access to the account control flags on the ob7ect. Misuse of this user right could cause unauthori'ed impersonation of other users on the network. The !nable computer and user accounts to be trusted for dele"ation setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned only to the &dministrators group for the SSL: environment.
6-
Force shutdown &ro" a re"ote syste"

This policy setting determines whether users can shut down computers from remote locations on the network. Any user who can shut down a computer could cause a DoS condition. Therefore1 this user right should be tightly restricted. The 0orce s'utdown from a remote system setting is configured to .ot defined for the LC and ?C environments. This user right is assigned only to the &dministrators group for the SSL: environment.
Generate security audits

This policy setting determines whether a process can generate audit records in the Security log. Cecause the Security log can be used to trace unauthori'ed access1 accounts that can write to the Security log could be used by an attacker to fill that log with meaningless events. 3f you configure the computer to overwrite events as needed1 an attacker could use this capability to remove evidence of their unauthori'ed activities. 3f you configure the computer to shut down when it is unable to write to the Security log1 an attacker could use this capability to create a DoS condition. The Generate security audits setting is configured to .ot defined for the LC and ?C environments. This user right is assigned only to the 8?T!$KF S?K<3C? and L$CAL S?K<3C? accounts for the SSL: environment.
I"personate a c#ient a&ter authentication

This policy setting determines whether applications that run on behalf of an authenticated user can impersonate clients. 3f this user right is re=uired for this type of impersonation1 unauthori'ed users will not be able to convince a client to connectIfor e9ample1 by remote procedure call /K-C0 or named pipesIto a service that they created to impersonate that client. The unauthori'ed user could use this capability to elevate their permissions to administrative or system levels. The )mpersonate a client after aut'entication setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned only to the &dministrators group and S?K<3C? for the SSL: environment.
Increase schedu#in( priority

This policy setting determines whether users can increase the base priority class of a process. 3ncreasing relative priority within a priority class is not a privileged operation. This user right is not re=uired by administrative tools that are supplied with the operating system1 but it might be re=uired by software development tools. A user who is assigned this user right can increase the scheduling priority of a process to Keal%Time and leave little processing time for all other processes1 which could cause a DoS condition. The )ncrease sc'edulin" priority setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned only to the &dministrators group for the SSL: environment.
9oad and un#oad device drivers

This policy setting determines which users can dynamically load and unload device drivers. This user right is not re=uired if a signed driver for the new hardware already e9ists in the Driver.cab file on the computer. Device drivers run as highly privileged code. A user who is assigned the 2oad and unload device drivers user right can install
:0
malicious code that mas=uerades as a device driver /unintentionally or otherwise0. /Administrators should e9ercise greater care and install only drivers with verified digital signatures.0 The 2oad and unload device drivers setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned to only the &dministrators group for the SSL: environment.
9ock pa(es in "e"ory

This policy setting determines whether a process can keep data in physical memory1 which prevents the computer from paging the data to virtual memory on disk. Such an occurrence could significantly degrade performance. Jsers who are assigned this user right can assign physical memory to several processes and leave little or no random access memory /KAM0 for other processes1 which could lead to a DoS condition. The 2oc= pa"es in memory setting is configured to .ot defined for the LC and ?C environments. However1 for the SSL: environment this policy setting is configured to a null value or blank1 which means no security group or account will have this user right.
9o( on as a service
This policy setting determines whether a security principal can log on as a service. Services can be configured to run under the Local System1 Local Service1 or 8etwork Service accounts1 which have built%in rights to log on as a service. Any service that runs under a separate user account must be assigned this user right. The 2o" on as a service setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned only to the 8etwork Service account for the SSL: environment.
)ana(e auditin( and security #o(

This policy setting determines whether users can specify ob7ect access auditing options for individual resources such as files1 Active Directory ob7ects1 and registry keys. This user right is powerful and should be closely guarded. Anyone with this user right can clear the Security log and possibly erase important evidence of unauthori'ed activity. The Mana"e auditin" and security lo" setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned only to &dministrators in the SSL: environment.
I portant: Microsoft 61change Server 2003 modifies this user ri&ht in the 7efault 7omain Controller 8olic" durin& the installation process. ,or details# see 61change Server 2003 "ep$oy ent online at www.microsoft.com%technet%prodtechnol%e0chan&e%&uides%22k)A78erm% ..0e):bf-a6;c-(:bb-b(d'-.cfd')-d-cba.msp0. 6f this user ri&ht is restricted to the AdministratorQs &roup# 20chan&e will fre=uentl" record error messa&es to the Application event lo&. 6f "ou use 61change Server 2003 "ou will need to ad?ust the value of this settin& for the domain controllers. As with all of the settin&s that are recommended in this &uide# "ou ma" need to make some ad?ustments to allow "our or&ani>ationQs applications to function normall".
)odi&y &ir"ware environ"ent va#ues

This policy setting determines whether the computer;s environment variables can be modified1 either by a process through an A-3 or by a user through System %roperties. Anyone who is assigned this user right could configure the settings of a hardware component to cause it to fail1 which could lead to data corruption or a DoS condition.
:.
The Modify firmware environment values setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned to only the &dministrators group for the SSL: environment.
+er&or" vo#u"e "aintenance tasks

This policy setting determines whether a non%administrative or remote user can manage volumes or disks. A user who is assigned this user right could delete a volume and cause the loss of data or a DoS condition. The %erform volume maintenance tas=s setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned only to the &dministrators group for the SSL: environment.
+ro&i#e sin(#e process

This policy setting determines which users can use performance monitoring tools to monitor the performance of non%system processes. This user right presents a moderate vulnerability1 in that an attacker with this capability could monitor a computer s performance to help identify critical processes that they might want to attack directly. An attacker could also determine what processes run on the computer so that they could identify countermeasures to avoid1 such as antivirus software1 an intrusion detection system1 or other users logged onto a computer. The %rofile sin"le process setting is configured to .ot defined for the LC and ?C environments. :or greater security1 ensure that the %ower (sers group is not assigned this user right in the SSL: environmentV only members of the &dministrators group should have this capability in such an environment.
+ro&i#e syste" per&or"ance

This policy setting is similar to the previous setting. 3t determines whether users can monitor the performance of system processes. This user right presents a moderate vulnerability1 in that an attacker with this privilege could monitor a computer s performance to help identify critical processes that they might want to attack directly. An attacker could also determine what processes run on the computer to identify countermeasures to avoid1 such as antivirus software or an intrusion detection system. The %rofile system performance setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned to only the &dministrators group for the SSL: environment.
$e"ove co"puter &ro" dockin( station

This policy setting determines whether users of portable computers can click !,ect %C on the Start menu to undock the computers. Anyone who is assigned this user right can remove a portable computer from its docking station. The /emove computer from doc=in" station setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned to only the &dministrators group for the SSL: environment.
$ep#ace a process #eve# token

This policy setting determines whether a parent process can replace the access token that is associated with a child process.
:2
The /eplace a process level to=en setting is configured to .ot defined for the LC and ?C environments. However1 this user right is assigned to only the L$CAL S?K<3C? and 8?T!$KF S?K<3C? accounts for the SSL: environment.
$estore &i#es and directories

This policy setting determines which users can bypass file1 directory1 registry1 and other persistent ob7ects permissions when they restore backed up files and directories. 3t also determines which users can set any valid security principal as the owner of an ob7ect. The /estore files and directories setting is configured to .ot defined for the LC and ?C environments. However1 only the &dministrators group is assigned this user right for the SSL: environment. :ile restoration tasks are usually performed by administrators or members of another specifically delegated security group1 especially for highly sensitive servers and domain controllers.
Shut down the syste"

This policy setting determines which locally logged on users can shut down the operating system with the S'ut -own command. Cecause misuse of this capability could cause a DoS condition1 the ability to shut down domain controllers should be limited to a very small number of trusted administrators. ?ven though a system shutdown re=uires the ability to log on to the server1 you should be very careful about the accounts and groups that you allow to shut down a domain controller. The S'ut down t'e system setting is configured to .ot defined for the LC and ?C environments. However1 only the &dministrators group is assigned this user right for the SSL: environment.
Synchroni6e directory service data

This policy setting determines whether a process can read all ob7ects and properties in the directory1 regardless of the protection on the ob7ects and properties. This user right is re=uired to use LDA- directory synchroni'ation /Dirsync0 services. The default configuration of the Sync'roni1e directory service data setting is .ot defined1 which is sufficient for the LC and ?C environments. However1 for the SSL: environment this policy setting is configured to a null value or blank1 which means no security group or account will have this user right.
%ake ownership o& &i#es or other ob:ects

This policy setting determines whether users can take ownership of any securable ob7ect in the network1 including Active Directory ob7ects1 8T:S file system /8T:S0 files1 and folders1 printers1 registry keys1 services1 processes1 and threads. The Ta=e owners'ip of files or ot'er ob,ects setting is configured to .ot defined for the LC and ?C environments. However1 you should assign this user right only to the local &dministrators group for the SSL: environment.
Security Options
The policy settings in the Security $ptions section of Hroup -olicy are used to enable or disable capabilities and features such as floppy disk drive access1 CD%K$M drive access1 and logon prompts. These policy settings are also used to configure various other
:)
settings1 such as those for the digital signing of data1 administrator and guest account names1 and how driver installation works. Bou can configure the security options settings in !indows Server *++, with S-. at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\ 2ocal %olicies\Security +ptions 8ot all of the settings that are included in this section e9ist on all types of computers. Therefore1 the settings that comprise the Security $ptions portion of Hroup -olicy that are defined in this section may need to be manually modified on computers in which these settings are present to make them fully operable. The following sections provide information about the prescribed MSC- security options settings for all three environments that are defined in this guide. :or a summary of the prescribed settings1 see the Microsoft ?9cel workbook G!indows Server *++, Security Huide Settings1G which is included with the downloadable version of this guide. :or information about the default configuration and a detailed e9planation of each of the settings1 see the companion guide1 Threats and Countermeasures Security Settin!s in Windows Server 2003 and Windows XP. The tables in each of the following sections summari'e the recommended settings for the different types of security option settings. Detailed information about the settings is provided in the subsections that follow each table.
3ccounts Settin(s
Table B 12 Security +ptions> &ccounts Settin" /ecommendations Settin" Administrator account status Huest account status 2e"acy Client 8ot defined Disabled !nterprise Client 8ot defined Disabled ?nabled Speciali1ed Security 7 2imited 0unctionality ?nabled Disabled ?nabled
Limit local account use of ?nabled blank passwords to console logon only
&ccounts> &dministrator account status

This policy setting enables or disables the Administrator account during normal operation. !hen you start a computer in safe mode1 the Administrator account is always enabled1 regardless of this setting. The &ccounts> &dministrator account status setting is configured to .ot defined for the LC and ?C environments and to !nabled for the SSL: environment.
&ccounts> Guest account status

This policy setting determines whether the Huest account is enabled or disabled. This account allows unauthenticated network users to log on as Huest and gain access to the computer. The &ccounts> Guest account status setting is configured to -isabled in the baseline policy for all three environments that are defined in this guide.
:(
&ccounts> 2imit local account use of blan= passwords to console lo"on only
This policy setting determines whether local accounts that are not password protected can be used to log on from locations other than the physical computer console. 3f this policy setting is enabled1 local accounts with nonblank passwords will not be able to log on to the network from a remote client1 and local accounts that are not password protected will only be able to log on while physically located at the keyboard of the computer. The &ccounts> 2imit local account use of blan= passwords to console lo"on only setting is configured to the default value of !nabled in the baseline policy for all three of the environments that are defined in this guide.
3udit Settin(s
Table B 13 Security +ptions> &udit Settin" /ecommendations Settin" Audit the access of global system ob7ects Audit the use of Cackup and Kestore privilege Shut down system immediately if unable to log security audits 2e"acy Client Disabled Disabled Disabled !nterprise Client Disabled Disabled Disabled Speciali1ed Security 7 2imited 0unctionality Disabled Disabled ?nabled
&udit> &udit t'e access of "lobal system ob,ects

This policy setting audits the access of global system ob7ects when it is in effect. 3f both the &udit> &udit t'e access of "lobal system ob,ects and the &udit ob,ect access audit policy settings are enabled1 a large number of audit events will be generated. The &udit> &udit t'e access of "lobal system ob,ects setting is configured to the default value of -isabled in the baseline policy for all three environments that are defined in this guide.
3ote$ Chan&es to the confi&uration of this polic" settin& will not take effect until "ou restart 3indows +erver 200).
&udit> &udit t'e use of #ac=up and /estore privile"e

This policy setting determines whether to audit the use of all user privileges1 including Cackup and Kestore1 when the &udit privile"e use policy setting is in effect. 3f you enable this policy setting1 a large number of security events could be generated1 which would cause servers to respond slowly and the Security log to record numerous events of little significance. Therefore1 the &udit> &udit t'e use of #ac=up and /estore privile"e setting is configured to the default value of -isabled in the baseline policy for all three environments that are defined in this guide.
3ote$ Chan&es to the confi&uration of this polic" settin& will not take effect until "ou restart 3indows +erver 200).
:'
&udit> S'ut down system immediately if unable to lo" security audits

This policy setting determines whether the computer shuts down immediately if it is unable to log security events. The amount of administrative overhead that was re=uired to enable the &udit> S'ut down system immediately if unable to lo" security audits setting in the LC and ?C environments was determined to be too great. Therefore1 this policy setting is configured to -isabled in the baseline policy for those environments. However1 this policy setting is configured to !nabled in the baseline policy for the SSL: environment because the additional administrative overhead was deemed acceptable to prevent the deletion of events from the Security log unless an administrator specifically chooses to do so.
*evices Settin(s
Table B 1B Security +ptions> -evices Settin" /ecommendations Settin" Allow undock without having to log on Allowed to format and e7ect removable media -revent users from installing printer drivers 2e"acy Client Disabled Administrators ?nabled !nterprise Client Disabled Administrators ?nabled 8ot defined Speciali1ed Security 7 2imited 0unctionality Disabled Administrators ?nabled Disabled
Kestrict CD%K$M access 8ot defined to locally logged%on user only Kestrict floppy access to locally logged%on user only Jnsigned driver installation behavior 8ot defined
8ot defined
Disabled
!arn but allow installation
-evices> &llow undoc= wit'out 'avin" to lo" on

This policy setting determines whether a portable computer can be undocked without the user having to log on to the computer. Bou can enable this policy setting to eliminate a logon re=uirement and allow use of an e9ternal hardware e7ect button to undock the computer. 3f you disable this policy setting1 a user who is not logged on must be assigned the /emove computer from doc=in" station user right. The -evices> &llow undoc= wit'out 'avin" to lo" on setting is configured to -isabled in the baseline policy for all three environments that are defined in this guide.
-evices> &llowed to format and e,ect removable media

This policy setting determines who can format and e7ect removable media. $nly administrators should be able to e7ect removable media on servers.
:6
Therefore1 the recommended value for the -evices> &llowed to format and e,ect removable media setting is the default value of &dministrators in the baseline policy for all three environments that are defined in this guide.
-evices> %revent users from installin" printer drivers

:or a computer to print to a network printer1 it must have the driver for that network printer installed. 3f you enable the -evices> %revent users from installin" printer drivers setting1 only those in the &dministrators or %ower (sers groups or those with Server $perator privileges are allowed to install a printer driver to add a network printer. 3f you disable this policy setting1 any user can install a printer driver. The -evices> %revent users from installin" printer drivers setting is configured to the default value of !nabled in the baseline policy for all three environments that are defined in this guide.
-evices> /estrict C-*/+M access to locally lo""ed*on user only

This policy setting determines whether a CD%K$M is accessible to both local and remote users simultaneously. 3f you enable this policy setting1 only the interactively logged%on user is allowed to access removable CD%K$M media. !hen this policy setting is enabled and no one is logged on interactively1 the CD%K$M is accessible over the network. The -evices> /estrict C-*/+M access to locally lo""ed*on user only setting is configured to .ot defined in the baseline policy for the LC and ?C environments. 3n the baseline policy for the SSL: environment1 this policy setting is configured to -isabled.
-evices> /estrict floppy access to locally lo""ed*on user only

This policy setting determines whether removable floppy media are accessible to both local and remote users simultaneously. 3f you enable this policy setting1 only the interactively logged%on user is allowed to access removable floppy media. 3f this policy setting is enabled and no one is logged on interactively1 the floppy media is accessible over the network. The -evices> /estrict floppy access to locally lo""ed*on user only setting is configured to .ot defined in the baseline policy for the LC and ?C environments. 3n the baseline policy for the SSL: environment1 this policy setting is configured to -isabled.
-evices> (nsi"ned driver installation be'avior

This policy setting determines what happens when an attempt is made to install a device driver /by means of Setup A-30 that has not been approved and signed by the !indows Hardware Xuality Lab /!HXL0. Depending on how you configure it1 this policy setting will prevent the installation of unsigned drivers or warn the administrator that an unsigned driver is about to be installed. The -evices> (nsi"ned driver installation be'avior setting can be used to prevent the installation of drivers that have not been certified to run on !indows Server *++, with S-.. However1 this policy setting is configured to Warn but allow installation in the baseline policy for all three environments that are defined in this guide. $ne potential problem with this configuration is that unattended installation scripts will fail when they attempt to install unsigned drivers.
::
*o"ain )e"ber Settin(s

Table B 1< Security +ptions> -omain Member Settin" /ecommendations Settin" Digitally encrypt or sign secure channel data /always0 Digitally encrypt secure channel data /when possible0 Digitally sign secure channel data /when possible0 Disable machine account password changes Ma9imum machine account password age Ke=uire strong /!indows *+++1 !indows 2-1 or !indows Server *++,0 session key 2e"acy Client Disabled ?nabled ?nabled Disabled ,+ days ?nabled !nterprise Speciali1ed Security 7 Client 2imited 0unctionality ?nabled ?nabled ?nabled Disabled ,+ days ?nabled ?nabled ?nabled ?nabled Disabled ,+ days ?nabled
-omain member> -i"itally encrypt or si"n secure c'annel data @alwaysA

This policy setting determines whether all secure channel traffic that is initiated by the domain member must be signed or encrypted. 3f a computer is set to always encrypt or sign secure channel data1 then it cannot establish a secure channel with a domain controller that cannot sign or encrypt all secure channel traffic. The -omain member> -i"itally encrypt or si"n secure c'annel data @alwaysA setting is configured to -isabled in the baseline policy for the LC environment and to !nabled for the ?C and SSL: environments.
3ote$ To take advanta&e of this settin& on member workstations and servers# all domain controllers that constitute the memberQs domain must run 3indows T (.0 with +ervice 8ack 6a or la more recent version of 3indows. Also# this polic" settin& is not supported in 3indows -; +econd 2dition clients unless the" have the 7sclient installed.
-omain member> -i"itally encrypt secure c'annel data @w'en possibleA

This policy setting determines whether a domain member may attempt to negotiate encryption for all secure channel traffic that it initiates. 3f you enable this policy setting1 the domain member will re=uest encryption of all secure channel traffic. 3f you disable this policy setting1 the domain member will not be allowed to negotiate secure channel encryption. Therefore1 the -omain member> -i"itally encrypt secure c'annel data @w'en possibleA setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
:;
-omain member> -i"itally si"n secure c'annel data @w'en possibleA

This policy setting determines whether a domain member may attempt to negotiate a signature for all secure channel traffic that it initiates. Ke=uirement of a signature protects the traffic from modification by anyone who might capture the data. The -omain member> -i"itally si"n secure c'annel data @w'en possibleA setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
-omain member> -isable mac'ine account password c'an"es

This policy setting determines whether a domain member may periodically change its computer account password. 3f you enable this policy setting1 the domain member will not be able to change its computer account password. 3f you disable this policy setting1 the domain member will be able to change its computer account password as specified by the -omain Member> Ma3imum mac'ine account password a"e setting1 which is every ,+ days by default. Computers that are no longer able to automatically change their account passwords are at risk of attack by someone who has determined the password for the computer s domain account. Therefore1 the -omain member> -isable mac'ine account password c'an"es setting is configured to -isabled in the baseline policy for all three environments that are defined in this guide.
-omain member> Ma3imum mac'ine account password a"e

This policy setting determines the ma9imum allowable age for a computer account password. 3t also applies to computers that run !indows *+++1 but is not available through the Security Configuration Manager tools on these computers. Cy default1 the domain members automatically change their domain passwords every ,+ days. 3f this interval is increased significantly1 or if it is set to + so that the computers no longer change their passwords1 an attacker will have more time to undertake a brute force attack and guess the password of one or more computer accounts. Therefore1 the -omain member> Ma3imum mac'ine account password a"e setting is configured to 30 days in the baseline policy for all three environments that are defined in this guide.
-omain member> /e8uire stron" @Windows 2000 or laterA session =ey

This policy setting determines whether .*>%bit key strength is re=uired for encrypted secure channel data. 3f you enable this policy setting1 a secure channel will not be able to be established without .*>%bit encryption. 3f you disable this policy setting1 the domain member is re=uired to negotiate key strength with the domain controller. Session keys that are used to establish secure channel communications between domain controllers and member computers are much stronger in !indows *+++ than they were in previous Microsoft operating systems. Therefore1 because the three security environments described in this guide contain !indows *+++ domain controllers or later1 the -omain member> /e8uire stron"
:-
@Windows 2000 or laterA session =ey setting is configured to !nabled in the baseline policy for all three environments.
3ote$ 6f "ou enable this polic" settin& "ou will not be able to ?oin computers that run 3indows 2000 to 3indows T (.0 domains.
Interactive 9o(on Settin(s

Table B 1D Security +ptions> )nteractive 2o"on Settin" /ecommendations Settin" Display user information when the session is locked Do not display last user name Do not re=uire CTKLWALTWD?L Message te9t for users attempting to log on Message title for users attempting to log on 8umber of previous logons to cache /in case domain controller is not available0 -rompt user to change password before e9piration Ke=uire Domain Controller authentication to unlock workstation Ke=uire smart card Smart card removal behavior 2e"acy Client 8ot defined !nterprise Client 8ot defined Speciali1ed Security 7 2imited 0unctionality Jser display name1 domain and user names ?nabled Disabled /Consult with the relevant people in your organi'ation.0 /Consult with the relevant people in your organi'ation.0 +
?nabled Disabled
?nabled Disabled
/Consult with the /Consult with the relevant people in relevant people in your organi'ation.0 your organi'ation.0 /Consult with the /Consult with the relevant people in relevant people in your organi'ation.0 your organi'ation.0 . +
.E days
.E days
.E days
?nabled
?nabled
?nabled
8ot defined Lock !orkstation
Disabled Lock !orkstation
)nteractive lo"on> -isplay user information w'en t'e session is loc=ed

This policy setting determines whether the account name of the last user to log on to the client computers in your organi'ation will display in each computer s respective !indows logon screen. 3f you enable this policy setting1 intruders will not be able to collect account names visually from the screens of desktop or laptop computers in your organi'ation.
;0
The )nteractive lo"on> -isplay user information w'en t'e session is loc=ed setting is configured to .ot defined for the LC and ?C environments. 3t is configured to (ser display nameC domain and user names in the baseline server policy for the SSL: environment.
)nteractive lo"on> -o not display last user name

This policy setting determines whether the name of the last user to log on to the computer is displayed in the !indows logon screen. 3f you enable this policy setting1 the last logged on user s name will not display in the 2o" +n to Windows dialog bo9. The )nteractive lo"on> -o not display last user name setting is configured to !nabled in the baseline server policy for all three environments that are defined in this guide.
)nteractive lo"on> -o not re8uire CT/2G&2TG-!2

This policy setting determines whether a user must press CTKLWALTWD?L before they can log on. 3f you disable this policy setting1 all users will be re=uired to press CTKLWALTWD?L before they log on to !indows /unless they use a smart card for !indows logon0. The )nteractive lo"on> -o not re8uire CT/2G&2TG-!2 setting is configured to -isabled in the baseline policy for all three environments that are defined in this guide to decrease the chance of an attacker being able to intercept user passwords by means of a Tro7an horse program.
)nteractive lo"on> Messa"e te3t for users attemptin" to lo" on

This policy setting specifies a te9t message that displays to users when they log on. Typically1 this te9t is used for legal reasonsIfor e9ample1 to warn users about the ramifications of unauthori'ed access1 misuse of company information1 or that their actions may be audited. The )nteractive lo"on> Messa"e te3t for users attemptin" to lo" on security option setting is recommended. Bou should consult with the relevant people in your organi'ation to determine what this te9t should say.
3ote$ 9oth the Interactive $ogon: Message te1t *or users atte pting to $og on and the Interactive $ogon: Message tit$e *or users atte pting to $og on settin&s must be enabled for either one to work properl".
)nteractive lo"on> Messa"e title for users attemptin" to lo" on

This policy setting allows a title to be specified in the title bar of the interactive logon dialog bo9 that displays when users log on to the computer. The reason for this policy setting is the same as that for the Messa"e te3t for user attemptin" to lo" on setting. Therefore1 the )nteractive lo"on> Messa"e title for users attemptin" to lo" on setting is recommended. Bou should consult with the relevant people in your organi'ation to determine what this te9t should say
3ote$ 9oth the Interactive $ogon: Message te1t *or users atte pting to $og on and Interactive $ogon: Message tit$e *or users atte pting to $og on settin&s must be enabled for either one to work properl".
;.
)nteractive lo"on> .umber of previous lo"ons to cac'e @in case domain controller is not availableA
This policy setting determines whether a user can log on to a !indows domain with cached account information. Logon information for domain accounts can be cached locally so that if a domain controller cannot be contacted on subse=uent logons1 a user can still log on. This capability may allow users to log on after their account has been disabled or deleted1 because the workstation does not contact the domain controller. This policy setting determines the number of uni=ue users for whom logon information is cached locally. 3f you configure this setting to +1 the logon cache is disabled. The )nteractive lo"on> .umber of previous lo"ons to cac'e @in case domain controller is not availableA setting is configured to 0 in the baseline policy for the ?C and SSL: environments. 3n the LC environment1 the setting is configured to 1 to allow access for legitimate clients when they are unable to contact the domain controller.
)nteractive lo"on> %rompt user to c'an"e password before e3piration

This policy setting determines how many days in advance users are warned that their passwords are about to e9pire. The SAccount -oliciesT section in Chapter , recommends that user passwords be configured to e9pire periodically. 3f users are not notified when their passwords are about to e9pire1 they may not reali'e it until the passwords have already e9pired1 which could cause confusion for local users who find it difficult to change their passwords. Jne9pected e9pirations also make it impossible for remote users to log on through dial%up or virtual private networking /<-80 connections. Therefore1 the )nteractive lo"on> %rompt user to c'an"e password before e3piration setting is configured to the default setting of .E days in the baseline policy for all three environments that are defined in this guide.
)nteractive lo"on> /e8uire -omain Controller aut'entication to unloc= wor=station

:or domain accounts1 this policy setting determines whether a domain controller must be contacted to unlock a computer. This policy setting addresses a potential vulnerability that is similar to one for the )nteractive lo"on> .umber of previous lo"ons to cac'e @in case domain controller is not availableA setting. A user could disconnect the network cable of the server1 unlock the server with an old password1 and unlock the server without authentication. To prevent such an occurrence1 the )nteractive lo"on> /e8uire -omain Controller aut'entication to unloc= wor=station setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
I portant$ This polic" settin& applies to computers that run 3indows 2000# 3indows F8# and 3indows +erver 200)# but it is not available throu&h the +ecurit" Confi&uration Mana&er tools on computers that run 3indows 2000.
)nteractive lo"on> /e8uire smart card

This policy setting re=uires users to log on to a computer with a smart card. Security is enhanced when users are re=uired to use long1 comple9 passwords for authentication1 especially if they are re=uired to change their passwords regularly. This approach reduces the chance that an attacker will be able to guess a user;s password by means of a brute force attack. However1 it is difficult to make users choose strong passwords1 and even strong passwords are still vulnerable to brute%force attacks.
;2
The use of smart cards instead of passwords for authentication dramatically increases security1 because current technology makes it almost impossible for an attacker to impersonate another user. Smart cards that re=uire personal identification numbers /-38s0 provide two%factor authentication" the user must possess the smart card and know its -38. An attacker who captures the authentication traffic between the user;s computer and the domain controller will find it e9tremely difficult to decrypt the traffic. ?ven if they can decrypt the traffic1 the ne9t time the user logs onto the network a new session key will be generated to encrypt traffic between the user and the domain controller. Microsoft encourages organi'ations to migrate to smart cards or other strong authentication technologies. However1 you should only enable the )nteractive lo"on> /e8uire smart card setting if smart cards are already deployed. :or this reason1 this policy setting is configured to .ot defined in the baseline policy for the LC and ?C environments. This policy setting is configured to -isabled in the baseline policy for the SSL: environment.
)nteractive lo"on> Smart card removal be'avior

This policy setting determines what happens when the smart card for a logged%on user is removed from the smart card reader. 3f you configure this setting to 2oc= Wor=station1 the workstation is locked when the smart card is removed1 which allows users to leave the area and take their smart cards with them. 3f you configure this setting to 0orce 2o"off1 the user is automatically logged off when the smart card is removed. The )nteractive lo"on> Smart card removal be'avior setting is configured to .ot defined in the baseline policy for the LC environment and to 2oc= Wor=station for the ?C and SSL: environments.
)icroso&t ;etwork C#ient Settin(s

Table B 1E Security +ptions> Microsoft .etwor= Client Settin" /ecommendations Settin" Digitally sign communications /always0 Digitally sign communications /if server agrees0 2e"acy Client Disabled ?nabled !nterprise Client ?nabled ?nabled Speciali1ed Security 7 2imited 0unctionality ?nabled ?nabled
Send unencrypted password Disabled to third%party SMC servers
Disabled
Disabled
Microsoft networ= client> -i"itally si"n communications @alwaysA

This policy setting determines whether packet signing is re=uired by the SMC client component. 3f you enable this setting1 Microsoft network clients will not be able to communicate with a Microsoft network server unless that server agrees to perform SMC packet signing. 3n mi9ed environments with legacy clients you should set this option to -isabled1 because these clients will not be able to authenticate or gain access to domain controllers. However1 you can use this setting in environments that run !indows *+++1 !indows 2-1 and !indows Server *++,. The ?C and SSL: environments that are defined in this guide only contain computers that run these operating systems1 all of which support digital signatures.
;)
Therefore1 to increase communications security between computers in this environment1 the Microsoft networ= client> -i"itally si"n communications @alwaysA setting is configured to !nabled in the baseline policy for the ?C and SSL: environments.
Microsoft networ= client> -i"itally si"n communications @if server a"reesA

This policy setting determines whether the SMC client will attempt to negotiate SMC packet signatures. The implementation of digital signatures in !indows networks helps to prevent sessions from being hi7acked. 3f you enable this policy setting1 the Microsoft network clients on member servers will re=uest signatures only if the servers with which they communicate accept digitally signed communication. The Microsoft networ= client> -i"itally si"n communications @if server a"reesA setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
Microsoft networ= client> Send unencrypted password to t'ird*party SM# servers

3f you enable this policy setting1 the SMC redirector is allowed to send plainte9t passwords to non%Microsoft SMC servers that do not support password encryption during authentication. The Microsoft networ= client> Send unencrypted password to t'ird*party SM# servers setting is configured to the default value of -isabled in the baseline policy for the three environments that are defined in this guide1 unless application re=uirements supersede the need to maintain secret passwords.
)icroso&t ;etwork Server Settin(s

Table B 1F Security +ptions> Microsoft .etwor= Server Settin" /ecommendations Settin" Amount of idle time re=uired before suspending session Digitally sign communications /always0 Digitally sign communications /if client agrees0 Disconnect clients when logon hours e9pire 2e"acy Client .5 minutes Disabled ?nabled ?nabled !nterprise Client .5 minutes ?nabled ?nabled ?nabled Speciali1ed Security 7 2imited 0unctionality .5 minutes ?nabled ?nabled ?nabled
Microsoft networ= server> &mount of idle time re8uired before suspendin" session
This policy setting determines the amount of continuous idle time that must pass in an SMC session before the session is suspended because of inactivity. Administrators can use this policy setting to control when a computer suspends an inactive SMC session. 3f client activity resumes1 the session is automatically reestablished.
;(
The Microsoft networ= server> &mount of idle time re8uired before suspendin" session setting is configured to 1< minutes in the baseline policy for all three environments that are defined in this guide.
Microsoft networ= server> -i"itally si"n communications @alwaysA

This policy setting determines whether packet signing is re=uired by the SMC server component before further communication with an SMC client is permitted. !indows *+++ Server1 !indows *+++ -rofessional1 !indows Server *++,1 and !indows 2- -rofessional include versions of SMC that support mutual authentication1 which prevents attempts to hi7ack sessions and supports message authentication to prevent man%in%the%middle attacks. SMC signing provides this authentication because it places a digital signature into each SMC packet1 which is then verified by both the client and the server. !hen computers are configured to ignore all unsigned SMC communications1 legacy applications and operating systems will be unable to connect. 3f all SMC signing is completely disabled1 computers are vulnerable to attacks that attempt to hi7ack their communications sessions. The Microsoft networ= server> -i"itally si"n communications @alwaysA setting is configured to -isabled in the baseline policy for the LC and environment and to !nabled for the ?C and SSL: environments.
Microsoft networ= server> -i"itally si"n communications @if client a"reesA

This policy setting determines whether the SMC server will negotiate SMC packet signing with clients that re=uest it. !indows *+++ Server1 !indows *+++ -rofessional1 !indows Server *++,1 and !indows 2- -rofessional include versions of SMC that support mutual authentication1 which blocks attempts to hi7ack sessions and supports message authentication to prevent man%in%the%middle attacks. SMC signing provides this authentication because it places a digital signature into each SMC packet1 which is then verified by both the client and the server. !hen computers are configured to ignore all unsigned SMC communications1 legacy applications and operating systems will be unable to connect. 3f all SMC signing is completely disabled1 computers are vulnerable to attacks that attempt to hi7ack their communications sessions. The Microsoft networ= server> -i"itally si"n communications @if client a"reesA setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
Microsoft networ= server> -isconnect clients w'en lo"on 'ours e3pire

This policy setting determines whether to disconnect users who are connected to a network computer outside of their user account s valid logon hours. This policy setting affects the SMC component. 3f your organi'ation has configured logon hours for users1 then it makes sense to enable this policy setting. $therwise1 users should not be able to access network resources outside of their logon hours or they may be able to continue to use those resources with sessions that were established during allowed hours. The Microsoft networ= server> -isconnect clients w'en lo"on 'ours e3pire setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
;'
;etwork 3ccess Settin(s

Table B 1: Security +ptions> .etwor= &ccess Settin" /ecommendations Settin" Allow anonymous S3D#8AM? translation Do not allow anonymous enumeration of SAM accounts Do not allow anonymous enumeration of SAM accounts and shares 2e"acy Client 8ot defined !nterprise Client 8ot defined Speciali1ed Security 7 2imited 0unctionality Disabled
?nabled
?nabled
?nabled
?nabled
?nabled
?nabled
Do not allow ?nabled storage of credentials or .8?T -assports for network authentication Let ?veryone permissions apply to anonymous users 8amed -ipes that can be accessed anonymously Disabled
?nabled
?nabled
Disabled
Disabled
8ot defined
8ot defined
C$M8A-1 C$M8$D?1 SXLZXJ?KB1 S-$$LSS1 LLSK-C1 netlogon1 lsarpc1 samr1 browser SystemZ CurrentControlSetZ ControlZ -roduct $ptionsV SystemZ CurrentControlSetZ ControlZ Server ApplicationsV SoftwareZMicrosoftZ
Kemotely accessible registry paths
SystemZ CurrentControlSetZ ControlZ -roduct $ptionsV SystemZ CurrentControlSetZ ControlZ Server ApplicationsV
SystemZ CurrentControlSetZ ControlZ -roduct $ptionsV SystemZ CurrentControlSetZ ControlZ Server ApplicationsV
SoftwareZMicrosoftZ SoftwareZMicrosoftZ !indows 8TZ Current<ersion !indows 8TZ Current <ersion
!indows 8TZCurrent <ersion
;6
Settin" Kemotely accessible registry paths and sub% paths
2e"acy Client
!nterprise Client
Speciali1ed Security 7 2imited 0unctionality
/see the following /see the following /see the following subsection for subsection for subsection for setting setting information0 setting information0 information0 ?nabled ?nabled
Kestrict ?nabled anonymous access to 8amed -ipes and Shares Shares that can be accessed anonymously Sharing and security model for local accounts 8ot defined
8ot defined
8one
ClassicIlocal users authenticate as themselves
.etwor= access> &llow anonymous S)-5name translation

This policy setting determines whether an anonymous user can re=uest S3D attributes for another user. 3f this policy setting is enabled1 a user with local access could use the well% known Administrators S3D to obtain the real name of the built%in Administrator account1 even if the account has been renamed. That person could then use the account to initiate a password guessing attack. The .etwor= access> &llow anonymous S)-5.ame translation setting is configured to .ot defined in the baseline policy for the LC and ?C environments. This policy setting is configured to -isabled in the baseline policy for the SSL: environment.
.etwor= access> -o not allow anonymous enumeration of S&M accounts

This policy setting determines what additional permissions will be granted for anonymous connections to the computer. !indows allows anonymous users to perform certain activities1 such as enumerate the names of domain accounts. This capability is convenient1 for e9ample1 when an administrator wants to grant access to users in a trusted domain that does not maintain a reciprocal trust. However1 even if this setting is enabled1 anonymous users will still have access to any resources that have permissions that e9plicitly include the special built%in group &.+.HM+(S 2+G+. The .etwor= access> -o not allow anonymous enumeration of S&M accounts setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
.etwor= access> -o not allow anonymous enumeration of S&M accounts and s'ares
This policy setting determines whether anonymous enumeration of SAM accounts and shares is allowed. The .etwor= access> -o not allow anonymous enumeration of S&M accounts and s'ares setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
;:
.etwor= access> -o not allow stora"e of credentials or .!T %assports for networ= aut'entication
This policy setting determines whether settings for Stored (ser .ames and %asswords will save passwords1 credentials1 or Microsoft .8?T -assports for later use after domain authentication is achieved. The .etwor= access> -o not allow stora"e of credentials or .!T %assports for networ= aut'entication setting is configured to !nabled in the baseline policy for all three security environments that are defined in this guide.
3ote$ Chan&es that are made to the confi&uration of this polic" settin& will not take effect until "ou restart 3indows.
.etwor= access> 2et !veryone permissions apply to anonymous users

This policy setting determines what additional permissions are granted for anonymous connections to the computer. 3f you enable this policy setting1 anonymous !indows users will be able to perform certain activities1 such as enumerate the names of domain accounts and network shares. An unauthori'ed user could anonymously list account names and shared resources and use the information to guess passwords or perform social engineering attacks. Therefore1 the .etwor= access> 2et !veryone permissions apply to anonymous users setting is configured to -isabled in the baseline policy for all three environments that are defined in this guide.
3ote$ 7omains that have this polic" settin& enabled will be unable to establish or maintain trusts with 3indows T (.0 domains or domain controllers.
.etwor= access> .amed %ipes t'at can be accessed anonymously

This policy setting determines which communication sessions /named pipes0 will have attributes and permissions that allow anonymous access. Bou should enforce the default values for the .etwor= access> .amed %ipes t'at can be accessed anonymously setting in the SSL: environment. The default values consist of the following named pipes" C$M8A- @ S8A session access C$M8$D? @ S8A session access SXLZXJ?KB @ SXL instance access S-$$LSS @ Spooler service LLSK-C @ License Logging service 8etlogon @ 8et Logon service Lsarpc @ LSA access
;;
Samr @ SAM access browser @ Computer Crowser service
I portant$ 6f "ou need to enable this polic" settin&# ensure that "ou onl" add the named pipes that are needed to support the applications in "our environment. As with all recommended settin&s in this &uide# "ou should carefull" test this polic" settin& before "ou deplo" it in a production environment.
.etwor= access> /emotely accessible re"istry pat's

This policy setting determines which registry paths can be accessed over the network. The .etwor= access> /emotely accessible re"istry pat's setting is configured to its default value in the baseline security templates for all three security environments that are defined in this guide.
3ote$ 2ven if "ou confi&ure this polic" settin&# "ou must also start the 4emote 4e&istr" s"stem service if authori>ed users need to be able to access the re&istr" over the network.
.etwor= access> /emotely accessible re"istry pat's and sub*pat's

This policy setting determines which registry paths and sub%paths can be accessed over the network. The default values for the .etwor= access> /emotely accessible re"istry pat's and sub*pat's setting are enforced in the baseline security templates for all three security environments that are defined in this guide. The default values consist of the following paths and sub%paths" SystemZCurrentControlSetZControlZ-rintZ-rinters SystemZCurrentControlSetZServicesZ?ventlog SoftwareZMicrosoftZ$LA- Server SoftwareZMicrosoftZ!indows 8TZCurrent<ersionZ-rint SoftwareZMicrosoftZ!indows 8TZCurrent<ersionZ!indows SystemZCurrentControlSetZControlZContent3nde9 SystemZCurrentControlSetZControlZTerminal Server SystemZCurrentControlSetZControlZTerminal ServerZJserConfig SystemZCurrentControlSetZControlZTerminal ServerZDefaultJserConfiguration SoftwareZMicrosoftZ!indows 8TZCurrent<ersionZ-erflib SystemZCurrentControlSetZServicesZSysmonLog
.etwor= access> /estrict anonymous access to .amed %ipes and S'ares

This policy setting can be used to restrict anonymous access to shares and named pipes in the following settings" .etwor= access> .amed pipes t'at can be accessed anonymously .etwor= access> S'ares t'at can be accessed anonymously
;-
The .etwor= access> /estrict anonymous access to .amed %ipes and S'ares setting is configured to the default setting of !nabled in the baseline policy for all three environments that are defined in this guide.
.etwor= access> S'ares t'at can be accessed anonymously

This policy setting determines which network shares can be accessed by anonymous users. The default configuration for this setting has little impact1 because all users must be authenticated before they can access shared resources on the server. The .etwor= access> S'ares t'at can be accessed anonymously setting is configured to .ot defined for the LC and ?C environments and to .one for the SSL: environment.
3ote$ This polic" settin& can be ver" dan&erous# because an" shares that are listed can be accessed b" an" network user. +ensitive data could be e0posed or corrupted if this polic" settin& is enabled.
.etwor= access> S'arin" and security model for local accounts

This policy setting determines how network logons that use local accounts are authenticated. The Classic configuration allows fine control over access to resources1 and allows you to provide different types of access to different users for the same resource. The Guest only setting allows you to treat all users e=ually. 3n this conte9t1 all users authenticate as Guest only to receive the same access level to a given resource. The .etwor= access> S'arin" and security model for local accounts setting is configured to the default configuration of Classic in the baseline policy for all three environments that are defined in this guide.
;etwork Security Settin(s

Table B 20 Security +ptions> .etwor= Security Settin" /ecommendations Settin" Do not store LA8 Manager hash value on ne9t password change LA8 Manager authentication level 2e"acy Client ?nabled Send 8TLMv* responses only 8egotiate signing !nterprise Client ?nabled Send 8TLMv* response onlyZrefuse LM 8egotiate signing Speciali1ed Security 7 2imited 0unctionality ?nabled Send 8TLMv* response onlyZrefuse LM O 8TLM
LDA- client signing re=uirements
8egotiate signing
-0
Settin" Minimum session security for 8TLM SS- based /including secure K-C0 clients Minimum session security for 8TLM SS- based /including secure K-C0 servers
2e"acy Client 8o minimum 8o minimum
!nterprise Client ?nabled all settings ?nabled all settings
Speciali1ed Security 7 2imited 0unctionality ?nabled all settings
?nabled all settings
.etwor= security> -o not store 2&. Mana"er 'as' value on ne3t password c'an"e
This policy setting determines whether the LA8 Manager /LM0 hash value for the new password is stored when the password is changed. The LM hash is relatively weak and prone to attack compared to the cryptographically stronger !indows 8T hash. :or this reason1 the .etwor= security> -o not store 2&. Mana"er 'as' value on ne3t password c'an"e setting is configured to !nabled in the baseline policy for all three security environments that are defined in this guide.
3ote$ Cer" old le&ac" operatin& s"stems and some applications ma" fail when this polic" settin& is enabled. Also# "ou will need to chan&e the password on all accounts after this polic" settin& is enabled.
.etwor= security> 2&. Mana"er aut'entication level

This policy setting determines which challenge#response authentication protocol is used for network logons. This choice affects the level of authentication protocol that is used by client computers1 the level of security that is negotiated1 and the level of authentication that is accepted by servers as follows. The numbers in the following table are the actual settings for the 2MCompatibility2evel registry value. Table B 21 2MCompatibility2evel /e"istry 6alue Settin"s 6alue %rotocol + . * , E 5 Clients use LA8 Manager and 8TLM authentication and never use 8TLMv* session security. Clients use LA8 Manager and 8TLM authentication and 8TLMv* session security if the server supports it. Clients use only 8TLM authentication and 8TLMv* session security if the server supports it. Clients use only 8TLMv* authentication and 8TLMv* session security if the server supports it. Clients use only 8TLM authentication and 8TLMv* session security if the server supports it. The domain controller refuses LA8 Manager authentication. Clients use only 8TLMv* authentication and 8TLMv* session security if the server supports it. The domain controller refuses LA8 Manager and 8TLM authentication and accepts only 8TLMv*.
-.
Bou should configure this policy setting to the highest level that your environment allows according to the following guidelines" 3n an environment that includes only !indows 8T E.+ S-E1 !indows *+++1 and !indows 2- -rofessional1 configure this policy setting to Send .T2Mv2 response only\refuse 2M I .T2M on all clients1 and then to Send .T2Mv2 response only\refuse 2M I .T2M on all servers after all clients are configured. The e9ception to this recommendation is !indows Server *++, Kouting and Kemote Access servers1 which will not function properly if this policy setting is configured higher than Send .T2Mv2 response only\refuse 2M. The ?C environment may need to support Kouting and Kemote Access servers1 therefore the .etwor= security> 2&. Mana"er aut'entication level setting for this environment is configured to Send .T2Mv2 response only\refuse 2M in the baseline policy. Kouting and Kemote Access servers are not supported in the SSL: environment1 so the policy setting for this environment is configured to Send .T2Mv2 response only\refuse 2M I .T2M. 3f you have !indows 69 clients on which you can install the DSClient1 configure this policy setting to Send .T2Mv2 response only\refuse 2M I .T2M on computers that run !indows 8T /!indows 8T1 !indows *+++1 and !indows 2- -rofessional0. $therwise1 you must leave this policy setting configured to no higher than Send .T2Mv2 responses only in the baseline policy for computers that do not run !indows 691 which is how the setting is configured for the LC environment. 3f you find applications that break when this policy setting is enabled1 roll it back one step at a time to discover what breaks. At a minimum1 you should configure this policy setting to Send 2M I .T2M 7 use .T2Mv2 session security if ne"otiated in the baseline policy on all computers. Typically1 you can configure it to Send .T2Mv2 responses only on all computers in the environment.
.etwor= security> 2-&% client si"nin" re8uirements

This policy setting determines the level of data signing that is re=uested on behalf of clients that issue LDA- C38D re=uests. Jnsigned network traffic is susceptible to man%in% the%middle attacks. :or an LDA- server1 an attacker could cause a server to make decisions that are based on false =ueries from the LDA- client. Therefore1 the .etwor= security> 2-&% client si"nin" re8uirements setting is configured to .e"otiate si"nin" in the baseline policy for all three environments that are defined in this guide.
.etwor= security> Minimum session security for .T2M SS% based @includin" secure /%CA clients
This policy setting allows a client to re=uire the negotiation of message confidentiality /encryption01 message signing1 .*>%bit encryption1 or 8TLM version * /8TLMv*0 session security. Configure this policy setting to as high a security level as possible1 but remember that you still need to allow the applications on the network to function. -roper configuration of this policy setting will help ensure that network traffic from 8TLM SS-@ based servers is protected from man%in%the%middle attacks and data e9posure. The .etwor= security> Minimum session security for .T2M SS% based @includin" secure /%CA clients setting is configured to .o minimum in the baseline policy for the LC environment. All settings are enabled for the ?C and SSL: environments.
-2
.etwor= security> Minimum session security for .T2M SS% based @includin" secure /%CA servers
This policy setting allows a server to re=uire the negotiation of message confidentiality /encryption01 message integrity1 .*>%bit encryption1 or 8TLMv* session security. Configure this policy setting to as high a security level as possible1 but remember that you still need to allow the applications on the network to function. Like the previous policy setting1 proper configuration of this policy setting will help ensure that network traffic from 8TLM SS-@based clients is protected from man%in%the%middle attacks and data e9posure. The .etwor= security> Minimum session security for .T2M SS% based @includin" secure /%CA servers security option setting is configured to .o minimum in the baseline policy for the LC environment. All settings are enabled for the ?C and SSL: environments.
$ecovery Conso#e Settin(s

Table B 22 Security +ptions> /ecovery Console Settin" /ecommendations Settin" Allow automatic administrative logon Allow floppy copy and access to all drives and all folders 2e"acy Client Disabled ?nabled !nterprise Client Disabled ?nabled Speciali1ed Security 7 2imited 0unctionality Disabled Disabled
/ecovery console> &llow automatic administrative lo"on

This policy setting determines whether the password for the Administrator account must be entered before computer access is granted. 3f you enable this policy setting1 the Kecovery Console does not re=uire you to provide a password1 and it automatically logs on to the computer. The Kecovery Console can be very useful when you need to work with computers that have startup problems. However1 it can be detrimental to enable this setting because anyone can then walk up to the server1 disconnect its power to shut it down1 restart it1 select /ecover Console from the /estart menu1 and then assume full control of the server. Therefore1 the /ecovery console> &llow automatic administrative lo"on setting is configured to the default setting of -isabled in the baseline policy for all three environments that are defined in this guide. To use the Kecovery Console when this setting is disabled1 the user will have to enter a user name and password to access the Kecovery Console account.
/ecovery console> &llow floppy copy and access to all drives and all folders
Bou can enable this policy setting to make the Kecovery Console S!T command available1 which allows you to set the following Kecovery Console environment variables" &llowWildCards. ?nables wildcard support for some commands /such as the D?L command0. &llow&ll%at's. Allows access to all files and folders on the computer.
-)
&llow/emovableMedia. Allows files to be copied to removable media1 such as a floppy disk. .oCopy%rompt. Does not prompt when overwriting an e9isting file.
:or ma9imum security1 the /ecovery console> &llow floppy copy and access to all drives and all folders setting is configured to -isabled in the baseline policy for the SSL: environment. However1 this policy setting is configured to !nabled for the LC and ?C environments.
Shutdown Settin(s
Table B 23 Security +ptions> S'utdown Settin" /ecommendations Settin" Allow system to be shut down without having to log on Clear virtual memory page file 2e"acy Client Disabled Disabled !nterprise Client Disabled Disabled Speciali1ed Security 7 2imited 0unctionality Disabled Disabled
S'utdown> &llow system to be s'ut down wit'out 'avin" to lo" on

This policy setting determines whether a computer can be shut down by a user who is not re=uired to log on to the !indows operating system. Jsers who can access the console could shut down the computer. An attacker or misguided user could connect to the server through Terminal Services and shut it down or restart it without having to identify themselves. Therefore1 the S'utdown> &llow system to be s'ut down wit'out 'avin" to lo" on setting is configured to the default setting of -isabled in the baseline policy for all three environments that are defined in this guide.
S'utdown> Clear virtual memory pa"e file

This policy setting determines whether the virtual memory pagefile is cleared when the computer is shut down. !hen this policy setting is enabled1 it causes the system pagefile to be cleared each time that the computer shuts down gracefully. 3f you enable this policy setting1 the hibernation file /Hiberfil.sys0 is also 'eroed out when hibernation is disabled on a portable computer. Server shutdowns and restarts will take longer and will be especially noticeable on servers with large pagefiles. :or these reasons1 the S'utdown> Clear virtual memory pa"e file setting is configured to -isabled in all three environments that are defined in this guide.
3ote$ An attacker who has ph"sical access to the server could simpl" unplu& the server from its power source to b"pass this countermeasure.
-(
Syste" Crypto(raphy Settin(s

Table B 2B Security +ptions> System Crypto"rap'y Settin" /ecommendations Settin" :orce strong key protection for user keys stored on the computer Jse :3-S compliant algorithms for encryption1 hashing1 and signing 2e"acy Client Jser is prompted when the key is first used Disabled !nterprise Client Jser is prompted when the key is first used Disabled Speciali1ed Security 7 2imited 0unctionality Jser must enter a password each time they use a key ?nabled
System crypto"rap'y> 0orce stron" =ey protection for user =eys stored on t'e computer
This policy setting determines whether users private keys /such as their S%M3M? keys0 re=uire a password to be used. 3f you configure this policy setting so that users must provide a passwordIdistinct from their domain passwordIevery time that they use a key1 then it will be more difficult for an attacker to access locally stored keys1 even an attacker who discovers logon passwords. :or usability re=uirements in the LC and ?C environments1 the System crypto"rap'y> 0orce stron" =ey protection for user =eys stored on t'e computer setting is configured to (ser is prompted w'en t'e =ey is first used in the baseline policy. To provide additional security1 this policy setting is configured to (ser must enter a password eac' time t'ey use a =ey for the SSL: environment.
System crypto"rap'y> (se 0)%S compliant al"orit'ms for encryptionC 'as'in"C and si"nin"
This policy setting determines whether the Transport Layer Security#Secure Sockets Layer /TLS#SSL0 Security -rovider supports only the TLSPKSAP!3THP,D?SP?D?PCCCPSHA cipher suite. Although this policy setting increases security1 most public !eb sites that are secured with TLS or SSL do not support these algorithms. Many client computers are also not configured to support these algorithms. :or these reasons1 the System crypto"rap'y> (se 0)%S compliant al"orit'ms for encryptionC 'as'in"C and si"nin" setting is configured to -isabled in the baseline policy for the LC and ?C environments. This policy setting is configured to !nabled for the SSL: environment.
Syste" Ob:ects Settin(s

Table B 2< Security +ptions> System +b,ects Settin" /ecommendations Settin" Default owner for ob7ects created by members of the Administrators group 2e"acy Client $b7ect creator !nterprise Speciali1ed Security 7 Client 2imited 0unctionality $b7ect creator $b7ect creator
-'
Settin" Ke=uire case insensitivity for non% !indows subsystems
2e"acy Client ?nabled
!nterprise Speciali1ed Security 7 Client 2imited 0unctionality ?nabled ?nabled ?nabled ?nabled
Strengthen default permissions of ?nabled internal system ob7ects /for e9ample1 Symbolic Links0
System ob,ects> -efault owner for ob,ects created by members of t'e &dministrators "roup
This policy setting determines whether the &dministrators group or an ob7ect creator is the default owner of any system ob7ects that are created. !hen system ob7ects are created1 the ownership will reflect which account created the ob7ect rather than the more generic &dministrators group. The System ob,ects> -efault owner for ob,ects created by members of t'e &dministrators "roup setting is configured to +b,ect creator in the baseline policy for all three environments that are defined in this guide.
System ob,ects> /e8uire case insensitivity for non* Windows subsystems

This policy setting determines whether case insensitivity is enforced for all subsystems. The Microsoft !in,*( subsystem is case insensitive. However1 the kernel supports case sensitivity for other subsystems1 such as the -ortable $perating System 3nterface for J832 /-$S320. Cecause !indows is case insensitive and the -$S32 subsystem supports case sensitivity1 failure to enforce this setting makes it possible for a -$S32 user to create a file with the same name as another file if they use mi9ed case letters to label it. Such an occurrence may block another user s access to these files with typical !in,* tools1 because only one of the files will be available. To ensure consistency of file names1 the System ob,ects> /e8uire case insensitivity for non*Windows subsystems setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
System ob,ects> Stren"t'en default permissions of internal system ob,ects @e " Symbolic 2in=sA
This policy setting determines the strength of the default discretionary access control list /DACL0 for ob7ects1 and helps secure ob7ects that can be located and shared among processes. To strengthen the DACL you can use the default value of !nabled1 which it allows users who are not administrators to read shared ob7ects but not to modify any that they did not create. The System ob,ects> Stren"t'en default permissions of internal system ob,ects @e " Symbolic 2in=sA setting is configured to the default value of !nabled in the baseline policy for all three environments that are defined in this guide.
Syste" Settin(s
Table B 2D Security +ptions> System Settin" /ecommendations
-6
Settin" System settings" $ptional subsystems System settings" Jse Certificate Kules on !indows ?9ecutables for Software Kestriction -olicies
2e"acy Client 8one 8ot defined
!nterprise Client 8one Disabled
Speciali1ed Security 7 2imited 0unctionality 8one ?nabled
System settin"s> +ptional subsystems

This policy setting determines which subsystems are used to support applications in your environment. The default value for this policy setting in !indows Server *++, is %+S)J. To disable the -$S32 subsystem1 the System settin"s> +ptional subsystems setting is configured to .one in the baseline policy for all three environments that are defined in this guide.
System settin"s> (se Certificate /ules on Windows !3ecutables for Software /estriction %olicies
This policy setting determines whether digital certificates are processed when software restriction policies are enabled and a user or process attempts to run software with an .e9e file name e9tension. 3t enables or disables certificate rules /a type of software restriction policies rule0. !ith software restriction policies1 you can create a certificate rule that will allow or disallow the e9ecution of Authenticode(%signed software1 based on the digital certificate that is associated with the software. :or certificate rules to take effect in software restriction policies1 you must enable this policy setting. The System settin"s> (se Certificate /ules on Windows !3ecutables for Software /estriction %olicies setting is configured to !nabled in the SSL: environment. However1 it is configured to -isabled in the ?C environment and to .ot defined in the LC environment because of the potential performance impact.
vent 9o(
The event log records events on the computer1 and the Security log records audit events. The event log container of Hroup -olicy is used to define attributes of the Application1 Security1 and System event logs1 such as ma9imum log si'e1 access rights for each log1 and retention settings and methods. The settings for the Application1 Security1 and System event logs are configured in the MSC- and applied to all member servers in the domain. Bou can configure the event log settings in !indows Server *++, with S-. at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\!vent 2o" This section provides details about the prescribed MSC- event log settings for all three environments that are defined in this guide. :or a summary of the prescribed settings in this section1 see the Microsoft ?9cel workbook G!indows Server *++, Security Huide Settings1G which is available in the downloadable version of this guide. :or information about the default configuration and a detailed e9planation of each of the settings1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
-:
The following table summari'es the event log setting recommendations for the three environments that are defined in this guide. Additional information about each setting is provided in the subsections that follow the table. Table B 2E !vent 2o" Settin" /ecommendations Settin" Ma9imum application log si'e Ma9imum security log si'e Ma9imum system log si'e -revent local guests group from accessing application log -revent local guests group from accessing security log -revent local guests group from accessing system log Ketention method for application log Ketention method for security log Ketention method for system log 2e"acy Client .L1,>E FC >.16*+ FC .L1,>E FC ?nabled ?nabled ?nabled As needed As needed As needed !nterprise Speciali1ed Security 7 Client 2imited 0unctionality .L1,>E FC >.16*+ FC .L1,>E FC ?nabled ?nabled ?nabled As needed As needed As needed .L1,>E FC >.16*+ FC .L1,>E FC ?nabled ?nabled ?nabled As needed As needed As needed
)a!i"u" app#ication #o( si6e

This policy setting specifies the ma9imum si'e of the Application event log1 which has a ma9imum capacity of E HC. However1 this si'e is not recommended because of the risk of memory fragmentation1 which causes slow performance and unreliable event logging. Ke=uirements for the Application log si'e vary1 and depend on the function of the platform and the need for historical records of application%related events. The Ma3imum application lo" si1e setting is configured to the default value of 1DC3FB K# in the baseline policy for all three environments that are defined in this guide.
)a!i"u" security #o( si6e

This policy setting specifies the ma9imum si'e of the Security event log1 which has a ma9imum capacity of E HC. Bou should configure the Security log to at least >+ MC on domain controllers and stand%alone servers1 which should ade=uately store enough information to conduct audits. How you configure this policy setting for other computers depends on factors that include how fre=uently the log will be reviewed1 available disk space1 and so on. The Ma3imum security lo" si1e security setting is configured to F1C:20 K# in the baseline policy for all three environments that are defined in this guide.
)a!i"u" syste" #o( si6e

This policy setting specifies the ma9imum si'e of the System event log1 which has a ma9imum capacity of E HC. However1 this si'e is not recommended because of the risk of memory fragmentation1 which causes slow performance and unreliable event logging.
-;
Ke=uirements for the System log si'e vary1 and depend on the function of the platform and the need for historical records. The Ma3imum system lo" si1e setting is configured to the default value of 1DC3FB K# in the baseline policy for all three environments that are defined in this guide.
+revent #oca# (uests (roup &ro" accessin( app#ication #o(

This policy setting determines whether guests are denied access to the Application event log. Cy default in !indows Server *++, with S-.1 guest access is prohibited on all computers. Therefore1 this policy setting has no real effect on computers with default configurations. However1 because this configuration is considered a defense%in%depth measure with no side effects1 the %revent local "uests "roup from accessin" application lo" setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
3ote$ This settin& does not appear in the !ocal Computer 8olic" ob?ect.
+revent #oca# (uests (roup &ro" accessin( security #o(

This policy setting determines whether guests are denied access to the Security event log. A user must be assigned the Mana"e auditin" and security lo" user right /not defined in this guidance0 to access the Security log. Therefore1 this policy setting has no real effect on computers with default configurations. However1 because this configuration is considered a defense%in%depth measure with no side effects1 the %revent local "uests "roup from accessin" security lo" setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
+revent #oca# (uests (roup &ro" accessin( syste" #o(

This policy setting determines whether guests are denied access to the System event log. Cy default in !indows Server *++, with S-.1 guest access is prohibited on all computers. Therefore1 this policy setting has no real effect on computers with default configurations. However1 because this configuration is considered a defense%in%depth setting measure with no side effects1 the %revent local "uests "roup from accessin" system lo" setting is configured to !nabled in the baseline policy for all three environments that are defined in this guide.
$etention "ethod &or app#ication #o(

This policy setting determines the GwrappingG method for the Application log. 3t is imperative that the Application log be archived regularly if historical events are needed for either forensics or troubleshooting purposes. 3f events are overwritten as needed1 the log
--
will always store the most recent eventsIalthough this configuration could result in a loss of historical data. The /etention met'od for application lo" setting is configured to &s needed in the baseline policy for all three environments that are defined in this guide.
$etention "ethod &or security #o(

This policy setting determines the GwrappingG method for the Security log. 3t is imperative that the Security log be archived regularly if historical events are needed for either forensics or troubleshooting purposes. 3f events are overwritten as needed1 the log will always store the most recent eventsIalthough this configuration could result in a loss of historical data. The /etention met'od for security lo" setting is configured to &s needed in the baseline policy for all three environments that are defined in this guide.
$etention "ethod &or syste" #o(

This policy setting determines the GwrappingG method for the System log. 3t is imperative that the logs be archived regularly if historical events are needed for either forensics or troubleshooting purposes. 3f events are overwritten as needed1 the log will always store the most recent eventsIalthough this configuration could result in a loss of historical data. The /etention met'od for system lo" setting is configured to &s needed in the baseline policy for all three environments that are defined in this guide.
3dditiona# $e(istry
ntries
Additional registry entries /also called re!istry va#ues0 were created for the baseline security template files that are not defined within the default Administrative Template /.adm0 file for the three security environments that are defined in this guide. The .adm files define the policies and restrictions for the desktop1 shell1 and security for !indows Server *++,. These registry entries are embedded within the security templates /in the GSecurity $ptionsG section0 to automate the changes. 3f the policy is removed1 these registry entries are not automatically removed with itV they must be manually changed with a registry editing tool such as Kegedt,*.e9e. The same registry entries are applied across all three environments. This guide includes additional registry entries that are added to the Security Configuration ?ditor /SC?0. To add these registry entries1 you need to modify the Sceregvl.inf file /located in the $windir$\inf folder0 and re%register the Scecli.dll file. The original security entries1 as well as the additional ones1 appear under 2ocal %olicies\Security in the snap%ins and tools that are listed earlier in this chapter. Bou will need to update the Sceregvl.inf file and re%register the Scecli.dll file for any computers on which you will edit the security templates and Hroup -olicies that are provided with this guide. Details about how to update these files are provided in the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56. This section is only a summary of the additional registry entries that are described in detail in the companion guide. :or information about the default settings and a detailed e9planation of each of the settings that are discussed in this section1 see Threats and Countermeasures Security Settin!s in Windows Server 2003 and Windows XP.
.00
Security Consideration &or ;etwork 3ttacks

Denial of service /DoS0 attacks are network attacks that attempt to make a computer or a particular service on a computer unavailable to network users. DoS attacks can be difficult to defend against. To help prevent these attacks1 you should keep your computer updated with the latest security fi9es and harden the TC-#3- protocol stack on computers that run !indows Server *++, with S-. and are e9posed to potential attackers. The default TC-#3- stack configuration is tuned to handle standard intranet traffic. 3f you connect a computer directly to the 3nternet1 Microsoft recommends that you harden the TC-#3stack against DoS attacks. Bou can add the registry values in the following table to the template file in the ?K!HL2+C&2LM&C?).!\System\CurrentControlSet\Services\Tcpip\%aram eters\ subkey. Table B 2F TC%5)% /e"istry !ntry /ecommendations /e"istry entry 0ormat 2e"acy Client !nterprise Client Speciali1ed Security 7 2imited 0unctionality + . + ,++1+++ * * , +
?nable3CM-Kedirect SynAttack-rotect ?nableDeadH!Detect FeepAliveTime Disable3-SourceKouting TcpMa9ConnectKesponseKetrans missions TcpMa9DataKetransmissions -erformKouterDiscovery
D!$KD D!$KD D!$KD D!$KD D!$KD D!$KD D!$KD D!$KD
+ . + ,++1+++ * * , +
+ . + ,++1+++ * * , +
Other $e(istry
ntries
$ther recommended registry entries that are not specific to TC-#3- are listed in the following table. Additional information about each entry is provided in the subsections that follow the table. Table B 2: +t'er /e"istry !ntry /ecommendations
.0.
/e"istry entry
0ormat
2e"acy Client
!nterprise Client
Speciali1ed Security 7 2imited 0unctionality .
MSS" /8o8ameKelease$nDemand0 Allow the computer to ignore 8etC3$S name release re=uests e9cept from !38S servers MSS" /8tfsDisable>dot,8ameCreation0 ?nable the computer to stop generating >., style filenames /recommended0 MSS" /8oDriveTypeAutoKun0 Disable Autorun for all drives /recommended0 MSS" /ScreenSaverHrace-eriod0 The time in seconds before the screen saver grace period e9pires /+ recommended0
D!$KD
D!$KD
D!$KD
+9::
+9::
+9::
String
MSS" /!arningLevel0 -ercentage D!$KD threshold for the security event log at which the system will generate a warning MSS" /SafeDllSearchMode0 ?nable Safe DLL search mode /recommended0 MSS" /AutoKeboot0 Allow !indows to automatically restart after a system crash /recommended e9cept for highly secure environments0 MSS" /AutoAdminLogon0 ?nable Automatic Logon /not recommended0 MSS" /AutoShare!ks0 ?nable Administrative Shares /recommended e9cept for highly secure environments0 MSS" /DisableSave-assword0 -revent the dial%up password from being saved /recommended0 MSS" /8oDefault?9empt0 ?nable 8oDefault?9empt for 3-Sec :iltering /recommended0 D!$KD
6+
6+
6+
D!$KD
D!$KD
D!$KD
D!$KD
D!$KD
.02
Confi"ure .et#)+S .ame /elease Security> &llow t'e computer to i"nore .et#)+S name release re8uests e3cept from W).S servers
This entry appears as MSS> @.o.ame/elease+n-emandA &llow t'e computer to i"nore .et#)+S name release re8uests e3cept from W).S servers in the SC?. 8etC3$S over TC-#3- is a network protocol that /among other things0 provides a way to easily resolve 8etC3$S names that are registered on !indows%based computers to the 3- addresses that are configured on those computers. This value determines whether the computer releases its 8etC3$S name when it receives a name%release re=uest. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\System\CurrentControlSet\Services\.etbt\%arame ters\ subkey.
-isable &uto Generation of F 3 0ile .ames> !nable t'e computer to stop "eneratin" F 3 style filenames
This entry appears as MSS> @.tfs-isableFdot3.ameCreationA !nable t'e computer to stop "eneratin" F 3 style filenames @recommendedA in the SC?. !indows Server *++, with S-. supports >., file name formats for backward compatibility with.L%bit applications. The >., file name convention is a format that only allows file names of eight characters or less. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\System\CurrentControlSet\Control\0ileSystem\ subkey.
-isable &utorun> -isable &utorun for all drives

This entry appears as MSS> @.o-riveType&uto/unA -isable &utorun for all drives @recommendedA in the SC?. Autorun begins to read from a drive on your computer as soon as media is inserted into it. As a result1 things like the setup file /for programs0 or the sound /for audio content0 start immediately. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\S+0TW&/!\Microsoft\Windows\Current6ersion\% olicies\!3plorer\ subkey.
Ma=e Screensaver %assword %rotection )mmediate> T'e time in seconds before t'e screen saver "race period e3pires @0 recommendedA
This entry appears as MSS> @ScreenSaverGrace%eriodA T'e time in seconds before t'e screen saver "race period e3pires @0 recommendedA in the SC?. !indows includes a grace period between when the screen saver is launched and when the console is actually locked automatically when screen saver locking is enabled.
.0)
Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\Software\Microsoft\Windows .T\Current6ersion\ Winlo"on\ subkey.
Security 2o" .ear Capacity Warnin"> %ercenta"e t'res'old for t'e security event lo" at w'ic' t'e system will "enerate a warnin"
This entry appears as MSS> @Warnin"2evelA %ercenta"e t'res'old for t'e security event lo" at w'ic' t'e system will "enerate a warnin" in the SC?. This option became available with S-, for !indows *+++. 3t generates a security audit in the Security log when its si'e reaches a user%defined threshold. :or e9ample1 if you configure the value for this registry entry to 6+ and the Security log reaches 6+ percent of capacity1 the log will show one entry with an event3D of 5*, that reads as follows" SThe security event log is 6+ percent full.T
3ote$ 6f "ou confi&ure lo& settin&s to 4verwrite events as needed or 4verwrite events o$der than 1 days# this event will not be &enerated.
Bou can add this registry value to the security template file in the ?K!HL2+C&2LM&C?).!\ SHST!M\CurrentControlSet\Services\!ventlo"\Security\ subkey.
!nable Safe -22 Searc' +rder> !nable Safe -22 searc' mode @recommendedA
This entry appears as MSS> @Safe-llSearc'ModeA !nable Safe -22 searc' mode @recommendedA in the SC?. The DLL search order can be configured to search for DLLs that are re=uested by running processes in one of two ways" Search folders that are specified in the system path first1 and then search the current working folder. Search the current working folder first1 and then search the folders that are specified in the system path.
The registry value is configured to .1 which causes the computer to first search the folders that are specified in the system path and then the current working folder. 3f you configure this entry to +1 the computer first searches the current working folder and then the folders that are specified in the system path. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\ SHST!M\CurrentControlSet\Control\Session Mana"er\ subkey.
.0(
&utomatic /eboot> &llow Windows to automatically restart after a system cras'

This entry appears as MSS> @&uto/ebootA &llow Windows to automatically restart after a system cras' @recommended e3cept for 'i"'ly secure environmentsA in the SC?. This entry1 when enabled1 permits a server to automatically reboot after a fatal crash. 3t is enabled by default1 which is undesirable on highly secure servers. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\System\CurrentControlSet\Control\Cras'Control\ subkey.
&utomatic 2o"on> !nable &utomatic 2o"on

This entry appears as MSS> @&uto&dmin2o"onA !nable &utomatic 2o"on @not recommendedA in the SC?. Cy default1 this entry is not enabled and should never be used on a server in practically any conceivable circumstance. :or more information1 see the Microsoft Fnowledge Case article GHow to turn on automatic logon in !indows 2-G at http"##support.microsoft.com#default.asp9? kbid4,.5*,.. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\Software\Microsoft\Windows .T\Current6ersion\ Winlo"on\ subkey.
&dministrative S'ares> !nable &dministrative S'ares

This entry appears as MSS> @&utoS'areW=sA !nable &dministrative S'ares @recommended e3cept for 'i"'ly secure environmentsA in the SC?. Cy default1 when !indows networking is active on a server1 !indows will create hidden administrative sharesIwhich is undesirable on highly secure servers. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\System\CurrentControlSet\Services\/asMan\%ara meters\ subkey.
-isable Saved %asswords> %revent t'e dial*up password from bein" saved
This entry appears as MSS> @-isableSave%asswordA %revent t'e dial*up password from bein" saved @recommendedA in the SC?. Cy default1 !indows will offer the option to save passwords for dial%up and <-8 connections1 which is not desirable on a server. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\System\CurrentControlSet\Services\2anmanServ er\ %arameters\ subkey.
.0'
!nable )%Sec to protect Kerberos /S6% Traffic> !nable .o-efault!3empt for )%Sec 0ilterin"
This entry appears as MSS> @.o-efault!3emptA !nable .o-efault!3empt for )%Sec 0ilterin" @recommendedA in the SC?. The default e9emptions to 3-sec policy filters are documented in the Microsoft !indows Server *++, online help. These filters make it possible for 3nternet Fey ?9change /3F?0 and the Ferberos authentication protocol to function. The filters also make it possible for the network Xuality of Service /XoS0 to be signaled /KS<-0 when the data traffic is secured by 3-sec1 and for traffic that 3-sec might not secure /such as multicast and broadcast traffic0. Bou can add this registry value to the template file in the ?K!HL2+C&2LM&C?).!\System\CurrentControlSet\Services\)%S!C\ subkey.
$estricted Groups
The Kestricted Hroups capability allows you to manage group membership through policy mechanisms and prevent either deliberate or inadvertent e9ploitation of groups that have powerful user rights. Bou should first review the needs of your organi'ation to determine the groups that you want to restrict. The #ac=up +perators and %ower (sers groups are restricted in all three environments that are defined in this guide. Although members of the #ac=up +perators and %ower (sers groups have less access than members in the &dministrators group1 they still have powerful capabilities.
3ote: 6f "our or&ani>ation uses an" of these &roups# then carefull" control their membership and do not implement the &uidance for the 4estricted 5roups settin&. 6f "our or&ani>ation adds users to the 8ower /sers &roup# "ou ma" want to implement the optional file s"stem permissions that are described in the followin& K+ecurin& the ,ile +"stemL section.
Bou can configure the Kestricted Hroups setting in !indows Server *++, with S-. at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\/estricted Groups\ Administrators may configure restricted groups by adding the desired group directly to the MSC-. !hen a group is restricted1 you can define its members and any other groups to which it belongs. 3f you do not specify these group members1 the group remains totally restricted.
Securin( the Fi#e Syste"

The 8T:S file system has been improved with each new version of Microsoft !indows1 and the default permissions for 8T:S are ade=uate for most organi'ations. The settings that are discussed in this section are provided for optional use by organi'ations that do not use restricted groups but still wish to have an additional level of hardening on their servers. Bou can configure the file system security settings at the following location in the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\0ile System
.06
3ote$ Jou should thorou&hl" test an" chan&es to the default file s"stem securit" settin&s in a lab environment before "ou deplo" them in a lar&e or&ani>ation. There have been cases in which file permissions have been altered to a point that re=uired the affected computers to be completel" rebuilt.
The default file permissions in !indows Server *++, with S-. are sufficient for most situations. However1 if you do not plan to block membership of the %ower (sers group with the Kestricted Hroups feature or if you plan to enable the .etwor= access> 2et !veryone permissions apply to anonymous users setting1 you may want to apply the optional permissions that are described in the paragraph that follows. They are very specific1 and they apply additional restrictions to certain e9ecutable tools that a malicious user with elevated privileges may use to further compromise the computer or network. 8ote how these changes do not affect multiple folders or the root of the system volume. 3t can be very risky to change permissions in that manner1 and doing so can often cause computer instability. All of the following files are located in the $System/oot $\System32\ folder1 and they are all given the following permissions" &dministrators> 0ull ControlC System> 0ull Control. regedit.e9e arp.e9e at.e9e attrib.e9e cacls.e9e debug.e9e edlin.e9e eventcreate.e9e eventtriggers.e9e ftp.e9e nbtstat.e9e net.e9e net..e9e netsh.e9e netstat.e9e nslookup.e9e ntbackup.e9e rcp.e9e reg.e9e regedt,*.e9e regini.e9e regsvr,*.e9e re9ec.e9e route.e9e rsh.e9e sc.e9e secedit.e9e subst.e9e systeminfo.e9e telnet.e9e tftp.e9e tlntsvr.e9e
:or your convenience1 these optional permissions are already configured in the security template called +ptional*0ile*%ermissions inf1 which is included with the downloadable version of this guide.
3dditiona# Security Settin(s

Although most of the countermeasures that are used to harden the baseline servers in this guide were applied through Hroup -olicy1 there are additional settings that are difficult or impossible to apply with Hroup -olicy. :or a detailed e9planation of each of the countermeasures discussed in this section1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
.0:
)anua# 'ardenin( +rocedures

This section describes how some additional countermeasures /such as securing accounts0 were implemented manually for each of the security environments that are defined in this guide.
Manually &ddin" (ni8ue Security Groups to (ser /i"'ts &ssi"nments

Most of the recommended security groups for user rights assignments were configured within the security templates that accompany this guide. However1 there are a few rights that cannot be included in the security templates1 because the S3Ds of the specific security groups are uni=ue between different !indows Server *++, domains. The problem is that the K3D /Kelative 3dentifier01 which is part of the S3D1 is uni=ue. These rights are referenced in the following table.
Warning$ The followin& table contains values for 9uilt-in Administrator. The 9uilt-in Administrator is the built-in user account# not the securit" &roup 0d inistrators. 6f the 0d inistrators securit" &roup is added to an" of the followin& den" access user ri&hts# "ou will need to lo& on locall" to correct the mistake. Also# the 9uilt-in Administrator account ma" have a new name if "ou followed the recommendation to rename it earlier in this &uide. 3hen "ou add this account to an" den" access user ri&hts# make sure that "ou select the newl" renamed administrator account.
Table B 30 Manually &dded (ser /i"'ts &ssi"nments Settin" .ame in () Deny access to this computer from the network 2e"acy Client !nterprise Client Speciali1ed Security 7 2imited 0unctionality Cuilt%in AdministratorV SupportP,>>6E5a+V HuestV all 8$8% $perating System service accounts SupportP,>>6E5a+ and Huest Cuilt%in AdministratorV HuestsV SupportP,>>6E5a+V HuestV all 8$8% operating system service accounts
Cuilt%in Cuilt%in AdministratorV AdministratorV SupportP,>>6E5a+V SupportP,>>6E5a+V HuestV all 8$8% $perating System service accounts HuestV all 8$8% $perating System service accounts SupportP,>>6E5a+ and Huest Cuilt%in AdministratorV HuestsV SupportP,>>6E5a+V Huest V all 8$8% operating system service accounts
Deny log on as a batch 7ob Deny log on through Terminal Services
SupportP,>>6E5a+ and Huest Cuilt%in AdministratorV HuestsV SupportP,>>6E5a+V Huest V all 8$8% operating system service accounts
I portant$ All 1 -operatin& s"stem service accounts are service accounts for specific applications in "our enterprise. These accounts do not include !1CA! +J+T2M# !1CA! +24C6C2# or the 2T314< +24C6C2 accounts that are built-in accounts for the operatin& s"stem.
To manually add the listed security groups to the ?nterprise Client % Member Server Caseline -olicy1 complete the following steps. To add security "roups to t'e (ser /i"'ts &ssi"nments 3n Active Directory Jsers and Computers1 right%click the Member Servers $J1 and then select %roperties. .. $n the Hroup -olicy tab1 select the ?nterprise Client Member Server Caseline -olicy to edit the linked H-$.
.0;
*. Select ?nterprise Client @ Member Server Caseline -olicy1 and then click ?dit. ,. 3n the Hroup -olicy window1 click Computer ConfigurationZ!indows SettingsZSecurity SettingZLocal -oliciesZJser Kights Assignment to add the uni=ue security groups from the previous table for each right. E. Close the Hroup -olicy that you modified. 5. Close the Member Servers $J -roperties window. L. :orce replication between the domain controllers so that all have the policy applied to them by doing the following" a. $pen a command prompt1 type "pupdate 50orce and press ?8T?K to force the server to refresh the policy. b. Keboot the server. N. <erify in the event log that the Hroup -olicy downloaded successfully and that the server can communicate with the other domain controllers in the domain.
Securin" Well*Known &ccounts

!indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted but can be renamed. Two of the most well%known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 the built%in Administrator account is renamed and the description altered to help prevent compromise of a remote server by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the S3D /security identifier0 of the built%in Administrator account to determine its true name and then break in to the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against the Administrator account if you rename it with a uni=ue name. Complete the following steps to secure well%known accounts on domains and servers" Kename the Administrator and Huest accounts1 and change their passwords to long and comple9 values on every domain and server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all others with the same account name and password. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes that you make in a secure location.
3ote$ The built-in Administrator account can be renamed throu&h 5roup 8olic". This settin& was not implemented in the baseline polic" because ever" or&ani>ation should choose a uni=ue name for this account. *owever# "ou can confi&ure the 0ccounts: +ena e ad inistrator account settin& to rename administrator accounts in all three environments that are defined in this &uide. This polic" settin& is a part of the +ecurit" 1ptions settin&s of a 581.
.0-
Securin" Service &ccounts

8ever configure a service to run under the security conte9t of a domain account unless it is unavoidable. 3f the server is physically compromised1 domain account passwords could be easily obtained by dumping LSA secrets. :or more information about how to secure service accounts1 see The Services and Service Accounts Security -lanning Huide at http"##go.microsoft.com#fwlink#?Link3d4E.,...
.T0S
8T:S partitions support ACLs at the file and folder levels. This support is not available with the file allocation table /:AT0 or :AT,* file systems. :AT,* is a version of the :AT file system that has been updated to permit significantly smaller default cluster si'es and to support hard disks up to two terabytes in si'e. :AT,* is included in !indows 65 $SK*1 !indows 6>1 Microsoft !indows Me1 !indows *+++1 !indows 2- -rofessional1 and !indows Server *++,. :ormat all partitions on every server with 8T:S. Jse the convert utility to carefully convert :AT partitions to 8T:S1 but remember that the convert utility will set the ACLs for the converted drive to !veryone> 0ull Control. :or computers that run !indows *++, Server with S-.1 apply the following two security templates locally to configure the default file system ACLs for member servers and domain controllers respectively" $windir$\inf\defltsv inf $windir$\inf\defltdc inf
3ote$ The default domain controller securit" settin&s are applied durin& the promotion of a server to a domain controller.
All partitions on servers in all three environments that are defined in this guide are formatted with 8T:S partitions to provide the means for file and directory security management through ACLs.
Terminal Services Settin"s

The Set client connection encryption level setting determines the level of encryption for Terminal Services client connections in your environment. The ?i"' 2evel setting option that uses .*>%bit encryption prevents an attacker from eavesdropping on Terminal Services sessions with a packet analy'er. Some older versions of the Terminal Services client do not support this high level of encryption. 3f your network contains such clients1 set the encryption level of the connection to send and receive data at the highest encryption level that is supported by the client. Bou can configure this setting in Hroup -olicy at the following location" Computer Confi"uration\&dministrative Templates\Windows Components\ Terminal Services\!ncryption and Security Table B 31 Client Connection !ncryption 2evel Settin" /ecommendation Settin" name in () Set client connection encryption level 2e"acy Client High !nterprise Client High Speciali1ed Security 7 2imited 0unctionality High
..0
The three available levels of encryption are described in the following table" Table B 32 Terminal Services !ncryption 2evels !ncryption level High level -escription ?ncrypts data that is sent from client to server and from server to client with strong .*>%bit encryption. Jse this level when the terminal server runs in an environment that contains .*>%bit clients only /such as Kemote Desktop Connection clients0. Clients that do not support this level of encryption will not be able to connect. ?ncrypts data that is sent between the client and the server at the ma9imum key strength that is supported by the client. Jse this level when the terminal server runs in an environment that contains mi9ed or legacy clients. ?ncrypts data that is sent from the client to the server with 5L%bit encryption. )mportant" Data sent from the server to the client is not encrypted.
Client Compatible
Low level
rror $eportin(
Table B 33 /ecommended !rror /eportin" Settin"s Settin" Turn off !indows ?rror Keporting 2e"acy Client ?nabled !nterprise Client ?nabled Speciali1ed Security 7 2imited 0unctionality ?nabled
This service helps Microsoft track and address errors. Bou can configure this service to generate reports for operating system errors1 !indows component errors1 or program errors. 3t is only available in !indows 2- -rofessional and !indows Server *++,. The !rror /eportin" service can report such errors to Microsoft through the 3nternet or to an internal file share. Although error reports can potentially contain sensitive or even confidential data1 the Microsoft privacy policy with regard to error reporting ensures that Microsoft will not use such data improperly. However1 the data is transmitted in plainte9t HTT-1 which could be intercepted on the 3nternet and viewed by third parties. The Turn off Windows !rror /eportin" setting can control whether the ?rror Keporting service transmits any data. Bou can configure this policy setting in !indows Server *++, at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\&dministrative Templates\System\)nternet Communications Mana"ement\)nternet Communications settin"s Configure the Turn off Windows !rror /eportin" setting to !nabled in the DCC- for all three environments that are defined in this guide.
!nable Manual Memory -umps

!indows Server *++, with S-. includes a feature that you can use to halt the computer and generate a Memory.dmp file. Bou must e9plicitly enable this feature1 and it may not be appropriate for all servers in your organi'ation. 3f you determine that it would be
...
valuable to capture memory dumps on some servers1 you can follow the instructions that are provided in !indows feature allows a Memory.dmp file to be generated with the keyboard at http"##support.microsoft.com#default.asp9?kbid4*EE.,6.
I portant: 3hen memor" is copied to disk as described in the referenced article# sensitive information ma" be included in the Memor".dmp file. 6deall"# all servers are protected from unauthori>ed ph"sical access. 6f "ou &enerate a memor" dump file on a server that is at risk for ph"sical compromise# be sure to delete the dump file after troubleshootin& is concluded.
Creatin( the -ase#ine +o#icy 7sin( SCW

To deploy the necessary security settings1 you first need to create a member server baseline policy /MSC-0. To do so1 you must use SC! /the Security Configuration !i'ard tool0 and the security templates that are included with the downloadable version of this guide. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should use hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. During the MSC- creation steps you will probably remove the :ile server role from the list of detected roles. This role is commonly configured on servers that do not re=uire it and could be considered a security risk. To enable the :ile server role for servers that re=uire it1 you can apply a second policy later in this process. To create t'e Member Server #aseline %olicy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain. E. 3nstall and configure only the mandatory applications that will be on every server in your environment. ?9amples include your software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. L. Kemove the :ile server role from the listed of detected roles. N. ?nsure that the detected server roles are appropriate for your environment. >. ?nsure that the detected client features are appropriate for your environment. 6. ?nsure that the detected administrative options are appropriate for your environment. .+. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. ... Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer.
..2
.*. ?nsure the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall. .,. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .E. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .5. 3nclude the appropriate security template /for e9ample1 ?C%Member Server Caseline.inf0. .L. Save the policy with an appropriate name /for e9ample1 Member Server Caseline.9ml0.
%est the +o#icy 7sin( SCW

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method offers the advantage of the ability to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more details about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.
..)
Convert and *ep#oy the +o#icy

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Mem"er Ser#er $aseline !ml" /g:"Mem"er Ser#er $aseline Policy"
Su""ary
This chapter e9plained the server hardening procedures that were initially applied to all of the servers that run !indows Server *++, with S-. in all three security environments that are defined in this guide. Most of these procedures created a uni=ue security template for each security environment and imported it into a H-$ that is linked to the parent $J for the member server to achieve the targeted level of security. However1 some of these hardening procedures cannot be applied through Hroup -olicy. Huidance was provided about how to configure these settings manually. Additional steps were taken for specific server roles to enable them to function within their roles as securely as possible. Server role%specific steps include both additional hardening procedures and procedures to reduce the security settings in the baseline security policy. These changes are discussed in detail in the following chapters of this guide.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening servers that run !indows Server *++, with S-.. :or more information about !indows Server *++, security settings1 see the Security Setting Descriptions page at http"##technet*.microsoft.com#!indowsServer#en#Library#dd6>+ca,%fL>L%Effc%aL.N% 5+cL*E+f55>*.+,,.msp9. :or more information about security for !indows Server *++,1 see the !indows Server *++, Security Center at www.microsoft.com#technet#security#prodtech#windowsserver*++,.msp9.
..(
:or more information about audit policy for !indows Server *++,1 see the Auditing -olicy page at http"##technet*.microsoft.com#!indowsServer#en#Library#L>ENeN*b% 6cEN%E*ab%b,e,%L6.addac6f,,.+,,.msp9. :or more information about Microsoft $perations Manger /M$M01 see the Microsoft $perations Manager page at www.microsoft.com#mom#. :or more information about user rights in !indows Server *++,1 see the Jser rights page at http"##technet*.microsoft.com#!indowsServer#en#Library#5>66>+fb%.a>,% E6+e%aNE5%,5NN5+ced,d6.+,,.msp9. :or more information about default security settings for !indows Server *++,1 see the Differences in default security settings page at http"##technet*.microsoft.com#!indowsServer#en#Library#.E6Ebf*c%b56L%EN>5%6,bb% bc>Lf>e5E>d5.+,,.msp9. :or more information about how to secure !indows *+++ Terminal Services1 see SSecuring !indows *+++ Terminal ServicesT at www.microsoft.com#technet#prodtechnol#win*kts#maintain#optimi'e#secw*kts.msp9. :or more information about how to secure the !indows Server *++, TC-#3- stack1 see the Microsoft Fnowledge Case article GHow To Harden the TC-#3- Stack Against Denial of Service Attacks in !indows Server *++,G at http"##support.microsoft.com#? kbid4,*E*N+. :or more details about how to harden the settings for !indows Sockets applications1 see the Microsoft Fnowledge Case article G3nternet Server Jnavailable Cecause of Malicious SB8 AttacksG at http"##support.microsoft.com#?kbid4.E*LE.. :or more information about the location of .adm files1 see the Microsoft Fnowledge Case article GLocation of ADM /Administrative Template0 :iles in !indowsG at http"##support.microsoft.com#?kbid4**>EL+. :or more information about how to customi'e the Security Configuration ?ditor user interface1 see the Microsoft Fnowledge Case article SHow to Add Custom Kegistry Settings to Security Configuration ?ditorT at http"##support.microsoft.com#? kbid4*.EN5*. :or more information about how to create custom administrative template files in !indows1 see the Microsoft Fnowledge Case article SH$! T$" Create Custom Administrative Templates in !indows *+++T at http"##support.microsoft.com#? kbid4,*,L,6. Also review the white paper SJsing Administrative Template :iles with Kegistry%Cased Hroup -olicyT at www.microsoft.com#technet#prodtechnol#windowsserver*++,#technologies#managem ent#gp#admtgp.msp9. :or more information about ensuring that more secure LA8 Manager authentication level settings work in networks with a mi9 of !indows *+++ and !indows 8T E.+ computers1 see the Microsoft Fnowledge Case article GAuthentication -roblems in !indows *+++ with 8TLM * Levels Above * in a !indows 8T E.+ DomainG at http"##support.microsoft.com#?kbid4,+5,N6. :or more information about 8TLMv* authentication1 see the Microsoft Fnowledge Case article GHow to enable 8TLM * authenticationG at http"##support.microsoft.com#? kbid4*,6>L6. :or more information about the default settings for services in !indows Server *++,1 see the Default settings for services page at http"##technet*.microsoft.com#!indowsServer#en#Library#*b.dcLcf%*e,E%EL>.%6aaL% >d+ffba*d,e,.+,,.msp9. :or more information about smart card deployment1 see SHet SmartU Coost Bour 8etwork;s 3X !ith Smart CardsT at www.microsoft.com#technet#technetmag#issues#*++5#+.#SmartCards#default.asp9.
..'
:or more information about the GKestrict AnonymousG registry value and !indows *+++1 see the Microsoft Fnowledge Case article SThe GKestrictAnonymousG Kegistry <alue May Creak the Trust to a !indows *+++ DomainT at http"##support.microsoft.com#?kbid4*6LE+5. :or more information about error reporting1 see the Corporate ?rror Keporting page at www.microsoft.com#resources#satech#cer#. :or information about network ports used by Microsoft applications1 see the Microsoft Fnowledge Case article GService overview and network port re=uirements for the !indows Server systemG at http"##support.microsoft.com#kb#>,*+.N.
Chapter .: %he *o"ain Contro##er -ase#ine +o#icy

Overview
Addressing security in the Domain Controller server role is one of the most important aspects of any environment with computers that run Microsoft( !indows Server) *++, with Service -ack . /S-.0 and the Active Directory( directory service. Any loss or compromise of a domain controller in such an environment could seriously affect client computers1 servers1 and applications that rely on domain controllers for authentication1 Hroup -olicy1 and a centrali'ed lightweight directory access protocol /LDA-0 directory. Cecause of their importance1 domain controllers should always be stored in physically secure locations that are accessible only to =ualified administrative staff. !hen domain controllers must be stored in unsecured locations1 such as branch offices1 several security settings can be ad7usted to limit the potential damage from physical threats.
*o"ain Contro##er -ase#ine +o#icy

Jnlike the other server role policies that are detailed later in this guide1 the Hroup -olicy for the Domain Controllers server role is a baseline policy like the Member Server Caseline -olicy /MSC-0 defined in Chapter E1 GThe Member Server Caseline -olicy.G The Domain Controller Caseline -olicy /DCC-0 is linked to the Domain Controllers organi'ational unit /$J0 and takes precedence over the Default Domain Controllers -olicy. The policy settings that are included in the DCC- will strengthen the overall security of all domain controllers in any environment. Most of the DCC- is copied from the MSC-. Therefore1 you should carefully review Chapter E1 GThe Member Server Caseline -olicyG to fully understand the many policy settings that are also included in the DCC-. $nly the DCC- settings that differ from those in the MSC- are documented in this chapter. Domain controller templates are uni=uely designed to address the security needs of the three environments that are defined in this guide. The following table shows the domain controller .inf files that are included with this guide for the Legacy Client /LC01 ?nterprise Client /?C01 and Speciali'ed Security @ Limited :unctionality /SSL:0 environments. :or e9ample1 the ?C%Domain Controller.inf file is the security template for the ?nterprise Client environment.
Chapter '$ The 7omain Controller 9aseline 8olic"
..:
Table < 1 -omain Controller #aseline Security Templates 2e"acy Client !nterprise Client Speciali1ed Security 7 2imited 0unctionality SSL:%Domain Controller.inf
LC%Domain Controller.inf ?C%Domain Controller.inf
3ote$ 7omain operations could be severel" impaired if an incorrectl" confi&ured 5roup 8olic" ob?ect @581A is linked to the 7omain Controllers 1/. /se e0treme care when "ou import these securit" templates# and verif" that all imported polic" settin&s are correct before "ou link a 581 to the 7omain Controllers 1/.
3udit +o#icy Settin(s

The Audit policy settings for domain controllers are almost the same as those specified in the MSC-. :or more information1 see Chapter E1 GThe Member Server Caseline -olicy.G The policy settings in the DCC- ensure that all the relevant security audit information is logged on the domain controllers. Table < 2 /ecommended &udit %olicy Settin"s Settin" Audit directory service access 2e"acy Client 8o auditing !nterprise Client 8o auditing Speciali1ed Security 7 2imited 0unctionality :ailure
3udit directory service access

This policy setting determines whether to audit user access to an Active Directory ob7ect that has its own specified system access control list /SACL0. 3f you define the &udit directory service access setting1 you can specify whether to audit successes1 failures1 or not audit the event type at all. Success audits generate an audit entry when a user successfully accesses an Active Directory ob7ect that has a specified SACL. :ailure audits generate an audit entry when a user unsuccessfully attempts to access an Active Directory ob7ect that has a specified SACL. 3f you enable the &udit directory service access setting in the DCC- and configure SACLs on directory ob7ects1 a large volume of entries can be generated in the Security logs on domain controllers. Bou should only enable this setting if you actually intend to use the information that is created. The &udit directory service access setting is configured to .o auditin" in the LC and ?C environments. 3t is configured to log 0ailure events in the SSL: environment. The following table includes the important security events that the &udit directory service access setting records in the Security log. Table < 3 -irectory Service &ccess !vents !vent )- !vent description 3D 5LL Description A generic ob7ect operation took place.
..;
7ser $i(hts 3ssi(n"ent Settin(s

The DCC- specifies a number of user rights assignments for the domain controllers. 3n addition to the default configuration1 several user rights settings were modified to strengthen the security for the domain controllers in the three environments that are defined in this guide. This section provides details about the prescribed user rights settings for the DCC- that differ from those in the MSC-. :or a summary of the prescribed settings in this section1 refer to the Microsoft ?9cel( workbook G!indows Server *++, Security Huide SettingsG that is included with the downloadable version of this guide. The following table summari'es the recommended user rights assignment settings for the DCC-. Additional information for each setting is provided in the sections that follow the table. Table < B /ecommended (ser /i"'ts &ssi"nments Settin"s Settin" 2e"acy Client !nterprise Client Speciali1ed Security 7 2imited 0unctionality Administrators1 Authenticated Jsers1 ?8T?K-K3S? D$MA38 C$8TK$LL?KS Administrators Administrators
Access this computer from the network
8ot defined
8ot defined
Add workstations to domain Allow log on locally
8ot defined Administrators1 Server $perators1 Cackup $perators Administrators Administrators1 L$CAL S?K<3C? 8ot Defined
8ot defined Administrators1 Server $perators1 Cackup $perators Administrators Administrators1 L$CAL S?K<3C? 8ot Defined
Allow log on through Terminal Services Change the system time ?nable computer and user accounts to be trusted for delegation Load and unload device drivers Kestore files and directories Shutdown the system
Administrators Administrators1 L$CAL S?K<3C? Administrators
Administrators Administrators Administrators
3ccess this co"puter &ro" the network

This policy setting determines which users and groups are allowed to connect to the domain controller over the network. 3t is re=uired by a number of network operations1 including Active Directory replication between domain controllers1 authentication re=uests
..-
to domain controllers from users and from computers1 and for access to shared folders and printers. Although permissions that are assigned to the !veryone security group no longer provide access to anonymous users in !indows Server *++, with S-.1 guest groups and accounts can still be provided with access through the !veryone security group. :or this reason1 the !veryone security group is removed from the &ccess t'is computer from t'e networ= user right in the DCC- for the SSL: environment. Kemoval of this group provides an e9tra safeguard against attacks that target guest access to the domain. This policy setting is configured to .ot defined for the LC and ?C environments.
3dd workstations to do"ain

This policy setting specifies which users can add computer workstations to a specific domain. :or this policy setting to take effect1 it must be assigned to the user as part of the Default Domain Controller -olicy for the domain. A user who has been assigned this right can add up to .+ workstations to the domain. Jsers who have been assigned the Create Computer +b,ects permission for an $J or the Computers container in Active Directory can add an unlimited number of computers to the domain1 regardless of whether they have been assigned the &dd wor=stations to a domain user right. Cy default1 all users in the &ut'enticated (sers group have the ability to add up to .+ computer accounts to an Active Directory domain. These new computer accounts are created in the Computers container. 3n !indows@based networks1 the term security )rinci)a# is defined as a user1 group1 or computer that is automatically assigned a security identifier to control access to resources. 3n an Active Directory domain1 each computer account is a full security principal with the ability to authenticate and access domain resources. However1 some organi'ations may want to limit the number of computers in an Active Directory environment so that they can consistently track1 build1 and manage the computers. 3f users are allowed to add computers to the domain1 tracking and management efforts would be hampered. Also1 users could perform activities that are more difficult to trace because of their ability to create additional unauthori'ed domain computers. :or these reasons1 the &dd wor=stations to domain user right is assigned only to the &dministrators group in the DCC- for the SSL: environment. This policy setting is configured to .ot defined for the LC and ?C environments.
3##ow #o( on #oca##y

This policy setting specifies which users can start interactive sessions on the domain controller. Jsers who do not have this right are still able to start a remote interactive session on the domain controller if they have been assigned the &llow lo"on t'rou"' Terminal Services user right. Bou should restrict the number of accounts that can log on to domain controller consoles to help prevent unauthori'ed access to domain controller file systems and system services. A user who is able to log on to the console of a domain controller could maliciously e9ploit the computer and possibly compromise the security of an entire domain or forest. Cy default1 the &ccount +perators1 #ac=up +perators1 %rint +perators1 and Server +perators groups are assigned the &llow lo" on locally user right on domain controllers. Jsers in these groups should not need to log on to a domain controller to perform their management tasks1 and they should be able to perform their duties from
.20
other workstations. $nly users in the &dministrators group should perform maintenance tasks on domain controllers. 3f you assign the &llow lo" on locally user right only to the &dministrators group1 physical and interactive domain controller access is limited to only highly trusted users1 which enhances security. :or this reason1 the &llow lo" on locally user right is assigned only to the &dministrators group in the DCC- for the SSL: environment. This policy setting is configured to include the Server +perators and #ac=up +perators groups for the LC and ?C environments.
3##ow #o( on throu(h %er"ina# Services

This policy setting specifies which users can log on to the domain controller through a Kemote Desktop connection. Bou should restrict the number of accounts that can log on to domain controller consoles through Terminal Services to help prevent unauthori'ed access to domain controller file systems and system services. A user who is able to log on to the console of a domain controller through Terminal Services can e9ploit that computer and possibly compromise the security of an entire domain or forest. 3f you assign the &llow lo" on t'rou"' Terminal Services user right only to the &dministrators group1 interactive domain controller access is limited to only highly trusted users1 which enhances security. :or this reason1 the &llow lo" on t'rou"' Terminal Services user right is assigned only to the &dministrators group in the DCCfor all three environments that are defined in this guide. Although logon to a domain controller through Terminal Services re=uires administrative access by default1 configuration of this policy setting helps protect against inadvertent or malicious actions that might compromise the network. As an additional security measure1 the DCC- denies the default Administrator account the &llow lo" on t'rou"' Terminal Services user right. This configuration prevents attempts by malicious users to remotely break into a domain controller with the default Administrator account. :or more details about this policy setting1 see Chapter E1 GThe Member Server Caseline -olicy.G
Chan(e the syste" ti"e

This policy setting specifies which users can ad7ust the time on a computer s internal clock. However1 it is not needed to change the time 'one or other display characteristics of the system time. Synchroni'ed system time is critical to the operation of Active Directory. -roper Active Directory replication and authentication ticket generation processes that are used by the Ferberos authentication protocol rely on time being synchroni'ed across any environment. A domain controller clock that is not synchroni'ed with the system time on other domain controllers in the environment could interfere with the operation of domain services. 3f only administrators are allowed to modify system time1 the possibility of incorrect system time on a domain controller is minimi'ed. Cy default1 the Server +perators group has the ability to modify system time on domain controllers. Cecause of the problems that could be caused by incorrect modification of a domain controller s clock by members of this group1 the C'an"e t'e system time user right is assigned in the DCC- to only the &dministrators group and the 2ocal Service account for all three environments that are defined in this guide.
.2.
:or more information on the Microsoft !indows( Time Service1 see the !indows Time Service Technical Keference at http"##technet*.microsoft.com#!indowsServer#en#Library#a+fcd*5+%e5fN%E.b,%b+e>% *E+f>*,Le*.+.+,,.msp9.
nab#e co"puter and user accounts to be trusted &or de#e(ation

This policy setting specifies which users can change the Trusted for -ele"ation setting on a user or computer ob7ect in Active Directory. Delegation of authentication is a capability that is used by multi%tier client#server applications. 3t allows a front%end service1 such as an application1 to use the credentials of a client in authenticating to a back%end service1 such as a database. :or such authentication to be possible1 both client and server must run under accounts that are trusted for delegation. Misuse of this user right could allow unauthori'ed users to impersonate other users on the network. An attacker could e9ploit this user right to gain access to network resources as if they were a different user1 which could make it difficult to determine what has happened after a security incident. The !nable computer and user accounts to be trusted for dele"ation user right is assigned only to the &dministrators group on domain controllers for the SSL: environment. This policy setting is configured to .ot defined for the LC and ?C environments.
3ote$ Althou&h the 7efault 7omain Controllers 8olic" assi&ns the 0d inistrators &roup this user ri&ht# the 7C98 enforces this ri&ht in the ++!, environment onl" because it was ori&inall" based on the M+98. The M+98 assi&ns this ri&ht a null value.
9oad and un#oad device drivers

This policy setting specifies which users can load and unload device drivers1 and is necessary to load and unload -lug and -lay devices. Careless device driver management on domain controllers provides opportunities for bugs or malicious code to adversely impact the operation of the domain controllers. 3f the accounts that can load and unload device drivers are restricted in the DCC- to only the most trusted users1 you minimi'e the potential for device drivers to be used to compromise domain controllers. Cy default1 the 2oad and unload device drivers user right is assigned to the %rint +perators group. As mentioned earlier1 creation of printer shares is not recommended on domain controllers1 which removes the need for %rint +perators to have the ability to load and unload device drivers. Therefore1 the 2oad and unload device drivers user right is assigned only to the &dministrators group in the DCC- for all three environments that are defined in this guide.
$estore &i#es and directories

This policy setting specifies which users can circumvent file and directory permissions during the restore process. Any valid security principal could be set as the owner of an ob7ect. An account that has the ability to restore files and directories to the file system of a domain controller can easily modify e9ecutable files. Malicious users could e9ploit this capability to not only render a domain controller useless1 but also to compromise the security of a domain or an entire forest.
.22
Cy default1 the /estore files and directories user right is assigned to the Server +perators and #ac=up +perators groups. 3f you remove this user right from these groups and assign it only to the &dministrators group1 the likelihood of domain controller compromise by improper modifications to the file system is reduced. Therefore1 the /estore files and directories user right is assigned only to the &dministrators group in the DCC- for all three environments that are defined in this guide.
Shutdown the syste"

This policy setting specifies which users can shut down the local computer. Malicious users with the ability to shut down domain controllers can easily initiate a denial of service /DoS0 attack that could severely affect an entire domain or forest. An attacker could e9ploit this user right to launch an elevation of privilege attack on a domain controller s account when it restarts services. A successful elevation of privilege attack on a domain controller compromises the security of a domain or an entire forest. Cy default1 the S'utdown t'e system user right is assigned to the &dministrators1 Server +perators1 %rint +perators1 and #ac=up +perators groups. 3n secure environments1 none of these groups e9cept &dministrators re=uire this right to perform administrative tasks. :or this reason1 the S'utdown t'e system user right is assigned only to the &dministrators group in the DCC- for all three environments that are defined in this guide.
Security Options
Most of the security option settings for domain controllers are the same as those specified in the MSC-. :or more information1 see Chapter E1 GThe Member Server Caseline -olicy.G Differences between the MSC- and the DCC- policy settings are described in the following sections.
*o"ain Contro##er Settin(s

Table < < Security +ptions> -omain Controller Settin" /ecommendations Settin" Allow server operators to schedule tasks LDA- server signing re=uirements Kefuse machine account password changes 2e"acy Client !nterprise Client Disabled 8ot defined Disabled Disabled 8ot defined Disabled Speciali1ed Security 7 2imited 0unctionality Disabled Ke=uire signing Disabled
-omain controller> &llow server operators to sc'edule tas=s

This policy setting determines whether members of the Server +perators group are allowed to submit 7obs by means of the AT schedule facility. The -omain controller> &llow server operators to sc'edule tas=s setting is configured to -isabled in the DCC- for all three environments that are defined in this
.2)
guide. The impact of this policy setting configuration should be small for most organi'ations. Jsers1 including those in the Server +perators group1 will still be able to create 7obs by means of the Task Scheduler !i'ard1 but those 7obs will run in the conte9t of the account with which the user authenticates when they set up the 7ob.
3ote$ An AT +ervice Account can be modified to select a different account rather than the !1CA! +J+T2M account. To chan&e the account# open +"stem Tools# click Schedu$ed !as5s# and then click 0ccessories folder. Then click 0! Service 0ccount on the 0dvanced menu.
-omain controller> 2-&% server si"nin" re8uirements

This policy setting determines whether the LDA- server re=uires a signature before it will negotiate with LDA- clients. 8etwork traffic that is neither signed nor encrypted is susceptible to man%in%the%middle attacks in which an intruder captures packets between the server and the client1 modifies them1 and then forwards them to the client. :or an LDA- server1 an attacker could cause a client to make decisions that are based on false records from the LDA- directory. 3f all domain controllers run !indows *+++ or !indows Server *++,1 configure the -omain controller> 2-&% server si"nin" re8uirements setting to /e8uire si"nin". $therwise1 leave this policy setting configured as .ot defined1 which is the DCCconfiguration for the LC and ?C environments. This policy setting is configured to /e8uire si"nin" in the DCC- for the SSL: environment because all computers in this environment run either !indows *+++ or !indows Server *++,.
-omain controller> /efuse mac'ine account password c'an"es

This policy setting determines whether domain controllers will refuse re=uests from member computers to change computer account passwords. 3f you enable this policy setting on all domain controllers in a domain1 computer account passwords on domain members will not be able to be changed and they will be more susceptible to attack. Therefore1 the -omain controller> /efuse mac'ine account password c'an"es setting is configured to -isabled in the DCC- for all three environments that are defined in this guide.
;etwork Security Settin(s

Table < D Security +ptions> .etwor= Security Settin"s /ecommendations Settin" Do not store LA8 Manager hash value on ne9t password change 2e"acy Client ?nabled !nterprise Client ?nabled Speciali1ed Security 7 2imited 0unctionality ?nabled
;etwork security: *o not store 93; )ana(er hash va#ue on ne!t password chan(e
This policy setting determines whether the LA8 Manager /LM0 hash value for the new password is stored when the password is changed. The LM hash is relatively weak and prone to attack compared to the cryptographically stronger !indows 8T( hash.
.2(
:or this reason1 the DCC- enables the .etwor= security> -o not store 2&. Mana"er 'as' value on ne3t password c'an"e setting in all three environments that are defined in this guide.
3ote$ 1lder operatin& s"stems and some third-part" applications ma" fail if "ou enable this polic" settin&. ,or e0ample# 3indows -' and 3indows -; will fail if the" do not have the Active 7irector" Client 20tension installed. Also# all accounts will be re=uired to chan&e their password if "ou enable this polic" settin&.
vent 9o( Settin(s

The event log settings for domain controllers are the same as those that are specified in the MSC-. :or more information1 see Chapter E1 GThe Member Server Caseline -olicy.G The baseline settings in the DCC- ensure that all the relevant security audit information is logged on the domain controllers1 including Directory Services Access.
$estricted Groups
As described in the previous chapter1 the /estricted Groups setting allows you to manage the membership of groups in !indows Server *++, with S-. through Active Directory Hroup -olicy. :irst1 review the needs of your organi'ation to determine the groups you want to restrict. :or domain controllers1 the Server +perators and #ac=up +perators groups are restricted in all three environments that are defined in this guide. Although members of the Server +perators and #ac=up +perator groups have less access than members in the &dministrators group1 they still have powerful capabilities.
3ote: 6f "our or&ani>ation uses an" of these &roups# then carefull" control their membership and do not implement the &uidance for the +estricted Groups settin&. 6f "our or&ani>ation adds users to the +erver /sers &roup# "ou ma" want to implement the optional file s"stem permissions that are described in the K+ecurin& the ,ile +"stemL section in the previous chapter.
Table < E /estricted Groups /ecommendations 2ocal Group Cackup $perators Server $perators 2e"acy Client 8o members 8o members !nterprise Client 8o members 8o members Speciali1ed Security 7 2imited 0unctionality 8o members 8o members
The /estricted Groups setting can be configured in !indows Server *++, with S-. at the following location in the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\/estricted Groups\ To configure restricted groups for a H-$1 administrators can add the desired group directly to the /estricted Groups node of the H-$ namespace. !hen a group is restricted1 you can define its members and any other groups to which it belongs. 3f you do not specify these group members1 the group is left totally restricted. Hroups can only be restricted with security templates.
.2'
To view or modify t'e /estricted Groups settin" .. $pen the Security Templates Management Console.
3ote$ The +ecurit" Templates Mana&ement Console is not added to the Administrative Tools menu b" default. To add it# start the Microsoft Mana&ement Console @mmc.e0eA and add the +ecurit" Templates Add-in.
*. Double%click the configuration file directory1 and then the configuration file. ,. Double%click the /estricted Groups item. E. Kight%click /estricted Groups. 5. Select &dd Group. L. Click the #rowse button1 then 2ocations1 select the locations you want to browse1 and then click +K.
3ote$ T"picall"# this action will cause a local computer to displa" at the top of the list.
N. Type the group name in the !nter t'e ob,ect names to select te9t bo9 and then click the C'ec= .ames button. @ or @ Click the &dvanced button1 and then the 0ind .ow button to list all available groups. >. Select the groups you want to restrict1 and then click +K. 6. Click +K on the &dd Groups dialog bo9 to close it. 3n this guidance1 all membersIusers and groupsIof the Server +perators and #ac=up +perators groups were removed to totally restrict them in both environments. Also1 for the SSL: environment1 all members were removed for the /emote -es=top (sers group. Microsoft recommends that you restrict any built%in group you do not plan to use in your organi'ation.
3ote$ The confi&uration of 4estricted 5roups that is described in this section is ver" simple. Cersions of 3indows F8 with +8. and +82 as well as 3indows +erver 200) support more comple0 desi&ns. ,or more information# see the Microsoft <nowled&e 9ase article K/pdates to 4estricted 5roups @HMember ofHA 9ehavior of /ser-7efined !ocal 5roupsL at http$%%support.microsoft.com%default.asp0OkbidP;.00:6.

This section describes modifications that must be made to the DCC- manually1 as well as additional settings and countermeasures that cannot be implemented through Hroup -olicy.
)anua##y 3ddin( 7ni5ue Security Groups to 7ser $i(hts 3ssi(n"ents

Most user rights assignments that are applied through the DCC- are properly specified in the security templates that accompany this guide. However1 there are a few accounts and security groups that cannot be included in the templates because their security identifiers /S3Ds0 are specific to individual !indows Server *++, domains. Jser rights assignments that must be configured manually are specified in the following table.
Warning$ The followin& table contains values for the built-in Administrator account. This account is not to be confused with the built-in 0d inistrators securit" &roup. 6f "ou add the 0d inistrators securit" &roup to an" of the followin& den" access user ri&hts# "ou will need to lo& on locall" to correct the mistake. Also# if "ou renamed the built-in Administrator account in
.26
accordance with the recommendations in Chapter (# HThe Member +erver 9aseline 8olic"#H ensure that "ou select the newl" renamed administrator account when "ou add the account to an" den" access user ri&hts.
Table < F Manually &dded (ser /i"'ts &ssi"nments Settin" Deny access to this computer from the network 2e"acy Client Cuilt%in AdministratorV SupportP,>>6E5a+V HuestV all 8$8% $perating System service accounts SupportP,>>6E5a+ and Huest Cuilt%in AdministratorV all 8$8%operating system service accounts !nterprise Client Cuilt%in AdministratorV SupportP,>>6E5a+V HuestV all 8$8% $perating System service accounts SupportP,>>6E5a+ and Huest Cuilt%in AdministratorV all 8$8%operating system service accounts Speciali1ed Security 7 2imited 0unctionality Cuilt%in AdministratorV SupportP,>>6E5a+V HuestV all 8$8% $perating System service accounts SupportP,>>6E5a+ and Huest Cuilt%in AdministratorV all 8$8%operating system service accounts
Deny log on as a batch 7ob Deny log on through Terminal Services
I portant$ KAll non-operatin& s"stem service accountsL includes service accounts that are used for specific applications across an enterprise# but does 1T include !1CA! +J+T2M# !1CA! +24C6C2 or the 2T314< +24C6C2 accounts @the built-in accounts that the operatin& s"stem usesA.
*irectory Services
Domain controllers that run !indows Server *++, with S-. store directory data and manage user and domain interactions1 including user logon processes1 authentication1 and directory searches.
/elocatin" -ata 7 &ctive -irectory -atabase and 2o" 0iles

To maintain directory integrity and reliability1 it is essential that you safeguard the Active Directory database and its log files. Bou can move the 8tds.dit1 ?db.log1 and Temp.edb files from their default location1 which will help to conceal them from an attacker if a domain controller is compromised. 3f you move the files off the system volume to a separate physical disk1 you will gain the added benefit of improved domain controller performance. :or these reasons1 this guide recommends that you move the Active Directory database and log files for the domain controllers to a striped or striped#mirrored disk volume that does not contain the operating system. These files should be moved for all three environments that are defined in this guide.
/esi1in" &ctive -irectory 2o" 0iles

An ade=uate amount of information must be logged to effectively monitor and maintain the integrity1 reliability1 and availability of Active Directory. 3nformation is needed from all domain controllers in the environment. Bou can increase the ma9imum si'e of the log files to support this effort. More log information will allow administrators to perform meaningful audits if hacker attacks occur.
.2:
This guide recommends that you increase the ma9imum si'e of the Directory Service and :ile Keplication Service log files from the 5.* FC default to .L MC on the domain controllers in the three environments that are defined in this guide.
(sin" Sys=ey
$n domain controllers1 password information is stored in Active Directory. 3t is not unusual for password%cracking software to target the Security Accounts Manager /SAM0 database or directory services to access passwords for user accounts. The System Fey utility /Syskey0 provides an e9tra line of defense against offline password%cracking software. Syskey uses strong encryption techni=ues to secure account password information that is stored in the SAM on the domain controller. Table < : Sys=ey Modes System Key option Mode ." System Henerated -assword1 Store Startup Fey Locally Security level Secure -escription Jses a computer%generated random key as the system key and stores an encrypted version of the key on the local computer. This option provides strong encryption of password information in the registry1 and enables the user to restart the computer without the need for an administrator to enter a password or insert a disk.
Mode *" Administrator generated password1 -assword Startup
More secure Jses a computer%generated random key as the system key and stores an encrypted version of the key on the local computer. The key is also protected by an administrator%chosen password. Jsers are prompted for the system key password when the computer is in the initial startup se=uence. The system key password is not stored anywhere on the computer. Most secure Jses a computer%generated random key and stores the key on a floppy disk. The floppy disk that contains the system key is re=uired for the computer to start1 and it must be inserted at a prompt during the startup se=uence. The system key is not stored anywhere on the computer.
Mode ," System Henerated -assword1 Store Startup Fey on :loppy Disk
Syskey is enabled on all !indows Server *++, with S-. servers in Mode . /obfuscated key0. :rom a security standpoint1 this configuration appears sensible at first. However1 Syskey in Mode . allows an attacker to read and alter the contents of the directory1 which would render the domain controller easily vulnerable to an attacker with physical access. There are many reasons to recommend using Syskey in Mode * /console password0 or Mode , /floppy storage of Syskey password0 for any domain controller that is e9posed to physical security threats. However1 the operational need to restart domain controllers tends to make Syskey Mode * or Mode , difficult to support. To take advantage of the added protection provided by these Syskey modes1 the proper operational processes must be implemented in your environment to meet specific availability re=uirements for the domain controllers. The logistics of Syskey password or floppy disk management can be =uite comple91 especially in branch offices. :or e9ample1 it can be very e9pensive to re=uire one of your branch managers or local administrative staff to come to the office at , A.M. to enter
.2;
passwords or insert a floppy to enable user access. Such e9pensive re=uirements can make the achievement of high availability service level agreements /SLAs0 a significant challenge. Alternatively1 if you decide to allow your centrali'ed 3T operations personnel to provide the Syskey password remotely1 additional hardware is re=uired. Some hardware vendors have add%on solutions that allow you to remotely access server consoles. :inally1 the loss of the Syskey password or floppy disk would leave your domain controller in a state where it cannot be restarted. There is no method for you to recover a domain controller if the Syskey password or floppy disk is lost. 3f this happens1 the domain controller must be rebuilt. !ith the proper operational procedures in place1 Syskey can provide an increased level of security to protect sensitive directory information on domain controllers. :or these reasons1 Syskey Mode * or Mode , is recommended for domain controllers in locations without strong physical storage security. This configuration applies to domain controllers in all three environments that are described in this guide. To create or update a system =ey .. Click Start1 click /un1 type sys=ey1 and then click +K. *. Click !ncryption !nabled1 and then click (pdate. ,. Click the desired option1 and then click +K.
3ctive *irectory<Inte(rated *;S

Microsoft recommends the use of Active Directory%integrated D8S in the three environments that are defined in this guide. -art of the reason for this recommendation is because Active Directory 'one integration makes it simpler to secure the D8S infrastructure in an environment that uses Active Directory%integrated D8S than in an environment that does not use Active Directory%integrated D8S.
%rotectin" -.S Servers

3t is essential to safeguard D8S servers in any Active Directory environment. The following sections provide several recommendations and e9planations about how to safeguard D8S servers. !hen a D8S server is attacked1 one possible goal of the attacker is to control the D8S information that is returned in response to D8S client =ueries. 3f an attacker controls this information1 clients may be unknowingly redirected to unauthori'ed computers. 3spoofing and cache poisoning are e9amples of this type of attack. 3n 3- spoofing1 a transmission is given the 3- address of an authori'ed user to obtain access to a computer or network. Cache poisoning is an attack in which an unauthori'ed host transmits false information about another host into the cache of a D8S server. The attack causes clients to be redirected to unauthori'ed computers. 3f client computers are allowed to communicate with unauthori'ed computers1 the unauthori'ed computers may attempt to gain access to information on the client computers. 8ot all attacks focus on spoofing D8S servers. Some DoS attacks could alter D8S records in legitimate D8S servers to provide invalid addresses in response to client =ueries. 3f a D8S server responds with invalid addresses1 clients and servers cannot locate the resources they need to function1 such as domain controllers1 !eb servers1 or file shares.
.2-
:or these reasons1 the routers that are used in the three environments that are defined in this guide are configured to drop spoofed 3- packets1 which helps ensure that the 3addresses of the D8S servers are not spoofed by other computers.
Confi"urin" Secure -ynamic (pdates

The -.S client service in !indows Server *++, with S-. supports dynamic D8S updates1 which allow client computers to add D8S records directly into the database. 3f a dynamic D8S server is configured to accept unsecured updates1 an attacker could transmit malicious or unauthori'ed updates from a client computer that supports the D8S dynamic update protocol. At a minimum1 an attacker can add false entries to the D8S database. At worst1 an attacker can overwrite or delete legitimate entries in the D8S database. Such an attacker could accomplish any of the following" -irect clients to unaut'ori1ed domain controllers. !hen a client submits a D8S =uery to find the address of a domain controller1 a compromised D8S server can be instructed to return the address of an unauthori'ed server. Then1 with the use of other non%D8S related attacks1 the client might be tricked and convinced to transmit secure information to the unauthori'ed server. /espond to -.S 8ueries wit' invalid addresses. Clients and servers would be unable to locate one another. 3f clients cannot locate servers1 they cannot access the directory. !hen domain controllers cannot locate other domain controllers1 directory replication stops1 which creates a DoS condition that could affect users throughout a forest. Create a -oS condition. A server;s disk space could be e9hausted by a huge 'one file that is filled with dummy records or large numbers of entries that slow down replication.
Jse of secure dynamic D8S updates guarantees that registration re=uests are only processed if they are sent from valid clients in an Active Directory forest. This method severely limits the ability of an attacker to compromise the integrity of a D8S server. :or these reasons1 the Active Directory D8S servers in the three environments that are defined in this guide are configured to accept only secure dynamic updates.
2imitin" Mone Transfers to &ut'ori1ed Systems

Cecause of the importance of 'ones in D8S1 they should be available from more than one D8S server on the network to provide ade=uate availability and fault tolerance for name resolution =ueries. !hen additional servers host a 'one1 'one transfers are re=uired to replicate and synchroni'e all copies of the 'one for each server that is configured to host the 'one. Also1 a D8S server that does not limit who can re=uest 'one transfers is vulnerable to transfer of the entire D8S 'one to anyone who re=uests it. This transfer can be easily accomplished with tools such as 8slookup.e9e. Such tools can e9pose the entire domain s D8S dataset1 including such things as which hosts serve as domain controllers1 directory%integrated !eb servers1 or Microsoft SXL Server) databases. :or these reasons1 Active Directory%integrated D8S servers in the three environments that are defined in this guide are configured to allow 'one transfers1 but to limit which computers can make transfer re=uests.
.)0
/esi1in" t'e !vent 2o" and -.S Service 2o"

An ade=uate amount of information must be logged to effectively monitor and maintain the D8S service. 3nformation is needed from all domain controllers in the environment. Bou can increase the ma9imum si'e of the D8S service log file1 which will allow administrators to perform meaningful audits in the event of an attack. This guide recommends that you increase the ma9imum si'e of the D8S service log file to at least .L MC on the domain controllers in the three environments that are defined in this guide. Also1 ensure that the +verwrite events as needed option in the D8S service is selected to ma9imi'e the amount of log entries preserved.
Securin( We##<4nown 3ccounts

!indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted but can be renamed. Two of the most well known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 you should rename the built%in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in administrator account to determine its true name and then break in to the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name. Complete the following steps to secure well%known accounts on domains and servers" Kename the Administrator and Huest accounts1 and change their passwords to long and comple9 values on every domain and server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all others with the same account name and password. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes that you make in a secure location.
3ote$ The built-in administrator account can be renamed throu&h 5roup 8olic". This polic" settin& was not implemented in an" of the securit" templates that are provided with this &uide because ever" or&ani>ation should choose a uni=ue name for this account. *owever# "ou can confi&ure the 0ccounts: +ena e ad inistrator account settin& to rename administrator accounts in all three environments that are defined in this &uide. This polic" settin& is a part of the +ecurit" 1ptions settin&s of a 581.
Securin( Service 3ccounts

8ever configure a service to run under the security conte9t of a domain account unless it is unavoidable. 3f the server is physically compromised1 domain account passwords could be easily obtained by dumping LSA secrets. :or more information about how to secure
.).
service accounts1 see The Services and Service Accounts Security -lanning Huide at http"##go.microsoft.com#fwlink#?Link3d4E.,...
%er"ina# Services Settin(s

Table < 10 /ecommended Terminal Services Settin"s -efault Set client connection encryption level 2e"acy Client High !nterprise Client High Speciali1ed Security 7 2imited 0unctionality High
The Set client connection encryption level setting determines the level of encryption for Terminal Services client connections in your environment. The ?i"' 2evel option that uses .*>%bit encryption prevents an attacker from eavesdropping on Terminal Services sessions with a packet analy'er. Some older versions of the Terminal Services client do not support this high level of encryption. 3f your network contains such clients1 set the encryption level of the connection to send and receive data at the highest encryption level that is supported by the client. The Set client connection encryption level setting is configured to !nabled and ?i"' 2evel encryption is selected in the DCC- for the three security environments that are defined in this guide. Bou can configure this policy setting in !indows Server *++, at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\&dministrative Templates\Windows Components\ Terminal Services\!ncryption and Security The three available levels of encryption are described in the following table" Table < 11 Terminal Services !ncryption 2evels !ncryption level High level -escription ?ncrypts data that is sent from client to server and from server to client with strong .*>%bit encryption. Jse this level when the Terminal Server runs in an environment that contains .*>%bit clients only /such as Kemote Desktop Connection clients0. Clients that do not support this level of encryption will not be able to connect. ?ncrypts data that is sent between the client and the server at the ma9imum key strength that is supported by the client. Jse this level when the Terminal Server runs in an environment that contains mi9ed or legacy clients. ?ncrypts data that is sent from the client to the server with 5L%bit encryption. )mportant" Data sent from the server to the client is not encrypted.
Client Compatible
Low level
.)2
rror $eportin(
Table < 12 /ecommended !rror /eportin" Settin"s Settin" Turn off !indows ?rror Keporting 2e"acy Client ?nabled !nterprise Client ?nabled Speciali1ed Security 7 2imited 0unctionality ?nabled
This service helps Microsoft track and address errors. Bou can configure this service to generate reports for operating system errors1 !indows component errors1 or program errors. 3t is only available in !indows 2- -rofessional and !indows Server *++,. The !rror /eportin" service can report such errors to Microsoft through the 3nternet or to an internal file share. Although error reports can potentially contain sensitive or even confidential data1 the Microsoft privacy policy with regard to error reporting ensures that Microsoft will not use such data improperly. However1 the data is transmitted in plainte9t HTT-1 which could be intercepted on the 3nternet and viewed by third parties. The Turn off Windows !rror /eportin" setting controls whether the !rror /eportin" service transmits any data. Bou can configure this policy setting in !indows Server *++, at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\&dministrative Templates\System\)nternet Communications Mana"ement\)nternet Communications settin"s Configure the Turn off Windows !rror /eportin" setting to !nabled in the DCC- for all three environments that are defined in this guide.
Creatin( the +o#icy 7sin( SCW

To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a domain controller baseline policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These policy settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that are configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should install the operating system on hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. To create t'e -omain Controller #aseline %olicy Bou must use a computer that is configured as a domain controller to create the Domain Controller Caseline -olicy. Bou can use either an e9isting domain controller or create a reference computer and use the Dcpromo tool to make the computer a domain controller. However1 most organi'ations do not want to add a domain controller to their production environment because it may violate their security policy. 3f you use an e9isting domain
.))
controller1 make sure that you do not apply any setting to it with SC! or modify its configuration. .. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. *. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. ,. ?nsure that the detected server roles are appropriate for your environment. Do not remove the :ile server role1 because it is re=uired for the proper operation of domain controllers. E. ?nsure that the detected client features are appropriate for your environment. 5. ?nsure that the detected administrative options are appropriate for your environment.
3ote$ 6f "our environment contains domain controllers in multiple sites# ensure that Mai$7 &ased 0ctive "irectory rep$ication is selected.
L. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. N. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. >. ?nsure that the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall.
3ote$ 2nsure that #orts *or Syste +#C 0pp$ications is selected.
6. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .+. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. ... 3nclude the appropriate security template /for e9ample1 ?C%Domain Controller.inf0. .*. Save the policy with an appropriate name /for e9ample1 Domain Controller.9mlA.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method offers the advantage of the ability to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you
.)(
should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more details about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\%omain Controller !ml" /g:"%omain Controller Policy"
*. Jse the Hroup -olicy Management Console to link the newly created H-$ to the Domain Controllers $J1 and make sure to move it above the Default Domain Controllers -olicy so that it receives the highest priority. 8ote that if the SC! security policy file contains !indows :irewall settings1 !indows :irewall must be active on the local computer for this procedure to complete successfully. To verify that !indows :irewall is active1 open Control -anel and then double%click Windows 0irewall. Kemember that the newly created H-$ can take some time to replicate to all domain controllers1 especially in environments with domain controllers in multiple sites. After you verify that the H-$ has replicated successfully1 you should perform a final test to ensure that the H-$ applies the desired policy settings. To complete this procedure1 confirm that the appropriate settings were made and that functionality is not affected.
Su""ary
This chapter e9plained how to harden domain controller servers that run !indows Server *++, with S-. in each of the three environments that are defined in this guide. Most of the policy settings that were discussed were configured and applied through Hroup -olicy. The Domain Controller Caseline -olicy /DCC-0 that complements the Default Domain Controller -olicy was linked to the Domain Controllers $J. The DCC- settings will enhance overall security for domain controllers in any environment. The use of two H-$s to secure domain controllers allows the default environment to be preserved and simplifies troubleshooting. Several of the settings that were discussed cannot be applied through Hroup -olicy. :or these settings1 manual configuration details were provided.
.)'
After the domain controllers are configured for security1 other server roles can be made more secure. The following chapters of this guide focus on how to secure several other specific server roles.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening domain controllers that run !indows Server *++, with S-.. :or information about the Microsoft Systems Architecture" ?nterprise Data Center prescriptive architecture guides1 see the MSA ?DC -rescriptive Architecture Huide page at www.microsoft.com#resources#documentation#msa#edc#all#solution# en%us#pak#pag#default.msp9. :or information about how to enable anonymous access to Active Directory1 see the Microsoft Fnowledge Case article GDescription of Dcpromo -ermissions ChoicesG at http"##support.microsoft.com#?kbid4*5N6>>. :or information about !indows *+++ D8S1 see the G!indows *+++ D8S !hite -aperG at www.microsoft.com#technet#prodtechnol#windows*+++serv#plan# w*kdns*.msp9. :or more information about !indows *+++ D8S1 see Chapter L of the online version of GTC-#3- Core 8etworking HuideG in the !indows *+++ Server Kesource Fit at www.microsoft.com#resources#documentation#!indows#*+++#server#reskit#en% us#Default.asp?url4#resources#documentation#!indows#*+++#server#reskit#en% us#w*rkbook#Core8etwork.asp. :or more information about the changes to D8S in !indows Server *++,1 see the SChanges to D8S in !indows Server *++, Microsoft -ower-oint presentationT at http"##download.microsoft.com#download#e#.#a#e.aba.5N%E6>,%E>+e%aae5% ,ENbEa,>ea5*#ChangestoD8S.ppt. :or more information about restricting Active Directory1 see the Microsoft Fnowledge Case article GKestricting Active Directory replication traffic to a specific portG at http"##support.microsoft.com#?kbid4**E.6L. :or more information about restricting :KS replication traffic1 see the Microsoft Fnowledge Case article GHow to restrict :KS replication traffic to a specific static portG at http"##support.microsoft.com#?kbid4,.655,. :or more information about the !indows Time Service1 see the !indows Time Service Technical Keference at http"##technet*.microsoft.com#!indowsServer#en#Library#a+fcd*5+%e5fN%E.b,%b+e>% *E+f>*,Le*.+.+,,.msp9. :or more information about 3- spoofing1 see the -D: version of the article S3ntroduction to 3- SpoofingT at www.giac.org#practical#gsec#<ictorP<elascoPHS?C.pdf.
Chapter /: %he In&rastructure Server $o#e

Overview
This chapter e9plains the policy settings you can use to harden infrastructure servers that run Microsoft( !indows Server) *++, with Service -ack . /S-.0 in the three environments that are defined in this guide. :or the purposes of this guide1 an infrastructure server is one that provides DHC- services or Microsoft !38S functionality. Most of the settings in this chapter are configured and applied through Hroup -olicy. A Hroup -olicy ob7ect /H-$0 that complements the Member Server Caseline -olicy /MSC-0 can be linked to the appropriate organi'ational units /$Js0 that contain the infrastructure servers to provide additional security for the servers. This chapter only discusses those policy settings that vary from the MSC-. !here possible1 these policy settings are gathered in an incremental Hroup -olicy ob7ect that will be applied to the 3nfrastructure Servers $J. Some of the settings in this chapter cannot be applied through Hroup -olicy. Detailed information about how to configure these settings manually is provided. The following table shows the names of the infrastructure server security templates for the three environments that are defined in this guide. These templates provide the policy settings for the incremental 3nfrastructure Server template1 which in turn is used to create a new H-$ that is linked to the 3nfrastructure Servers $J in the appropriate environment. Step%by%step instructions are provided in Chapter *1 G!indows Server *++, Hardening MechanismsG to help you create the $Js and Hroup -olicies and then import the appropriate security template into each H-$. Table D 1 )nfrastructure Server Security Templates and %olicies 2e"acy Client LC%3nfrastructure Server.inf !nterprise Client ?C%3nfrastructure Server.inf Speciali1ed Security 7 2imited 0unctionality SSL:%3nfrastructure Server.inf
:or information about policy settings in the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.T :or information on all default policy settings1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-* which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.

The Audit policy settings for infrastructure servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings turn on logging for the relevant security audit information on infrastructure servers.
Chapter 6$ The 6nfrastructure +erver 4ole
.):
7ser $i(hts 3ssi(n"ent Settin(s

The user rights assignments for infrastructure servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings configure user rights assignments uniformly on all infrastructure servers.
Security Options
The security options settings for infrastructure servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings configure relevant security options settings uniformly on all infrastructure servers.
vent 9o( Settin(s

The event log settings for infrastructure servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G

The security settings that the MSC- applies significantly enhance the security of infrastructure servers. This section discusses some additional settings for consideration. Bou cannot configure the settings in this section through Hroup -olicyV you need to configure them manually on all infrastructure servers.
Con&i(ure *'C+ 9o((in(

Cy default1 the DHC- service only logs startup and shutdown events in the event log. Complete the following steps to enable a more detailed log on the DHC- server" .. Kight%click the DHC- server in the DHC- Administration Tool. *. Select %roperties. ,. $n the General tab of the %roperties dialog bo91 click !nable -?C% &udit 2o""in". !hen you complete these steps1 the DHC- server creates a log file in the following location" $systemroot$\system32\d'cp\ DHC- client information is often difficult to locate in log files because the only information that is stored in most logs are computer names1 not 3- addresses. The DHC- audit logs provide an additional tool to help locate the sources of internal attacks or inadvertent activities. However1 the information in these logs is not foolproof1 because both host names and media access control /MAC0 addresses can be forged or spoofed. /Spoofing makes a transmission appear to come from a user other than the user who performed the action.0 However1 the benefits that this information provides outweigh any costs that are incurred when logging is enabled on a DHC- server. 3t can be very helpful to have more than 7ust
.);
an 3- address and a computer name when you need to determine how a particular 3address was used on a network. Cy default1 the Server +perators and &ut'enticated (sers groups have read permissions to the DHC- log files. To best preserve the integrity of the information logged by a DHC- server1 it is recommended that access to these logs be limited to server administrators. The Server +perators and &ut'enticated (sers groups should be removed from the Access Control List /ACL0 of the $systemroot$\system32\d'cp\ folder. 3n theory1 the DHC- audit logs could fill the disk on which they are stored. However1 the default configuration for the -?C% &udit 2o""in" setting ensures that logging will stop if there is less than *+ MC of free disk space available on the server. This default configuration is ade=uate for servers in most environments1 but you can modify it to ensure sufficient free disk space is available for other applications on a server. :or information about how to modify this configuration1 refer to the DhcpLogMinSpace$nDisk page in the !indows Server *++, Tech Center at http"##technet*.microsoft.com#!indowsServer#en#Library#fN>+*dce%,ff6%E+La%b,eL% c+cLb,edE6E..+,,.msp9.
+rotect 3(ainst *'C+ *enia# o& Service 3ttacks

Cecause DHC- servers are critical resources that provide client access to the network1 they could be prime targets for a DoS attack. 3f a DHC- server is attacked and unable to service DHC- re=uests1 DHC- clients will eventually be unable to ac=uire leases. Those clients will then lose their e9isting 3- leases and the ability to access network resources. 3t would not be very difficult to write an attack tool script that re=uests all available addresses on a DHC- server. Such a script would e9haust the pool of available 3addresses for subse=uent1 legitimate re=uests from DHC- clients. 3t is also possible for a malicious user to configure all DHC- 3- addresses on the network adapter of a computer they administer1 which would cause the DHC- server to detect 3- address conflicts for all addresses in its scope and to refuse to allocate DHC- leases. Also1 as with all other network services1 a DoS attackIfor e9ample1 C-J e9haustion or filling the re=uest buffer of the DHC- listenerIthat e9hausts the DHC- server s ability to respond to legitimate traffic could make it impossible for clients to re=uest leases and renewals. This type of problem can be avoided by proper design of DHC- services. Bou can configure DHC- servers in pairs and follow the best practice >+#*+ ruleIsplit DHC- server scopes between servers so that >+ percent of the addresses are distributed by one DHC- server and *+ percent by anotherIto help mitigate the impact of these types of attacks. These configuration suggestions help ensure that clients can continue to receive 3- address configuration despite server failure. :or more information about the >+#*+ rule and the DHC- protocol1 see the Dynamic Host Configuration -rotocol page in the !indows *+++ Server Kesource Fit at www.microsoft.com#resources#documentation#!indows#*+++#server# reskit#en%us#cnet#cncbPdhcPklom.asp.
3ote$ The ;0%20 4ule described in the 3indows 2000 +erver 4esource <it also applies to 7*C8 services in 3indows +erver 200) with +8..

!indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted but can be renamed. Two of the most well%known built%in accounts in !indows Server *++, are Huest and Administrator.
.)-
Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 you should rename the built%in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in Administrator account to determine its true name and then break into the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name. To secure well*=nown accounts on infrastructure servers Kename the Administrator and Huest accounts1 and change their passwords to long and comple9 values on every domain and server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all other servers with the same account name and password. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes that you make in a secure location.
3ote$ The built-in Administrator account can be renamed throu&h 5roup 8olic". This polic" settin& was not implemented in an" of the securit" templates that are provided with this &uide because ever" or&ani>ation should choose a uni=ue name for this account. *owever# "ou can confi&ure the 0ccounts: +ena e ad inistrator account settin& to rename administrator accounts in all three environments that are defined in this &uide. This polic" settin& is a part of the +ecurit" 1ptions settin&s of a 581.


To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a server policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These policy settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should install the operating system on hardware that is
.(0
similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. During the server policy creation steps you will probably remove the :ile server role from the list of detected roles. This role is commonly configured on servers that do not re=uire it and could be considered a security risk. To enable the :ile server role for servers that re=uire it1 you can apply a second policy later in this process. To create t'e infrastructure server policy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain1 which will apply all security settings from parent $Js. E. 3nstall and configure only the mandatory applications that will be on every server that shares this role. ?9amples include role%specific services1 software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. L. ?nsure that the detected server roles are appropriate for your environmentIfor e9ample1 the DHC- server and !38S server roles. N. ?nsure that the detected client features are appropriate for your environment. >. ?nsure that the detected administrative options are appropriate for your environment. 6. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. .+. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. ... ?nsure the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall. .*. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .,. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .E. 3nclude the appropriate security template /for e9ample1 ?C%3nfrastructure Server.inf0. .5. Save the policy with an appropriate name /for e9ample1 3nfrastructure Server.9ml0.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices.
.(.
Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more details about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Infrastructure !ml" /g:"Infrastructure Policy"
*. Jse the Hroup -olicy Management Console to link the newly created H-$ to the appropriate $J. 8ote that if the SC! security policy file contains !indows :irewall settings1 !indows :irewall must be active on the local computer for this procedure to complete successfully. To verify that !indows :irewall is active1 open Control -anel and then double%click Windows 0irewall. Bou should now perform a final test to ensure that the H-$ applies the desired policy settings. To complete this procedure1 confirm that the appropriate policy settings were made and that functionality is not affected.
Su""ary
This chapter e9plained the policy settings that can be used for DHC- and !38S servers that run !indows Server *++, with S-. in the three environments that are defined in this guide. Most of the settings for these roles are applied through the MSC-. The primary goal of creating an 3nfrastructure -olicy ob7ect for the DHC- and !38S servers is to
.(2
enable the necessary services for these roles to fully function and keep them well secured. Although the MSC- provides a great level of security1 this chapter also discussed other considerations for the infrastructure server roles. -rimarily1 these considerations included the generation of log files.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening infrastructure servers that run !indows Server *++, with S-.. :or information about how DHC- logging has changed in !indows Server *++,1 see the Microsoft Fnowledge Case article SChanges in !indows Server *++, DHCLoggingT at http"##support.microsoft.com#?kbid4,*>>6.. :or more information about DHC-1 see the Dynamic Host Configuration -rotocol page at www.microsoft.com#resources#documentation#!indows#*+++#server#reskit# en%us#cnet#cncbPdhcPklom.asp. :or more information about !38S1 see the S!indows *+++ Server !indows 3nternet 8aming Service /!38S0 $verviewT at www.microsoft.com#technet#archive#windows*+++serv#evaluate#featfunc#nt5wins.msp 9. :or information about installing !38S in !indows Server *++,1 see the S3nstall and Manage !38S ServersT page at www.microsoft.com#technet#prodtechnol#windowsserver*++,#library# ServerHelp#a*6d+a56%>bdd%Ea>*%a6>+%b5,bdN*fcb+e.msp9.
Chapter 0: %he Fi#e Server $o#e

Overview
3t can be a challenge to harden file server computers that run Microsoft( !indows Server) *++, with Service -ack . /S-.01 because the most essential services that these servers provide are the ones that re=uire the Server Message Clock /SMC0 and Common 3nternet :ile System /C3:S0 protocols. These protocols can provide rich information to unauthenticated users1 and they are often disabled in high security !indows environments. However1 it will be difficult for both users and administrators to access file servers if these protocols are disabled. Most of the policy settings in this chapter are configured and applied through Hroup -olicy. A Hroup -olicy ob7ect /H-$0 that complements the Member Server Caseline -olicy /MSC-0 can be linked to the appropriate organi'ational units /$Js0 that contain the file servers to provide the re=uired security settings for this server role. This chapter only discusses those policy settings that vary from the MSC-. !here possible1 these policy settings are gathered in an incremental Hroup -olicy ob7ect that will be applied to the :ile Servers $J. Some of the policy settings in this chapter cannot be applied through Hroup -olicy. Detailed information about how to configure these policy settings manually is provided. The following table shows the names of the file server security templates for the three environments that are defined in this guide. These templates provide the settings for the incremental :ile Server template1 which in turn is used to create a new H-$ that is linked to the :ile Servers $J in the appropriate environment. Step%by%step instructions are provided in Chapter *1 G!indows Server *++, Hardening MechanismsG to help you create the $Js and Hroup -olicies and then import the appropriate security template into each H-$. Table E 1 0ile Server Security Templates 2e"acy Client LC%:ile Server.inf !nterprise Client ?C%:ile Server.inf Speciali1ed Security 7 2imited 0unctionality SSL:%:ile Server.inf
:or information about policy settings in the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.T :or information on all default policy settings1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-* which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.

The Audit policy settings for file servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings activate security audit information logging on all file servers.
.((

The user rights assignment settings for file servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings uniformly configure all appropriate user rights assignments on all file servers.
Security Options
The security options settings for file servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings uniformly configure all relevant security option settings on all file servers.
vent 9o( Settin(s

The event log settings for file servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G

Although the security settings that the MSC- applies significantly enhance the security of file servers1 this section discusses some additional considerations. However1 the settings in this section cannot be implemented through Hroup -olicy and must therefore be performed manually on all file servers.

!indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted but can be renamed. Two of the most well%known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 you should rename the built%in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in Administrator account to determine its true name and then break into the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name. To secure well*=nown accounts on file servers Kename the Administrator and Huest accounts1 and then change their passwords to long and comple9 values on every domain and server.
Chapter :$ The ,ile +erver 4ole
.('
Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all others. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes that you make in a secure location.
3ote$ Jou can rename the built-in Administrator account throu&h 5roup 8olic". This settin& was not implemented in an" of the securit" templates that are provided with this &uide because ever" or&ani>ation should choose a uni=ue name for this account. *owever# "ou can confi&ure the 0ccounts: +ena e ad inistrator account settin& to rename administrator accounts in all three environments that are defined in this &uide. This polic" settin& is a part of the +ecurit" 1ptions settin&s of a 581.


To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a server policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should install the operating system on hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. To create t'e file server policy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain1 which will apply all security settings from parent $Js. E. 3nstall and configure only the mandatory applications that will be on every server that shares this role. ?9amples include role%specific services1 software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. L. ?nsure that the detected server roles are appropriate for your environmentIfor e9ample1 the :ile server role.
.(6
N. ?nsure that the detected client features are appropriate for your environment. >. ?nsure that the detected administrative options are appropriate for your environment. 6. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. .+. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. ... ?nsure the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall. .*. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .,. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .E. 3nclude the appropriate security template /for e9ample1 ?C%:ile Server.inf0. .5. Save the policy with an appropriate name /for e9ample1 :ile Server.9mlA.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use the SC! HJ3 to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more information about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.
Chapter :$ The ,ile +erver 4ole
.(:

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\&ile Ser#er !ml" /g:"&ile Ser#er Policy"
Su""ary
This chapter e9plained the policy settings that can be used to configure file servers that run !indows Server *++, with S-. in the three environments that are defined in this guide. Most of the policy settings are applied through a Hroup -olicy ob7ect /H-$0 that was designed to complement the MSC-. H-$s can be linked to the appropriate organi'ational units /$Js0 that contain the file servers to provide additional security. Some policy settings cannot be applied through Hroup -olicy. :or these policy settings1 manual configuration details were provided.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening file servers that run !indows Server *++, with S-.. :or more information about file servers1 see GTechnical $verview of !indows Server *++, :ile ServicesG at www.microsoft.com#windowsserver*++,#techinfo#overview#file.msp9. :or more information about D:S and :KS1 see the Distributed :ile System Technology Center at www.microsoft.com#windowsserver*++,#technologies#storage#dfs#default.msp9.
Chapter 1: %he +rint Server $o#e

Overview
This chapter focuses on how to harden print servers that run Microsoft( !indows Server) *++, with S-.1 which can be a challenge. The essential services that these servers provide are ones that re=uire the Server Message Clock /SMC0 and Common 3nternet :ile System /C3:S0 protocols1 both of which can provide rich information to unauthenticated users. These protocols are often disabled on print servers in high%security !indows environments. However1 it will be difficult for both administrators and users to access print servers if these protocols are disabled in your environment. Most of the settings in this chapter are configured and applied through Hroup -olicy. A Hroup -olicy ob7ect /H-$0 that complements the Member Server Caseline -olicy /MSC-0 can be linked to the appropriate organi'ational units /$Js0 that contain the print servers to provide the re=uired security settings for this server role. This chapter only discusses those policy settings that vary from the MSC-. !here possible1 these settings are gathered in an incremental Hroup -olicy template that will be applied to the -rint Servers $J. Some of the settings in this chapter cannot be applied through Hroup -olicy. Detailed information about how to configure these settings manually is provided. The following table shows the names of the print server security templates for the three environments that are defined in this guide. These templates provide the policy settings for the incremental -rint Server template1 which in turn is used to create a new H-$ that is linked to the -rint Servers $J in the appropriate environment. Step%by%step instructions are provided in Chapter *1 G!indows Server *++, Hardening MechanismsG to help you create the $Js and Hroup -olicies and then import the appropriate security template into each H-$. Table F 1 %rint Server Security Templates for &ll T'ree !nvironments 2e"acy Client LC%-rint Server.inf !nterprise Client ?C%-rint Server.inf Speciali1ed Security 7 2imited 0unctionality SSL:%-rint Server.inf
:or information about settings in the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.T :or information on all default settings1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-* which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
3ote: 8rint servers that are secured with the ++!,-8rint +erver.inf securit" template can onl" be accessed reliabl" b" client computers that are secured with compatible settin&s. +ee the Windows XP Security Guide for information about how to secure client computers with ++!,-compatible settin&s.
Chapter ;$ The 8rint +erver 4ole
.(-

The Audit policy settings for print servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings activate logging for security audit information on all print servers.

The user rights assignment settings for print servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings uniformly configure user rights assignments on all print servers.
Security Options
Most security option settings for print servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G Differences between the MSC- and the -rint Server Hroup -olicy are described in the following section.
)icroso&t network server: *i(ita##y si(n co""unications =a#ways>

Table F 2 /ecommended Settin"s for -i"itally Si"nin" Communications @&lwaysA Settin" 2e"acy Client !nterprise Client Disabled Speciali1ed Security 7 2imited 0unctionality Disabled
Microsoft network server" Disabled Digitally sign communications /always0
This policy setting determines whether packet signing is re=uired by the SMC server component. The SMC protocol provides the basis for Microsoft file and print sharing and many other network operations1 such as remote !indows administration. To prevent man%in%the%middle attacks that modify SMC packets in transit1 the SMC protocol supports SMC packet digital signing. This policy setting determines whether SMC packet signing must be negotiated before further communication with an SMC client is permitted. Although the Microsoft networ= server> -i"itally si"n communications @alwaysA setting is disabled by default1 the MSC- enables this setting for servers in the SSL: environment1 which allows users to print but not view the print =ueue. Jsers who attempt to view the print =ueue will see an access denied message. The Microsoft networ= server> -i"itally si"n communications @alwaysA setting is configured to -isabled for print servers in all three environments that are defined in this guide.
.'0
vent 9o( Settin(s

The event log settings for print servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G

Although the security settings applied through the MSC- significantly enhance the security of print servers1 there are a few additional settings that you should consider. The settings in this section cannot be applied through Hroup -olicy and must therefore be performed manually on all print servers.

Microsoft !indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted but can be renamed. Two of the most well%known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 you should rename the built%in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in Administrator account to determine its true name and then break into the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name. To secure well =nown accounts on print servers Kename the Administrator and Huest accounts1 and then change their passwords to long and comple9 values on every domain and server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all others. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes that you make in a secure location.
3ote$ Jou can rename the built-in Administrator account throu&h 5roup 8olic". This settin& was not implemented in an" of the securit" templates that are provided with this &uide because ever" or&ani>ation should choose a uni=ue name for this account. *owever# the 0ccounts: +ena e ad inistrator account settin& can be confi&ured to rename administrator accounts in all three environments that are defined in this &uide. This polic" settin& is a part of the +ecurit" 1ptions settin&s of a 581.

8ever configure a service to run under the security conte9t of a domain account unless it is unavoidable. 3f the server is physically compromised1 domain account passwords could
.'.
be easily obtained by dumping LSA secrets. :or more information about how to secure service accounts1 see The Services and Service Accounts Security -lanning Huide at http"##go.microsoft.com#fwlink#?Link3d4E.,...

To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a server policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should use hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. To create t'e print server policy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain1 which will apply all security settings from parent $Js. E. 3nstall and configure only the mandatory applications that will be on every server that shares this role. ?9amples include role%specific services1 software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. L. ?nsure that the detected server roles are appropriate for your environment1 for e9ample the -rint server role. N. ?nsure that the detected client features are appropriate for your environment. >. ?nsure that the detected administrative options are appropriate for your environment. 6. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. .+. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. ... ?nsure the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall. .*. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .,. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file.
.'2
.E. 3nclude the appropriate security template /for e9ample1 ?C%-rint Server.inf0. .5. Save the policy with an appropriate name /for e9ample1 -rint Server.9mlA.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method offers the advantage of the ability to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more details about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Print Ser#er !ml" /g:"Print Ser#er Policy"
*. Jse the Hroup -olicy Management Console to link the newly created H-$ to the appropriate $J. 8ote that if the SC! security policy file contains !indows :irewall settings1 !indows :irewall must be active on the local computer for this procedure to complete successfully. To verify that !indows :irewall is active1 open Control -anel and then double%click Windows 0irewall.
.')
Bou should now perform a final test to ensure that the H-$ applies the desired settings. To complete this procedure1 confirm that the appropriate settings were made and that functionality is not affected.
Su""ary
This chapter e9plained the policy settings that can be used for print servers that run !indows Server *++, with S-. for the three environments that are defined in this guide. Most of the policy settings are applied through a Hroup -olicy ob7ect /H-$0 that was designed to complement the MSC-. H-$s can be linked to the appropriate organi'ational units /$Js0 that contain the print servers to provide additional security. Some policy settings that were discussed cannot be applied through Hroup -olicy. :or these policy settings1 manual configuration details were provided.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening print servers that run !indows Server *++, with S-.. :or an overview of print servers1 see the GTechnical $verview of !indows Server *++, -rint Services1G which is available for download at www.microsoft.com#windowsserver*++,#techinfo#overview#print.msp9. :or more information about print servers1 see G!hat s 8ew in :ile and -rint ServicesG at www.microsoft.com#windowsserver*++,#evaluation#overview#technologies# fileandprint.msp9.
Chapter 2: %he Web Server $o#e

Overview
This chapter provides guidance that will help you harden the !eb servers in your environment that run Microsoft( !indows Server) *++, with S-.. To provide comprehensive security for !eb servers and applications within your organi'ation s intranet1 Microsoft recommends that you protect each Microsoft 3nternet 3nformation Services /33S0 server as well as each !eb site and application that run on these servers from client computers that can connect to them. Bou should also protect these !eb sites and applications from the !eb sites and applications that run on the other 33S servers within your organi'ation;s intranet. To help protect against malicious users and attackers1 the default configuration for members of the !indows Server *++, family does not install 33S. !hen it is installed1 33S is configured in a highly secure1 GlockedG mode. :or e9ample1 in its default state 33S will only serve static content. Cecause they could be e9ploited by potential intruders1 features such as Active Server -ages /AS-01 AS-.8?T1 Server Side 3ncludes /SS301 !eb Distributed Authoring and <ersioning /!ebDA<0 publishing1 and Microsoft :ront-age( Server ?9tensions will not work until an administrator enables them. These features and services can be enabled through the !eb Service ?9tensions node in 3nternet 3nformation Services Manager /33S Manager0. 33S Manager has a graphical user interface /HJ30 that is designed to facilitate administration of 33S. 3t includes resources for file management1 directory management1 and configuration of application pools1 as well as security1 performance1 and reliability features. Bou should consider implementation of the settings that are described in the following sections of this chapter to enhance the security of 33S !eb servers that host HTML content within your organi'ation;s intranet. To help secure your servers1 you should also implement security monitoring1 detection1 and response procedures to watch for new threats. Most of the settings in this chapter are configured and applied through Hroup -olicy. An incremental H-$ that complements the MSC- is linked to the appropriate $Js and provides additional security for the !eb servers. To improve the usability of this chapter1 only those policy settings that vary from the MSC- are discussed. !here possible1 these settings are gathered in an incremental Hroup -olicy template that will be applied to the !eb Servers $J. Some of the settings in this chapter cannot be applied through Hroup -olicy. Detailed information about how to configure these settings manually is provided. The following table shows the names of the !eb server security templates for the three environments that are defined in this guide. These !eb server security templates provide the policy settings for the incremental !eb Server template. Bou can use this template to create a new H-$ that is linked to the !eb Servers $J in the appropriate environment. Chapter *1 G!indows Server *++, Hardening Mechanisms1G provides step%by%step instructions to help you create the $Js and Hroup -olicies and then import the appropriate security template into each H-$. Table : 1 ))S Server Security Templates
Chapter -$ The 3eb +erver 4ole
.''
2e"acy Client LC%!eb Server.inf
!nterprise Client ?C%!eb Server.inf
Speciali1ed Security 7 2imited 0unctionality SSL:%!eb Server.inf
:or information about all default setting configurations1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56. This guide illustrates how to secure 33S with minimal features installed and enabled. 3f you plan to use additional features in 33S you may need to need to ad7ust some of the security settings. 3f you install additional services such as SMT-1 :T-1 or 88T-1 you will need to ad7ust the provided templates and policies. The online article G33S and Cuilt%in Accounts /33S L.+0G at www.microsoft.com#technet#prodtechnol#!indowsServer*++,#Library#33S# ,LE>,ELf%eEf5%ENEb%>LcN%5a>Le>5fa.ff.msp9 e9plains the accounts that different features of 33S use and the privileges that are re=uired by each. To implement more secure settings on !eb servers that host comple9 applications1 you may find it useful to review the complete 33S L.+ Documentation at www.microsoft.com#technet#prodtechnol#!indowsServer*++,# Library#33S#>E>6L>f,%baa+%ELf6%b.eL%ef>.dd+6b+.5.msp9.
3nony"ous 3ccess and the SS9F Settin(s

:our of the user rights that are e9plicitly defined in the SSL: scenario in the MSC- are designed to break anonymous access to 33S !eb sites. However1 if you need to allow anonymous access in an SSL: environment you will need to make some important changes to the $J structure and H-$s that are described in Chapters *1 ,1 and E of this guide. Bou will need to create a new $J that is not part of the hierarchy below the Member Servers $J. This $J could be linked directly to the domain root1 or it could be a child $J of some other $J hierarchy. However1 you should not assign user rights in a H-$ that will affect the 33S servers that will be placed in this new $J. Bou can move the 33S servers to the new $J1 create a new H-$1 apply the MSC- settings to it1 and then reconfigure user rights assignments so that they can be controlled by local policy rather than the domain@based H-$. 3n other words1 you should configure the following user rights settings to .ot defined in this new H-$. Access this computer from the network Allow log on locally Cypass traverse checking Log on as a batch 7ob
The 33S features that you need to enable will determine whether you will need to also reconfigure other user rights assignment settings to .ot defined.

The Audit policy settings for 33S servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings ensure that all the relevant security audit information is logged on all 33S servers.
.'6

The user rights assignment settings for 33S servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings ensure that all the relevant security audit information is logged on all 33S servers.
Security Options
The security option settings for 33S servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings ensure that all the relevant security options are uniformly configured on all 33S servers.
vent 9o( Settin(s

The event log settings for 33S servers in the three environments that are defined in this guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings ensure that the appropriate event log settings are uniformly configured on all 33S servers in an organi'ation.

!hen 33S is installed on a computer that runs !indows Server *++, with S-.1 its default setting only allows transmission of static !eb content. !hen !eb sites and applications contain dynamic content or re=uire one or more additional 33S components1 each additional 33S feature must be individually enabled. However1 you should be careful to minimi'e the attack surface of each 33S server in your environment. 3f the !eb sites in your organi'ation are comprised of static content and do not re=uire any other 33S components1 then the default 33S configuration is sufficient to minimi'e the attack surface of the 33S servers. The security settings that are applied through the MSC- provide a great deal of enhanced security for 33S servers. However1 there are a few additional settings that you should consider. The settings in the following sections cannot be implemented through Hroup -olicy and must therefore be performed manually on all 33S servers.
Insta##in( On#y ;ecessary IIS Co"ponents

33S L.+ includes other components and services in addition to the !orld !ide !eb -ublishing Service1 such as the services that are re=uired to provide :T-1 88T-1 and SMT- support. 33S components and services are installed and enabled with the !indows Components !i'ard Application Server that can be launched through Add or Kemove -rograms in Control -anel. After you install 33S1 you will need to enable all 33S components and services that are re=uired by your !eb sites and applications. To install )nternet )nformation Services @))SA D 0 .. 3n Control -anel1 double%click &dd or /emove %ro"rams. *. Click the &dd5/emove Windows Components button to start the !indows Components !i'ard.
.':
,. 3n the Components list1 click &pplication Server1 and then -etails. E. 3n the &pplication Server dialog bo91 under Subcomponents of &pplication Server1 click )nternet )nformation Services @))SA1 and then -etails. 5. 3n the )nternet )nformation Services @))SA dialog bo91 in the Subcomponents of )nternet )nformation Services @))SA list1 do either of the following" To add optional components1 select the check bo9 ne9t to the component that you want to install. To remove optional components1 clear the check bo9 ne9t to the component that you want to remove.
L. Click +K until you return to the !indows Component !i'ard. N. Click .e3t1 and then 0inis'. Bou should only enable essential 33S components and services that are re=uired by !eb sites and applications. 3f you enable unnecessary components and services1 the attack surface of an 33S server increases. The following illustrations and tables show the location and suggested settings for 33S components. The subcomponents in the &pplication Server dialog bo9 are shown in the following figure"
0i"ure : 1 &pplication Server dialo" bo3 wit' list of subcomponents The following table briefly describes the Application Server subcomponents and provides recommendations for when to enable them. Table : 2 /ecommended &pplication Server Subcomponents Settin"s Component name in () Settin" Settin" lo"ic
.';
Application Server Console Disabled
-rovides a Microsoft Management Console /MMC0 snap%in that you can use to administer all the !eb Application Server components. This component is not re=uired on a dedicated 33S server because 33S Server Manager can be used. -rovides support for AS-.8?T applications. ?nable this component when an 33S server runs AS-.8?T applications. Allows an 33S server to host C$MW components for distributed applications. Ke=uired for :T-1 C3TS server e9tension1 !orld !ide !eb Service1 and 33S Manager among others. Allows an 33S server to host applications that participate in network transactions through Distributed Transaction Coordinator /DTC0. Disable this component unless the applications that run on the 33S server re=uire it. -rovides basic !eb and :T- services. This component is re=uired for dedicated 33S servers. .ote" 3f this component is not enabled1 then all subcomponents are disabled.
AS-.8?T
Disabled
?nable network C$MW access
?nabled
?nable network DTC access
Disabled
3nternet 3nformation Services /33S0
?nabled
Message Xueuing
Disabled
Microsoft Message Xueuing /MSMX0 -rovides a message routing1 storage1 and forwarding middleware layer for enterprise !eb applications.
.'-
The subcomponents in the )nternet )nformation Services @))SA dialog bo9 are shown in the following figure"
0i"ure : 2 ))S dialo" bo3 wit' list of subcomponents The following table briefly describes the 33S subcomponents and provides recommendations for when to enable them. Table : 3 /ecommended ))S Subcomponents Settin"s Component name in () Cackground 3ntelligent Transfer Service /C3TS0 server e9tension Settin" Disabled Settin" lo"ic The C3TS server e9tension allows C3TS on the clients to upload files to this server in the background. 3f you have an application on the clients that uses C3TS to upload files to this server1 then enable and configure the C3TS server e9tensionV otherwise1 leave it disabled. 8ote that !indows Jpdate1 Microsoft Jpdate1 SJS1 !SJS1 and Automatic Jpdates do not re=uire this component to run. They re=uire the C3TS client component1 which is not part of 33S. 33S re=uires these files and they must always be enabled on 33S servers. Allows 33S servers to provide :T- services. This service is not re=uired for dedicated 33S servers. -rovides :ront-age support to administer and publish !eb sites. Disable on dedicated 33S servers when no !eb sites use :ront-age e9tensions.
Common :iles :ile Transfer -rotocol /:T-0 Service :ront-age *++* Server ?9tensions
?nabled Disabled
Disabled
.60
Component name in () 3nternet 3nformation Services Manager 3nternet -rinting
Settin" ?nabled Disabled
Settin" lo"ic Administrative interface for 33S. -rovides !eb%based printer management and allows printers to be shared over HTT-. This component is not re=uired on dedicated 33S servers. Distributes1 =ueries1 retrieves1 and posts Jsenet news articles on the 3nternet. This component is not re=uired on dedicated 33S servers. Supports the transfer of electronic mail. This component is not re=uired on dedicated 33S servers. -rovides !eb services1 static1 and dynamic content to clients. This component is re=uired on dedicated 33S servers.
88T- Service
Disabled
SMT- Service
Disabled
!orld !ide !eb Service
?nabled
The subcomponents in the Messa"e Nueuin" dialog bo9 are shown in the following figure"
0i"ure : 3 Messa"e Nueuin" dialo" bo3 wit' list of subcomponents
.6.
The following table briefly describes the Message Xueuing subcomponents and provides recommendations for when to enable them. Table : B /ecommended Messa"e Nueuin" Subcomponents Settin"s Component name in () Active Directory 3ntegration )nstallation Settin" lo"ic option Disabled -rovides integration with the Active Directory( directory service whenever an 33S server belongs to a domain. This component is re=uired when !eb sites and applications that run on 33S servers use Microsoft Message Xueuing /MSMX0. This component is re=uired when !eb sites and applications that run on 33S servers use MSMX. -rovides access to Active Directory and site recognition for downstream clients. This component is re=uired when an 33S server s !eb sites and applications use MSMX. -rovides the ability to send and receive messages over the HTT- transport. This component is re=uired when an 33S server s !eb sites and applications use MSMX. -rovides store%and%forward messaging as well as efficient routing services for MSMX. This component is re=uired when !eb sites and applications that run on 33S servers use MSMX. Associates the arrival of incoming messages at a =ueue with functionality in a C$M component or a stand%alone e9ecutable program.
Common
Disabled
Downlevel Client Support
Disabled
MSMX HTT- Support
Disabled
Kouting support
Disabled
Triggers
Disabled
.62
The subcomponents in the #ac="round )ntelli"ent Transfer Service @#)TSA Server !3tensions dialog bo9 are shown in the following figure"
0i"ure : B #)TS Server !3tensions wit' list of subcomponents The following table briefly describes the C3TS Server ?9tensions subcomponents and provides recommendations for when to enable them. Table : < /ecommended #)TS Server !3tensions Subcomponents Settin"s Component name in () C3TS management console snap%in )nstallation Settin" lo"ic option Disabled 3nstalls an MMC snap%in to administer C3TS. ?nable this component when the C3TS server e9tension for 3nternet Server Application -rogramming 3nterface /3SA-30 is enabled. 3nstalls the C3TS 3SA-3 so that an 33S server can transfer data using C3TS. C3TS Server ?9tensions allow C3TS on the clients to upload files to this server in the background. 3f you have an application on the clients that uses C3TS to upload files to this server1 then enable and configure the C3TS server e9tensionV otherwise leave it disabled. 8ote that !indows Jpdate1 Microsoft Jpdate1 SJS1 !SJS1 and Automatic Jpdates do not re=uire this component to run. They re=uire the C3TS client component1 which is not part of 33S.
C3TS server e9tension 3SA-3
Disabled
.6)
The subcomponents in the World Wide Web Service dialog bo9 are shown in the following figure"
0i"ure : < World Wide Web Service dialo" bo3 wit' list of subcomponents The following table briefly describes the !orld !ide !eb Service subcomponents and provides recommendations for when to enable them. Table : D /ecommended World Wide Web Service Subcomponent Settin"s Component name in () Active Server -ages )nstallation Settin" lo"ic option Disabled -rovides support for AS-. Disable this component when no !eb sites or applications on 33S servers use AS-1 or disable it by using the !eb service e9tensions. :or more information1 see the following S?nabling $nly ?ssential !eb Service ?9tensionsT section in this chapter. -rovides support for dynamic content that is provided through files with .idc e9tensions. Disable this component when no !eb sites or applications that run on 33S servers include files with .idc e9tensions1 or disable it by using the !eb service e9tensions. :or more information1 see the following S?nabling $nly ?ssential !eb Service ?9tensionsT section in this chapter.
3nternet Data Connector
Disabled
.6(
Component name in () Kemote Administration /HTML0
)nstallation Settin" lo"ic option Disabled -rovides an HTML interface to administer 33S. Jse 33S Manager instead to provide easier administration and to reduce the attack surface of an 33S server. This feature is not re=uired on dedicated 33S servers. 3ncludes Microsoft Active2( control and sample pages to host Terminal Services client connections. Jse 33S Manager instead to provide easier administration and to reduce the attack surface of an 33S server. 8ot re=uired on a dedicated 33S server. -rovides support for .shtm1 .shtml1 and .stm files. Disable this component when no !eb sites or applications that run on 33S server use include files with these e9tensions. !ebDA< e9tends the HTT-#... protocol to allow clients to publish1 lock1 and manage resources on the !eb. Disable this component on dedicated 33S servers or disable it by using the !eb service e9tensions. :or more information1 see the following S?nabling $nly ?ssential !eb Service ?9tensionsT section in this chapter. -rovides !eb services1 static1 and dynamic content to clients. This component is re=uired on dedicated 33S servers.
Kemote Desktop !eb Connection
Disabled
Server @ Side 3ncludes
Disabled
!ebDA<
Disabled
!orld !ide !eb Service
?nabled
nab#in( On#y ssentia# Web Service !tensions

Many !eb sites and applications that run on 33S servers have e9tended functionality that goes beyond static pages1 including the ability to generate dynamic content. Any dynamic content that is served or e9tended through features that are provided by an 33S server is accomplished through !eb service e9tensions. ?nhanced security features in 33S L.+ allow individual !eb service e9tensions to be enabled or disabled. As stated earlier1 33S servers will transmit only static content after a new installation. Dynamic content capabilities can be enabled through the !eb Service ?9tensions node in 33S Manager. These e9tensions include AS-.8?T1 SS31 !ebDA<1 and :ront-age Server e9tensions. $ne way to ensure the highest possible compatibility with e9isting applications is to enable all !eb service e9tensions1 but this method also creates a security risk because it increases the attack surface of 33S. Bou should only enable those !eb service e9tensions that are re=uired by the !eb sites and applications that run on 33S servers in your environment. This approach will minimi'e server functionality and reduce the attack surface of each 33S server. To reduce the attack surface of 33S servers as much as possible1 only necessary !eb service e9tensions are enabled on 33S servers in the three environments that are defined in this guide.
.6'
The following table lists predefined !eb service e9tensions1 and provides details on when to enable each e9tension. Table : E !nablin" Web Service !3tensions Web service e3tension Active Server -ages AS-.8?T v....E,** All Jnknown CH3 ?9tensions All Jnknown 3SA-3 ?9tensions !nable e3tension w'en $ne or more !eb sites and applications that run on 33S servers contain AS- content. $ne or more !eb sites and applications that run on 33S servers contain AS-.8?T content. $ne or more !eb sites and applications that run on 33S servers contain unknown CH3 e9tension content. $ne or more !eb sites and applications that run on 33S servers contain unknown 3SA-3 e9tension content. $ne or more !eb sites that run on 33S servers use :ront-age ?9tensions. $ne or more !eb sites and applications that run on 33S servers use 3DC to display database information /this content includes .idc and .id9 files0. $ne or more !eb sites that run on 33S servers use SS3 directives to instruct 33S servers to insert reusable content /for e9ample1 a navigation bar1 a page header or footer0 into different !eb pages. !ebDA< support is re=uired on 33S servers for clients to transparently publish and manage !eb resources.
:ront-age Server ?9tensions *++* 3nternet Data Connector /3DC0
Server Side 3ncludes /SS30
!eb Distributed Authoring and <ersioning /!ebDav0
+#acin( Content on a *edicated *isk ?o#u"e

33S stores files for its default !eb site in the <systemroot>\inetpub\wwwroot folder /where $systemroot% is the drive on which the !indows Server *++, operating system is installed0. 3n the three environments that are defined in this guide1 all files and folders that make up !eb sites and applications are placed on dedicated disk volumes that are separate from the operating system. This approach helps prevent directory traversal attacks in which an attacker sends re=uests for a file that is located outside the directory structure of an 33S server. :or e9ample1 the Cmd.e9e file e9ists in the <systemroot>\System32 folder. An attacker could make a re=uest to the following location" ..Z..Z!indowsZsystemZcmd.e9e in an attempt to invoke the command prompt. 3f the !eb site content is on a separate disk volume1 a directory traversal attack of this type would not work for two reasons. :irst1 permissions on the Cmd.e9e file have been reset as part of the base build of !indows Server *++, with S-. that restricts access to a much more limited group of users. Second1 the Cmd.e9e file would not e9ist on the same disk volume as the !eb root1 and there are currently no known methods to access commands on a different drive with this type of attack.
.66
3n addition to the security%related benefits1 administration tasks such as backup and restore are easier when !eb site and application files and folders are placed on a dedicated disk volume. Also1 use of a separate1 dedicated physical drive can help reduce disk contention on the system volume and improve overall disk access performance.
Settin( ;%FS +er"issions

Computers that run !indows Server *++, with S-. e9amine 8T:S file system permissions to determine the types of access a user or a process has on a specific file or folder. Bou should assign 8T:S permissions to allow or deny access to specific users for !eb sites on 33S servers in the three environments that are defined in this guide. 8T:S permissions affect only the accounts that have been allowed or denied access to the !eb site and application content. Bou should use 8T:S permissions in con7unction with !eb permissions1 not instead of !eb permissions. !eb site permissions affect all users who access the !eb site or application. 3f !eb permissions conflict with 8T:S permissions for a directory or file1 the more restrictive settings are applied. Bou should e9plicitly deny access to anonymous accounts on !eb sites and applications for which anonymous access is not desired. Anonymous access occurs when a user who has no authenticated credentials accesses network resources. Anonymous accounts include the built%in Huest account1 the Guests group1 and 33S Anonymous accounts. Also1 eliminate any write%access permissions to all users e9cept those who are 33S administrators. The following table provides some recommendations about the 8T:S permissions that should be applied to the different file types on an 33S server. The different file types can be grouped in separate folders to simplify the application of 8T:S permissions. Table : F /ecommended .T0S %ermissions Settin"s 0ile type CH3 files /.e9e1 .dll1 .cmd1 .pl0 /ecommended .T0S permissions ?veryone /e9ecute0 Administrators /full control0 System /full control0 Script files /.asp0 ?veryone /e9ecute0 Administrators /full control0 System /full control0 3nclude files /.inc1 .shtm1 .shtml0 ?veryone /e9ecute0 Administrators /full control0 System /full control0 Static content /.t9t1 .gif1 .7pg1 .htm1 .html0 ?veryone /read%only0 Administrators /full control0 System /full control0
Settin( IIS Web Site +er"issions

33S e9amines !eb site permissions to determine the types of action that can occur within a !eb site1 such as script source access or directory browsing. Bou should assign !eb
.6:
site permissions to provide additional security for !eb sites on 33S servers in the three environments that are defined in this guide. !eb site permissions can be used in con7unction with 8T:S permissions1 and can be configured for specific sites1 directories1 and files. Jnlike 8T:S permissions1 !eb site permissions affect everyone who tries to access a !eb site that runs on an 33S server. !eb site permissions can be applied with the MMC 33S Manager snap%in. The following table lists the !eb site permissions that are supported by 33S L.+1 and provides brief e9planations of when to assign any given permission to a !eb site. Table : : ))S D 0 Web Site %ermissions Web site permission %ermission "ranted Kead !rite Script Source Access Jsers can view the content and properties of directories or files. This permission is selected by default. Jsers can change content and properties of directories or files. Jsers can access source files. 3f Kead is enabled1 then the source can be readV if !rite is enabled1 then the script source code can be changed. Script Source Access includes the source code for scripts. 3f neither Kead nor !rite is enabled1 this option is not available. )mportant" !hen Script Source Access is enabled1 users may be able to view sensitive information1 such as a user name and password. They may also be able to change source code that runs on an 33S server and seriously affect the server s security and performance. Directory browsing Log visits 3nde9 this resource ?9ecute Jsers can view file lists and collections. A log entry is created for each visit to the !eb site. Allows the )nde3in" Service to inde9 resources1 which allows searches to be performed on resources. The following options determine the level of script e9ecution for users" .one. Does not allow scripts e9ecutables to run on the server. Scripts only. Allows only scripts to run on the server. Scripts and !3ecutables. Allows both scripts and e9ecutables to run on the server.
Con&i(urin( IIS 9o((in(

Microsoft recommends that 33S logging be enabled on 33S servers in the three environments that are defined in this guide. Separate logs can be created for each !eb site or application. 33S logs more information than the event logs and performance monitoring features that are provided by the !indows operating system. The 33S logs can include information such as who has visited a site1 what the visitor viewed1 and when the information was last viewed. 33S logs can be used to assess content popularity1 identify information bottlenecks1 or as resources to help investigate attacks.
.6;
The MMC 33S Manager snap%in can be used to configure the log file format1 the log schedule1 and the e9act information to be logged. To limit the si'e of the logs1 you should use a careful planning process to determine which fields to log. !hen 33S logging is enabled1 33S uses the !,C ?9tended Log :ile :ormat to create daily activity logs in the directory that is specified for the !eb site in 33S Manager. To improve server performance1 you should store logs on a non%system striped or striped#mirrored disk volume. Logs can also be written to a remote share over a network by using a full1 Jniversal 8aming Convention /J8C0 path. Kemote logging allows administrators to set up centrali'ed log file storage and backup. However1 server performance could be negatively affected when log files are written over the network. 33S logging can be configured to use several other ASC33 or $pen Database Connectivity /$DCC0 log file formats. $DCC logs can store activity information in a SXL database. However1 note that when $DCC logging is enabled1 33S disables the kernel%mode cache1 which can degrade overall server performance. 33S servers that host hundreds of sites can enable centrali'ed binary logging to improve logging performance. Centrali'ed binary logging enables all !eb sites on an 33S server to write activity information to a single log file. This method can greatly increase the manageability and scalability of the 33S logging process because it reduces the number of logs that need to be individually stored and analy'ed. :or more information about centrali'ed binary logging1 see the 33S Centrali'ed Cinary Logging /33SL.+0 page at www.microsoft.com#technet#prodtechnol# !indowsServer*++,#Library#33S#.,aEc+b5%L>Lb%ENLL%>N*6%a,E+*da>,5f..msp9. !hen 33S logs are stored on 33S servers1 only server administrators have permission to access them by default. 3f a log file directory or file owner is not in the 2ocal &dministrators group1 the HTT-.sys file /the kernel%mode driver in 33S L.+0 publishes an error to the 8T event log. This error indicates that the owner of the directory or file is not in the 2ocal &dministrators group1 and that logging has been suspended for that site until the owner is added to the 2ocal &dministrators group1 or the e9isting directory or log file is deleted.

Most user rights assignments that are applied through the MSC- have the proper security groups specified in the security templates that accompany this guide. However1 there are a few accounts and security groups that cannot be included in the templates because their security identifiers /S3Ds0 are specific to individual !indows *++, domains. Jser rights assignments that must be configured manually are specified in the following table.
Warning$ The followin& table contains values for the built-in Administrator account. 7o not confuse the Administrator account with the built-in 0d inistrators securit" &roup. 6f "ou add the 0d inistrators securit" &roup to an" of the listed den" access user ri&hts# "ou will need to lo& on locall" to correct the mistake. Also# "ou ma" have renamed the built-in Administrator account in accordance with the recommendation in Chapter (# HThe Member +erver 9aseline 8olic".H 3hen "ou add the Administrator account to an" user ri&hts# ensure that the renamed account is specified.
.6-
Table : 10 Manually &dded (ser /i"'ts &ssi"nments Member server default Deny access to this computer from the network 2e"acy Client !nterprise Client Speciali1ed Security 7 2imited 0unctionality
Cuilt%in Cuilt%in Cuilt%in AdministratorV AdministratorV AdministratorV SupportP,>>6E5a+V SupportP,>>6E5a+V SupportP,>>6E5a+V HuestV all 8$8% HuestV all 8$8% HuestV all 8$8% $perating System $perating System $perating System service accounts service accounts service accounts
I portant: KAll non-operatin& s"stem service accountsL includes service accounts that are used for specific applications across an enterprise# but does 1T include !1CA! +J+T2M# !1CA! +24C6C2 or the 2T314< +24C6C2 accounts @the built-in accounts that the operatin& s"stem usesA.

!indows Server *++, has a number of built%in user accounts that cannot be deleted but can be renamed. Two of the most well%known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 you should rename the built%in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in Administrator account to determine its true name and then break into the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name. To secure well =nown accounts on ))S servers Kename the Administrator and Huest accounts1 and change their passwords to long and comple9 values on every domain and server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all others. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes you make in a secure location.
3ote$ Jou can rename the built-in administrator account throu&h 5roup 8olic". This settin& was not implemented in an" of the securit" templates that are provided with this &uide because ever" or&ani>ation should choose a uni=ue name for this account. *owever# "ou can confi&ure the 0ccounts: +ena e ad inistrator account settin& to rename administrator accounts in the three environments that are defined in this &uide. This polic" settin& is a part of the +ecurit" 1ptions settin&s of a 581.
.:0


To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a server policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should use on hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. To create t'e ))S server policy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain1 which will apply all security settings from parent $Js. E. 3nstall and configure only the mandatory applications that will be on every server that shares this role. ?9amples include role%specific services1 software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. L. ?nsure that the detected server roles are appropriate for your environmentIfor e9ample the Application server and !eb server roles. N. ?nsure that the detected client features are appropriate for your environment. >. ?nsure that the detected administrative options are appropriate for your environment. 6. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. .+. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. ... ?nsure the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall.
.:.
.*. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .,. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .E. 3nclude the appropriate security template /for e9ample1 ?C%33S Server.inf0. .5. Save the policy with an appropriate name /for e9ample1 33S Server.9ml0.
3ote$ The M+98 disables several other 66+-related services# includin& ,T8# +MT8# and T8. The 3eb +erver polic" must be modified if an" of these services are to be enabled on 66+ servers in an" of the three environments that are defined in this &uide.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more details about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\IIS Ser#er !ml" /g:"IIS Policy"
.:2
Su""ary
This chapter e9plained the policy settings that can be used to harden 33S servers that run !indows Server *++, with S-. in the three environments that are defined in this guide. Most of the settings are applied through a Hroup -olicy ob7ect /H-$0 that was designed to complement the MSC-. H-$s can be linked to the appropriate organi'ational units /$Js0 that contain the 33S servers to provide additional security. Some of the settings that were discussed cannot be applied through Hroup -olicy. :or these settings1 manual configuration details were provided.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening 33S@based !eb servers that run !indows Server *++, with S-.. :or information about how to enable logging in 33S1 see the Microsoft Fnowledge Case article GHow to enable logging in 3nternet 3nformation Services /33S0G at http"##support.microsoft.com#?kbid4,.,E,N. Additional information about logging is available on the ?nable Logging /33S L.+0 page at www.microsoft.com#technet#prodtechnol#!indowsServer*++,#Library#33S# d*6*+Ne>%5*NE%EfEb%6a++%6E,,bN,*5*dL.msp9. :or information about how to log site activity1 see the Logging Site Activity /33S L.+0 page at www.microsoft.com#technet#prodtechnol#!indowsServer*++,#Library# 33S#abNeE+N+%e.>5%E..+%b*b.%.bcacEb.L>e+.msp9. :or information about e9tended logging1 see the Customi'ing !,C ?9tended Logging /33S L.+0 page at www.microsoft.com#technet#prodtechnol#!indowsServer*++,#Library# 33S#6Laf*.Lb%e*c+%E*>e%6>>+%65cbd>5d6+a..msp9. :or information about centrali'ed binary logging1 see the Centrali'ed Cinary Logging in 33S L.+ /33S L.+0 page on Microsoft.com at www.microsoft.com#technet#prodtechnol# !indowsServer*++,#Library#33S#b6cdc+NL%E+,d%EL,e%6a,L%5a.E>..d,EcN.msp9. :or information about remote logging1 see the Kemote Logging /33S L.+0 page at www.microsoft.com#technet#prodtechnol#!indowsServer*++,#Library#33S# aL,ENae,%,6d.%EE,E%6Nc6%5N5Le5>L*cL..msp9. :or additional information about 33S L.+1 see the 3nternet 3nformation Services page at www.microsoft.com#!indowsServer*++,#iis#default.msp9.
Chapter 10: %he I3S Server $o#e

Overview
This chapter provides recommendations and resources that will help you harden 3nternet Authentication Service /3AS0 servers in your environment that run Microsoft !indows Server *++, with S-.. 3AS is the Microsoft implementation of a Kemote Authentication Dial%in Jser Service /KAD3JS0 server and pro9y that enables centrali'ed management of user authentication1 authori'ation1 and accounting. 3AS can be used to authenticate users in databases on !indows Server *++,1 !indows 8T( E.+1 or !indows *+++ domain controllers. 3AS also supports a variety of network access servers /8AS01 including Kouting and Kemote Access /KKAS0. The KAD3JS hiding mechanism uses the KAD3JS shared secret1 the Ke=uest Authenticator1 and the MD5 hashing algorithm to encrypt the Jser%-assword and other attributes1 such as Tunnel%-assword and MS%CHA-%M--?%Feys. K:C *>L5 notes the potential need to evaluate the threat environment and to determine whether additional security should be used. The settings in this chapter are configured and applied through Hroup -olicy. A Hroup -olicy ob7ect /H-$0 that complements the Member Server Caseline -olicy /MSC-0 can be linked to the appropriate organi'ational units /$Js0 that contain the 3AS servers to provide the re=uired security setting changes for this server role. This chapter only discusses those policy settings that vary from the MSC-. !here possible1 these settings are gathered in an incremental Hroup -olicy template that will be applied to the 3AS Servers $J. Some of the settings in this chapter cannot be applied through Hroup -olicy. Detailed information about how to configure these settings manually is provided. The name of the infrastructure server security template for the ?C environment is ?C% 3nfrastructure Server.inf. This template provides the settings for the incremental 3AS Server template1 which in turn is used to create a new H-$ that is linked to the 3AS Servers $J. Step%by%step instructions are provided in Chapter *1 G!indows Server *++, Hardening MechanismsG to help you create the $Js and Hroup -olicies and then import the appropriate security template into each H-$. :or information about settings in the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.T :or information on all default setting configurations1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-* which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
3ote$ The settin& prescriptions for the 6A+ server role were tested for the 2nterprise Client environment onl". ,or this reason# the 7o+ attack information specified for the ma?orit" of the other server roles in this &uide is not included here.
3udit +o#icy
Audit policy settings for 3AS servers in the ?C environment are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 SThe Member Server
.:(
Caseline -olicy.G The MSC- settings ensure that all the relevant security audit information is logged on all 3AS servers in an organi'ation.

Jser rights assignments for 3AS servers in the ?C environment are also configured through the MSC-. :or more information about the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.G The MSC- settings ensure that appropriate access to 3AS servers is uniformly configured throughout an organi'ation.
Security Options
The security options settings for 3AS servers in the ?C environment are also configured through the MSC-. :or more information about the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.G The MSC- settings ensure that appropriate access to 3AS servers is uniformly configured across an enterprise.
vent 9o(
The event log settings for 3AS servers in the ?C environment are also configured through the MSC-. :or more information about the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.G

Although the security settings that are applied through the MSC- significantly enhance the security of 3AS servers1 this section discusses some additional considerations. However1 the settings in this section cannot be applied through Hroup -olicy1 and must therefore be performed manually on all 3AS servers.

!indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted1 but can be renamed. Two of the most well known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 the built%in Administrator account should be renamed and the description altered to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in Administrator account to determine its true name and then break into the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name.
Chapter .0$ The 6A+ +erver 4ole
.:'
To secure well*=nown accounts on )&S servers Kename the Administrator and Huest accounts1 and change their passwords to long and comple9 values on every domain and server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all others. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes that you make in a secure location.
3ote$ The built-in Administrator account can be renamed throu&h 5roup 8olic". This polic" settin& was not implemented in an" of the securit" templates that are provided with this &uide because ever" environment should choose a uni=ue name for this account. *owever# the 0ccounts: +ena e ad inistrator account settin& can be confi&ured to rename administrator accounts in the 2C environment. This polic" settin& is a part of the +ecurit" 1ptions settin&s section of a 581.


To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a server policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 the installation should be on hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. During the server policy creation steps you will probably remove the :ile server role from the list of detected roles. This role is commonly configured on servers that do not re=uire it and could be considered a security risk. To enable the :ile server role for servers that re=uire it1 you can apply a second policy later in this process. To create t'e )&S server policy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain1 which will apply all security settings from parent $Js.
.:6
E. 3nstall and configure only the mandatory applications that will be on every server that shares this role. ?9amples include role%specific services1 software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. L. ?nsure that the detected server roles are appropriate for your environment1 for e9ample the )&S server @/&-)(SA role. N. ?nsure that the detected client features are appropriate for your environment. >. ?nsure that the detected administrative options are appropriate for your environment. 6. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. .+. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. ... ?nsure the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall. .*. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .,. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .E. 3nclude the appropriate security template /for e9ample1 ?C%3AS Server.inf0. .5. Save the policy with an appropriate name /for e9ample1 3AS Server.9ml0.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s.
Chapter .0$ The 6A+ +erver 4ole
.::
:or more information about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\I'S Ser#er !ml" /g:"I'S Policy"
*. Jse the Hroup -olicy Management Console to link the newly created H-$ to the appropriate $J. 8ote that if the SC! security policy file contains !indows :irewall settings1 !indows :irewall must be active on the local computer for this procedure to complete successfully. To verify that !indows :irewall is active1 open Control -anel and then double%click !indows :irewall. Bou should now perform a final test to ensure that the H-$ applies the desired settings. To complete this procedure1 confirm that the appropriate settings wee made and that functionality is not affected.
Su""ary
This chapter e9plained the settings that can be used to harden 3AS servers that run !indows Server *++, with S-. in the ?nterprise Client environment that is defined in this guide. These settings may also work in the other environments defined in this guide1 but they have not been tested or validated. The settings were configured and applied through a Hroup -olicy ob7ect /H-$0 that was designed to complement the MSC-. H-$s can be linked to the appropriate organi'ational units /$Js0 that contain the 3AS servers in your organi'ation to provide additional security.
.:;
)ore In&or"ation
The following links provide additional information about topics that relate to hardening 3AS servers that run !indows Server *++, with S-.. :or more information about 3AS1 see the Jnderstanding 3AS page at http"##technet*.microsoft.com#!indowsServer#en#Library#abEeeeb*%b+aa%EbEa%a656% ,6+*b*b,f.af.+,,.msp9. :or more information about 3AS and security1 see the 3nternet Authentication Service page at http"##technet*.microsoft.com#!indowsServer#en#Library#d6>eb6.E%*5>c% Ef+b%ad+E%dcEdb6eEeeL,.+,,.msp9. :or information about 3AS1 firewalls1 and !indows Server *++,1 see the 3AS and firewalls page at www.microsoft.com#technet#prodtechnol#windowsserver*++,#library# ServerHelp#5.>eN+a6%6eNa%E**b%a.,f%f,.6,dEfd*.5.msp9. :or more information about KAD3JS1 see the K:C memo GKAD3JS AccountingG at www.ietf.org#rfc#rfc*>LL.t9t.
Chapter 11: %he Certi&icate Services Server $o#e

Overview
This chapter provides guidance that will help you harden servers that run Microsoft( !indows Server) *++, with Service -ack . /S-.0 and Microsoft Certificate Services in your environment. Although this chapter includes all of the information you need to secure these types of servers1 it does not provide any details about how to create a secure Certificate Services infrastructure in your environment or how to deploy a certification authority /CA0. These topics are discussed in detail in the !indows Server *++, product documentation. They are also discussed in the Windows Server 2003 Resource Kit and in white papers that are available on the Microsoft !eb site. Additional information can be found in a companion guide" Securing !ireless LA8s with Certificate Services1 which is available at http"##go.microsoft.com#fwlink#?Link3d4.E>E,. The settings in this chapter are configured and applied through Hroup -olicy. A Hroup -olicy ob7ect /H-$0 that complements the Member Server Caseline -olicy /MSC-0 can be linked to the appropriate organi'ational units /$Js0 that contain the CA servers to provide the re=uired security setting changes for this server role. This chapter only discusses those policy settings that vary from the MSC-. !here possible1 these settings are gathered in an incremental Hroup -olicy template that will be applied to the CA Servers $J. Some of the settings in this chapter cannot be applied through Hroup -olicy. Detailed information about how to configure these settings manually is provided. The name of the CA Server security template for the ?C environment is ?C%CA Server.inf. This is the incremental CA Server template1 which is used to create a new H-$ that is linked to the CA Servers $J in the appropriate environment. Step%by%step instructions are provided in Chapter *1 G!indows Server *++, Hardening MechanismsG to help you create the $Js and Hroup -olicies and then import the appropriate security template into each H-$. :or information about settings in the MSC-1 see Chapter E1 SThe Member Server Caseline -olicy.T :or information on all default settings1 see the companion guide1 Threats and Countermeasures" Security Settings in !indows Server *++, and !indows 2-* which is available at http"##go.microsoft.com#fwlink#?Link3d4.5.56.
3ote$ The polic" settin& recommendations for the Certificate +ervices server role were tested for the 2nterprise Client environment onl". ,or this reason# the denial of service @7o+A information that was specified for most of the other server roles in this &uide is not included in this chapter.
Bou might install Microsoft 3nternet 3nformation Services /33S0 on some of the Certificate Services servers in your environment so that these servers can distribute CA certificates and certificate revocation lists /CKLs0. 33S is also used to host the Certificate Services server !eb enrollment pages1 which allow non%Microsoft !indows( clients to enroll certificates. Cefore you act on the information in this chapter1 make sure you understand how to securely install 33S1 which is described in Chapter 61 GThe !eb Server KoleG in this
.;0
guide. 3f you install 33S on your CAs1 the security configuration template that was developed for Chapter 6 must be applied to your Certificate Services servers before you configure the prescribed settings that are described in this chapter.
3ote$ 6n simplified environments# the issuin& CA server can be used to host the 3eb server# the CA certificate# and the C4! download points. *owever# "ou should consider usin& a separate 3eb server in "our own environment to improve the securit" of "our CAs.
33S is used to host the certificate server enrollment pages and to distribute CA certificates and CKL download points for non%!indows clients. Microsoft recommends that you not install 33S on the root CA server. 3f possible1 you should not run 33S on your issuing CA and any intermediate CAs in your environment. 3t is more secure to host the !eb download points for CA certificates and CKLs on a different server than the CA server itself. Many certificate users /internal and e9ternal0 who need to retrieve CKLs or CA chain information should not necessarily be permitted access to the CA. However1 you cannot isolate users from the CA if you host the download points on it.

Audit policy settings for Certificate Services servers in the ?nterprise Client environment guide are configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings ensure that all the relevant security audit information is logged on all Certificate Services servers.

Jser rights assignment settings for Certificate Services servers in the ?nterprise Client environment are also configured through the MSC-. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The MSC- settings ensure that appropriate access to Certificate Services servers is uniformly configured across an enterprise.
Security Options
The Security $ptions section of Hroup -olicy is used to enable or disable security settings for computers1 such as digital signing of data1 Administrator and Huest account names1 floppy disk drive and CD%K$M drive access1 driver installation behavior1 and logon prompts. Bou can configure the security options settings in !indows Server *++, at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\Windows Settin"s\Security Settin"s\ 2ocal %olicies\Security +ptions The following table includes the recommended security options setting for the Certificate Services server role in the ?nterprise Client environment. Detailed information about the setting is provided in the te9t that follows the table. Table 11 1 /ecommended Security +ptions Settin"s Settin" System cryptography" Jse :3-S compliant algorithms for encryption1 hashing1 and signing !nterprise Client ?nabled
Chapter ..$ The Certificate +ervices +erver 4ole
.;.
Syste" crypto(raphy: 7se FI+S co"p#iant a#(orith"s &or encryption8 hashin(8 and si(nin(
This policy setting determines whether the Transport Layer Security#Secure Sockets Layer /TLS#SSL0 Security -rovider supports only the TLSPKSAP!3THP,D?SP?D?PCCCPSHA cipher suite. 3n effect1 support for this cipher suite means that the provider only supports the TLS protocol as a client and a server /if applicable0. The TLS#SSL Security -rovider uses the following algorithms" The Triple Data ?ncryption Standard /,D?S0 encryption algorithm for the TLS traffic encryption. The Kivest1 Shamir1 and Adelman /KSA0 public key algorithm for the TLS key e9change and authentication. /KSA is a public%key encryption technology that was developed by KSA Data Security1 3nc.0 The SHA%. hashing algorithm for the TLS hashing re=uirements.
:or the ?ncrypting :ile System Service /?:S01 the TLS#SSL Security -rovider supports only the Triple D?S encryption algorithm to encrypt file data that is stored in the !indows 8T:S file system. Cy default1 in !indows *+++ and !indows 2- with no service packs1 ?:S uses the D?S2 algorithm to encrypt file data1 however in !indows 2- S-. and later1 and !indows Server *++,1 the default algorithm is Advanced ?ncryption Standard /A?S0 using a *5L%bit key. 3f you enable this policy setting1 computers that fulfill this server role in your environment will use the most powerful algorithms that are available for digital encryption1 hashing1 and signing. Jse of these algorithms minimi'es risk because they limit the ability of an unauthori'ed user to compromise digitally encrypted or signed data. :or these reasons1 the System crypto"rap'y> (se 0)%S compliant al"orit'ms for encryptionC 'as'in"C and si"nin" setting is configured to !nabled for the ?nterprise Client environment.
3ote$ Client computers that have this polic" settin& enabled will be unable to communicate throu&h di&itall" encr"pted or si&ned protocols with servers that do not support these al&orithms. etwork client computers that do not support these al&orithms will not be able to use servers that re=uire the al&orithms for network communications. ,or e0ample# man" ApacheDbased 3eb servers are not confi&ured to support T!+. 6f "ou enable this settin& "ou must also confi&ure 6nternet 20plorer to use T!+. To do so# open the Internet 4ptions dialo& bo0 from the 6nternet 20plorer !oo$s menu# click the 0dvanced tab on the Internet 4ptions dialo& bo0# scroll towards the bottom of the Settings list# and then click the 8se !9S 1.0 checkbo0. 6t is also possible to confi&ure this functionalit" throu&h 5roup 8olic" or with the 6nternet 20plorer Administrators <it.
vent 9o( Settin(s

The event log settings for Certificate Services servers in the ?nterprise Client environment are configured through the MSC-. :or more information on the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G
3dditiona# $e(istry
ntries
Additional registry entries were created for the ?C%CA Server.inf template file. These entries are not defined within the Administrative Template /.adm0 files for the ?nterprise
.;2
Client environment as defined in this guide. The .adm files define the system policies and restrictions for the desktop1 shell1 and security settings for !indows Server *++, with S-.. The additional registry entries are configured within the security template to automate their implementation. 3f the 3ncremental Certificate Services Hroup -olicy for this environment is removed1 its settings are not automatically removed and must be manually changed with a registry editing tool such as Kegedt,*.e9e. Bou can configure the registry entries in !indows Server *++, at the following location within the Hroup -olicy $b7ect ?ditor" M&C?).!\SHST!M\CurrentControlSet\Services\CertSvc\Confi"uration

The following ACLs are suggested and can be assigned through Hroup -olicy. However1 these ACLs are not included in the security templates that are provided with this guide because the path for the database and logs will differ from server to server. :or e9ample1 your Certificate Servers server could have a C"Z1 D"Z1 and ?"Z drive. Details about how to manually implement these policy settings are provided in the following section.
Fi#e Syste" 3C9s

:iles that are not protected by access control lists /ACLs0 can be easily viewed1 changed1 or deleted by unauthori'ed users who can access them locally or over the network. Although ACLs can help protect files1 encryption provides much more protection and is a viable option for files that only need to be accessible to a single user. The following table includes the file system ACLs for !indows Server *++,@based Certificate Services servers in the ?nterprise Client environment. 3n this environment1 the Certificate Services servers use ->\CertSrv as the certificate database directory and the database logs are stored in the default folder $System/oot$\system32\Cert2o". 3t is also possible to move the logs from the system drive to a physically separate mirrored drive1 such as !>\Cert2o". Security considerations do not re=uire separation of the database and logs onto different physical disk drives1 but this configuration is recommended for added protection from disk failures and to improve performance. The Certificate Services default installation folders $System/oot$\system32\Cert2o" and $System/oot$\system32\CertSrv have the correct ACLs by default1 which are shown in the following table. Table 11 2 0ile System &C2s &C2 pat' in () [SystemKoot[Zsystem,*ZCertLog /propagate to all subfolders0 [SystemKoot[Zsystem,*ZCertSrv /propagate to all subfolders0 !nterprise Client Administrators /:ull Control0 SBST?M /:ull Control0 Administrators /:ull Control0 SBST?M /:ull Control0 Jsers /Kead and ?9ecute1 List :older Contents1 and Kead0 D"ZCertLog Administrators /:ull Control0 SBST?M /:ull Control0
.;)
&C2 pat' in () D"ZCertSrv
!nterprise Client Administrators /:ull Control0 SBST?M /:ull Control0 Jsers /Kead and ?9ecute1 List :older Contents1 and Kead0
Cecause of the security%sensitive nature of CAs1 file auditing is enabled on the Certificate Services folders that are listed in the preceding table. The audit entries are configured as shown in the following table" Table 11 3 Certificate Services 0ile and /e"istry &udit Confi"uration 0ile pat' or re"istry pat' &udit type &udit settin" ?veryone /:ull Control0 ?veryone /Modify0 ?veryone /Modify0 ?veryone /Modify0
[SystemKoot[Zsystem,*ZCertLog :ail [SystemKoot[Zsystem,*ZCertSrv Success D"ZCertSrv D"ZCertLog Success Success
These policy settings will audit any type of failure access /read or modify0 from any user and also audit any successful modification by any user.

!indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted1 but can be renamed. Two of the most well known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 the built%in Administrator account should be renamed and the description altered to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in Administrator account to determine its true name and then break into the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name. To secure well*=nown accounts on C& servers Kename the Administrator and Huest accounts1 and change their passwords to long and comple9 values on every domain and server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all domains and servers1 an attacker who gains access to one member server will be able to gain access to all others.
.;(
Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord these changes in a secure location.
3ote$ Jou can rename the built-in Administrator account throu&h 5roup 8olic". This polic" settin& was not implemented in an" of the securit" templates that are provided with this &uide because ever" or&ani>ation should choose a uni=ue name for this account. *owever# "ou can confi&ure the 0ccounts: +ena e ad inistrator account settin& to rename the Administrator account in the 2C environment. This polic" settin& is a part of the +ecurit" 1ptions settin&s of a 581.


To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a server policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should use hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. During the server policy creation steps you will probably remove the :ile server role from the list of detected roles. This role is commonly configured on servers that do not re=uire it and could be considered a security risk. To enable the :ile server role for servers that re=uire it1 you can apply a second policy later in this process. To create t'e Certificate Services server policy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. Roin the computer to the domain1 which will apply all security settings from parent $Js. E. 3nstall and configure only the mandatory applications that will be on every server that shares this role. ?9amples include role%specific services1 software and management agents1 tape backup agents1 and antivirus or antispyware utilities. 5. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. L. ?nsure that the detected server roles are appropriate for your environmentIfor e9ample the Certificate Services role.
.;'
N. ?nsure that the detected client features are appropriate for your environment. >. ?nsure that the detected administrative options are appropriate for your environment. 6. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected. .+. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. ... ?nsure the S=ip t'is section checkbo9 is unchecked in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall. .*. 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .,. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .E. 3nclude the appropriate security template /for e9ample1 ?C%CA Server.inf0. .5. Save the policy with an appropriate name /for e9ample1 Certificate Services.9ml0.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Two options are available to test the policy. Bou can use the native SC! deployment facilities1 or deploy the policies through a H-$. !hen you start to author your policies1 you should consider using the native SC! deployment facilities. Bou can use SC! to push a policy to a single server at a time1 or use Scwcmd to push the policy to a group of servers. The native deployment method allows you to easily roll back deployed policies from within SC!. This capability can be very useful when you make multiple changes to your policies during the test process. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more details about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.
.;6

After you thoroughly test the policy1 complete the following steps to convert it into a H-$ and deploy it" .. At the command prompt1 type the following command" scwcmd transform /p:<PathToPolicy.xml> /g:<GPODisplayName> and then press ?8T?K. :or e9ample" scwcmd transform /p:"C:\Windows\Security\msscw\Policies\Certificate Ser#ices !ml" /g:"Certificate Ser#ices Policy"
Su""ary
This chapter e9plained the policy settings that can be used to harden Certificate Services servers that run !indows Server *++, with S-. in the ?nterprise Client environment as defined in this guide. The settings are configured and applied through a Hroup -olicy ob7ect /H-$0 that complements the MSC-. H-$s can be linked to the appropriate organi'ational units /$Js0 that contain the Certificate Services servers to provide additional security.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening servers that run !indows Server *++, with S-. and Certificate Services. :or a good introduction to public key infrastructure /-F30 concepts and the features of !indows *+++ certificate services1 see GAn 3ntroduction to the !indows *+++ -ublic Fey 3nfrastructureG at www.microsoft.com#technet#archive#windows*+++serv# evaluate#featfunc#pkiintro.msp9. :or more detailed information about -F3 functionality in !indows Server *++, and !indows 2-1 see G-F3 ?nhancements in !indows 2- -rofessional and !indows Server *++,G at www.microsoft.com#technet#prodtechnol#win9ppro#plan#pkienh.msp9. :or more background information about key -F3 concepts1 see the -ublic Fey 3nfrastructure page at http"##technet*.microsoft.com#!indowsServer#en#Library#,*aacfe>%>,af%ELNL%aE5c% N5E>,5E5a6N>.+,,.msp9.
Chapter 12: %he -astion 'ost $o#e

Overview
This chapter focuses on how to harden bastion hosts that run Microsoft( !indows Server) *++, with Service -ack . /S-.0 in your environment. Castion hosts are secure but publicly accessible computers that are located on the public%facing side of an organi'ation;s perimeter network /also known as DMM1 demilitari'ed 'one1 and screened subnet0. Castion hosts are unprotected by a firewall or filtering router1 which makes them fully e9posed to attack. To minimi'e the possibility of compromise1 bastion hosts need to be carefully designed and configured. Castion hosts are commonly used as !eb servers1 D8S servers1 :ile Transfer -rotocol /:T-0 servers1 Simple Mail Transfer -rotocol /SMT-0 servers1 and 8etwork 8ews Transfer -rotocol /88T-0 servers. 3deally1 bastion hosts are dedicated to 7ust one of these functions1 because the more functions that a server provides the greater the likelihood that a security hole will be overlooked. 3t is easier to secure a single service on a single bastion host than it is to secure multiple services. $rgani'ations that can afford multiple bastion hosts can greatly benefit from this type of network architecture. Secure bastion hosts are configured very differently from typical hosts. All unnecessary services1 protocols1 programs1 and network interfaces are disabled or removed1 and then each bastion host is configured to fulfill a specific role. 3f you use this method to harden bastion hosts you can limit potential methods of attack. The following sections of this chapter describe various security settings that will help secure bastion hosts in any environment. The steps that are included in this chapter will help you create an SMT- bastion host. Bou will need to modify the configuration files that are included with the guide to add any additional functionality.
-astion 'ost 9oca# +o#icy

The server roles that are described earlier in this guide used Hroup -olicy to configure servers. Hroup -olicy cannot be applied to bastion host servers because they are configured as stand%alone hosts that do not belong to an Active Directory( directory service domain. Cecause they are e9posed and not protected by other devices1 only one level of guidance is prescribed for bastion host servers in the three environments that are defined in this guide. The security settings that are described in this chapter are based on the Member Server Caseline -olicy /MSC-0 for the SSL: environment that is defined in Chapter E1 GThe Member Server Caseline -olicy.G The settings are included in a security template that must be applied to the Castion Host Local -olicy /CHL-0 of each bastion host. Table 12 1 #astion ?ost Server Security Templates 2e"acy Client SSL:%Castion Host.inf !nterprise Client SSL:%Castion Host.inf Speciali1ed Security 7 2imited 0unctionality SSL:%Castion Host.inf
.;;

The CHL- Audit policy settings for bastion hosts are included in the SSL:%Castion Host.inf file. These settings are the same as those specified in the SSL:%Member Server Caseline.inf file. :or more information about the MSC-1 see Chapter E1 GThe Member Server Caseline -olicy.G The CHL- settings ensure that all relevant security audit information is logged on all bastion host servers.

The SSL:%Castion Host.inf file includes the CHL- user rights assignments for bastion hosts. These policy settings are based on those that are specified in the SSL:%Member Server Caseline.inf file in Chapter E1 GThe Member Server Caseline -olicy.G The information in the following table summari'es the differences between the CHL- and the MSC-. Detailed information is provided in the te9t that follows the table. Table 12 2 /ecommended (ser /i"'ts &ssi"nments Settin" (ser /i"'ts assi"nment Deny access to this computer from the network Settin" A8$8$BM$JS L$H$8V Cuilt%in AdministratorV SupportP,>>6E5a+V HuestV all 8$8%$perating System service accounts
*eny access to this co"puter &ro" the network

3ote$ A 1 1JM1/+ !151 # 9uilt-in Administrator# +upportM);;-('a0# 5uest# and all 1 operatin& s"stem service accounts are not included in the securit" template. These accounts and &roups have uni=ue securit" identifier @+67sA. Therefore# "ou need to add them manuall" to the 9*!8.
This policy setting determines which users cannot access a computer over the network. 3t denies a number of network protocols1 including server message block /SMC0%based protocols1 8etC3$S1 Common 3nternet :ile System /C3:S01 HTT-1 and Component $b7ect Model -lus /C$MW0. This policy setting overrides the &ccess t'is computer from t'e networ= setting when a user account is sub7ect to both policies. 3f you configure this user right for other groups1 you could limit the ability of users to perform delegated administrative tasks in your environment. 3n Chapter E1 GThe Member Server Caseline -olicy1G this guide recommends that you include the Guests group in the list of users and groups that are assigned this user right to provide the highest possible level of security possible. However1 the 3JSK account that is used for anonymous access to 33S is a member of the Guests group by default. The -eny access to t'is computer from t'e networ= setting is configured to include A8$8$BM$JS L$H$81 Cuilt%in Administrator1 SupportP,>>6E5a+1 Huest1 and all 8$8%$perating System service accounts for bastion hosts in the SSL: environment that is defined in this guide.
Security Options
The CHL- security options settings for bastion hosts are the same as those specified in the SSL:%Member Server Caseline.inf file in Chapter E1 GThe Member Server Caseline
Chapter .2$ The 9astion *ost 4ole
.;-
-olicy.G These CHL- settings ensure that all relevant security options are uniformly configured on all bastion host servers.
vent 9o( Settin(s

The CHL- event log settings for bastion hosts are the same as those specified in the SSL:%Member Server Caseline.inf file in Chapter E1 GThe Member Server Caseline -olicy.G These CHL- settings ensure that all relevant event log settings are uniformly configured on all bastion host servers.

The security settings that the CHL- applies significantly enhance the security of bastion host servers. However1 there are a few additional settings that should be considered. These settings cannot be applied through local policy1 and must therefore be completed manually on all bastion host servers.

Most user rights assignments that are applied through the MSC- have the proper security groups specified in the security templates that accompany this guide. However1 there are a few accounts and security groups that cannot be included in the templates because their security identifiers /S3Ds0 are specific to individual !indows Server *++, domains. The user rights assignment setting in the following table must be configured manually.
Warning$ The followin& table contains values for the built-in Administrator account. This account is not to be confused with the built-in 0d inistrators securit" &roup. 6f the 0d inistrators securit" &roup is added to the specified K7en" accessL user ri&ht "ou will need to lo& on locall" in order to correct the mistake. Also# the built-in Administrator account ma" have been renamed# as recommended in Chapter (# HThe Member +erver 9aseline 8olic".H 3hen "ou add the Administrator account to a user ri&ht# ensure that "ou specif" the renamed account.
Table 12 3 Manually &dded (ser /i"'ts &ssi"nments Settin" Deny access to this computer from the network 2e"acy Client !nterprise Client Speciali1ed Security 7 2imited 0unctionality
Cuilt%in Cuilt%in Cuilt%in AdministratorV AdministratorV AdministratorV SupportP,>>6E5a+V SupportP,>>6E5a+V SupportP,>>6E5a+V HuestV all 8$8% HuestV all 8$8% HuestV all 8$8% $perating System $perating System $perating System service accounts service accounts service accounts
I portant$ KAll non-operatin& s"stem service accountsK includes service accounts that are used for specific applications across an enterprise# but does 1T include !1CA! +J+T2M# !1CA! +24C6C2 or the 2T314< +24C6C2 accounts @the built-in accounts that the operatin& s"stem usesA.
.-0

!indows Server *++, with S-. has a number of built%in user accounts that cannot be deleted but can be renamed. Two of the most well%known built%in accounts in !indows Server *++, are Huest and Administrator. Cy default1 the Huest account is disabled on member servers and domain controllers. This configuration should not be changed. Many variations of malicious code use the built%in Administrator account in an initial attempt to compromise a server. Therefore1 you should rename the built%in Administrator account and alter its description to help prevent compromise of remote servers by attackers who try to use this well%known account. The value of this configuration change has diminished over the past few years since the release of attack tools that specify the security identifier /S3D0 of the built%in Administrator account to determine its true name and then break into the server. A S3D is the value that uni=uely identifies each user1 group1 computer account1 and logon session on a network. 3t is not possible to change the S3D of this built%in account. However1 your operations groups can easily monitor attempted attacks against this Administrator account if you rename it with a uni=ue name. To secure well =nown accounts on bastion 'ost servers Kename the Administrator and Huest accounts1 and then change their passwords to long and comple9 values on every server. Jse different names and passwords on each server. 3f the same account names and passwords are used on all servers1 an attacker who gains access to one server will be able to gain access to all others. Change the account descriptions to something other than the defaults to help prevent easy identification of the accounts. Kecord any changes that you make in a secure location.
rror $eportin(
Table 12 B /ecommended !rror /eportin" Settin"s Settin" Turn off !indows ?rror Keporting 2e"acy Client ?nabled !nterprise Client ?nabled Speciali1ed Security 7 2imited 0unctionality ?nabled
This service helps Microsoft track and address errors. Bou can configure this service to generate reports for operating system errors1 !indows component errors1 or program errors. 3t is only available in !indows 2- -rofessional and !indows Server *++,. The !rror /eportin" service can report such errors to Microsoft through the 3nternet or to an internal file share. Although error reports can potentially contain sensitive or even confidential data1 the Microsoft privacy policy with regard to error reporting ensures that Microsoft will not use such data improperly. However1 the data is transmitted in plainte9t HTT-1 which could be intercepted on the 3nternet and viewed by third parties. The Turn off Windows !rror /eportin" setting controls whether the !rror /eportin" service transmits any data.
.-.
Bou can configure this policy setting in !indows Server *++, at the following location within the Hroup -olicy $b7ect ?ditor" Computer Confi"uration\&dministrative Templates\System\)nternet Communications Mana"ement\)nternet Communications settin"s Configure the Turn off Windows !rror /eportin" setting to !nabled in the CHL- for all three environments that are defined in this guide.

To deploy the necessary security settings1 you must use both the Security Configuration !i'ard /SC!0 and the security templates that are included with the downloadable version of this guide to create a server policy. !hen you create your own policy1 be sure to skip the GKegistry SettingsG and SAudit -olicyT sections. These settings are provided by the security templates for your chosen environment. This approach is necessary to ensure that the policy elements that are provided by the templates take precedence over those that would be configured by SC!. Bou should use a new installation of the operating system to begin your configuration work1 which helps ensure that there are no legacy settings or software from previous configurations. 3f possible1 you should use hardware that is similar to the hardware that is used in your deployment to help ensure as much compatibility as possible. The new installation is called a reference com)uter. During the server policy creation steps you will probably remove the :ile server role from the list of detected roles. This role is commonly configured on servers that do not re=uire it and could be considered a security risk. To enable the :ile server role for servers that re=uire it1 you can apply a second policy later in this process. To create t'e bastion 'ost policy .. Create a new installation of !indows Server *++, with S-. on a new reference computer. *. 3nstall the Security Configuration !i'ard component on the computer through Control -anel1 Add#Kemove -rograms1 Add#Kemove !indows Components. ,. 3nstall and configure only the mandatory applications that will be on every bastion host. ?9amples include antivirus or antispyware utilities. E. Launch the SC! HJ31 select Create new policy1 and point it to the reference computer. 5. ?nsure that the detected server roles are appropriate for the bastion host /for e9ample1 !eb server0. Kemove all other server roles. L. ?nsure that the detected client features are appropriate for your environment. Kemove all unnecessary client features. :or e9ample1 you should remove the Microsoft networ=in" client and the -?C% client features to reduce the server;s attack surface. N. :or ma9imum protection1 remove all administrative options e9cept for !indows :irewall. Additional options will increase the manageability of the bastion host1 but will also increase its attack surface. Carefully weigh the benefits of any options that are not crucial to the proper operation of the bastion host against the potential security risks they might pose. >. ?nsure that any additional services that are re=uired by your baseline1 such as backup agents or antivirus software1 are detected.
.-2
6. Decide how to handle unspecified services in your environment. :or e9tra security1 you may wish to configure this policy setting to -isable. Bou should test this configuration before you deploy it to your production network because it may cause problems if your production servers run additional services that are not duplicated on your reference computer. .+. ?nsure the S=ip t'is section checkbo9 is unselected in the G8etwork SecurityG section1 and then click .e3t. The appropriate ports and applications identified earlier are configured as e9ceptions for !indows :irewall. Jncheck all ports e9cept those that are re=uired for the bastion host function. ... 3n the GKegistry SettingsG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .*. 3n the GAudit -olicyG section1 click the S=ip t'is section checkbo9 and then click .e3t. These policy settings are imported from the supplied 38: file. .,. 3nclude the appropriate security template /for e9ample1 SSL:%Castion Host.inf0. .E. Save the policy with an appropriate name /for e9ample1 Castion Host.9ml0.

After you create and save the policy1 Microsoft strongly recommends that you deploy it to your test environment. 3deally1 your test servers will have the same hardware and software configuration as your production servers. This approach will allow you to find and fi9 potential problems1 such as the presence of une9pected services that are re=uired by specific hardware devices. Cecause computers in the bastion host role are not connected to a domain1 you must apply the settings with SC!. Bou cannot use Hroup -olicy without a domain. The policy is tested to ensure that the application of this policy to the target servers will not adversely affect their critical functions. After you apply the configuration changes1 you should begin to verify the core functionality of the computer. :or e9ample1 if the server is configured as a certification authority /CA01 ensure that clients can re=uest and obtain certificates1 download a certificate revocation list1 and so on. !hen you are confident in your policy configurations1 you can use Scwcmd as shown in the following procedure to convert the policies to H-$s. :or more details about how to test SC! policies1 see the Deployment Huide for the Security Configuration !i'ard at http"##technet*.microsoft.com#!indowsServer#en#Library#5*5Ef>cd%.E,e%E556%a*66% 6cN*,b,LL6EL.+,,.msp9 and the Security Configuration !i'ard Documentation at http"##go.microsoft.com#fwlink#?linkid4E,E5+.
I"p#e"ent the +o#icy

After you thoroughly test the policy1 complete the following steps to implement it" .. Launch the SC! HJ3. *. Select &pply an e3istin" security policy. ,. Select the 2ML file that you created earlier. :or e9ample1 Castion Host.9ml. E. Complete the SC! wi'ard to apply the settings. 8ote that if the SC! security policy file contains !indows :irewall settings1 !indows :irewall must be active on the local computer for this procedure to complete successfully. To verify that !indows :irewall is active1 open Control -anel and then double%click Windows 0irewall.
.-)
Bou should now perform a final test to ensure that SC! applies the desired settings. To complete this procedure1 confirm that the appropriate settings were made and that functionality is not affected.
Su""ary
Cecause bastion host servers that run !indows Server *++, with S-. are not protected by other devices such as firewalls1 they are e9posed to outside attacks. They must be secured as much as possible to ma9imi'e their availability and to minimi'e the possibility of compromise. The most secure bastion host servers limit access only to highly trusted accounts1 and enable only those services that are necessary to fully perform their functions. This chapter e9plained settings and procedures that can be used to harden bastion host servers and make them more secure. Many of the settings can be applied through local Hroup -olicy. Huidance about how to configure and apply manual settings was also provided.
)ore In&or"ation
The following links provide additional information about topics that relate to hardening bastion host servers that run !indows Server *++, with S-.. :or more information about building private networks1 open the .pdf file G:irewalls and <irtual -rivate 8etworksG by ?li'abeth D. Mwicky1 Simon Cooper1 and Crent D. Chapman at www.wiley.com#legacy#compbooks#press#+EN.,E>*+.P+6.pdf. :or more information about firewalls and security1 see G3nternet :irewalls and Security @ A Technology $verviewG by Chuck Semeria at www.itmweb.com#essay5,E.htm. :or information about the defense%in%depth model1 see the J.S. Military About defense in depth page at http"##usmilitary.about.com#od#glossarytermsd#g#did.htm. :or information about safeguards against intruders1 see the G3ntruder Detection ChecklistG by Ray Ceale at www.cert.org#techPtips#intruderPdetectionPchecklist.html. :or more information about how to harden bastion hosts1 see the SA8S 3nfo Sec Keading Koom article GHardening Castion HostsG at www.sans.org#rr#whitepapers#basics#E*+.php. :or additional information about bastion hosts1 see GHow Castion Hosts !orkG at http"##thor.info.uaic.ro#\busaco#teach#docs#intranets#ch.L.htm. :or information about how to troubleshoot the Security Configuration and Analysis Tool1 see the Microsoft Fnowledge Case article G-roblems After Bou 3mport Multiple Templates 3nto the Security Configuration and Analysis ToolG at http"##support.microsoft.com#?kbid4*N6.*5. :or information about site security1 see the GSite Security HandbookG at www.fa=s.org#rfcs#rfc*.6L.html.
Chapter 13: Conc#usion

Congratulations. 8ow that you have finished this guide1 you should have a clear understanding of how to assess risks that may affect the security of those computers that run Microsoft( !indows Server) *++, with S-. in your organi'ation. Bou have gained an understanding of how to plan and design security into your network infrastructure wherever possible. This guide included prescriptive guidance that may be applied to any organi'ation. Some of this guidance includes material that was collected from consultants and systems engineers who have implemented !indows Server *++,1 !indows 2-1 and !indows *+++ solutions in a variety of settings. This material has helped establish a set of best practices for how to make !indows Server *++, as secure as possible. Kegardless of your organi'ation s environment1 security%related matters should be treated seriously. However1 many organi'ations still do not sufficiently address security issues because they mistakenly view security as something that restricts their agility and fle9ibility. !hen well%designed security becomes a core business re=uirement and is planned for at the start of every information technology /3T0 pro7ect1 a properly implemented security strategy can help to improve the availability and performance of your computer systems. However1 security that is added to a pro7ect as an afterthought can negatively affect usability1 stability1 and management fle9ibility. ?very organi'ation should include security among its highest priorities. This guide e9plained how to effectively mitigate security risks for computers that run !indows Server *++, with S-. in three distinct environments. 3t documented methods for how to plan and design security into your organi'ation s network infrastructure1 and provided detailed guidance about how to correct specific vulnerabilities that are commonly found on computers that run !indows Server *++, with S-.. The reasons for certain choices were e9plained in terms of the tradeoffs that must be considered when an organi'ation needs to decide whether to implement each of the countermeasures. Details were provided about how specific countermeasures may affect the functionality1 manageability1 performance1 and reliability of the computers so that you can make informed choices about which countermeasures to implement in your own environment. :inally1 it is important to understand that the task of securing the servers in a network is not a one time pro7ect1 but rather an ongoing process that organi'ations must include in their budgets and schedules. Most organi'ations that use the !indows Server *++, operating system would improve their security if they implemented all of the countermeasures that are discussed in this guide. However1 when the ne9t serious vulnerability is discovered1 these environments may again be =uite susceptible to attack. :or these reasons1 it is essential that you monitor a variety of resources to stay current on security issues related to the operating systems1 applications1 and devices that are present in your environment. ?very member of the team that produced this guide hopes that you found the material covered in it useful1 informative1 and easy to understand.
.-'
)ore In&or"ation
The following links provide additional information about topics that relate to hardening servers that run !indows Server *++, with S-.. :or more information about security at Microsoft1 see the Trustworthy Computing" Security page at www.microsoft.com#mscorp#twc#default.msp9. :or more detail about how M$: can assist in your enterprise1 see the Microsoft $perations :ramework page at www.microsoft.com#technet#itsolutions#cits#mo#mof#default.msp9.
3ppendi! 3: Security %oo#s and For"ats

3t can be a challenge to create1 test1 deploy1 and manage a complete set of policy and templates for your organi'ation. This appendi9 provides an overview of the available Microsoft tools and the formats that security policies may come in.
Security %oo#s
The following tools are available either with the !indows Server) *++, operating system or as free downloads from the Microsoft !eb site.
Security Con&i(uration Wi6ard

The Security Configuration !i'ard /SC!0 was introduced in !indows Server *++, S-.. Jnlike Hroup -olicy1 it is not integrated with the Active Directory( directory service1 so it cannot be used to configure the domain%level policies. However1 it does provide a consistent role%based hardening methodology that uses wi'ards1 which makes it easy to create secure policies. !ith SC!1 you can =uickly and easily create prototype policies for multiple server roles that are based on the latest guidance and best practices from Microsoft. SC! will automatically manage service settings1 registry settings1 !indows :irewall e9ceptions1 and more. 3t includes the ability to remotely profile target computers1 deploy policies1 and roll back policies. The command%line tool Scwcmd allows SC! and Hroup -olicy to be used together to deploy policies to groups of computers or convert policies to H-$s.
Security Con&i(uration
ditor
The Security Configuration ?ditor /SC?0 tools are used to define security policy templates that can be applied to individual computers or to groups of computers through Active Directory Hroup -olicy. The SC? first appeared as an add%on for !indows 8T( E.+ and has become an integral part of Hroup -olicy. The SC? is no longer a separate component and is used in the following Microsoft Management Console /MMC0 snap%ins and administrative utilities" MMC Security Configuration and Analysis snap%in MMC Security Templates snap%in Hroup -olicy ?ditor snap%in /used for the Security Settings portion of the Computer Configuration tree0 Local Security Settings tool Domain Controller Security -olicy tool Domain Security -olicy tool
Appendi0 A$ +ecurit" Tools and ,ormats
.-:
Cecause all of these tools use the SC?1 !indows administrators en7oy a consistent1 powerful interface to create and edit policies whether they are intended for a stand%alone computer or will be deployed as a H-$. Bou can find more information about SC? from !indows Help.
3ctive *irectory 7sers and Co"puters

The MMC Active Directory Jsers and Computers snap%in provides the primary HJ3 to create and manage organi'ational units /$Js0 within the domain. Bou can link H-$s and $Js1 control policy order and inheritance1 and launch the Hroup -olicy $b7ect ?ditor as a separate process to edit H-$s. However1 the snap%in does not offer a consistent1 integrated way to inventory1 author1 and manage your Hroup -olicies. Bou can find more information about the MMC Active Directory Jsers and Computers snap%in from !indows Help.
Group +o#icy )ana(e"ent Conso#e

The Hroup -olicy Management Console /H-MC0 was produced by Microsoft in response to feedback from customers who needed a better way to control Hroup -olicy in a large environment. The H-MC must be run on !indows 2- with S-. or !indows Server *++, and consists of an MMC snap%in and a set of scriptable interfaces that can be used to manage Hroup -olicy. 3t can manage both !indows *+++ Server and !indows Server *++, domains. The H-MC provides" A user interface that focuses on Hroup -olicy use and management. The ability to =uickly back up1 restore1 import1 e9port1 copy1 and paste H-$s. Simplified management of Hroup -olicy%related security. Keport capabilities for H-$ and Kesultant Set of -olicy /KSo-0 data. Scriptable H-$ operations.
The Hroup -olicy Management Console with Service -ack . is available as a free download for all !indows Server *++, customers at www.microsoft.com#downloads#details.asp9?:amily3D4+aLdEc*E%>cbd%Eb,5%6*N*% dd,cbfc>.>>NODisplayLang4en.
Security Fi#e For"ats

Security policies can be created and stored in a variety of formats. The following sections detail the common file formats that are used by !indows Server *++,"
SCW +o#icy =@!"#>

SC! introduces a new file format that is based on 2ML. 8ative SC! policies are saved with an e9tension of .9ml. These 2ML policy files have no official schema1 but can be identified by the ]Security-olicy <ersion4G..+G^ element. The SC! policy file is actually a complete manifest of several different types of settings" System services startup mode !indows :irewall e9ceptions
.-;
Selected computer roles Selected computer tasks Kegistry settings -olicy settings Audit policies
Also1 SC! policies can be linked to one or more policy templates to provide additional functionality that is not native to SC!1 such as system service or registry access control lists /ACLs0.
+o#icy %e"p#ate =@in&>

-olicy templates are te9t files that follow a standard format for !indows data files" one or more sections that are set off by special s=uare bracket%enclosed keywords1 which are followed by one or more attribute#value pairs. -olicy templates can contain one or more sections that define the following types of data" -assword policies Lockout policies Ferberos authentication protocol policies Audit policies ?vent log settings Kegistry values Service startup modes Service permissions Jser rights Hroup membership restrictions Kegistry permissions :ile system permissions
-olicy templates are supported by almost all of the tools that are listed earlier in this appendi91 and the same template format can be used for both local computer policies and Active Directory Hroup -olicies. Cefore they can be used1 the templates must be imported by the appropriate tool.
Group +o#icy Ob:ects

H-$s are policy data that is stored both in Active Directory and as a collection of files within special directories on domain controllers. These policy files represent computer policies and user policies and are not usually manipulated directly. Bou can use a tool such as the H-MC to modify the settings or e9port the H-$ into a policy template. Bou can e9port or back up a H-$ from within H-MC to save all the information that is stored inside the H-$ to the file system. H-$ backups that are created in this way keep the following information" The H-$ s globally uni=ue identifier /HJ3D0 and domain H-$ settings The discretionary access control list /DACL0 on the H-$
.--
The !M3 filter link1 if there is one /but not the filter itself0 Links to 3- Security policies1 if any 2ML report of the H-$ settings1 which can be viewed as HTML from within H-MC Date and time stamp of when the backup was taken Jser%supplied description of the backup
However1 this backup does not save any of the data that is e9ternal to the H-$. 3n particular1 this file will not contain link information for sites1 domains1 or $Js and it will not contain the actual !M3 filters or 3- security policies.
3ppendi! -: 4ey Settin(s to Consider

Although this guide discussed many security countermeasures and security settings1 it is important to understand that some of them are especially important. This appendi9 highlights those settingsV you may wish to refer to the relevant chapter for an e9planation of what the setting does and why it is important. !hich settings to include in this list could be the sub7ect of an e9tensive debate. 3n fact1 this topic was discussed at great length by a group of security e9perts within Microsoft. Bou may feel that some settings are missing1 or that some of the listed settings do not need to be on the list. Cecause each organi'ation has a distinct environment with uni=ue business re=uirements1 different opinions about security issues should be e9pected. Still1 this list might help you prioriti'e tasks that relate to hardening computers that run Microsoft( !indows(. 3mportant countermeasures that are not security settings include" Feep computers up%to%date on service packs and hotfi9es with automated tools for testing and deployment. 3nstall and configure distributed firewall software or organi'ational 3-sec policies. Deploy and maintain antivirus software. Deploy and maintain antispyware software on computers that are used to browse !eb sites. Jse a non%administrative account for day%to%day tasks. Bou should only use an account with administrator privileges to perform tasks that re=uire elevated privileges. -assword policy1 which is discussed in Chapter ,1 GThe Domain -olicy.G ?nforce -assword History Ma9imum -assword Age Minimum -assword Length -asswords must meet comple9ity re=uirements Store -assword Jsing reversible encryption for all users in the domain Access this computer from the network Act as part of the operating system Allow logon locally Allow Log on through Terminal Services
Fey security settings that are available in Microsoft !indows include"
Jser rights1 which are discussed in Chapter E1 GThe Member Server Caseline -olicy.G
20.
Security options1 which are discussed in Chapter E1 GThe Member Server Caseline -olicy.G Accounts" Limit local account use of blank passwords to console logon only Domain Member" Digitally encrypt or sign Secure channel Data /always0 Domain Member" Digitally encrypt Secure channel Data /when possible0 Domain Member" Digitally sign Secure channel Data /when possible0 Domain member" re=uire strong /!indows *+++ or later0 session key 8etwork access" Allow anonymous S3D#8ame translation 8etwork Access" Do not allow anonymous enumeration of SAM accounts 8etwork access" do not allow enumeration of SAM accounts and shares 8etwork Access" Let ?veryone permissions apply to anonymous users 8etwork Access" Kemotely Accessible Kegistry -aths 8etwork Access" Kestrict Anonymous access to named pipes and shares 8etwork Access" Shares that can be accessed anonymously 8etwork Access" Sharing and Security Model for Local Accounts 8etwork Security" Do not store LA8 manager hash value on ne9t password change 8etwork Security" LA8 Manager Authentication Level
Additional registry settings1 which are discussed in Chapter E1 GThe Member Server Caseline -olicy.G Safe DLL Search Mode.
3ppendi! C: Security %e"p#ate Settin( Su""ary

The Microsoft( ?9cel( workbook G!indows Server *++, Security Huide Settings.9lsG /included with this guide0 documents the policy and service settings for all of the roles and environments that are included in this guide. This workbook contains ten worksheets1 one for each role in the guide" The -omain worksheet contains the Hroup -olicy settings that configure the domain% level policy ob7ects as described in Chapter ,1 GThe Domain -olicy.G The Member Server #aseline worksheet contains the Hroup -olicy and SC! service settings that configure the MSC- as described in Chapter E1 GThe Member Server Caseline -olicy.G The -omain Controller worksheet contains the Hroup -olicy and SC! service settings that configure the DCC- as described in Chapter 51 GThe Domain Controller Caseline -olicy.G The )nfrastructure Server worksheet contains the Hroup -olicy and SC! service settings that configure the infrastructure server policies as described in Chapter L1 GThe 3nfrastructure Server Kole.G The 0ile Server worksheet contains the Hroup -olicy and SC! service settings that configure the file server policies as described in Chapter N1 GThe :ile Server Kole.G The %rint Server worksheet contains the Hroup -olicy and SC! service settings that configure the print server policies as described in Chapter >1 GThe -rint Server Kole.G The Web Server worksheet contains the Hroup -olicy and SC! service settings that configure the 33S !eb server policies as described in Chapter 61 GThe !eb Server Kole.G The )&S Server worksheet contains the Hroup -olicy and SC! service settings that configure the 3AS server policies as described in Chapter .+1 GThe 3AS Server Kole.G The C& Server worksheet contains the Hroup -olicy and SC! service settings that configure the Certificate Services server policies as described in Chapter ..1 GThe Certificate Services Server Kole.G The #astion ?ost worksheet contains the Hroup -olicy and SC! service settings that configure the bastion host policies as described in Chapter .*1 GThe Castion Host Kole.G
20)
?ach worksheet contains the following columns" The H column1 %olicy Settin" .ame in (ser )nterface1 is the name of the setting as it appears in the !indows Server *++, Hroup -olicy ?ditor snap%in. The R column1 2e"acy Client1 is the recommended value for that setting in the LC environment. The F column1 !nterprise Client1 is the recommended value for that setting in the ?C environment. The L column1 SS201 is the recommended value for that setting in the SSL: environment.
To make the spreadsheet easy to read1 additional columns were used to illustrate the hierarchy of ob7ects within the Hroup -olicy ?ditor. Columns A through H are used to represent one level each of the hierarchy. :or e9ample1 Computer Confi"uration appears in column A1 and Security Settin"s appears in column C. Column 3 was also inserted to help with readability.
3ppendi! *: %estin( the Windows Server 2003 Security Guide

Overview
The Windows Server 2003 Security Guide is designed to provide proven and repeatable configuration guidance to secure computers that run Microsoft( !indows Server) *++, with Service -ack . /S-.0 in a variety of environments. The Windows Server 2003 Security Guide was tested in a lab environment to ensure that the guidance works as e9pected. The documentation was checked for consistency and all recommended procedures were tested by the Windows Server 2003 Security Guide test team. Tests were performed to verify functionality1 but also to help reduce the amount of resources that are needed by those who use the guidance to build and test their own implementations.
Scope
The Windows Server 2003 Security Guide was tested in a lab that simulated three different security environmentsILegacy Client /LC01 ?nterprise Client /?C01 and Speciali'ed Security @ Limited :unctionality /SSL:0. These environments are described in Chapter .1 G3ntroduction to the !indows Server *++, Security Huide.G Tests were conducted based on the criteria that are described in the following GTest $b7ectivesG section. A vulnerability assessment of the test lab environment that was used to secure the Windows Server 2003 Security Guide solution was out of scope for the test team.
%est Ob:ectives
The Windows Server 2003 Security Guide test team was guided by the following test ob7ectives" <alidate the recommended changes in security settings for the three security levels that are defined in the guide. Keasons for these changes include" Changes caused by the release of S-. for !indows Server *++,. Jse of the new Security Configuration !i'ard /SC!0 tool that became available in S-. and new features such as !indows :irewall. 3nternal and e9ternal feedback that was received about the previous version of the guide.
?nsure that the security settings and configuration changes that are recommended in the guide meet the re=uirements of the LC1 ?C1 and SSL: environments. ?nsure that hardened domain member servers are able to successfully perform their role tasks.
Appendi0 7$ Testin& the 3indows +erver 200) +ecurit" 5uide
20'
?nsure that communication between the client computers and the domain controllers is not negatively affected. <erify that all prescriptive guidance is clear1 complete1 and technically correct.
:inally1 the guidance should be repeatable and reliably usable by a Microsoft Certified Systems ?ngineer /MSC?0 with two years of e9perience.
%est
nviron"ent
The test lab networks that were developed to test this guide were similar to those that were used in the previous version of the guide. Three separate but similar networks were developed1 one for each of the defined environments. ?ach test network consisted of a !indows Server *++, with S-. Active Directory( directory service forest1 computers for infrastructure server roles that provided domain controller1 D8S1 !38S and DHC- services1 and other computers for application server roles that provided file1 print1 and !eb services. The ?C network also included computers for the Certificate Services and 3AS server roles1 and the Castion Host /CH0 server role was included in the SSL: network. Also1 the ?C and SSL: networks included Microsoft $perations Manager /M$M0 *++5 and Systems Management Server /SMS0 *++, to manage and monitor the domain member servers and client computers. These networks also included Microsoft ?9change Server *++, for e%mail service. The client computers in the different networks used !indows 2- -rofessional with S-* and !indows *+++ -rofessional with S-E. The LC network also included client computers that ran the !indows 6> SK* and !indows 8T( E.+ workstation with S-La operating systems.
206
The following diagram shows the test lab network that was developed for the ?C environment.
0i"ure - 1 2o"ical dia"ram of t'e test lab networ= for t'e !C environment To verify replication scenarios between hardened domain controllers1 the Active Directory forest consisted of two sites. $ne site was the main office site with an empty root domain and a child domain that consisted of the previously mentioned server and client computers. The second site consisted merely of a single second domain controller of the child domain.
20:
The following diagram shows the test lab network that was developed for the SSL: environment.
0i"ure - 2 2o"ical dia"ram of t'e test lab networ= for SS20 environment
%estin( )ethodo#o(y
This section describes the procedures that were followed to test the Windows Server 2003 Security Guide. The test team established a lab that incorporated the three networks that are described in the previous section. A =uick proof of concept /-$C0 test pass and then two more robust test cycles were e9ecuted. During each pass the team strove to stabili'e the solution. A test cycle was defined as a se=uence of the following phases" .. Security Configuration Cuild phase Manual configuration phase Hroup -olicy configuration phase
*. Test ?9ecution phase The details of each phase are provided in the following G-hases in a Test -assG section. The GTest -reparation -haseG section describes the steps that were performed to ensure that the lab environment was free of any issues that could cause a misinterpretation of the actual test results after the three environments were hardened through the first two incremental build phases. 3t is also referred to as the SbaselineT state.
20;
+hases in a %est +ass

The test pass phases are described in the following subsections. Any critical issues that were found during the build phase were identified as bugs and resolved in that phase before the test team moved to the test e9ecution phase. This method ensured that correct security configuration was implemented in the network and validated the accuracy of the test results that were obtained.
Test %reparation %'ase

This phase set up the baseline configuration to which the solution is applied during the Security Configuration Cuild phase. The following steps were performed for each of the three environmentsILC1 ?C1 and SSL:" To complete t'e test preparation p'ase .. 8etwork the computers as illustrated in the network diagram and install the appropriate versions of the !indows operating system on all server and client computers. *. Create and configure the domain1 domain controllers1 and the two sites. ,. Roin and configure each member server and the management servers. Also1 7oin the client computers to the domain. E. ?9ecute basic verification tests for each server role to confirm proper network and application configuration. 5. Check the event log of each member server in the network to ensure that there are no application or system level errors. L. ?nsure client computer accessibility to the services that are provided by the domain controller and member servers /D8S1 DHC-1 CA1 file1 print1 !eb and e%mail0. Check the event logs on the client computers to ensure that there are no errors. N. ?nsure that all re=uired applications1 services1 and agents are installed on each domain member. :or e9ample1 verify that the M$M agent is installed on all the servers that will be managed by the M$M server. >. After the previous steps are completed1 create an image backup of each computer. These backup images are used to Groll backG the network to the baseline configuration before a new test pass is started.
Security Confi"uration #uild %'ase

The ob7ective of this phase was to follow the procedures in the guide to configure the domain1 domain controllers1 and member servers to a more secure level than the baseline configuration.
Man al !on"ig ration P#ase

This phase is often the first security build phase. The manual hardening recommendations that were provided in each chapter were implemented during this phase.
3ote$ +ome of these steps ma" be applicable for "our network and some ma" not. 4eview each procedure carefull" to understand its impact on "our network.
20-
To perform t'e manual confi"uration p'ase .. Jse the Microsoft Management Console /MMC0 Computer Management snap%in to perform the prescribed policy setting changes /such as the local administrator account and password0 on each member computer. Complete the following steps to secure the domain accounts" a. ?nsure that the built%in local Administrator account has a comple9 password1 has been renamed1 and has had its default account description removed. b. Kename the Huest accounts on the host and disable them. c. 3ncorporate any additional recommendations from the guide about how to secure the domain accounts.
*. Add any uni=ue security groups or accounts to the user rights settings as described in the chapters. ,. -erform all other applicable manual hardening procedures as prescribed in each chapter. :or e9ample1 enable Manual Memory Dumps and ?rror reporting configuration.
$ro p Policy !on"ig ration P#ase

The purpose of this phase is to create and apply the Hroup -olicy ob7ects /H-$s0 at the domain and organi'ational unit /$J0 levels. H-$s are applied to the different $Js based on the recommendations in Chapter *1 G!indows Server *++, Hardening Mechanisms.G Service -ack . for !indows Server *++, introduced some new tools and features that caused the Hroup -olicy implementation design to change from its previous version. SC! is an attack%surface reduction tool that is used to create the re=uired set of security policies for each of the server roles that are discussed in this guide. The availability of SC! caused the following two significant changes for the Hroup -olicy Configuration -hase" 3-sec filters that were provided with the previous version of this guide were replaced with !indows :irewall port configurations that were created with SC!. Security templates that are included with the guide are to be used in con7unction with SC! to create 2ML security template files. These templates are then converted to corresponding H-$s using the Scwcmd command%line tool.
The following steps were repeated for each of the three security environments" To create Group %olicy ob,ects .. ?nsure that all re=uired applications1 services1 and agents were installed on each domain member in the baseline network. :or e9ample1 ensure that the M$M agent was installed on all the domain member servers that will be managed by M$M. *. Jse the MMC Active Directory Jsers and Computers snap%in to create the described $J structure. ,. Create the Domain -olicy H-$ with the .inf security template. This step does not re=uire the use of SC!. E. Jse the SC! tool to create 2ML@based security templates for each server role that is described in the guide. -rescriptive steps are described in Chapter *1 G!indows Server *++, Hardening MechanismsG and each individual server role chapter. !hen you perform this step1 include the appropriate .inf security template for the server role. The template files are included with the downloadable version of this guide.
2.0
5. Jse the Scwcmd command%line tool to convert the 2ML security templates that were created in the previous step to H-$s. L. Kepeat step E on the Castion Host server to create the Castion Host 2ML security template and then use SC! again to convert and apply it to the Local H-$. After the H-$s are successfully created1 compare the settings with the guidance in the chapters to identify any incorrect configurations. At this stage1 all the domain member servers reside in the Computers $J. These servers are then moved to their respective $Js under the Member Server $J. The ne9t task /detailed in the following procedure0 is to apply each of these H-$s to the respective $Js. The Hroup -olicy Management Console /H-MC0 tool was used to link the H-$ with the $J. The Domain Controller -olicy H-$ was linked last. The following steps were performed to complete the rest of the Security Configuration Cuild phase" To apply Group %olicy ob,ects .. Link the Domain -olicy H-$ to the domain ob7ect.
3ote$ 6f default 581 links are alread" present or if there are multiple 581s# "ou mi&ht need to elevate the 581 links in the priorit" list.
*. Jse the Hroup -olicy Management Console tool to link the Member Server Caseline -olicy H-$ to the Member Servers $J. /Bou can also perform this step with the MMC Active Directory Jsers and Computers snap%in.0 ,. Link each individual server role H-$ to the appropriate server role $J. E. Link the Domain Controller -olicy H-$ to the Domain Controller $J. 5. To ensure application of the latest Hroup -olicy settings1 e9ecute gpudpate /force at a command prompt on all domain controllers. Then restart all the domain controllers one at a time1 starting with the primary domain controller. Allow sufficient time for Active Directory to replicate the changes between the sites.
I portant$ 6t is ver" important to restart the domain controllers after "ou appl" the 7omain Controllers 8olic" 581. 6f "ou do not perform this step "ou ma" see replication errors in the 7irector" +ervice folder or /serenv errors in the Application folder of 2vent Ciewer.
L. Kepeat step 5 on all of the domain member servers. N. Check ?vent <iewer for any errors. Keview the error logs to troubleshoot and resolve any failures. >. $n the Castion Host server1 use the SC! tool to apply the Castion Host 2ML security template on the Local H-$ of the server.
%eri"ying $ro p Policy Do&nload on t#e Member Server !omp ters

The previous procedures created H-$s and applied them to $Js to configure the computers in those $Js. Complete the following steps to confirm the successful download of Hroup -olicy from domain controllers to member server computers. /3t is assumed that the member server computers were restarted after the H-$ was linked to the $J.0 To verify Group %olicy download on a member server computer .. Log on to the member server computer. *. Click Start1 /un1 type rsop msc1 and press ?8T?K.
2..
,. 3n the /esultant Set of %olicy console1 e9pand Console /oot and browse to Computer Confi"uration. E. Kight%click Computer Confi"uration and click %roperties. The list of H-$s will display in the Computer Confi"uration %roperties panel. The H-$ that was applied to the $J should be available in the list1 and there should be no errors associated with it.
Test !3ecution %'ase

This phase e9ecutes the test cases that were developed by the test team. The test e9ecution phase seeks to identify the following" Any potential application1 security1 or system failure events that are caused by processes that were used to harden the domain1 domain controllers1 member servers1 or Castion Host server. Lost availability of a service or functionality that is caused by changes to the security configuration of the servers in the network. Technical inaccuracies between what is documented in the chapters and the physical implementation in the test lab.
The test team e9ecuted the set of test cases that are included in ZWindows Server 2003 Security Guide Tools and Templates\Test Tools folder. /The tools and templates are included with the downloadable version of this guide.0 These tests were e9ecuted on each of the three separate networks e9cept for those that tested components that were only available in one networkIsuch as Certificate Services1 which was only available in the ?C environment. 3n addition to these test cases1 manual testing was performed at various timeIfor e9ample1 to periodically check ?vent <iewer logs or to verify any specific issues that were discovered in the previous version of the guide. All issues that were found were logged in a database and triaged with members of the development team until they were resolved. More detailed information about the different types of tests that were performed is provided in the ne9t section.
%ypes o& %ests

The test team performed the following types of tests during the test phases to ensure that the secured domain1 domain controllers1 and member servers did not e9perience any significant loss of functionality. Bou may want to refer to the ?9cel workbooks in the \Windows Server 2003 Security Guide Tools and Templates\Test Tools folder that is included in the download for this guide1 which contain the complete list of test cases that were e9ecuted for domain@based as well as stand%alone servers that run !indows Server *++, with S-.. Details such as test scenarios1 e9ecution steps1 and e9pected results are also provided. These tests were e9ecuted multiple times. More importantly1 they were e9ecuted before and after the security settings that are described in this guide were implemented. This approach helped the test team to identify potential errors and any variations in functionality for the listed server roles.
Client Side Tests

These test cases were e9ecuted on the client computers in the network. The main purpose of these tests was to ensure that domain services /such as authentication1 access rights1 name resolution1 and so on0 and application based services /such as :ile1
2.2
-rint1 and !eb0 are available to the client computers after the network servers are hardened. :or the LC environment1 these tests ensured that those client computers that run !indows 8T E.+ S-La and !indows 6> were able to authenticate with the !indows Server *++, Active Directory domain.
-ocumentation #uild Tests

These tests validate that the statements1 procedures1 and functions that are documented in the implementation guidance are accurate1 unambiguous1 and complete. 8o separate test cases are listed for these tests.
Script Tests
Some of the client test scenarios were scripted in <CScript. These test cases are primarily concerned with proper functionality of !indows 2- client computers that use network@based services1 such as domain logon1 password change1 and print server access. The <CScript files for these test cases are available in the \Windows Server 2003 Security Guide Tools and Templates\Test Tools folder that is included in the downloadable version of this guide.
Server Side Tests

These test cases were developed to verify functionality and the effect of the build procedures on !indows Server *++, with S-. servers that were secured with the recommendations in this guide. All the server roles that are described in this guide were tested. The additional server roles that were included in the test network1 such as ?9change1 M$M1 and SMS1 were also tested.
+ass and Fai# Criteria

Cefore tests were performed1 the following criteria were defined to ensure defect prevention and bug resolution" All test cases must pass with e9pected results as described in the individual test case spreadsheets. A test case is considered to have passed if the actual result matched the e9pected result that is documented for the case. 3f the actual result does not match the e9pected result1 it was treated as a failed test case1 a bug was created1 and a severity score was assigned. 3f a test case failed1 it was not assumed that the solution guidance was necessarily defective. :or e9ample1 misinterpretation of product documentation1 incomplete documentation1 or inaccurate documentation could cause failures. ?ach failure was analy'ed to discover its cause based on actual results and the results that were described in pro7ect documentation. :ailures were also escalated to the appropriate owners of the respective Microsoft products.
$e#ease Criteria
The primary release criterion for the Windows Server 2003 Security Guide was related to the severity of bugs that were still open. However1 other issues that were not being tracked through bugs were also discussed. The criteria for release are" 8o bugs are open with severity levels . and *. All open bugs are triaged by the leadership team1 and their impacts are fully understood.
2.)
Solution guides are free of comments and revision marks. The solution successfully passes all test cases in the test lab environment. Solution contents have no conflicting statements.
-u( C#assi&ication
The bug severity scale is described in the following table. The scale is from . to E1 with . as the highest severity and E as the lowest severity. Table - 1 #u" Severity Classification Severity . Most common types @ Cug blocked build or further testing. @ Cug caused une9pected user accessibility. @ Steps defined in the documentation were not clear. @ Kesults or behavior of a function or process contradicts e9pected results /as documented in functional specification0. @ Ma7or mismatch between the security template files and the functional specification. @ Steps defined in the guide are not clear. @ Documented functionality is missing /in this case1 test was blocked0. @ Documentation is missing or inade=uate. @ 3nconsistency between security template files and content in the guide1 but security template file is in sync with functional specification. @ Documented format issue. @ Minor documentation errors and inaccuracies. @ Te9t misspellings. Conditions re8uired @ Solution did not work. @ Jser could not begin to use significant parts of the computer or network. @ Jser had access privileges that should not be allowed. @ Jser access was blocked to certain server/s0 that should be allowed. @ ?9pected results were not achieved. @ Testing cannot proceed without being addressed. @ Jser had no simple workaround to amend the situation. @ Jser could not easily figure out a workaround. @ -rimary business re=uirements could not be met by the computer or network.
@ Jser has a simple workaround to mend situation. @ Jser can easily figure out workaround. @ Cug does not cause a bad user e9perience. @ -rimary business re=uirements are still functional. @ Clearly not related to this version.
@ Suggestions. @ :uture enhancements.
2.(
Su""ary
This appendi9 enables an organi'ation that uses the Windows Server 2003 Security Guide to understand the procedures and steps that were used to test the implementation of the solution in a test lab environment. The actual e9perience of the Windows Server 2003 Security Guide test team is captured in this appendi91 which includes descriptions of the test environment1 types of tests1 the release criteria1 and bug classification details. All of the test cases that were e9ecuted by the test team passed with the e9pected results. The test team confirmed that the re=uisite functionality was available after the recommendations from the Windows Server 2003 Security Guide for the defined environments were applied.
3cknow#ed("ents
The Microsoft Solutions for Security and Compliance group /MSSC0 would like to acknowledge and thank the team that produced the Windows Server 2003 Security Guide. The following people were either directly responsible or made a substantial contribution to the writing1 development1 and testing of this solution.
Authors
Mike Danseglio Furt Dillard Ros_ Maldonado Crad !arrender
Kelease Managers
:licka Crandell Farl Seng1 Siemens 0!ency Services
Testers
Fenon Cliss1 +o#t "nformation Sciences Haurav Singh Cora1 "nfosys Techno#o!ies -aresh Hu7ar1 "nfosys Techno#o!ies <ince Humphreys1 +o#t "nformation Sciences Ashish Rava1 "nfosys Techno#o!ies Mehul Mediwala1 "nfosys Techno#o!ies Kob -ike <arun Kastogi1 "nfosys Techno#o!ies
Content Contributors
Liam Colvin1 3Shar)* ((C !illiam Di9on1 +, Security "ncTony Dowler1 3Shar)* ((C ?ric :it'gerald Devin Hanger1 3Shar)* ((C Stirling Hoet' 3an Hellen Resper Rohansson Steve Kyan1 Content Master Firk Soluk
Keviewers
Koger Abell1 0ri1ona State 2niversity Rose Luis Auricchio Avi Cen%Menahem Kich Cenack Shelly Cird Susan Cradley Steve Clark Kob Cooper Duane Crider Farel Dekyvere Christine Duell ?ric :it'gerald Mike Hreer Kobert Hensing Chad Hilton Andrew Mason
-rogram Managers
Comani Siwatu Alison !oolford1 Content Master
?ditors
Keid Cannecker !endy Cleary1 S.T /nsite Rohn Cobb1 +o#t "nformation Sciences Felly McMahon1 Content Master Lynne -erry1 Content Master Ron Tobey Steve !acker1 !adeware LLC
2.6
Don McHowan Rames 8oyce Roe -orter Roel Scambray Debra Little7ohn Shinder Tom Shinder Steve Smegner Cen Smith Allen Stewart Didier <andenbroeck Kyan <atne Reff !illiams Rim !hitney1 Confi!uresoft Shain !ray
Chase Carpenter Reff Cohen Rohn Dwyer Sean :innegan Farl Hrunwald Roanne Fennedy Farina Larson1 +o#t "nformation Sciences Chrissy Lewis1 Siemens 3usiness Services David Mowers Reff 8ewfeld Kob $ikawa <ishnu -atankar -eter Meister Feith -roctor Cill Keid Sandeep Sinha Stacy Tsurusaki1 +o#t "nformation Sciences David <isintainer1 +o#t "nformation Sciences Hraham !hiteley Kob !ickham Lori !oehler Ray Mhang
$ther Contributors
3gnacio Avellaneda Hanesh Calakrishnan Tony Cailey Shelly Cird 8athan Cuggia Derick Campbell
At the re=uest of Microsoft1 The Center for 3nternet Security /C3S0 and the Jnited States Department of Commerce 8ational 3nstitute of Standards and Technology /83ST0 participated in the final review of these Microsoft documents and provided comments1 which were incorporated into the published versions.

Windows Server 2003 Security Guide

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Windows Server 2003 Security Guide

Caricato da

Copyright:

Formati disponibili

Microsoft Solutions for Security and Compliance

Windows Server 2003 Security Guide

3indows +erver 200) +ecurit" 5uide

3indows +erver 200) +ecurit" 5uide

3indows +erver 200) +ecurit" 5uide

3indows +erver 200) +ecurit" 5uide

3indows +erver 200) +ecurit" 5uide

3indows +erver 200) +ecurit" 5uide

Chapter 1: Introduction to the Windows Server 2003 Security Guide

3indows +erver 200) +ecurit" 5uide

Who Shou#d $ead %his Guide

Scope o& this Guide

Chapter .$ 6ntroduction to the 3indows +erver 200) +ecurit" 5uide

3indows +erver 200) +ecurit" 5uide

Chapter 1: Introduction to the Windows Server 2003 Security Guide

Chapter 2: Windows Server 2003 'ardenin( )echanis"s

Chapter 3: %he *o"ain +o#icy

Chapter ,: %he )e"ber Server -ase#ine +o#icy

Chapter .$ 6ntroduction to the 3indows +erver 200) +ecurit" 5uide

Chapter .: %he *o"ain Contro##er -ase#ine +o#icy

Chapter /: %he In&rastructure Server $o#e

Chapter 0: %he Fi#e Server $o#e

Chapter 1: %he +rint Server $o#e

Chapter 2: %he Web Server $o#e

3indows +erver 200) +ecurit" 5uide

Chapter 10: %he I3S Server $o#e

Chapter 11: %he Certi&icate Services Server $o#e

Chapter 12: %he -astion 'osts $o#e

Chapter 13: Conc#usion

Chapter .$ 6ntroduction to the 3indows +erver 200) +ecurit" 5uide

3ppendi! 3: Security %oo#s and For"ats

3ppendi! -: 4ey Settin(s to Consider

3ppendi! C: Security %e"p#ate Settin( Su""ary

3ppendi! *: %estin( the Windows Server 2003 Security Guide

%oo#s and %e"p#ates

3indows +erver 200) +ecurit" 5uide

Ski##s and $eadiness

Chapter .$ 6ntroduction to the 3indows +erver 200) +ecurit" 5uide

!lement $"ta#ic% Monospace font

Chapter 2: Windows Server 2003 'ardenin( )echanis"s

'ardenin( with the Security Con&i(uration Wi6ard

Chapter 2$ 3indows +erver 200) *ardenin& Mechanisms

Creatin( and %estin( +o#icies

3indows +erver 200) +ecurit" 5uide

&pply t'e %olicy wit' t'e SCW G()

&pply t'e %olicy wit' t'e Scwcmd Command*line Tool

Convert t'e SCW %olicy to a Group %olicy +b,ect

Chapter 2$ 3indows +erver 200) *ardenin& Mechanisms

'ardenin( Servers with 3ctive *irectory Group +o#icy

3ctive *irectory -oundaries

3indows +erver 200) +ecurit" 5uide

Chapter 2$ 3indows +erver 200) *ardenin& Mechanisms

3indows +erver 200) +ecurit" 5uide

3ctive *irectory and Group +o#icy

-ele"atin" &dministration and &pplyin" Group %olicy

Chapter 2$ 3indows +erver 200) *ardenin& Mechanisms

Group %olicy &pplication

3indows +erver 200) +ecurit" 5uide

Chapter 2$ 3indows +erver 200) *ardenin& Mechanisms

Security Template Mana"ement

3indows +erver 200) +ecurit" 5uide

Successful G%+ &pplication !vents

Sever /ole +r"ani1ational (nits