How to Add Your Computer to the Stanford Windows Infrastructure

This document describes the process of joining a Windows 2000, Windows XP Professional, Windows Server 2003, or Windows Vista Business, Enterprise, or Ultimate computer to the Stanford Windows Infrastructure. This document is intended for Windows administrators. If are not a Windows administrator, but would like to join the infrastructure, contact your LNA or school/department Windows administrator for assistance. If you are unfamiliar with who this is, check this contact list of Windows Administrators for your school or department. If you still need help, contact the Helpdesk at (650)725-HELP (725-4357). for assistance, or enter a help ticket in the HelpSU system.

Preparation
Create the computer account
Configure authentication level (Not required for Vista)
Configure for Kerberos cross-realm/single-sign-on to @stanford.edu (Recommended for clients, Required for servers)
Join the domain
Configure for security
First user login

Note: Windows 9x clients are no longer supported. Home and Media editions of XP and Vista cannot support Kerberos, which is required for joining the infrastructure.

Macintosh clients can consult How to configure Mac services on a Windows 2000 Server for configuration instructions on how they can connect to Windows computers in the Stanford Windows Infrastructure. Mac OSX connections are possible, but are not documented here.

Preparation

1. Make sure you have a local account with administrative rights on the computer. If anything goes wrong, this account will be needed--double-check that the password is known by logging in with it.
2. You may wish to back up user profiles (usually located either at C:\winnt\profiles\%username% or at C:\Documents and Settings\%username%) and any other critical data before beginning.
3. Make sure you TCP/IP settings are correctly configured. http://www.stanford.edu/group/itss/ess/pc/SUNet.html details the proper network settings for Stanford Windows computers. Specifically note that you should use 171.64.7.155 & 171.64.7.177 as your WINS servers.
4. You will need to know in which Domain and OU this computer will reside. Consult your local Windows administrator if don’t know which Domain and OU your computer should go into.
5. Finally, make sure your computer is registered in NetDB. Your NetDB entry should match the Windows computer name you are using - or you will have problems that manifest themselves as slow network connectivity.

Go back to table

Creating the computer account

There are 3 options to creating the computer account:

1. Add the computer to the domain at the desktop without pre-creating the account. (Skip to the next section)
   
   The advantage of this method is that it is easy. The disadvantage is that the computer account will be placed into the default "Computers" container. While the computer account remains in this container, no special group policy can be applied and any department Windows administrator can administer the computer object  - not the computer itself, however. After creating a computer account in this manner, you will need to move it to the correct OU as soon as possible.
    
2. Pre-create the account in Active Directory Users and Computers.
   
   This method is more direct and is probably the best in general. This method allows you to place the computer object in the correct OU when it is created.
   1. Open Active Directory Users & Computers
   2. Connect to the Domain and browse to the OU where the computer object should reside
   3. Right-Click on the OU, then Select New->Computer
   4. You can grant permissions on the new Object to allow another (non-privileged) user to perform the add at the console.
       
3. Pre-create the account using VB tool
   
   The VB Tool automates the tasks for method two.
   1. Open AddComputers.exe on a machine in the infrastructure and running as a privileged account.
   2. Browse to the Domain and OU where the account should be created
   3. Enter the computer name
   4. Optional - Enter the full user name (WIN\Sunet) for an account to add the computer to the domain
   5. Click "Create Computer Account"

Note that it will take five minutes for the computer account object to replicate to the other domain controllers. If you add the computer before the object replicates, you may cause a duplicate object to be created. This may prevent domain authentication from succeeding.

Go back to table

Setting Authentication Level

If you are setting up Windows Vista, you can skip this section

