Windows enterprise paradigm

2. Windows enterprise paradigm • Windows paradigm has changed over the years, and with Windows 2000 takes a huge step forward into a true enterprise solution. • Initially, you had standalone workstations. • With Windows 95, you had workgroups, which are roughly analogous to OU’s in Windows 2000. The workgroup allowed limited sharing of resources like printers. • With Windows NT, you had domains. The domain had a common authentication and name resolution, but lacked true directory services, and wasn’t really enterprise capable. • Now with Windows 2000, you have a forest or tree of domains, with Active Directory providing three basic enterprise services: Name resolution, directory services, and authentication. Microsoft chose common standards in implementing Windows 2000, so DNS, LDAP, and Kerberos are the protocols underlying these three basic services. Stanford already has enterprise implementations using these standards, and fortunately, Microsoft’s implementation allows for interoperability.

3. Integration with Existing Enterprise The Windows 2000 Project is about integrating Microsoft’s Active Directory (AD) with the existing enterprise, and making AD work given Stanford’s organizational structure. Windows DNS: NetDB Windows workstations will retain names such as myworkstation.stanford.edu, and will continue to require an entry in NetDB. Windows Directory: Stanford.you The Stanford Directory (Stanford.you) provides an authoritative source for person-related data. The Windows infrastructure will subscribe to a partial set of this data. Windows Authorization: SUNet ID Access to all campus kerberos-based services from a Windows workstation in the infrastructure will require a single login. Windows users will login as SUNetID@stanford.edu.

4. Domains, OUs and Computers Computers join a domain other than the root domain Domains are based on school or large group distinctions. A general domain is available. The root domain is for enterprise objects only, which provides a security zone. Local Windows administrators retain local power over desktops and servers OUs provide a way to delegate authority. Have ability to create local accounts, administer computers, manage resource access, restrict login, manage your environment.

5. User Account administration Account OUs All accounts will be under a common root OU, placed in a second level OU named the value of the department listed for the person. This enables us to give departments the ability to directly manage their Windows accounts, via the standard Microsoft tools. This management will only be for Windows-only account attributes, such as Home Directory location, Profile location, and Terminal Server settings, which is data that is not stored in the existing Registry/Directory. All other person/account related data should be managed via the existing source systems. There will be no web portal as previously discussed, and departments will be able to set account based GPOs, without loopback.

6. What is a harvester? • Several source systems feed the registry. • The registry posts an event to an event queue when any record changes. • A harvester is a program which polls this event queue for events, and takes action by copying the person’s record to another directory. • Currently, a harvester loads the Stanford Directory. A different harvester will load the PeopleSoft implementation. • This event-driven architecture makes it easy to initially load or reload a directory, by manually placing an event for each person in the event queue.

7. Harvesting to AD Ensuring privacy of personal data is top priority, and we do not want to replace the existing directory services With this in mind, very little is harvested. Currently, we only plan to harvest a person’s: unique SUNetID, department, privilege group memberships, name, and privacy settings. Passwords are synchronized but outside of the harvester process

8. What is ITSS’ role? ITSS wants to enable departments to do business how they want, but provide a reliable and secure infrastructure ITSS will manage the following: All domain controllers, the integration pieces of the infrastructure, the harvester, account creation/deletion & passwords, delegation of account OUs, creation and delegation of domains, infrastructure-wide policy, and the general SU domain. ITSS also wants to provide technical leadership ITSS will provide: Migration assistance for departments,facilitation of infrastructure-wide schema management, limited emergency departmental administration, security warnings and prevention, Windows administrator contact lists, and documentation.

9. 24x7x365 on-call rotation • ITSS has 99.999% uptime for the 80+ Windows servers it currently manages • Generator-backup UPS, climate control, and multiple locations • Dedicated Network • Domain controllers security is tight: Campus Security reviews security logs & regularly scans domain controller subnet • Frequent infrastructure data backups: Global catalog servers backed up 6 times a day Operational details

10. Still in development • Gb Networking not here yet • Sweet Hall co-location details still being worked out • Full NetDB support • SRV record support for Domain Controllers • Machine data sync’d to AD (i.e. user and location)

11. Benefits • File sharing with colleagues in other departments • Access your data from any campus Windows machine • Less account maintenance, and the possibility of single sign-on • Software distribution via Group Policy • Other possible infrastructure services • Exchange mailboxes • Remote Desktop Management • Allows for other advanced features, such as:

12. What is the timeline? 1.Pre-pilot work begins – early January ‘02 2.     Windows 2000 Infrastructure testing complete – late February ‘02 3.     Begin pilot migration of users – late March ‘02 4.     Pilot complete – late April ‘02 5.     Begin ITSS user migration - late April ‘02 6.     First Exchange 2000 Server in Infrastructure – early May ‘02 7.     Finish ITSS migration – early June ‘02 1.

13. What is the timeline? 8. Begin Facilities user migration – early June ‘02     9.  Facilities migration complete – early July ‘02      10.  Begin GSB user migration – early July ’02 11. GSB migration complete – early August ‘02

14. Stanford Windows Infrastructure http://windows.stanford.edu E-mail: windows-feedback@lists.stanford.edu