Stanford Windows 2000 Tree account synchronization and migration issues

1
(No Transcript)
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 OUs 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 wasnt 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,
  Microsofts implementation allows for
  interoperability.

3
Integration with Existing Enterprise

• The Windows 2000 Project is about integrating
  Microsofts Active Directory (AD) with the
  existing enterprise, and making AD work given
  Stanfords 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_at_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
  persons 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 persons 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
Operational details

• 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

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 syncd 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_at_lists.stanford.edu