Windows workstations have several authentication methods available to them to enable a user to login. The more insecure of these authentication methods allow backward compatibility for legacy applications. Among the authentication methods available (in order from strongest to weakest) are Kerberos, NTLM version 2, NTLM version 1, LanMan, and basic (cleartext). Windows workstations always negotiate the most secure method, and use it. Only Windows 2000, Windows XP Professional, Windows 2003, and Windows Vista Business, Enterprise, and Ultimate Edition computers can use Kerberos, so in general the most secure authentication method available to all Windows computers is NTLM version 2. You must configure your computer to not use basic authentication, and to only use NTLM version 2. This will protect your account and password. For more details on the implications of this change read both of these Microsoft support articles http://support.microsoft.com/support/kb/articles/Q239/8/69.ASP and http://support.microsoft.com/support/kb/articles/Q147/7/06.ASP.

The following steps will set up NTLMv2 authentication on your computer:

1. Login with an account which is a member of the local administrators group.
2. Open the registry editor. On Windows NT/2000/XP/2003 computers, use regedt32.exe.
3. Browse to HKLM\System\CurrentControlSet\Control\Lsa\
   
   
   
   
4. On the Edit menu, click Add Value, and then add the following registry value (or update if it exists):
   • Value Name: LMCompatibilityLevel
   • Data Type: REG_DWORD
   • Value: 3
5. Reboot your computer.

Go back to table

Configuring the computer for Kerberos cross-realm "single sign-on" (Recommended for clients, Required for servers)

To enable negotiate auth for WebAuth single sign-on, go to https://weblogin.stanford.edu/settings

The Kerberos for Windows installer, available at the Essential Stanford Software site or through Stanford Desktop Tools, will perform this configuration for you, including installing the noted hotfixes. If you are using Kerberos for Windows, you can skip this step

Performing this configuration on servers allows for ticket requests for services to be routed to the correct realm for authentication. Performing this configuration will also allow users to log on to the machine using the Unix Kerberos realm (stanford.edu) as <SUNetID>@stanford.edu. This option is in addition to the default Windows user name forms <SUNetID>@win.stanford.edu or WIN\<SUNetID>.

There are two different methods by which an administrator can configure their client computers for sign-on to the stanford.edu MIT kerberos5 realm. The first is a simple registry modification using a file distributed by ITS. The second is a command-line process that can be executed via batch or script.

Registry file method (preferred)

Install Windows 2000 Service Pack 1 or later on all client computers. Download the Stanford kerberos interoperability registry file. You may have to right-click on the link and save the target to properly download the file. Login as a user with permission to write to the Local Machine section of the registry. Copy the registry file to the client computer. Double-click the file and click OK when asked if you wish to add the information to the registry. Log out.

Command line method

Install Windows 2000 Service Pack 1 or later on all client computers. Extract ksetup.exe from the X:\support\tools\support.cab file from your install CD (Professional or  Server) Login as a user with permission to write to the Local Machine section of the registry. Copy ksetup.exe to the client computer. From a command prompt, run the following three commands:

• ksetup /addkdc stanford.edu krb5auth1.stanford.edu
• ksetup /addkdc stanford.edu krb5auth2.stanford.edu
• ksetup /addkdc stanford.edu krb5auth3.stanford.edu

Either method adds this Registry value:

HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains\stanford.edu
    KdcNames (REG_MULTI_SZ) = krb5auth1.stanford.edu, krb5auth2.stanford.edu, krb5auth3.stanford.edu

Go back to table

Join the computer to the domain

First make sure the computer name matches the name of the corresponding computer object you have created in the domain. If it doesn’t, you will need to recreate the computer account and delete the misnamed one.
 

Click the "Properties" button and a window like this should appear:

Check the "Domain" radio button and enter "yourdomainhere.win.stanford.edu" as the domain name, where yourdomainhere is the Windows domain this computer should belong in.


 

Click on "More" and a window like this should appear:

Uncheck "Change primary DNS suffix…" and enter "stanford.edu" in the field as shown in the picture and click "OK". Click "OK." It may take a few moments before you receive a response.
 

Within 2 minutes, you should receive a window welcoming you to the domain like this one:

You may receive an error message at this point. Common reasons for problems at this point are:

