150 likes | 256 Views
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
E N D
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 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 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 • 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’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 • 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)