internal
Policy Guide for Administrators in the Stanford Windows Infrastructure
This document is for Administrators in the Stanford Windows Infrastructure. Windows computing professionals who wish to learn about the Stanford Windows Infrastructure should review in the Windows Admin Guide document. A technical description of the architecture, as well as definition of the roles different people play in supporting this infrastructure are described in detail there.
This Policy Guide describes the policy that governs the use of an administrative account within this infrastructure. Any non-SUNetID account that has been delegated the ability to read or modify multiple SUNetID accounts is considered subject to these policies. In addition, any account that has been delegated the ability to administrate domain resources in a child domain is also considered subject to these policies. Note that, in addition to this Guide, Windows system administrators are expected to review Stanford's official administrative guides regarding: Administrative Computing Systems Standards, Computer and Network Usage Policy, Identification and Authentication Systems, Electronic Commerce, and Chat Rooms and Other Forums Using Stanford Domains or Computer Services.
Contents
The administrator should read through the document once before using the following hyperlinks to jump through the document. Some concepts and definitions are introduced sequentially, and will make more sense when read sequentially.
Policy
Being an administrator at any level in the Stanford Windows Infrastructure carries certain responsibilities and expectations. This policy section further expands on the official policy statements to delineate appropriate standards within the Stanford Windows Infrastructure.
Schools or large administrative units can get their own child domain within the Stanford Windows Infrastructure. This allows groups with similar academic interests to create domain trusts with groups external to Stanford, or create domain local accounts for visitors so they can access a subset of resources, while limiting the number of domains to a manageable number. Talk to the ITSS Windows Infrastructure Group if you aren’t a school and would like to be a domain. New domains subordinate to an already established child domain will not be created, i.e. there will be no grand-child domains-only two levels of domains in the domain tree.
Domain Controllers (Child Domains)
At least two domain controllers are required for each child domain. All Windows infrastructure domain controllers are managed and hosted by ITS Windows Systems, which provides a reliable environment, security, 24x7 emergency response capabilities, and other amenities for these machines. All the domain controllers in the infrastructure will only run the default Active Directory services, namely a kerberos distribution center (KDC) and LDAP. No additional software will be installed on these servers.
Note on child domains for departments: Support for all systems supported by ITS Windows Systems are billed according to ITS Data Center rates. The Active Directory rate reflects a child domain with two domain controllers. Having more than two domain controllers in your child domain will require additional maintenance cost (for hardware and application support). There is currently no charge to utilize the shared child domain.
Domains outside the forest will not trust the WIN domain, except for those (Windows NT 4.0) domains that are in the process of migrating to the tree. The WIN domain will not trust domains outside the forest for any reason. Domain migrations should occur in a timely manner to reduce a prolonged security risk via the trust, and the trust relationship will not be allowed for an indefinite period of time. Child domains can trust a domain external to the forest, but one should issue a change management request with the details of the change to notify all parties of this intention prior to the creation of such a trust.
Schema changes will be implemented first in a pre-production forest. After successful testing, normal change management procedures will be followed. Domain administrators will be involved in the authorization process. The schema policy is fully documented outside this document. The intention is to verify that a schema change doesn’t negatively affect existing services, while allowing schema changes to be implemented without unnecessary delay.
There are 3 enterprise administrators that constitute the ITSS Windows Infrastructure Group. They ensure that the infrastructure services run smoothly, and integrate with existing infrastructure services. These individuals have the inherent ability to take ownership of any resource in the Windows Infrastructure, and read or modify those resources. This level of authority demands a high level of accountability. For this reason, additional access control factors will be required for these accounts. Enterprise admin accounts are restricted to only logging in via 4 computers. Smart card or biometric authentication may also be employed. All use of privileges by these accounts is audited for review by both the Stanford Security Office as well as by departmental administrators. Enterprise administrators will only take ownership or use their privileges on child domain resources when requested to do so by someone with the appropriate authority, or in a case of emergency when failing to do so will put Stanford resources at risk.
Domain administrators hold a level of authority comparable to enterprise admins for their domain resources. Use of their privileges will also be audited. ITSS strongly recommends that additional steps, such as additional authentication factors, be taken to verify use of these accounts. ITSS also strongly recommends that the number of accounts with this level of authority be kept to an absolute minimum.
Membership of each of the domain administrator groups is strongly protected via a mandatory site policy. Changes the mandatory site policy can only be made by enterprise admins. Any changes to the membership of these groups without first coordinating a corresponding change with the enterprise admin group will result in the new member being removed automatically. This is by design to help protect domain resources, and to help establish a strong relationship between domain admins and enterprise admins.
Child domain admins inherently have several rights and privileges that should be carefully exercised, because they can hold great implications for the rest of the infrastructure. These are enumerated below as items to exercise care with.
Domain admins can manually force replication of the configuration, schema partitions, and global catalog partitions, in addition to their domain partition. While forced replication of their domain’s partition only affects child domain resources, forced replication of the other partitions affects the entire infrastructure. Because of this, please limit this activity to a minimum.
Child domain admins can promote a child domain controller to be a global catalog server. This is strictly prohibited. Global catalog placement is part of the design of the infrastructure and only enterprise admins should make this type of change after following a clear change management process.
Child domain admins can make modifications to the domain controller computer account, install software on the domain controller, create GPOs on the DC OU, and install services on the domain controller. This is strictly prohibited. All changes to domain controllers, and their associated computer accounts are limited to the enterprise admins, and will follow a clear change management process.
Child domain admins can modify the sidhistory attribute of accounts in their child domain. This attribute’s intended use is in migrations to allow the new account to assume the privileges of the old account. The existing migration path that ITSS provides departments does not include the use of sidhistory as a mechanism for migration. Sidhistory can be used maliciously to improperly assume the privileges of another account. This security vulnerability is documented in MS02-001. While we have applied the associated patches to limit Stanford’s vulnerability, there are still ways to take advantage of this. Misleading a system to grant unauthorized rights is known as an elevation of privilege attack, and Stanford considers this justification for termination and may choose prosecute. Contact the enterprise admins if you plan to make use of sidhistory.
Personal data replicated into the Active Directory from the Stanford Registry will retain the visibility settings that the person requested. These settings include: the world, the stanford community, and private. Currently, the name, department and 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, according to the Family Educational Rights and Privacy Act of 1974 (FERPA). The details of how data visibility is set in Active Directory can be found in the Windows Admin Guide.
ITSS does not own this data, and in most cases the ownership resides with the Registrar’s office, as delegated by the Stanford Board of Trustees. ITSS is a custodian of the data for the Registrar. If in the future, clients would like more personal data replicated to Active Directory, ITSS will pursue the likelihood of replicating additional data with the Registrar.
ITSS has also been granted the ability to delegate visibility to departmental administrators for the personal data of members of that department. This enables departmental administrators to view all the accounts of members of their department and administrate user accounts. When you are delegated access to personal information, you must agree to safeguard that information, and only use it for official Stanford business.You demonstrate your agreement by physically signing this policy.
Replication is one-way, and Active Directory is not the authoritative source of personal information. Therefore, user attributes which hold personal data such as name fields, address fields, phone numbers, etc will remain read-only to everyone at this time. Any personal data that is manually entered may be overwritten by replication of the authoritative data of record.
Windows administrators can choose to create all new computer accounts via Active Directory Users & Computers or available computer creation executable. Doing so allows an administrator to specify which OU container the computer account should be created in, otherwise the computer account is placed by default in the Computers container, which can be problematic. For more details, read the How to Add a Computer to SWI document.
Administrators of the Windows SUNet Ids will only have access to the accounts of people affiliated with the department that the account operator administers. For a limited period in times of emergency, the ITSS Windows Infrastructure Group will provide a backup person for any group whose account administrator is absent or unavailable.
ITSS strongly discourages the creation of non-SUNet accounts. Users generally get better, more secure access to Stanford resources via a free, base-level SUNet ID than they do from a local non-WIN user account. To find out more about requesting or sponsoring a SUNet ID, follow this link.
If you must create a local non-WIN account, be aware of the following: The UPN suffix of the domain in which the local account is created must be appended to the UPN of that account. By default, all new local user accounts begin with WIN.Stanford.edu. So you will have to manually change this setting every time you create a new local account. For example, an administrator in the SU domain must ensure that a new local account’s UPN is not newuser@WIN.stanford.edu but is instead newuser@SU.WIN.stanford.edu. This will prevent naming conflicts with the Windows SUNet accounts. Accounts that conflict with the Windows SUNet Ids will be periodically audited, and mistakes will be corrected by the ITSS Windows Infrastructure Group.
Domain administrators are responsible for developing naming standards for domain accounts and groups and enforcing them. (For example a policy might be that, all temporary accounts might have usernames that begin with “temp” and all test accounts might similarly begin with “test.”) Naming standards make account maintenance easier and environments more secure. In the SU domain, user objects will have a prefix chosen by the individual systems administrator groups.
Stanford discourages the use of shared accounts. Shared accounts compromise the usefulness of auditing information, and are more often used in break-ins. Sunet Ids can not be shared by Stanford policy.
In situations where group objects need to be created in a domain that is shared by many administrators, the names of those groups must be unique. To ensure this uniqueness, every systems administrator group will pick a prefix ending with a "_" for security groups that they create.
Global groups may be created in the WIN domain. They have the most functionality for migration because they can be applied to permissions on resources in a migrating Windows NT 4.0 domain. It is advised, however, that most groups be Domain Local groups in a child domain so that the groups and their memberships will not be so widely available to other entities.
The list of site-wide policy settings functionally enforces all policies designated in this document. ITSS recommends that security settings in the site-wide Best Practices GPO only be replaced with more secure values. If you do override security settings, it would be a good idea to let both the ITSS Windows Infrastructure Group know as well as the Security office.
Domain administrators are responsible for creating a policy which governs the creation of group policies within their domain.
In accordance with Stanford computer security policy, cleartext authentication is not allowed in the Stanford Windows Infrastructure. The ability to use cleartext authentication will be turned off on all domain controllers. Configuring IIS to allow cleartext authentication is not allowed. Configuring Mac File & Print Services to allow cleartext authentication is not allowed. Samba cleartext interoperability isn’t allowed. FTP (in cleartext) with Windows SUNet Ids is not allowed. Anonymous ftp is allowed.
Both Lan Manager (LM) and NTLMv1 authentication uses an insecure password hash that poses a serious security risk. Both Lan Manager and NTLMv1 authentication has also been turned off at the domain controllers.
Lan Manager Authentication was required for Mac Client access, but a new Mac UAM has been released which supports NTLMv2.
Currently, LM authentication is needed for the default Win9x client access. NTLMv2 authentication can be achieved on Win9x clients by installing the Active Directory client, and then by configuring a registry key after installing the AD client.
To protect the integrity of the Stanford Windows Infrastructure, all accounts must have a password that meets certain basic requirements for strength, complexity and form, as spelled out in the SUNet ID Passwords document. Passwords on non-SUNet accounts will be subjected to a password filter that simulates the SUNet ID password restrictions filter.
The Stanford Security office provides an ongoing security review. All security "events" are sent to this Office via a real-time event log daemon. All use of administrative privileges will be audited for review by both the Stanford Security Office as well as by departmental administrators. In addition to general security evaluations, the Computer Security Office investigates circumstances in which a Windows administrator is suspected or is deemed to have abused his or her administrative privileges. On a structural level, security scans of the domain controller network are conducted on a periodic basis.
Prior to joining the Stanford Windows Infrastructure you must ensure that your system adheres to Microsoft software licensing policy. Ongoing compliance is also required after you have joined the tree. Since non-compliance can conceivably effect any service provider within the tree, it is in Stanford’s best interest to make sure licensing is done. ITSS will not provide Windows 2000 Server/Professional licenses or client access licenses for computers. Stanford University does not have any form of site licensing for Microsoft Software. However, the campus does have an attractive pricing structure via the Select Academic Pricing plan.
Windows DNS Services must NOT be installed on any system within the Stanford Windows Infrastructure. Windows 2000 workstations must be configured to turn off DDNS registration. All Stanford-owned computers in the Stanford Windows Infrastructure -- except domain controllers -- must have Stanford.edu as their primary DNS suffix name, and must be registered properly in NetDB. To conform to campus networking standards, all computers must have a DNS name that matches their registered NetDB node.
All computers in the Stanford Windows Infrastructure should use the central WINS servers.
No Certificate Authority Server will be setup in the domain tree. (Though it may be offered as a centrally offered service at some point in the future.)
EFS recovery by an ITSS administrator is not possible, because it would require a Windows CA server. EFS can be run using local self-signing certificates, but users should be made aware that this creates the possibility that their encrypted files might be unrecoverable if the certificate is lost.
Certificates signed outside the Windows Infrastructure will not be associated with the SUNet accounts, because a compromise of the external CA server could result in a compromise of the SUNet 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.
There are no restrictions on connecting to Netware resources. Synchronization of AD directory services with eDirectory (NDS) services will not be done. This is because ITSS is not the owner of the data, but is simply a custodian. Please contact the ITSS Windows Infrastructure Group to discuss this further.
There are two areas of Active Directory that a departmental administrator might have authority in. One is in the root domain, WIN, for the OU that corresponds to their department’s accounts. The other area is within a child domain. Any given departmental administrator may or may not have authority in both places. Some of the policies listed below only apply to authority given in the root domain for Windows SUNet accounts. These policies will be clearly designated that the policy only applies to administrator accounts that have been “delegated authority in the WIN domain for SUNet accounts.”
Administrators who are delegated authority in the WIN domain for SUNet accounts must read this document and agree to the policies within, prior to being given authority to view personal data associated with a Windows SUNet account. Delegation of this authority is made by the ITSS Windows Infrastructure Group via membership in security groups that reside in the WIN domain. When logging on you agree to follow this policy by clicking OK to the logon banner. Again, this is because the university has legal obligations because of the personal data issues. This is a less restrictive practice than the existing practice that the Registrar’s office uses to give access to this data, which involves attending a training class.
Departmental administrators will find themselves in possession of two accounts. The first is a regular Windows account, is used for general staff-related duties at the University. The second account, an administrative account, is used for performing the duties of a Windows system administrator. An administrator’s regular Windows SUNet account must never be used to perform administrative duties. We recommend that administrators use the “Run as ...” command to switch between their two accounts. Note that the “Run as” functionality can be accessed via the “runas.exe” executable or by right clicking in the start menu on Windows 2000 and later operating systems.
Administrators are welcome to delegate administrative rights in their child domain to another administrator’s administrative account, subject to any policies that your domain may have.
All administrative accounts and administrative group accounts will reside within a special, hidden account OU in each domain. All objects within this OU cannot be enumerated by non-administrative accounts, that limits exposure to security break-ins. This special OU employs a mandated account lockout policy as a means of limiting brute force security attacks on the privileged administrative accounts. This special OU will be created by the ITSS Windows Infrastructure Group, but ongoing maintenance will be taken care of by the child domain administrators. Making sure this OU is used for all administrative accounts will be audited on a periodic basis.
All actions taken by all accounts are subject to monitoring and audit, this is especially true for systems administrative level accounts. All administrative accounts shall be named such that administrative level and user level accounts can be readily apparent in the audit logs.
Data Backup
Computer systems are complex: they are subject to failures in ways that cannot be foreseen. Therefore, to minimize the effects of such failures, you must safeguard the data on your system by periodically backing up your system (i.e., copying all files to some alternate media so that you can restore files that have been lost due to software problems, hardware malfunctions, or to disaster situations), or by making provisions to have it done. Note that ITSS will perform this service for all domain controllers in the campus tree.
Privacy of Files
As an administrator you must undertake, by your best efforts, to hold private all files stored on the system you administer. Note, however, that for various legal reasons described below (see Security Issues), your ability to maintain the privacy of all files may be limited. Make sure that people who use your system know better than to expect "absolute" privacy for their files; they should be wary of using your system (or any of Stanford's shared-access computer systems) for storing highly personal or sensitive information. You should also make yourself aware of the EFS functionality that NTFS5 offers, and be aware of the dangers of using it.
Resolving Security Incidents
As the administrator of your system, you have the right to inspect any files stored on your system and to record any communications that pass through your system when investigating allegations of misconduct. You might also be called on to investigate and pursue appropriate disciplinary or legal action against a person or persons using your system.
This circumstance may occur when a user's behavior is causing, -- or is alleged to have caused -- some form of harm to or an abridgement of the rights of other persons, including other persons' legitimate use and enjoyment of your computer system or of other computers accessible via SUNet. The following are among the activities particularly proscribed:
- Theft of computer services, including, but not limited to:
- Obtaining services fraudulently (e.g., use of another person's name or University ID; giving one's password to another person; using another person's account regardless of permission, etc.).
- Using the facilities for any commercial purpose or for any partisan political purpose.
- Gaining unauthorized access to computer system privileges.
- Theft of data, including, but not limited to: accessing another person's files without proper and appropriate permission. (Plagiarism, which is the unacknowledged use of another's work, is usually punishable under the provisions of the Honor Code); copying programs or data protected by copyright or by special license.
- Using the facilities to harass another person, i.e., to take any intentional action to deny or to degrade another person's legitimate access to your system or legitimate access to other computers accessible via the network. Harassment includes, but is not limited to, the following examples:
- The creation or running of a "computer virus" program or any program that can disrupt normal system functioning, disclose system data, destroy system data, obtain undue system resources, and/or multiply without internal restraint.
- Using the facilities as the base from which to "attack" the security of any computer.
- Any action taken by a student that results in an unfair academic advantage may constitute a violation of the Honor Code.
Your action in response to an allegation of offensive behavior against someone using your system depends upon many factors, including the source of the allegation and the nature of the alleged behavior. In situations where an instructor alleges plagiarism or unpermitted collaboration, you may, in cooperation with the Campus Computer Security Officer, gather any information relevant to the specific allegation, discuss that information and its interpretation with the instructor, and, upon the request of the instructor, provide that information to the appropriate University Officer. In situations characterized as minor infractions you may, in cooperation with the Campus Computer Security Officer, communicate with the responsible person, informing that individual of the nature of the purported violation. You must then give the individual an opportunity to discuss these matters with you first. At your discretion you may then consult with the Campus Computer Security Officer, Judicial Affairs, or the cognizant Staff Affairs Officer in order to determine the best course of action. In circumstances where facts are inconclusive, you may also propose that an individual's computer activities be monitored. In such a situation, you must first obtain permission in writing from the CIO, a designated representative of ITSS, or other appropriate officer.
Situations in which a person's behavior creates a disruption of service to your users may be met by suspending access and services to that person. Access and services might be restored following a discussion, as described above. When requested to do so by a law enforcement agency of appropriate jurisdiction, or when there is reason to believe that illegal activities or significant infractions of our rules have occurred or are continuing to occur, you may be asked to monitor a suspected individual's computer files and activities. In situations where such monitoring has been proposed, you must first obtain permission in writing from the CIO, designated representative of ITSS, or other appropriate officer. If necessary, you may invoke the assistance of a law enforcement agency.
Information gathered through the monitoring of an individual's computer activities or files can only be used to provide investigating authorities with relevant and adequate information to guide their actions. You may not employ this information for any other purpose. You should forward such information to Judicial Affairs, in the case of students; to the cognizant Staff Affairs Officer in the case of staff; or to a law enforcement agency. Only such authorities may initiate any disciplinary or legal action. Data will be kept as long as required by the investigating or adjudicating authority. To protect the privacy of uninvolved second or third parties, files containing "electronic mail" messages will be examined only under conditions where there are extremely clear indications that such messages contain information pertinent to the investigation.
For more information about security issues, send email to the Campus Computer Security Office at security@stanford.edu.