• The computer account wasn’t created; you skipped a step.
• The computer account wasn’t replicated to all domain controllers; wait 5 minutes after the computer account creation and try again.
• The domain controllers for the domain you want to join couldn’t be located; make sure your TCP/IP settings are configured correctly.
• There is a firewall between your computer and the Domain Controllers that is blocking your request. You must be able to communicate with the domain controllers using RPC, NetBIOS, Kerberos, SNTP, LDAP, and NTDS (an RPC port) .

On reboot, your computer should come up in the domain you specified. The first time booting will take a little longer as computer GPOs are applied. To log on, you will need to acknowledge the notice about Stanford computing policies, by hitting "OK".

• For Windows 2000, XP, or 2003, you will be presented with a login dialog, that should list many choices in the "Log on to:" box, including your local computer name, WIN, stanford.edu(Kerberos Realm), and other "child" domains (you may need to use the expansion button in the dialog to see the "Log on to:" drop down box depending on OS). The selection "stanford.edu(Kerberos Realm)" is only available if you perform the SSO configuration noted above.
• For Windows Vista, only a username and password box will be shown with a notation "Logging in to <domainname>". To log in to another domain, enter DOMAIN\username or enter a fully qualified principal name into the username dialog box  (ex "WIN\SUNetID",  "SUNetID@stanford.edu", or "SUNetID@win.stanford.edu")

Go back to table

Configuring the computer for secure distributed computing use

The administrator should take steps to prevent avoidable security issues. Microsoft has written excellent documents on client security at Windows Vista Security Guide and Windows XP Security and Privacy. These documents are also relevant to other Windows versions.

Windows workstations which are in  locations physically accessible to people other than the primary user are of particular concern. Local administrators will want to examine the membership of the local Users group because many default rights & file permissions are assigned to it. Authenticated Users, which includes every account in the Stanford Windows Infrastructure, is by default a member of the local Users group, and it might be wise to remove it, and specifically add those accounts or groups which should have a basic level of access. By default, Domain Users is also a member of the local Users group, and you may also wish to remove it. This task can be done for all workstations in an OU via a group policy configuration, scripted by using the secdefs tool, or manually using the user management tool. It is also strongly recommended that local administrators implement the NTFS file system on their workstations for the file security and auditing functionality it allows the user to take advantage of. A local administrator will want to pay special attention to local directories where particularly sensitive data may be stored, such as an Eudora mail directory or a documents directory.

A document for Securing a Windows 2000 Server is available, and may offer applicable tips.

Go back to table

First user login

If  the computer has been so configured, users at Windows 2000, XP, 2003 computers can select "stanford.edu (Kerberos Realm)" from the domain pull-down menu in the logon interface. Vista users will need to enter SUNetID@stanford.edu into the user name field. All users can select "WIN" from the pull-down menu in Windows 2000, XP, or 2003 or specify WIN\SUNetID as their username in Vista. In both cases, the username and password fields are the user's SUNet username and password.

If you have PC-Leland/Stanford Desktop Tools installed with the SSO option it will automatically sign you in during this period.

Common problems

• Since some users may not be familiar with their SUNet usernames and passwords. Their SUNet username/password is usually the same as their e-mail account username. Users who do not know their SUNet username or password should contact the Helpdesk at (650)725-HELP (725-4357). for assistance or use the password reset tool.
• If a user has not changed their SUNet password recently they may receive an error message that their password is incorrect. This password error happens because their password has never been synchronized into the Stanford Windows Infrastructure. The user can update the Stanford Windows Infrastructure with the correct password by going to Stanford.You and changing their password (even to the same one). The password synchronization process should take 5 minutes at most.

After the user has successfully logged in, you will need to copy relevant portions of their profile and double-check to see that all their data is accessible.

Go back to table

Created: May 21, 2001 by Brian Arkills Last modified: July 08, 2008 by Ross Wilper ©2008 Trustees of the Leland Stanford Junior University E-mail comments/suggestions/additions