Windows 2000: Concepts & Deployment Larry Lieberman NT Support Engineer Premier Enterprise Support Microsoft Corporation

Agenda  Active Directory  Microsoft DNS  Distributed Security  System Management

Active Directory  Architecture  Components  Planning AD Design

AD Architecture  X.500 derived data model  Directory stored schema  Windows 2000 Trusted Computing Base security model  Delegated Administration Model  DNS integration

AD Components (1/10)  Objects  Organizational Units (OUs)  Domains  Sites  Trees & Forests  Global Catalog

AD Components (2/10) Objects Object Class Attributes Defined in the schema Data storage is allocated as necessary Directory Object An object instance is created in the Directory

AD Components (3/10) Object Access  Access to directory objects is controlled via Access Control Lists (ACLs) Directory Object Fine granularity is provided by Access Control Entries (ACEs) that apply to specific attributes Fine granularity is provided by Access Control Entries (ACEs) that apply to specific attributes ACL Sales Managers read access ACE ACEs can apply to specific attributes

AD Components (4/10) Organizing the Directory  A hierarchy of objects can be created using Organizational Units (OUs) Although OUs are the primary containers used to create the hierarchy, all directory objects are potential containers Although OUs are the primary containers used to create the hierarchy, all directory objects are potential containers ou Deep or flat structure? ou

AD Components (5/10) OUs  OU security provides the mechanism for controlling object visibility and delegating administration OU ACL Sales Managers read access ACL UK User Admins Create Users UK User Admins Create Users ACL Location1 Admins Reset passwords Location1 Admins Reset passwords ACL UK Users Read Volume objects UK Users Read Volume objects Inheritable ACLs

AD Components (6/10) Domains  One or more domain controllers Sites Domain directory Directory hosted on all DCs  Multi-master replication One or more sites One or more sites Configuration Schema

AD Components (7/10) Sites  Controls Active Directory replication Schedule Inter-site replication Intra-site replication automatically configured One or more subnets  Site knowledge used Logon locator Logon locator Printer locator and pruner Printer locator and pruner Dfs and more Dfs and more

AD Components (8/10) Trees And Forests  Configuration and schema common to all domains  Transitive trusts link domains

AD Components (9/10) Boundaries  Replication  Administration  Security Policy  Group Policy

AD Components (10/10) Global Catalog  Enterprise wide searches  Resolves enterprise queries GC Partial replica of all domain objects Hosted on one or more DCs

Planning AD Design (1/6) Considerations  Defining a logical hierarchy of resources  Administrative architectures  Allocation of physical resources and budget  Current infrastructure and upgrade strategies  Data availability requirements  Network bandwidth  Politics

Planning AD Design (2/6) One Or More Forests  All domains in a forest share a common schema and global catalog  Create multiple forests if: Separate schemas are required Separate schemas are required One or more domains are required to be isolated from the spanning tree of transitive trusts One or more domains are required to be isolated from the spanning tree of transitive trusts Total administrative autonomy is required Total administrative autonomy is required

Planning AD Design (3/6) Domain Structure  Where possible use a single domain Use OUs to delegate administration Use OUs to delegate administration Use sites to tune replication Use sites to tune replication  Use multiple domains when there is a requirement for Scalability across WANs Scalability across WANs Autonomous administrative entities Autonomous administrative entities Different security account policies Different security account policies password, lockout and Kerberos ticket password, lockout and Kerberos ticket

Planning AD Design (4/6) Multiple Domains(1/3)  Containment of network traffic Directory replication Directory replication Policies (FRS) Policies (FRS)  In-place upgrades from Windows NT domains Autonomous divisions with separate names Autonomous divisions with separate names No technical reasons, only politics No technical reasons, only politics Names are not important Names are not important

 Each domain has an incremental overhead Increased administration Increased administration Increased hardware Increased hardware Separate DCs are required for each domain Separate DCs are required for each domain  Try to avoid creating divisional or departmental domains for purely political reasons Change is inevitable, they are easy to create and hard to retire Change is inevitable, they are easy to create and hard to retire Planning AD Design (5/6) Multiple Domains(2/3)

 Separate the production forest from development and testing Prevents unwanted schema changes propagating through the enterprise Prevents unwanted schema changes propagating through the enterprise  Create a separate forest to restrict access for business partners Planning AD Design (6/6) Multiple Domains(3/3)

Microsoft DNS  Windows 2000 DNS Requirements  MS DNS Features  DNS Design

