Windows 2000Windows 2000

University of Colorado

BackgroundBackground

• Limited enterprise services: MIT K5 in labs, modems and some desktops, starting directories now, no identifier registry

• Departmental NT4 deployments are not coordinated; very little Novell; fair number of Macs

• MS RDP program: 6/98 to 2/00; MS provided excellent field engineer and diagnostic support.

Protecting existing infrastructureProtecting existing infrastructure

• Dynamic DNS - where to accept dynamic updates from

• DHCP

Extenuating circumstancesExtenuating circumstances

• existing MIT Kerberos • NT4 infrastructure - NTLM and SAM replaced• Exchange 2000

DNSDNS

• Currently use ISC BIND 8.2.2• Three zone solution

– Colorado.edu (static zone w/ A records)– AD.colorado.edu (dynamic SRV, A records)– 128.138… (static zone w/ PTR records)

• AD zone accepts dynamic SRV updatesfrom Win2000 Domain Controllers only

Central DC servicesCentral DC services

• Three domain controllers, one in CC, one in Telecom, one in Engineering

• Dells with dual 700 MHz processors, 30 GB Raids, Fast ethernet

• Secondary dc expected in a year

Support for Down-level Support for Down-level ClientsClients• Problem: Since NTLM is disabled at the DC’s, support for

down-level/foreign client access to resources in the Windows2000 realm doesn’t exist. Furthermore, the password assigned to an account in the Windows2000 domain is unknown to the user, so they cannot provide it on demand.

• Solution: NTLM security can be enabled locally (at the OU level). Local administrators can choose to use NTLM authentication for the resources they manage and create local accounts for their users. Users would then have access to resources from their down-level/foreign clients, but these privileges would be available locally only, with no value or impact elsewhere in the domain. They would also not have the benefit of single sign-on access to these resources.

CyberSafe SolutionCyberSafe Solution

• www.cybersafe.com

• Primary advantage - account and password sync

• DisadvantagesSecurityAvailability of required clients; Mac?Product release schedule

• MIT interop

• Future directions – business focus

Dual MIT and MS KDC’sDual MIT and MS KDC’s

• Home-grown account sync• No password synch• Existing tools work• 100% MIT compatibility for non-W2K clients

Final Kerberos DesignFinal Kerberos Design

• Create a two realm Kerberos environment: existing MIT realm and new Windows2000 realm(domain). Continue to use the existing MIT-based KDC as the primary authentication authority for campus.

• Populate the Windows2000 KDC with account principal information from the MIT KDC. No password synchronization, so passwords will be randomly generated for Windows2000 accounts and remain unknown to the account owners and administrators.

• Access to resources in the Windows2000 realm will be accomplished through a one-way, non-transitive trust relationship.

AD DesignAD Design

• One domain• OU=people for everyone• OU=departments (delegated)• OU=ITS

– three subtrees: geographic (for Labs), resources (servers), political/functional (for workgroups within ITS)

– some subdivisions within each area

GPO’sGPO’s

• for labs• for users• will use loopback GPO actions

Difficult issuesDifficult issues

• Trust model – one-way versus two-way

– central resources versus LAN folks

• Defining the limits of the services– do we support Exchange

– building infrastructure - backups, identifiers, etc.

• Scaling W2K utilities - people picker, CertServ

Not difficult issuesNot difficult issues

• moratorium on servers• W2K clients (Pro)

Further informationFurther information

• http://www.colorado.edu/ITS/Windows2000

• http://coyote.colorado.edu/rdp/• For technical questions, Richard Jones

(jones@colorado.edu)• For service questions, Dave Bodnar

(bodnar@colorado.edu)• For policy questions, Dennis Maloney

(Dennis.Maloney@Colorado.edu)