Windows 2000 University of Colorado

Background 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 infrastructure Dynamic DNS - where to accept dynamic updates from DHCP

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

DNS Currently use ISC BIND Three zone solution –Colorado.edu (static zone w/ A records) – AD.colorado.edu (dynamic SRV, A records) – … (static zone w/ PTR records) AD zone accepts dynamic SRV updates from Win2000 Domain Controllers only

Central 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 Clients 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 Solution Primary advantage - account and password sync Disadvantages Security Availability of required clients; Mac? Product release schedule MIT interop Future directions – business focus

Dual MIT and MS KDC’s Home-grown account sync No password synch Existing tools work 100% MIT compatibility for non-W2K clients

Final 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 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’s for labs for users will use loopback GPO actions

Difficult 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 issues moratorium on servers W2K clients (Pro)

Further information For technical questions, Richard Jones For service questions, Dave Bodnar For policy questions, Dennis Maloney