DNS Requirements  A DNS server that is authoritative for a Windows 2000 domain MUST support SRV records (RFC 2052)  It also should support dynamic updates (RFC 2136) The NETLOGON service on the domain controller automatically registers all of the domain services and the site that it supports The NETLOGON service on the domain controller automatically registers all of the domain services and the site that it supports

MS DNS Features (1/12)  Active Directory integration  Dynamic Update  Aging  Administrative tools  Caching resolver

MS DNS Features (2/12) Active Directory Integration  AD-integrated DNS zone is multi-master

1) Receive update 3) ADS replicates 4) Read from ADS 2) Write to ADS ADS DNS ADS DNS “Primary” zones MS DNS Features (3/12) Active Directory integration

MS DNS Features (4/12) Active Directory integration  AD-integrated DNS zone is multi-master High availability of write, as well as read High availability of write, as well as read Doesn’t require separate from AD replication Doesn’t require separate from AD replication

MS DNS Features (5/12) Active Directory integration  ADS replication is loosely consistent  Name-level collision Two hosts create same name simultaneously (first writer wins) Two hosts create same name simultaneously (first writer wins)  Attribute-level collision Two hosts modify A RRset for microsoft.com simultaneously (last- writer wins) Two hosts modify A RRset for microsoft.com simultaneously (last- writer wins)

MS DNS Features (6/12) Dynamic Update  Based on RFC 2136  Client discovers primary server for the zone where the record should be added/deleted  Client sends a dynamic update package to the primary server  Primary server processes the update

MS DNS Features (7/12) Dynamic Update  Windows 2000 computer registers A RR with: A RR with: Hostname.PrimaryDnsSuffix (default) Hostname.PrimaryDnsSuffix (default) and Hostname.AdapterSpecificDnsSuffix (if configured) and Hostname.AdapterSpecificDnsSuffix (if configured) PTR RR if adapter is not DHCP configured or DHCP server doesn’t support DNS RR registration PTR RR if adapter is not DHCP configured or DHCP server doesn’t support DNS RR registration

MS DNS Features (8/12) Dynamic Update  Windows 2000 DHCP server registers (based on draft-ietf-dhc-dhcp-dns-*.txt) PTR records on behalf of upgraded clients (default) PTR records on behalf of upgraded clients (default) A and PTR records on behalf of downlevel clients (default) A and PTR records on behalf of downlevel clients (default) A and PTR records on behalf of upgraded clients (if configured) A and PTR records on behalf of upgraded clients (if configured)  Windows 2000 DHCP server removes records that it registered upon lease expiration

MS DNS Features (9/12) Secure Dynamic Update  Based on draft-skwan-gss-tsig-04.txt  Available only on AD-integrated zones  Per -zone and -name granularity  ACL on each zone and name

MS DNS Features (10/12) Aging/Scavenging  Enables deletion of the stale records in AD-integrated zones  Requires periodic refreshes of the records

MS DNS Features (12/12) Caching Resolver  Windows 2000 service Caches RRs according to TTL Caches RRs according to TTL Negative caching Negative caching Tracks transient/PnP adapters Tracks transient/PnP adapters Reorders servers according to responsiveness Reorders servers according to responsiveness  Fewer round-trips, fewer timeouts, faster response time

DNS Design (1/11) To support DC locator  DNS server authoritative for the DC records MUST support SRV RRs  Support for Dynamic Updates is recommended

DNS Design (2/11)  Delegate a DNS zone for each AD domain to the DNS servers running on the DCs in that AD domain

DNS Design (3/11) corp.example.com Zones: Primary AD-int “corp.example.com”

DNS Design (4/11) corp.example.com Domain1.corp.example.com Zones: Primary AD-int “Domain1.corp.example.com” Zones: Primary AD-int “corp.example.com”

DNS Design (5/11)  Delegate a DNS zone for each AD domain to the DNS servers running on a DC in that AD domain  Install a DNS server on at least two DCs in each AD domain and one DC in each site

DNS Design (6/11) corp.example.com Domain1.corp.example.com Site1 Site2 Site3 Zones: Primary AD-int “Domain1.corp.example.com” Zones: Primary AD-int “corp.example.com”

DNS Design (7/11)  Delegate a DNS zone for each AD domain to the DNS servers running on a DC in that AD domain  Install a DNS server on at least two DCs in each AD domain and one DC in each site  If different sites in the forest are connected over slow link, delegate the zone “_msdcs. ” and make at least one DNS server in every site secondary for this zone

DNS Design (8/11) corp.example.com Domain1.corp.example.com Site1 Site2 Site3 Zones: Primary AD-int “Domain1.corp.example.com” Secondary “_msdcs.corp.example.com.” Zones: Primary AD-int “corp.example.com” Primary AD-int “_msdcs.corp.example.com.”

