Domain Tree Policy

· Child domains can be created for schools or large administrative units

This allows groups with similar political interests to create domain trusts with groups external to Stanford, to create domain local accounts for visitors for access to a subset of resources, while limiting the number of domains to a manageable number. Talk to the infrastructure support team if you aren’t a school and would like to be a child domain.

· At least 2 domain controllers are required for child domains.

Having more than 2 domain controllers in your child domain will require an additional maintenance cost for hosting & support personnel.

· All domain controllers will be managed and hosted by ITSS.

ITSS will provide a reliable environment and security for the domain controllers. By centralizing the domain controllers, security issues can be promptly addressed, and maintenance costs reduced. These domain controllers will only run the default Active Directory services, namely a kerberos distribution center (KDC) and LDAP. File services and other client services should be located on other hosts.

· Grandchild domains (i.e. child domains of child domains) will not be created.

We know of no reasons to have a grandchild domain. Speak with the infrastructure service team if you have a valid reason.

· The top level domain will not trust domains outside the tree, except domains which are in the process of migration to the tree.

To reduce security concerns, only those domain trusts which are functionally necessary will be allowed. Domain migrations are functionally necessary, but will not be allowed for an indefinite period.

· Administrative control of child domains will be delegated to a pre-created administrator group.

The child domain will designate administrators who will be added to an administrative group for their user accounts. All the admin global groups will be within the top-level WIN domain. The admin accounts for child domains will be a second account, in addition to the admin’s non-privileged, sso account. These admin accounts must be in the WIN domain.

· Administration of SSO accounts will be largely left to child domain administrators

The appropriate child domain admin group will have privileges to make changes to a subset of attributes for their department’s accounts. This subset of attributes includes windows-centric properties like home directory location, profile location, and terminal server settings. The replicated attributes password, account name (sunetid), department, and affiliation (and any future extensions of other personal data replicated to AD) will be read-only to child domain admins and the user. The authoritative Stanford registry (accessible via Stanford.you) will be the only source for changes to these read-only attributes.

· Local accounts should use the UPN of their child domain.

All local accounts should have the suffix of their child domain. This is needed to eliminate any potential account namespace collision. In general, local accounts can have suffixes from any domain in the tree including the top level domain, and default to the top level domain UPN suffix. So for example, local accounts from the GSB child domain should all have UPN’s of the form account@gsb.win.stanford.edu.

· Data replicated into the AD from the Stanford Registry will retain its visibility settings.

Currently, the name, department & affiliation attributes are the only non-public data that will be replicated. Stanford is legally required to maintain the privacy of the data it has been given. Departmental administrators will be given read-only access to this person data to allow them to perform their administrative functions.

· Person data attributes which are stored in the Stanford Registry but not replicated to AD will remain unwritable.

The Stanford Directory is the authoritative source of person data, and allowing a non-replicated set would create a data management problem. The data which is being replicated is the minimum needed to allow the basic functionality which clients have requested.

· Problems with the SSO account replication process should be directed to win-tree@lindy.stanford.edu

Admins from the account’s department should contact win-tree@lindy.stanford.edu if they suspect the password replication has failed. Similarly, they should contact win-tree@lindy.stanford.edu in the event that an account which should be created isn’t showing up.

· ITSS enterprise administrators will assume a “hands-off” approach to domain administration within child domains.

Only in cases of enterprise emergency, where no adequate alternative exists, will ITSS administrators take action within child-domains. Enterprise admins will have administrator privileges to all child domain controllers, for the purposes of maintaining the domain controllers and directory services.

· The Stanford Security office will provide an ongoing security review

The security office will have every security event sent to them via a real-time event log daemon. In addition to normal security risk evaluation, they will help ensure that no abuse of enterprise administrative privileges occurs. Suspected abuse of enterprise admin privileges can be brought to them.

· The ITSS Schema Administrator will coordinate any needed schema changes, and determine a process for implementing them.

Schema changes will be implemented first in the MS pre-production domain tree. After successful testing, normal change management procedures will be followed, and child domain administrators will be involved in the authorization process.

