Ms Security Permissions Ch8

Passwords andPermissionsBy Roger Grimes

Keeping Your BusinessSAFE from Attack:

Passwords andPermissionsBy Roger Grimes

Keeping Your BusinessSAFE from Attack:

ContentsChapter 1 Defense in Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Security Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Defense-in-Depth Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Technology Is Not a Panacea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Computer Security Is About Minimizing Risk, Not Eliminating It . . . . . . . . . . . . . . . . 6Acceptable Use Policies Are Vital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Use the Least Privilege Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Minimize the Available Attack Surface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Require Authentication and Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Automated vs. Dedicated Hackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Physical Layer Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Data-Link Layer Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Network Layer Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Transport Layer Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Session Layer Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Presentation Layer Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Application Layer Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Incident Response Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1. Report the Incident to a Leader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132. Collect Initial Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133. Minimize Damage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134. Communicate with End Users and Management . . . . . . . . . . . . . . . . . . . . . . . . . 145. Collect More Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146. Get Assets Back to Production . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147. Verify That Eradication Steps Are Working . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158. Determine Public Relations Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159. Conduct a More Thorough Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Automating Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Role-Based Organizational Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Role-Based Group Policy Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Role-Based Security Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Local Computer Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

i

http://www.windowsitlibrary.com/Ebooks

http://www.microsoft.com/security

ContentsChapter 2 Windows Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Why Authentication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Authentication Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Password Hashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Windows Logon Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Types of Windows Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Windows Logon Authentication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

LAN Manager Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29NTLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30NTLMv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Authentication Service (AS) Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Ticket-Granting Service (TGS) Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Client-Server (CS) Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Kerberos Policy Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Why Not Use Only Kerberos? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Anonymous Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Disabling Anonymous Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Restricting Anonymous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Windows Logon Authentication Best Practice Recommendations . . . . . . . . . . . . . 41Remote Authentication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Extensible Authentication Protocol (EAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) . . . . . . . . . . 43Challenge Handshake Authentication Protocol (CHAP) . . . . . . . . . . . . . . . . . . . 43Password Authentication Protocol (PAP) and

Shiva Password Authentication Protocol (SPAP) . . . . . . . . . . . . . . . . . . . . . . . 43Unauthenticated Access Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Internet Information Service (IIS) Authentication Protocols . . . . . . . . . . . . . . . . . . . 44

ii



iii

Anonymous Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Basic Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Digest Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Integrated Windows Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45.NET Passport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45SSL/TLS Digital Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Microsoft Credential Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ContentsChapter 3 Protecting Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

The Windows Logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Local Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Domain Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Password Conflict Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Windows Password Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Computer Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Directory Services Restore Mode Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Service Account Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Creating Strong Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Password Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Applicant Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Secure Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Secure Credential Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59System Key Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Strong Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Password Length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Randomness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Password Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Dates of Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Offsetting Protections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Password Crackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66LOphtcrack (LC5) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Petter Nordahl-Hagen’s Offline NT Password & Registry Editor . . . . . . . . . . . . . . . . 67John the Ripper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68NTAccess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Winternal’s Administrator’s Pak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68EBCD-Emergency Boot CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Windows XP/2000/NT Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Austrumi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68O&O BlueCon XXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Password Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

iv



ContentsChapter 4 Securing File System and Registry Permissions . . . . . . . . . . . . . 70

Gathering Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Components of a Resource Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

OS Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Installed Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71File System: FAT and NTFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Local vs. Domain Logon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Account Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Group Membership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Group Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Built-in Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Correctly Applying Group Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Windows Trusts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Encrypting File System (EFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Software Restriction Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84Local Computer Policy and Group Policy Objects . . . . . . . . . . . . . . . . . . . . . . . 85User Rights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Security Identifiers (SIDs) and Access Control Lists (ACLs) . . . . . . . . . . . . . . . . . . . . 86NTFS/Share Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

NTFS Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Effective Permissions Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Registry Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Share Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Using Permissions to Secure Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Where Malware Hides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Securing the File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Securing the Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Securing File Associations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

What is a High-Risk File Association? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Blocking High-Risk File Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

v



ContentsChapter 5 Auditing to Detect Intrusions . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Intrusion Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Windows Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Security Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Event Message Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Other Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Audit Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Maximum Log Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Archiving Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Audit Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Audit Account Logon Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Audit Account Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Audit Directory Service Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Audit Logon Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Audit Object Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Audit Policy Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Audit Privilege Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Audit Process Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Audit System Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Per-User Selective Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Auditing Isn’t Perfect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Event Log Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Measuring Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Synchronizing Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120Logging Security Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Determining Log Rotation and Permanence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Centralizing Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Event Viewer Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121EventCombMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122Log Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Microsoft Audit Collection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Standardizing Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Filtering Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

vi



vii

Correlating Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Extracting Useful Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Setting up an Alerting System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Simple Windows Alerting Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Windows Event Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Other Third-Party Alert Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Auditing Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

ContentsChapter 6 Using Smart Cards and Two-Factor Authentication . . . . . . . . . . 129

Two-Factor Authentication and Smart Cards: The Basics . . . . . . . . . . . . . . . . . . 129Two-Factor Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Why a Smart Card? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Smart Card Physical Makeup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Contact vs. Contactless Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Smart Card Standards: Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Smart Card Standards: Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

The Personal Computer/Smart Card Specification . . . . . . . . . . . . . . . . . . . . . 134Smart Card Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

sidebar: Cell Phone Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Implementing a Two-Factor System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Identify the Processes that Require Two-Factor Authentication . . . . . . . . . . . . . . 136Consider: Smart Card or Token? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Using Smart Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Using Security Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Choose the Correct Token or Smart Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Weigh Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Define Service Level Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Ensure OS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Ensure Software Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Select a Certification Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Select Smart Card/Token Hardware Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Select a Back-end Authentication Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Set up Auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Staff Your Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Issues in Two-Factor Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143sidebar: Cell Phone Two-Factor Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Using Smart Cards in a Windows Environment . . . . . . . . . . . . . . . . . . . . . . . . . 144Certification Authority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Smart Card Distribution Pathway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Smart Cards Step-by-Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Installing the Smart Card Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

viii



ix

Templates and Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Web Enrollment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152Requesting an Enrollment Agent Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Requesting a Smart Card Certificate on Behalf of Other Users . . . . . . . . . . . . . . . 156Requesting a Smart Card Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Configuring Group Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158Requiring Smart Cards for Interactive Logons . . . . . . . . . . . . . . . . . . . . . . . . . . 158Requiring Smart Cards for Remote Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Remote Desktop/Terminal Services Logons . . . . . . . . . . . . . . . . . . . . . . . . . 160RRAS Logons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Smart Card Removal Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161When Smart Cards Can’t Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162More Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

General Smart Card Knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Microsoft Smart Card Deployment Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

ContentsChapter 7 Implementing Rights Management . . . . . . . . . . . . . . . . . . . . . . 164

Digital Rights Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Microsoft Media DRM Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164Windows Media Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Windows Rights Management Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166How RMS Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167Installing RMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168RM Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170RMS Policies and Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Information Rights Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173Rights Management Add-on for Internet Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . 177Custom RMS Applications and Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177For More Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Authorization Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Authorization Manager Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182Authorization Manager Online Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

Microsoft Identity Integration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184MIIS Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187Configuring MIIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187MIIS Password Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190MIIS Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190MIIS Online Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

x



1

Brought to you by Microsoft and Windows IT Pro eBooks

Chapter 1:

Defense in DepthKeeping Your Business Safe from Attack: Passwords and Permissions is a prescriptive guide to implementing security best practices in a Windows network environment. Many network administra-tors are vacillating about whether to implement an Intrusion Prevention System (IPS) or an IntrusionDetection System (IDS)—but they don’t have the basics done right. While they are building thickercastle walls and digging deeper moats, the bridge across the moat leading directly into the castle liesopen and unguarded.

Correctly implementing passwords and object permissions is easily the most important securitydefense you can use. Good passwords, strong authentication protocols, and appropriate permissionswill thwart a hacker more often than a heuristic antivirus scanner or deep packet inspection firewall.And it’s built into Microsoft Windows for free.

As Windows administrators, we all learn password and permission security in our introductoryadministration classes, but when we’re in the workforce, it is as if these skills are thrown aside in ourrush to buy the next hot security toy. Most Windows administrators don’t know the differencebetween LM password hashes and the Kerberos protocol; most don’t have an inkling about defaultNTFS permissions. The problem is that weak passwords and incorrectly set permissions allow a malicious intruder to trump the most sophisticated security tools you can deploy. Keeping Your Business Safe from Attack: Passwords and Permissions is an important look at the basics.

Chapter Summary This guide will provide an enjoyable and fact-filled journey covering Windows authenticationmechanics in seven chapters.

Chapter One, “Defense in Depth,” discusses the security principles that should drive all securitydefenses. Because you can’t defend against threats you don’t understand, a large portion of thechapter discusses password and permission attack vectors. Chapter One also covers the elements ofusable security policies that satisfy both technical and management objectives. The third section looksat incident response—how to respond when computer defenses fail. The last section focuses onautomating your security policy using Active Directory, Group Policy, and security templates. Thissection is an excellent tutorial for using Active Directory to support security objectives and how andwhen to use Microsoft’s new management tools.

Chapter Two, “Windows Authentication,” introduces the reader to authentication and the piecesof the security puzzle that any authentication protocol must cover. In particular, it covers differentWindows authentication protocols, ranging from logon authentication methods to remote access andweb server protocols. This chapter covers identity verification, SIDs, and Windows trusts. You learnthe difference between an authentication protocol and its password hash, which is more susceptibleto attack than the protocol itself. Chapter Two introduces Microsoft’s new Credential Manager software and ends with authentication best practices.

Chapter Three, “Protecting Passwords,” is dedicated to securing passwords. Although most of the world knows that complex passwords are an important way to prevent malicious hacking, fewenterprises require them. Learn how easy it is to defeat simple passwords, and see how a fewchanges can make your passwords a strong point in your security suite. Chapter Three also coversthe Syskey utility, disabling weaker password mechanisms, and strengthening security principalaccounts. It helps the reader develop a policy that supports password best practices.

Chapter Four, “Securing File System and Registry Permissions,” reveals simple strategies thatreaders can use to minimize successful exploitation. Although Windows Server 2003 is significantlyhardened against unauthorized attack, it is still indirectly vulnerable—unthinking users who executeevery malicious email attachment that heads their way can still cause problems. Chapter Four givesstrategies to prevent end users from hurting their computers and your networks. Learn about all themechanisms that affect permissions, including share permissions, ACLs, and Encrypting File System.Using file and registry permissions, you can prevent end users from executing file attachments andfrom installing myriad types of spyware.

Chapter Five, “Auditing to Detect Intrusions,” covers Windows auditing tools, event log management, and intrusion detection. You may know how to turn on auditing, but do you knowwhich auditing category to enable to catch invalid IIS authentications? Do you know how to set upan alert so that you know when an Internet scanning worm has been successful? How do you goabout retracing the steps of a hacker who has successfully exploited your server? Learn about auditingand how to implement it to detect intrusions.

Chapter Six, “Using Smart Cards and Two-Factor Authentication,” covers Windows support ofsmart cards and other two-factor authentication devices. If password authentication isn’t already toobasic for your employer’s security needs, it soon will be; password authentication will becomeinsignificant for protecting your home computer as well. Two-factor authentication is being used tostop phishing attacks, is included on medical information cards, and may even be used by yourhometown bank. Learn the intricacies of implementing smart cards, including the basics of the publickey infrastructure, and two-factor authentication in your company and at home.

Chapter Seven, “Implementing Rights Management and Authentication Solutions,” coversMicrosoft’s new authentication and digital rights management solutions: Digital Rights Management,Authorization Manager, Rights Management Server, and Identity Integration Server. Microsoft’s con-tinued commitment to improving security has led to authentication and digital rights managementproducts ready to take us forward. Learn how each works and where it fits in your organization.

By the time you finish this book, you will be a master of your domain...and Active Directoryforest.

Security Principles In the corporate world, accountants are charged with correctly booking debits and credits for anytype of financial transaction that the business world can conduct. Recording transaction results can bea challenge to an accountant, given all business transactions that are possible in today’s world. But ifthe accountant chooses incorrectly, the CEO can be dragged into court and sued by investors. Forthis reason, accountants have a general set of accounting rules that guide any transaction that theymight have to account for. One common rule is this: expenses must be matched against the revenuesthey create.

2 Keeping Your Business Safe from Attack: Passwords and Permissions


Although the guiding principles for security administration aren’t as longstanding and formal asaccounting rules, knowing them gives you a head start in creating a secure network. They include

• Follow a defense-in-depth, or multiple-layered, security model• Don’t believe that technology is a panacea• Develop and enforce acceptable-use policies • Grant the lowest possible level of privilege to users • Minimize your network’s surface area • Require authentication and confidentiality

These principles should guide every computer security decision an administrator makes.

Defense-in-Depth Model The most commonly discussed security principle is that of defense-in-depth. Defense-in-depth dictatesthat multiple, duplicate layers of defense are preferable to a single line of defense. Although multipledefenses can be more complicated to manage, they usually give you more secure defense againstintruders.

For example, to fight malicious mobile code, running two or more antivirus scanners, each in adifferent location, theoretically stops more malicious software (malware) than running only oneantivirus program. If you have a network perimeter firewall in place, you should still strongly consider installing a host firewall on every PC. If your firewall can perform intrusion detection, consider adding a dedicated intrusion detection device as backup or install one as an early warningsystem on the LAN.

The defense-in-depth is applicable to an operating system as well. Windows files and folders aretypically protected by NTFS and Share permissions, though as we learn in Chapter Four, many otherfactors are also involved. According to old-school advice, you should give the Everyone securitygroup Full Control permissions on all new shares. In fact, legacy Windows server operating systemsused that as the default setting. Security was then controlled using correctly set NTFS permissions.The thinking was that the NTFS permissions, which are in effect for local and network logins, wouldestablish the correct, effective security. And if the permissions are always set up correctly, every time,this strategy is successful.

In contrast, the defense-in-depth model dictates setting the correct permissions with the leastamount of permissions needed for both NTFS and Share permissions. In this way, if an administratorforgets to correctly set one type of permission, the other type minimizes the mistake. This newmindset is reflected in Windows Server 2003’s default Share permission for the Everyone group—only the Read permission. I suggest using even tighter controls. The Everyone group should have nopermissions to newly created shares unless that is the desired effective permissions.

Defense-in-depth followers believe that multiple defenses are better than one. What one defensemisses, another defense might catch. This mindset assumes that a single defense will fail—because it’strue; individual defenses fail. Human beings make mistakes; perfect implementations are hard to sustain over long periods of time. Providing multiple layers of cost-effective defenses minimizes mistakes and unexpected exploits.

Chapter 1 Defense in Depth 3


In December 2000, the defense-in-depth concept was formalized in the ISO’s 17799(http://www.17799.com/index.php) publication as an internationally agreed-upon best practice.

Figure 1-1 shows the multiple layers of defense for a typical network environment.

Figure 1-1Defense-in-depth model

The model starts with the Physical Defense layer; here, the computer resource must be protectedagainst unauthorized physical access. If malicious hackers can access a physical computer, they cando anything—it’s game over. They can circumvent any security device, crack passwords, corrupt data,format hard drives, or destroy or steal the computer.

At the Network Defense layer, the focus is on protecting the network perimeter. The mostcommon defense at this layer is a centralized firewall. Other network defenses may include gatewaytools, network IDSs, and access control lists for routers.

This guide concentrates primarily on the Host Defense layer, which includes all computer-baseddefenses that are designed solely to protect the host machine where they are installed. Defenses forthis layer include desktop-based antivirus scanners, host-based firewalls, host-based IPSs, updatepatches, and securely configured operating systems and applications.



PhysicalDefenses

NetworkDefenses

Host Defenses

ApplicationDefenses

Data Defenses

http://www.17799.com/index.php

As defenses for the Network layer become more permeable, the Host Defense layer is becomingmore important. Before, the perimeter firewall stopped Internet scanning worms; now, the worms aresneaking in on unpatched laptops and unsecured VPNs that tunnel through the firewall.

Applications are attacked more often than operating systems. An attacker who forces an application to execute an unauthorized behavior can gain control of the machine. If an application iscommonly installed on a particular platform, it will often be used in attacks. For example, hackersknow that Internet Explorer (IE) is installed and used on most Windows computers; therefore, if theycan successfully exploit IE, they can reach Windows and the innocent end user. Too, applications likeMicrosoft Office are cross-platform—they run on Intel-compatible and Apple computers. With onemacro virus, a malicious coder can infect both platforms. Even seemingly simple, innocuous programslike Notepad can be used maliciously to overwrite important files or execute unauthorized programs.Notepad’s developers probably didn’t foresee the creative ways hackers could use it to do maliciousdamage.

Applications can become more secure only if their developers work harder to write more-securecode. Application defenses can be subdivided into two categories. Defenses in the first category try tomake the application coding itself more secure; examples include defenses against buffer or stackoverruns. Defenses in the second category focus on protecting the application data from being usedmaliciously by the application—for example, input validation.

Microsoft requires each programmer to attend secure coding classes and participate in designingsecure code from the ground up. Besides this education, Microsoft has processes and tools in placeto catch vulnerable code and a strict regime of internal and external code reviews. No longer is security allowed to be an afterthought in application design. It is an essential part of the process,changing application design and coding in the same way that the course of a stream is determined by its banks.

Data Defense, the last network layer, uses a two-pronged approach. First, data should be confidential and viewed only by authorized users. To that end, applications that hold data are writtento prevent the unauthorized access of confidential data. Second, data structures can prevent data from being used in malicious ways—for example, in macro viruses. This approach too requires anapplication-driven defense. Malformed data structures can be used in buffer overflow attacks, MIME-type mismatches, and scripting viruses, among other attacks. Data structures and applicationsmust be built to minimize the possibility of malicious use of data.

Administrators should consider all seven layers of their network when developing security strategies and should include multiple defenses on each layer, when practical and cost efficient.

Technology Is Not a Panacea It is crucial that administrators understand this guideline: no technology can guarantee a securesystem. An innocent end user can unknowingly violate the best security defense. In password studies(http://news.bbc.co.uk/1/hi/technology/3639679.stm and http://www.theregister.co.uk/2003/04/18/office_workers_give_away_passwords/), a large percentage of end users revealed their passwords to a stranger on the street for a small prize like candy bar or pen. Some end users openany file attachment, no matter how many times they have been warned not to. Some of the mostfamous hackers, like Kevin Mitnick, spent more time gaining unauthorized access using social engineering tricks than with sophisticated hacking tools. No matter how good your firewall or security



http://news.bbc.co.uk/1/hi/technology/3639679.stm

http://www.theregister.co.uk/2003/04/18/office_workers_give_away_passwords/

http://www.theregister.co.uk/2003/04/18/office_workers_give_away_passwords/

defenses are, if a malicious hacker can trick the end user into executing an untrusted file, yoursystem is not secure.

For this reason, when building your security defenses, you must assume that end users willignore everything you tell them; therefore, you must prevent malicious code from ever getting to theend user. Further, a good defense-in-depth plan minimizes the damage that can occur even when the end user executes malware. For example, if malicious code reaches a logged-in user with administrative permissions, that code can do more harm than a non-administrative user. An inclusivesecurity strategy includes end user education, mostly to enlighten users about the most obviousthreats. But end user education is no more a panacea than technology. Use both liberally in yourcomputer security defense plan.

Computer Security Is About Minimizing Risk, Not Eliminating It A computer under your control will be exploited—the only question is when, not whether. Somedaya hacker will do something unauthorized to a computer your organization values. No matter howhard you try, no matter which antivirus scanner product you use, a virus or worm will be successfulin infecting a computer you protect. Perhaps an authorized internal network user will do somethingunauthorized. Your defenses cannot prevent every malicious act. A perfectly secured computer andnetwork is an unusable computer and network. Computer security is about minimizing risk, not eliminating it. Eliminating all risk incurs costs that are not offset by benefits. The best you can do isreduce security risks to an acceptable level, one agreed to by your management, using the care that areasonable person in your position would exercise.

As an administrator, you should never adopt the mindset that you will win every time. Hackershave the easier job. Administrators are pitted against a much larger group of maliciously minded individuals. You can secure your system 99.9 percent of the time, but the one exploit you don’texpect can start and finish before you even get out of bed. For example, the Slammer worm infectedmost of its victim computers in fewer than 10 minutes. Forget downloading the latest virus definition—the attack was over hours before most administrators had even heard of it.

Administrators need to embrace that computer security is a mostly thankless job against a foe that will probably win, at least occasionally. A defense-in-depth strategy uses detective and correctivecontrols to minimize the damage. Detective controls will be covered in Chapter 5, “Auditing to DetectIntrusions.” Using multiple corrective controls is the basis of the defense-in-depth strategy. Alwaysexpect one control to fail, and have another control set up to be its backup.

Acceptable Use Policies Are Vital As discussed above, the weakest link in most networks is the end user. Every company shoulddevelop an acceptable use policy (AUP) that spells out what is and isn’t acceptable use of companycomputer resources. Without a documented and signed AUP, an employee can claim ignorance when caught doing something unauthorized. Employees should sign an AUP on their first day ofemployment and sign the AUP again as part of any end user education program.



An AUP should include an explicit statement about the level of privacy an employee can expectwhen using computer resources, such as email and instant messaging. You can use an Internet searchengine to find published AUPs to use as your own template if you company doesn’t currently havean AUP.

Use the Least Privilege Principle The least privilege principle security guideline states that users (as well as services and computeraccounts) should have the minimum amount of access they need to perform their authorized function. Users should not be granted permissions that they don’t need.

This principle also applies to computer professionals in the company. Some malicious attacksrequire that the login user have a highly privileged account. If you can minimize the number and theuse of highly privileged accounts, you can reduce attack risk.

Minimize the Available Attack Surface No PC needs to have 131,071 ports—65,535 TCP ports plus 65,535 UDP ports—open to the world.Most PCs only use a few dozen of their ports. By installing a host-based firewall, thereby reducingcontactable TCP/IP ports from more than 130,000 to a few dozen, you can significantly reduce thepotential attack surface area that a hacker can exploit.

You can also reduce your attack surface by using the least privilege principle to correctly configure security permissions, requiring authentication, tightening application settings, enabling pre-ventative controls, and removing or disabling unused applications and services. Reducing the surfacearea that is open to attack reduces the malicious attacker’s options.

Require Authentication and Confidentiality A secure network requires non-anonymous authentication and ensures confidentiality by default.However, this requirement is not currently the norm. In today’s Internet world of default anonymity,hackers and malicious coders attack with relative impunity. Spammers ignore federal laws. Viruswriters release their latest creations. Why? Because they are hard to catch.

The Internet is quickly moving to a model of default authentication. In the near future, users and servers who work anonymously will not be allowed to connect to most business networks—theyrepresent too much risk. In general, there is no good reason to guarantee anonymity; there are a fewexceptions, so anonymous networks will always be available for those uses. However, the default will soon be authenticated networks, authenticated users, and authenticated programs. Along withauthentication, encrypted communications will become the norm as assured confidentiality and privacy become expected.

NoteRead Microsoft’s 10 Laws of Immutable Security (http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx) and Microsoft’s 10 Laws of ImmutableSecurity Administration (http://www.microsoft.com/technet/archive/community/columns/security/essays/10salaws.mspx). Both papers are quick, enjoyable reads and deliver guidingsecurity principles that are almost as important as the guidelines listed in this document.

n



http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx

http://www.microsoft.com/technet/archive/community/columns/security/essays/10salaws.mspx

http://www.microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx

http://www.microsoft.com/technet/archive/community/columns/security/essays/10salaws.mspx

Attack Vectors To create good defenses against malicious attacks, you have to be able to understand the differenttypes of attacks. Attacks can occur along every layer of the OSI model, from the Physical layer to theApplication layer, and can originate from a dedicated hacker or from automated code, as Figure 1-2shows. Malicious code can enter a computer from any input device, be it a floppy disk, network connection, USB connection, or commands typed at the keyboard. Most of today’s attacks occuracross networks, the Internet in particular. However, network attacks can make use of email, VPNconnections, wireless connections, peer-to-peer networks, instant messaging, web browsers, andmedia players.

Figure 1-2Potential attack vectors

Automated vs. Dedicated Hackers Although most attacks are automated, dedicated human hackers do exist, and their attacks can besophisticated and sublime. Human attackers have the opportunity to modify their attack, dependingon what they find. For example, a hacker may originally explore a computer hoping to find a vulnerable SQL server and find instead an unpatched version of IIS 4. At that point, the hacker canthen pull out IIS 4 exploits and gain access to the server.

Automated code, on the other hand, often attacks the host without regard for the likelihood ofthe success of that exploit. For example, the Slammer SQL worm didn’t know or care whether anintended host was running a vulnerable version of SQL. It tried its exploit and moved to the nexthost. Most of the hosts it tried were not running SQL. Is running an exploit against every computeryou find, regardless of potential weakness, a successful strategy? Although it seems inefficient, it is



TravelingWormsMacro

VirusesFile and

Boot Viruses

LaptopUsers

DedicatedAttacker

E-mail Attacks

HTMLE-mail Instant

Messaging

RemoteUsers

BrowserThreatsP2P

Networks

UnsecuredVPNs

WirelessAttacks

PDA andMobileDevices

Your PC or Network

apparently effective. For example, the SQL Slammer worm infected nearly every one of its victim inthe first 10 minutes of its release (http://www.cs.berkeley.edu/~nweaver/sapphire). Because it wasreleased in the early morning hours for most of the United States, the attack had been essentially overfor hours by the time most administrators even got out of bed.

Computer viruses, Trojan horses, and worm programs account for a large percent of attacks. Usually, they arrive as a file attachment to an email message. The unsuspecting user opens the attachment, and then the malware executes. Most malicious mobile code threats today use a combination of strategies, such as using the mechanisms of a Trojan horse and a worm. The emailclaims that the file attachment is something else, which is a Trojan horse trick; when the user opensthe file, the worm portion burrows into the system and begins replicating. The malware tries toembed itself into Windows so that it is run again when the computer restarts, often manipulating theregistry database or tagging along with another legitimate program.

NoteComputer viruses aren’t as successful on newer versions of Windows, now that systemexecutables are protected by Windows File Protection and, on Windows ME, System FileProtection.

Physical Layer Attacks Once an attacker gains physical access to a machine or network, a multitude of attack options can be performed. For example, even the best NTFS permissions and authentication will have difficultlyprotecting data if the intruder can bypass the controlling operating system; however, EFS can still provide protection if it is enabled and used. A boot virus can still readily disable any Windowsmachine. Some security professional are concerned about the consequences of USB “thumb” memorydrives. An attacker could copy data to the USB drive or copy a malicious payload to the computerand be gone quickly before anyone notices. An intruder can even install a keystroke logger programto record another user’s keystrokes and, therefore, passwords. An intruder connected to the physicalnetwork can inject malicious code, cause denial-of-service attacks, and sniff unprotected data acrossthe network wire.

Defenses against physical attacks include physical perimeter security, such as locks, gates, andcontrolled room access; smart cards; encrypted files; and biometrics. It’s also a good idea to disablebooting from removable media drives.

Data-Link Layer Attacks Data-link layer attacks occur at the network frame level, where network packet types are convertedfrom physical bits to 1s and 0s and then formatted in a particular network frame type (e.g.,Ethernet_II, Ethernet_802.2). Most data-link attacks involve intruders injecting an overwhelmingamount of bogus network traffic or manipulating the address resolution protocol (ARP) to redirecttraffic toward a malicious host.

For example, in an ARP spoofing attack, when any network host sends a broadcast looking for aparticular IP address so it can send its communications, the malicious host replies along with thelegitimate host. If the malicious host’s ARP reply packet beats the legitimate reply, the originating host

n



http://www.cs.berkeley.edu/~nweaver/sapphire

contacts the malicious computer. The malicious host often relays packets between the original sourceand destination computers, completing a successful man-in-the-middle attack.

Rogue DHCP servers that assign unauthorized IP addressing information also qualify as data-linkattacks.

Defenses include authenticated network communications, and using network equipment andoperating systems that are not susceptible to Layer 2 or ARP flooding attacks. For example, some Ethernet switches prevent MAC flooding by not allowing multiple MAC addresses to originate on asingle network port. Another defense is to institute rate controls so that no one device or port canoverwhelm the network.

Network Layer Attacks Network Layer attacks include exploits at the network protocol level and include IP address spoofing,fragmentation attacks, protocol anomalies, denial-of-service attacks, and the PING of death.

Another example of a network layer attack is a smurf attack. In a smurf attack, a ping (ICMPecho) request is sent to a network segment’s broadcast address, forged with an origination addressfrom the intended victim. Because the ping packet is sent to the broadcast address, some networksthen send the ping request to all hosts on the segment, which, in turn, all reply to the intendedvictim. If sent in sufficient quantifies, smurf packets create a denial-of-service condition at theintended victim computer and often on the entire segment.

Defenses against network layer attacks include firewalls, IDSs, TCP/IP stack hardening, anddefenses at the host operating system.

Transport Layer Attacks Transport Layer protocols include TCP and UDP. Attacks at the transport layer include anomalousTCP flag combinations, port scanning, and SYN floods.

Port scanning occurs when a remote hacker sends multiple packets to ports that might be open on a computer host. If a port is active and reachable, the intruder then maps which ports andservices are open to attack. Malicious hackers have become quite creative in the types of packetsthey send during a port scan. They may even send one packet at a time, waiting a long timebetween packets so as to not trigger alerts or responses from an IDS or firewall.

Defenses against transport layer attacks include authenticated data communications, firewalls,IDSs, and TCP/IP stack hardening.

Session Layer Attacks Session layer attacks are becoming more widespread as Internet worms try new tactics. Session layerprotocols include RPC, NetBIOS, SSL, and peer-to-peer protocols such as IRC and ICQ.

Session layer attacks can be prevented using authentication, firewalls, and secure (and bug-fixed)applications.

Presentation Layer Attacks Data than an application uses is often represented in the presentation layer. Design flaws in the datastructure or application may let malformed data corrupt the program or may result in unauthorizedactions.



For example, last year Portable Network Graphic (PNG) files were reported to be used in anexploit. A malformed PNG file, if appropriately constructed, executed a buffer overflow attack on themachine where it was opened. This particular attack was successful because the underlying PNGcode library contained a null-pointer error in its coding.

Other presentation attacks include MIME-type mismatches. In mismatches, a downloaded mediafile includes a header that claims to be one type of file—a type that bypasses security checks—butthe file really is a malicious file. For example, end users may think they’re downloading a simplegraphics file as a GUI “skin” for their media player; however, the file really contains embedded malicious Javascript coding.

Presentation layer attacks can be reduced using firewalls, IPSs, secure applications, and patchmanagement.

Application Layer Attacks Popular applications are often victims of their own success, indirectly inviting hackers to look for programming flaws that leave the application vulnerable to buffer overflow attacks. If the applicationhas even one bad stack instruction, a remote hacker can use malformed data to create a denial-of-service condition or take complete control of the compromised machine.

Application attacks also include directory transversals, email worms, computer viruses, Trojanhorses, and spam. To prevent application layer attacks, use the same defenses you use against session layer attacks. It also helps if you uninstall unnecessary software and services.

Damage doesn’t have to be inflicted maliciously or intentionally. A user who accidentally writesover an important data file or unknowingly installs spyware isn’t intentionally causing harm. A well-designed security plan take into account both intentional and unintentional acts and plans configurations accordingly.

Sometimes misconfigured security is all it takes for a system to be compromised. For example,not giving local administrator privileges to end users will prevent them from installing many unautho-rized software programs. Similarly, sensitive files on shared directories should have read-only permis-sions if the user doesn’t need to modify the files.

Security Policy Computer security isn’t won by tracking the latest hacker or by installing the latest security gizmo.Instead, it is won or lost in the day-to-day—in the trenches of policies, procedures, and best practices. The best security administrator has a boring job because all the holes are plugged and theintruders are kept outside the network.

Real computer security begins with a computer security team that determines the best securitybest practices for maintaining the most secure environment possible, given a specific cost/benefit scenario. These best practices must be researched, discussed, and tested. Then they should be documented and communicated to all employees in an organization. Periodic audits should be conducted to ensure that recommended practices are being followed consistently.

It’s easy to do a one-time pass on all PCs and institute secure settings. But can your companymaintain a consistent level of security over a long period, including a period in which you add newcomputers, new employees, vendor computers, and consultants? That’s the real challenge.

A good computer security policy is a document that details specific actions, rules, and proceduresto follow when configuring and maintaining computer assets. A security policy should cover



everything relating to data communications and computing, including purchasing, evaluating, settingup computers, performing ongoing maintenance, providing support, and training users.

The SANS Institute (http://www.sans.org) has an excellent portal about developing security policies, including many example policies (http://www.sans.org/resources/policies/#name). Severalother web sites have also published security policies, guidelines, and recommendations.

Here are a few possible information security policies for a typical company:• Acceptable Encryption Policy—determines the encryption algorithms used• Acceptable Use Policy—specifies how computer equipment and services are used and the

employee’s responsibility for security• Analog/ISDN Use Policy—covers use of fax lines as well as computer modem connections• Anti-Virus Process—specifies how the risk of virus infection will be minimized• Application Service Provider Policy—defines the minimum level of security an application

service provider must be able to provide to be considered as a vendor• Acquisition Assessment Policy—lays out responsibilities for acquiring computing assets• Audit Vulnerability Policy—specifies the scope of authority of the security team to perform

audits to safeguard, monitor, and investigate a company’s security• Database Credentials Coding Policy—defines how database credentials are securely stored and

retrieved• Dial-in Access Policy—covers how dial-in access to a network may be granted and used by

employees or vendors• Email Policy—provides standard practices for email content to ensure your company’s

professional reputation • Ethics Policy—specifies ways to maintain a company’s integrity in business • Extranet Policy—defines criteria that must be met by external companies that want to sign on

to your company’s networks• Information Sensitivity Policy—sets standards for classifying and protecting a company’s

sensitive information• Internet DMZ Equipment Policy—determines policies for use of computer resources that your

company owns that are operated outside the company’s firewall (the demilitarized zone)• Password Protection Policy—specifies how to create, protect, and change sound passwords• Remote Access Policy—sets standards for connecting to a company’s network from any

computer outside the network • Risk Assessment Policy—states how the security team will identify, evaluate, and fix risks to

the security of a company’s information infrastructure • Router Security Policy—specifies security criteria for laying out routers and switches• Server Security Policy—provides standards for secure configuration of servers in a company’s

network• Third Party Network Connection Agreement—lays out the legal and infrastructure requirements

for connecting a third party’s network to your company’s network• VPN Security Policy—defines the requirements for virtual private network connections• Wireless Communication Policy—specifies standards for connecting to your company’s

network using wireless technology



http://www.sans.org

http://www.sans.org/resources/policies/#name

As you can see, your organization may require many kinds of security policies to adequately protect all its resources. The keys to a good security policy, or to a suite of security policies, are completeness, enforceability, accountability, and management support.

Incident Response Plan A successful compromise will happen. How you and your team respond determines whether you end up looking like a bumbling detective or Sherlock Holmes. Good incident response, like goodcomputer security, requires practicing policy and procedure. A good starting point is to determine thesize of security incident that is officially worthy of an incident response team. For example, which ofthe following incidents requires a team response?

• Any compromise of a critical asset• Unauthorized disclosure of confidential information• 10 or more machines with an email malware outbreak

It’s wise to anticipate occasional incidents and implement a plan to deal with threats quickly andefficiently. An incident response team should include the following people:

• Team leader• Team members with expertise in each covered technology• Outside vendors, if additional areas of expertise are needed• Communications specialist to communicate with end users and management

Although each security incident is different, here is a basic set of steps to follow when an incident occurs.

1. Report the Incident to a Leader No matter how the incident is first noticed, the first team member to hear about it should alert theteam leader and then the other team members. The communication method you use for these alertsshould be fast, reliable, and not prone to interruption by the very events to be reported.

For example, if you routinely send critical pages to team members via an Internet email addressgateway, what if the email gateway is clogged with malicious code emails? You need to plan an alternate communication method. Some teams manually dial a list of pager numbers if an email threatis involved; others use cell phones or HTML-based email.

2. Collect Initial Facts After they are notified, team members should start sharing what they know about the incident. Howmany computers are compromised? Is the attack still active? What data has been compromised? Howis the compromise occurring? When did it first occur? Begin to collect the facts needed to get anintroductory understanding.

3. Minimize Damage After you have a set of initial facts, immediately take steps to minimize the damage. If the vulnera-bility is Internet-related, disable Internet access. If intruder or malicious code is actively modifying ordestroying files on a computer, disable connections. If the attack is bad enough, consider poweringdown the assets that are involved. However, keep in mind that powering down compromised assets



should be a last resort at this stage, because you need to collect forensic evidence, and poweringdown computers affects the data.

4. Communicate with End Users and Management Make sure the word gets out to all affected end users. They should know about the incident andhave instructions for proceeding with their work. At the same time, don’t spread the informationbeyond parties who are directly affected. At this point, your intent is to minimize unneeded access tothe assets involved.

At the appropriate time, contact management, too. Although you may not want to contact management until all the facts are known and you can communicate what you are doing to resolvethe problem, you also don’t want management to find out through unofficial channels.

5. Collect More Facts By now, you should have the intrusion somewhat contained and taken the steps to prevent furtherdamage. At this time, you need more information. Finding out what isn’t compromised is as importantas knowing what is. If every computer but one in a particular department or of a particular configura-tion is compromised, find out what is different about that computer. If the compromise should havebeen prevented by your defense tools, figure out how it got by.

Determine the extent of the damage. How widespread is it? How many computers? How manydepartments hit? What did the exploit do to the computer? Did it drop off other files, rename files,overwrite files, make registry changes, or insert itself in the startup areas? When gathering forensicevidence, consider the following:

• Find out what files have been modified during the exploit• Check various startup areas, looking for suspicious inserts• Look for suspicious network or Internet connections• View suspicious files, looking for any revealing statements

Team members investigating different computers or areas should compare notes. Did the exploitconsistently do the same thing? Are the system modifications consistent between computers? Collectand log all the evidence. Make a verified disk image copy of any impacted hard drive. Two copiesare better—one copy can be used for forensic exploration, while the other is preserved as an unmodified control disk and can be used to make future copies.

6. Get Assets Back to Production Now it’s time for further action. Take what you have learned and implement a methodical eradication plan. Close the vulnerability that allowed the exploit. Remove or replace any damaged orinfected files. Consider reformatting the computer, reinstalling a fully patched operating system andapplication, and restoring data files from a known clean backup copy. Being thorough is the onlytrue way to assure that Trojan code, which a hacker use to gain access or cause further damage, wasnot left behind. Use a predefined communication mechanism to alert end users and to give additionalinstructions. If appropriate, allow assets back online to production status.



7. Verify That Eradication Steps Are Working Send members of your team to verify that computers are remaining unexploited and to monitor communication channels for problems. Sometimes, at this point, I have found out that the teammissed some information during the initial analysis stage. If this is the case, modify the eradicationplan appropriately and redistribute it to all affected computers. Communicate the status of the cleanupto end users and management.

At this point, you can relax a little. The incident response team can disassemble and go back totheir normal duties.

8. Determine Public Relations Impact Discuss the exploit’s impact on end users, the company, operations, external customers, and businesspartners. If the exploit spread from your company to other companies or involved private customerdata, now is the time for legal review. Notify any required reporting agencies, and decide if lawenforcement needs to be involved. Also consider how you or the public relations department willrespond if the news media calls your company. The text of the response should be documented inyour security plan.

9. Conduct a More Thorough Analysis Now that the crisis is over, analyze your information more thoroughly. By this point, you should fullyunderstand what the exploit did. Use your new analysis to repair remaining damage. Determinewhether your defense plan or tools had flaws that allowed the exploit to be successful.

After performing a more thorough analysis of a security event, it’s very important that the knowledge you gain is fed into the system and that you make requisite changes to your security.Otherwise, the response team didn’t really make the network safer.

You can also use collected statistics and metrics from this incident in future budget talks to justifythe expense and effort of a security program.

Automating Security Microsoft has provided many security tools that are unequaled on any platform. How many operatingsystems have a tool that lets web servers across 15,000 computers world-wide be disabled in 15 min-utes? If you use an Active Directory forest and Group Policy Objects (GPOs), you can with Windows.This section discusses the fantastic tools available with Active Directory domains and forests.

Active Directory is an x.500-compatible directory service that can be installed with Windows 2000Server or Windows Server 2003. Windows 2000 Professional, Windows XP Professional, and relatedserver platforms can also participate in an Active Directory forest.

One of the key structures in Active Directory is an organizational unit (OU). An OU lets youorganize users, computers, and other objects (such as groups, printers, and shares) logically under theActive Directory root structure. You can create and organize OUs in almost any way that makes network objects easier to locate and manage.

Role-Based Organizational Units From a security perspective, the OUs should reflect shared roles of users and computers. This meanscreating an OU for every shared role to group computers or users with common security needs. AnOU should be created for every user’s role. At the top of the structure, users, workstations, servers,



and domain controllers should have different OUs. You can create OUs under this upper level,breaking down the parent OU into separate OUs based on each user’s participatory role and securityrequirements. For example, common user roles include executive management, IT help desk, administrative assistants, accounting and data entry workers, and payroll supervisor. Often OU structure can follow a company’s organizational chart.

Use the same philosophy to separate file server and workstation roles. You can further separateworkstation roles according to the end user or, for example, by desktop versus laptop users. Fileservers should be separated according to their network infrastructure role—for example, file server,print server, web server, mail server, digital certificate server, RADIUS server, domain controller, DNSserver, member server, and bastion host.

Often, production networks have multi-purpose servers, such as a file and print server acting as adomain controller. The OU structure should handle whatever roles are present in the network. Figure1-3 shows an example OU structure based on simple, single-role servers.

Figure 1-3Example role-based organizational unit structure

You create OUs for specific roles so that you can apply security settings to users and computersbased upon their common needs. For example, in Figure 1-3, the member servers are structuredbelow a parent OU called Member Servers OU. At the parent level, you apply all the security settings



MemberServers OU

DomainControllers OU

WorkstationOU

Mobile PC’sOU

EndUserPC’s OU

File

Infrastructure

CA

IIS

IAS

Print

that are common across all member servers, such as disallowing the Log on Locally permission tonormal end users or disabling non-necessary services. Then each lower OU holds servers performinga particular role; in those OUs, you apply permissions common to those computers. On the certificateauthority server computers (CA OU), I would disable DNS services, IIS, print services, and any otherservice not explicitly needed for a server functioning as a certification authority.

The key is that identical computers and users with identical roles should be configured withidentical security. By creating role-based OUs, to which you apply common security settings, you canensure appropriately applied security. And once the role-based security infrastructure is developed,applying appropriate security is as easy as placing the user or computer account into the appropriateOU.

Role-Based Group Policy Objects Next, you want to create role-based group policy objects (GPOs) for each role-based OU. A GPO isan Active Directory object that you can use to define thousands of computer settings. With a GPO,you can automate configuration settings to user or computer account objects; without a GPO, youwould use registry edits or make changes from a GUI. The kinds of configuration settings you canautomate with GPOs include:

• Registry permissions and key values• File and folder NTFS permissions• Software installation• Service startup types and permissions• Enabling auditing• Password policy• IPSec policy• Application settings• Digital certificate trusts• User privileges• Logon scripts• Acceptable authentication protocols

Using the Automatic Updates service, clients pull down GPOs from Active Directory and applythe contained settings. Creating a separate GPO for each role-based OU gives you identical role-basedGPOs. Of course, the default GPOs (Default Domain Policy and Default Domain Controllers Policy)should be appropriately configured to account for settings shared among all computers and users.

Role-Based Security Templates The last step is creating and applying role-based security templates to the appropriate role-basedGPOs. Security templates are text files; they contain configuration settings that can also be defined inthe Security Settings container object of GPOs. Using the Security Configuration and Analysis consolesnap-in tool, you can create role-based security templates that contain the settings that are appropriatefor each user and computer role. Then you simply attach the role-based security template to therelated role-based GPO, and attach the GPO to the appropriate role-based OU, as Figure 1-4 shows.



Figure 1-4Role-based security automation

Microsoft provides many predefined security templates for all computers in Windows 2000 andlater in %Windir%\Security\Templates. Microsoft provides security templates that follow server rolerecommendations in Threats and Countermeasures: Security Settings in Windows Server 2003 andWindows XP security guide, located at http://go.microsoft.com/fwlink?LinkID=15160.

They provide templates in three categories: legacy, enterprise, and high-security segments. Legacy templates are for networks with systems prior to Windows 2000. Enterprise templates are for organizations running Windows 2000 and more recent versions that have normal security requirements. The high-security templates are for organizations that need restricted security. Thesetemplates can be used as a starting point for your own organization. Figure 1-5 shows an example ofrole-based security using Microsoft’s security templates.



Role-based SecurityTemplate

Role-based GPO

Enterprise Client-IISServer Role.inf

http://go.microsoft.com/fwlink?LinkID=15160

Figure 1-5Example role-based security using Microsoft templates

The whole key is to create an Active Directory structure that supports security automation basedupon work roles. If you think about it, Windows administrators have been approximating this type of security since the first Windows server operating system, without necessarily formalizing oursystem. For example, when installing an accounting application, you may give different users variouspermissions they need to access the appropriate parts of the application. Role-based security automation takes the concept used for a single application to a new level.

Local Computer Security Policy Every Windows computer running at least Windows 2000 comes with a local computer securitypolicy; to access it, type gpedit.msc on the Run line. If the Local Computer Policy object contains any settings, it is applied to the computer on boot up and to the user on logging in. It contains mostof the security settings you could otherwise set using an Active Directory GPO. When a domain computer and user logs into a domain, any applicable GPOs are downloaded to the computer. If anysettings on the Active Directory GPOs conflict with the Local Computer policy, the Active DirectoryGPO wins.



EnterpriseClient-

MemberServer

Baseline.infEnterprise

Client-MemberServer

BaselinePolicy

MemberServers OU

DomainRoot

DomainControllers

OU

EnterpriseClient-Domain

Level Policy

EnterpriseClient-Domain

Level.inf

EnterpriseClient-DomainControllers.inf

EnterpriseClient-File

Server Role.inf

EnterpriseClient-IIS

Server Role.inf

EnterpriseClient-

InfrastructureServer Role.inf

EnterpriseClient-

InfrastructureServer Role

Policy

Enterprise Client-Domain

Controllers Policy

Enterprise Client-File Server

Role Policy

EnterpriseClient-IIS Server

Role PolicyFile

Web

Infrastructure

However, that fact doesn’t mean that local computer security shouldn’t be used—far from it. It is important to set a local computer security policy because it is all too easy for a domain-based computer or user to log in locally or be disconnected from the network—especially laptop users. Forthis reason, you want a local computer policy to apply when the Active Directory GPOs cannot beapplied.

In fact, an Active Directory environment structured around security should use all the availabletools and apply them when appropriate. Each tool has its area of applicability. Let’s look at anexample procedure.

Newly arriving computers should have a large security template applied against them; this template should contain every possible security setting that is common across most of the computers.You can use Windows’ default Setup Security security template as a model, customized for your organization. However, you should never use a GPO to apply a very large security template, becausethe size significantly slows down logging on and other network communications.

You apply this large security template using the Security Configuration and Analysis snap-in orSECEDIT.EXE, because it makes the security template’s configuration settings permanent (“tattooingthe registry”). In contrast, GPO settings can be transient. You should apply this template on any newPC to ensure that all PCs start with a common baseline; thereafter, you can apply this template periodically.

Next, the Local Computer Policy object should be configured to apply medium- to critically-ratedsecurity settings every time the computer boots up or the user logs on. This policy object won’t be aslarge as the security template you install the first time, but it will probably be larger than the securitytemplates applied using GPOs.

Then in Active Directory, you should prepare a security template and GPO for the domain toapply all critical security settings that are common across all users and computers. Supplement thisGPO with a role-based GPO for the user or computer’s specific role as defined in Active Directory,containing the unique security settings (see Figure 1-6).



Figure 1-6Security automation pathway

The net effect of these steps is a very secure computer network with high degree of control andcompliance.

Summary Chapter One begins our journey to secure computer assets using authentication and permissions.Security principles guide policy and determine the tools you use to maintain a secure network. Thedefense-in-depth model is key among these security principles; it proposes using multiple redundantlayers of defense. The redundancy is important in part because attacks happen along every layer ofthe OSI model; most are automated forms of malicious mobile code.

Your company’s security policy should offer specific guidelines for technology implementations.Good security takes planning, documentation, communication, and verification. Even with the bestsecurity, an exploit will happen. To be prepared, all organizations should create an incident responseteam and plan how incidents will be handled.

Microsoft provides security automation tools, like Group Policy Objects, Security Templates, and Local Computer Policy that no other platform can match. Instead of spending time evaluatinghigh-priced, high-risk security tools, most administrators would be better off examining their defaultauthentication and permission settings.

Chapter Two, Windows Authentication, discusses Windows authentication protocols and solutionsin detail.



Baseline Group PolicyCritical Settings

Baseline Security Template

Re-applied Frequently

One-time and as needed

Applied Less Frequently Than Group Policy

Incremental Group PolicyCritical Settings

Incremental Security Template

Local AppliedInclusive

Baseline Security Template

Local Computer PolicyCritical and Moderate Settings

Baseline Security

Applying Group Policy and Security Templates

22


Chapter 2:

Windows AuthenticationChapter Two covers Windows authentication protocols and mechanisms in detail, with special attention to Windows Logon Authentication protocols. Internet Information Service (IIS) and remoteauthentication protocols are covered briefly to contrast with and to round out a fuller picture of Windows authentication.

Why Authentication? According to conventional wisdom, the three reasons for securing computers are confidentiality,integrity, and availability—sometimes known as the CIA Triad. Of these reasons, integrity is the mostcritical. In general terms, integrity refers to data and means that data has not been modified during itstransmission from user to user. Ensuring integrity therefore includes more than a simple focus ondata; it also includes tasks relating to authentication of both data and users. When users digitally signdata, they certify that the data is in a specific form, current as of the time they sign it. When the dataarrives at the receiver and the data’s digital signature is verified, the verification determines that thedata did not change between the time it was signed and the time it was received.

NoteWe use the term data to mean any type of digital bytes, whether it’s data, program files, ormultimedia content.

But even more important than authenticating the data is confirming the user’s identity. If theusers who rely on the data cannot rely upon the identify of the sender or creator of the data, the rest of the security triad isn’t material. If you can’t be sure who made or sent data, what does itmatter if that data is protected? Why should network administrators work to ensure high rates of dataavailability if they can’t trust the data itself? Data security becomes important only if the data can beconfirmed during creation, modification, and transmission. Data becomes valuable and thereforeworth protecting when its sources can be authenticated.

Viruses and worms, and other types of malware attacks, proliferate only because the malicioushackers have a high level of assured anonymity. Their chances of being identified and charged with acrime are miniscule in today’s Internet environment. Malevolent hacking would stop in an instant ifhackers knew they could be identified. Devious insiders would not harm data or plant logic bombs ifthey knew they could always be traced.

For many companies, the strategy for reaching the goal of a more secure network—a networkworth protecting—is doing away with default anonymity. Microsoft and other entities are workingtoward universal default authentication with a variety of proposals and protocols. Since the introduc-tion of the NTFS subsystem, Windows computers can identify and authenticate users, computers, andother security principals on the local computer or domain. To solve the most persistent problems,companies like Microsoft are introducing new authentication and identity schemes. For example,

n

Chapter 2 Windows Authentication 23


Microsoft’s Caller ID™ and Sender Policy Framework (SPF) are two recent proposed authenticationstandards that are designed to reduce the amount of unsolicited email that seeps into our networks.

Perhaps the grandest proposal is Microsoft’s Next Generation Secure Computing Base (NGSCB;http://www.microsoft.com/resources/ngscb/default.mspx). NGSCB will let trusted applications anddata communicate with users and each other securely. Untrusted programs, like viruses and worms,will be unable to make unauthorized changes to the system and data, which will effectively kill themoff in mass. The seeds of NGSCB were implemented in Windows XP Professional Service Pack 2, butthe first full implementation will appear in the next version of Windows (code-named Longhorn) andrequire special CPU extensions.

To summarize, authentication is used to identify a user, computer, or some other security principal reliably. Successful authentication is then used to assign access controls to different objectsand to audit object use. We cannot control access to resources without an authentication mechanism.

Authentication Fundamentals Authentication is the process by which a security principal (a user, a group, a service, or a computer)identifies itself to an authentication authority. The security principal is a unique, defined identity inthe system to which it is applying for authentication—in Windows, an account. In authentication vernacular, the account involved in the client-side of the authentication event is known as the supplicant. Every Windows security principal has a security identifier (SID) which uniquely identifiesthe principal for authentication, authorization, auditing, delegation, and trusts.

Figure 2-1 shows the basic authentication process from identification through authorization.

Figure 2-1 Basic authentication

In the next sections, we look at each step in the process, consider how password hashing fitsinto authentication, and review the Windows logon process before examining Windows authentica-tion options in detail.

Identification The process of identification requires that a security principal submit, as proof of its identity, something that only that principal is capable of submitting—in Windows, the logon account name.Then, the security principal’s identity is verified, based on the presented proof. For a principal to beauthenticated, the proof submitted must equate to the expected value of this proof (also known asthe authenticator) that is stored in the authentication database.

Note The term authenticator can be used to represent two different security concepts whendiscussing authentication. It can mean, as it does in this paper, the proof submitted to proveidentity; or it can mean the authentication mechanism and database used to authenticate.

n

Identify Authenticate Authorize

http://www.microsoft.com/resources/ngscb/default.mspx



Identity can be proved by:• Something only the security principal knows• Something only the security principal has• Something only the security principal is

Something only the security principal knows includes passwords, passphrases, or personal identification numbers (PINs). Smart cards and tokens are examples of something only a security principal has. Biometric data, such as fingerprints or retinal patterns that can be scanned, is some-thing only a security principal is.

These proofs of identity are known as factors. If an authentication process requires the securityprincipal to use two of the three types of factors, the process is known as two-factor authentication.If the security principal is required to use identifiers from all three factor classes, then the process isknown as multi-factor authentication. Two-factor authentication is considered to be more reliablethan one-factor authentication (all other factors equal), and multi-factor authentication is consideredthe most reliable authentication method.

Email phishing attacks, in which a forged email tricks a user into revealing security credentials toan unauthorized third party, is leading many entities, such as online banks, to require two-factorauthentication. Although a password or PIN may be easy to steal, it is less likely that a malicioushacker will also have the legitimate user’s smart card or token at the same time. High-security companies require multi-factor authentication. VeriSign (http://www.verisign.com), which maintainssome of the Internet’s top-level domain naming servers and is involved in a significant portion of allInternet commerce, requires multi-factor authentication to access its protected computers. Userswishing to access the inner computer sanctums must type in their PIN, swipe a smart card badge,and submit to a hand geometry scan.

Authentication Regardless of the way the identity credentials are submitted, an authentication mechanism (that is, anauthentication protocol) submits the credentials to an authentication database for comparison. In Windows, authentication databases are usually either a local security accounts management (SAM)database or an Active Directory database.

Protecting all the transactions—the transmission of the authenticator and all subsequent transac-tions—against unauthorized modification or eavesdropping is an important part of authentication. Thegoals of protecting the transactions include:

• Preventing capture of principal credentials• Limiting exposure of principal authenticator• Preventing manipulation of authentication traffic• Preventing spoofing of authentication server identity• Reducing burden on authentication server• Providing timely information about principal authorizations

http://www.verisign.com

As Figure 2-2 shows, any authentication system contains an authenticator that is input and thensecurely transported to the authentication database for verification. The processes and mechanismsthat are involved in the authentication process are called authentication protocols.

Figure 2-2 Authentication model

Authentication protocols protect the transmission of the authenticator and the resulting transactions. In early systems, when users typed their passwords, they were transmitted in clear textto the verification database. Malicious hackers can insert an eavesdropping tool, sniff the passwordcredentials, and authenticate as the other user. Unfortunately, this breach can still happen today inunprotected FTP, Telnet, and POP authentication transactions.

Modern authentication protocols do not pass the original authenticator in clear text. Instead, theauthenticator is manipulated or sent through a cryptographic process between the sender andreceiver. The manipulation is done so that only the security principal, who knows the plain-textauthenticator, can create the correct obscured authenticator.

NoteFor the rest of this chapter, the simpler term password will be used in place of authenticator.

Password Hashing Plain-text passwords are not usually stored in the verification database. As is the case on the securityprincipal’s originating computer, the password is manipulated by a cryptographic process and storedin its changed form. Thus, if the verification database is compromised, the plain-text passwordscannot be discovered immediately.

Password hashing is an example of a simple password protection mechanism. In a system thatuses password hashing, the user’s input password is converted, by using a hashing algorithm, into a value; this value is then stored in the verification database. Hashing algorithms are usually well-known cryptographic formulas that convert input into a unique computational value. Hashes areconsidered one-way in that even if you have a hash result, it is difficult to find the original valuewithout computing all possible hash results. Some Windows authentication protocols use MD4(http://www.faqs.org/rfcs/rfc1320.html) or MD5 (http://www.faqs.org/rfcs/rfc1321.html) hashing algorithms.

n



Authenticator

Input

Transport

Verification

A

B

C D

http://www.faqs.org/rfcs/rfc1321.html


Let’s look at the whole process. When users log on, they input their user account name andpassword. The plain-text password is computed to its password hash, and the password hash is sentto the authentication process and compared to the value stored in the verification database. If thevalues match, the authentication is successfully verified. The authentication protocol knows that onlysomeone with the correct password could have created the correct password hash. With this method,passwords can still be used for authentication without the risk of transmitting them in clear text.

You might ask, “Can’t the password hash be sniffed off the wire and then used to fake laterauthentication?” Yes. For that reason, today’s authentication protocols usually don’t actually send thepassword hash between sender and receiver; instead, they go one step further. The verification database server creates a unique one-time value, called a challenge, and sends it to the principal. Theprincipal (in actuality, its authentication proxy process) uses its password hash cryptographicallyagainst the challenge to respond. The response is sent to the verification database server, which hasperformed the same computation. If the two resulting challenges agree, then authentication is verified.Secure authentication protocols even include a timestamp in the challenge and response to ensurethat hackers can’t use the resulting computations in a later replay attack. All in all, authentication protocols can be quite complex.

NoteTo understand authentication thoroughly, it’s important to understand the difference betweenthe authentication protocol—the processes that encompass the whole authentication process—and the stored password hashes that are involved in the authentication process. Some malicioushacks attack the authentication process, but it is more common for hackers to attack theresulting password hashes in an attempt to recover the original passwords.

The authentication process can be separated from the sender and receiver involved; this setup is called trusted third-party authentication (TTP). Many of today’s authentication networks, like Kerberos (discussed below) and Public Key Infrastructure (PKI) rely on TTPs to store the protectedpassword (authenticator) credentials. In this way, protected credentials don’t have to be stored onevery single sender and receiver that could potentially perform authentication. Also, you can increasesecurity on the TTP to prevent unauthorized access, which is easier to do on one, or a few, centralized computers than across all computers.

Authorization After a successful authentication, Windows gathers the cumulative permissions assigned to the principal’s account and security group memberships, and the security principal is authorized to access allowed resources. However, authorization doesn’t mean that the system won’t perform moreidentifications and authentications—authentication occurs more often than only during the logon process. Nearly every time a principal accesses a Windows object, an authentication event is trigged.

For example, when a user connects to another computer’s file or print share, the user must beauthenticated. When the security principal—in this case, a user—contacts the share, the principal ischallenged for its authentication and must pass an authentication process or be vouched for by a verification database server.

n





Windows Logon Process Now let’s look at the specific logon process that Windows uses before we cover the Windowsauthentication protocols in detail. Figure 2-3 shows the interactive logon (in this case, a local logon)process.

Figure 2-3Windows interactive logon process

When a user initiates an interactive logon (a local logon with the Ctrl-Alt-Del sequence), the Winlogon service calls the Graphical Identification and Authentication (GINA) program. The GINAextracts the user’s logon name, password, and domain information and passes them to the local security authority (LSA). The LSA program uses the authentication protocol as a guide to createauthentication packages that are sent either to the local or to the remote verification databases.

Types of Windows Authentication Windows can use several different types of authentication, depending on the access you need andthe location of the security principal. The most popular categories of Windows authentication areWindows Logon authentication, remote user authentication, and Internet Information Services (IIS)user authentication. Each has strengths and areas in which an administrator must use caution. High-lights for each type of authentication are summarized in Figure 2-4; we cover each in detail in thenext sections.

Winlogon

GINA

LSA

AuthenticationPackage

VerificationDatabase

MSGINA.DLL

Determined byAuthenticationProtocol

SAM or ActiveDirectory

Figure 2-4 Windows authentication protocols

Windows Logon Authentication Protocols Windows Logon authentication happens whenever a user or computer logs on to a Windows computer or domain, or whenever an object with security access control entries (ACEs) is contacted.The Windows Logon Authentication protocols are

• LAN Manager• NTLM (version 1.0)• NTLMv2• Kerberos

NoteThe abbreviation NTLM refers to version 1.0, whereas NTLMv2 refers uniquely to the secondversion of NTLM.

With increasing preference, each protocol in the list above is more secure and resistant to malicious attack than the one listed before it. LAN Manager is the weakest and Kerberos is the mostsecure. Most Windows computers support all four protocols, depending on the circumstances. Let’slook at each protocol in detail. To make the discussion of each easier, we will look at authenticationfrom the perspective of only an interactive logon. Other authentication events are similar.

n



Remote User AuthenticationProtected EAP (PEAP)—adds TLStunnel layer to other EAP types,commonly used in wireless auth.

EAP-TLS—smart cards or certificates.

EAP-MD5—uses CHAP, usespasswords.

MS-CHAPv2—Win2K and later, andolder clients with DUN upgrade canVPN (but not dial-up), mutualauthentication. MS-CHAP

CHAP—plain text, supports old andnon-Windows clients. Server mustallow reversible encryption.

SPAP—plain-text login, not tested.

PAP—plain-text logon, user can’tchange password easily.

IIS 6.0 User AuthenticationAnonymous—uses IUSR_servername account

Integrated Windows Authentication—nosecond login, good for local, uses NTLM orKerberos

Digest Authentication—sends hash auth., IISmust reside in DC domain, user still logs in,not as secure as IWA

Basic—plain text login dialog box

.NET Passport (Certificates-machine auth.,with trusted CA)

Windows LogonAuthenticationLM—old, insecure

NTLM—pre-Win2K default

NTLMv2—Win2k and later,plus NT SP4, Win9x withAD client (NTLM(v2) stillused in NT domains evenwhen Win2K logs into NTdomain)

Kerberos—default Win2Kprotocol, can’t be used byearlier clients

LAN Manager Protocol LAN Manager (LM) protocol was created by IBM and implemented in early versions of Windows andWindows networking. Like all Microsoft authentication protocols, LM converts typed-in plain-text pass-words into password hashes that are stored and used by sender and receiver during the authentica-tion process. This process is called the LM hash.

LM password hashes are created by performing the following steps on the submitted plain-textpassword:

1. All alphabetic characters are converted to uppercase.2. The password is padded or truncated to make it exactly 14 characters long, and then it is bro-

ken into 7-character halves.3. Each half is used as a DES key to encrypt a constant string.4. The two results are concatenated into a 128-bit string and storing it as 32-byte hex string.

The LM password hash is then used in the LM authentication protocol process in the following way:

1. The client makes the authentication request to the server.2. The server generates a 16-byte random number as a challenge and sends it to the client (Type

message).3. On the client, the LM hash is created, as described in the paragraph above, from the plain-text

password typed into the GINA GUI.4. The 16-byte LM hash is null-padded to 21 bytes. 5. This value is split into three 7-byte thirds. 6. Each 7-byte third is used to create a DES key. 7. Each DES key is used to DES-encrypt the challenge from the Type 2 message sent by the

authenticating server, resulting in three 8-byte ciphertext values. 8. These three ciphertext values are concatenated to form a 24-byte value, which is the client’s

LM protocol response.

Although the LM protocol was adequate protection when it was invented, it is easy to exploitusing today’s technology and techniques. Among its problems is the relatively small number of possible passwords created by converting all lowercase characters to uppercase and limiting pass-words to 14 characters. With the computing power available today, all the possible password hashesare easy to pre-compute in a short time.

Worse, if the password isn’t 14 characters long, which is almost always the case, the addedspaces were easily recognizable in the hash result. Thus, a hacker could immediately spot the exactsize of the password and begin hacking on just that password size, focusing only on uppercasealphabetic characters and numbers.

To exacerbate the problem, most users used only alphabet characters—no numbers, symbols, orspaces—and most spelled common words that could be found in the dictionary. The possibleresulting passwords could usually be cracked by only a few thousand guesses. In the world ofauthentication, that kind of security isn’t even close to being good enough. For more details, seehttp://www.insecure.org/sploits/l0phtcrack.lanman.problems.html.



http://www.insecure.org/sploits/l0phtcrack.lanman.problems.html

NTLM Because of the weaknesses in the LM protocol, Microsoft created the NTLM protocol as the defaultauthentication protocol for Windows NT 4.0. NTLM uses a more sophisticated authentication algorithm and creates a more secure stored password hash. NTLM can support up to 128 characterpasswords. Unlike LM hashing, which is very limited in the ASCII characters that can be used, NTLMhashing supports the full Unicode character set, thereby adding more complexity to the process.

The NTLM protocol uses the following steps to create the password hash. 1. The password is truncated at the 128th character.2. The password is converted to 16-bit Unicode value.3. The value is run through the MD4 digest function.4. The resulting 128-bit MD4 hash is stored as 32-character hexadecimal string.

On the downside, NTLM performs absolutely no salting. Salting is the process of changing theoutcome of a password hash by using a randomly created string of characters. Without salting, everyidentical password has an identical password hash. If a hacker can pre-compute a large collection ofpassword hashes, a captured password hash might be cracked to its originating plain-text password.

Here is the NTLM authentication process between a security principal and a server:1. The client makes authentication request to server.2. The server generates a 16-byte random number as a challenge and sends it to the client (Type

2 message).3. The client creates an NTLM hash of password. 4. The 16-byte NTLM hash is null-padded to 21 bytes.5. This value is split into three 7-byte thirds. 6. These values are used to create three DES keys (one from each 7-byte third). 7. Each of these keys is used to DES-encrypt the challenge from the Type 2 message (resulting in

three 8-byte ciphertext values). 8. These three ciphertext values are concatenated to form a 24-byte value. This is the NTLM

response. 9. The client sends NTLM response to server.

10. The server sends three items to a verification database for authentication: the username, the challenge sent to the client, and the response received from client.

11. The verification process retrieves the hash associated with the user and uses the hash toencrypt the challenge.

12. If the result and the client’s response match, authentication is successful and the verification database responds to the original server.

For more information about the NTLM protocol, check the following sites: • http://davenport.sourceforge.net/ntlm.html• http://www.securityfriday.com/Topics/ntlm_optimizedattacks.html• http://msdn.microsoft.com/library/default.asp?url=/library/en-us/

security/Security/microsoft_ntlm.asp



http://davenport.sourceforge.net/ntlm.html

http://www.securityfriday.com/Topics/ntlm_optimizedattacks.html

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/Security/microsoft_ntlm.asp

NTLMv2 Security researchers eventually proved that the NTLM protocol was insecure. Microsoft responded bycreating NTLM Version 2 (NTLMv2) and released it with Windows NT 4.0 Service Pack 4. NTLMv2,although surpassed by Kerberos as today’s default Windows authentication protocol, has proven to bereliably secure for most environments.

The NTLMv2 protocol is similar to NTLM, except that1. HMAC-MD5 message authentication is used in the NTLMv2 password hash2. A block of data called the blob is constructed with timestamp, client challenge, and other info

and used in the process3. The challenge and the blob are concatenated to form NTLMv2 response

Here is the NTLMv2 authentication process between a security principal and a server:1. The client makes an authentication request to a server.2. The server sends the client a challenge in a Type 2 message.3. The NTLM password hash is created (as discussed previously, this is the MD4 digest of the

Unicode mixed-case password). 4. The Unicode uppercase username is concatenated with the Unicode uppercase authentication

target (domain or server name). 5. The HMAC-MD5 message authentication code algorithm (described in RFC 2104) is applied to

this value using the 16-byte NTLM hash as the key. This results in a 16-byte value—theNTLMv2 hash.

6. The blob—a block of data—is built from a timestamp, a client challenge, and otherinformation from the Type 2 message.

7. The challenge from the Type 2 message is concatenated with the blob. The HMAC-MD5 message authentication code algorithm is applied to this value using the 16-byte NTLMv2 hash(calculated in step 2) as the key. This results in a 16-byte output value.

8. This value is concatenated with the blob to form the NTLMv2 response.

Overall, NTLMv2 is harder to compromise with brute-force attacks than NTLM because it uses a128-bit encryption key. Most attacks against NTLMv2 are successful only because of weak passwords(brute force attacks always work against weak passwords) and because older authentication methods(LM, NTLM) can be forced by a client (who could be an attacker).

Kerberos Kerberos is the default logon authentication protocol in Windows 2000 and later. It is a free mutualauthentication and encryption method developed by MIT and supported by most major vendors,including Microsoft. The name is taken from Greek mythology, referring to the three-headed dog thatguarded the gates of Hades.

Kerberos uses symmetric key encryption technology and is considered extremely secure becausethe security principal’s password hash (actually the challenge response) is transmitted over the network only during the initial authentication event. After that, the TTP server authenticates securityprincipals to requested resources with temporary session keys. The benefits of Kerberos include:



• Mutual authentication• Increased password protection• Replay attack protection• Delegation of identity• Interoperability

In the previous authentication protocols, the security principal was always authenticating itself tothe verification database and/or requested resource. Kerberos requires mutual authentication, in whichthe resource must also prove its identity to the requesting client. The temporary session keys areencoded with timestamps, so that attackers cannot capture and replay the session keys at a later time. Kerberos also allows a principal to assign its credentials to another computer. Lastly, becauseKerberos is an open, widely supported standard, Microsoft’s implementation (with some adjustments)can interoperate with other vendor’s implementations.

This next section will cover the Kerberos authentication process. Although it can seem a bit complicated the first few times you see it, you don’t have to understand the technical mechanicsbehind Kerberos to use it. In fact, Kerberos works quite well on its own most of the time, and network administrators don’t have to adjust it.

Let’s start with a high-level summary of the Kerberos process, followed by a more detailedexample.

When a client wishes accesses a Kerberos protected resource, it requires a Kerberos ticket. The(highly simplified) process for receiving a ticket is:

1. The The client first requests authentication from the Kerberos Authentication Server (AS)2. The The AS authenticates the user when the user successfully logs on.3. The The AS approves the request and creates a session key. 4. The The session key authenticates the client to the Ticket-Granting Service (TGS).5. The The TGS gives the client a Kerberos ticket. 6. The The client hands the original resource the Kerberos ticket to authenticate itself.

Before we continue, some Kerberos terminology and technology requires definition. • A realm is a Kerberos boundary for the authentication system. In the Windows world, a realm

usually equates to a domain.• The Key Distribution Center (KDC) server is sometimes referred to as either the Authentication

server or the Ticket Granting server, although these are just different functions of the server,not distinct roles. In Windows, the domain controllers run the KDC service. An account namedkrbtgt is created on DCs for the Kerberos service. You can not turn off the KDC on a domaincontroller.

• Tickets are data packages issued by a KDC that contain information about the authenticatedclient, the resource they are authenticated to, the duration of that authentication, the sessionkey, and other data. A user ticket is what is traditionally called a ticket granting ticket (TGT).

• A session ticket is also called a service ticket.• The long-term key or secret key is derived from the user’s password. Long-term keys for

computers are more complex (14 characters) and are automatically changed every 7 days.• A session key is generated by the KDC and is good only for the particular authentication

session between principals.



• A Privilege Attribute Certificate (PAC) contains the SIDs associated with the user or groups theuser belongs to.

The Kerberos protocol is composed of three subprotocols. The subprotocol in which the KDCserver gives the client a logon session key and a TGT is called the Authentication Service (AS)Exchange. The subprotocol in which the KDC distributes a service session key and a ticket for theservice is called the TGS Exchange. The subprotocol in which the client pre-sends the ticket foradmission to a service is called the Client/server (CS) Exchange.

To understand the Kerberos protocol in more depth, let’s look at what happens with each subprotocol. Here is the chain of communication involved in a Kerberos authentication sessionbetween a client workstation and a resource server in a Windows 2000 domain environment; we willfollow a request through

• The AS Exchange• TGS Exchange• C/S Exchange.

This overview is still somewhat simplified, but it will give you an accurate picture.

Authentication Service (AS) Exchange The starting point: User A wants access to a Windows 2000 network.

1. User A, at a Microsoft Windows 2000 Professional workstation, logs on to a Microsoft Windows 2000 network, typing the user name and password.

2. The Kerberos client running on A’s workstation converts the password to an encryption keyand saves the result in a program variable.

3. The Kerberos client sends a message of type KRB_AS_REQ (Kerberos Authentication ServerRequest) to the KDC. This message has two parts: - An identification of the user, A, and the service for which A is requesting credentials, the

TGS.- Pre-authentication data, intended to prove that A knows the password. This data is simply

an authenticator encrypted with A’s master key. The master key is generated by running A’spassword through an OWF.

4. Upon receipt of KRB_AS_REQ from A, the KDC looks up the user A in its database (the ActiveDirectory), gets the user’s master key, decrypts the pre-authentication data, and evaluates thetime stamp inside. If the time stamp passes the test, the KDC can be assured that the pre-authentication data was encrypted with A’s master key and is not merely a captured replay.

5. Finally, once the KDC has verified A’s identity, it will create credentials that the client programon A’s workstation can present to the TGS. The credentials are created and deployed as follows:- A brand new logon session key is encrypted with A’s master key. - A second copy of the logon session key and A’s authorization data, in a Ticket Granting

Ticket (TGT), is encrypted with the KDC’s own master key. - The KDC sends these credentials back to the client by replying with a message of type

KRB_AS_REP (Kerberos Authentication Response) - When the client receives the reply, it decrypts the logon session key by applying A’s master

key. The session key is then stored in the client workstation’s ticket cache. The TGT isextracted from the message and stored in the cache as well.



Ticket-Granting Service (TGS) Exchange Here, the starting point is a request from the Kerberos client running on User A’s workstation actuallyrequests credentials to access the target server, User B.

1. The Kerberos client running on A’s workstation sends a message of type KRB_TGS_REQ (Kerberos Ticket-Granting Service Request) to the KDC. This message consists of the followingcomponents. - The identity of the target service for which the client is requesting credentials - The authenticator encrypted with the user’s logon session key - The TGT acquired from the AS Exchange

2. The KDC decrypts the TGT with its master key and extracts A’s logon session key. A’s logonsession key is used to decrypt A’s authenticator. If A’s authenticator passes the test, the KDCinvents a new session key for A to share with B. Two copies of this new session key are sentback to A in a single message, encrypted as follows:- One copy is encrypted using A’s logon session key.- The second copy is encrypted using the target server’s master key, in a ticket along with

A’s authorization data.3. User A’s client decrypts the target server session key, using its logon session key, and stores

the session key in the local cache, along with the target server ticket.

Client-Server (CS) Exchange The Kerberos client on User A’s workstation is now ready to be authenticated by the target server,User B.

1. User A’s Kerberos client sends User B a message of type KRB_AP_REQ (Kerberos ApplicationRequest). This message contains - An authenticator encrypted with the session key for B. - The ticket for sessions with B, encrypted with B’s master key.- A flag indicating whether the client requests mutual authentication.

2. B decrypts the ticket and extracts A’s authorization data and session key. B uses the sessionkey to decrypt A’s authenticator and evaluates the time stamp. If the authenticator passes thetest, B looks for a mutual authentication flag. If this flag is set, B uses the session key toencrypt the time from A’s authenticator and returns the result to A in a message of typeKRB_AP_REP (Kerberos Application Reply).

3. A’s client decrypts the reply with the session key. If the authenticator is identical to the onesent to B, the client is assured that the server is genuine, and the connection proceeds.

As you can see, Kerberos is a complex protocol, but it is a secure one. Microsoft’s implementa-tion of Kerberos has withstood many tests. To date, only one vulnerability has been demonstrated(http://ntsecurity.nu/toolbox/kerbcrack), and it has not been widely deployed. The attack is known asKerbcrack; it works by capturing and cracking the less-protected pre-authentication packets which aresent, ironically, to prevent password-sniffing attacks.



http://ntsecurity.nu/toolbox/kerbcrack

Kerberos Policy Settings Kerberos authentication can be customized with the policy settings listed below.

• Enforce user logon restrictions: your options are Yes and No• Maximum lifetime of service tickets: the default is 10 hours• Maximum lifetime of user tickets: the default is 10 hours• Maximum lifetime for user ticket renewal: the default is 7 days• Maximum tolerance for computer clock synch: the default is 5 minutes

Checking logon restrictions determines whether the user’s account has been locked out since theuser ticket was originally issued. It also makes the resource server check to make sure the user hasbeen granted permission to access the computer from the network.

Particular problems may arise that force administrators to change the default values, but those situations are not common. In general, don’t change the default settings unless you have a good justification and fully understand the implications. For example, changing the maximum lifetime ofservice tickets from 10 hours to 5 hours could result in twice the normal amount of authenticationtraffic on the participating domain controllers.

NoteWindows built-in smart card domain authentication requires Kerberos.

Why Not Use Only Kerberos? If Kerberos is the most reliable authentication protocol, why not use only Kerberos? The short answeris this: Windows can’t always use it. Although Kerberos is the default login authentication protocol forWindows 2000 and later, in several circumstances, older password hashes and protocols are still commonly used.

• LM password hashes are stored by default on all Windows systems, even Windows Server2003. When you hear about password-cracking tools easily breaking into modern Windowscomputers, they are usually breaking into the much easier to hack stored LM password hashes,not the NTLM or Kerberos protocols.

• LM must be used to connect to LAN Manager networks or older legacy clients, such as OS/2,DOS, Mac, WFW, or Win95, that have not be updated to support new authentication methods.

• NTLM is supported on Windows NT, Windows 2000, and Windows 2003.• NTLMv2 is supported natively in Windows 2000, Windows XP, and Windows Server 2003 and

can be added to Windows NT and Windows 98 with the Active Directory Client Extensionsoftware. It can be added to Windows 95 and 9x clients using DFS client, WinSock 2.0 update,or Microsoft DUN 1.3 (KB 239869).

• NTLMv2 is used in mixed-mode domains. • You can’t use Kerberos with RRAS; NTLMv2 is the user authentication protocol that is used.• When an NTLM challenge is issued by a server to a Windows client, all Windows clients, by

default, reply with both an NTLM (or an NTLMv2) and an LM response.• Windows 2000 and later computers still use NTLM or NTLMv2 for authentication when

authenticating to computers outside its own domain (unless in a Windows 2003 forest).

n



• When a computer joins a Windows 2000 (or later version) domain for the first time, NTLM orNTLMv2 is used.

• For circumstances when domains aren’t set up, such as logging in locally or peer-to-peer connections, NTLM or NTLMv2 is used.

• NTLM or NTLMv2 is used when connecting to non-Kerberos versions of Windows or toresources of servers that aren’t domain members.

• Telnet and FTP services use NTLM or NTLMv2.

As you see, it is virtually impossible to rid yourself of all authentication protocols prior to Kerberos. Windows 2000 and later systems will always use a combination of Kerberos and one ormore of the other authentication protocols. However, you should disable LM and NTLM protocolswhen possible. You can use group policy settings or registry modifications to force the Windowslogon authentication protocols used by clients and servers.

The group policy setting for network security is LAN Manager Authentication Level. In the listbelow, the value number is associated with the value in the LMCompatibility registry key that couldbe modified: The possible values for the LAN Manager Authentication Level are

• 0 = Send LM and NTLM responses (the default for the Windows XP Local Security Policy).Clients use only LM and NTLM (not NTLMv2).

• 1 = Send LM and NTLM; use NTLMv2 session security if negotiated. Clients first use LM andNTLM, using NTLMv2 session security if the server supports it.

• 2 = Send NTLM response only (the default for the Windows Server 2003 Default Domain Controller Policy). Clients use NTLM and NTLMv2 session security if the server supports it.

• 3 = Send NTLMv2 response only. Clients use NTLMv2 authentication only and NTLMv2 sessionsecurity if the server supports it.

• 4 = Send NTLMv2 response only \ refuse LM. Clients use NTLMv2 authentication only andNTLMv2 session security if server supports it.

• 5 = Send NTLMv2 response only \ refuse LM & NTLM. Clients use NTLMv2 authenticationonly and NTLMv2 session security if server supports it.

These settings affect client computers and domain controllers differently. Only the last two set-tings listed affect DCs by limiting them to NTLM and NTLMv2 (option 4) or just NTLMv2 (option 5).Otherwise they also accept LM, NTLM, or NTLMv2.

NoteThis setting doesn’t affect Kerberos use.

Anonymous Logons No discussion of Windows authentication would be complete without mentioning anonymous logons.In many instances, Windows needs to have unauthenticated access to a Windows system to do itsrequested work. For this reason, Microsoft created a non-credentialed session called the anonymouslogon or null session.

n



The anonymous user account has no password, but it can be controlled through access controllists. For example, you can give the anonymous user account the ability to access any file or folderby selecting it when you define security permissions. The anonymous user account is not part of theAuthenticated Users group. The anonymous user is part of the Everyone group in Windows 2000, butnot in XP or 2003.

Note Anonymous logons have nothing to do with IIS’s anonymous user accounts (for example,IUSR_computername) even though they sound similar.

If you want to create and experiment with an anonymous user session, follow these steps:1. Get to a command prompt.2. Use the Net View command to enumerate shares on a remote computer. For example, type

Net View \\<remotecomputersname>. A list of the computer’s advertised shares shouldappear. If anonymous enumerations are not allowed, the query asking to list that computer’sshares will fail. If so, configure the computer (at least temporarily) to allow anonymous enumeration. You can do it in group policy and reboot or find the share and explicitly give itanonymous permissions.

3. Now establish an anonymous connection to the remote computer. For example, type Net Use\\<remotecomputersname>\<sharename> “” /user:”” This will establish an anonymousconnection.

4. Issue the same Net View \\<remotecomputersname> command again. This time, it shouldwork, demonstrating the anonymous account’s newly established connection.

Anonymous logons have been the subject of controversy since the early days of Windows NT 4.0because the earlier versions of Windows allowed and relied upon anonymous enumeration. Theword enumeration is synonymous with query; it is the way Windows systems discover variousobjects. It uses TCP/IP ports 139 and 445. For example, when Network Neighborhood is used tobrowse, enumeration is used locate computers, network information, and shares. Another good exampleoccurs when accounts and resources are accessing resources in other domains. An anonymous enumeration event is necessary even for the basic trust information to be negotiated and verified—forexample, creating a list of valid user accounts that should be accessing the resource domain.

Of course, unauthorized users can attempt enumeration to learn about a system to attack it.Using anonymous enumeration, hackers can gather the following information about a Windowssystem:

• Network Information (domain, trusts, etc.)• Shares• Users and groups• Privileged accounts• Registry keys

Hackers who learn enumeration information, such as drive shares and user names, can use thatinformation to attack the network. For example, anonymous enumeration may let a hacker identify

n



user accounts as administrative or non-administrative by looking at the user account’s SID. By default, user accounts are given well known SIDs that identify privileged accounts. For example, theSID S-1-5-xxx-500 is always the administrator account; SID S-1-5-xxx-519 is always the enterpriseadministrator account; and S-1-5-xxx-512 is always the domain administrator account. A commondefense against this attack is to rename the administrator account to something that a hacker wouldnot automatically guess. However, if the computer system allows anonymous SID enumeration, aremote hacker may be able to query the user accounts and locate the renamed administrator. Ifhackers can enumerate your network, half their work is done.

Disabling Anonymous Enumeration However, disabling all anonymous enumeration isn’t the answer, either. It can cause problems withlegacy operating systems and applications, as listed below.

• Pre-2000 users may not be able to change passwords after they expire• Adding workstations to domains may fail• Trust problems with NT domains may arise• Browser service may experience problems• Exchange GAL problems may come up.

Restricting Anonymous The more important security defense is to restrict anonymous access instead of disabling it outright.The RestrictAnonymous feature (and registry key) was added in NT4 SP3. The values and behaviorsare slightly different in NT, 2000, and later operating systems. Compared to previous versions, Windows 2003 has enhanced granularity of control. Although anonymous enumeration can berestricted with the Restrict Anonymous registry key (HKLM\System\CurrentControlSet\Control\LSA\RestrictAnonymous), it is easiest to use a Group Policy setting (Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options) to accomplish the same thing. The RestrictAnonymous registry key values, and the behavior they set, are listed below.

• In Windows 2000 and XP- 0 = anonymous enumeration allowed- 1 = anonymous enumeration of SAM accounts and shares allowed only using certain

Win32 API calls- 2 = anonymous enumeration not allowed; no access allowed without specific permissions

given• In Windows 2003

- 0 = anonymous enumeration allowed- Any non-zero number = anonymous enumeration of SAM accounts and shares allowed only

using certain Win32 API calls

In Windows 2000 and later, setting RestrictAnonymous=1 lets programs that use various legitimate APIs perform anonymous enumerations. Therefore, if you want to prevent all anonymousenumeration in 2000, set the value to 2 (unfortunately, setting the value to 2 doesn’t work in Server2003 or XP). Setting the value to 2 in Windows 2000 removes the Everyone SID from the anonymoususer, which is handled by a separate key in XP and 2003. Because preventing ALL anonymous enumerations can disrupt legacy operating systems and applications, most people should not set



Restrict Anonymous to 2. In XP and 2003, any non-zero number (including 2) has the same effect as =1. Even with values set at 1 or 2, explicit permission for the anonymous user account can begiven to different registry keys, shares, Named Pipes, etc. This setting simply prevents anonymousenumeration without explicit access.

Never set the Restrict Anonymous registry key value to 2 in mixed domain environments or withlegacy clients. It is safer to set the value to 1. If you need to permit clients running versions of Windows earlier than Windows 2000 to change their passwords, add the Everyone and AnonymousLogon groups to the pre-Windows 2000 compatible access group, enabling anonymous access to theaccounts. Use the Let Everyone permissions apply to anonymous users policy to extend anonymousaccess to match the Windows NT 4.0 model. Disable or do not configure this policy if your domainincludes computers running versions of Windows earlier than Windows 2000 or if it has an outbound, one-way trust relationship with a domain in another forest.

The browser service on computers running Windows NT 4.0 and earlier requires the ability toenumerate shares anonymously when it connects to backup browsers, master browsers, and domainmaster browsers to retrieve server lists and domain lists. Users on the trusting side of a one-way trustrelationship need the ability to enumerate SAM accounts anonymously when they add domainaccounts and groups on the trusted side of the relationship to security groups in the trusting domain.Most, but not all, of the issues are related to pre-2000 computers and domains.

It is easier to control anonymous enumeration by adjusting group policy settings in WindowsServer 2003. The settings are

• Do not allow anonymous enumeration of SAM accounts• Do not allow anonymous enumeration of SAM accounts and shares• Allow Anonymous SID/Name translation

The first option, Do not allow anonymous enumeration of SAM accounts, was called Additionalrestrictions for anonymous users in Windows 2000. Do not allow anonymous enumeration of SAMaccounts and shares is a new option in XP and 2003. Allow Anonymous SID/Name translation is anew option in XP and 2003; it was not part of 2000.

Allow Anonymous SID/Name translation is disabled by default on Windows Server 2003 memberservers (but not domain controllers). If enabled, it makes a system less secure because it lets hackersfind renamed administrator and guest accounts. Unfortunately, domain controllers must leave anonymous SID/Name translation enabled in order to do their job.

NoteBecause domain controllers have no SAM to worry about, disallowing anonymous enumerationof SAM accounts has no effect on domain controllers.

One of the big changes between 2000 and later versions (XP and 2003) is that anonymous users are not part of the Everyone group, by default. You can, however, enable the Let Everyone permissions apply to anonymous users setting to support legacy applications and operating systemfunctions. The anonymous user can never be added to the Authenticated Users group, which has thesame membership as the Everyone group without the anonymous user and guest account.

n



Windows Server 2003 has new ways to fine-tune what objects anonymous users can enumerateand to define the shares, registry keys, and named pipes that are remotely accessible. New securitysettings define what default shares can be accessed anonymously. The default shares includeCOMCFG and DFS$. COMCFG is used for SNA legacy applications and DFS$ is used by the WindowsDistributed File System feature. The COMCFG share is not usually active on most servers (unless youhave SNA server installed), so you can ignore it. If DFS is enabled on your server and the DFS$ shareis enabled, do not disable it.

The Remote accessible registry paths and subpaths setting is another new security setting introduced in Server 2003. It replaces XP’s Remote accessible registry paths. Either security settingdefines registry keys that are accessible to anyone, including anonymous users, regardless of the key’sACL permissions. You can add registry keys to remotely accessible registry paths as desired. Turningoff remote registry accesses breaks most remote management tools.

Default settings for named pipes that can be accessed anonymously are COMNAP, COMNODE,SQL\QUERY, SPOOLSS, LLSRPC, EPMAPPER, LOCATOR, TrkWks, and TrkSvr.

• The COMNAP and COMNODE named pipes are used for SNA sessions with certain clients(OS/2, Win95, Windows 3.x and LanMan 2.2c) that are trying to connect to a Microsoft SNAServer (service) running on a Windows NT 4.0 box.

• The SQL\QUERY named pipe provides null connectivity to Microsoft’s SQL Server running ona Windows NT 4.0 box.

• The SPOOLSS named pipe provides null connectivity to the Spooler service (Print Server).Typically SPOOLSS can be removed from the Print Server without causing too many problems,but problems can occur with legacy clients (see Knowledge Base article 162695 SMSINST, entitled” ‘Access Denied’ Message When Connecting to a Printer”).

• The LLSRPC named pipe provides null connectivity to the RPC Interface of the License Logging Service.

• The EPMAPPER named pipe provides null connectivity to the Endpoint Mapper, which lists all the applications that are using RPC. Disabling this can cause problems.

• The LOCATOR named pipe provides null connectivity to the name-service provider service. • TrkWks (workstation) and TrkSvr (server) are related to Distributed Link Tracking and should

not be removed.

As shown in Table 2-1, the Restrict Anonymous setting is the guiding control that determineswhether an anonymous connection can access local SAM accounts and shares. Note that Anonymousin the Everyone Group setting does not seem to affect the outcome.

Table 2-1 Effect of disabling anonymous enumerations on a domain controller

Setting Outcome Restrict Anonymous Anonymous in Can Anonymous enumerate local Enabled? Everyone Group SAM shares and accounts?

No Yes Yes No No Yes Yes No No Yes Yes No



Table 2-2 shows the complex interactions of anonymous enumerations, coupled with the inclu-sive membership of the Everyone and Pre-Windows 2000 Compatibility groups.

Table 2-2 Effect of anonymous enumerations

Setting Outcome Restrict Anonymous Anonymous in Membership of Pre-Windows Can Anonymous Enabled? Everyone Group 2000 Compatibility Group enumerate AD data?

No Effect No Empty No No Effect No Everyone No No Effect No Anonymous Yes No Effect Yes Empty No No Effect Yes Everyone Yes No Effect Yes Anonymous Yes

Use Tables 2-1 and 2-2 to strengthen your network against malicious enumerations.

Windows Logon Authentication Best Practice Recommendations Windows Logon Authentication is important to Windows computer and network security. Followthese best practice recommendations to strengthen your environment:

• Limit authentication to Kerberos and NTLMv2 authentication whenever possible. LM and NTLMauthentication protocols are demonstrably insecure. Disable them whenever you can.

• Disable LM Password Hashes (covered in more detail in Chapter 3). By default, LM passwordhashes are stored in SAM and AD verification databases by default on all Windows versions.This is the password hash that most brute force hacking tools compromise.

• Disable anonymous enumeration when possible.

Most network administrators never give Windows Logon authentication protocols a secondthought—users log on and the protocols do all the hard work behind the scenes. However, as statedin this chapter, understanding and configuring authentication protocols is an important part of anyadministrator’s job.

Remote Authentication Protocols Remote authentication protocols are used when a user connects to Routing and Remove Access Services (RRAS) or Internet Authentication Service (IAS). The remote authentication protocol choices are:

• EAP• MS-CHAPv2• MS-CHAP• CHAP• SPAP• PAP• Unauthenticated Access



The list goes from strongest at the top to weakest at the bottom. If several authentication protocols are selected, the client can authenticate to the first available protocol that matches their ownoptions. You may need to enable weaker protocols if the connecting clients don’t understand thestronger choices. For example, if Macintosh or Unix clients want to connect, they may support onlyPAP or CHAP protocols. Also, using weaker protocols often requires that reversible encryption beenabled on the principal’s account.

For a remote authentication protocol to work from a Windows client to an RRAS server, the threecomponents must be configured with the same protocol(s) and settings. The three components are:

1. Remote client software2. Remote Access Policy (RAP)3. Remote access server (RAS)

If all three components don’t share the same protocol settings, remote authentication fails. Evenafter authenticating remotely successfully, the user often must still go through some form of Windowslogon authentication, such as LM, NTLM, or NTLMv2.

NoteRRAS prevents the use of Kerberos.

Let’s consider each of the remote authentication protocols in turn, from strongest to weakest.

Extensible Authentication Protocol (EAP) The newest and most secure remote authentication protocol is EAP. Several of the many types of EAPprotocols are listed below.

• EAP MD5-Challenge (aka EAP-MS-CHAPv2) uses the same handshake protocol as PPP-basedCHAP but sends challenges and responses as EAP messages.

• PEAP-EAP-MS-CHAPv2 is easier to deploy than EAP-TLS because user authentication is accomplished with a password-based credential (username and password) instead of certificates or smart cards (as is used in EAP-TLS). When PEAP-EAP-MS-CHAPv2 is used onlyRADIUS server (if used) is required to have a certificate (which must be trusted by client).

• PEAP-EAP-TLS uses certificates for server authentication and certificates or smart cards for user and computer authentication. Must use PKI. EAP-TLS can only be used in domain environments running RRAS.

Windows 2000 supports only MD5 and EAP-TLS EAP types. The PEAP protocol layer is new in Server 2003. It is not a remote authentication protocol (or EAP type) by itself; instead, it is used to create an encrypted TLS channel between the PEAP client and the PEAP authenticator (RRAS orIAS server). This channel is a secure tunnel that can be used in conjunction with other remoteauthentication protocols (EAP-MS-CHAP or EAP-TLS) to provide secure access. PEAP can be used for802.11 wireless client computers but is not supported for VPN or other RAS client types.

n



Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) After EAP (which many legacy clients don’t support), Microsoft Challenge Handshake AuthenticationProtocol (MS-CHAP) is the most secure remote authentication protocol in Windows. As with NTLM,MS-CHAP’s version 2.0 is more secure than the first version and should be used when MS-CHAP support is desired. Version 1.0 provides only one-way authentication (client to server) and uses thesame cryptographic key for sending and receiving data. Every time a user connects with the samepassword, the same cryptographic key is generated because it is based on the user’s password. It alsoallows LM authentication. These limitations were solved in MS-CHAP version 2 (MS-CHAPv2). In contrast, MS-CHAPv2 provides these features:

• Two-way, mutual authentication (client to server and server to client)• Separate cryptographic keys for sending and receiving data• Different cryptographic keys used for each connection session• Does not allow LM authentication

MS-CHAP (version 1 or 2) is the only remote authentication protocol that allows passwordchanges during the authentication process. Windows 95 needs the DUN 1.3 upgrade to support MS-CHAPv2, although it can only be used for VPN connections (not dial-up). Encryption expert BruceSchneier has written an excellent paper comparing MS-CHAP and MS-CHAPv2(http://www.schneier.com/paper-pptpv2.html).

Challenge Handshake Authentication Protocol (CHAP) Challenge Handshake Authentication Protocol (CHAP) was one of the first industry standard protocols to utilize a challenge-response algorithm instead of transmitting authentication credentials inclear text. CHAP is documented in RFC 1334 (http://www.faqs.org/rfcs/rfc1334.html), along with itsless-secure cousin, PAP (covered below).

After the initial physical link is established, CHAP is used to authenticate the user to the remoteauthenticator. The CHAP authentication sequence is submitted upon the initial connection and can berequested again at any time during the communication session. A CHAP authentication sequenceinvolves three steps:

1. The authenticator sends a “challenge” to the client.2. The client responses using a value calculated using their MD5 password hash. For this reason,

CHAP authentication requires passwords that are stored with reversible encryption (a securitysetting disabled by default in Windows 2003 Server).

3. The authenticator checks the client’s hashed response against the expected hash calculation. Ifthe two hashes agree, the client is authenticated. CHAP provides limited protection againstreplay attacks, but cannot be used in Microsoft Point-to-Point (MPPE) tunneling.

Password Authentication Protocol (PAP) and Shiva Password Authentication Protocol (SPAP) Both Password Authentication Protocol (PAP) and Shiva Password Authentication Protocol (SPAP) are legacy protocols intended to add a basic user authentication layer to serial access networks whenfew authentication standards existed. PAP is an open standard, but SPAP is a proprietary protocolimplemented by a company with a popular (in the 1990’s) line of remote communication devices andmodems. Both protocols are often considered together because they had similar features and werereleased in the same time period. Except for unauthenticated access, PAP and SPAP are the least



http://www.schneier.com/paper-pptpv2.html


secure methods of authentication because the user’s credentials are transmitted in clear text and theylack anti-replay mechanisms. When either is used and the initial link is established, the client beginssending the plaintext user ID and password combination repeatedly to the authenticator until itacknowledges the authentication or terminates the connection. If the authentication is accepted, theuser’s credentials are never passed again or verified. You cannot use Microsoft Point-to-Point (MPPE)tunneling with SPAP or PAP.

Unauthenticated Access Authentication Unauthenticated access means the user name and password are not required for remote connectionestablishment. Unauthenticated access might be useful in mixed-client environments, guest logons, orwith DNIS or ANI/CLI authentication. Unauthenticated access may even be desirable, if you offset therisk by implementing some other external form of authentication or security. For example, if the userhas already authenticated to the hardware-based VPN solution, it may be reasonable for the remoteauthentication protocol to be essentially disabled.

Internet Information Service (IIS) Authentication Protocols Internet Information Service (IIS) has its own set of authentication protocols. You can use them asanother layer on top of the NTFS permissions and authentication encountered while accessing underlying files and folders of a web site. Internet Information Service (IIS) authentication protocolsinclude:

• Anonymous• Basic• Digest• Advanced Digest• Integrated Windows Authentication

- NTLM- Kerberos

• .NET Passport• SSL/TLS Digital Certificates

Note Share permissions do not apply to IIS-contacted files and folders.

IIS authentication protocols allow the web administrator to prompt the user, or the user’sbrowser, for a username and password associated with an account either in the local SAM or theActive Directory. You can simultaneously support multiple forms of authentication. IIS will alwaysattempt the more complex or restrictive form of authentication, falling back until it finds a method theclient can support.

Authentication protocols can be enabled at the server level, per web site, per folder, and evenper file. Like most security permissions in Windows, higher-level authentication protocols inheritedabove can be overwritten by lower-level authentication protocols that are explicitly set. For example,a web site configured for anonymous access can require that logon credentials be used to access particular folders, web pages, or files.

n



Anonymous Authentication When a web resource is set up with anonymous authentication, neither the user nor the user’sbrowser will be prompted for login credentials. Access is granted using the rights and permissions ofthe user account affiliated with the IIS anonymous user (the default is IUSR_computername). Therecan be only a single IIS anonymous user account shared among all web sites with anonymousauthentication enabled. Anonymous enumeration is used where non-authenticated public access isdesired.

NoteDo not confuse the anonymous user account that IIS uses with the anonymous context used fornull session Windows logons.

Basic Authentication Basic authentication prompts the user for a logon name and password, but it doesn’t require InternetExplorer or Active Directory. It is used when the web site needs to support a wide variety of Webbrowsers and clients (such as Mac, OS/2, Unix, and Linux). It uses passwords obscured only withBase64 encoding, which is nearly plain-text. You can improve the security of basic authentication bycombining it with SSL.

Digest Authentication Digest authentication prompts the user for a login name and password and requires Active Directoryrunning on Microsoft Windows 2000 Server or later. The protocol uses password hashes, not the actual password itself, and it supports authentication through firewalls and proxies. Digest authentication requires you to encrypt and store the user’s password with reversible encryption and itrequires the connecting client to use Internet Explorer version 5.0 or later.

If Digest authentication is used on a W2K3 web server running in a W2K3 domain, DigestAuthentication becomes Advanced Digest Authentication. Advanced Digest was introduced in Windows Server 2003 as an improvement over Digest authentication. It stores a version of the password that has been hashed with MD5. It is available only after the Windows Server 2003 schemaextension.

Integrated Windows Authentication Integrated Windows authentication is useful for times when you need a moderate level of userauthentication, but you don’t necessarily need the user to do a manual logon. For example, it is oftenenabled on intranet web servers; it passes the user’s Windows authentication logon credentials to theweb site without prompting the user (a setting that can be configured in Internet Explorer). NTLMand Kerberos are both usable in Integrated Windows Authentication. NTLM requires Internet Explorer2.0 or later, and Kerberos requires Internet Explorer 5.0 or later, or Windows 2000 or later.

.NET Passport

.NET Passport authentication can be used starting with Windows Server 2003 and IIS 6.0. .NET Passport is essentially another TTP service. A central web site administered by Microsoft performs

n



authentication, and authentication success is sent to participating web sites. When the user logs on toa web site that requires a .NET passport logon, the user is temporarily redirected to Microsoft’s .NETPassport authentication service. The user then authenticates to the .NET Passport service. ParticipatingWeb sites never receive a member’s password.

The central .NET Passport server(s) return encrypted sign-in and profile information to the participating web site, which can then use the client’s Passport authentication approval to write localcookies. The use of cookies avoids redirects back to the central .NET Passport servers on subsequentpage views. The .NET Passport central server does not authorize or deny access to individual .sites. Itis the responsibility of the Web site to control user access rights.

Microsoft .NET Passport uses standard Web technologies, such as SSL, HTTP redirects, cookies,JScript, and symmetric key encryption. .NET Passport is compatible with Internet Explorer 4 and later,Netscape Navigator version 4.0 and later, and some versions of UNIX.

SSL/TLS Digital Certificates Web servers or clients can also require the use of trusted digital certificates for authentication. In thetypical web server SSL scenario, the client connects to an SSL server; the SSL server then sends theclient its public digital certificate, which authenticates the server to the client. The client uses theserver’s digital certificate to create a secure channel, over which is passed a shared symmetric keythat is used to encrypt and decrypt protected communications. Although digital certificates are morelikely to be used for server-to-client authentication, the server can require clients to use digital certificates and authenticate, too.

Table 2-3 summarizes IIS authentication protocols and their characteristics.



Table 2-3 IIS authentication protocol characteristics

Method Security How Passwords Crosses Proxy Servers Client RequirementsLevel Are Sent and Firewalls

Anonymous None N/A Yes Any browser authentication Basic Low Base64 encoded Yes, but sending passwords Most browsers authentication clear text across a proxy server or

firewall in clear text is a security risk because Base64 encoded clear text is not encrypted.

Digest Medium Hashed Yes Internet Explorer 5 orauthentication later Integrated High Hashed when No, unless used over a Internet Explorer 2.0 orWindows NTLM is used; PPTP connection later for NTLM; authentication Kerberos ticket Windows 2000 or later

when Kerberos with internet Explorer 5is used. or later for Kerberos

.NET Passport High Encrypted Yes, with an SSL connection Internet Explorer andauthentication Netscape SSL/TLS Digital High n/a Yes Most browsers support Certificates SSL or TLS

When a user accesses an IIS web site, IIS authentication is performed before access is given.After remotely authenticating to the IIS server, the user’s effective permissions are determined by theweb site’s intersection of NTFS permissions and its IIS permissions (e.g. Read, Execute, DirectoryBrowsing).

Microsoft Credential ManagerMicrosoft Credential Manager (MCM) is a single-signon solution available in Windows XP and Server2003. You may have used it without even realizing it, because no GUI is entitled Microsoft CredentialManager. Essentially, MCM gives users an opportunity to store and automatically use passwords thatbelong to different DNS or NetBIOS domains if the contacted applications are MCM-aware.

If a user or the user’s system is prompted for logon credentials, MCM first replies with the user’scurrent logon credentials. If that fails and the application is MCM-aware, the application can promptMCM for the appropriate credentials, assuming the credentials have been stored before. If the credentials haven’t been stored before, the user is prompted for the credentials and be given theopportunity to save the credentials at the Remember my password check box. The credentials arethen saved in the user’s local or roaming profile and can be access by any application using the MCMAPI. The next time a user access the same resource, MCM automatically offers the application themapped credentials without prompting the end user.

You can access the MCM User Interface by opening the Control Panel User Accounts applet,clicking the Advanced tab, and choosing the Manage Passwords option (Figure 2-5).



Figure 2-5 Microsoft Credential Manager user interface

Note MCM must be used with caution. The authentication credentials stored by MCM are notsynchronized with normal password mechanisms. Therefore, if a stored password is changed orreset on the application side and the MCM is not changed, too, the result is failed logons, andperhaps an account lockout.

Many security experts believe a single sign on is equivalent to a single failure point—and they’reright. If the Windows logon authentication account is compromised, an intruder can then access anysites that are listed in the MCM User Interface (see Figure 2-5) without being prompted for an authentication password.

n



MCM passwords can be stored and accessed at the command prompt using the Net Use /Savecred command (http://support.microsoft.com/?kbid=287536) in both Windows 2003 and XP.Windows 2003 also has a command prompt utility called CMDKEY (see Figure 2-6) that can be usedto manage MCM credentials.

Figure 2-6 CMDKEY command-line options

Summary In this chapter, we took a detailed look at Windows authentication protocols and made best practicerecommendations. For strong security, it is essential that Windows authentication be configured correctly. Administrators should disable LM and NTLM protocols, disable anonymous enumerations,and disable LM password hash storage. Unfortunately, even strong authentication practices can beundermined by weak passwords.

Chapter 3 will review password policies and make best practice recommendations for a strongpassword system.



http://support.microsoft.com/?kbid=287536

50


Chapter 3:

Protecting PasswordsThis chapter is devoted to a discussion of developing and maintaining strong password systems. It discusses how passwords figure into the Windows logon process, other ways Windows uses passwords, the characteristics of a strong password, how to crack Windows passwords, and passwordbest practices.

The Windows Logon As discussed in Chapter 2, “Windows Authentication,” passwords are the most common type ofauthorization check in Windows, although a security token, such as a smart card, or a Kerberos ticketis also a valid security credential. Passwords are used by security principals — users, groups, andcomputers — and many different processes, including trusts, clustering, and services. Passwords canbe submitted during logon or while accessing a resource; they can be local or submitted over a network.

One of the most common password authentication events is that of a user logging on locally.The user types the logon name followed by the password. The user’s logon name must be uniquewithin the authentication database; also, theoretically, only the user knows his or her password. Thus,a successful logon uniquely identifies the user to the authentication server. After successfully loggingon, authentication processes help authorize the user access allowed resources.

During an interactive logon, the Winlogon.exe process is responsible for managing the security-related user interactions with the operating system and for coordinating the logon and logoffprocesses. Winlogon.exe calls the Msgina.dll (graphical identification and authentication interface),which displays the standard logon box. Msgina.dll prompts the user for the logon name and password, and possibly more information, such as the domain name. The Winlogon process passesthe information that is input securely to the Local Security Authority (LSA) process, which determineswhether the logon request must be authenticated locally or against a domain database and whether itrequires Kerberos or NTLM authentication (see Figure 3-1).

Figure 3-1 Windows Interactive Logon Authentication Pathway

Local Logons If the local computer name is referenced during the logon, a local logon is initiated. The local credential database is a Security Account Manager (SAM) database. The SAM database is stored in aprotected subdirectory that is usually accessible only to the LSA process. The SAM database is in aspecially protected part of the registry in the HKEY_LOCAL_MACHINE\SECURITY\SAM subkey andduplicated to the HKEY_LOCAL_MACHINE\SAM subkey. At the file system level, the SAM registryfiles are stored together with the registry files under \%systemroot%\system32\config (SECURITY andSAM files). Many password cracker utilities attack these keys or physical file locations.

The password captured by Msgina.dll is hashed, using the LM or NTLM algorithm (which wascovered in Chapter 2), and sent to the NTLM driver (Msv1_0.dll). A challenge-response session is initiated and compared against the stored credentials. Local accounts can be used to access resourcesonly on the local computer where the credentials are authenticated.

Chapter 3 Protecting Passwords 51


Winlogon.exeMsgina.dll

LSA process

SAM Database

Active Directory

SAM Database

DomainLocal

Local or

Domain Logon?

LM or

NTLM?

LM, NTLM, or Kerberos?

NT domains

Windows 2000and laterdomains



Domain Logons If a domain name is referenced during the logon process, the next step is to determine whether touse Kerberos or NTLM authentication. In Windows 2000 and later, the LSA does this by passing thelogon credentials to the Security Support Provider Interface (SSPI). If the user’s logon name cannot be found in the Kerberos Key Distribution Center (KDC) domain database, the credentials are resubmitted to the NTLM driver (Msv1_0.dll), which then uses the Net Logon service to complete theauthentication process.

The user’s domain logon account can exist in only one domain in the Windows forest. Usersmust successfully log on to their account’s “home” domain and one of its domain controllers to beauthenticated (setting aside for the moment the existence of cached logon credentials). In a largedomain, a user might log on with his or her user principal name (UPN) to ensure that the logonrequest reaches the appropriate domain and domain controllers. The UPN uniquely identifies the useraccount in an Active Directory forest. Typically, the UPN is the account’s logon name followed by theaccount’s local domain name (although UPNs can be virtually any suffix). For example, Fred Smith’sUPN might be [email protected].

The domain credential database is queried to see whether the submitted logon credentials arevalid. The domain database can be either a SAM database (NT 4.0 or earlier) or Active Directory(Windows 2000 or Windows 2003 domains). The Active Directory database is a Jet database calledNTDS.DIT and is stored by default on domain controllers in the %windir%\NTDS folder (the locationis chosen during the Dcpromo). In Active Directory, user passwords are stored in the user object inthe unicodePwd attribute; they are Unicode octet-strings that are encoded using Basic Encoding Rules (BER).

NoteUnicode characters can represent several different language and character sets using a singleset of ASCII characters.

If the NTLM authentication protocol is used, the Net Logon service queries the SAM database.The Net Logon service passes the user’s hashed response through a secure channel to the SAMdomain database. In addition, the Net Logon service performs a variety of other functions related tothe logon process, such as periodic password updates for computer accounts and domain controllerdiscovery.

If Kerberos is used, the KDC service authenticates logon requests to the Active Directory database(the Kerberos authentication process was covered in Chapter 2). The KDC service runs on all domaincontrollers (Windows 2000 and above). Any future authentication events are handled by the KDC oreach computer’s LSA or Net Logon service. Access tokens or Kerberos tickets are created using thesecurity identifiers (SIDs) assigned to the user’s account and group memberships. Then, for interactiveusers, the Windows Explorer shell is started. When a user wants to access an object protected by anaccess control list (ACL), the user’s access token or ticket is analyzed to determine whether therequest is allowed.

n

Password Conflict Resolution In a (Windows 2000 or later) domain environment, passwords are managed by the domain controllerthat is acting as the primary domain controller (PDC) Flexible Single-Master Operation (FSMO) roleowner for the domain. By default, password changes for user and machine accounts are sent immediately to the PDC FSMO.

In a mixed-mode domain, if a Microsoft Windows NT 4.0 domain controller receives the request,the client is sent to the PDC FSMO role owner (which must be a Windows 2000- or 2003-based computer) to make the password change. This change is then replicated to other Windows 2000domain controllers using Active Directory replication and to down-level domain controllers throughthe replication process.

If a Windows 2000 domain controller receives the request (either in mixed or native mode), thepassword change is made locally and sent immediately to the PDC FSMO role owner using the NetLogon service in the form of a Remote Procedure Call (RPC). The password change is then replicatedto its partners using the Active Directory replication process. Down-level domain controllers replicatethe change directly from the PDC FSMO role owner (or from a replication partner if they do notdirectly replicate from the PDC FSMO role holder).

During logon, if a user’s (or computer’s) logon name is found in the credential database, but thepasswords do not match the domain controller’s local copy of the Active Directory database, the PDCFSMO is contacted for resolution. If the collected password matches the one stored at the PDC FSMO,then the logon authentication is allowed and the domain controller denying the original request isupdated. If the passwords don’t match, the PDC FSMO indicates the failure in its return code to thedomain controller, and the logon fails. Because the PDC FSMO is the ultimate arbitrator of passwordsynchronization, it is the service that determines when to lock out an account because of invalidlogon attempts with incorrect passwords.

Therefore, in a distributed domain environment with more than one domain controller, administrators need to pay special attention to password changes. Password resets done at the PDCFSMO may take time to replicate to the domain controller that the user is logging onto. You canbypass the password synchronization lag problem by resetting the password on the domain controller(if you know it) where the user is logging on. To find out which domain controller the user is logging onto, you can audit Logon Account events or use one of several other Microsoft utilities.

To reset the password on a particular domain controller, you connect to it (in Active DirectoryUsers and Computers) first — before resetting the password. This way, the user will be able to takeadvantage of the password reset immediately, and the new password is then propagated to the PDCFSMO. Of course, if the affected domain controller is not a direct replicating partner of the PDCFSMO role holder, the change will be replicated from the domain controller to its replication partnerand eventually make its way to the PDC FSMO holder, depending on your replication topology.



CautionResetting passwords can cause a user’s EFS files to be inaccessible. EFS-protected files areencrypted using a user’s EFS public key. Decrypting requires the user’s EFS private key. Theuser’s EFS private key is stored in the user’s local profile (and on the server if roaming profilesare used). The EFS private key is protected with another “master key,” which is associated withthe user’s password. If a password is reset by a third party, the user’s master key can no longerunlock the EFS private key, which leaves the EFS-protected files unavailable (unless other datarecovery methods were implemented).

Windows Password Uses Password credentials are used throughout Windows, more than only for user logons and authentication events. Passwords are created for computer accounts, services, trusts, and all sorts ofother events that require authentication. Many users don’t fully understand these other commonaccounts with passwords.

Computer Account Each computer that accesses a domain must have a valid logon name and password. Usually, Windows sets and updates computer account credentials without user intervention. The machineaccount is authenticated, both as an additional security measure and to establish a secure channelbetween the workstation and the domain controller. The secure channel is used for authentication butis not encrypted.

Each Windows-based computer maintains a machine account password history that contains thecurrent and previous passwords for the account. When two computers try to authenticate with eachother and a change to the current password has not yet been received, Windows relies on the previous password. If the sequence of password changes has occurred more than twice, the computers involved may not be able to communicate, and you may receive error messages. Forexample, you may receive an “Access Denied” error messages when Active Directory replicationoccurs. This behavior also applies to replication between domain controllers of the same domain.

You cannot change the machine account password with the Active Directory Users and Computers snap-in, but you can reset the password with the Netdom.exe tool. The Netdom.exe toolis included in the Windows Support Tools (on the install media located in \SUPPORT\TOOLS\SUPPORT.CAB). The Netdom.exe tool resets the account password on the computer locally (knownas a local secret) and, at the same time, writes this change to the computer’s computer account objecton a Windows domain controller that resides in the same domain. Simultaneously writing the newpassword to both places ensures that at least the two computers involved in the operation are synchronized. Normal Active Directory replication ensures that the other domain controllers receivethe change.

Directory Services Restore Mode Password When a member server is promoted to a domain controller (i.e., using Dcpromo.exe), accounts in theSAM, along with a new set of default users and groups, are migrated to the jet-based Active Directory

d





database. A new registry-based SAM, containing an “offline” administrator account and other built-inaccounts needed to recover and manage the domain controller, is created. The original local accountsare no longer available or accessible in the local SAM database.

The new SAM-based accounts and passwords are computer-specific and are not replicated toother domain controllers in the domain. They are available only in Directory Services Restore mode,accessed by pressing F8 in the early part of the Windows boot process (which takes Active Directoryoffline). During the domain controller creation process, the user is prompted for a Directory ServicesRestore mode administrative account password. This password is used only when starting the domaincontroller in Directory Services Restore mode or when using the Windows Recovery Console. Moreimportant, password changes to the domain administrator account have no effect upon the DirectoryServices Restore mode password.

Because this newly created administrative account is rarely accessed, and many administratorsdon’t understand its implications, the password is often forgotten or lost. You can change it in Windows 2000 using Microsoft’s Setpwd.exe utility (http://support.microsoft.com/default.aspx?kbid=810037) or in Windows 2003 using Ntdsutil.exe (http://support.microsoft.com/kb/322672).

Service Account Passwords Windows services must log on to the operating system to begin operation. Services can use one ofthe built-in service accounts in Windows (Local System, LocalService, or NetworkService) or a custom-created service account. In simple terms, a service account is nothing more than a normaluser account that is granted the Logon as a Service user right. This right lets the service account logon to the operating system (under the auspices of the Service Control Manager) when Windows isbooted without waiting for the actual user to log on; this right also confers additional rights for interacting with the operating system.

The default built-in service accounts do have passwords, but they are managed by the operatingsystem. Custom-created service accounts must have credentials supplied to the service (which is thenstored in Service Control Manager database located in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services) and also set up in the normal user credentialing database (SAMor Active Directory). Passwords for custom-created service accounts should be strong and should bechanged more frequently than passwords for accounts with lesser privileges. Although there is nogeneral rule of thumb, many hardening guides recommend changing passwords at least monthly.Password changes must be synchronized between the service’s logon properties and the credentialdatabase. You can synchronize them manually, by creating your own script (check http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/changing_the_password_on_a_serviceampaposs_user_account.asp), or by using one of the scripts widely available on the Internet.

Of course, many other types of passwords are used throughout Windows, depending on yourconfiguration and services. Other services that require passwords include Windows trusts, clustering,Microsoft Credential Manager, remote access, telnet services, web sites, and SQL server passwords.Passwords are even required to unlock screen savers. Anywhere passwords are used in Windows, itis best to use strong passwords, which leads us to the question, “What does ‘use strong passwords’mean?”

http://support.microsoft.com/kb/322672

http://support.microsoft.com/default.aspx?kbid=810037

http://support.microsoft.com/default.aspx?kbid=810037

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/changing_the_password_on_a_serviceampaposs_user_account.asp



Creating Strong Passwords The exact definition of what is and isn’t a strong password is a subject of debate, especially if you’relooking for specific and exact figures. Older textbooks and discussion papers often select an absoluteminimum password size and paint that size as constituting a strong password. Conventional wisdomsays that a password’s length should increase as the value of the asset it protects increases. However,the truth is that strength depends on more than only the password itself and is certainly more complicated than the single characteristic of password size. For example, experts agree that a weakpassword is one that can be easily guessed.

A strong password is one that can outlast expected and near-term future attacks. It is much like abuilding with an alarm system and locked glass doors. An alarm system with an audible alert is neverdesigned to stop intruders – it’s a defense-in-depth countermeasure to alert other dissuaders. Similarly,locked glass doors won’t stop a sufficiently motivated attacker for long. Instead, they’re intended tostop most attackers from the attempt in the first place and to stop the dedicated intruder just longenough for the cops to show up.

A good password system works the same way. An appropriate password system will discourageor prevent most intruders from attacking in the first place; it will slow down those would-be intruderswho do attack. A password has to be strong enough only to last until another offsetting control canactively participate – or until the protected asset has limited value. That last statement may soundstrange, but consider this: confidential World War II secrets only had to outlast the war. Yesterday’ssecret ciphers are today’s classroom examples.

The strength of a password should flex according to the value of the asset it is protecting. Thepassword that protects this document’s transportation during its pre-publication phase is not nearly asimportant as a password protecting an Active Directory domain database for a large company.

A strong password requires a strong password system. A strong password system is made up of• A strong, enforced password policy• The reliable identification and verification of applicants • A secure authentication protocol• A secure credential database• And yes, a secure passwordLet’s consider each element in turn.

Password Policy A password policy establishes minimum password system characteristics as discussed and defined bymanagement. A password policy should be written, approved, and shared with users. It should detailthe characteristics of a strong and secure password, such as those listed in the next paragraph. Inshort, a password policy should control user behavior.

For example, passwords should never be shared, not even with IT help desk support (unlessthey’re changed immediately). Users who freely share their passwords should be penalized. Passwords should not be posted in public places or documented in a way that can allow for easydisclosure. Passwords should not be made up of words that could easily be associated with the user.Passwords should not be named after loved ones, pets, or sports teams. A user who learns of a password compromise should report it to the appropriate team members.

However, password policy should cover more than just computers and more than Windowsoperating system passwords. Company should require passwords for cell phones, PDAs, PBX remote



maintenance consoles, fax machines, copiers, and in any other place where individual auditing andaccess control is appropriate. Passwords should be required on bootup for laptop and PDAs to protect confidentiality; they should also be required for PC BIOS changes. A good password policyshould minimize the number of privileged accounts that can change or reset passwords, unless usersare supposed to take care of their own password changes.

A password policy should recommend that logon credentials should not be shared among users,including IT users. For example, it is a common practice in some companies to have computers thatstay logged on with the same user name (e.g. Front Desk or Accounting1, etc.), regardless of who isactually using the computer. This practice should be discouraged. Even if the logon name is identical,each user should have a unique password. Similarly, the domain administrative password should notbe the same as local administrative passwords. BIOS passwords should never the same as operatingsystem passwords. The Directory Services Restore mode password should be different, too. Usersshould be encouraged to use different passwords for different applications and web sites. Failure todo so could result in a more sensitive compromise.

Windows authentication supports a default mechanism, pass-through authentication, that cancause problems if logon credentials aren’t different. If a login-account-and-password combination isidentical in two domains or forests, Windows assumes you want to manage the objects in the destination resource domain with the credentials of the security principle in the destination domain or forest — even though you began by using the source domain’s credentials. It will appear as if theresource access in the destination domain is occurring from the source domain security principalaccount, even though it is not.

For example, assume I have two Active Directory forests, Forest A and Forest B, on the same IPsubnet but without a Windows trust. Theoretically, an administrator in Forest A should not be able tomanage and access resources in Forest B, because they have two different security principal accounts.But if the two security principal accounts are the same, Windows will assume I want to use the destination security principal’s credentials and give me access. This Windows “feature” is an unintended security credential collision that probably, in most cases, is desired by network administrators.

Unless good password policy is communicated to employees, they will likely use the same password at work and to access untrusted websites on the Internet. On a weakly protected web site,a hacker could discover a user’s password and then use it to attack the user’s online bank account —or the company’s payroll database.

When you have created and communicated a password policy, you should enforce it. In practice,enforcement can be hard. For example, you might want to enforce a policy that passwords musthave more than 15 characters so that the LM hash can’t be stored. However, Active Directory andLocal Computer Policy allows the minimum password length to be 14 characters (this limit will beincreased in the future). Even if you require a certain size password or a certain combination of char-acters, some systems do not support them. Many web sites cannot handle passwords with more thaneight characters. Some mainframe systems have a maximum password size of 6 characters. Someoperating systems don’t handle case-sensitive passwords. Some Unicode or control characters are notavailable on all keyboard language sets.

Regardless of the policy and enforcement method, passwords should be periodically audited(manually or using automated tools) to ensure compliance. No matter how strong the rest of thepassword system is, a single password can be compromised by lazy policy enforcement.



For more information about developing a password policy, see • “Password Policy” on the SANS (SysAdmin, Audit, Network, Security) Web site at

http://go.microsoft.com/fwlink/?LinkId=22205. SANS has advice about creating formal corporate security policies and sample policies.

• “Sample Generic Policy and High Level Procedures for Passwords and Access Forms” on the National Institute of Standards (NIST) Web site athttp://go.microsoft.com/fwlink/?LinkId=22206. NIST has a sample password policy that many government agencies have used.

• “Account Passwords and Policies” on the Microsoft TechNet Web site athttp://go.microsoft.com/fwlink/?LinkId=22208.

Applicant Identity If a password credential is to be worth anything, the user’s identity needs to be independently verified before it is associated with a credential set (logon name and password). If any person cancall to get a password or request a password change, you have poor password control. All passwordrequests should be accompanied by some form of third-party verification. Employees should requestpassword-related changes in person; the requests should be approved by management or verified bysome other process (for example, the administrator may recognize the applicant). The process foridentifying applicants should be covered in the password policy. Universal enforcement of the process reduces fraud from social engineering attacks.

Secure Authentication Protocol As covered in Chapter 2, using a reliable and secure authentication protocol is significant. Weakauthentication protocols lead to trivial exploits and compromises. For that reason, use of the LM andNTLM (not NTLM version 2) authentication protocols should be discouraged and they should be disabled wherever practical.

NoteYou should disable LM and NTLM only if you aren’t using any applications and services relyingon those protocols. Most Windows password recovery tools rely upon the existence of LM orNTLM password hashes to be successful.

All newer Windows operating systems are capable of authenticating using LM, NTLM, NTLMv2,and Kerberos protocols. Kerberos and some version of NTLM must be used. Disable the use of LMand NTLM (version 1.0) protocols, and disable LM hashes. After you disable LM hashes (according tothe recommendations in Chapter 2), force all users to change their passwords; you can use the queryfeature in Active Directory Users and Computers to make all user passwords expire at the same time.This additional step is needed because the current password’s hash stays in storage, even when LMhashing is disabled. After users change their passwords, the old hash remains; however, if a hackerrecovers the hash, the current password is not recovered. Of course, the user’s new password shouldnot be similar to the old password.

n



http://go.microsoft.com/fwlink/?LinkId=22208



Secure Credential Database The credential database that holds the logon accounts and passwords should be secure. The first

step in database security is ensuring physical security. To be successful, most Windows passwordcracking or resetting tools require local access to the Windows password database, and most require the ability to boot around the operating system protections that are normally in place. Simplypreventing unauthorized local access to the Windows password databases will thwart most passwordcracking or resetting attacks. Also, you should disable the ability to boot from any removable mediadrives, such as floppy disks, CD-ROMs, or USB drives. In fact, you should disable removable mediafrom even being considered as a boot-up option in the ROM-BIOS and then password-protect theROM-BIOS settings from alteration.

Consider setting up credential database servers to require boot-up passwords or password tokensto start. Some high-security web sites tie boot-ups to the successful validation of an externally locateddevice. For example, the entire hard drive may be protected by an external cryptographic system inwhich the hard drive is “encased” with a cryptographic cipher. Booting the hard drive requires one ormore smart cards, with appropriate digital keys and manually input passwords. Verisign(http://www.verisign.com) protects their most valuable key management servers this way. Two smartcards, one carried by an IT employee and one carried by management, are necessary for the serverto boot.

System Key Protection Security credential databases, even if locally compromised, should prevent non-trivial password compromises. To start with, passwords shouldn’t be stored in plain-text in an easily accessible database. Windows meets this standard by storing all passwords as hashes and then storing even thepassword hashes in encrypted form.

Since Windows NT, Microsoft’s Syskey utility safeguards SAM databases (but not Active Directory)from physical attacks. The SAM database stores hashed copies of passwords. This database isencrypted with a locally stored system key. To keep the SAM database secure, Windows requires thatthe password hashes be encrypted. Windows prevents the use of stored, unencrypted passwordhashes.

You can use the Syskey utility to provide extra security to the SAM database; move the SAMdatabase encryption key off the Windows-based computer or require a start-up password thatdecrypts the system key so that Windows can access the SAM database. By default, Windows Server2003 enables Syskey, which requires a locally stored key to access the SAM database. You can configure Syskey to require the additional protection of one of the remotely stored key settings. Todo so, follow these steps:

1. At a command prompt, type Syskey, and then press Enter.2. In the Securing the Windows Account Database dialog box (see Figure 3-2), note that the

Encryption Enabled option is already selected and is the only option available. When thisoption is selected, Windows always encrypts the SAM database.



http://www.verisign.com

Figure 3-2 Configuring Syskey

3. Click Update.4. If you want to require a password to start Windows, click Password Startup. Use a complex

password that contains a combination of uppercase and lowercase letters, numbers, and symbols. The startup password must be at least 12 characters long and can be up to 128 characters long.

NoteIf you must remotely restart a computer that requires a password (if you use the PasswordStartup option), a person must be at the local console during the restart. Use this option only ifa trusted security administrator is available to type the startup password.

5. If you do not want to require a password, click System Generated Password. Then select oneof the following options: • Store Startup Key on Floppy Disk — this option requires that someone insert the floppy

disk containing the encryption key to start the operating system. This choice provides thehighest level of protection for the SAM database.

• Store Startup Key Locally — the encryption key on the hard disk of the local computer.This is the default option. Click OK two times to complete the procedure.

If you use the Store Startup Key on Floppy Disk option, always create a back-up floppy disk.You can restart the system remotely if someone is available to insert the floppy disk into the computer when it restarts.

n



NoteThe Microsoft Windows NT 4.0 SAM database was not encrypted by default. You can encryptthe Windows NT 4.0 SAM database using the Syskey utility.

Syskey is a wonderful utility, but its protection applies only before the Windows operating systemis booted. After the Windows operating system boots Syskey provides no additional protection. Further, several Windows password cracking utilities (discussed below) can disable Syskey and itsboot-up protections.

Strong Password Finally, a secure password system requires a strong password. The exact makeup of a strong password depends on the value of your data, the strength of the password management system protecting the password, and the types of hacker tools available to attack your system. Here are somecharacteristics of a strong password:

• Length• Randomness• Secure storage• Dates of use• Offsetting protections

Password Length A password must be long enough to discourage password cracking attacks. Types of password-cracking attacks include

• Brute-force guessing• Dictionary or word list attacks• Birthday attack• Pre-computed hash attacks

Brute force attacks begin attacking the password by guessing every possible password sequence,starting with the lowest available character, and cycling through all possible symbol sequences until a correct password is found. This strategy is the worst possible way to guess a password. NTLM and Kerberos passwords can be made up of 65,536 different character symbols. Starting with one-character passwords and trying all 65,536 characters, and then trying all two-character password combinations, and so on. Very quickly, the password cracker is weighed down by the sheer volumeof potential password sequences.

To put it in perspective, even with all the foreseeable computing power and hard drive spacethat will be available in the next hundred years, it would take decades to find a random match forone single password. The data being protected by that password has a greater chance of losing itsvalue than a cracker has of finding the password – assuming it didn’t change in that time.

It makes more sense to guess only those passwords that might be used. Here’s where the process can get interesting. Dr. Jesper M. Johansson’s paper, The Great Debates: Pass Phrases vs. Passwords: Part 1 of 3 (http://www.microsoft.com/technet/security/secnews/articles/itproviewpoint091004.mspx), provides some important data. First, although it is possible to use 65,536 different

n



http://www.microsoft.com/technet/security/secnews/articles/itproviewpoint091004.mspx

http://www.microsoft.com/technet/security/secnews/articles/itproviewpoint091004.mspx

Unicode characters in a Windows password, most passwords use just 32 different characters – the 26lowercase alphabetic characters, a handful of uppercase alphabetic characters, and the non-alphabeticexclamation point symbol (!). A cracker could limit the attack to those 32 characters, plus maybe thepound (“#”) and at sign (“@”) to be inclusive, reducing the work from churning through 65,363 symbols to checking only 34 symbols. Most Windows passwords have eight or fewer characters (infact, most administrators require a minimum length of only five characters), so instead of guessing atall possible password lengths, from zero to 127 characters, hackers can further reduce the scope oftheir tries. Again, guessing 35 different characters in a password of 5 to 8 characters is significantlyeasier to compute than 65,536 characters at every combination between 0 and 127.

A birthday attack takes password cracking one step further. Statistical models show that althougheach person has a 1 in 365 chance of being born on a particular day of the year, in a random group of 23 people, there is a 50% chance that two people share the same birthday. This statistical phenomenon means that a randomly generated guess at the password will probably arrive at the correct password significantly faster than a sequential search from either the beginning or the end ofthe available possibilities.

Instead of guessing the plain-text password, the pre-computed password hash attack starts in theother direction. First, an attacker creates a database of all the possible passwords and their hashes.These databases are also known as rainbow tables. When a password hash is found, it is directlymatched to a pre-computed hash and its plain-text counterpart in the database. The weakness of thisattack is the amount of storage required — all the possible pre-computed hashes can easily take upgigabytes. Small rainbow tables are at least a few hundred megabytes and larger ones are over 24 GB(http://www.antsight.com/zsl/rainbowcrack).

In fact, large rainbow tables don’t really contain all the possible password hashes for a Windowssystem. Even if you limit password hashes to weak 8-character (or less) LM hashes, pre-computing allthe possible combinations requires more than 62 GBs of storage space. If users take advantage of thetotal number of available password characters available in Windows, even relatively short passwords(8 characters or less) require rainbow tables bigger than all the available drive storage in existencetoday. Unfortunately, because most users use passwords with easy-to-guess character sequences,rainbow tables can be significantly smaller and still be very accurate.

It’s still easier to get a password by asking the user for it or even knowing that the user has aweak password. Social engineering attacks are far more adept at gaining access to passwords than arethe (over-romanticized) efforts of a remote password cracker compromising a domain database. Oneof the best social engineering scams occurred at a national university. A student posted his dormphone number on a flyer as the IT Help Desk number. Within days he had “helped” dozens ofunsuspecting users and helped himself to their logon credentials. As stated in Chapter 1, in severalstudies over the years, most users will share their passwords with strangers on the street for prizeslike pens and chocolate candy. Why hack hard when you can hack easy?

Bottom line: how many characters are necessary for a good password? Passwords should be atleast six characters, to even begin to approach a low minimum number. Each character adds signifi-cantly more computations to a password cracking attack. Some security guides say that eight is themagic length; others say nine. Windows security experts often recommend passwords of 15 or morecharacters simply to disable LM hashing. If you don’t have LM hashing disabled globally in your environment, this recommendation good. One Microsoft security analyst recommends a minimumlength of 42 characters (http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx).



http://www.antsight.com/zsl/rainbowcrack

http://blogs.msdn.com/robert_hensing/archive/2004/07/28/199610.aspx

As you can see, there are no hard and fast rules. Anyone who tells you a rule without askingyou about the rest of your password management system isn’t getting enough detail. It is known thatthat every increase in password length, if the password symbol is random enough (more on thisbelow), will result in a stronger password. Of course, if passwords become too long and your usersrevolt, then the negatives offset any security gains.

Randomness For a password to be strong, and to defeat password cracking tools, it must be random. Using aspouse’s name as a password is not random. As discussed above, most people don’t vary the rangeof characters they use. Although 65,536 different Unicode symbols can be used in a Windows password, most users choose from among a set of about 35. The actual level of randomness in theirpasswords is significantly less than the theoretical possibility.

Lately, there has been a big push for the use of passphrases instead of passwords. The concept isthat multiple-word passphrases are longer than average passwords, thereby making the job that muchharder for password crackers. However, this holds true only if the passphrase is made up of randomsymbols; however, most passphrases are made up of English words. Johansson’s paper demonstratesthat random 9-character passwords are roughly as secure as 5- to 6-word passphrases – although apassword may use random characters, a passphrase is more likely to use very common Englishwords. The entropy (a measure of randomness) of the words in a passphrase is less than the entropyof a randomly chosen password. The conclusion of his paper, and many others, is that if passphrasesbecome commonplace, without any additional randomness, they will be no better than significantlyshorter passwords. Instead of using individual characters or symbols, password-cracking tools willsimply use whole English words instead.

Asking a user to create a random password on their own, especially if the requirements are notenforced, is futile. Most passwords will be 6 or fewer characters, chosen from that set of 32 charactersmost likely to be used. Microsoft Windows 2003 requires a slightly more complex password, usingthe following rules:

• The password must be at least six characters • The password cannot contain more than three characters from the user’s account name• The password can contain English uppercase characters (A through Z)• The password can contain English lowercase characters (a through z)• The password can contain numerals (0 through 9)• The password can contain non-alphabetic characters (such as !, $, #, %)

Further, a Windows password must contain at least three of the four character groups listed inthe last four bullet points. You can turn off Windows password complexity using a group policyobject setting. Changing the specific complexity requirements requires custom programming.

Strong passwords include both length and randomness. Some users create passphrases thatinclude English words with intentional misspellings or symbol replacement. For example, thepassphrase, “I’ll always love our time in paris” can be typed in as “I’l1 Always Love OuR T1M3 nP@r!5”. As complicated as the example seems, and as difficult as it is to type, its random element isstill not too strong for future passphrase crackers. Still, it (or something like it) will trump a short six- to eight-character password every time.



Password Storage Having many complex passwords can be a memory problem, especially when the passwords aren’tused often (for example, for. service accounts or Directory Restore mode). Writing them down is anobvious solution, but is it possible to write down passwords securely? A crude method is to store thewritten password in a secure location, such as a fireproof vault, preferably in two locations for redundancy.

A more high-tech solution is a password storage program. Password storage programs are smalldatabases that store passwords securely. By remembering only one complex password, you canalways retrieve all your important passwords. Many password storage database programs are available, including the popular Password Safe (http://passwordsafe.sourceforge.net).

Dates of Use Another way to help protect a password is to limit the time period when it is used. The more valuable the data and the higher the risk, the shorter the time period should be. Again, althoughthere is no hard and fast rule, most companies follow some general rules of thumb. Environments oraccounts at high risk should set maximum password age to 30 days or less. Companies that can tolerate more risk can extend maximum password age to 3 to 6 months. Pick a maximum passwordage that fits your environment.

You enable the minimum password age and password history settings in Windows. The Minimum Password Age setting imposes a minimum length of time a password must be used beforechanging the password. The Password History setting instructs Windows how many old passwords toremember as the user chooses a new password. Windows does not let a user re-use a password thatis in the user’s password history list. By enabling both minimum password age and password history,an administrator can ensure that users don’t change the password several times in a row simply to re-gain the original password they liked.

Remember, different accounts with varying levels of risk require different maximum passwordages. Unfortunately, Active Directory currently only allows one password policy per domain, but thisis scheduled to change.

Offsetting Protections The defense-in-depth philosophy applies to password policies. Windows contains several passwordpolicies that limit the exposure of passwords to cracking attempts. The single biggest step any administrator can take is to enable account lockouts. Enabling lockouts ensures that any account thatexperiences a certain number of invalid login attempts during a given time period (all customizable)is disabled. Like password policies, account lockouts (see Figure 3-3) can be set at the local ordomain level. Set to almost any threshold settings, account lockouts are an excellent way to deterpassword cracking.



http://passwordsafe.sourceforge.net

Figure 3-3 Account lockout settings

Without account lockouts, most password crackers operating over a network are limited to 2 or 3password guesses per second because of the way network logons against a single logon account areprocessed by Windows; a locally installed password guessing tool could try hundreds to thousands ofguess per second. Enabling account lockouts significantly slows any progress a password crackingtool could make against an active database.

A word of caution: although you can require that the administrator unlock any disabled accounts,doing so increases network support costs — some surveys say a single password reset or accountunlock costs $75 — or could lead to a denial of service attack. Hackers have been known to attacknetworks, intentionally guessing bad passwords to disable as many accounts as they can. Often thebest cost-benefit tradeoff is to re-enable disabled accounts automatically after a short time (forexample, 5 minutes). Even if you lock out the account only for a few minutes, you’ve defeated mostonline password hacking tools that try to brute-force the database.

Windows Kerberos goes one better and requires pre-authentication before a password guess canbe made. Pre-authentication is a challenge-response process in which the Kerberos password cannoteven be submitted for review at the KDC unless a pre-logon challenge is answered correctly. Thechallenge can be answered correctly only by a Winlogon.exe service that already has the correctpassword hash. Therefore, to guess the password you have to know the password. Without a successful pre-authentication challenge, a brute force tool would not even be allowed to take a guess.

Another offsetting mechanism is to limit the number of times and the computers at which alogon account can be used. For example, most custom service accounts are needed on only onecomputer at a time. Because these accounts also usually carry high privileges, limiting the number of their potential logons, and limiting them to only the machine they are needed on, significantlyminimizes risk.

Consider renaming highly-privileged default accounts. Give your administrator account a differentname. Make it look like a normal end-user account. Change the account description, even. Renamethe administrators group. Renaming these accounts and groups won’t change their permissions, but itwill frustrate password cracking tools that don’t know you’ve renamed them. Of course, hackers whocan do SID enumeration can still find the highly privileged accounts, but you can turn off anonymousSID and account enumeration, and most hackers don’t even try that anyway.

NoteSometimes, a renamed administrator account is still referred to as its original default name. Forexample, if you boot up into the Windows recovery console, it will ask for the administratorpassword even though the account is renamed.

n



If the original account name is missing or disabled when a hacker tries to use it to log on, amessage indicating the account’s true status will be returned to the cracker. Therefore, to frustratepassword crackers even more, create new accounts with the old accounts’ original names but withhighly restricted privileges, Full Control-Deny on all NTFS permissions, and complex passwords.Crackers will burn all their CPU cycles trying to break a tough password, and even if they do, they’vestill got less access than is given to the guest account.

As is the case when implementing any security recommendation, experiment and test beforeimplementing changes to your password policies. Changing password sizes and complexity can haveoperational and end-user emotional effects that are outside the control of the network administrator.Operationally, dozens of documented problems can occur as you increase password length and complexity. Some of the problems are

• Clustering passwords must be greater than 14 characters (15 or larger) if LM hashes are disabled; otherwise, newly joining cluster nodes will try to join using an LM hash first (seeMicrosoft Knowledgebase article# 828861)

• Disabling LM authentication causes problems with legacy operating systems• Third-party SMB shares often require simple or plain-text passwords

Password Crackers Windows operating systems are highly resistant to password cracking attacks if you take simple

preventative steps. Most attack tools rely on local access to the computer or the presence of the LMhashes. Hackers with local access to a PC can do anything. Forget about stealing or resetting pass-words; they can take the whole PC. Most Windows password crackers are successful only only onolder versions of the operating system; just a handful can crack Windows Server 2003 passworddatabases. Even then, most of those tools crack only the local SAM database and won’t even attemptto crack domain logon credentials.

In this section, we review some common password cracking tools – both free and commercial,both password recovery utilities and password re-setters. Here are some other general observations:

• Password crackers are more successful on weak, short passwords. • Most password crackers are really password re-setters, which allow passwords to be changed,

not recovered. They might cause a successful intrusion, but you would probably detect it. • Password dictionary attacks require a word list database. Although most databases are suffi-

cient to guess most of today’s passwords, adding just a little complexity and length to yourpasswords will defeat most of them.

• To be successful, online dictionary attacks require that account lockouts be disabled.• To be successful, offline dictionary attacks require LM hashes.• Most password cracking tools assume passwords have 14 or fewer characters.• Most password cracking tools do not work against a Windows computer secured with the best

practices recommended at the end of this chapter.

Now, let’s review a few popular password cracking tools.

LOphtcrack (LC5) You can find this password recovery tool at http://www.atstake.com/products/lc. LOphtcrack, nowcalled LC5, is a commercial tool recently purchased by Symantec. LOphtcrack is the best Windows



http://www.atstake.com/products/lc

password-cracking tool available. It can work locally or remotely. It first recovers password hashesand then attempts dictionary attacks against the recovered hashes. It can capture passwords over thenetwork in “sniffing” mode, but it cannot break NTLMv2 or Kerberos authentication. It can recoverActive Directory accounts. It requires an administrative level account to work. If you need to do Windows password cracking or auditing for a living, this is the tool.

Petter Nordahl-Hagen’s Offline NT Password & Registry Editor Find this password re-setter at http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html. It is a free,self-contained Linux boot diskette image with fairly easy-to-understand, scripted menu commands. Itwill work on all versions of Windows SAM databases, but it cannot access Active Directory. It canreset and blank passwords but not recover them, and it cannot reset domain passwords. Nordahlmenus are similar to the one shown in Figure 3-4.

Figure 3-4 Example of the Nordahl password reset screen

=========================================================

. Step THREE: Password or registry edit

=========================================================

chntpw version 0.99.2 040105, (c) Petter N Hagen

[.. some file info here ..]

* SAM policy limits:

Failed logins before lockout is: 0

Minimum password length : 0

Password history count : 0

<>========<> chntpw Main Interactive Menu <>========<>

Loaded hives: <sam> <system> <security>

1 - Edit user data and passwords

2 - Syskey status & change

3 - RecoveryConsole settings

- - -

9 - Registry editor, now with full write support!

q - Quit (you will be asked if there is something to save)

What to do? [1] -> 1

===== chntpw Edit User Info & Passwords ====

RID: 01f4, Username: <Administrator>

RID: 01f5, Username: <Guest>, *disabled or locked*

Select: ! - quit, . - list users, 0x<RID> - User with RID (hex)

or simply enter the username to change: [Administrator]



http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html

John the Ripper This password recovery tool is available at http://www.openwall.com/john. It’s a free passwordcracker ported from Unix that requires local access and weak password hashes; it works only onSAM databases. Basically, it compares an input file against an inputted word list database, using therelated cryptographic routines. To use it, you must first extract the password hashes from the localSAM using another tool, such as Todd Sabin’s Pwdump2 or Phil Staubs’ Pwdump3(http://www.polivec.com/pw3dump/default.htm), both of which require administrative credentials.However, after you have extracted the LM password hashes, you can use John the Ripper to convertto their resulting passwords.

NTAccess A password re-setter, NTAccess is available at http://www.mirider.com/ntaccess.html. This commercialproduct, made by Dieter Spaar, resets reset the local administrator password. It’s notable because itcan locate a renamed administrator account and enable a disabled administrator account. It requireslocal access and cannot defeat offline Syskey passwords. It does not work with Windows Server 2003domain accounts, but it claims to be successful with NT and 2000 domain controllers. It requires Windows boot floppies.

Winternal’s Administrator’s Pak This password re-setter, available at http://www.winternals.com/products/repairandrecovery/index.asp?pid=ap, is a commercial product that can do a whole lot more than reset password resets. It’s abeautiful tool with nice GUIs. It requires local access to the system, works only on local administratorpasswords, and requires access to the SAM registry hive.

EBCD-Emergency Boot CD You can find this password re-setter at http://ebcd.pcministry.com. It is open source and containedon a Rescue Linux distribution. It requires local access and only resets local SAM account databasepasswords.

Windows XP/2000/NT Key This commercial password re-setter is available at http://www.lostpassword.com/windows-xp-2000-nt.htm. It needs Windows install boot diskettes to work. It can only reset passwords, but it claims to reset domain administrator passwords, too. It works with Windows Server 2003.

Austrumi An open-source password re-setter, Austrumi is available at http://sourceforge.net/projects/austrumi.It’s an open source bootable Linux image. It resets only local SAM account databases.

O&O BlueCon XXL You can find this commercial password re-setter at http://www.oo-software.com/en/products/oobluecon/index.html. It can reset local SAM passwords but requires local access. It claims to workwith XP, 2000, and NT, but it does not mention Windows Server 2003.



http://www.openwall.com/john

http://www.polivec.com/pw3dump/default.htm

http://www.mirider.com/ntaccess.html

http://ebcd.pcministry.com

http://www.winternals.com/products/repairandrecovery/index.asp?pid=ap

http://www.winternals.com/products/repairandrecovery/index.asp?pid=ap

http://sourceforge.net/projects/austrumi

http://www.lostpassword.com/windows-xp-2000-nt.htm

http://www.lostpassword.com/windows-xp-2000-nt.htm

http://www.oo-software.com/en/products/oobluecon/index.html

http://www.oo-software.com/en/products/oobluecon/index.html

Using password cracking tools isn’t always a bad thing. In fact, they make great passwordauditors. Password re-setters are helpful if you forget or lose the local administrator’s password. Only

two of the tools, L0phtcrack and Windows XP/2000/NT Key, claim to work with domain accounts.Most of the tools are simple password re-setters that operate on local SAM accounts. Only L0phtcrackand Jack the Ripper claim to do password recovery. However, even these recovery tools can bestopped by passwords that are longer and more complex than is normally expected.

Password Best Practices Microsoft’s latest operating systems are resistant to password cracking attacks. By requiring NTLMv2authentication, disabling LM hashing, disabling booting from removable media, and increasing pass-word length and complexity, you can significantly diminish the risk of password hacking attacks.Here is a recap of recommended best password practices, plus a few new ones.

• Create and enable a strong password policy• Disable booting from removable drives• Use Syskey• Enable account lockouts• Increase password length and complexity, and shorten the time they can be used • Enforce a minimum password age• Enable password history tracking• Disable LM hashes• Force NTLMv2 authentication• Use EFS• Create different passwords for different accounts and uses• Rename sensitive accounts• Enable auditing on the following audit categories: Audit Account Logon Events, Audit Account

Management, Audit Logon Events, and Audit Policy Change• Enabling Audit Object Access on SAM file located in %WINDIR%\SYSTEM32\CONFIG folder• Consider requiring smartcard logons for sensitive accounts

As an administrator, if you do nothing else after reading this chapter, start to lead by example.Use longer and more complex passwords. Make sure your personal passwords are not simple passwords. Make sure administrative and service account passwords are longer and more complexthan the average end-user password. Begin to live and practice what you have been learning in thecomputer security field. You can use your experiences and lessons as a way to teach others.

After a successful authentication, a security principal has access to the resources that are allowed them by their security permissions and rights. Chapter 4 will cover NTFS permissions. If it’sappropriately configured, Windows can significantly reduce the risk of malicious exploitation.



70


Chapter 4:

Securing File System and Registry PermissionsAfter the authentication process is complete, a user’s access to Windows resources is determinedlargely by resource permissions. Windows has some of the strongest and most flexible ways to con-trol access available in a personal computer operating system. If appropriately configured, Windowssecurity can prevent unauthorized access, defeat malware, and maintain a high level of availability.Chapter Four begins by examining permissions and how they are assigned. It ends by taking thatknowledge and applying it to better secure Windows resources.

Gathering Permissions To access a resource, a security principal must have the appropriate permission. Determining aneffective set of permissions for a given security principal is more involved than most administratorsrealize.

After enumerating the basic components of a resource permission, this section examines thesecurity roles of security identifiers and access control lists as well as NTFS and Share permissions.

Components of a Resource PermissionContrary to popular belief, authorized access to Windows resources involves more than NTFS andShare permissions. The following Windows features affect access control:

• Operating system (OS) version• Subsystems • File system: FAT or NTFS• Local or domain logon• Account permissions• Group membership• Inheritance• Windows trusts (cross-domain access)• Encryption (EFS)• Software restriction policies• Local computer and group policy• User rights

This list is not exhaustive. Depending on the system configuration and applications installed,many more mechanisms can affect permissions. For example, objects accessed through Internet Information Service (IIS) are protected with additional internal IIS restrictions.

OS Version The OS version significantly affects the resource permissions available. For example, the Windows 9xfamily does not support NTFS permissions. Windows NT 4.0 does not support inheritance the sameway as non-legacy OSs do. Windows XP and Server 2003 have new encryption algorithms that arenot available to earlier OS versions. Generally, the newer the OS, the stronger and more reliable theaccess controls. For this reason, Microsoft always recommends that its latest OSs be used by customers with the NTFS file system installed.

Installed Subsystems Early versions of Windows supported many non-native subsystems, like Portable Operating SystemInterface for UNIX (POSIX) and High Performance File System (HPFS). If installed, each subsystemhas its own permissions and control mechanisms. Windows XP and Server 2003 no longer supportthese subsystems.

File System: FAT and NTFS Perhaps the largest impact on permissions is the file system that is installed. Every OS comes with afile system that determines how objects are stored, how they are located, and how file attributes andpermissions are assigned.

The FAT file system has been supported by Microsoft since the early days of DOS, although theearly versions had no security features. Starting with the Windows 3.x family, the FAT file systemcould be used to assign Share-level permissions. These permissions are used in a network environ-ment to offer the use of resources (usually files, folders, or printers) to remote network users.

All Windows versions of FAT support Share permissions, with varying degrees of control andmore than a few limitations. First, Share permissions cannot be set at the file level; instead, Share permissions are set on folders. To share one file, you must place it in a folder (or the root directoryof a drive) and share the parent object.

Share permissions are not nearly as granular as permissions provided by NTFS, and they vary byoperating system. For example, two Share access control permissions are offered by Windows XPHome Edition (assuming that network access is enabled): Everyone Read, and Everyone Read andWrite (http://support.microsoft.com/kb/q304040 ).This system is called Simple File Sharing. The classicShare permissions offered in the other OSs in the Windows NT family are a bit more granular andmay be defined by security principal. We discuss these later in the chapter.

NTFS (originally short for NT File System), introduced in Windows NT, remains the core accesscontrol mechanism in today’s Windows OSs. NTFS allows a level of control not matched by most personal computer OSs. When the NTFS file system is used, NTFS permissions are always in effect,whether the security principal accesses a resource locally or over a network share. NTFS is alsorequired for the following Windows features:

• Disk Compression• Disk Quota Management• Encrypting File System• Active Directory• Domain Controllers• Auditing• Mounting volumes to empty folders

Chapter 4 Securing File System and Registry Permissions 71


http://support.microsoft.com/kb/q304040



• File Level Security• Remote Installation Services

NTFS is also required or recommended for many other applications. For example, although youcan install IIS on a FAT volume, it is not recommended. The additional security features and auditingthat NTFS provide make its use almost mandatory.

Notice that Client OSs that access shares over a network do not necessarily have to “understand”the network server’s underlying file system. For example, Windows 9x clients can readily access NTFSshares, and most non-Windows clients can access FAT and NTFS shares through IIS.

Local vs. Domain Logon Logging on locally or logging on using a domain account affects the resources you can access andthe permissions you receive. By default, local logons can access only local resources unless additionalaccounts and rights are created on network resources. When a security principal account logs on to adomain account, it receives access to network resources that use domain authentication. The domainaccount is added to other group memberships simply because it joined a domain instead ofremaining local.

However, be aware that even if you logon locally, you can still be affected by domain accountsand settings. For example, if a computer is connected to a domain and a user logs on locally, thecomputer is probably still logged on to the domain (unless the network connection to the domaincontroller is interrupted). Therefore, rights, settings, and group policy objects applied at the domainlevel may still affect users who are logged on locally.

Account Permissions In Windows, a security principal’s account can be given direct permissions that are specifically forthat account. Account permissions are most often given to user accounts but can also be given tocomputer, service, and other types of accounts (as discussed in Chapter 3). If a Windows resource is“owned” by an account, that account, along with the administrator’s group, controls the object’s per-missions and the access to it.

Although a security principal account can be given permissions, it is often easier to manage mul-tiple permissions in the long run by using groups.

Windows has several built-in accounts (see Figure 4-1) that vary depending on OS and whetherthe computer is in workgroup or domain mode (see Table 4-1).

Figure 4-1 Built-in Windows users and groups in Active Directory Users and Computers

Table 4-1 Built-in accounts in Windows Server 2003 domain mode

Account Name Description

Administrator Domain administrator. This account usually has Full Control permissions to all domainresources; it can be renamed, but not deleted or disabled. By default, it is a member ofAdministrators, Domain Admins, Domain Users, and Group Policy Creator Owners groups.In the first domain in a new forest (that is, the forest root domain), the Administrator is also amember of the Enterprise Admins and Schema Admins groups, which means that theAdministrator of a forest root domain is significantly more powerful than other domainadministrators in the same forest. Note: the Local administrator account can be disabled in Windows XP and non-domaincontroller Windows Server 2003 servers.

Guest Default account for guest logins. The account can be renamed, but not deleted. It is amember of Domain Guests and Guest groups. The guest account does not use a password.This account is disabled by default; but must be enabled for some legacy applications andfunctions. If enabled, this account opens an avenue for a privilege escalation attack. InWindows 2000, the guest account was a member of the Domain Users group, which gave itadditional permissions not acquired in Windows Server 2003.

HelpAssistant This account is created when Remote Assistance is enabled and a remote assistance sessionis requested; it is deleted if no remote assistance requests are pending. It has limited access tothe desktop environment.



Table 4-1 Built-in accounts in Windows Server 2003 domain mode (continued)

Account Name Description

IUSR_<computername> This account is not a default account but is added if IIS is added. It is the security principalaccount for all users connecting anonymously to an IIS web site. By default, it is a member ofthe Domain Users and Guests groups, which can indirectly give more permission thannecessary for the web site alone. In IIS, the default anonymous account (IUSR_) can bechanged to another security principal account.

IWAM_<computername> This account is not a default account but is added if IIS is added. This account is used forweb sites running "out-of-process," which is used more often in previous versions of IIS. It is amember of the Domain Users and IIS WPG groups.

Krbtgt This Kerberos-related account is disabled by default. Kerberos authentication requires ticketsthat are enciphered with a symmetric key derived from the password of the server or serviceto which access is requested. To request such a session ticket, a special ticket called theTicket Granting Ticket (TGT) must be presented to the Kerberos service itself. The TGT isenciphered with a key that is derived from the password of the KRBTGT account, which isknown only by the Kerberos service.

Local Service This security principal is new in Windows Server 2003. It is a lesser-privilege account that isintended for use with service accounts. This account has same permissions as the Usersgroup and accesses network services with anonymous credentials.

Network Service This security principal is new in Windows Server 2003. It is a lesser-privilege accountintended for use with service accounts. This account has the same permissions as the Usersgroup. It accesses network services with same credentials as those given to its local machineaccount.

Support_<number> This Microsoft vendor support account is disabled by default. It is part of theHelpServicesGroup group and is intended as a default account for remote support throughthe Help and Support center.

System (also known This is the highest-privileged account on the local computer – it is even more powerful thanas Local System) the administrator. Most of the OS and kernel-mode applications run with the privileges of

this security principal. Any Windows service running within the System context probablyneeds to stay that way, but each non-Windows service should be strictly evaluated beforeassigning it the Local System account. Hackers who gain control over or buffer overflows aservice running in the System context becomes all-powerful on the computer.

As is the case with all user accounts, built-in accounts can have their privileges, permissions, and(usually) group memberships modified.

Group Membership Security permissions are often assigned to group accounts, which contain other security principals. A security principal’s effective permissions are the combination of the permissions given to their individual accounts and that of their group memberships.

Group Characteristics Starting with Windows 2000, groups come in two types: security-related groups and distributiongroups. Security groups can have access permissions associated with them, whereas distribution listsare designed to collect related users for purposes other than security. A distribution group (or



distribution list) cannot have a security permission associated with it, but you can convert a distribu-tion list to a security group, if the domain is native to Windows 2000 and above the functional level.Security groups can also be converted to distribution groups, but they lose security permissions.

Groups also have an associated scope – Local, Domain Local, Global, or Universal – that determines what member types they can contain and what they can be a member of. Local groupscan have local permissions attached and can contain local security principal members. Domain localgroups are on domain controllers and contain permissions to local resources. Global groups can beassigned permissions to resources in the local domain and contain members and other Global groupsfrom any domain. Universal groups can have permissions to resources and users throughout the sameforest.

In mixed-mode domains, it is possible to nest groups – that is, make groups members of othergroups. Local Domain groups can have Global groups from any domain. In Windows 2000 nativeand above domain functional level, most types of group nesting are allowed, except that Universalgroups cannot nest inside Domain Local groups.

Built-in Groups Security principals are often members of groups that they aren’t explicitly aware of, such as the Usersor Interactive groups. Windows contains many default built-in security groups whose permissions canbe modified and whose members can be changed (see Tables 4-2 and 4-3).

Table 4-2 Windows Server 2003 built-in groups

Group Name Type Description

Account Operators Domain Local This relatively powerful group mimics a lower-privilege administrator. Ithas no default members. Members can view and manage user, group,and computer accounts (except objects in the Domain Controllerscontainer). Members can view but not modify high-privilege accountsand cannot change group membership of the highly-privileged built-ingroups. Members can log on locally to domain controllers, which normalusers cannot do.

Administrators Domain Local Members of this group have Full Control of local servers and domaincontrollers in the domain, as well as any related security principalaccounts. The Administrator is a default member, and the DomainAdmins group is added when the server joins a domain.

Backup Operators Domain Local Members can backup and restore files regardless of other securitypermissions. They can also log on locally to domain controllers. Thisgroup has no default members, although Administrators also have thesame restore and backup rights without belonging to this group. Tapebackup service accounts should belong to this group instead ofbelonging to the Administrators group, if possible.

Cert Publishers Domain Local Members of this group can publish user and computer digital certificatesto Active Directory. Computers with Microsoft Certificate Servicesinstalled are automatically added to this account in their own domain.However, if Certificate Services is to publish certificates to areas outsideits home domain, members may need to be added to Cert Publishersgroups in other domains or forests This group has no default membersuntil Certificate Services is installed.



Table 4-2 Windows Server 2003 built-in groups (continued)


DHCP Administrators Domain Local Installed with Microsoft DHCP service, this group contains no defaultmembers. Members can configure DHCP using the GUI or the Netshcommand, but cannot perform other administrative tasks on the server.

DHCP Users Domain Local Installed with Microsoft DHCP service, this groups gives its membersread-only access to the DHCP service. It has no default members.

DNS Admins Domain Local This group is, by default, available only in domains or forests usingMicrosoft DNS. Members of this group have full control of all zones andzone records in the domains in which it contains members. It has nodefault members.

DnsUpdateProxy Global Members are allowed to perform DNS dynamic updates on behalf ofother clients. This group is usually used only if Microsoft DHCP serversare installed in a domain. By default, down-level DHCP-clients (forexample, Windows 98) have their DNS records registered by DHCP,which then becomes the owner. If the DHCP server goes down, theclient may have trouble updating its own DNS host records. By placingthe DHCP computer accounts in this group, the client’s host records arenot secured and can be updated by other computers. By default, it hasno members.

Domain Admins Global Members are domain administrators, with Full Control to domainresources. The administrator is a default member of this group. Thisgroup is a member of the Administrators group.

Domain Computers Global This group contains all the computer accounts of the computers joined tothe domain. It lets the computer create a secure channel between itselfand another computer for privileged communications, but the channelitself doesn’t encrypt communications.

Domain Controllers Global This group contains the computer accounts of the domain controllersjoined to the domain.

Domain Users Global This group contains all user accounts created in the domain. Permissionsgiven to this group are extended to all users in the same domain. Mostnew and built-in user accounts are part of this group, includingAdministrator, Krbtgt, Support_#, and the IIS default user accounts. InWindows Server 2003, Everyone and Anonymous are not part of thisgroup.

Enterprise Admins Universal Members of this group have Full Control permissions to all resources inthe forest. By default, this group is a member of the Administrators groupof all domains in the forest.

Group Policy Global Members of this group can modify group policy objects. The only defaultCreator Owners member is the Administrator account.

Guests Domain Local Members of this group have a temporary profile created during logonthat is deleted during logoff. Default members are Guest, DomainGuests, and the IIS Anonymous user account. This group has the samepermissions and access as the User account.





HelpServicesGroup Domain Local This group allows administrators to set rights common to all supportapplications. The Support_# user account and any Remote Assistanceuser are added to this group.

IIS_WPG Domain Local This new group in IIS 6.0 is used for worker processes. Members of thisgroup usually serve as identities for specific namespaces or applicationpools. The application pool identities should belong to this group.

Incoming Forest Domain Local Members of this group can create one-way forest trusts to the forest rootTrust Builders domain. It has no default members.

Network Configuration Domain Local Members of this group can make changes to the network configuration Operators settings (most often TCP/IP) and renew and release DHCP lease settings.

It has no default members.

Performance Domain Local Members of this group can manage and create performance counters,Log Users alerts, and logs without being members of the Administrators group. It

has no default members.

Performance Domain Local Members of this group can view performance counters, alerts, and logs Monitor Users without being members of the Administrators group; it has no default

members.

Power Users Domain Local Members of this group can create security principal accounts, and theycan modify and delete the accounts they have created. They can createlocal groups and add or remove users from them. They can also add orremove users from the Power Users, Users, and Guests groups. Memberscan create shared resources and administer them. They cannot takeownership of files, back up or restore directories, load or unload devicedrivers, or manage security and auditing logs.

Pre-Windows 2000 Domain Local By default, either the Authenticated Users or the Everyone group is a Compatible Access member, which is determined during a domain controller promotion

(dcpromo.exe). If the Permissions compatible with pre-Windows 2000servers option is selected, the Everyone group is added; if not, theAuthenticated Users group is added. Essentially, adding the Everyonegroup lets Anonymous session connections (such as the null session) readdomain information. Members have read access to all users and groupsin the domain. This group is provided for backwards-compatibility forlegacy systems. Add users and computers to this group if they arerunning legacy systems.

Print Operators Domain Local Members of this group can create, manage, and share printers; they canalso log on locally to domain controllers and load and unload devicedrivers. It has no default members.

RAS and IAS Servers Domain Local Members of this group can access the remote access properties of useraccounts. The group has no default members. Pre-Windows 2000 RRASand IAS server computer accounts should be added.

Remote Desktop Users Domain Local Members of this group are granted the right to log on remotely. It has nodefault members, and administrators are not required to belong. It’sequivalent to the Terminal Server Users group on prior Windowsversions.





Replicator Domain Local This group supports the File Replication service for Active Directoryreplication. Usually, it should not be modified. The default member isthe domain user account used to log on to Replicator services on domaincontrollers.

Schema Admins Universal The members of this group are possibly the most powerful in the forest,even more powerful than Enterprise Administrators. The Administratoraccount of the forest root domain is a default member. Members of thisgroup can modify Active Directory schema.

Server Operators Domain Local This relatively powerful group mimics a lower-privilege administrator.Members of this group can log on locally; create, delete and manageresources; manage services; back up and restore files; change systemtime; and format the hard disk. It has no default members.

TelnetClients Domain Local This group allows non-administrative members to log on to Telnet Serverservices.

Terminal Server Domain Local This group contains computer accounts of the servers running Terminal License Servers Server License service.

Users Domain Local Any user account created in the domain becomes a member of thisgroup (plus Authenticated Users and the Interactive groups, whenappropriate). Members can perform common user tasks, such as runningpreviously installed applications and using local and network resources.

Windows Authorization Domain Local Members of this group have access to the computed Access Group tokenGroupsGlobalAndUniversal attribute on User objects (as does the

Pre-Windows 2000 Permissions Compatible Access group).

Note Many of the groups listed as Domain Local are also Local groups on non-domain controllers.

Built-in Windows groups vary in flexibility. You can change the permissions and memberships ofmany. Others, like Users or Domain Users, are more resistant to membership modifications, but youcan modify their permissions for a particular resource. The built-in groups listed in Table 4-3 do notallow membership changes. Simply by performing an actions, such as logging on locally, the securityprincipal’s account is added to the group “on the fly.” You cannot choose whether your user accountis included in the group, but you can change the permissions each group has to a particular resource.

n



Table 4-3 Selected built-in groups with membership based on activity

Anonymous Logon (also Security principals connecting anonymously (accessing resources over a networkknown as the Anonymous connection with a null user account name, domain, and password) are added as memberssession, and null session) to this group.

For anonymous users or connections to gain access, resources must specifically allow theAnonymous security identifier (SID). Anonymous users are important to the operation ofWindows, and if this function is completely disallowed, it causes disruptions in service.

In Windows Server 2003 and XP, the Everyone group does not contain this group as amember. In previous versions of Windows, anonymous users could access the sameresources as the Everyone group, which caused potential security issues.

Note: The Anonymous Logon security group is not related to the IIS anonymous useraccount.

Authenticated Users This group includes all currently logged on users (interactive or network) who haveauthenticated with a username and password. It does not include the anonymous or guestuser. This group is a member of the Users group. When assigning new permissions, youshould use the Authenticated Users group instead of the Everyone group, unless you want toallow for unauthenticated access. Authenticated users from trusted domains or forests are alsoplaced in this group.

Creator Owners When an object is created by a security principal, that principal’s context is assigned as theOwner and Creator Owner. Creator Owners usually have Full Control permissions over theircreated objects. Thus, although the Everyone group may be denied a particular permission,normal users may be given additional permissions through their membership in the CreatorOwner’s group for a particular object.

Everyone This group includes all authenticated users plus the members of the Guests group.

Interactive Members of this group include anyone logging on locally or using Terminal Server services.Many malicious attacks require the Interactive SID to be successful.

Network Members of this group include anyone accessing a computer over a network connection(except Terminal Server users).

Other Organization This group identifies security principals from other domains and forests. It is added whensecurity principals in a trusted forest are authenticated to resources in the local domain.

Service This group contains all logged on accounts with the Logon as Service user privilege.

Terminal Server Users This group contains any users who are currently logged on using Terminal Server. It is forrunning Windows programs needing pre-Windows 2000 compatibility permissions.

This Organization New to Windows Server 2003, this group identifies the security principal as belonging to thecurrent domain or forest. It is added when security principals that are located in any of thedomains in a trusting forest authenticate to a local Windows Server 2003 member server ordomain controller.

NoteOther built-in users and groups, such as SChannel Authentication and Debugger Users, are notincluded in the tables above because they aren’t commonly used or don’t exist in a defaultinstallation of Windows Server 2003.

n



Correctly Applying Group Permissions Although security permissions can be applied to security principal accounts directly, it is easier tomanage permissions using groups. Whenever possible, resource permissions should be given toDomain Local groups. In a multi-domain forest, security principal accounts should be placed intoGlobal groups in their respective domains. The Global groups can be placed into Universal groups ordirectly into the Domain Local groups. If you use Universal groups (available in Windows 2000 nativeand above domain functional levels), you can place them in the Domain Local Groups.

The concept of using multiple groups with varying scopes to appropriate manage resource permissions is known by the acronym of AGULP (see Figure 4-2): Accounts are put into globalgroups, which are put into universal groups or domain local groups, where resource permissions areassigned.

Figure 4-2 AGULP permissions model



Accounts

GlobalGroup

UniversalGroup

Domain LocalGroup

Permissionsassigned

Users

Group

or

Group

Group

Resource Permissions

Server Shared Printer

This model for managing security permissions is one of the best, although many administrators,when first exposed to it, balk at its apparent complexity. In fact, most networks have an unregulatedmash of security permissions assigned to various groups, and some directly assigned to the user. Theresult is that the administrator really doesn’t know what security is assigned to whom or where tofind it. Adhering to a strict regimen of conveying all manually-assigned permissions to Domain LocalGroups gives administrators one place to look for all permissions.

If you haven’t enforced the AGULP model in your network, imagine the benefits of knowing allthe permissions of every user, computer, group, and resource in your network by looking at onlyone set of groups. Of course, some permissions will always be given by Windows built-in groups andlocal groups, but with the AGULP model, controlling security permissions becomes a manageabletask.

In the end, a security principal’s effective permissions are, in large part, determined by theirgroup memberships, both those assigned directly and those indirectly acquired by membership in aWindows built-in group.

Inheritance Inheritance also plays a major role in determining a security principal’s permissions. Permissions canbe inherited from parent folders and containers. By default, permissions set in a higher-level folder,organizational unit, or container flow downward. However, a permission explicitly set at a lowerlevel usually overrides an implicit inherited permission. For example, if a security principal is giventhe Full Control-Deny permission at the root directory level but more permissive options are set at alower level, the lower-level permissions win.

The inheritance model holds true when comparing folder and file permissions. Normally, filesinside a folder inherit permissions from the parent folder. But if a file has a specific permission set onit directly, that permission overrides the parent permission. Further, the default Traverse permissiongiven to the Everyone group allows a security principal to access a resource at a lower level, even ifthe higher level permission forbids access. Although you can turn off Traverse permissions on filesand folders, doing so will cause undesired effects.

However, you can change inheritance on each folder – even on a user. To review inheritancesettings, select a file or folder and check the Permissions tab of the Advanced Security Settings box(Figure 4-3).



Figure 4-3 Reviewing inheritance settings

To override permission inheritance, you must clear the check box, Allow Inheritable Permissions FromThe Parent To Propagate To This Object (see Figure 4-4).



Figure 4-4 Clearing inheritance

When you clear this box, you are prompted to either Remove all permissions or to Copy existingpermissions to use as the new starting point (see Figure 4-5).

Figure 4-5 Determining new permissions after disabling inheritance



When determining effective permissions, you must always consider inheritance. When trying totightly secure a resource, you should consider turning off inheritance and removing all inherited permissions so that you can begin with a clean slate.

Windows Trusts In simple terms, establishing a Windows trust between two domains or forests means that the trustingdomain relies on the trusted domain’s authentication mechanism to verify its security principals. Witha few exceptions (such as permissions given to the Authenticated Users or Everyone group), securityprincipals from the trusted domain or forest are given no explicit permissions in the trusted domainor forest.

Some administrators mistakenly believe that establishing a Windows trust somehow sets up significant additional permissions between the two domains or forests. Although the two defaultgroups listed above do have a number of permissions, most trusting resource permissions must stillbe assigned to the trusted security principals before access is authorized.

Encrypting File System (EFS) Encrypting File System (EFS) is the default encryption mechanism for ensuring confidentiality for filesand folders in Windows. If EFS is enabled, it takes precedence over normal security permissions.When EFS protection is used on a resource, users who aren’t specifically authorized to access thatresource cannot access it. For example, if a file is EFS-protected, not even the administrator candecrypt it unless that administrator is an EFS recovery agent.

In Windows 2000, only the user who protects the resource with EFS and EFS recovery agents canaccess it. In Windows XP and Windows Server 2003, the user enabling EFS on a particular file orfolder can determine whether other EFS users can access the protected resource.

Even if a malicious hacker compromises the Windows operating system and bypasses normalNTFS permissions, EFS-protected files are still protected, unless the intruder happens to recover theprivate key from the user or EFS recovery agent. An intruder who bypasses NTFS protection may beable to access, delete, or copy an EFS-protected resource but will not be able to view, read, or printthe resource.

EFS provides real protection for files and folders and will maintain confidentiality as long as therecovery keys are protected against unauthorized use.

Software Restriction Policies Starting in Windows XP, Microsoft introduced Software Restriction Policies (SRP, also known asSAFER). These policies can add extra restrictions to prevent. SRP can prevent programs from runningusing a variety of rules (path, registry, digital certificate, and hash). Even if a user has the appropriateNTFS file permissions, an SRP can still prevent access to a particular file.

SRPs also have an advantage over some other access control methods because they can set policies for future resources. You can use NTFS permissions to control access to existing resources;you can use an SRP to prevent the creation of or control access to new resources. For example, if auser tries to install an Internet Explorer Browser Helper Object (BHO), an SRP can, by default, prevent unauthorized programs.



Local Computer Policy and Group Policy Objects Every computer with Windows 2000 and later OS versions has a Local Computer Policy that isapplied upon computer startup. It can contain a host of security settings (see Figure 4-6) that affectthe access to a resource. For example, the Local Computer Policy can determine whether the anonymous user is part of the Everyone group.

Figure 4-6 Example local computer policy

Computers in an Active Directory domain can take advantage of Group Policy Objects (GPOs).GPOs lets you set configuration and security settings at the domain level. GPOs can apply file, folder,and registry permissions; they take precedence in conflicts. Together, Local Computer and GroupPolicies are another very effective tool in the Microsoft arsenal for securing resource permissions.

User Rights User Rights (also known as User Privileges or User Rights Assignments) give security principals accesscontrols beyond normal user permissions. For example, the Logon Locally right lets a user log on to acomputer interactively. By default, non-administrative users can’t log on locally to a domain controller.



You can control more than 60 user rights using Local Computer or Group Policies and audit the privi-leges using the setting Audit Privilege Use.

Many other factors can affect resource permissions, depending computer and network configura-tions. For example, large environments often extend Active Directory schema to install new accesscontrol functionality. Any sized-environment can install third party applications to help configure andmanage security. Most Windows objects have assignable permissions, but not all objects can be givenpermission. Understanding this sentence is crucial to understanding Windows security.

Security Identifiers (SIDs) and Access Control Lists (ACLs) The Windows NT OS family tracks security principals using a unique 48-bit number called a securityidentifier (SID), instead of the friendly names we readily see displayed in most Windows interfaces.All SIDs begin with the letter S, which is followed by a series of numbers separated by dashes. Partof the SID is unique and part is common to similar objects in any domain or forest, called a relativeidentifier or RID. For example, a RID of 500 always identifies the local administrator. Even if theadministrator account is renamed, the account can be identified by enumerating its SID.

For example, a SID of a local administrator account may be

S-1-5-21-276391366-4959655609-1373442946-500

The RID portion is the 500, which identifies the account as the original local administrator. In thebuilt-in groups discussed in Table 4-3, you recall that a user account is placed in one of those groupsbased on the account’s current action. Behind the scenes, what happens is that the built-in group’sSID is added to the user’s own account SID, thereby creating a new effective permission set.

On computers running Windows, access control lists (ACLs) and SIDs control access to resources.Each resource has an ACL that contains the SIDs of all users and groups that have been granted ordenied access to the resource. The SIDs of any user account in Windows Server 2003 can be revealedwith the WHOAMI /USER /GROUPS command. It will reveal the user’s SID and any SIDs given to theuser by group memberships. For example, the Authenticated Users SID has a RID of 11. The Interac-tive group has a SID ending with a RID of 4.

All the SIDs given to a user from of the user’s account, and all the SIDs gathered from the user’sgroup memberships, are collected in a package called a token. When a domain user logs on, eitherinteractively or remote, the domain controller collects the user’s SIDs (from its own security databaseand from the domain controller with the global catalog role), creates the user’s token, and hands it tothe user. When a security principal needs access to a resource, it presents its token, which is thenused to find the associated permissions. Permissions are accumulated and evaluated, compared to theobject’s ACLs, and the security principal is given appropriate access.

Because a user’s SID token is generated only after a successful logon, if a user’s permissions aremodified or if their group membership changes (or the group’s permissions), the new changes maynot take effect until the user logs on again because the user’s token is generated during logon.

The ACL is a collection of access control entries (ACEs). An ACE is a permission that is attachedto an object. The ACL is part of the security permissions interface most users are familiar with (seeFigure 4-7). In Figure 4-7, the ACEs are the individual permissions, like Full Control or Modify. TheACL is the collection of all available permissions that can be assigned to the object and which permis-sions are assigned to each security principal. All the information displayed under the Security tab isthe object’s ACL.



Figure 4-7 Access control list for the boot.ini file

Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, oraudited for that trustee.

The security descriptor for a securable object can contain two types of ACLs: a discretionaryaccess control list (DACL) and a system access control list (SACL). A DACL identifies the trustees that are allowed or denied access to a securable object. A DACL for a particular object might readsomething like

Administrator S-1-5-21-276391366-4959655609-1373442946-500 Full Control

Everyone S-1-5-5-11 Deny Write

When a tries to access a securable object, the System Reference Monitor (SRM) checks the ACEsin the object’s DACL to determine whether to grant access to it. If the object does not have a DACL,the system grants full access to Everyone. If the object’s DACL has no ACEs, the system denies allattempts to access the object because the DACL does not allow any access rights. The system checksthe ACEs in sequence until it finds one or more ACEs that allow all the requested access rights, oruntil any of the requested access rights are denied. In the simple example above, the administratoruser would eventually end up with all permissions except Write.

A system access control list (SACL) lets administrators log attempts to access a secured object.Each ACE specifies the types of access attempts by a specified trustee that cause the system to



generate a record in the security event log. An ACE in a SACL can generate audit records when anaccess attempt fails, when it succeeds, or both. In future Windows releases, a SACL will also be ableto raise an alarm when an unauthorized user attempts to gain access to an object.

To summarize, when a domain user logs on, its group memberships are gathered by the domaincontroller to create an access token. When the user wants to access an object, the SRM compares theuser’s token SIDs against the DACLs for the object to determine the effective permissions – assuming,of course, that no other mechanisms, such as SRP or EFS, have already blocked access.

NTFS/Share Permissions When a system is formatted with NTFS, NTFS permissions can be assigned to users, files, folders, andregistry keys. NTFS permissions apply whether resources are accessed over the network or interac-tively. Share permissions apply only when resources are accessed over the network or when localresources are accessed using Network Neighborhood.

NTFS Permissions Most users are familiar with the NTFS file and folder top-level permissions and descriptions in Table 4-4.

Table 4-4 NTFS top-level permissions

Permission Description Applies

Full Control Can read, add, delete, execute, and modify files; change permissions and Files and foldersattributes; and take ownership

Modify Can read, add, delete, execute, and modify files; cannot delete subfolders and Files and folderstheir file content, change permissions, or take ownership.

Read & Execute Includes the capabilities of both List Folder Content and Read Files and folders

List Folder Can list (traverse) files in the folder or switch to a subfolder, view folder attributes FoldersContent and permissions, and execute files but cannot view file contents

Read Can view file contents andview folder attributes and permissions but cannot Files and folders traverse folders or execute files

Write Can create files, write and append data to files, create folders, delete files, and Files and folders modify folders and file attributes (but not to subfolders and their files)

Although many administrators know that Full Control-Deny permission overrides any allow position, most don’t know that a Read-Deny can accomplish nearly the same thing. If a resource can’tbe read, it can’t be viewed, printed, modified, executed, or deleted. Of course, Read-Deny and FullControl-Deny are different things. If these permissions were applied at the folder level and resourcesinherited them, Full Control-Deny would prevent new files from being created, but Read-Deny wouldlet new files be written (but not modified).

All top-level NTFS permissions are made up of the more detailed sets of permissions shown inTable 4-5. You can view these permissions by clicking the Advanced button when viewing anobject’s NTFS permissions.



Table 4-5 NTFS lower-level permissions

Permission Description

Traverse Folder/ For folders: Traversing is moving through folders to reach other files or folders, even if Execute File the user has no permissions for the traversed folders. (This permission applies to folders

only.) Traverse Folder takes effect only when the group or user is not granted the Bypasstraverse checking user right in the Group Policy snap-in. (By default, the Everyone groupis given the Bypass traverse checking user right.)

For files: Execute File allows or denies running program files; the permission applies tofiles only.

Setting the Traverse Folder permission on a folder does not automatically set the ExecuteFile permission on all files in that folder.

List Folder/ Read Data List Folder lets a user view file names and subfolder names within the folder. List Folderaffects only the contents of that folder and does not affect whether the folder itself islisted. The permission applies to folders only.

Read Data lets a user view data in files; the permission applies to files only.

Read Attributes This permission lets a user view the attributes of a file or folder, such as whether the fileor folder is read-only or hidden. Attributes are defined by NTFS.

Read Extended The user with this permission can view a file’s or folder’s extended attributes, which are Attributes defined by each program.

Create Files/Write Data This permission lets a user create files in a folder and applies to folders only.

Write Data lets a user change the file, overwriting existing content, and applies to files only.

Create Folders/ Append Data Create Folders lets a user create a folder within the folder and applies only to folders.

Append Data lets a user make changes to the end of the file but not change, delete, oroverwrite existing data; it applies to files only.

Write Attributes This permission lets a user change the attributes of a file or folder, such as whether thefile or folder is read-only or hidden. Attributes are defined by NTFS.

The Write Attributes permission does not let a user create or delete files or folders; itincludes the permission only to change the file’s or folder’s attributes. To grant create ordelete ability, see Create Files/Write Data, Create Folders/Append Data, DeleteSubfolders and Files, and Delete.

Write Extended Attributes This permission lets a user change a file’s or folder’s extended attributes, which aredefined by programs.

The Write Extended Attributes permission does not grant the ability to create or deletefiles or folders; the user can only change the attributes. To allow create or delete ability,see Create Files/Write Data, Create Folders/Append Data, Delete Subfolders and Files,and Delete.

Delete Subfolders and Files Lets the user delete subfolders and files, even if the Delete permission has not beengranted on a specific subfolder or file. This permission applies to folders.

Delete Lets the user delete the file or folder. If you do not have Delete permission on a file orfolder, you can delete it if you have been granted Delete Subfolders and Files on theparent folder.



Table 4-5 NTFS lower-level permissions (continued)

Permission Description

Read Permissions Lets a user read a file’s or folder’s permissions, such as Full Control, Read, and Write.

Change Permissions Lets a user change a file’s or folder’s permissions, Full Control, Read, and Write.

Take Ownership Lets a user take ownership of the file or folder. The owner of a file or folder can alwayschange permissions on it, regardless of any existing permissions that protect the file orfolder.

Synchronize This permission lets different threads wait on the handle for the file or folder andsynchronize with another thread that may signal it. This permission applies only tomultithreaded, multiprocess programs.

When reviewing and setting NTFS permissions, it is important to use the more detailed, lower-level set of permissions because they use these ACEs. If you rely on the upper-level representations,you cannot guarantee how the lower-level ACEs are configured. For example, I have seen an admin-istrator choose the upper-level Read permission, but the lower-level permissions were Read, List, andExecute – more privileges than the administrator intended. I have also seen user accounts thatappeared to lack any permissions or had only the Special permissions check box enabled. When youview the basic Security tab, mixed advanced permissions show up as Special access. According to thelower-level permissions, the user account had Full Control permissions. Therefore, it’s a good idea toget into the habit of using the lower-level permissions to set and maintain security.

Effective Permissions Tab In Windows XP and Server 2003, clicking the Advanced button in the Security dialog box givesaccess to a new tab called Effective Permissions (see Figure 4-8). This helpful dialog box lets youspecify a security principal and see its effective NTFS permissions as accumulated by its NTFS token SIDs.



Figure 4-8 The Effective Permissions tab for boot.ini

Still, as helpful as the new feature is, it is important to note that the Effective Permissions tabdoes not reveal Share permissions or all the other system features and attributes that could determineeventual access control.

By default in Windows Server 2003, the Everyone group has Read and Execute, Traverse Folder,and List Folder permissions to the root directory of each volume. Consider removing all permissionsfrom the Everyone group in the root directory and assigning them to the Authenticated Users groupinstead. The default Everyone permission to the root directory is not inherited downward, so youdon’t have to worry about the Everyone group being added to newly created files and or folders.

NoteBe careful when using Deny permissions with the Everyone group; you may deny access toadministrative accounts unintentionally.

Registry Permissions NTFS permissions also apply to objects besides files and folders, such as printers and registry keys.Registry keys have top-level and lower-level NTFS permissions (see Table 4-6 and Figure 4-9). Reg-istry permissions can be viewed using regedt32.exe (regedit.exe in Windows XP Pro and Server2003). Registry permissions are highly undervalued as a tool in the fight against malicious mobilecode and intruders.

n



Table 4-6 Default registry permissions

Registry Hive\Key Function Default Permissions

(HKCR) Contains file associations and information used • Administrators, Creator Owners, and by Shell and COM applications System have Full Control

• Users have Read access• Power users have Special access

HK_Current_User Defines the settings and preferences of the • System, Administrators, and logged(HKCU) current user on user have Full Control

HK_Users (HKU) Defines the default user configuration for new • System and Administrators have Fullusers on the local computer and the user Controlconfiguration for the current user • Everyone group has Read access

HK_Current_Configuration Contains information about the current hardware • Users and Power users have Read(HKCC) profile of the local computer system. Describes access

only the differences between the current hardware • Administrators, System, and Creatorconfiguration and the standard configuration Owners have Full Control

HK_Local_Machine Defines the current state of the computer’s • System and Administrators have(HKLM) hardware and software Full Control

• Everyone group has Read access

HKLM\Software Defines current software settings, including • Administrators, Creator Owners,operating system settings and System have Full Control

• Users have Read access• Power Users and Terminal Service

User group have Special permissions



Figure 4-9 Sample NTFS registry permissions

Share Permissions Share-level permissions are available whether the file system is formatted with FAT or NTFS. Sharepermissions apply only to resources accessed over the network. They can be applied on folders andprinters, among other objects, but can’t be applied at the file level. To share a file, you must sharethe folder it is in. Share folder permissions are shown in Table 4-7. Share permissions don’t have aset of “lower-level” permissions to worry about.

Table 4-7 Folder share permissions

Permission DescriptionFull Control Grants all access and permissions to the share, including taking ownership and assigning share

permissions Change Grants the ability to read, modify, write, and delete files Read Grants the ability to read and list files, but not modify or delete them

Again, like NTFS permissions, assigning Read-Deny will result in consequences almost similar toFull Control-Deny. You should set Share permissions as permissively as is practical. However, the oldmethod – setting Share permissions to give Everyone Full Control, allowing the NTFS permissions todo the real security work – is negligent. Both NTFS and share permissions should be set to give all



security principals the least amount of permissions required to do their jobs. This new advice followsthe principle of defense-in-depth and gives an extra level of protection if either setting is incorrect.

By default in Windows Server 2003, the Everyone group has Read permissions to all existingadministrative shares and all newly created shares. Do not remove the Share permissions of theEveryone group from default admin shares (although Windows doesn’t allow admin share permis-sions to be changed by default, some third party utilities might). When new shares are created, makesure the default permissions of the Everyone group are removed unless they’re needed. Considerusing the Authenticated Users group instead of Everyone if all users need access but you want todeny anonymous and guest access.

You can use the srvCheck.exe utility, located in the Windows Server 2003 Resource Tool Kit, toidentify all existing shares and their assigned security principals and permissions. It can be used tocheck local and remote Share permissions. You can use subinacls.exe (also in the Windows Server2003 Resource Kit) to change Share permissions.

Using Permissions to Secure Resources Now that we have set up our knowledge base about permissions, we are ready to discuss specificrecommendations to better secure resources. Specifically, we’ll cover how to secure Windows systems, paying special attention to the file system and registry. As with all recommendations in thischapter, you should test any changes to your production network before applying them.

Where Malware Hides To better protect Windows systems, it’s important to understand where malware and hackers hide.After a successful exploit, the malware or the hacker usually re-configures the system so that the malicious code is loaded again if the computer reboots; this step ensures its survival. To do so, itmodifies files, startup areas, and registry keys. Using Object Access auditing, you can monitorattempts to access to these areas. Windows security can be strengthened by protecting unauthorizedaccess to these areas.

Securing the File System Windows default file security provides adequate security for most networks if it is installed, config-ured, and managed using Microsoft’s best practice recommendations. For example, with Windowsdefault security permissions, only administrative users have Write permissions to the areas of concern.This setting is the default for all startup areas and files, except for the user’s own profile (users haveFull Control of their own profiles).

Unfortunately, many networks give their end-users local administrator permissions. In general,non-administrative users should

• Be denied Read access to high-risk files• Have only Read & Execute permissions to their own startup folders, so that malware executing

in the user’s security context cannot write to these critical areas• Remove unnecessary files

A high-risk file, mentioned above, is a file that is more likely to be used maliciously by an unauthorized user than legitimately by an authorized user. These files tend to be located on thesystem with



• Minimal use by authorized users• Potential use by unauthorized users• High potential to do damage if used incorrectly• A higher-than-average chance of being used by unauthorized users or in an unauthorized way,

as compared to by legitimate users in an authorized way.

High-risk files are different from network to network, but some files, such as debug.exe andformat.com should be considered high-risk files in all networks. Other high-risk riles include

• Unneeded applications and services• Unneeded example files and scripts installed by applications• Resource tool kits (downloaded and installed for one file)• Troubleshooting utilities• Files left behind by software installation routines (some contain plaintext privileged account

passwords and program secrets)

Figure 4-10 shows files commonly considered high-risk by network administrators. However,before you disable one of these files, you should review the effect it would have on your network.

Figure 4-10 Common high-risk files



cmd.execommand.comformat.comregedit.exeregedt32.exeedit.combootcfg.execacls.execscript.exewscript.exedebug.exediskpart.exeedlin.exe

exe2bin.exe

expand.exe

ftp.exe

mshta.exe

progman.exe

regsvr32.exe

replace.exe

rsh.exe

runas.exe

taskkill.exe

taskman.exe

tlntsvr.exe

Potentially high risk OS file list includes:

To secure high-risk files, you have many options.• Remove or uninstall the files• Rename the files• Delete the files• Use SRP• Use third-party software applications that restrict the files• Use File permissions to prevent unauthorized users from having Read and Execute permissions

The first three options are not available on many default Windows system files because WindowsFile Protection (WFP) replaces the original file. In Windows Server 2000 SP2 and later versions, youcan no longer disable Windows File Protection by changing the registry.

The best way to secure high-risk files is to take away Read permissions to these files from theEveryone or Authenticated Users group. Don’t deny the Read permission, just clear the Allow Read.Denying Read access to the Everyone group prevents legitimate users and administrators fromaccessing these files, too.

Here’s an example that uses ACLs to secure the Windows\System32 folder.• By default, the Authenticated Users group has Read & Execute permission, as well as List

permission, to Windows and System32 folders.• Creator Owners usually have Full Control.• If you specifically remove Read & Execute access to high-risk files, unauthorized users can’t

execute high-risk files unless they installed them (creator owners).• After thorough testing, you should consider removing the System account from the highest-risk

files, like cmd.exe. Often, the System account never accesses these files, but an intruder whooverflows them may be able to use the System account’s access in a privilege escalationattack. Denying the System account therefore defeats many hacker mechanisms.

Securing the Registry The registry is the most common place malware hides to be executed. As is true for the file system,high-risk areas of the registry should be secured. One way to secure the registry is to restrict Readpermissions to only authorized users for high-risk registry areas.

With HKCU, the logged on user with Full Control (see Table 4-6) makes it possible for malwarethat is executed in the user’s context to write to this registry hive, which contains areas where malware would like to hide. Other concerns that make securing the registry challenging include

• There is no easy way to remove Full Control from the logged on user’s group on the HKCUkey, even if you wanted to.

• In the HKCC hive, Creator Owners also have full control, which is a concern, but unlikeHKCU, HKCC is not a popular malware target.



Usually, malware hides in auto-run registry keys to ensure that it will execute when the filereboots. Five autorun keys, along with subkeys and a few recommendations, are listed below.

HKLM\Software\Microsoft\Windows\CurrentVersion• Run• RunOnce• RunServices• RunServicesOnce• RunOnce\Setup• Policies\Explorer\Run

HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Windows• Run• Load• Winlogon\Shell

- Should either be blank or have value explorer.exe- Should not have a path

HKLM\Software\Microsoft\Active Setup\InstalledComponents\<clsid>• KeyFileName• StubPath

HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\• Shell Folders• User Shell Folders

- \Startup- \Common Startup

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ Explorer\BrowserHelper Objects

• Used by Internet Explorer 4.x and to attach browser add-ins and extend functionality• Any program registered there is loaded when Internet Explorer loads• Often used by malware and spyware

Assign non-administrators only Read access (Query Value, Enumerate Subkeys, Notify, and ReadControl) to the registry keys listed above. This setting is usually the default for all keys except HKCU,which is difficult to secure because of the special current logged on user permissions given by default.

Securing File Associations Another practical recommendation is to secure high-risk file associations. File associations tie a fileextension to a particular default application. Many file types are capable of delivering a maliciouspayload and have very little legitimate use in a corporation. You should secure high-risk file associa-tions by preventing unauthorized users from having Read access.



File associations are stored in the HKCR registry hive (HKCR is really mirror data fromHKLM\Software\Classes and HKCU\Software\Classes). Three different registry locations – HKCR,HKLM, and HKCU – can contain different values, depending on where values are added or modified.HKCR is combination mirror of the other two class hives; it is set up this way so that software caneasily, without checking multiple locations, find file association information. HKCU lets a programregister its file association on a user-by-user basis. If a file association entry appears in both HKLMand HKCU, HKCU takes precedence. If a program creates an entry in HKCR, it also appears inHKLM. If an existing entry exists in both HKLM and HKCU, and the HKCR entry is modified, only theHKCU entry is updated (which makes it user-specific). If an entry exists in HKLM or HKCU only, andthe HKCR entry is modified, only the hive with the existing value is modified.

What is a High-Risk File Association? High-risk file associations, like high-risk files, are more likely to be used maliciously by an intruderthan legitimately by an authorized program. Some types of files are often associated with malware,such as .scr, .vbs, .hta, and .wsf files. For example, a worm sent itself around disguised as a controlpanel applet: http://securityresponse.symantec.com/avcenter/venc/data/w32.beagle@mm!cpl.html. It’ssafe to say that most companies don’t need to allow their end users to send and receive controlpanel applets. If the .cpl file extension had been blocked from executing, the worm would have beenrendered harmless.

Microsoft’s Outlook/Exchange security filters block the following extensions by default: ade, adp,bas, bat, chm, cmd, com, cpl, crt, exe, hlp, hta, inf, ins, isp, js, jse, lnk, mda, mdb, mde, mdt, mdw,mdz, msc, msi, msp, mst, ops, pcd, pif, prf, reg, scf, scr, sct, shb, shs, url, vb, vbe, vbs, wsc, wsf, andwsh. Table 4-8 shows a much larger list of potentially dangerous files. You’ll see that many of themare associated with Internet Explorer (IE).

Table 4-8 Potentially high-risk file associations

Extension Description Threat

.ade, .adp, .and Microsoft Access project files Can contain autoexecuting macros

.asf, .lsf, .lsx Streaming audio or video file Can be exploited through buffer overflows, headmalformation, or dangerous scriptable content

.atf Symantec pcAnywhere autotransfer file Can initiate a pcAnywhere file-transfer session

.bas Visual Basic (VB) class module Can be a malicious program

.bat DOS batch file Can contain malicious instructions

.cab Microsoft cabinet archive file Opens in IE and can help install malicious files

.cer, .crt, .der Security certificate Can install a malicious certificate in IE to permitautomatic downloading of malicious content

.cpl Control Panel application Can install malicious code

.dsm, .far, .it, Nullsoft WinAmp media file Has been involved in malicious exploits

.stm, .ult, .wma

.dun DUN export file Can contain malicious dial-up connection informationthat initiates outward calls

.eml, .email Outlook Express email message Used by Nimda

.exe Application file Can launch malicious executables



http://securityresponse.symantec.com/avcenter/venc/data/w32.beagle@mm!cpl.html

Table 4-8 Potentially high-risk file associations (continued)


.fav IE Favorites list Can list malicious Web sites

.hlp Microsoft Help File Can be used in multiple exploits

.ht, .htt Hyperterminal file Can initiate dial-up connections to untrusted hosts

.hta HTML application Frequently used by worms and trojans

.htm, .html IE HTML file Can initiate an IE session and be used to automaticallydownload and execute rogue files

.ini Application configuration settings file Can change a program’s default settings

.ins, .isp Internet communication settings Can be used to initiate Internet connections tountrusted sources

.jar Java archive file Can launch Java attacks

.jav, .java Java applet Can launch Java attacks

.js, .jse JavaScript (encoded) file Can contain malicious code

.lnk, .desklink Shortcut link Can be used to automate malicious actions

.mad, .maf, .mda, Access module shortcut Can carry out macro manipulation that isn’t

.mas, .mag, .mam, controlled by Office security settings

.maq, .mar, .mat,

.mav, .maw, .mdn,

.mdt, .mdx

.mdb, .mdbhtml Access application or database Can contain malicious macros

.mde Access database with all modules Can contain malicious macroscompiled and source code removed

.mhtml, .mhtm MIME HTML document Can contain harmful commands

.mim MIME file Can be a target of future MIME exploits

.msg, .mmf Microsoft Mail or Outlook Express item Can carry the Nimda virus

.msi, .msp Microsoft Installer package Can install or modify software

.mst Visual Basic test source file Can be used maliciously

.nws Outlook Express news message Can carry the Nimda virus or other malware

.pdc Microsoft compiled script Can contain dangerous code

.pif Program information file Can run malicious programs

.pl Perl script file Can contain rogue code

.prf Outlook profile settings Can override default or trusted settings

.ppt, .ppa, .pot, Microsoft Powerpoint presentation, Can contain scripted exploits

.ppthtml, .pothtml add-in, or template file

.pst Outlook or Exchange personal store file Can contain malicious attachments and be importedinto Outlook or Outlook Express

.py Python script file Can contain rogue code

.reg Registry entry file Can create or modify registry keys

.rtf Rich Text Format file Can script other attacks

.scf Windows Explorer command Could be used maliciously in future attacks



Table 4-8 Potentially high-risk file associations (continued)


.scp DUN script Can initiate rogue outbound connections

.scr Windows screen saver file Can contain worms or Trojans

.shs, .shb Shell scrap object Can mask rogue programs

.slk Excel SLK data-import file Can contain hidden malicious macros

.stl Certificate Trust List (CTL) Can induce user to trust a rogue certificate

.swf, .spl Shockwave Flash object Can be exploited

.url Internet shortcut Can connect user to malicious Web site or launch a maliciousaction

.vb, .vbe, .vbs VBScript file Can contain malicious code

.vxd Virtual device driver Can trick a user into saving a Trojan version of a legitimatedevice driver

.wbk Word backup document Can contain dangerous macros

.wiz Wizard file Could be used to automate a future social engineering attack

.ws, .cs, .wsf, WSH file Can execute malicious code

.wsc, .sct

.xla, .xlb, .xlc, Excel file types Can contain dangerous macros and code

.xld, .xlk, .xll,

.xlm, .xlt, .xlv

.xls, .xlshtml, Excel spreadsheet Can contain dangerous macros and code

.xlthtml

.xml, .xsl XML file Likely to be the next language of choice for malicious coders

Blocking High-Risk File Extensions Security administrators, in association with management, should determine the file extensions a company blocks. From the list presented above, decide which file formats are used legitimately inyour company, and block the rest. You can block files in many ways: with firewalls, email scanninggateways, anti-spam filters, email server filters, and client-side mechanisms.

Another block denies non-administrator users Read access to the registry keys that determine fileassociations. Each file association key can be traced back to HKCR and blocked there. For example,Visual Basic Scripting is often used to write email worms. To block users from executing a worm ofthat nature, follow these steps:

1. Determine the file extension. In this case, the file extension is vbs.2. Open the HKCR registry hive. Search for the .vbs file extension. A file extension search, with

the period included, usually points to an upper-level registry key in HKCR that points to thekey we really want (see Figure 4-11).

3. The key reveals that the .vbs file association is handled by a key called VBSFile.4. Search on VBSFile registry key located in the lower portion of HKCR. The HKCR/VBS key

appears.5. Open HKCR\VBSFile and modify its permissions to remove Read permission for all

non-administrator users (see Figure 4-12).



Figure 4-11 Using HKCR to locate the .vbs file association key

Figure 4-12 Removing non-administrative access to the VBSFile key

Blocking file extension associations in the registry doesn’t guarantee that a particular file typewon’t be executed – for example, VBS files can still be executed by vbscript.dll in IE – but it is agood start. Of course, using automation tools like Group Policy makes the job easier. The key is thatyou should not wait until a virus or worm gets past the perimeter security defenses to react. Beproactive and prevent regular users from executing malicious code in the first place.



Startup areas and file associations aren’t the only places in the registry that malware hides. Thefollowing registry keys are often exploited using the Shell\Open\Command registry keys.

• HKCR\exefile• HKCR\comfile• HKCR\batfile• HKCR\htafile• HKCR\piffile

HKLM\Software\Classes and HKCU\Software\Classes also have the same keys.

For example, HKCR\exefile\Shell\Open\Command is often exploited by worms. The value ofthis key should almost always be “%1” %* (the value must include quotes and the space after secondquote). Malware often places its filename in the value, which launches the malware program anytimethe default program is launched. For example, FILES32.VXD “%1” %* . You should ensure that non-admin users have only Read and Read & Execute permissions to this registry key.

Best Practices For optimal security relating to file system and registry permissions, follow these recommendations.

• Understand Windows’ built-in users and groups, when they apply, and their consequences• Use NTFS• Use the AGULP security model• Assign permissions using the least privilege principle• Use the Runas feature when possible for administrative tasks• Document file and share permissions• Use other mechanisms (such as SRPs and GPOs) to help control access• When managing NTFS permissions, get into the habit of using the “lower-level” permissions to

set and maintain security• Secure high-risk files• Secure high-risk registry locations

Summary Chapter 4 examines Windows NTFS and share permissions in detail. A security principal’s access to aresource is governed by more than the resource’s NTFS and Share permissions, but those permissionsmust be thoroughly understood to knowledgeably manage security. Administrators have many optionsfor strengthening Windows security in these areas, including securing high-risk files and registry keys.Chapter 5 looks at designing an effective audit policy to detect malicious intrusions.



103


Chapter 5:

Auditing to Detect IntrusionsNo matter how well you secure a computer, malware and rogue hackers will still assess its weaknesses and try to exploit any potential vulnerability. Windows has a fantastic feature that letsyou monitor attempted and successful exploits – auditing. When configured correctly, auditing canmonitor and detect most intrusions. The more you learn about Windows security, the more you’ll beinvolved with the audit logs.

With Windows auditing, you can configure settings in nine different categories of events; in this way, you can capture most events occurring on a workstation or server. To successfully enableauditing, you need to understand what each audit category does, understand the different components of a successful audit policy, and know how to read the resulting messages. Chapter 5covers basic intrusion detection, Windows auditing, audit policy, auditing categories, event log management, and audit policy best practices.

Intrusion Detection Intrusion detection is the process of noticing an unauthorized event, an unauthorized action, or unauthorized content. Unauthorized events can be caused intentionally by outside hackers, legitimateinsiders performing unauthorized activities, or automated malware, or even by insiders innocentlycausing accidents.

According to the Microsoft product support teams that handle hacking incidents, the mostcommon symptoms of unauthorized malicious events are

• Unexplained account lockouts• Unexplained significant, rapid, sustained increase in CPU utilization (indicating a possible

worm)• Unexplained significant, rapid sustained increase in usage of local or wide-area network

bandwidth (indicating a possible worm or a denial-of-service attack)• Unexplained significant decrease in free disk space (indicating the possibility of a hacker using

storage space)• Unexpected server or workstation reboots (all instances should be investigated thoroughly)• Unexpected process crashes (indicating buggy hacker code)• Unexplained STOP errors (a.k.a. Blue Screens of Death)• Unexplained network connections• Unexpected installation of new services or programs (which is hard to track unless you are on

top of the services and programs that should be running)• Unexpected installation of new software patches (indicating the possibility that hackers are

closing holes that allowed them in to protect their newly acquired asset from other hackers)• Unexpected file or registry modifications (a very common indication of automated malware)• Suspension or disappearance of antivirus software • Deletion of Admin shares



• Appearance of new, unauthorized user accounts• Unexpected activation of a high number of DHCP leases • Unexplained clearing of the security log — which is different from a security log that has

never logged any security events

Although any of these events can have non-malicious causes, any instance of these symptomsshould be immediately researched to conclusion. All of these types of events can be detected manually through observation or using auditing and other related mechanisms.

Windows Auditing In Windows, you can audit nine categories of policies in up to six default log files: Application,Directory service, DNS Server, File Replication Service, Security, and System. Security events are usually posted to the Security log, although some are sent to the Application log file. Log files can beaccessed using Event Viewer (Eventvwr.exe located in the System32 folder). Users, by default, haveRead and Execute NTFS permissions on the Event Viewer application. It can be launched and usedon the command line, through a Microsoft Management Console (MMC) application (for example,Computer Management or Local Computer Policy), through group policy, or through administrativeutilities such as Systems Management Server or Message-Oriented Middleware.

The Application, Security, and System log files are available on all operating systems in the NTfamily, to both clients and servers. Any application can write to the Application log file, but the application developer must specifically code the application to do so; Windows doesn’t automaticallywrite application errors to the Application log. The Windows OS writes most audit messages to theSecurity log, although other applications can also use the security log if they are specifically programmed and allowed to do so. The System log file typically contains only event messages thatare generated by the operating system. The Directory Service and File Replication Service log files areavailable only on computers with Windows 2000 or later file server OSs. The DNS Server log file isavailable on Windows 2000 or later file servers running the DNS Service. This chapter concentrates onthe Security log file.

Security Log The security log file is called SecEvent.Evt and is located in %SystemRoot%\System32\Config along with the other default log files. To change the location of the Security log file, modify theHKLM\System\CurrentControlSet\Services\Security\File registry key. Several other log-related valuescan be modified in this registry area.

By default, two different services write to it the Security log: the Security Reference Monitor(SRM) and the Local Security Authority Service (LSASS). The SRM reports on interactions with objectsand LSASS on all other operating system audited events. By default, only Administrators and theLocalSystem accounts have Full Control access to the default log files. Non-administrative users canview (but not manage or clear) the Application and System logs, but they have no access the Securitylog file. A group policy (or registry edit) setting called Prevent local guests group from accessing security log determines whether members of the Guests local group can access the security log. Guest access is disabled by default in Windows XP and above, although enabling the setting is usually unnecessary anyway because the default Guest account is disabled by default. Guest access tothe security logs was necessary for some legacy applications.

Chapter 5 Auditing to Detect Intrusions 105


User accounts must possess the Manage auditing and security log user privilege to access theSecurity log. Unfortunately, user accounts with this right can also clear the Security log. This right alsolets individual users enable object access auditing (covered below) on a per-object basis, but does notenable general Audit Object Access auditing. By default, only Administrators have this right.

Another related setting is Generate security audits. Accounts with this user right can add events tothe Security log. By default, only the Local Service and Network Service accounts have this privilegein Windows XP and 2003. To write to the Security log, other applications or services must run in auser account context that possesses this user right. This right was created to prevent hackers or programs from writing random security events to the Security log file in an attempt to hide legitimateentries.

For some events, such as detailed Kerberos events, to be written to the security log, logging mustbe turned on explicitly. By default, most Kerberos authentication events are logged; however, not allare included. To ensure that all Kerberos events are logged, you must enable detailed Kerberos logging by creating a new registry value. Create the HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel and set its value to 1.

Event Message Fields Every event log message contains one or more fields. Table 5-1 shows the main Security log eventmessage fields:

Table 5-1 Security event log message fields

Field Description

Date The date the event occurred.

Time The time the event occurred.

Type This field has two possible values: Success Audit or Failure Audit. Typically, a success audit is loggedwhen some event has been successful (for example, a successful logon or permitted object access), and afailure audit is logged when some event has not been successful (for example, a failed logon or deniedobject access). Some success audits are generated for events that failed or were denied (successfully so, Iguess).

User The security principal account involved in the security event. This account can be a user, computer(computer accounts end with a $), a service, a built-in account (for example, System orAnonymous_Login), or other security principal.

Computer The computer where the event happened or was authenticated.

Source The process, service, or application involved in the event. Unfortunately, in the Security log, the Sourcefield always contains the value, “Security,” which provides little additional help.

Category In the Security log, the category classifies the type of event, such as account management or object access.

Event ID The numeric value of the event message. Microsoft tracks event messages using this value; this value alsoidentifies the message in event log databases. An excellent online source for event IDs ishttp://www.eventid.net. It’s not always 100 percent accurate or inclusive, but it is as good as you’ll find.

Description This field contains more event-specific information (see Table 5-2 for example fields). The iformationdisplayed varies by event type.

http://www.eventid.net

Figure 5-1 is an example of a Security event log message showing many of the common fields.The example shows Event ID 540, a successful logon/authentication event of a workstation accountto the server.

Figure 5-1 Example security event log message



Table 5-2 Example security event description fields

Field Description

Event Description A short text field, usually one sentence or less, that tracks to the Event ID.

User Name The account involved in the event. Could be an actual user logon name, a computername (always followed by a $), or a built-in account like System.

Domain The name of the NetBIOS domain where the (user name) account is located. If the useraccount is from the local Security Accounts Manager, this field has the local computer’sNetBIOS name. For built-in local accounts, this field has the value of NT Authority.

Logon ID A number unique to the logon session. It is not the user’s logon account name. The LogonID is unique until the computer is restarted. This field can be used to track related events.

Logon Type The method the account logged on with (see Table 5-3). It indicates whether the accountlogged on locally (interactive), over the network, or in some other way.

Logon Process The name of process that performed the logon (see Table 5-4).

Authentication Package The authentication software package used in the authentication event (see Table 5-5).

Workstation Name The NetBIOS computer name.

Logon GUID A number that is like the Logon ID field but is globally unique.

Transited Service The Kerberos delegation extension field (http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs).

Source Network Address The source IP address, if available (and if it’s part of the event message).

Source Port The source transport port number, if available (and if it’s part of the event message).

The description information that is displayed varies widely according to the Event ID. Forexample, Event ID 776, Certificate Services published the certificate revocation list (CRL), has description fields labeled Base CRL, CRL No, Key Container, Next Published, and Published URLs. For more information about each event message, search on each Event ID in Windows Help andSupport, online help, or on one of the online support sites (such as http://www.eventid.net).



http://www.eventid.net

http://msdn.microsoft.com/msdnmag/issues/03/04/SecurityBriefs

Table 5-3 Logon types

Value Description

2 An interactive logon; a local logon, not done using a network. However, in Windows NT and 2000, TerminalServices and remote desktop logons are recorded as local logons.

3 A network logon; a logon that occurred remotely over network. However, this value can also be recorded if alocal user browses a computer using Network Neighborhood.

4 A batch logon; this value indicates accounts that log on with the Logon as batch job privilege. Normally, thisvalue is recorded only for Task Scheduler jobs, but any logon account can be given that right.

5 A service logon; the logon was done by a service configuration manager on behalf of a service using a serviceaccount (that is, a service started and logged on).

6 A proxy logon

7 An unlock workstation event; a user logged back into a workstation at a console locked from the screensaver.

8 A network cleartext logon; this value is usually associated with an IIS logon using Basic Authentication.

9 A Newcredentials logon; a caller (process, thread, or program) cloned its current SID token and specified newcredentials for outbound connections, creating a new logon session.

10 A RemoteInteractive logon; this value indicates a Remote desktop (RDP) or terminal services logon process(new in XP and above).

11 A logon process that used cached credentials. By default, all computers and users can log on using previouslycached credentials if a domain controller is not available to authenticate their logon request.

Table 5-4 Logon processes

Value Description

AdvApi An application called LogonUser initiated the logon

Kerberos Kerberos initiated the logon IIS Microsoft IIS initiated the logon

MS.Radiu A Remote Authenticated Dial-In User Service (RADIUS) such as InternetAuthentication Service (IAS) initiated the logon

Ntlmssp NTLM performed authentication

SCMgr A service account logged on

User32 or Winlogon/MSGina A normal interactive (local) logon process, often initiated by the end-user hitting Ctrl-Alt-Del sequence to log on

Table 5-5 Default authentication package values

Value Description

Microsoft_Authentication_Package _V1_0 Capable of LM or NTLM (version 1 or 2) authentication

Kerberos Kerberos authentication. Not valid for local logons; available only inWindows 2000 and above

Negotiate Client and server negotiate authentication protocol. Currently valid onlybetween NTLM and Kerberos.

SChannel IIS authentication. SSL or TLS support.

Digest Authentication IIS authentication.



Because authentication packages can be customized (for example, for advanced cryptography orsmart cards), the values listed above can change.

Microsoft is aware that their event log messages aren’t always easy to understand for the newuser, but every version of the operating system has easier-to-understand messages. Event log messages in Windows XP and above often contain direct links to Microsoft articles about that Eventlog message. In Windows 2000, the user can copy the event log message text to the clipboard withone click, so that it can then be posted easily into an Internet query. Microsoft is also working tominimize the number of less-useful messages (that is, “noise”) to make the logs more relevant.

Other Logs Many other Windows applications have their own log files, including IIS, Windows Firewall, DHCP,DNS, and PPP. IIS has multiple logs (located by default in %SystemRoot%\System32\Logfiles),including separate log files for HTTP, FTP, and the SMTP virtual server. IIS 6.0 splits invalid HTTPrequests from the normal web log to a separate log file under the \Httperr folder.

Each of these logs can be customized to change the frequency the log rotates, its location, andthe information it contains. The IIS logs can be used with the Security log to track events. Forexample, successful or failed IIS authentication events are tracked to the security log; however, in IISversions before 6.0, the IP address of the computer attempting to authenticate was tracked only in theIIS web service log file. Used together, both logs paint a more complete picture. In Windows Server2003, the security log in IIS 6.0 security log can track IP addresses for IIS authentication events.

The Windows Firewall log, when enabled, saves events to %SystemRoot%\Pfirewall.log. DHCPsaves detailed log files to %SystemRoot%\System32\DHCP. Each log file begins with a description ofthe various DHCP events tracked. Perhaps the most detailed logs are generated by DNS. WindowsServer 2003 DNS can track every DNS event down to packet-level data.

When setting up a Windows auditing scheme, you should research the logs that are available to the various applications enabled on each computer; you might find that there are advantages to enabling logging there, too. Follow the instructions in KB Article 234014 (http://support.microsoft.com/default.aspx?scid=kb;%5BLN%5D;234014) to enable PPP logging of dial-up connections. IAS and RRAS have similar instructions to enable logging.

The Performance Monitoring utility (called the Performance Console in XP and above) can track statistics that provide useful security information. For example, worms, buffer overflows, anddenial-of-service trojans often cause sudden, unexplained, sustained spikes in processor or networkutilization. The worms start thread after thread in their search for more machines to exploit. Bufferoverflows can cause spikes of 100% utilization because of the unnatural way programs end. Savvysecurity administrators can enable Performance Monitor alerts to warn them of sustained high utilization levels.

In the larger picture of detecting malicious intrusions, don’t forget the logging facilities of yourother network devices, such as firewalls, switches, antivirus services, mail gateways, routers, and othersecurity devices. When a malicious event occurs, every bit of extra auditing helps in forensic analysisand recovery.



http://support.microsoft.com/default.aspx?scid=kb;%5BLN%5D;234014

Audit Policy As is the case with any security tool, successful audit policies require a little bit of forethought andpre-planning. Enabling auditing should involve these three overall steps:

1. Decide what to audit. 2. Configure and enable auditing. 3. Monitor audit event messages.

Here are some basic questions to consider: • How large can the audit logs become? • What audit categories should I enable?• What objects should I audit?• How should I collect and monitor event messages?• Who has ownership of the audit policy?• How should the event logger treat log files when they become their maximum size?• If the audit log fills up, should the computer “freeze”?• How should old event logs be archived and for how long?

The rest of this chapter will cover these topics.

Maximum Log Size The first order of business is to determine the maximum size of the Security log (see Figure 5-2).Although the theoretical maximum size of the log file is the maximum file size that is available to theNTFS file system (4 GB in Windows 2000 and later), the real maximum size is much smaller. BillBoswell, columnist for Redmond Magazine (http://www.redmondmag.com/columns/article.asp?EditorialsID=743) discovered that the maximum size is 1 GB, and because of other related processes,the maximum practical size is somewhere around the area of 300 MB.

In any case, very large logs are cumbersome and slow; as the size grows, the log works evenmore slowly. It takes longer to open Event Viewer, takes event log management tools longer to perform queries, and makes sorting and extracting information sluggish. On the opposite end of thespectrum, if you create separate smaller log files, you must combine them to get trends and findevents that span multiple time periods. Regardless, at some point, your logs fill and have to becleared, archived, or overwritten.

You can set the maximum size for the log file in three ways: in the registry, in the user interface(see Figure 5-2), or using group policy.



http://www.redmondmag.com/columns/article.asp?EditorialsID=743

http://www.redmondmag.com/columns/article.asp?EditorialsID=743

Figure 5-2 User interface for setting maximum log file size

Log sizes must be multiples of 64KB. The default log size for Windows Server 2003 is 16 MB; for XP Pro, it is 512KB. Choose any size that is practical for your organization. For example, if yoursecurity log captures 1 MB of data per day and you need 7 days of data in one log, make your Security log maximum size 7MB (or a bit more to include long weekends and holidays).

If you are unsure what size to make your log, start with a 16MB file and adjust up or down, asyour experience dictates. As a general rule, domain controllers and file servers probably need largelog files and end user workstations smaller logs.

Archiving Events When the log file has reached its maximum size, you have three options: clear the log, allow it to beoverwritten, or save the log file. In setting group policy, this setting is known as Retention method forlog. The default setting (see Figure 5-2) is to Overwrite events as needed. This option overwrites oldestevents first. You can also choose to Overwrite events older than x days old. You may also choose tonot overwrite events, which requires that you clear the event log manually. If you choose this optionand the event log fills up, no events will be logged until the log is cleared.

In high-security environments, you can enable a security setting to shut down the system if the Security log becomes full; in group policy, choose Local Policies, Security Options, Audit: Shutdown system immediately if unable to log system audits or by setting a registry key value (seehttp://support.microsoft.com/?kbid=888179 ). This setting is available so that security events are neverdropped. If events can’t be recorded, the system becomes unavailable. This defense was created




specifically to prevent a hacker from generating enough bogus security events to fill the Security logand make it stop logging. If the system does stop processing because of this setting, it generates aSTOP error. The system can be restarted, but only an administrator can log on. The administratormust re-set a registry value, save and clear the log, and restart the system.

It makes sense to save and back up your logs before you clear them or allow events to be overwritten by new events. Often, the event you are troubleshooting, malicious or not, had its originsdays or months before you noticed the symptom. An archive of old logs makes forensic investigationeasier; creating a plan to archive audit logs is covered below. In high-security environments, youshould consider backing up all logs to write-one, read-many media. This will help support the logs asstronger evidence, if the need arises.

Audit Categories You can log nine categories of events (see Figure 5-3):

• Audit account logon events • Audit account management • Audit directory service access • Audit logon events • Audit object access • Audit policy change • Audit privilege use • Audit process tracking • Audit system events

Figure 5-3 Audit categories

Categories can be enabled or disabled using Local Computer Policy or group policy. You canenable each category for success, for failure, or for both. You should audit both the success andfailure of high-risk events (such as logons), failure-only for events that monitor attempted unautho-rized access, and both success and failure for high-risk events for which any access should be noted.



Generally, you should audit success and failure events • if the asset has a high risk of compromise• if the asset has high value to the organization• if the asset, if successfully exploited, leads to widespread compromise of other network

resources (for example, the Domain controller, DNS server, or the Certificate Services server)• any system events • any policy changes

In general, you should audit failure events for most audit categories except process tracking andpolicy change. Generally, you should audit success events for Audit account management.

Table 5-6 shows the recommended settings from in the Microsoft Windows Server 2003 SecurityGuide.

Table 5-6 Windows Server 2003 Security Guide recommendations

Computer Environment Audit Category Legacy Enterprise High Security

Account logon events Success, Failure Success, Failure Success, Failure

Account management Success, Failure Success, Failure Success, Failure

Directory service access Success, Failure Success, Failure Success, Failure

Logon events Success, Failure Success, Failure Success, Failure

Object access Success, Failure Success, Failure Success, Failure

Policy change Success Success Success

Privilege use No Auditing Failure Success, Failure

Process tracking (see Note below) No Auditing No Auditing No Auditing

System events Success Success Success

NoteThe Security Guide recommends a setting of No Auditing for Process Tracking; however, thischapter recommends enabling it on domain controllers. See the “Audit Process Tracking”section below for more discussion.

When enabling these overall categories, most categories are “all or nothing” — you can’t set themfor individual objects or users. For example, if you enable Audit privilege use or Audit system events,all uses of those privileges (such as user right assignments) or all system events for all security principles will be recorded. However, the Audit object access category must be set on a per-objectbasis, and on a per-user or group basis.

Now, we’ll cover each category in more detail.

Audit Account Logon Events When Audit account logon events is enabled, all domain-based authentication events are logged tothe authenticating domain controller. For example, if a domain user on Computer A connects to a fileshare on MemberServerB, the authentication event is logged only on the domain controller that

n



authenticated the event. This setting does not track logons or authentication events involving localaccounts. When tracking hackers, an administrator has to check only participating domain controllersto find relevant authentication events. This setting was not available until Windows 2000.

When checking events in this category, you look for sustained patterns of logon failures,although not all logon intrusion events will trigger a failure event. For example, Event 644-AccountLockout is a success event. If you find suspicious patterns, note the logon time, type, and process.Multiple, successive logon attempts performed in a very short time period usually indicate an automated attack.

Note Both Audit account logon events and Audit logon events monitor successful and failed attemptsto logon or to authenticate.

Audit Account Management This setting tracks the creation, change, or deletion of a user account or group and records when a password is set or changed. Hackers often create new user accounts or add themselves to administrative groups. For example, a hacker could use a privilege escalation attack to add a regularend-user account to the Administrators group or to enable a previously inactive account. Events inthis category tell you what was affected and what account initiated the change. Accounts that arelocked out are recorded in this category, as well as passwords that are reset or changed.

Important account management events include• 624 User account created• 627 User password reset• 628 User password set• 630 User account deleted• 629, 626 Account disabled, or re-enabled• 632 Member added to global group• 635 New local group created• 636 Member added to local group• 643 Domain policy changed• 644 User account locked• 645 Computer account created• 658 Universal group created• 660 Member added to universal group• 685 Name of an account changed

n



Audit Directory Service Access This category records when a security principal accesses an Active Directory object on a domain controller. In the Default Domain Controller Group Policy object (GPO), this value is set, by default,to no auditing and remains undefined for workstations and servers where it has no meaning.Although security experts often ignore this category, they shouldn’t — it is good for tracking hackeractivities during a known compromise across the network.

Audit Logon Events This category tracks local logons and authentication events at the computer where the resource isaccessed. Events to watch for in this category include

• 528 User logged on• 529 Logon failure; bad name or password• 530 Logon failure; outside allowed logon time• 531 Logon failure; logon attempted to disabled account• 532 Logon failure; logon attempted using expired account• 533-539 Logon failures for various reasons• 540 User logged on to network• 548 and 549 Logon failure-Filtered SID• 550 Possible denial of service (DoS) attack

In most cases, enabling Audit logon events and Audit account logon events at the same time is agood way to make sure you capture all logon and authentication events, which will let you watch forpassword and account hacking. For example, if you have renamed your Administrator account, be onthe lookout for attempted logon attempts to the old account name, which will trigger the messageEvent ID 529 - Unknown User name or bad password. If you have disabled your bogus Administratoraccount, look for Event ID 531 - Logon Failure-Account Disabled or Event ID 675 - Pre-authenticationfailed - the user typed bad password.

Audit Object Access This category, Audit object access, is perhaps the juiciest auditing feature in Windows. It tracks anyaccess or attempted access of any Windows object with a system access control list (SACL; covered inan earlier chapter). In tracking hackers and malware, auditing object access is the most valuableplayer.

Objects that can be audited include files, folders, registry keys, and printers. Objects can beaudited overall, per group, or per user. The specific attributes and accesses that can be audited vary,because files, registry keys, and printers are distinctly different objects. Attributes available for fileauditing (see Figure 5-4) include read access, delete attempts, write attempts, execution, changingpermissions, and taking ownership.



Figure 5-4 File auditing attributes

Object access auditing is particularly tricky because it is a two-step process: it must be enabledoverall (in the category setting) and then on each individual object you want to monitor. However,enabling auditing on every object on a computer system creates a lot of overhead and takes literallyhours to complete, even if you perform it at the root level. Therefore, you should enable objectaccess auditing on areas that are most likely to be compromised, such as auto-run registry keys,Startup folders, and the System32 folder. Other sensitive areas to monitor include

• Write success or failure on system or program files to monitor for virus execution• Write success of HOST file• Deletion or modification of antivirus program files

Notable Event IDs include• 563 Attempt was made to delete file• 564 Object deleted• 567 Permission was executed on object• 570 Object access attempted



Audit Policy Change This security setting can log every change to user rights assignment policies, audit policies, or trustpolicies. Note that this setting does not include changes to group policy (as often believed) orchanges to password policy. It might be helpful in catching a hacker clearing the event log or inattempting to elevate privileges. Notable events include

• 608 User right assigned• 609 User right removed• 612 Audit policy changed• 621 System access granted to an account

Note Because of a bug, the Failure setting does not capture data; therefore, the administrator cancheck only for successful Audit Policy Changes. There is no easy way around this bug untilMicrosoft fixes it.

Audit Privilege Use This security setting can track each instance in which a security principal exercises a user right (that is, a privilege). To see a list of possible privileges, open any group policy object and view theUser Right Assignments container object or visit http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/520.asp. User rights assignments are considered privileges becausethey convey additional permissions that cannot be communicated solely using NTFS object security.

When enabled, this category tracks the use or attempted use of any privilege by a security principal of any user right except these:

• Bypass traverse checking • Debug programs • Create a token object • Replace process level token • Generate security audits • Back up files and directories • Restore files and directories

Auditing the user rights listed above tends to generate too many (usually uninteresting) events inthe security log, which impedes performance without adding security value. For example, if backingup and restoring files were audited by default, every routine data backup would generate thousandsto millions of events each time it ran. However, if you choose, you can enable the auditing of theserights in the security options of group policy.

n



http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/standard/proddocs/en-us/520.asp



Audit Process Tracking This category creates detailed information for events such as program activation, process exit, handleduplication, and indirect object access. It is usually not set unless it is needed in ongoing programdevelopment or hacker tracking. Often, security guides recommend not enabling process trackingbecause of the “noise” it could create, but you should enable it on any computer where you suspectmalicious or unauthorized activity.

You should also enable it on any domain controllers. Domain controllers aren’t usually startingand stopping a lot of applications, so any “noise” it creates is minimal. Also, any domain controller isa high-value target, so enabling Audit process tracking is compulsory for competent security auditing.

Notable events for this category include • 592 New process created• 593 Process exited• 595 Indirect access to an object was obtained• 601 User attempted to install service

Audit System Events This category tracks the times that a user restarts or shuts down the computer or when an eventoccurs that affects either the system security or the Security log. Events to be aware of in this categoryinclude

• 512 Windows is starting up• 516 Resources exhausted; security events lost• 517 Audit log cleared• 519 Process used invalid local procedure call in an attempt to impersonate a client• 520 System time changed

If any of these events happen unexpectedly, you should investigate the event until you areassured that it was not an intrusion.

Per-User Selective Auditing A new feature added in XP SP2 (and slated for Windows Server 2003 SP1) is Per-User SelectiveAuditing. Introduced to meet a Common Criteria (http://csrc.nist.gov/cc) objective, it allows exceptions to overall audit policy on a per-user basis (you cannot set up exceptions for groups). Italso ignores audit exceptions set for administrative accounts.

Using the AuditUsr.exe tool located in %SystemRoot%\System32, you can define exceptions tothe overall audit policy for all nine categories (see Figure 5-5).



http://csrc.nist.gov/cc

Figure 5-5 AuditUsr.exe command line syntax

With this tool, you can import user accounts and settings in a comma-delimited file and exportcurrent exceptions to a file for confirmation purposes. Unfortunately, this feature is not very well documented.

Auditing Isn’t Perfect Although Windows auditing can capture most unauthorized events, it isn’t perfect. To begin with,most event log messages are summaries. If you need the details of an attack, you’ll need to rely onanother auditing tool, like Network Monitor. Second, Windows auditing uses in-band tools, meaningthat the data collection happens on the system that is being monitored. Therefore, a hacker can findout whether auditing is enabled, and if it is, manipulate the outcome. Finally, auditing misses manysuccessful attacks, including many buffer overflows. If a buffer overflow from a single packet attackcompromises a particular executable, the event logs don’t always note the event as malicious. For thisreason, always use Windows auditing in conjunction with other monitoring tools, such as antivirus orintrusion detection systems.



Event Log Management Managing your event logs requires more than simply collecting and reading event messages. Itincludes

• Measuring baselines• Synchronizing time • Logging security events • Determining log rotation and permanence• Collecting data in a central place • Filtering data • Correlating data • Extracting useful information • Setting up an alerting system

All part of the process must be planned, coordinated, and tested if intrusion detection is to besuccessful and useful.

Measuring Baselines Detecting unauthorized activity is impossible if you don’t know what normal baseline activities are tostart with. Before you start actively managing your event logs, you should monitor all the computersinvolved for normal activity. As any system administrator knows, Windows constantly creates eventmessages on any system. The trick is to learn what is and isn’t normal. You should troubleshoot anyunexpected events that come up during the baseline monitoring sessions before you start activelymanaging your event logs for security events. You should note and document baseline activity to usein future comparisons.

Synchronizing Time It is important that all computers involved be synchronized, including the logging and monitoringworkstations. Make sure the time, date, and time zone settings are identical. Unsynchronized systemscan make event correlation much harder than it needs to be. As a side benefit, guaranteed accuratetime synchronization will make hacking evidence hold up better in court.

Modern Windows computers use the Windows Time Service and a protocol called Simple Network Time Protocol (SNTP, documented in IETF RFC 2030). The Windows Time Service can befed its time reading from an internal computer clock (the default) or use an external time source,such as an Internet NTP time server. Window workstations participating in a Windows 2000 or laterdomain and using the default Kerberos authentication must be time-synchronized within 5 minutes ofthe authenticating domain controller to complete a successful login.

In a Windows domain environment, the domain controller that fulfills the PDC Emulator role isthe centralized time sync server for the domain. The PDC Emulator computer should use a very accurate internal PC clock or should be configured to get its time from an external NTP server source(http://support.microsoft.com/kb/216734/EN-US). Several free NTP clients, including NetTime(http://nettime.sourceforge.net), are available for legacy Windows systems that do not have an NTP-compatible application.



http://support.microsoft.com/kb/216734/EN-US

http://nettime.sourceforge.net

Logging Security Events Logging should be done anywhere it can be done. Start by using the Windows event logs, and usethird-party tools as desired. All network devices in the path of data communications headed into andout of your network should have logging enabled — detailed logging when possible. You may havelogs from Windows, firewalls, IDS, routers, switches, gateways, antivirus software, and anything elsethat may track packets or network communications.

Determining Log Rotation and Permanence Logs should be collected and rotated frequently enough that data is not overwritten. It is importantthat logs be rotated on a schedule that balances accuracy and performance. Logs can quickly becomelarge. A compromised computer with full logging enabled can have daily logs that are tens ofmegabytes big.

Security events should be logged to a permanent write-once, read-many media source if it is possible that the data will ever be used in court. Courts often support the “best evidence” doctrine,which states that nearly anything (except evidence known as hearsay) can be used for evidence in acourt of law. However, evidence that is professionally collected and resistant to tampering will bemore convincing in court than evidence without the same protections. If you can prove that yourdata was collected in a time-synchronized environment, tracked through its chain of custody, and was difficult to manipulate after collection, you have a pretty good evidence trail. Thoughtful decision-making must accompany log file rotation and archiving.

Centralizing Data Collection It is the rare network that has only one log. Most have dozens or hundreds of logs. A setup thatrequires an administrator to check each log manually almost guarantees that the logs won’t bechecked routinely. Smart administrators collect as many security events as they can to a centralizedlocation. It is nearly impossible for one centralized data collection system to collect all events, but themore you can collect centrally, the better off you will be. Microsoft has several free tools; dozens ofthird-party applications also collect and prioritize Windows log files. The four we look at are theEvent Viewer Console, EventCombMT, the Log Parser, and the Microsoft Audit Collection System.

Event Viewer Console If you have Windows 2000 or later, you can use the Event Viewer MMC snap-in to view event logson the local machine and/or one or more remote machines. You can create an Event Viewer consolethat contains multiple computers’ event logs in one location, as shown in Figure 5-6.



Figure 5-6 Event Viewer snap-in console monitoring several computers

To view events remotely, you must have local administrator rights and you must have theRemote Registry and the Server services enabled on the remote machine. Although the Event Viewerconsole lets you view multiple computers’ event logs in a central location, each log and its events arestill separated.

EventCombMT Microsoft provides several ways to remotely collect multiple security event logs into a centralizeddatabase where they can be viewed, sorted, and prioritized at once. The oldest of these tools isEventCombMT (http://support.microsoft.com/default.aspx?scid=kb;en-us;824209&Product=winsvr2003).It lets you query multiple computer event logs and get the results in a common file. The file can beimported into SQL Server, Microsoft Excel, or another tool for analysis. EventCombMT works on Windows NT and later.

Although EventCombMT works well, it is not a real-time utility. Each time you want to collectdata, you must initiate an EventCombMT query. Running a query against multiple machines, or evenon a single machine with tens of thousands of records, can take a long time.



http://support.microsoft.com/default.aspx?scid=kb;en-us;824209&Product=winsvr2003

Log Parser Microsoft released a new tool called Log Parser in the IIS 6 Resource Kit (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=8cde4028-e247-45be-bab9-ac851fc166a4) that,although it is simply a rudimentary command-line tool, can extract data and events from a widerange of log sources. It does not require IIS 6 to work.

Log Parser uses SQL-like statements to query log file sources. Queries can be basic and extract allevents or pull just specific records. You can save data to SQL databases, CSV files, and in many otherformats. If you aren’t used to SQL queries, the complexity and exacting syntax can be a hurdle. Andlike EventCombMT, Log Parser is a batch process. You can learn more about LogParser athttp://www.logparser.com.

Microsoft Audit Collection System Microsoft’s newest addition to the log collection family is the Microsoft Audit Collection System (orMACS). MACS represents the future of Microsoft’s log collection tools. It is still in limited beta releaseand is not available to the general public. You can read more about MACS atwww.windowsboston.com/downloads/doc/MACS_beta_Overview.doc.

MACS is a real-time system that works only with Microsoft security event logs. Multiple computers’ security log files can be collected to a centralized SQL database. Each participating clientruns a MACS client service that communicates with the centralized server.

Microsoft also supports event log collection using SMS (http://www.microsoft.com/smserver/default.asp) and Microsoft Operations Manager (http://www.microsoft.com/mom/default.mspx),known as MOM.

Standardizing Terms Although setting up a central location for data may seem like a challenge, it is really the easy part.The hard part is a result of the fact that no two OSs or security devices collect and define data in thesame way, leading to a “Tower of Babel” situation. For example, competing antivirus scanners arenotorious for giving the same malware two different names. So, if you have log entries from two different antivirus platforms protecting your honeypot, one may report the SQL Slammer worm asSQL.Slammer.worm.A and another as SQL.Worm.32.

Even in a pure Windows environment, different events may be called different things or be handled differently between OS versions. For example, in Windows 2000, failed account logon eventsare logged to Event IDs 681 and 676. In Server 2003, they are logged to 680 and 672. In Windows2000, RDP and Terminal Server logons are considered interactive logons. In Windows XP and later,they are called Type 10 Logons instead (see Table 5-3 above). The different versions of Windowscontain many other auditing changes. There is no easy solution for this problem — administratorssimply must become familiar with the common Event IDs used by each Windows version.

Filtering Data Once all the data is collected, it needs to be sorted and prioritized. High-priority items should bebrought to the attention of the appropriate person, and low-priority messages should be filtered andsaved to a log file. The hard part is determining what is and isn’t high priority. Unfortunately, theWindows Security log does not come with built-in levels of criticality, like the other default logs have.And even if it did, a low-priority event to one administrator may be a high-priority event to another.



http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=8cde4028-e247-45be-bab9-ac851fc166a4

http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=8cde4028-e247-45be-bab9-ac851fc166a4

http://www.logparser.com

http://www.windowsboston.com/downloads/doc/MACS_beta_Overview.doc

http://www.microsoft.com/mom/default.mspx

http://www.microsoft.com/smserver/default.asp

http://www.microsoft.com/smserver/default.asp

The trick is to develop a customized set of priorities for your environment based upon measuredbaselines, evaluated risks, and expected attacks. You should develop several levels of priority andthen evaluate and sort all the different collected events into your priority levels.

Low-priority events should be simply recorded. High-priority events should be acted on immediately. However, never delete any security event log messages, because something innocuousmight end up being important information later. Sometimes, what didn’t happen at a particular time isas important as what did happen.

Many data collection systems also contain data filtering abilities. All of Microsoft’s event log collection tools contain query features that you can use to sort collected events. Even the EventViewer utility has simple query features. For example, Figure 5-7 shows the Event Viewer applicationfiltering all events (tens of thousands) except Event 682 (Successful Re-Connection to a Winstation),which shows successful RDP reconnections, including the login name used. A user could construct asimple filter that queries for a handful of high-priority events.

Figure 5-7 Event Viewer filtering successful logins

Most third-party event log collectors also have a query feature. A common query that could beconstructed in most data filters could collect all Warning and Audit Failure events.



Correlating Data Data correlation is the grouping of data into useful sets of information instead of relying on one datapoint. A simple example is noting whether you are dealing with a hacker who is attempting to logon to one computer several times using various guesses, or one who is scanning your entire networkfor any weakly protected resources. The latter type of attack will be successful more often than theformer.

Data correlation tools are just starting to make their debut. MOM (http://www.microsoft.com/mom/default.mspx) is Microsoft’s data correlation tool. It includes predefined event ID and alertthresholds. A new microcosm of vendors specializing in Security Event Management (SEM), alsoknown as Security Incident Management (SIM) is cropping up. SEM/SIM vendors perform event logmanagement tasks, as described in the preceding sections, and even merge vulnerability ratings, patchmanagement, and risk exposure into the cycle. Vendors such as ArcSight (http://www.arcsight.com),netForensics (http://www.netforensics.com), Computer Associates (http://www.ca.com), and IBM(http://www.ibm.com) are heavily investing in their software, hardware, and managed serviceSEM/SIM products. See InfoWorld magazine’s excellent summary article on SIM/SEM athttp://www.infoworld.com/infoworld/article/04/10/29/44FEbigsecure_1.html for more details.Microsoft is developing similar, robust solutions.

Extracting Useful Information After all this careful log planning, only the useful, critical, information should be culled and presentedfor action. For logged security events to provide you with useful information, they must be relevantto your environment. Relevancy in this case is a measure of how likely it is that a particular attackwill be successful in your environment.

For example, do you care if a hacker tried Unix exploits against your Windows Server 2003machines? Some system administrators do and some don’t. The last piece in the puzzle in event logmanagement is to make sure that only relevant critical events get passed to the administrator. Eventswith a low relevancy should be noted and logged but not forwarded to an administrator for action.

Setting up an Alerting System An event logging system must have a way of alerting appropriate people when a high-priority eventoccurs. Alert messages should be short, so that they can be sent to consoles, pagers, and cell phones,which are the preferred methods of receiving a high-priority alert. However, alert messages shouldalso include enough information to let the responder assess the situation.

At a minimum, an alert message should carry the following information:• Date and time of alert• Message text indicating identified threat• Priority• Location of threat

The following line shows a sample alert message:

07-04-03 01:03:04.2345 High priority; Slammer probe; worm; DMZ IIS 6.0 Server2;

Typically, the alert is sent to an Internet e-mail address that corresponds to an alphanumericpager or cell phone. Because sending messages via the Internet can sometimes be unreliable,



http://www.ibm.com

http://www.infoworld.com/infoworld/article/04/10/29/44FEbigsecure_1.html

http://www.netforensics.com

http://www.ca.com

http://www.arcsight.com



especially during a high-priority attack, many alert systems use dial-up modems that connect to a proprietary messaging service belonging to the pager or cell phone company.

Sending alerts via the console works only if you are on the local network when the alert is sent.Sending an alert via e-mail won’t mean much if you aren’t reading your e-mail that very second, andit will mean even less if it’s buried in hundreds of other e-mail messages.

Alerting is more of an art than it sounds. If you simply set up an alerting mechanism to go offeach time high-priority activity occurs, you could end up with a backlog of a hundred alerts in a fewminutes. The alerting system must be smart enough to alert you only once for each related event; thissetup is called alert throttling or message throttling. The idea is that after the system alerts you, itshould sit idle for a predetermined amount of time if further activity appears to be coming from thesame source and in the same priority level.

Also consider who should be alerted. If you are out of town or otherwise unavailable, whoshould respond in your place? You may even want to define response time guidelines according tothe threat level. Whatever your alerting mechanism is, above all else, it should be reliable.

Simple Windows Alerting Mechanisms In Windows, you can use the NET SEND command, Msg.exe, and many other programs to sendalerts. These programs can be used for sending short console messages across networks.

NET SEND has been around since at least Windows 95, but it may have been available in evenearlier Microsoft products. NET SEND is a subcommand under the larger umbrella functionality available with the Net.exe program. Although the NET command is usually used to map drive shares(such as NET USER X: \\fileserver\sharename) or list users (NET USERS), it can also be used to sendconsole messages. Each message arrives with a bell sound to alert any nearby users.

The Messenger service must be enabled on the computers involved. Because of potential spammessage harassment, the Messenger service is disabled by default in Windows Server 2003 and Windows XP Service Pack 2. NET SEND can send messages to a user, domain, workgroup, or IPaddress. Messages can contain up to 128 characters. NET SEND’s syntax is as follows:

NET SEND {<user> or /domain:<domain> or /users or <IPAddr>} <message>

The /domain parameter sends the supplied message to all users in the specified domain or workgroup. The /users option sends the message to all users with active connected sessions to thecomputer it is sent on. On Windows XP Service Pack 2, when sending to a single user, the /domainparameter must also be entered. The message can be plainly typed without any quotation marksunless you use non-text characters, such as a slash. Here are two NET SEND examples:

NET SEND admin There are failed logons on IIS 6 Server 3

NET SEND 192.168.1.56 “Disabled account has been enabled on FS3”

You can even incorporate external programs to extend the functionality of NET SEND. Forexample, with a bit of command-line coding and the free Showmbrs program, you can send mes-sages to a Windows group (http://www.jsiinc.com/SUBB/tip0700/rh0757.htm). Other monitoring toolsoften use NET SEND as a quick and easy way to alert the administrator to activity in the honeypot,although it does not scale well over routed networks.



http://www.jsiinc.com/SUBB/tip0700/rh0757.htm

NoteWindows 9x computers need to run Winpopup.exe to accept NET SEND messages.

Windows Event Triggers Windows XP and Server 2003 even allow the NET SEND command to be triggered off a local orremote Windows event log message. The very useful and powerful Eventtriggers.exe program letsyou create, delete, list, and query trigger events, as they are called (see Table 5-7 for syntax). Oncecreated, trigger events are active until deleted, even surviving a system reboot.

The EVENTTRIGGERS command syntax is as follows:

EVENTTRIGGERS /Create [/S system [/U username [/P [password]]]] /TR triggername /TK

taskname [/D description] [/L log] { [/EID id] [/T type] [/SO source] } [/RU username

[/RP password]]

Type EVENTTRIGGERS /? or EVENTTRIGGERS /Create /? to see the full syntax options.

Table 5-7 EVENTTRIGGERS /Create options

Parameter Variable Description /S System Specifies the remote system to connect to. /U [domain\]user Specifies the user context under which the command should execute. /P [password] Specifies the password for the given user context; prompts for input if omitted. /TR Triggername Specifies a friendly name to associate with the event trigger. /L Log Specifies the NT event log(s) to monitor events from. Valid types include Application,

System, Security, DNS Server Log, and Directory Log. The wildcard (*) may be used,and the default value is *.

/EID Id Specifies a specific event ID the event trigger should monitor for. /T Type Specifies an event type that the trigger should monitor for. Valid values include

ERROR, INFORMATION, WARNING, SUCCESSAUDIT, and FAILUREAUDIT. /SO Source Specifies a specific event source the event trigger should monitor for. /D Description Specifies the description of the event trigger. /TK Taskname Specifies the task to execute when the event trigger conditions are met. /RU Username Specifies the user account (user context) under which the task runs. For the system

account, the value must be “”. /RP Password Specifies the password for the user. To prompt for the password, the value must be

either * or none. The password is not needed for the SYSTEM account.

You can create as many trigger events as you like and display them using the EVENTTRIGGERS/query /v command.

Trigger events can be used along with the NET SEND command for alerting purposes. Forexample, the following EVENTTRIGGERS command alerts the administrator if an invalid password isused during a login:

EVENTTRIGGERS.exe /create /l security /eid 529 /tr IncorrectLogon /tk “NET SEND

administrator Incorrect Logon on FileServer1”

n



This trigger event, called IncorrectLogon, triggers event ID 529 (Bad Password or User AccountName) and sends a message to the administrator.

The next example triggers an alert if the security log is cleared:

Eventtriggers.exe /create /l security /eid 517 /tr LogCleared /tk “Net Send

administrator IIS Log Cleared”

The EVENTTRIGGERS command is very versatile. See http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/eventtriggers.mspx for more details.

Of course, Microsoft’s MOM and SMS are perfect tools for event log alerting.

Other Third-Party Alert Utilities You can use a plethora of other utilities to send alerts from your honeypot or monitoring system.One of the most popular choices is a public domain utility called Blat (http://www.blat.net). Blat is avery small SMTP client that allows messages and files to be sent using the SMTP protocol to port 25(or any other port number). It uses multiple sender profiles and retries if the receiving computer isbusy. A DLL version can be directly installed and renamed to send messages directly from the honeypot. You can send messages with predefined subjects, messages, and attached files. It’s perfectfor sending alerts to e-mail systems or small-form computers and PDAs. Scripts and programs thatneed more functions than NET SEND can provide commonly use Blat.

Other third-party message sending programs include Net Send Command Line and Net Send Lite(http://www.rjlsoftware.com), Febooti Command Line (http://www.febooti.com), and WinMessenger(http://www.vypress.com). ServerSentry (http://www.datatribe.net) also monitors Windows event logsand services and sends trigger messages.

As you have learned, an event log management system entails more than simply turning onauditing and collecting event messages.

Auditing Best Practices Audit policy is best implemented with a little foresight and research. Here are some best practices tofollow:

• Create an audit plan before turning on auditing• Decide what events you will audit and where• Decide how often logs will be reviewed and by whom• Configure event log settings• Configure using Domain Controller’s policy and Domain policy• Implement an audit log management tool• Collect and archive audit logs and critical events across your organization

Summary Chapter 5 discussed event auditing as a primary tool in detecting attempted intrusions into your Win-dows system. If auditing is appropriately configured, it can capture critical information about mostunauthorized events.

Chapter 6 will consider two-factor authentication and smart cards.



http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/eventtriggers.mspx

http://www.rjlsoftware.com

http://www.febooti.com

http://www.datatribe.net

http://www.vypress.com

http://www.blat.net

129


Chapter 6:

Using Smart Cards and Two-Factor AuthenticationUsing passwords or passphrases to control access to your network provides fairly secure authentica-tion when you can guarantee that the passwords are both complex and protected. Unfortunately, it’s difficult to enforce the use of complex passwords. Even though Windows Active Directory canrequire complex passwords, the level of “complexity” it requires isn’t necessarily enough. As shownby Dr. Jesper M. Johansson, quoted in Chapter 3, users’ “complex” passwords aren’t all that difficultto guess. The password length requirement is also difficult to enforce because the largest minimumsize you can require in Windows is 14 characters, although this limitation will be removed in futureWindows versions. And in today’s world of spybots, internet scanning worms, and identity theft, malware can simply install a keystroke logging trojan to record a user’s password, no matter howcomplex and random it is. Sometimes passwords alone aren’t enough.

When they aren’t, the most popular answer is to use a two-factor solution – that is, a combina-tion of two methods of protection, such as an authentication token and password or PIN. The conventional wisdom is that a hacker may be able to capture either the token or the password but is not as likely to acquire both at the same time. Many security experts predict that two-factor authentication, led by the use of smart cards, cryptographic tokens, and USB keys, will become theauthentication mechanism of choice. Some laptops and PC keyboards now have built-in smart cardreaders, and this feature is likely to become standard in the future.

In this chapter, we look at the basics of using two-factor authentication and smart cards and howto use smart cards in a Windows environment.

Two-Factor Authentication and Smart Cards: The Basics A security token is a physical device that only the legitimate user possesses. Tokens can be nearlyany unique identification device, including a USB key, cryptographic number generators (like thepopular RSA SecureID device), or a smart card. A smart card is a digital device encoded with information that uniquely identifies the intended holder. Smart cards often hold digital certificates(trusted third-party authenticated public keys) and private keys, but they also can hold encryptedpasswords, other identifying information, and application data.

Two-Factor Authentication Two-factor authentication describes an authentication or identification event that requires two of thethree types of authentication discussed in Chapter 2:

• Something only the security principal knows (e.g., a password)• Something only the security principal has (e.g., a smart card)• Something only the security principal is (e.g., a biometric identifier)



Two-factor authentication isn’t satisfied by two of the same type of factor. For example, requiringa user to input two different passwords isn’t two-factor authentication. However, supplying thesecond password in the form of a digital certificate stored on a token device that is synchronized withback-end authentication database does meet the requirement.

Smart Cards The most popular form of two-factor authentication uses a smart card. Smart cards were first used in the 1970s, and more than one billion smart cards are used today. European countries lead the way in smart card utilization. For example, in Germany, a smart card is required to access publichealthcare. Smart card technology is also central to the national healthcare programs of France, Austria, Belgium, the Czech Republic, and Japan. Since 2002, the European Union has passed severalproposals that either mandate smart card use or that can be facilitated by using smart cards. By 2007, every citizen of Belgium will use a smart card as a national ID, and similar programs havebeen proposed in the U.S. After the events of September 11, 2001, many U.S immigration and port-of-entry programs are starting to use smart cards and biometric identification.

In the corporate environment, smart cards and tokens are becoming more popular because passwords alone aren’t reliable and simply do not provide enough security. Password-sniffing keyloggers and trojans capture users’ passwords; phishing emails look surprisingly similar to the websites they fake. Applications and companies that need high security and validation are turning to two-factor authentication.

Why a Smart Card? A common question is why smart cards are becoming more popular than earlier token devices, suchas credit cards with PINs. Smart cards offer many advantages. First, they almost always contain uniqueidentifying information in addition to other data unique to a particular application, such as banking,e-commerce, or long-distance telephone information.

Also, smart cards offer more data storage and protection than the traditional low-volume magnetic stripe used on most credit cards today. Any magnetic stripe reader can read the data on anymagnetic stripe, and any device that writes magnetic stripes can change or erase the data. Securingdata integrity is limited to running checksums on data blocks and trying to obscure data areas. Incomparison, a smart card grants access to its data only to pre-approved applications and processes; itcan also enforce strong cryptographic processes. A malicious program or electrostatic discharge candamage or change the data storage on a smart card; the card may be ruined, but at least the data,and therefore the card, won’t be accepted as valid.

In general, a smart card offers additional security to the carrier and vendors relying on the protected data. A credit card number typed on a keyboard can be captured and used in an unauthorized way, whereas a smart card or similar token must be physically acquired. Furthermore, a smart card is often used in conjunction with another security factor, such as a PIN. Typing thewrong PIN too many times can disable the smart card, either permanently or until the administratorre-enables it.

Chapter 6 Using Smart Cards and Two-Factor Authentication 131


NoteEven though a smart card or other token must be physically present to work, that fact doesn’tmean that all physical authentication devices are invincible to authentication hacking. Forexample, after the smart card or token is inserted and the user or transaction is authenticated,a Trojan horse or man-in-the-middle program could still manipulate intercepted transactiondata.

One of the primary uses for a smart card is to store and secure value, either in the form of electronic money or some sort of earned credit. Because the value stored on the card can be cryptographically protected, even a malicious inspection of the card will not allow the card’s data tobe manipulated. Some cell phones carry smart cards that give users a particular time window beforethe phone stops working. Several vendors have micro-payment schemes in which a smart card holdsa larger sum of value purchased or earned ahead of its use. As the holder spends the money, thestored value is decreased. More than 100 countries, including France and Brazil, have replaced coin-based public telephones with phones that accept smart cards.

Smart Card Physical Makeup Smart cards are made of plastic and often look like a credit card, although they are sometimessmaller. Each card contains

• A main memory storage area• A processor chip• An operating system• Connectors

The memory storage area is usually an Electrically Erasable Programmable Read-Only Memory(EEPROM) chip. EEPROMs can have their content changed by writers and maintain the stored dataeven when no electrical current is applied, unlike normal PC RAM. Memory storage space normallyranges from 1k to 64k of data, and capacity is increasing every year. The memory is often brokeninto separate areas, with a controlling file system. Each area has a certain number of files, and only acertain number and type of application can access each area. In this way, applications that need moresecurity can store confidential data in protected memory spaces, while less-critical data is stored inareas that are more open to inspection.

Microprocessor-based smart cards usually contain an 8-, a 16-, or a 32-bit processor, along withoptional additional memory storage, numeric processors, and cryptographic features. The processorhas its own RAM, although it is typically smaller than the main memory storage area (for example,3k). Each vendor develops its own operating system (OS) for the smart card; usually, these OSs areresistant to tampering and have very limited features, which is good for security.

Separate numeric processors speed up the card’s cryptographic processes, which are usuallyhard-coded into the smart card. A card supports a limited set of cryptographic algorithms and keysizes. For example, Athena’s ASECard for Windows (http://www.athena-scs.com/product.asp?pid=22)supports 1024- or 2048-bit RSA asymmetric keys, 3DES or DES symmetric keys, and SHA-1 or MD5hashes. Other cards support AES, DESX, and other key sizes.

http://www.athena-scs.com/product.asp?pid=22

Contact vs. Contactless Cards One of the primary distinctions between types of smart cards is whether they must make physicalcontact with a reader to be used. On a contact smart card, a set of gold-plated contacts is embeddedon the surface of the card; they connect to the memory storage area and processor. Usually the contact area is about ? inch on a side and is located on one face of the plastic card, oriented to oneend (see Figure 6-1).

Figure 6-1 Contact smart cards

The contact area contains eight pins (four on each end across from each other) to transmit andreceive data and commands.

The memory and processor are located directly beneath the contact area. For data to be transmitted, the contact end must be correctly aligned in the reader. The reader device usually provides power through the interface, which energizes the card’s memory and CPU. Data is thenread, written, modified, or deleted. The card and the associated application can also exchange commands. Often, all these processes occur in fractions of a second.

A contactless card, sometimes called a radio frequency card or proximity card, has an antennaembedded in the plastic. The antenna can be a thin wire or even a line of conductive ink that is connected to the processor and memory. These cards are powered by wireless induction technology;that is, the cards become active and readable when an appropriate electrical current is introducedinto their field of electronics by the reader’s antenna. Data and commands are sent between the card



and reader device as long as the power induction remains within acceptable parameters – usuallycentimeters, although vendors are developing readers and cards that work at greater distances.

Some security experts are wary of contactless cards because they may be read or manipulatedmalicious by unseen parties. Some smart cards contain both contact and contactless interfaces and aretherefore known as hybrid, combi, or dual-interface cards.

NoteA similar technology, radio frequency identification (RFID), is often used to identify goods in asupply chain or to track cars passing through a toll booth. RFID technology is not the same assmart card technology. RFID strips usually do not contain writable storage and are notcryptographically protected; sometimes they’re called “smart bar codes.” However, self-powered RFID applications that contain processing units are being developed, which blursthe distinction between them and smart cards.

Smart Card Standards: Hardware Many standards exist for smart cards, with each standard each defining a different layer: hardware,interface, software, or business use. The hardware standards, which define the physical characteristicsof a smart card, its connections, and layout, are followed more closely than the implementation standards.

The ISO/IEC 7816 (http://www.cyberd.co.uk/support/technotes/smartcards.htm orhttp://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37990&ICS1=35&ICS2=240&ICS3=15&scopelist=CATALOGUE) series of standards define the physical characteristics of contact smart cards, including size, shape, acceptable x-ray exposure levels, height of contacts, processor pin placement, card strength, damage resistance, electrical resistance, magnetic field resis-tance, static electricity resistance, and bending resistance. Contactless smart cards are governed by theISO/IEC 14443 and 15693 standards (http://www.jayacard.org/14443). In the 14443 standard, readerswork up to a maximum distance of 10 cm; the 15963 standard allows communications at distancesreaching to 50 cm.

Data exchange rates normally range from 9.6k to 424k per second for both contact-based andcontactless cards. Although this number may seem small, the rate isn’t bad, considering that slowerrates are more reliable and only a small amount of data is transmitted. Still, higher data exchangerates are under development and will become standard over the next few years.

Smart cards usually contain pre-assigned numbers that identify the vendor, the specific card, andthe allowed applications. The first and last numbers ensure that a particular card is used only by itsassociated applications. The card-specific number attaches a particular smart card to a particular userand applications. These numbers also help prevent “collisions,” when more than one smart card ispresented to the same application at the same time, as can happen often in a contactless environ-ment. Also, a single card cannot be tied to multiple applications without explicit authorization by theapplication developer, which allows the use of smart cards to be strictly controlled.

n



http://www.cyberd.co.uk/support/technotes/smartcards.htm

http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=37990&ICS1=35&ICS2=240&ICS3=15&scopelist=CATALOGUE

http://www.jayacard.org/14443

Smart Card Standards: Interfaces Many standards for smart card interfaces, which allow applications to interact with either the smartcard or the reader and writer devices, are in use today because particular applications require different attributes. Some of the software standards for smart cards define the interface layer, andothers are designed to be placed on top of the interface and be application-specific.

The Personal Computer/Smart Card Specification Microsoft, along with IBM, Bull, and Schlumberger, developed one of the most popular smart card computer standards, the Personal Computer/Smart Card specification (http://www.pcscworkgroup.com). The PC/SC specification builds on the ISO 7816 standard and adds “low-leveldevice interfaces and device-independent application APIs as well as resource management, to allowmultiple applications to share smart card devices attached to a system.” Although it is platform independent, the PC/SC specification v.1.2 is supported by Windows. Other complementary and competing standards include the OpenCard Framework (http://www.opencard.org). This standard isessentially Java-based.

Some smart card applications work with both standards, but you should check to be sure thanany smart card you use, and its associated applications, supports the same standard. A smart card thatclaims to be compatible with Microsoft Windows should support the PC/SC standard.

Different industries, such as banking and finance, have their own standards – for example, the ISO TC 68 standard (http://www.iso.org/iso/en/stdsdevelopment/tclist/TechnicalCommitteeDetailPage.TechnicalCommitteeDetail?TC=68). These standards define features that are layered on topof the physical and software layers. For example, EMV (Europay, MasterCard, Visa) is a global standard for smart card/terminal interoperability (http://www.emvco.com), used with credit cards. Themajor card associations set a January 2005 deadline for Europe-wide migration to EMV cards. ThePC/SC specification supports the EMV standards.

The National Institute of Standards and Technology (NIST) document “Security Requirements forCryptographic Modules” defines acceptable physical security for a smart card; this standard is knownas FIPS 140-1 (http://csrc.nist.gov/publications/fips). Windows supports many of the FIPS standardsusing a group policy object setting called System Cryptography: Use FIPS compliant algorithms forencryption, hashing, and signing (see Figure 6-2). In this case the 3DES, RSA, and SHA-1 cryptographic functions would be used.

Figure 6-2 Group Policy setting for FIPS compliance



http://www.pcscworkgroup.com

http://www.opencard.org

http://www.iso.org/iso/en/stdsdevelopment/tclist/TechnicalCommitteeDetailPage.TechnicalCommitteeDetail?TC=68

http://www.emvco.com

http://csrc.nist.gov/publications/fips

Programmable smart cards, which allow for custom-developed and -implemented data formatsand applications, are available, but most companies are sticking to better-supported standards, even ifthe companies program their own cards and applications. Other application-specific standards definecontrol commands, such as “waking up” the card, initiating authentication, exchanging crypto keys,formatting memory storage areas, retrieving and writing files, and deleting data.

Smart Card Applications Smart cards can supplement traditional computer logons, SSL, and other traditional one-factor e-commerce authentication schemes. In a Windows network, smart cards can be mandated for end-user logons – either for everyday use or for use with privileged accounts. You can require asmart card for initial logon and for ongoing computer user. You can even instruct Windows to log offa user immediately if the smart card is removed from the reader device.

You can deploy smart cards without employees even realizing that they are using smart cardtechnology. For example, Microsoft Certificate Services can issue digital certificates to every employee;you can require employees to use these certificates to enter a building or to access an owned computer system, perhaps through campus badges. To the employee, the badge might seem like anormal picture identification badge. But that employee’s personalized access to specific campus locations can be coded into the badge. Contactless readers can also “invisibly” give the employeeaccess to specific locations or computer systems. Smart cards can even be used to track employeelocations using integrated GPS technology.

Other examples of applications for smart card technology include• Employees can be required to use smart cards to log on to their desktop computer, laptop, or

PDA. If they remove the smart card, the computer is automatically locked. In any of thesecases, the computer must be fitted with a reader device and Windows must be appropriatelyconfigured.

• Administrators can be required to use smart cards to access servers. • Web administrators can be required to use smart cards to access Internet-facing web servers to

perform administrative duties.• Users can be required, using smart card redirection, to use smart cards to access Terminal

Server applications.• Smart cards can be used in PC-based time-card tracking systems. Using smart cards would

make it harder co-workers to clock in or out for another employee.

Perhaps the most ambitious U.S smart card effort is at the Department of Defense (DoD). TheDoD requires that every active duty military person, reservist, and civilian contractor be identified and authenticated by a smart card before accessing their facilities and computer systems(http://www.dod.mil/nii/ebpublic/dod_sc_prog.htm). The massive program has been an over-whelming success and has generated more than a few “lessons learned” along the way.

It isn’t only the government that is utilizing two-factor authentication. Many banks require smartcard or token authentication to conduct online money transfers. Hospitals require two-factor authentication to access patient data remotely.

Popular online services, such as America Online, now offer two-factor authentication solutions.AOL’s offering is called Passcode (http://help.channels.aol.com/article.adp?catId=6&sCId=415&sSCId=4090&articleId=217623). To use Passcode, AOL members buy an AOL Passcode token (which is a



http://www.dod.mil/nii/ebpublic/dod_sc_prog.htm

http://help.channels.aol.com/article.adp?catId=6&sCId=415&sSCId=4090&articleId=217623

re-branded RSA Security token) for $9.95. Then the member can associate one or more AOL accountswith the Passcode program, which requires an additional fee starting at $1.95 per month. When theaccount is associated with Passcode, the 6-character Passcode-generated number must be typed alongwith the normal logon information. Before the first use, the Passcode’s unique 8-digit serial number isinput to synchronize the Passcode number generating sequence with the backend authenticationserver. After the Passcode is enabled, no one can logon to an AOL service with a secured accountwithout also inputting the new Passcode number.

Many security experts believe that two-factor authentication will surpass password-only authenti-cation long before end-users will memorize and type long, random passwords or passphrases. Thisargument is gaining validity as default two-factor authentication is becoming required by more busi-nesses and as cheap biometric and token products become more pervasive. If you are a networkadministrator, you’ll probably be dealing with two-factor authentication in the near future. Before weget to the specifics of implementing a smart card solution in a Windows network, it helps to under-stand the larger picture.

Implementing a Two-Factor System No matter what two-factor system you implement, you need to decide many issues, including

• Proving the business value of your two-factor project to senior management• Creating a plan for the use of smart card or token authentication systems• Selecting a vendor for your hardware and software solutions• Creating a deployment plan• Creating a plan for ongoing support and operations

Here are some issues relating to those decisions.

Identify the Processes that Require Two-Factor Authentication A two-factor system can help your organization meet numerous sensitive business requirements. Youcan use tokens or smart cards for any or all of the following processes:

Cell Phone Applications One of the most popular uses of smart cards is with Global System for Mobile Communication (GSM)cellular phone networks. Subscriber Information Module (SIM) cards, which are nothing more than smartcards, allow GSM phone users to change cell phone information, including data such as the subscriber’spersonal information, phone settings, phone number, personal security key, and other data necessary forthe handset to function, on the fly. Each SIM is tied to a particular subscription network, but the cardallows users to switch phones without losing their phone number, other identifying information, orsecurity protection (by moving the SIM). Conversely, a person can use the same phone, switching phonenumbers and security codes, as easily as using a new SIM card. This latter method has been used byspies, terrorists, and others seeking more secrecy.



• Interactive user logons, including remote access• Administrator logons• Ongoing computer use (for example, if the smart card is removed, the user is immediately

logged off)• Third-party authentication across the Internet• Signing and encrypting email

When smart cards are involved, Windows Server 2003 can help automate these requirements andprocesses.

Consider: Smart Card or Token? One of the most obvious priorities in any two-factor authentication project is to pick the type ofdevice you will rely on to for the additional authentication factor. Setting aside a discussion of biometrics for the purposes of this chapter, your decision will usually be between smart cards andsecurity tokens.

Using Smart Cards Smart cards are very popular and inexpensive. If treated properly, they can last a long time. One ofthe biggest benefits of using smart cards is that they can easily integrate into an existing or futurepublic key infrastructure (PKI) solution. If you plan to require digital certificates to sign or encryptcontent, smart cards offer a convenient way to store a user’s credentials (although Active Directorymapping is even more convenient). Smart cards, in the form of badges or employee IDs, can be distributed and used without the words “smart card” even being mentioned — not to keep the use of smart cards secret, but to deploy a new level of security without introducing new concepts andterminology to users. Teaching users how to use smart cards is fairly easy; most users are comfortablewith them from using credit and debit cards to pay for everyday transactions.

The downsides of smart cards, compared to security tokens, are that their storage capacity isslightly more limited and they are limited in their ability to be used with applications other than theones they were originally targeted to. Otherwise, smart cards are a good, reliable choice. Becausethey come in the form of a card and can be printed as credit cards or ID badges, they are an easychoice for many applications.

Probably less than a dozen smart card vendors (those who make their own cards and OSs) areavailable to choose from. They include Athena (http://www.athena-scs.com), Axalto(http://www.axalto.com), Gemplus (http://www.gemplus.com), and Bull (http://www.bull.com). Associated with these vendors are hundreds of available applications. Leading smart card vendorswith Windows-specific products are listed at the end of this chapter. Additional smart card vendorsand information can be obtained at the Smart Card Alliance web site(http://www.smartcardalliance.org).

Using Security Tokens Security tokens are usually more expensive to purchase, but considering the total cost of ownership,they may be competitive with smart cards. Security tokens offer slightly more storage capacities, capabilities, and security. The two most popular types of tokens are USB keys and dynamic passwordgenerators.



http://www.athena-scs.com

http://www.axalto.com

http://www.gemplus.com

http://www.bull.com

http://www.smartcardalliance.org

USB keys look like a USB memory card (or “thumb drive”) and act much like a smart card does,but they have more storage. As security tokens, USB keys must be inserted into the workstation tolog on or to remain logged in. USB keys are used for applications for which a smart card readerhasn’t been available, such as laptop logon authentication (although some laptops are now comingwith built-in smart card readers).

Dynamic password generators, like RSA’s SecureID solution (http://www.rsasecurity.com/node.asp?id=1157), generate new passwords regularly, usually every 60 seconds. The password that is generated is synchronized with the back-end authentication server. To establish the synchronization,each device is given a unique serial number that is input into the back-end database. When given theunique serial number, the backend database generates the same password as the remote securitytoken. A user logging on inputs a logon name, a PIN (if required), and the number generated by thesecurity token device (see Figure 6-3). Time synchronization is of the utmost importance, of course.

Figure 6-3 Example security token

The best feature of dynamic password generators is that even if one password sequence is compromised, the next one won’t be. It is considered non-trivial to predict the next dynamically generated password. Password generators come as close to the ultimate cryptography goal of “one-time” passwords as can be implemented in a user-friendly and reliable way.

Disadvantages include the additional effort required for initial synchronization, more complex use(end-users will incorrectly type the dynamic password more often than they will a simple password),time synchronization issues (users will learn not to use dynamic passwords nearing the end of theirscheduled time duration), and the need for customized front-end and back-end applications. Microsoft Windows does not directly support any tokens other than smart cards without additionalthird party software, but more than 100 vendors offer Windows-compatible solutions. And the primary disadvantage, which is the same as with any physical authentication device: if you leave it athome, you can’t log on.

RSA (http://www.rsasecurity.com), Authenex (http://www.authenex.com), Aladdin(http://www.aladdin.com/etoken), Verisign (http://www.verisign.com/products-services/security-services/unified-authentication/usb-tokens/index.html), and ActivCard (http://www.activcard.com) are a fewof the vendors offering security tokens. RSA’s SecureID token has been around for nearly a decadeand is by far the market leader, although other alternatives are gaining market acceptance. Many vendors that offer smart cards also offer security token devices, and vice versa.



http://www.rsasecurity.com/node.asp?id=1157

http://www.rsasecurity.com

http://www.authenex.com

http://www.aladdin.com/etoken

http://www.verisign.com/products-services/security-services/unified-authentication/usb-tokens/index.html

http://www.verisign.com/products-services/security-services/unified-authentication/usb-tokens/index.html

http://www.activcard.com

Another growing trend is for three-factor security systems, adding biometrics to the mix. Althoughthree-factor authentication can increase security, it also adds complexity. Biometrics can be the mostaccurate of all the security solutions; after all, only you have your particular retina pattern. However,biometrics can be faked (fingerprint scanners have been bypassed using gummy-bear-type candy)and are prone to false-negative events. You can see this last point in action — I watch people withfingerprint-scanning PDAs swipe their fingerprint over and over before they are given access; I alsosee people at a retinal scanner open their eye as wide as they can and continually adjust their headposition until the scanner accepts their retina print. Lastly, biometric images have larger storagerequirements, compared to their other authentication peers. This means a lot of storage space isneeded in the authentication database, and the images can take longer to send over the network ifthey’re not stored locally. But even with those disadvantages, three-factor security is a requirement formany environments.

Choose the Correct Token or Smart Card You need to choose a security token or smart card that fulfills the application and physical requirements of the project. First, you must choose a solution that supports the cryptographic keys,sizes, and algorithms you want to use. For example, most smart cards support DES and 3DES symmetric ciphers, but only a smaller subset supports the AES standard. Do you need to care? Yes –AES has replaced DES as the government’s recommended symmetric cipher standard. Standard 56-bitDES, although secure, is now considered breakable, even though it still takes an enormous amount ofeffort for most intruders.

Note3DES is not an official government supported standard, but its 168-bit encryption protection isstill widely used.

Consider the physical aspects of the security device you need – how the token or smart cardworks. A smart card can simply be inserted into a reader, while a token usually requires a user toread information from it and input that information into the system. Which method is more compatible with your environment? Tokens that require user input are more susceptible to user errorsand synchronization issues, but they don’t require external readers. If you do need a reader, does thedevice come in the correct physical format; that is, serial port vs. USB vs. PCMCIA? Smart card andtoken readers can be installed externally, installed internally, installed in available drive bays, or integrated into other input devices, such as keyboards. How many times can the token or smart cardbe used or written to – a measurement known as cycle time or life expectancy? How user-friendly isthe card or token during setup, use, and maintenance? How much physical memory does the devicehave? You may require large amounts of memory to store multiple digital certificates, keys, or application data.

How easy is it to obtain more smart cards or tokens? Slow production of your chosen device canimpede deployment and operations. I’ve seen companies that have run out of security tokens or thathave broken equipment, which has meant that large numbers of new employees or vendors areissued temporary (less secure) badges. If these problems occur frequently, the total security of thesystem is undermined. Get service level guarantees from the vendor for response times and inventory.

n



Purchase back-up equipment that is stored in a secure location. And before you choose any vendor’ssolution, thoroughly test the software and hardware involved for both deployment and ongoing use.Even in limited testing, you should begin to get a feel for the durability of the hardware, software,and tokens.

Weigh Costs Two-factor authentication projects are not without cost and effort, even if you’re using inexpensivesmart cards and Microsoft Windows’ built-in support. Total cost of ownership can be measured inthree phases:

• Initial acquisition costs• Deployment costs• Ongoing operating and support costs

The cost of a two-factor authentication project must offset the potential risks and losses yourcompany can incur from having a less-secure system. Refer to Microsoft resources (see OtherResources, below) or a vendor help to justify the cost of projects.

Define Service Level Requirements Before you deploy a token or smart card program, establish service level agreements to help your ITorganization align performance with the company objectives in areas such as reliability, responsetimes, and support procedures. For example, you need to define service level standards for

• The types of identification required to obtain a smart card or token. You might choose torequire a specific type of personal ID, such as an employee badge, driver’s license, or otherphoto ID. Or you can require an administrative form signed by an authorized supervisor.

• How users can obtain replacement cards and how old cards are decommissioned.• Special classes of employees, such as executives or roaming employees, which might mean

unique guarantees. Define whether certain classes of employees require different service levelagreements.

• Acceptable time required for users to log on. It is best to ensure that the number of steps andthe time it takes to log on with smart cards or tokens are comparable to the steps and time ittakes to log on with conventional passwords.

• Acceptable logon times for remote access users. Remote access logon times are more vulnerable to degradations in network performance than local network connections, especiallyif users have slow dial-up access connections. You might need to upgrade your remote accessconfiguration to ensure acceptable logon times for remote users.

• Remote access exceptions. The computer configurations of some users might not be compatible with smart cards or tokens, and remote users might lose or forget their authentication device. Identify the circumstances, if any, in which remote users are givenremote access without using a smart card or token.

• The number of unsuccessful password or PIN entries allowed. Two-factor authenticationrequires using a regular password, PIN, or biometric inspection in conjunction with the smartcard or token. Do not allow an unlimited number of attempts to gain access; three or fourattempts should be generally adequate. You can minimize support costs while still frustrating



password guessers or intruders by configuring the Account Lockout feature to re-enable lockedaccounts after some small period of time, such as one minute.

• Service guarantees to users who cannot use their smart cards or tokens because of loss, damage, or blocking. Defining these limits helps you establish user expectations and supportprocedures. The guarantees should include - Establishing when and how users can regain access to the network. - Determining whether to restrict these users’ future access to the network to certain areas or

allow them access to any areas of the network that were previously accessible to them.

Document your service level agreement. You will need to apply these standards in your smartcard or security token operations plan, test them in your lab and pilot deployments, communicatethem to help desk personnel and to your users, and include them in your support and maintenanceplan.

Ensure OS Support Is the software Windows-compatible? In any token or smart card solution, the hardware must be supported by the operating system unless you’re installing third-party drivers, and the OS must support the authentication type unless you’re using a third-party authentication solution. MicrosoftWindows Server 2003 and XP Pro support most smart cards without additional software beyond thesmart card reader/writer driver and interface.

Ensure Software Availability You must have software to support two-factor authentication. Microsoft Certificate Services can generate smart card certificates. Active Directory lets you enable or require smart cards to log on.Windows Server 2003 allows smart card redirection, which requires smart cards to log on to remoteadministrative sessions. You need vendor-specific software to support the specific token or smart cardreader/writer devices.

Select a Certification Authority Most smart card solutions require access to a Certification Authority (CA), and you can choose to usean external trusted CA or Microsoft Certificate Services. Windows servers have had Microsoft Certificate Services available since Windows NT 4.0 Server Option Pack. Windows Server 2000 provided a substantially improved CA, and Windows Server 2003 raised the bar even more. If yourtwo-factor solution requires digital certificates, Microsoft’s Certificate Services can handle most needswithout additional software costs.

NotePublic digital certificates (that is, certificates readily accepted by computers outside the localcomputing environment) require a common third-party trusted root certificate authority, suchas Verisign.

n



Select Smart Card/Token Hardware Devices To use two-factor authentication, you must either use a device writer to create new tokens or rely onan external vendor. Smart card devices are often combination readers and writers, with administrativefunctions controlled by their software. If you use a cryptographic token, like RSA’s SecureID(http://www.rsasecurity.com/node.asp?id=1157), you need to access (either locally or remotely) acryptographic synchronization server to synchronize the device’s computations with the back-endauthentication server database.

Select a Back-end Authentication Database Even though the smart card or token holds the user’s credentials, you still need a secure back-endauthentication database to evaluate the authentication event. In Windows, user credentials are storedin SAM or Active Directory databases (covered in detail in Chapter 3). Smart Card authentication projects can use Windows as the sole authentication database, although administrators should stillfollow the recommendations at the end of Chapter 3.

If your authentication solution requires a third-party authentication database, make sure it ishighly secure, protected, and accessible to participating users. Unfortunately, even some authentica-tion solutions store user credentials in plain text in their proprietary back-end databases.

Set up Auditing The process of creating, deploying, and recovering security tokens must be tracked. If the number ofdeployed devices cannot be adequately audited or accounted for (there will always be lost devicesthat need to be revoked), the security of the whole system is undermined. Additionally, you need tobe able to audit the success or failure of authentication events. Normally, successful and failed logonsare written to the Windows security log, if Windows authentication is used. Third-party applicationssometimes write to their own log and sometimes to either the Application or Security log. Eventsinvolving Microsoft Certificate Services are also tracked within the Certificate Services application.Effective, reliable maintenance and auditing must be confirmed to document assurance and compliance.

Staff Your Operation Before you deploy two-factor authentication, you must decide what personnel you’ll need. WindowsServer 2003 significantly eases the cost of administration by offering auto-enrollment and auto-approval capabilities, although smart cards are often issued through centralized smart card enrollmentstations (see below). Still, you need employees to

• Lead two-factor authentication project from beginning to implementation• Evaluate vendor alternatives and select the winner• Create and implement a delivery plan• Develop and update security policies to include token use• Educate management and employees on new token requirements• Distribute tokens or smart cards• Replace lost or damaged tokens or smart cards• Audit the efficiency and compliance of the system on an ongoing basis



http://www.rsasecurity.com/node.asp?id=1157

Will the two-factor authentication plan be implemented solely by IT or will it require otherdepartments as well? Successful implementations often use the company’s existing security or humanresources department as places to deploy the new system. No matter what the solution is, personnelneed to be trained to operate and maintain the system.

Issues in Two-Factor Systems As great as two-factor authentication is, you need to consider some possible issues before you imple-ment it. The most obvious issue is what to do when the smart card or token fails. Because smartcards and tokens are physical devices, they are susceptible to external forces and physical damage.

For example, if your computer’s USB connection breaks, it can’t use a USB-attached reader oraccept a USB security token. I saw a user struggling and wiggling his USB token device up anddown in a failed attempt to get his laptop’s USB port to accept his token. He was out in the field,and his mandatory use of the token put above-normal stresses on the laptop’s USB port. Although hisWindows session was up and operating, and he was in the middle of an important document, hewas unable to access it. It was clearly a very frustrating moment.

Be sure not to minimize the effectiveness of your two-factor authentication by making it too easyfor the end-user. Crypto-expert Bruce Schneier flogged a UK credit card smart card implementationbecause the company actively encourages users to select an easy-to-remember PIN, like their birthday(http://www.schneier.com/blog/archives/2005/01/easytoremember_1.html). This approach effectivelytells malicious users the password and PIN combinations they should try if they get access to thesmart card – and completely destroys the benefits of two-factor authentication. Many companiesrequire that the employee’s PIN be the employee’s company ID or the last four digits of theemployee’s social security number. However, password/PIN combinations used in two-factor authentication should always be random.

Another troubling issue is the security used on token and smart cards by the vendor. At least onestudy (http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci968784,00.html) revealed that someimplementations actually store the secret data in plain text on the device instead of protecting it.When evaluating two-factor authentication devices, get the vendor’s written statement as to the strongprotection of cryptographic keys and other confidential information.

Cell Phone Two-Factor AuthenticationSome banks, like ASB Bank and BankDirect (http://www.bankdirect.co.nz/story799.asp), are using ahybrid approach to use two-factor authentication while bypassing the need to rely on a single physicaldevice. When a customer conducts a transaction with a value of more than $2,500, these banks requirethe user to input a second authentication password. First, the user logs on to the web site normally, withthe logon name and password. Then the second password is sent to the user’s (predefined) cell phoneusing an SMS text message. The user has three minutes to enter the second code into the web site toconduct the transaction. This approach has advocates and critics, but it is harder to fake than regularsingle-factor authentication.



http://www.schneier.com/blog/archives/2005/01/easytoremember_1.html

http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci968784,00.html

http://www.bankdirect.co.nz/story799.asp

If you’re using a contactless token or smart card, it is vulnerable to scanning by a malicioussource. Some vendors brag about how far their wireless devices can transmit, as measured in meters,not centimeters. Although a longer distance may be more convenient for a user, the farther away asecurity device can transmit, the more likely it is to be intercepted. Legitimate applications look forspecific vendor attributes, discussed above, before they accept the card’s transmission, but not allsmart cards and tokens defend against eavesdropping as readily as they should. In most contactlessscenarios, the most important cryptographic operations are performed locally, on the card itself, nottransmitted, which affords additional protection. Be sure to ask the vendor and test its assertionsregarding the device’s defenses.

Always be aware that two-factor authentication can be bypassed or disabled. Many vendors’ solutions can be bypassed by simply booting into safe mode. Although the software can require thata smart card or token be used even in safe mode, many don’t. And if malware can be insertedbetween the smart card or token and the back-end authentication database, it is still possible for thesecret data to be recorded and used maliciously later. Smart card- or token-enabled devices must stilltake all the normal precautions to prevent malware installation.

Despite these issues, two-factor authentication is a viable way to add security to any computer ornetwork.

Using Smart Cards in a Windows Environment Windows 2000 and 2003 Active Directory environments with Windows 2000 Professional and laterclients support smart card logons. In these environments, smart card logons are allowed by extendingthe Kerberos authentication protocol, which is available only on these Active Directory forest andclient types. Smart card logons are not supported in earlier clients without complete third-party soft-ware support. Microsoft Windows Server 2003 Standard Edition, Enterprise Edition, and DatacenterEdition OSs provide ample smart card support for logon authentication.

• Enabling smart cards in a Windows environment requires• a Certification Authority (CA)• smart card certificates• Active Directory• smart cards• smart card readers/writers• smart card software (to interface with the reader/writer)• Windows 2000 and later clients

Certification Authority The general installation and use of Microsoft Certificate Services is beyond the realm of this chapter.Instead, this section focuses on implementing smart card certificates only. For information aboutimplementing Microsoft Certificate Services, see the recommendations in the Other Resources sectionbelow.

To deploy smart cards in a Windows 2000 or Windows Server 2003 Active Directory environment, your system must meet the following requirements:

• All domain controllers and computers in the Active Directory forest must trust the root CA ofthe smart card certificate’s certificate chain.



• The CA that issues the smart card certificate must be included in the Active Directory NTAuthority (NTAuth) store. When a CA certificate is added to the NTAuth object in Active Directory (CN=NTAuthCertificates, CN=Public Key Services, CN=Services, CN=Configuration,DC=ForestRootDomain, where ForestRootDomain is the LDAP distinguished name of the forest’s root domain), the thumbprint of the CA’s certificate is automatically distributed to allWindows 2000 and later domain members in theHKEY_LOCAL_MACHINE\Software\Microsoft\EnterpriseCertificates\NTAuth\Certificates registry key. You can verify the CA certificates included in the NTAuth store by using the PKIHealth Tool (pkiview.msc) included in the Windows Server 2003 Resource Kit.

• The smart card certificate must contain the smart card logon (1.3.6.1.4.1.311.20.2.2) and clientauthentication (1.3.6.1.5.5.7.3.2) object identifier (OID) in the enhanced key usage (EKU)extension or in the application policies extension. The smart card logon and client authentication OIDs must be valid in the entire certificate chain.

• The smart card certificate must contain the user’s UPN in the subject alternative name extension.

• All domain controllers must have a Domain Controller or Domain Controller Authenticationcertificate installed.

• Smart card authentication requires mutual authentication of the user and the domain controllerinvolved in the Kerberos authentication.

A Windows Server 2003 Enterprise Edition Enterprise CA (vs. a Standalone CA) meets theserequirements. If you choose, a third-party CA can issue a smart card certificate as long as the requirements are met. The requirements are detailed in Knowledge Base article 281245, “Guidelinesfor Enabling Smart Card Logon with Third-Party Certification Authorities.”

Smart Card Distribution Pathway Here are the general steps you will follow to distribute smart cards in your organization.

1. Create an issuance policy. Either the end-user can request smart card certificates or you canuse an enrollment agent.

2. Select and configure certificate templates.3. Install smart card readers and writers.4. Install smart card reader and writer software.

We cover a specific setup step-by-step below, but before we get into that detail, you need tomake one basic decision: will the end-users request and create smart cards themselves or will youuse an enrollment agent? Enrollment agents have special rights, given through an Enrollment Agentcertificate, that let them request smart card certificates on behalf of another user. Typically, the enrollment agent verifies the end-user’s request and identity, generates the smart card certificate (seethe “Templates and Certificates” section below), and creates the smart card.

The enrollment agent signs the user’s certificate request with a certificate that includes the Certificate Request Agent object identifier in the EKU or Application Policy extension of the enroll-ment agent’s certificate. The enrollment agent uses the Certificate Services Web Enrollment pages (seethe “Web Enrollment” section below) to request the smart card certificate on behalf of another user.



The smart card enrollment pages must be added to the Local intranet security zone and allowuntrusted ActiveX controls to be downloaded.

If your company doesn’t require the separate validation of the end-user’s identity, you can use anauto-enrollment process. In this case, you must ensure that smart cards, smart card readers, and support software, such as smart card management software and Cryptographic Service Providers, aredistributed to the users before you start the auto-enrollment process.

Smart Cards Step-by-Step Here are the specific steps that you must complete enable smart card deployment using MicrosoftCertificate Services with both Enrollment Agents and web enrollment:

1. Install smart card reader/writers and accompanying software to all involved computers, including the CA.

2. Install Internet Information Services (IIS) to support web enrollment.3. Install and configure Certificate Services.

a. Install an issuing CA (an Enterprise CA simplifies smart card deployment but is notrequired).

b. Install the Web Enrollment component.4. Configure and publish the following templates to the Certificate Services CA:

a. Enrollment Agentb. Enrollment Agent (Computer)c. Smart card logond. Smart card user

5. Establish Enrollment Agent6. Configure a web enrollment site in the local intranet security zone on the Enrollment Agent’s

computer or the end-users’ computers.7. Allow the Enrollment Agent to request smart card certificates on behalf of other users.8. Allow users to pick up smart cards.9. Have users test smart card logons.

The next few sections will cover these steps in detail.

Installing the Smart Card Software By default, Microsoft Windows supports many smart cards from various vendors. For Windows to recognize and retrieve data from a smart card, Windows must recognize the smart card’s Cryptographic Service Provider (CSP). CSPs are software interfaces that allow Microsoft’s cryptographicAPI (called CryptoAPI) to interact with the smart card or token and partly determine the cryptographyused.

The CSP software must be installed on the computers where the smart card is used. Windowsships with a certain number of pre-installed CSPs, but vendors often install their own versions. Normally, all this software is provided by the vendor of the smart card reader/writer. Figure 6-4shows a smart card vendor’s installation routine as it prepares to install its own CSP.



Figure 6-4 Example smart card vendor software installation process

It is common today for smart card readers to be USB devices. As is the case with most USBdevices, you should install the software before connecting the USB reader. After the reader is pluggedin, a series of “new hardware-found” balloons will appear to confirm the successful installation of thesmart card software and reader.

Usually, a new taskbar icon associated with the smart card vendor is also installed. Clicking thetaskbar icon opens the vendor’s software and reveals the characteristics of the currently installedsmart card and smart card reader (see Figure 6-5). Note the card’s unique identification number, available memory storage, and card OS version.

Figure 6-5 Example of vendor’s software indicating smart card characteristics



You must install the vendor’s software on the CA so the vendor’s CSP will be available to theserver as a selection (see Figure 6-6). To specify only the vendor CSPs that are directly related to thesmart card vendor you are using, choose Requests must use one of the following CSPs. If you don’tlimit the possible CSPs, the enrollee might choose an invalid option that doesn’t work with the specific smart card and application.

Figure 6-6 Request handling showing vendor’s CSP installed

Templates and Certificates Next, you must configure the appropriate certificate templates. Microsoft Certificate Services issues certificates based on configured certificate templates, which are then published to the CA. All settingsrelated to a particular certificate type are configured in the template, including

• Certificate type and function• Certificate name• Security• Who can request (that is, enroll)• Auto-enrollment enabling • Issuance requirements

The smart card user must have, at a minimum, a certificate that includes the Smart Card Logon(1.3.6.1.4.1.311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2) OIDs in the certificate’s EKU orApplication Policies extension. This functionality is provided in two default version 1 certificate templates: Smart Card Logon and Smart Card User. Smart card certificates can be based on either certificate; certificates created with the Smart Card User certificate template can also be used to signand encrypt email.



The enrollment agent must hold a certificate allowing that agent to request a smart card certificateon behalf of another user. To set this up, include the Certificate Request Agent OID(1.3.6.1.4.1.311.20. 2.1) in the EKU or Application Policies extension of the certificate. This function isincluded in the default Version 1 Enrollment Agent certificate template, but you can also further customize the template using Version 2 templates (available in Windows Server 2003 Enterprise Edition Enterprise CAs). Version 2 templates let you require validation of an enrollment agent’s identity, enable auto-enrollment for certificate renewal, add a certificate policy to describe theissuance method of the smart card certificate, add application policies to the smart card certificate,and enforce the use of a specific smart card CSP.

Once you determine how smart cards are to be used in your organization and how the certificates are to be deployed, you can define the certificate templates. Most organizations use thedefault Enrollment Agent certificate template. If you implement this template, my only recommenda-tion is that you modify the permissions to allow a custom global or universal group (in the case of amultiple domain forest) only Read and Enroll permissions. Remove the Enroll permission assignmentfor members of the Enterprise Admins and forest root domain’s Domain Admins groups to preventunauthorized registration of the Enrollment Agent certificate template.

If you want to implement certificate manager approval for enrollment agent certificates, you mustcreate a Version 2 certificate template based on the Version 1 Enrollment Agent certificate template.Right-click the Enrollment Agent certificate template and choose Duplicate Template (see Figure 6-7).

Figure 6-7 Creating a Version 2 Enrollment Agent certificate template

In the Version 2 certificate template definition, configure the Issuance Requirements tab to requirea Certificate Manager’s approval (see Figure 6-8). This step effectively disables auto-enrollment fornew Enrollment Agents, which isn’t a bad thing; in fact, it’s encouraged.



Figure 6-8 Requiring the Certificate Manager’s approval on Enrollment Agent certificate requests

Once a Certificate Manager’s approval is given, the requesting user can then use web enrollment(see below) to request the Enrollment Agent certificate.

Also, if you use a Version 2 Enrollment Agent certificate template, designate the version 1.0Enrollment Agent certificate as a superseded template. By doing so, you make it impossible forsomeone to generate additional Enrollment Agent certificates using the older default template.

Figure 6-7 shows the other two default Enrollment Agent certificate templates: Enrollment Agent(Computer) and Exchange Enrollment Agent (Offline request). The Enrollment Agent (Computer) template creates certificates for Enrollment Agent workstations. A secure environment requires that theEnrollment Agent request certificates on the behalf of other users from a computer that has theEnrollment Agent (Computer) certificate issued to it. This prevents an unauthorized intruder fromissuing smart card certificates from another computer after simply compromising the EnrollmentAgent’s user account.



NoteYou can’t put any limits on the users for whom enrollment agents can request certificates. Thismeans agents can request smart card logon certificates for members of the EnterpriseAdministrators, Administrators, and Schema Admins groups. Of course, the enrollment agentalso must know that person’s logon password (if required), so there is an offsetting control.

Because the Enrollment Agent’s account is highly privileged and grants logon access to otherusers, you should strongly consider creating a separate Enrollment Agent user account that is allowedto log on only to the specific Enrollment Agent workstation computer (using User Account propertiesin Active Directory Users and Computers) and disallow all other local access, besides members of theAdministrators group and the System account.

The Exchange Enrollment Agent (Offline request) template allows a computer that is hosting anExchange Key Management Service (KMS) to request certificates on the behalf of Exchange emailencryption users. The KMS method of key distribution is being discontinued in Exchange, and there-fore isn’t used frequently anymore.

After you have configured the correct certificate templates, you must publish them to CertificateServices. From the Certification Authority console on the CA Server, right-click the Certificate Tem-plates leaf object and choose New, then select Certificate Template to Issue (see Figure 6-9). Selectthe appropriate templates and click OK (see Figure 6-10).

Figure 6-9 Selecting new smart card certificate templates to publish to CA

n



Figure 6-10 Publishing new smart card certificate templates to CA

Web Enrollment If web enrollment is correctly installed, a new virtual directory called CertSrv should be present, alongwith other associated files and folders (see Figure 6-11).

Figure 6-11 CertSrv virtual directory associated with web enrollment



You should secure the web enrollment site as you would any other IIS web site, including determining ahead of time whether user logons can be anonymous or must be authenticated. Youconnect to the web enrollment site by typing the following URL in Internet Explore (see Figure 6-12):

http://<servername>/CertSrv

Figure 6-12 Web enrollment web site

To connect, of course, the connecting computer must be able to find the server (using DNS, NetBIOS, or the IP address) and must have permission to read the web page. The web enrollmentsite can be customized for any environment. Some companies have different web sites coded for different languages and uses.

For users, including Enrollment Agents, to access the web enrollment site, they must allow a WebEnrollment ActiveX control to be installed in Internet Explorer. Unfortunately, this means the localuser must be logged on with Administrator privileges during the ActiveX install. You can ensure thatsigned ActiveX controls are allowed to run and be installed by adding the web enrollment web siteto Internet Explorer’s Local Intranet security zone.

NoteTo decrease security risk, IIS and web enrollment files should not installed on the same serveras Certificate Services.

n



Requesting an Enrollment Agent Certificate Now the Enrollment Agent can request an Enrollment Agent Certificate.

1. Click Request a certificate.2. Click Or, submit an advanced certificate request.3. Click Create and submit a request to this CA.4. Choose the correct Enrollment Agent Certificate type in the Certificate Template field (see Fig-

ure 6-13) and click Submit (at the bottom of the page).5. The vendor’s software may pop up at this point (because it is included in the Certificate

request’s CSP field) and prompt the user for a PIN to secure the certificate (see Figure 6-14). Ifprompted, type the PIN.

Figure 6-13Choosing the Enrollment Agent certificate template during web enrollment



Figure 6-14 Certificate prompting for PIN

In Figure 6-14, notice that the vendor’s software gives the option of changing the PIN when thecertificate is first retrieved or used. This feature makes it possible for the Enrollment Agent to requestthe certificate and let the ultimate end-user choose a personal PIN. After the PIN is entered, the CSPgenerates the private/public key pair on the workstation and sends a copy of the public key alongwith the request.

Now the Certificate Manager should approve the request in the Certification Authority console.The new Enrollment Agent user can log on to the Web Enrollment web site again and retrieve thenew Enrollment Agent certificate. This process should be repeated for the Web Enrollment Computercertificate. At that point, the Enrollment Agent is ready to request smart card certificates on behalf ofother users. Figure 6-15 shows an example of an Enrollment Agent Certificate.



Figure 6-15 Details of an example Enrollment Agent Certificate

Requesting a Smart Card Certificate on Behalf of Other Users Now authorized Enrollment Agents can request smart card certificates from the web enrollment siteon behalf of other users. From an Enrollment Agent workstation with an attached smart card writer:

1. Insert a new smart card into the writer.2. Log on to the web enrollment site as an authorized Enrollment Agent.3. Click Request a certificate.4. Click Or, submit an advanced certificate request.5. Click Request a certificate for a smart card on behalf of another user by using the smart card

certificate enrollment station (see Figure 6-16). The first time this is selected, it will install theSmart Card Enrollment Station ActiveX control.

6. Type the required information (see Figure 6-17) and click Enroll.7. Type the smart card PIN when prompted and click OK. The smart card certificate will be

generated and saved to the smart card. You can give the user the option of selecting a newPIN upon first use.

8. Remove the smart card from the writer and give it to the user. If the feature was enabled during the previous step, the user will be prompted to select a new PIN.



Figure 6-16 Requesting a certificate on behalf of another user during web enrollment

Figure 6-17 An Enrollment Agent requests a certificate on behalf of another user



The smart card should now contain user’s smart card certificate (see Figure 6-18) and be readyfor use.

Figure 6-18 Example smart card with installed certificates

Requesting a Smart Card Certificate Now authorized users can request a smart card certificate from the web enrollment site.

1. Click Request a certificate.2. Click Or, submit an advanced certificate request.3. Click Create and submit a request to this CA.4. Choose the correct smart card certificate type in the Certificate Template field and click Submit

at the bottom of the page. If prompted, type the PIN.5. After the certificate request is approved, install the smart card certificate.

Configuring Group Policy Group policy options allow you to require smart cards for interactive or remote logons and define thecomputer’s behavior if the smart card is removed.

Requiring Smart Cards for Interactive Logons You can require the use of smart cards using the Interactive Logon: Require Smart Card setting. This setting, defined in Computer Settings | Windows Settings | Security Settings | Local Policies |Security Options, ensures that a smart card is required to log on locally for all computer accounts inthe OU or domain where the group policy is applied.



After you’ve set up this requirement, if the smart card is inside the reader before the user tries tolog on, the user types the normal logon name and password. If the user ejects and re-inserts thesmart card, the user is prompted to type the smart card’s PIN. If the user tries to log on withoutinserting the smart card, an error message is presented (see Figure 6-19).

Figure 6-19 Error message displayed when trying to log on without a smart card when a

smart card is required

NoteThis feature is available on XP only if you have http://support.microsoft.com/?kbid=834875installed. Using this setting also breaks Remote Assistance unless you installhttp://support.microsoft.com/?kbid=893226.

You can require smart cards on a per-user basis in Active Users and Computers (see Figure 6-20).Setting up the option there overrides group policy and local computer policy settings. Be aware thatenabling this option changes the user’s password to a random password, which can cause authentica-tion problems with applications that are not smart card-aware. If the user ever disables this feature,the administrator will have to reset the password for the first time the user logs on without a smartcard.

n





Figure 6-20 Requiring smart card logons on a per-user basis

NoteEnabling the Smart Card is Required for Interactive Logon and the User Must Change PasswordAt Next Logon options at the same time will cause a logon conflict that can’t be fixed until oneof the settings is disabled.

Requiring Smart Cards for Remote Logons You can require smart cards to log on using Remote Desktop or Terminal Services, or for Routingand Remote Access (RRAS) logons.

Remote Desktop/Terminal Services Logons By default, when smart card logons are required for a particular user or computer, they will berequired when logging on using the Remote Desktop Protocol (RDP). You can disable this particularfeature using group policies, but by default, the requirement will be passed along to the remoteworkstation. Both the intended host and the remote client must have the smart card CSP installed for

n



smart card redirection to work. If the user tries to log on using the RDP, the user will be presentedwith an error message like the one in Figure 6-19.

RRAS Logons To enforce smart card authentication for remote access, you must configure a remote access policy at a remote access server or a RADIUS server to require Extensible Authentication Protocol withTransport Layer Security (EAP/TLS) authentication in the profile settings. When you enforce EAP/TLSauthentication, you can elect to restrict client certificates to a smart card or other certificate. The only additional configuration required at the RRAS server or the Internet Authentication Services (IAS) server is to designate the Server Authentication certificate used by the server for mutual authentication.

Smart Card Removal Behavior Using group policies, you can define what occurs when users remove their smart cards from a smartcard reader. The Interactive Logon: Smart Card Removal Behavior Group Policy setting, defined inComputer Settings | Windows Settings | Security Settings | Local Policies | Security Options, ensuresthat smart card removal behavior is consistent for all computer accounts in the OU or domain wherethe group policy is applied. In this group policy setting, you can define the removal behavior one ofthree ways:

• No Action: The default setting. Removing the smart card does not lock the workstation or logoff the current user.

• Lock Workstation: Removing the smart card causes the workstation to lock. The user mustpress Log On Interactively or provide the PIN for the smart card to unlock the workstation.

• Force Logoff: Removing the smart card causes the user currently logged on to be logged offautomatically.

The option you choose should support your company’s security policy. The first option, NoAction, means a smart card is needed to log on but is not needed thereafter. The second option locksthe workstation when the smart card is not present, but it allows any running applications to continueto remain active in the background. The third option logs off the user and closes any active applica-tions, which could cause the user to lose data.

When Smart Cards Can’t Work You should remember that smart cards don’t work in every circumstance. Some applications can’t usesmart cards as an authentication mechanism – for example, in Outlook Web Access; you must typecredentials into a form or use basic authentication protected by Secure Sockets Layer (SSL). SomeExchange Server deployment scenarios have configuration options that don’t support the use of smartcards. For example, if the user account and the mailbox are in different forests, smart card authentica-tion is not possible.

In a pure Windows 2000 network, it isn’t possible to use smart cards for all administrative tasks.Several tasks require inputting user credentials and passwords, which reduce any security gainsachieved by the smart cards. Windows XP and Windows Server 2003 offer enhancements that enablethe use of smart cards in additional administrative tasks, including the RunAs, Net Use, and DCPromocommands, and Terminal Services.



Another option that does not support smart card authentication is the implementation of RemoteProcedure Calls over HTTP in Microsoft Outlook. Service accounts and batch files also cannot usesmart cards for authentication. A scheduled task that implements a service’s account doesn’t promptfor the insertion of a smart card or for the input of a PIN to access the private key material on thesmart card.

If a workstation is not joined to a domain, Windows NT LAN Manager (NTLM or NTLMv2)authentication is used to for the account and password combination. Because smart cards requireKerberos authentication, they cannot be used in this scenario. If a web application uses Basic Authentication or NTLM authentication, it can’t use smart cards for authentication. Only applicationsusing Kerberos that support smart card extensions work with smart cards.

Vendors Microsoft Windows Marketplace-smart cardshttp://www.windowsmarketplace.com/results.aspx?text=smartcard

More Resources These resources contain additional information and job aids related to this chapter.

General Smart Card Knowledge How Stuff Works — Smart Card Basicshttp://electronics.howstuffworks.com/framed.htm?parent=question332.htm&url=http://www.smartcardbasics.com

The Smart Card Alliancehttp://www.smartcardalliance.org

Smart Card FAQhttp://electronics.howstuffworks.com/framed.htm?parent=question332.htm&url=http://www.faqs.org/faqs/technology/smartcards/faq/index.html

Microsoft Smart Card Deployment Guides Microsoft Smart Card Deployment Planninghttp://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dsscg_smc_vevm.asp

Get Smart! Boost Your Network’s IQ with Smart Cardshttp://www.microsoft.com/technet/technetmag/issues/2005/01/SmartCards

“Certificate Templates” in Help and Support Center for Windows Server 2003 for information abouthow to configure certificate templates

“Prepare a smart card certificate enrollment station” in Help and Support Center for Windows Server2003 for information about delegating enrollment agent authority to individuals who are not domainadministrators



http://www.windowsmarketplace.com/results.aspx?text=smartcard

http://electronics.howstuffworks.com/framed.htm?parent=question332.htm&url=http://www.smartcardbasics.com

http://www.smartcardalliance.org

http://electronics.howstuffworks.com/framed.htm?parent=question332.htm&url=http://www.faqs.org/faqs/technology/smartcards/faq/index.html

http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dsscg_smc_vevm.asp

http://www.microsoft.com/technet/technetmag/issues/2005/01/SmartCards

“User and Group Smart Card Requirements” (DSSSMC_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “User and Group Smart Card Requirements” on the Web athttp://www.microsoft.com/reskit)

“Smart Card Service Level Agreement” (DSSSMC_2.doc) on the Windows Server 2003 Deployment Kitcompanion CD (or see “Smart Card Service Level Agreements” on the Web athttp://www.microsoft.com/reskit)

“Smart Card Hardware Specification” (DSSSMC_3.doc) on the Windows Server 2003 Deployment Kitcompanion CD (or see “Smart Card Hardware Specification” on the Web athttp://www.microsoft.com/reskit)

“Smart Card Reader Evaluation” (DSSSMC_4.doc) on the Windows Server 2003 Deployment Kit companion CD (or see “Smart Card Reader Evaluation” on the Web athttp://www.microsoft.com/reskit)

“Smart Card Deployment Schedule” (DSSSMC_5.doc) on the Windows Server 2003 Deployment Kitcompanion CD (or see “Smart Card Deployment Schedule” on the Web athttp://www.microsoft.com/reskit)

Books Microsoft Windows Server 2003 PKI and Certificate SecurityAuthors: Brian Komar and the Microsoft PKI Team Publisher: Microsoft PressISBN: 0735620210

Smart Card HandbookAuthors: Wolfgang Rankl and Wolfgang EffingPublisher: John Wiley & Sons, 3rd editionISBN: 0470856688

Smart Card Security and ApplicationsAuthor: Mike HendryPublisher: Artech House Publishers, 2nd editionISBN: 1580531563

Conclusion Two-factor authentication can significantly increase the security of any environment. Microsoft Windows Server 2003 supports smart card authentication and offers a variety of tools to ease thedeployment and management of smart cards. Before rolling out smart cards, you should create adeployment plan and evaluate vendor products.

Chapter 7, the last chapter of Keeping Your Business Safe From Attack: Passwords andPermissions, will cover implementing rights management solutions.



http://www.microsoft.com/reskit





164


Chapter 7:

Implementing Rights ManagementAs you have seen in the previous six chapters, Microsoft provides one of the most granular securityaccess control systems of any popular operating system. Using myriad tools, group policy, and security templates, you can configure any Windows system to resist to malicious attack. Microsoftcontinues to lead the field of access control with its Digital Rights Management (DRM), WindowsRights Management Service, Information Rights Management, Authorization Manager, and IdentityIntegration Server initiatives. The first four of these technologies focus on controlling who has whatcontent and what they can do with it. The last technology, Identity Integration Server, manages useraccounts in one or more directory spaces from a central management point. Chapter 7 summarizesthese technologies and shows how they may fit in your computing environment.

Digital Rights Management Digital rights management isn’t a specific Microsoft technology or product; instead, DRM is a conceptthat is implemented in several different products. The idea is that content creators and publishersshould be able to control who has access to the content they manage and what consumers can dowith it. DRM enforces the generally accepted principles of copyright law to minimize unauthorizeddistribution or use of any digital content — music, video, software, or proprietary confidential data.DRM protects the ownership and integrity of the digital content, wherever the content resides.

Distribution and use is controlled by applying cryptographic processes at the content and program levels. For any DRM scheme to work, the following must be true:

• A DRM platform or protocol must be developed that can be readily used by the contentowner and consumer

• The DRM platform must make unauthorized use or distribution difficult• The content must be created and DRM-protected by the publisher before it is distributed or

otherwise made available • Software that can play or present the protected data must be programmed to allow only

authorized content and use after successful validation

Covered content is usually encrypted or digitally signed in a way that prevents playing or useunless a legitimate, licensed key is present. DRM schemes are available in many Microsoft products,including Microsoft Media DRM, Windows Media Player, and Microsoft Office.

Microsoft Media DRM Platform Microsoft Media DRM (http://www.microsoft.com/windows/windowsmedia/drm/default.aspx) is aplatform that lets independent software vendors (ISVs) develop applications to play protected Windows Media-based content. Media can be protected, delivered, and played a la carte or via subscription on computers or portable media devices. With Windows Media Rights Manager (WMRM),anyone can package files and issue licenses. Packaged files are encrypted and locked with a key. The

http://www.microsoft.com/windows/windowsmedia/drm/default.aspx

Chapter 7 Implementing Rights Management 165


key is stored in an encrypted license, which should be distributed separately; the protected digitalcontent includes the URL at which the license can be acquired. The packaged file can then be placedon a web site, distributed on physical media, or transferred to consumers. The content provider mustfirst establish a license “clearinghouse” server that implements the WMRM License Service. When theconsumer accesses the protected files, the license server is contacted. A license can be free or purchased, according to the publisher’s requirements.

The consumer’s media players must also be licensed to play DRM-protected content. Before acompany can incorporate Windows Media DRM into their players, Microsoft must first give authorization. This process lets Microsoft revoke the media player’s license certificate if the player iscompromised. The licensed player and its applications must be authenticated before protectedlicenses or content can be played.

Windows Media DRM is supported by many vendors, including Casio, Creative, Diamond, Intel,Nike, Sony, Panasonic, and Texas Instruments. Of course, Microsoft’s own Windows Media Player isalso an approved application.

Windows Media Player When protected content is accessed in the more recent versions of Windows Media Player (WMP),the player automatically tries to access or acquire the correct license. In WMP 10, choose Optionsfrom the Tools menu and select the Privacy tab to enable or disable the Acquire licenses automati-cally for protected content option (see Figure 7-1). Acquired licenses should be backed up to preventloss or damage.

Figure 7-1 Enabling Windows Media Player’s acquire licenses option



Windows Media Player’s DRM features are necessary for many vendors and customers – and corporate environments need similar protection for non-media content.

Windows Rights Management Service First-generation DRM solutions focused on limiting who had access to a particular piece of content,but they weren’t particularly adept at controlling what could be done with it once it was accessedlegitimately. For example, music publishers are especially concerned with preventing unauthorizedcopying of digital music. Some corporations have similar concerns about their digital data – forexample, they want to share confidential documents and spreadsheets without worrying that thosesame documents will land in the hands of unauthorized readers or competitors. Enter WindowsRights Management Service (RMS).

Microsoft released RMS as a premium add-on component to Windows Server 2003. RMS also protects content against unauthorized access, but unlike legacy solutions, RMS also gives the owneror creator control over how the content is handled after the authorized party receives it. The protection stays with the document. With RMS, the creator can define who can see the content, howlong they can see it (using an expiration date), and what they can do with it. The authorized viewermay be allowed only to view and read the document, or viewers can be authorized to copy, print, orforward it to other approved users — and these rights can be denied as well. Unless the viewer takesa picture of the screen or captures screens with a third-party utility, the actions that can be performedon the document are limited.

The content creator embeds the allowed permissions into the document, which is then cryptographically protected. The document is distributed as it normally would be – through email, fileshare, physical media, or some other option. When the document is accessed, it “phones home” tosee what rights and permissions the current user was given. If the current user isn’t authorized, thedocument remains cryptographically protected. RMS works with content created using MicrosoftOffice 2003 Professional, custom RMS applications, and with Internet Explorer using a Rights-Management Add-on.

In general, you need the following components for an RMS infrastructure: Windows RMS Server,Windows RMS client software, and Windows RMS-enabled application. These three componentsinvolve more than a few hours of initial setup, but the access control payback is huge. Speficially,you must have

• Windows Server 2003 (Standard, Enterprise, or Datacenter editions) with an NTFS partition• Active Directory Forest (2000 or 2003)• Internet Information Service (IIS) 6 with ASP.NET• Messaging Queuing (located under Application Server components)• Microsoft SQL Server 2000 (SP3 or better)• Windows Rights Management Service SP1 for Windows Server 2003• Windows Rights Management client software• Windows RMS Client Access Licenses (CAL) for each participating user• An RMS-enabled application (i.e. Microsoft Office 2003 Professional or Internet Explorer with

the Rights Management Add-on)

RMS digital certificates, which are distributed to the server, the content creator, computers, anduser, make the whole protection scheme work. RMS uses Extensible Rights Markup Language (XrML),a standard based on XML, to apply rights and usage policies. You can find out more about XrML athttp://www.xrml.org. Although Windows Server 2003 is required, the forest can be a Windows 2000forest, and clients can be Windows 2000, XP, or 2003.

How RMS Works When creating content in an RMS-enabled application, the author chooses control protections for thatcontent. The first time the author applies RMS protection to a document, the author receives a clientlicensor certificate from the RMS sever. A publishing license, which contains the usage policy (that is,what receivers can do with the content), is generated. The author’s RMS client application encryptsthe file with a symmetric key, which is then encrypted with the RMS server’s public key. Theencrypted key is inserted into the publishing license and the publishing license is bound to the protected file. The author then distributes the file using normal distribution channels.

NoteA client can also be designated as an Offline Entity using a Client Licensor Certificate (CLC). Amachine processing a CLC can publish content without first contacting the RMS server.

Users receiving the file open it in an RMS-enabled application, such as Microsoft Office 2003 orInternet Explorer. The application sends a request for a use license to the author’s RMS server. Theuse license request includes the receiver’s account certificate (including the receiver’s public key) andthe protected document’s publishing license (which includes the document’s encrypted symmetrickey). If the RMS server approves the request, a use license is created.

The server creates the use license by decrypting the protected document’s symmetric key (sent inthe publishing license) and encrypting it with the receiver’s public key. The receiver’s private key,which only the receiver has, is the only key that can open the use license, thereby ensuring that theuse license cannot be used by any other unintended parties. The receiver decrypts the use license,recovers the document’s symmetric key, and decrypts the original document. The RMS applicationensures that the receiver can perform only those actions that the use license covers (see Figure 7-2).

n



http://www.xrml.org

Figure 7-2 Example of granted Rights Management permissions

Installing RMS RMS has server and client components. RMS can be installed on any Windows 2003 domain memberserver or domain controller but cannot be installed on a stand-alone server. Installing RMS on theserver involves first ensuring that the appropriate supporting applications are already installed,including Active Directory, IIS 6, and ASP.NET. Installation will proceed with fewer errors andwarning messages if IIS (with ASP.NET and Message Queuing) are installed first.

Microsoft SQL Server 2000 (including all service packs) can be installed either before or afterRMS, but you must install SQL Server before setting up RMS. Microsoft SQL Server Desktop Editioncan be installed for test configurations, but it cannot be used in production systems. In either case,the SQL engine must be active before you provision, or activate, RMS.

The Windows RMS 1.0 SP1 server install executable is available at (http://go.microsoft.com/fwlink/?linkid=17673) and must be installed by someone with local Administrator permissions who isalso a domain administrator. After the initial installation, an online help file guides the administratorthrough the rest of the steps.

The server portion of RMS is managed using a web-based interface running on TCP port 5720.The management web site can be accessed by clicking Start and selecting All Programs, WindowsRMS, and Windows RMS Administration. Although the web interface runs over HTTP, it can be protected using SSL. Two new application pools, DRMS Application Pool and _DRMSAppPool1, arecreated, along with the new web site.

After installing the first RMS server, it must be provisioned. Provisioning “activates” RMS and otherwise enables RM clients and applications to begin using the server. During the provisioning process (see Figure 7-3), you must select an RMS service account (you can choose Local System forsingle server installs) and the Cluster URL. The Cluster URL is the web location of the RMS server and



http://go.microsoft.com/fwlink/?linkid=17673

http://go.microsoft.com/fwlink/?linkid=17673

is to be referenced by all RM clients, even if Microsoft’s clustering fault-tolerant technologies aren’tinvolved. During provisioning, the RMS service can use the Internet to contact Microsoft to get anRMS account certificates. RMS 1.0 SP1 allows a server to be provisioned using offline media, as well.

Figure 7-3 RMS provisioning

After the provisioning is complete, an Enterprise Administrator can use the RMS web management tool to register the RMS Service Connection Point in Active Directory. After it’s regis-tered, RM clients can use Active Directory to find the RMS server. Afterwards the administrator mustappropriately configure the RMS-related URLs:

• Licensing URL• External Licensing URL• External Certification URL• Certification URL

You must provide both internal and external locations for licensing and certification. To be identified and participate, all users must have RM account certificates. By default, RM certificates aregood for 365 days from the date of issue. The licensing services refer to use and publishing licensesthat each participant can create. All URL references must be resolvable, usually via DNS.



RM Certificates Windows RMS requires a public key infrastructure (PKI) to work, but it doesn’t use X.509 certificatesor Microsoft Certificate Services. RMS uses XrML certificates, which are different from their X.509counterparts:

• XrML certificates are expressed in XML• XrML certificates often contain private keys, whereas X.509 certificates contain only public keys

RMS issues RMS account certificates that associate user accounts with specific computers (that is,using machine certificates). The user’s RM account certificate must be included in the request for publishing and use licenses. The publishing license allows an author to publish RM-protected content.Each RM account contains the user’s public key, which is used to encrypt the content’s symmetric key(which encrypts the content).

A secure client environment called the RMS lockbox is distributed to participating user/computercombinations as a series of digital files (in DLL file format). The RMS lockbox cryptographically protects the RMS machine certificates used. This protection is different from that normally given regular X.509 certificates distributed by Microsoft Certificate Services. In the course of normal protection, private keys are usually stored in the user’s profile. Even though the private keys have notyet been compromised without knowledge of the user’s logon password, the RMS lockbox is evenmore resistant to attack.

NoteIn RMS 1.0 SP1, the lockbox is FIPS compliant when used with Windows XP and WindowsServer 2003.

RM account certificates come in two types: standard and temporary. Although you can changethe time period for both types, by default standard certificates are good for 365 days and temporarycertificates for 15 minutes. Temporary certificates are designed to let a participating receiver use RM-protected content on a computer that does not have that user’s RM account certificate – forexample, at a public kiosk or in a meeting at another business location.

RMS Policies and Templates If multiple domains are involved with multiple RM servers, the next step is to create a Trust policy. Ifyou want a user in one domain to trust RM-protected content from another domain, the resourcedomain must be added as Trusted User domain. If your setup has no other user domains to trust,you can skip this configuration option.

The next step is to create one or more Rights Policy Templates (see Figures 7-4 and 7-5). Thetemplates describe a standard set of users, rights, and conditions that apply to RM-protected content.There can be any number of templates. For example, you can create templates that specify a particular content treatment:

• Only the author can modify content, but anyone can read or print it• Only specified recipients can read content, but no one besides the author can print, email, or

copy it• Anyone in the enterprise can view the content for one month, but no one can print or email it

n



You can add different users and groups to the template and give different rights to each. Usersand groups must be specified using their Universal Principle Names (UPN) — for example,[email protected], [email protected], [email protected]. RM has a special groupcalled Anyone, which is approximately analogous to the Everyone Windows security group. Templates aren’t always used in every RM-enabled application, but using them lets you standardizerights application and management.

Figure 7-4 List of rights policy templates

Each template lets you choose among various RM rights. RM rights include • Full Control• Export (Save as)• View• Extract• Allow Macros• Reply• View Rights• Save• Print• Edit• Forward• Reply All



By default, content creators have Full Control permissions. You can specify when the contentexpires, if ever, using a particular date or number of days after publishing. You can also require theuse licenses be renewed after a particular number of days, even if the content’s publishing licensehasn’t yet expired.

Figure 7-5 Creating an RM rights policy template

The administrator defines who can and can’t issue publishing licenses or obtain RM account certificates. You can exclude internal users by UPN or external users by their public keys. And eventhough Windows 98 Second Edition and Millennium Edition can participate in RM, you can choose toexclude them as well to minimize legacy security issues. You can even exclude RM-enabled applications by version number.

NoteWith RMS, even administrators can be excluded from accessing protected content. The “super-user” certificate gives that group access to any RM-protected content. With this feature,you create an escrow user account, which ensures that RM-protected content isn’t madeunavailable just because the author chooses to or is no longer available. This type of certificatecould be given to a trusted IT person, management, human resources officer, or the legaldepartment.

n



While making RM-protected content, the author enables various rights or applies a particular template to the content, and the rights conferred become part of the content’s publishing license. Ifthe author uses a template, the author can specify a URL or email address where receivers canrequest additional permissions. To see how this portion of the process works, we need to examinean RM-enabled application, such as Microsoft Office’s Information Rights Management.

Information Rights Management Information Rights Management (IRM) is a new feature of Microsoft Office 2003 Professional andmakes it possible for Word 2003, Excel 2003, PowerPoint 2003, and Outlook 2003 documents to beRM-enabled. RM client-side software must be installed for Office 2003 Professional users to create oraccess RM content. Microsoft has also allowed Internet Explorer to be RMS-enabled with a free add-on.

NoteClients must use the Professional version of Microsoft Office 2003 to use IRM.

To use RM enabling with Microsoft Office 2003 Professional, install it as you normally would. Then download and install the Windows Rights Management Client SP1,(http://go.microsoft.com/fwlink/?LinkID=18134). It can be installed on the clients previously listedabove, as long as the service packs are up-to-date. You’ll need to install the Active Directory ClientExtension (available on any Windows 2000 installation CD-ROM) on Windows 98 Second Edition andMillennium Edition machines to participate fully.

During the installation and activation processes of the Windows Rights Management client, theclient machine may need to be able to contact a Microsoft web site over the Internet. (RMS 1.0 SP1has a new self-activation mode that does not require Internet access.) RM client activation saves asoftware component that links RM user accounts to the particular computer accounts. Both must betrusted for RM to work. After the installation is complete, two new programs will show up in Add orRemove Programs under Control Panel: Windows Rights Management Client and Windows RightsManagement Services.

NoteMicrosoft has plans to develop an enterprise-wide secure activation appliance that will removethe need for either the server or client to contact a Microsoft web site for activation.

After the client portion of IRM has been installed, it creates a Permissions button on the toolbar(see Figure 7-6).

n

n



http://go.microsoft.com/fwlink/?LinkID=18134

Figure 7-6 Permissions button

When a user clicks the Permissions button for the first time, the RM client contacts Microsoft overthe Internet to gain a RM account certificate (see Figure 7-7). This certificate ties the user to specificcomputers, up to 25 of them. (If you need to use RM on more than 25 computers, consider using atemporary account certificate instead of the standard version.) You can initialize the RM account certificate using a regular Windows logon name and password or with a Microsoft Passport account,which gives you more options for external distribution.

Figure 7-7 RM client contacting Microsoft during initialization

After authors have a publishing certificate assigned for the first time, they can use the Permissionbutton to protect a document. The user enables the Restrict permission to this document option (seeFigure 7-8) to turn on RM protection. In the basic screen, the author can type UPNs or emailaddresses to restrict to Read or Change (Read, Edit, Save, but not Print) permissions.



Figure 7-8Basic RM permission setting

Clicking More Options lets you choose more settings, including expiration date, whether contentcan be printed, whether users with read access can copy content, whether content can be accessedby programs, where receivers can request additional permissions, and whether users with RM-compliant browsers (covered below in Rights Management Add-on for Internet Explorer) canaccess protected documents.

When a protected document is opened in an RM-based application, it recognizes the RM-protected content and queries for the user’s RM account certificate. The account certificate is used to send a use request to the RMS server. The RMS server evaluates the request and sends theappropriate use license. IRM disables the features not authorized by the content author. Figure 7-9shows a Word document that allows reading and printing but not saving (or copying).



Figure 7-9 RM-protected read-only document disallowing Save or Save As

A user without an RM account is prompted to establish one (or can switch to an RM account thatdoes have access to request and be issued a temporary license). If the user has not been allowed toaccess the document, an error message is displayed (see Figure 7-10). The receiver can also requestpermissions or additional permissions, if the author set up the document in that way.

Figure 7-10 IRM indicating user does not have sufficient RM permissions to access document



Similar features for creating protected content are available in Word 2003, Outlook 2003, andPowerPoint 2003. Each implements IRM slightly differently; for example, Outlook relies on predefinedPolicy Templates to define RM-rights, users, and groups. In Figure 7-11, recipients of the email areallowed only to read the email. They cannot print, forward, or copy it.

Figure 7-11 Example of a protected Outlook email

Rights Management Add-on for Internet Explorer Microsoft recognizes that not all users in a Windows network environment have Office 2003 Professional. At the same time, RMS is a very extensible platform and developers can create customRM-enabled applications. The free Rights Management Add-on (RMA) for Internet Explorer lets Windows users, with appropriate RM rights, view files with restricted permissions within a webbrowser. RMA for Internet Explorer, RMUSetup.exe (http://www.microsoft.com/windows/ie/downloads/addon/rm.mspx), can be installed on Windows ME, 2000 (SP4 or later), XP, or Server2003 running Internet Explorer 6 SP1 or later. Internet Explorer 5.5 SP2 is supported on Windows MEonly. Windows 98 is not supported. You must first install the Windows Rights Management client asdiscussed above.

When you install RMA, a new Permissions button is also installed on the Internet Explorer toolbar (similar to Figure 7-6), and Internet Explorer enables access to any rights-managed HTML (RMH)file. RMH is a new file format that provides information protection for any Windows application thatcan export to HTML. RMA users can only access protected content; they cannot create RM-protecteddocuments.

Custom RMS Applications and Toolkits Developers can make their own RMS-enabled applications. Applications can be built using severaltools, including the RMS Software Development Kit, RMSSDKSetup.exe, (http://go.microsoft.com/fwlink/?linkid=17584&clcid=0x409) or the Windows Rights Management Client Software DevelopmentKit, RMClientSDK.exe, (http://www.microsoft.com/downloads/details.aspx?familyid=863DADCE-D648-4D50-9392-B4FACA34A0A8&displaylang=en). The RMS SDK is intended for developing applica-tions that run on Windows servers. The Client SDK is for creating programs that run on RMS clients.Both contain ways to access the new RMS API, which is intended for software engineers proficient inC++ coding. RMS can be integrated with other authorization and authentication technologies, such assmart cards or biometrics.



http://www.microsoft.com/windows/ie/downloads/addon/rm.mspx

http://www.microsoft.com/windows/ie/downloads/addon/rm.mspx

http://go.microsoft.com/fwlink/?linkid=17584&clcid=0x409

http://go.microsoft.com/fwlink/?linkid=17584&clcid=0x409

http://www.microsoft.com/downloads/details.aspx?familyid=863DADCE-D648-4D50-9392-B4FACA34A0A8&displaylang=en

http://www.microsoft.com/downloads/details.aspx?familyid=863DADCE-D648-4D50-9392-B4FACA34A0A8&displaylang=en

Using the RMH Software Development Kit (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rma/introduction.asp), a developer can RM-protect any HTML document, even otherproprietary file formats. The RMH specification uses Web Services and Single Object Access Protocol(SOAP) over HTTP or HTTPS to connect to an RMS server to create signed publishing licenses. RMHfiles are encrypted, and can be compressed, for confidentiality and efficiency. Some developers haveeven created rights-managed portals that make it possible for legacy applications and their file formatsto be protected by RMS before they interact with clients. In this way, even legacy server-based applications can use the power of RMS.

Microsoft developers have also created many tools to help administrators and developers withtheir RMS applications. The Administration Toolkit for Windows Rights Management Services can bedownloaded at http://www.microsoft.com/downloads/details.aspx?FamilyID=b287cec3-b6ca-4c0b-a9f5-11428092cc3f&displaylang=en. Tools in the kit include

• IRM Check, which creates an HTML report of client configuration settings• RMS Cert Analyzer, which checks the certificate trust chain on a given RM account certificate• RMS Config Editor, which lets an administrator view and edit the RMS configuration database• RMS Event Viewer, which maps and view RMS log entries• Step-by-steps, which lists step-by-step procedures for various RMS tasks

All these tools and help files will make any RMS deployment go much more smoothly.

For More Information The RMS Service isn’t free. Check with your authorized Microsoft reseller for pricing information

Several online RMS resources exist, including• http://www.microsoft.com/rms• http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx• http://www.microsoft.com/technet/prodtechnol/office/office2003/maintain/rmsirm.mspx

Although RMS is the next generation of DRM, it still cannot completely control digital content.Many screen-capturing programs can take snapshots of protected content when it is viewed. Andeven if snapshots are blocked in the future, users can always take photographs of the monitor’sscreen. Still, RMS presents a solid way to control most digital rights in a Windows environment.

Authorization Manager Authorization Manager is Microsoft’s effort to offer a Role-Based Access Control (RBAC) system. Windows is normally described as a Discretionary Access Control (DAC) system. In a DAC system, an object’s permissions and the rights given to a particular security principal are determined by theowner or, in some cases, the administrator. Access levels are determined at the owner’s discretion. A DAC-based access control system is the most popular type. Although it works well in most circumstances, conventional thinking is that leaving security decisions up to the content owner maynot be the best idea for security.



http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rma/introduction.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rma/introduction.asp

http://www.microsoft.com/downloads/details.aspx?FamilyID=b287cec3-b6ca-4c0b-a9f5-11428092cc3f&displaylang=en

http://www.microsoft.com/rms

http://www.microsoft.com/windowsserver2003/technologies/rightsmgmt/default.mspx

http://www.microsoft.com/technet/prodtechnol/office/office2003/maintain/rmsirm.mspx

Indeed, this reservation may be justified. How many users really understand Windows security?How many understand the difference between Share and NTFS permissions, the difference betweenModify and Full Control permissions, or how inheritance works? Probably not many.

The idea of RBAC is that an application’s developers decide what end-user roles are needed torun a particular application. The developers define the roles and assign the permissions necessary foreach role. The system administrator assigns various users into the predefined roles and the flow ofaccess control permissions occurs naturally and with least privilege.

In a DAC system, a user’s effective permissions are determined when they try to access theobject. The user hands over the access token (containing user and group SIDs) to the security reference monitor (SRM), and it compares each SID’s permissions to the object. In an RBAC system,the user presents only the name of the role to which he or she is assigned, and the system alreadyunderstands the effective permissions for each role.

In a sense, Windows administrators have always tried to implement role-based security, even ifthey didn’t understand it. Today, administrators install a new application, create new security groups,and assign permissions for application to those security groups. RBAC changes the current model forthe better. The application is installed, users are assigned various least privilege roles, and thesystem/application takes care of the permissions.

Microsoft’s RBAC effort is even more exciting that it initially appears. The Authorization Managerallows effective permissions to be queried on-the-fly and then dynamically assigned only whenneeded. This means that if a user needs write access only to a particular part of the application or itsdatabase, write access can be assigned only when it’s needed and withdrawn later. In contrast, whenthe current DAC-based model gives the user permission to an object, permission is granted it full-time, 24 x 7. Make no mistake about it, Microsoft’s RBAC effort is the future. The sooner administrators and application developers adapt their processes to RBAC-based initiatives, the sooneroverall security will be improved.

The Authorization Manager is a free tool. It can be accessed on any Windows 2003 server byaccessing the MMC snap-in console called AZMAN.MSC (see Figure 7-12).

The unfortunate news is that the Authorization Manager is an access control technology lookingfor applications. Essentially, the Authorization Manager, and the related APIs, aren’t needed or calleduntil an application is coded to require and use them. Currently, there are no built-in Microsoft appli-cations that use or need the Authorization Manager.

You can experiment with Authorization Manager using sample code developed by Keith Brownat http://msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager.



http://msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager

Figure 7-12 Authorization Manager snap-in showing two applications

The Authorization Manager has two modes: Developer and Administrator (see Figure 7-13). InDeveloper mode, users have unrestricted access to features. They can develop, create, and maintainapplications. Choose this mode if you are trying to test Authorization Manager. The Administratormode lets users deploy and maintain existing applications, but they cannot create new applications ordefine their operations. You can switch between modes without interference.

Figure 7-13 Authorization Manager modes



To use Authorization Manager, developers code the application to query and use the new Authorization APIs, accessed in AZROLES.DLL. Using any normal language that can take advantage of Windows APIs, the application can be coded to create and manage roles. Essentially, the application contacts the Authorization Manager API, which queries a predefined policy database (seeFigure 7-14).

Figure 7-14 Authorization Manager architecture flow

The Authorization Manager policy database can be stored in Active Directory or in an XML file.To use Active Directory as the store, you are prompted to create a new Application Partition, and theActive Directory Forest must be running at Windows 2003 domain functional level. Although an XMLstore is easier to transport to other forests, an Active Directory store allows a greater degree of control. You can delegate the administrative control of its various components (for example, applications, scopes, and policy stores) separately.

One of the best things about Authorization Manager is that it isn’t an either/or proposition. Bydefault, Windows uses a DAC-based security model, and the normal Windows security groups (local,domain local, global, universal) can still be used as they always have. But you can create otherAuthorization Manager-specific groups that exist only within previously defined policy stores. Authorization Manager groups have features that the current Windows groups don’t. For example,Authorization Manager groups are dynamic, based on roles, and the membership change based upona previous action or query. Scripts can also be used to manipulate access control outcomes based onnearly any action or even external event – for example, the time of day. The sheer versatility ofAuthorization Manager makes it the access control choice for the future.

Of course, the RBAC model collapses if all developers don’t do a better job of understandingsecurity and the least privilege principle. Currently, most vendors don’t understand the permissionsand rights users in a particular role need to do their job. Developers will need this understanding ifthe Authorization Manager is to become the effective tool it can be.



Application 1

AuthorizationManager

Authorization API (AZRoles.dll)

Application 2 Application 3

AuthorizationManager Policy

Database

Authorization Manager Objects You can define Authorization Manager in more than one application (as shown in Figure 7-14 above)at the same time. Each application has its groups, roles, tasks, operations, role assignments, andscopes (see Figure 7-15). Each application has its own namespace for its own objects and their hierarchy; often, objects can be defined at the store, application, or scope level. An ApplicationGroup is the same concept as a normal Windows security group, except that you can define bothwho is a member and who isn’t allowed to be a member. This setup is similar to the group policyidea of Restricted Groups, but it can be defined at the application level.

Figure 7-15 Authorization Manager object hierarchy



Application Groups

Definitions (Roles, Tasks, Operations)

Role Assignments

Application Groups


Role Assignments

Scope A

Application 1

Scope B

Application Groups


Role Assignments

Application Groups


Role Assignments

Scope C

Application 2

Scope D

Application Groups


Role Assignments

Application Groups


Role Assignments

Scope E

Application 3

Scope F

It’s important to make groups based on roles, not just departments. When using RBAC accesscontrols, you want fewer groups named Accounting, HR, or IT, and more groups named AccountingManager, Accounting Data Entry, Payroll Clerk, HR Manager, HR Interviewer, Benefits Manager, ITExecutive Management, Programmers, and IT Help Desk. Create groups with the functions of roles inmind. A Basic group is a Windows security group. An LDAP query group is dynamically generated,based upon an LDAP query.

Next, map tasks, operations, and roles to each group. A task is an action that accomplishes alarger objective. An operation is single objective that is completed using the application. Each operation is assigned a whole number as an identification number. A role is a task-oriented job witha predefined set of operations. A role collects common tasks and operations into a single manageableentity.

For example, a task is to calculate an employee’s total salary for a given pay period. Examples ofoperations include reading the employee’s payroll rate from payroll database, querying the number ofdays in the current pay period, and multiplying the user’s payroll rate by the number of days in thecurrent pay period. Often you’ll need to work backward, creating the lower-level operation first andthen combining them into the higher-level definitions.

Figure 7-16 shows an example application hierarchy. In an accounting application, the variousoperations for producing current period financial statements (a task) might include

• Move last period’s financial figures to prior period location• Place current period income/loss amount into balance sheet• Reconcile cash flow statement• Make appropriate debit/credit reconciling journal entries• Make period adjustments• Calculate current period figures• Print current period financial statement drafts• Review and approve financial statements• Make financial statement corrections• Release financial statements to public

Individual operations can be collected into smaller tasks — for example, reconciling and printingthe current financial statements. Two roles could be assigned: Accounting Manager and AccountingStaff-Level 2. The Accounting Manager role reviews and approves the documents, and the AccountingStaff-Level 2 performs the rest of the operations.



Figure 7-16 Authorization Manager application example

Think of this example, with its related operations, tasks, roles, and groups, and imagine howwonderful it would be if we could apply a similarly detailed security model to all security principalsand objects. Although this process might seem complex at first, in reality, developers define thesetraits when they build applications anyway. The administrator’s job becomes simply placing the various users or groups into the appropriate Authorization Manager application groups or assignments. When we get to a development model that is based on RBAC by default, we willwonder how we could have done with out it.

Authorization Manager Online Sources Excellent developer and administrator resources cover the Authorization Manager, including

• http://support.microsoft.com/default.aspx?scid=kb;en-us;324470• http://msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager • http://www.serverwatch.com/tutorials/article.php/3287431 • http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/

Security/MSDNWebcastUsingAuthorizationManageronWindowsServer2003.html

Microsoft Identity Integration Server It’s a rare corporate network that has only one type of computing platform. Most enterprises havePCs running multiple versions of Windows and other platforms, such as Linux, Unix, Macintosh; mostprobably have one or more mid-range or large systems. Often, legacy applications require using multiple platforms until those applications are migrated to the newer options.

The administrator’s most frustrating task is managing all those environments. Central to runningmultiple environments is managing multiple user accounts in each computing platform for the varioususers. A single user can have 10 different logon names with 10 different passwords.

Into this confusion, enter Microsoft’s Identity Management Server (MIIS). Formerly calledMicrosoft Metadirectory Services (MMS), MIIS is a database management platform that manages usersand their passwords across multiple directory services in a central location (which Microsoft calls a



http://support.microsoft.com/default.aspx?scid=kb;en-us;324470

http://msdn.microsoft.com/msdnmag/issues/03/11/AuthorizationManager

http://www.serverwatch.com/tutorials/article.php/3287431

http://www.windowsnetworking.com/kbase/WindowsTips/Windows2003/AdminTips/Security/MSDNWebcastUsingAuthorizationManageronWindowsServer2003.html

metaverse). MIIS is a centralized repository where multiple directories can be defined along with theiruser account attributes. Each directory service interfaces with a management agent. The many management agents interface with the MIIS engine that connects to a SQL Server 2000 Database. Inthe database, different connectors for each directory service are queried and combined to make theone larger virtual directory view that makes up the metaverse. The metaverse, user accounts and theirpasswords, and the MIIS product are managed through a web-based console (see Figure 7-17).

It is important to note that while MIIS provides a centralized location for managing user accounts,their attributes, and their passwords, it is not a Single Sign-On (SSO) solution. Users are still requiredto log on to each directory service separately or utilize a common authentication service (such as Kerberos, if possible). Products that facilitate cross-platform authentication, authorization, andaccounting are called Federated Identity Management (FIM) systems. Microsoft has a FIM offeringcalled Active Directory Federation Services (formerly known as TrustBridge). You can find more information about ADFS at http://msdn.microsoft.com/theshow/episode047/default.asp.

Figure 7-17 Microsoft Identity Integration Server components

MIIS was created help with the following functions:• Automating account provisioning and de-provisioning• Synchronizing and managing passwords • Storing and managing identity information in a centralized location



Active Directory AD connector space

Novell connector space

Notes connector space MIIS

Eng

ine

Met

aver

seNT 4 connector space

SQL Server 2000 Database

Novell eDirecory

Lotus Notes/Dominos

Windows NT 4 Domains

Active Directory Management Agent

Novell eDirecory Management Agent

Lotus Notes/DominosManagement Agent

Windows NT 4 DomainManagement Agent

MIIS Administrative Console

http://msdn.microsoft.com/theshow/episode047/default.asp

Provisioning is the process of creating objects and security principals in a directory space. In thiscase, provisioning specifically refers to creation of user accounts. De-provisioning is the process ofremoving or de-activating objects in a directory space.

MIIS lets you add and delete objects across multiple directory spaces from a single managementconsole. MIIS also makes it possible to synchronize user passwords across multiple directory spaces.User password management is one of the largest cost drivers in any IT environment. MIIS allows anIT member, or the user, to manage passwords at centralized console. MIIS also makes it possible toenforce Active Directory password policies, such as complexity or minimum size. Because MIIS provides a virtual directory as part of its metaverse, that location is an obvious place to manage identities and their attributes. MIIS allows all the user’s attributes, from the various directory services,to be collected and viewed in one location. If a user’s attribute – for example, last name or phonenumber — is changed in one directory service, it can be replicated to the other directory services.

MIIS supports many directories/identity stores, including those listed below• Active Directory• Active Directory Application Mode (ADAM)• Microsoft Exchange Server (2003, 2000, and 5.5)• Windows NT Domains• Lotus Notes/Dominos• IBM DB2 Databases (7.0 and 8.1)• IBM Tivoli Directory Server• Novell eDirectory (formerly Novell Directory Services)• Sun ONE Directory• Oracle• SQL Server (2000 and 7.0)• Directory Services Markup Language (DSML)• LDAP Interchange format (LDIF)• Attribute-Value Pair Text• Flat file formats such as fixed-width, comma-separate values, column delimited, and tab

delimited• Applications like PeopleSoft, SAP, and ERP• Telephone switches

Microsoft plans to keep adding directory stores, including Computer Associates eTrust, IBMOS/400, and IBM RACF to meet continuing customer needs.

MIIS comes in two versions: Microsoft Identity Integration Server 2003 Enterprise Edition, andIdentity Integration Feature Pack 1a for Microsoft Windows Server Active Directory. The first version isthe fully featured product. Contact your authorized Microsoft reseller for pricing details. You candownload a trial version at http://www.microsoft.com/windowsserversystem/miis2003/evaluation/trial/default.mspx. The Identity Integration Feature Pack is free (http://www.microsoft.com/downloads/details.aspx?FamilyID=d9143610-c04d-41c4-b7ea-6f56819769d5&DisplayLang=en) and provides a similar feature set, but only for Active Directory, ADAM, and Exchange (2003 or 2000).Customers who need web-based password management or one of the other directory services needthe full-featured product.



http://www.microsoft.com/windowsserversystem/miis2003/evaluation/trial/default.mspx

http://www.microsoft.com/windowsserversystem/miis2003/evaluation/trial/default.mspx

http://www.microsoft.com/downloads/details.aspx?FamilyID=d9143610-c04d-41c4-b7ea-6f56819769d5&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=d9143610-c04d-41c4-b7ea-6f56819769d5&DisplayLang=en

MIIS Requirements The requirements for MIIS aren’t nearly as complex as those for RMS. MIIS requires Windows Server2003, IIS 6, and Microsoft SQL Server 2000 (with all service packs installed). After IIS 6 and SQLServer 2000 are installed and active, you can install MIIS. During the installation process, MIIS createsseveral new groups (see Figure 7-18). You can access the MIIS administrative console by clicking Startand choosing All Programs, Microsoft Identity Integration Server, Identity Manager.

Figure 7-18 MIIS groups

Configuring MIIS To configure MIIS, you define a management agent to connect to each of your directory spaces. Gen-erally, you create one management agent per connected directory space. Each management agenttype has its own wizard to walk you through the process (see Figure 7-19 and 7-20 for examplescreen shots). You will be asked to answer a series of questions that ask

• The location and name of the directory service database• The directory service account to use to access the database• What objects to manage• What object attributes to manage• Rules for treating data brought into or out of the metaverse



Figure 7-19 Creating an MIIS Management Agent for Active Directory

Figure 7-20 Creating an MIIS Management Agent for Active Directory



Each management agent creates a connector space (CS). The CS is a temporary storage area thateach management agent uses to move data into and out of the metaverse from its own directory service. The CS essentially mirrors its connected data source, to the extent of the attributes selected.The CS also tracks the “state” of each object and its attributes. The CS recognizes that an attribute haschanged and then treats it according to its predefined rules.

In the CS, two types of connectors operate: connector objects and disconnector objects. The tasksin the previous paragraph actually are performed by connector objects; however, disconnector objectsare an interesting development in MIIS. A disconnector object lets an administrator define explicitlythe objects and attributes in a particular directory space that should not be allowed into or out of themetaverse to a particular directory space. Disconnector objects ensure that incorrect information is notreplicated.

The metaverse is a set of MIIS tables that contain integrated (“joined”) identity information fromthe myriad connected directory spaces. Information flowing into and out of the metaverse is treatedby flow rules. The granularity and modularity of MIIS design ensures the most efficient treatment ofidentity information. Compared to other products, Microsoft’s wizards simplify processes. During theprocess of defining the various management agents, you are indirectly building the metaverse. In theMetaverse Designer (see Figure 7-21), you can customize the metaverse database fields (that is,schema or attributes). You can choose which attributes should be included, which can be deleted,which to index, and which to run rules on (such as normalization). You can even search on themetaverse fields in the virtual directory.

Figure 7-21 Creating an MIIS metaverse



MIIS is a mature product. Its string normalization feature can automatically force uppercase lettering, remove accents, or create additional attributes as the data is imported. It has a deletionthreshold setting to prevent erroneous actions from accidentally deleting an entire range of objects.Now that’s smart!

To create customized rules, you’ll need Microsoft Visual Basic .NET, Microsoft Visual C# .NET2003, or Microsoft Visual Studio .NET 2003.

MIIS Password Management MIIS lets authorized IT help desk staff and end-users reset passwords. A web-based interface can beaccessed on the MIIS server (see Figure 7-22). Basically, the authorized user queries MIIS with theuser’s unique logon name and domain. MIIS returns any account names for any of the connectorspaces. The user then selects one or more account names and types a new password. Many enterprises implement MIIS only for this feature. Unfortunately, it isn’t available in the free FeaturePack version.

Figure 7-22 Using the MIIS web site to change passwords

MIIS Tools The MIIS 2003 Resource Toolkit 2.0 (http://www.microsoft.com/downloads/details.aspx?FamilyId=D3C7BD7A-E8D5-43CF-AD4D-4F1F0AE00D79&displaylang=en) contains a useful set of command-lineand UI-based utilities to help you manage and troubleshoot MIIS. The toolkit can be installed onServer 2003 and XP Professional, although not all tools will work on the XP platform.



http://www.microsoft.com/downloads/details.aspx?FamilyId=D3C7BD7A-E8D5-43CF-AD4D-4F1F0AE00D79&displaylang=en

MIIS Online Resources http://www.microsoft.com/windowsserversystem/miis2003/default.mspx

MIIS has many value added partners (http://www.microsoft.com/windowsserversystem/miis2003/partners/default.mspx) . Although you don’t need to use a partner to install and use MIIS, Microsofthighly recommends training or partnering until at least after the first management agent is configured.

If you have multiple directory spaces within your enterprise, investigate and test MIIS. It is acompetitive product and is fully integrated with Microsoft Windows 2003.

Summary Microsoft provides a wealth of tools for extending and controlling your digital environment. WindowsMedia Player DRM allows media creators and owners to control who uses their content and preventsunauthorized distribution. Windows Rights Management and Information Rights Management allowauthors to control what is done with their content once it is available for distribution, and even to“take back” content already handed out. Authorization Manager allows applications to define Role-Based Access Control, gaining a new level of granularity based on the security concept of theleast privilege principle. Microsoft’s Identity Manager Server allows separate directory spaces, and their users, to be managed in a centralized location. Added onto the existing granular Windowsauthentication, authorization, and accounting technologies, Microsoft offers more platform control than any other competitor in the marketplace.



http://www.microsoft.com/windowsserversystem/miis2003/default.mspx

Ms Security Permissions Ch8

Education

Transcript of Ms Security Permissions Ch8