DNS Design (9/11)  Install a DNS server on at least two DCs in each AD domain and one DC in each site  Delegate a DNS zone for each AD domain to the DNS servers running on a DC in that AD domain  If different domains of the forest are connected over slow links, delegate the zone _msdcs. and make at least one DNS server in every site secondary for this zone  Each client should be configured to query at least two DNS servers one of which is in the same site

DNS Design (10/11) corp.example.com Domain1.corp.example.com Site1 Site2 Site3 Zones: Primary AD-int “Domain1.corp.example.com” Secondary “_msdcs.corp.example.com.” Zones: Primary AD-int “corp.example.com” Primary AD-int “_msdcs.corp.example.com.”

DNS Design (11/11) Hardware planning  Memory usage No zones loaded~4 MB No zones loaded~4 MB Each record requires ~100 bytes Each record requires ~100 bytes  Performance Alpha 533 MHz dual-processor with 25% Processor utilization Alpha 533 MHz dual-processor with 25% Processor utilization 1600 queries and 200 dynupd/second 1600 queries and 200 dynupd/second Intel P-II 400 MHz dual-processor with 30% Processor utilization Intel P-II 400 MHz dual-processor with 30% Processor utilization 900 queries and 100 dynupd/second 900 queries and 100 dynupd/second

Security Topics  Kerberos Integration with Windows NT  Security Provider Architecture  Public Key Security Components  Smart card logon and authentication  Encrypting File System  Security Policies and Domain Trust  Secure Windows NT Configuration

Security Goals  Single enterprise logon  Integrated security services with Windows NT Directory Service  Delegated administration and scalability for large domains  Strong network authentication protocols  Standard protocols for interoperability of authentication

Authentication/ Authorization  Authenticate using domain credentials User account defined in Active Directory User account defined in Active Directory  Authorization based on group membership Centralize management of access rights Centralize management of access rights  Distributed security tied to the Windows NT Security Model Network services use impersonation Network services use impersonation Object-based access control lists Object-based access control lists

One Security Model: Multiple Security Protocols  Shared key protocols Windows NTLM authentication: compatibility in mixed domains Windows NTLM authentication: compatibility in mixed domains Kerberos V5 for enterprise networks Kerberos V5 for enterprise networks  Public key certificate protocols Secure Sockets Layer (SSL) / Transport Layer Security (TLS) Secure Sockets Layer (SSL) / Transport Layer Security (TLS) IP Security IP Security  Multiple forms of credentials in the Active Directory

1.NTLM challenge/response Application server Windows NT domain controller MSV1_0 Netlogon NTLM Authentication 4. Server impersonates client 2.Uses LSA to log on to domain 3.Netlogon service returns user and group SIDs from domain controller Windows NT Directory Service

Kerberos Integration KDC relies on the Active Directory as the store for security principals and policy Kerberos SSPI provider manages credentials and security context; LSA manages ticket cache Server Session ticket authorization data supports NT access control model Client Windows NT Directory Server Key Distribution Center (KDC) Windows NT Domain Controller

Kerberos Protocol Advantages  Faster connection authentication Server scalability for high-volume connections Server scalability for high-volume connections Reuse session tickets from cache Reuse session tickets from cache  Mutual authentication of both client, server  Delegation of authentication Impersonation in three-tier client/server architectures Impersonation in three-tier client/server architectures  Transitive trust between domains Simplify inter-domain trust management Simplify inter-domain trust management  Mature IETF standard for interoperability Testing with MIT Kerberos V5 Release Testing with MIT Kerberos V5 Release

Kerberos Unix Interoperability  Based on Kerberos V5 Protocol RFC 1510 and RFC 1964 token format RFC 1510 and RFC 1964 token format Testing with MIT Kerb V5 Release Testing with MIT Kerb V5 Release  Windows NT DS hosts the KDC UNIX clients to Unix Servers UNIX clients to Unix Servers UNIX clients to NT Servers UNIX clients to NT Servers NT clients to UNIX Servers NT clients to UNIX Servers  Simple cross-realm authentication UNIX realm to NT domain UNIX realm to NT domain

Application Server (target) 3.Verifies session ticket issued by KDC Kerberos Auth Network Server connection Windows NT Directory Server Key Distribution Center (KDC) Windows NT domain controller 1.Send TGT and request session ticket from KDC for target server TGT 2.Present session ticket at connection setup Target