· Domain changes which may affect other parts of the tree will use the ITSS Change Management system

The Change Management system is used as a standard method of notification, coordination, authorization, and archival of notable changes. This will ensure adequate notification & authorization for all affected parties. Every child domain will have a corresponding Change Management domain to facilitate this practice. For more information about the system, go to http://www.stanford.edu/group/OSS/chng.html.

· Installation of new windows services should be proceeded by notification (& authorization) of the security office

This is a standard practice for new unix services. Within the Change Management system, select the security office as an authorizing subdomain to schedule installation of a new service. This will give the security office a trackable notice, and ample warning for services that have an increased threat.

· Installation of Windows DNS Services should not occur.

DNS services are not a supported activity within the tree.

· NTLM Authentication will be allowed for a limited time.

Currently, NTLM authentication is needed for Mac client access, Win9x client access, and Samba client access. NTLM.v2 authentication will be allowed for a limited time. We are planning to replicate the Sunet passwords to the Windows 2000 sso accounts to enable this functionality. At a future time, we will remove this functionality for several security reasons. Macintoshes will hopefully have a kerberos client by the sunset time.

· Lan Manager and Cleartext authentication won’t be allowed within the tree.

Cleartext authentication will be turned off on all domain controllers. This is according to the written Stanford computer security policy. Lan Manager authentication uses an insecure password hash, and as a serious security risk will also be turned off.

· Configuring IIS to allow cleartext authentication isn’t allowed.

· Configuring Mac File & Print Services to allow cleartext authentication isn’t allowed.

· FTP (in cleartext) with SSO accounts isn’t allowed. Anonymous ftp is allowed.

· Passwords on non-sso accounts will be subject to a password filter which simulates the Leland password restrictions filter.

All accounts should have a password of minimal strength, to protect the integrity of the entire tree’s services.

· ITSS will not provide Windows 2000 Server/Professional licenses or client access licenses for computers in child domains.

Unfortunately, given Microsoft’s current licensing policies, it is not cost-effective to site license or bulk license. However, the campus does have an attractive pricing structure.

· Adherence to Microsoft licensing policy prior to joining the tree will be necessary, and ongoing compliance is necessary.

Non-compliance does conceivably effect any service provider within the tree, so it is in Stanford’s best interest to make sure licensing is done.

· No Certificate Authority Server will be setup in the domain tree. At a later time, this may be a centrally offered service.

Certificates will not be associated with the SSO accounts, because a compromise of the CA server could result in a compromise of the sso accounts. In general, we discourage setting up CA servers for local accounts—please talk to us about the risks if you are considering this. At a later time, ITSS may offer a certificate service.

· EFS won’t be possible with the SSO accounts, because it requires a Windows CA server.

· Windows 2000 workstations should be configured to turn off DDNS registration.

DDNS is not supported at this time. A future release of NetDB may support it, but at this time it isn’t necessary for any functionality that we are aware of.

· All tree members, except domain controllers, should have a primary DNS suffix name of Stanford.edu, and be properly registered in NetDB.

Tree members can have any dns suffix; they don’t need to have the dns suffix of their domain. To conform to campus networking standards, all tree members should have a dns name which matches their registered netdb node. Therefore, all tree members should have a dns suffix of stanford.edu.

· Interoperability with Netware file & print servers can be done at a child domain/OU level.

There are no restrictions on connectivity to Netware resources. The possibility of synchronizing AD directory services with NDS services should be discussed with the infrastructure support team first.

· The documented list of site-wide group policy settings will be applied.

The documented list of site-wide policy settings is available here. For the most part, the gpo’s listed in that document functionally enforce the policies designated in this document.

Areas in need of policy statements:

· How does one bring up a new exchange 2000 implementation

· Are there restrictions on where the server can be, since it is so tightly reliant on the GC?

· Are there restrictions on how you implement exchange because of the AD integration?

Last modified by barkills at 10/4/2001 3:12 PM