Target Auth data:  User SID  Group SIDs  Privileges Kerberos LSA Session ticket Server application Building An Access Token with Kv5  Kerberos package gets auth data from session ticket Impersonation token Token  LSA builds access token for security context  Server thread impersonates client context

Remote File Access Check Rdr Server Kerberos SSP File application SMB protocol NTFS SSPI \\infosrv\share File Token KDC Ticket Access check SD Token Client

Secure RPC HTTP SSPI Internet Explorer, Internet Information Server NTLMKerberos SChannel SSL/TLS MSV1_0/ SAM KDC/DS DCOM application DPA Membership services POP3, NNTP Mail, Chat, News CIFS/SMB Remote file Architecture For Multiple Authentication Services LDAP Directory enabled apps using ADSI

Windows NT Interoperability  Windows NT 4.0 clients and servers Use NTLM authentication Use NTLM authentication  Windows NT 5.0 clients Locate NT 5.0 Active Directory and KDC Locate NT 5.0 Active Directory and KDC Support smart card logon Support smart card logon Use Kerberos or NTLM protocol Use Kerberos or NTLM protocol  Windows NT 5.0 Servers Accept both NTLM or Kerberos protocol Accept both NTLM or Kerberos protocol

Public Key Components X.509 and PKCS Standards Windows NT Directory Server Certificate Server For clients  User key and certificate mgmt  Secure channel  Secure storage  Auto enrollment For servers  Key and certificate management  Secure channel  Client authentication  Auto enrollment Enterprise  Certificate services  Trust policy

Crypto API Architecture Crypto API 1.0 RSA base RSA baseCSPFortezzaCSP Application SmartCardCSP u Cryptographic Service Providers Certificate management services Secure channel Key database Certificate store

SSL Client Authentication Integrated Security Administration  Strong authentication using X.509 certificates Single user ID for multiple protocols Single user ID for multiple protocols  Security account management Use existing infrastructure: ccount admin and access control Use existing infrastructure: ccount admin and access control  Accept third-party X.509 certificates from trusted Certificate Authorities  Inter-business authentication

SSL Client Authentication SChannel SSP Client certificate  Server Server Certificate Store of Trusted CAs Authentication service  Domain Org (OU) Users 2. Locate user object in directory by subject name Access token  3. Build NT access token based on group membership 1. Verify user certificate based on trusted CA, CRL Server resources  ACL 4. Impersonate client, object access verification

Internet Explorer 4.0 Reader Crypto API SmartCardCSP Reader driver Secure channel SSPI Client Authentication Using SmartCards  Secure channel between Internet Explorer and Internet Information Server  Keys and certificates managed by Crypto API  SmartCard CSP gets certificate and protocol signature from card ICC

Smart Card Logon  Private key and certificate on card  Public key domain authentication PK Kerberos ProfileCerts Keys Internet Explorer  User profile for other keys and certificates  RAS support Domain credentials  Obtain Kerberos TGT and NTLM credentials TGT

Management Of Trust  Trust policy decisions What CAs are trusted? What CAs are trusted? What are they trusted for? What are they trusted for?  Client Authentication,  Server Authentication,  Authenticode  Trust determination made locally Certificate path verification Certificate path verification  Configure trust policy centrally Define trust policy in Policy Editor Define trust policy in Policy Editor  Signed by an authorized user

Encrypting File System  Privacy of data that goes beyond access control Protect confidential data on laptops Protect confidential data on laptops Configurable approach to data recovery Configurable approach to data recovery  Integrated with core operating system components Windows NT File System - NTFS Windows NT File System - NTFS Crypto API key management Crypto API key management LSA security policy LSA security policy  Transparent and very high performance

Crypto API I/O manager EFS.sys NTFS User mode Kernel mode Win32 layer Applications LPC communication for all key management support FSRTL callouts Encrypted on-disk data storage EFSservice EFS Architecture

RNG Data decryption field generation (e.g., RSA) Data recovery field generation (e.g., RSA) DDF DRF User’s public key Recovery agent’s public key in recovery policy Randomly-generated file encryption key File Encryption File decryption (e.g., DES) A quick brown fox jumped... *#$fjda^ju539!3t t389E *&

*#$fjda^ju539!3t DDF A quick brown fox jumped... A quick brown fox jumped... DDF extraction (e.g., RSA) File decryption (e.g., DES) File encryption key DDF is decrypted using the private key to get to the file encryption key File Decryption DDF contains file encryption key encrypted under user’s public key User’s private key

Active Directory Security Features  Organization Units (OU) to organize the directory name space Users, groups, computers in separate containers Users, groups, computers in separate containers  Directory object security Per property access control Per property access control Per property auditing Per property auditing  Delegation of administration Who can create, manage users, groups, computer accounts, other objects Who can create, manage users, groups, computer accounts, other objects

Domain Domain Domain Domain Downlevel domain Explicit Windows NT 4.0-style trusts Domain microsoft.com europe. microsoft. com Kerberos trust fareast. microsoft. com Domain Trust

Managing Security  Security Configuration Editor (SCE) Defines security configuration templates Defines security configuration templates  Group Policy Editor Defines hierarchy of user or computer policy templates for OUs up to the Domain Defines hierarchy of user or computer policy templates for OUs up to the Domain  Security configuration is part of Group Policy Group Policy for a computer includes the security configuration Group Policy for a computer includes the security configuration Security configuration applied at startup Security configuration applied at startup

A Security Configuration  Covers various security areas Account Policies -- password, lockout, kerberos Account Policies -- password, lockout, kerberos Local Policies -- auditing, user rights,... Local Policies -- auditing, user rights,... Restricted Groups -- Administrators, Power Users,… Restricted Groups -- Administrators, Power Users,… Registry & File System -- security descriptors Registry & File System -- security descriptors Services -- startup mode and security descriptors Services -- startup mode and security descriptors

Summary (1/2)  Kerberos for domain authentication for the Enterprise Mutual authentication, transitive trust Mutual authentication, transitive trust  Public key security components Certificate Services to issue organization certificates Certificate Services to issue organization certificates Personal key and certificate management Personal key and certificate management Public key credentials for servers Public key credentials for servers  Directory-based SSL/TLS client authentication using X.509 certificates

Summary  Crypto API enhancements  Smart card logon and dialup access  Message encryption using SSPI  SMB data encryption using IPsec  Encrypting File System  DS Security Administration and Policy  Security Configuration Editor  Cross-platform authentication interoperability

Group Policy Objects

Group Policy Definition  “The ability for the administrator to state a wish about the state of their users’ environment once, and then rely on the system to enforce that wish!”

Group Policy Review  Policies Are Not Profiles A profile is a collection of user environment settings that the user may change A profile is a collection of user environment settings that the user may change Group Policy is a collection of user environment settings, specified by the administrator Group Policy is a collection of user environment settings, specified by the administrator  Group Policy is more than simple “lockdown” Group Policy enhances the “Follow Me!” experience by enabling organizations to: Group Policy enhances the “Follow Me!” experience by enabling organizations to: Set registry settings securely and without fear of tattooing (Administrative Templates) Set registry settings securely and without fear of tattooing (Administrative Templates) Specify security oriented settings (Security Settings) Specify security oriented settings (Security Settings) Install software (Software Installation) Install software (Software Installation) Re-direct “My Documents,” “Desktop,” etc. to the network (Folder redirection) Re-direct “My Documents,” “Desktop,” etc. to the network (Folder redirection) Implement tiered scripts (Scripts) Implement tiered scripts (Scripts)

 Sites are described by Subnet address’s and may cross Domain boundaries, normally they would not Site OU’s A1 A2 GPO’sA1 A2 A3 A5 A4  The affect of a GPO may be filtered based on security group membership (ACLs) A Domain  GPOs are per Domain Group Policy is NOT inherited across Domains  Any SDOU may be associated with any GPO, even across Domains (slower - maybe very slow) OU’s B1 B2 B3 B GPO’s B1 B2 Domain  Multiple SDOUs may use a single GPO  Multiple GPOs may be associated with a single SDOU What is my policy?  Sites are described by Subnet address’s and may cross Domain boundaries, normally they would not  GPOs are per Domain  Multiple GPOs may be associated with a single SDOU  Multiple SDOUs may use a single GPO  Any SDOU may be associated with any GPO, even across Domains (slower - maybe very slow)  The affect of a GPO may be filtered based on security group membership (ACLs) Group Policy And The Active Directory

Group Policy Linked To OUs  The OU structure is your administrative structure  Group Policy configuration must be tuned to fit your OUs structure  Design for the most stable and maintainable solution

Filtering  Security Groups may be used to filter the effect of Group Policy Any Group Policy may have it’s scope modified by setting ACL permissions Any Group Policy may have it’s scope modified by setting ACL permissions  Read and Apply Group Policy (AGP) ACEs are required for Group Policy to be applied  Only filter if necessary Keep simple if possible Keep simple if possible

GP applied to virtual group Example  Filtering can be inclusionary or using “deny” exclusionary ou GP ACL Read & APG

Conclusion  Active Directory  DNS  Security Features  Group Policy