March 09, 2005

Initial Setup

Once you've contacted to join the ADSTEST domain, there are a few simple steps to get you on your way. Step #1 is to setup Kerberos so you can log in using your campus ID and password:

C:\> ksetup /addkpasswd INS.CWRU.EDU KERBEROS.CWRU.EDU
C:\> ksetup /mapuser * *

The ksetup.exe tool is part of the Windows XP Service Pack 2 Support Tools or can also be found in the SUPPORT.CAB file on your Windows 2000/XP/2003 install disc.

Next, join the computer to the ADSTEST domain.

1. Go to the System Control Panel and click on the "Computer Name" tab.
2. Click the "Change" button. Set the domain as ""
3. Click the "More" button. Set the Primary DNS suffix of the computer to "" and uncheck the box labeled "Change primary DNS suffix when domain membership changes".


Reboot and you should now be able to log onto the machine either with your OU Administrator account into the ADSTEST domain or with your campus ID & password using the INS.CWRU.EDU Kerberos Realm. Follow the same procedure for subsequent machines, except you MUST first pre-create the computer object in the Organizational Unit you'd like it to reside in. To do this and administer other aspects of your Organizational Unit install the following tools on atleast one machine:

Download the Windows Server 2003 Service Pack 1 Administration Tools Pack which will add the Active Directory Users and Computers Control Panel to your system (among others). Next, download and install the Group Policy Management Console, which requires the .NET runtime to be installed. Installing .NET took me several reboots; After installing the .NET runtime a service pack appeared in windows update, and then on the second reboot a security update for the service pack appeared. This adds the "Group Policy Management" control panel, which along with the Active Directory Users and Computers Control Panel are pretty much all you need.

Posted by djc6 at 08:22 PM | Comments (0) | TrackBack (0)

*THE* book for OU Administrators

Bill Wichert from EECS recommended the book Group Policy, Profiles, and IntelliMirror for Windows 2003, Windows 2000, and Windows XP and it is well worth it. Its topic is narrow unlike a lot of Active Directory books, focusing on Group Policy and Profiles which are the most relevent to Case AD users.

Another book worth mentioning is O'Reilly's Active Directory Cookbook, and the full text is available from on campus via Safari. I didn't find it as useful as Bill Wichert's recommendation.

Posted by djc6 at 09:01 PM | Comments (0) | TrackBack (0)

Creating Custom Policies (.ADM files)

This website:

talks about how to create custom Administrative Template (.adm) files and includes a complete reference for the .adm language. You can use this to create policies in addition to the defaults provided in the Group Policy Editor. Some custom policies I've written include one to automatically log off users via the winexit.scr screensaver, and a policy to customize the default windows XP login prompt.

Posted by djc6 at 09:01 PM | Comments (0) | TrackBack (0)

Automatically log off users

One of the concerns I had with Active Directory in the Nord Computer Lab was that users would forget to log off their account. Previously, the computers automatically logged on as a generic user, so people had a habit of not logging off. One way to remedy this situation is the WINEXIT.SCR screensaver which is part of the Windows Server 2003 Resource Kit Tools

Copy the file to C:\WINDOWS\SYSTEM32 on each computer, and use the group policy management console to set this as the default screensaver and set the timeout period. You MUST also change the permission on a registry key for the screensaver to work for all users of the machine. See KB156677: Logoff Screen Saver Does Not Function in Windows NT

By default, WINEXIT.SCR presents the user with a dialog box 30 seconds before they are to be logged off, which is determined by when you've set the 'screensaver' to kick on. I wanted the dialog box to come on a lot earlier, say 5 minutes before hand to give the user time to react. You can also set WINEXIT.SCR to Force application termination, and insert a custom message. The following ADM file I wrote can be used with the group policy management console to configure these settings. Installing this will put a group of settings entitled "Winexit.scr Policy settings" under "User Configuration->Administrative Templates" in the GPMC.

;; Remember in GPMC to go View->Filtering ;; and uncheck "Only show policy settings that can be fully managed" ;; ;; David Carlin ( 2/25/2005 ;; ;; WINEXIT.SCR is located in the Windows Server 2003 Resource Kit CLASS USER CATEGORY !!Screen_Saver_Policy POLICY !!TERMINATE_APPS KEYNAME "Control Panel\Screen Saver.Logoff" VALUENAME ForceLogoff VALUEON "1" VALUEOFF "0" END POLICY POLICY !!COUNTDOWN_TIMEOUT KEYNAME "Control Panel\Screen Saver.Logoff" VALUENAME CountDownTimer VALUEON "300" END POLICY POLICY !!ENTER_DIALOG_MESSAGE KEYNAME "Control Panel\Screen Saver.Logoff" PART !!ENTER_DIALOG_MESSAGE EDITTEXT DEFAULT !!DEFAULT_MESSAGE VALUENAME DialogMessage END PART END POLICY END CATEGORY [strings] Screen_Saver_Policy="Winexit.scr Policy settings" TERMINATE_APPS="Terminate running applications" COUNTDOWN_TIMEOUT="Enable 5 minute warning logoff notice" ENTER_DIALOG_MESSAGE="Warning message about being logged off" DEFAULT_MESSAGE="You are about to be logged out. Press the cancel button to stop this process."

Posted by djc6 at 11:00 PM | Comments (23) | TrackBack (0)

March 10, 2005

Custom Login prompt: Helping users log in

One day while working in the Peter B. Lewis computer lab (a favorite hideout of mine, and an excellent lab), I noticed they had modified the login prompt of XP to include what computer image revision that computer was using. I decided to figure out how they did that so I could add instructions to the login box telling users to select the INS.CWRU.EDU domain when logging in. The results look like this:


I also set a registry entry to make INS.CWRU.EDU the default domain to log into. However, if it is changed (say to log in as your OU Administrator account into ADS), it doesn't get reset to INS.CWRU.EDU until the next reboot or until someone logs into the Kerberos Realm. If anyone knows how to permanently make this the default, I'd love to know!! But this works good enough for now..

This was accomplished using the following ADM file added to the GPMC:

;; Remember in GPMC to go View->Filtering ;; and uncheck "Only show policy settings that can be fully managed" ;; ;; David Carlin ( 2/25/2005 ;; CLASS MACHINE CATEGORY !!Winlogon POLICY !!DefaultDomainNameBox KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Winlogon" PART !!DefaultDomainNameBox EDITTEXT DEFAULT !!DefaultDomainName_default VALUENAME "DefaultDomainName" END PART END POLICY POLICY !!WelcomeBox KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Winlogon" PART !!WelcomeBox EDITTEXT DEFAULT !!Welcome_default VALUENAME "Welcome" END PART END POLICY POLICY !!LogonPromptBox KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Winlogon" PART !!LogonPromptBox EDITTEXT DEFAULT !!LogonPrompt_default VALUENAME "LogonPrompt" END PART END POLICY END CATEGORY [strings] Welcome_default="- READ CAREFULLY - Nord Computer Lab" LogonPrompt_default="NOTICE: Use your Case Email ID and Password. You must set 'Log on to: INS.CWRU.EDU' !!!!" DefaultDomainName_default="INS.CWRU.EDU" WelcomeBox="Enter Login screen title" LogonPromptBox="Enter custom login prompt" DefaultDomainNameBox="Enter Default Domain Name" Winlogon="Configure Login Prompt & Default Domain"

Posted by djc6 at 10:43 AM | Comments (8) | TrackBack (0)

How come some users can't log in?

If you have a current student, staff, or faculty member who cannot log into the Active Directory, it is almost always because they have not changed their password since September 1999. This coincides with Case's Kerberos KDC being upgraded from v4 to v5. Active Directory does not support v4 salt keys, and the only way to pick new v5 salt keys is by changing your password.

The ADS Administrator says there are more than 22,000 users who have not changed their password since 9/1999.

Posted by djc6 at 11:00 AM | Comments (0) | TrackBack (1)

March 12, 2005

Connecting to share without binding to Active Directory

I wanted to find a way for machines outside of the active directory to connect to shares on my file server. The purpose of this was for stduents to be able to access their lab home directory from the dorms. Unfortunately, I've so far only been able to do this from MacOS X and not windows clients. I found these instructions on UC Berkeley's website. Here is the /Library/Preferences/ file I used:

[libdefaults] default_realm = INS.CWRU.EDU [realms] INS.CWRU.EDU = { kdc = KERBEROS.CWRU.EDU kdc = KERBEROS2.CWRU.EDU admin_server = KERBEROS.CWRU.EDU default_domain = } [domain_realm] = INS.CWRU.EDU = INS.CWRU.EDU

Posted by djc6 at 01:34 PM | Comments (0) | TrackBack (0)

Applying User Policies

In the Case Active Directory, User Configuration Policies must be applied on a per computer basis using Loopback Processing of Group Policy. This is because the User and Computer objects aren't in the same OU container that the Group Policy Object is linked to. To accomplish this, open up the Group Policy Management Console and click Computer Configuration. Locate Administrative Templates, click System, click Group Policy, and then enable the User Group Policy loopback processing mode. Set the processing mode to Replace.

You can now set user configuration policies in the linked GPO and have them apply to any user logged into the computers in the OU. For instance, this is neccessary to configure the default user background for anyone using computers located in the Nord Lab Computers OU. For more information read KB231287: Loopback Processing of Group Policy.

Posted by djc6 at 02:37 PM | Comments (0) | TrackBack (0)

Roaming Profiles w/Case ADS

Roaming profiles not only make sense for a lab environment, but an office environment as well. In the Engineering Dean's Office I use them as a means of backing up all of a user's settings. If something happens to their PC, I can quickly put a backup machine in place while their office machine is repaired. The user simply logs in, and their previous settings are restored. This is how roaming profiles work with the campus ADS:

  • Every campus account in ADS and ADSTEST now has their profile set to: \\%ProfileServer%\%ProfileShare%\%Username%
  • The 'Only allow local user profiles' group policy is now enabled by default, so there is no error message like 'can't find roaming profile' should you not define these variables.
  • On each machine you want to roam, you need to define the variables %ProfileServer% and %ProfileShare% (these are not normally part of windows) system wide. You can create these variables in the system control panel - make sure you add them to the system environment variables and not the user environment variables. For example, you can simply set %ProfileServer% = skybridge and %ProfileShare% = nord-profile$ (examples from my setup - $ makes it a hidden share).
  • Create a group policy object linked to the OU you'd like to roam, and set this policy to "Disabled":
  • Computer Configuration -> Administrative Template -> System -> User Profiles -> Only allow local user profiles

  • Unique to my configuration was turning off caching of roaming profiles. Eventually the lab machines would have filled up with hundreds of cached copies of profiles. It makes sense to cache them in an office environment, but not in a lab:

    Computer Configuration -> Administrative Templates -> System -> Logon -> Delete cached copies of roaming profiles

  • Reboot the computer so these policies and the system environment variables take effect.
  • Now when you log in as a user in the kerberos realm, a profile should be automatically created on your server's %ProfileShare% - if not check the permissions on the share. The minimum permissions needed are "List Folder/Read data", "Read Attributes", and "Create Folder/Append data" applied to scope "This folder only". For my setup, I applied these permissions to the Group "Authenticated Users". Share permissions were set to "Authenticated Users" Full Control
  • The Cache Option for Offline Files Must Be Disabled on Roaming User Profile Shares. See KB287566

  • The profile should roam between two or more computers that have been setup with the above steps.
  • The Policies "Allow Cross-Forest User Policy and Roaming User Profiles" and "Add the Administrators security group to roaming user profiles" have been turned on by default. The first is necessary to make this work, and the second is so you can access users' profiles without having to change the permissions to include you first. The group added is %ProfileServer%\Administrators
Other methods exist for setting the environment variables, so you can more easily change them without revisiting each machine. One is creating an ADM file with a custom policy for these environment variables (something I'll look into). Another way is defining them in the login script, which is the method used by Alan Rothenbush at Simon Fraser University - whom I got this whole roaming profile idea from.

The default profile used when creating the user's first profile is the "C:\Documents and Settings\Default User" profile on the local machine used when first logging on. This is because no Default User profile exists in the SYSVOL share of the campus domain controllers (probably a good thing). Make any changes to this profile if you want them to apply to users when the first log in. See KB305709: HOW TO: Create a Custom Default User Profile

I have also setup Folder Redirection of the user's My Documents folder to speed up profile loading. Aside from the "nord-profile$" share I've created on my server, I've also setup "nord-home$". I then set the Folder Redirection policy to put My Documents in \\servername\nord-home$\%username% - using the same share/file system permissions listed above for the profile share. The results are seperating "My Documents" from the user's profile, so it isn't copied back and forth every time the user logs in. One 'surprise' is that Windows XP automatically turns on offline file caching for redirected folders. If you don't like this behaviour, enable the policy "Do not automatically make redirected folders available offline", under User Configuration -> Administrative Templates -> Network -> Offline Files.

Make sure to read Recommendations for Folder Redirection for more information on Folder Redirection policies.

Posted by djc6 at 03:35 PM | Comments (7) | TrackBack (0)

March 13, 2005

Restricting who can log on

By default, anyone in the Kerberos Realm can log on interactively at any machine in the active directory. To change this behavior, set the policy:

Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Allow log on locally

To include the list of users/groups you wish to be able to log on at the computer console.

Posted by djc6 at 02:20 PM | Comments (0) | TrackBack (0)

March 14, 2005

Error editing SP2 policies from SP1 or 2003 Server

If you encounter the following error when opening the group policy editor:

The following entry in the [strings] section is too long and has been truncated.

Download the update in this article KB842933: "The following entry in the [strings] section is too long and has been truncated" error message when you try to modify or to view GPOs in Windows Server 2003, Windows XP Professional, or Windows 2000

Posted by djc6 at 11:32 AM | Comments (0) | TrackBack (0)

Apply Group Policies to Groups

Say you want to have different user configuration policies based on whether a staff or student logs into a particular machine. You can apply Group Policies to Groups by modifying the security filtering - read this article:

Thanks for Jon Wehner in Admissions for pointing this out his first day on ADSTEST! Sometimes I overlook the obvious :)

Posted by djc6 at 01:47 PM | Comments (0) | TrackBack (0)

Group Policy Settings Reference

Check out this invaluable, but poorly formatted reference from Microsoft. A collection of every Group Policy description so you can easily do a keyword search and find the right one:

Group Policy Settings Reference for .adm files and Security Settings included with Windows XP Professional Service Pack 2

Posted by djc6 at 10:54 PM | Comments (1) | TrackBack (0)

May 16, 2005

Moving NT4 Profiles to Active Directory

I'm currently moving an office from their own NT4 domain to the Campus Active Directory and wanted to keep their account settings identical. I needed a straightforward way to migrate their old NT4 profile to ADS. I ended up using the moveuser.exe tool which is part of the Windows Server 2003 Resource Kit Tools.

On each machine, I made a local user called "tempuser". I then issued the command to associate the old NT4 profile with the new local user:

moveuser.exe nt4_domain\username tempuser

I then went through the proceedure to join the computer to the active directory. Once on the active directory, I did:

moveuser.exe tempuser ads\username

to asssociate the now local profile with the ADS account. I could then delete "tempuser", log on as the individual and the old profile was now properly associated with their active directory account.

Why couldn't I just "moveuser nt4_domain\username ads\username"? This is because the NT4 domain and campus AD are not trusted. The moveuser tool needs to be able to lookup the SSID for both accounts. Hence, the only way I could accomplish this was using an intermediary local account.

CAUTION: Often I'd have to reboot between adding the tempuser account and issuing the moveuser.exe command. Otherwise I'd get errors that it couldn't find the NT4 domain account, or occasionally an "Access Denied" error, presumably because some portion of the NT4 user's profile is still in use and inaccessable.

Sometimes "HKEY_LOCAL_MACHINE\Software\Classes" still has the old NT SSID in the permissions. When I'd log into AD as the user for the first time, I'd see if I could open it. If not, I'd change the permissions on Classes and find the old SSID in there... Delete it, and add the ADS\username into the permissions.

Apparently "HKEY_LOCAL_MACHINE\Software\Classes" is simply a link to the current user's own HKEY_CLASSES hive. If you go into regedit and look under "HKEY_USERS", you'll notice each user has a <SSID> entry and an <SSID>_Classes entry. I guess moveuser.exe sucks and doesn't check for the presence of <SSID>_Classes and change the permissions accordingly.

Posted by djc6 at 10:08 PM | Comments (2) | TrackBack (0)

May 18, 2005

Power Settings via Group Policy

I wanted to create a policy to set all of the laptops in the department to the same power scheme. This tool allows you to manage power options via Group Policy:

The EPA probably provided this link so you could easily allow systems to go into standby mode, but I want to use it to keep docked laptops on all the time :)

Posted by djc6 at 12:05 AM | Comments (16) | TrackBack (0)

May 23, 2005

FREE Print Quota Software for AD members ONLY

In March I purchased Print Quota software for the Nord Lab called PaperCut. I purchased an unlimited user license, which also covers an unlimited number of servers in the same Active Directory domain. I have confirmed with the authors that anyone at CWRU can use my copy without any additional cost, as long as they are on the Campus Active Directory.

I deployed it on the first day after spring break, and between March 14th and April 28th it processed 262,871 pages for 2,486 users in the Nord Lab flawlessly.

If you are interested and I can verify you are on the production active directory, let me know and I'll hook you up with the serial number and a copy of it.

If you do eventually use it, I am not opposed to those with money helping defray the $744.00 the Nord Lab spent on licensing it :) If you are too poor, I understand... you can pay me once you start saving money on printing costs! :) j/k.

For more information go to

There you can find info on the server software, the administrative console (for receptionists, lab monitors, etc.. who collect money) and also the optional web interface for administration and end user quota monitoring. It really is a spectacular package.

Posted by djc6 at 02:20 PM | Comments (0) | TrackBack (0)

June 03, 2005

Client-less Novell & Active Directory

One "gotcha" in a recent active directory conversion was that users could no longer clientlessly access the campus novell servers. Two solutions were presented to me, the first by Chuck Yoder:

Change Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network Security: LAN Manger authentication level to "Send NTLM response only" from the AD default "Send NTLMv2 response only/refuse LM/NTLM" to get clientless to work.

DISCLAIMER: The above method will lessen the security of clients using network resources. It is not recommended by the Case ADS Administrator. Only apply to machines requiring clientless novell access!

Please see section #10 of this Microsoft Knowledge Base Article: KB823659: Network security: Lan Manager authentication level for more information.

The second solution is from Ben Hrouda, which involves installing the Novell Client. This method does not require disabling NTLMv2 and is considered the more secure workaround. The instructions on this page must be followed in addition to the normal install:

Client32 for Active Directory Kerberos Interoperability

Posted by djc6 at 01:58 PM | Comments (3) | TrackBack (0)

June 22, 2005

Printing from OS X 10.4 TO windows printer on Active Directory

The version of samba included with MacOS 10.4 (Tiger) supports NTLMv2, which is on by default for machines in the Active Directory. Once I upgraded my machine to Tiger, I had set to out print through a shared windows printer on a machine in the active directory. Follow these steps:

  • Change the entry "client ntlmv2 = no" to read "yes" in the /etc/smb.conf file
  • Open the Printer Setup Utility
  • Click Add Printer
  • HOLD DOWN the alt/option key and click on the "More Printers..." button
  • In the first pull down menu select "Advanced"
  • Under Device select "Windows printer via SAMBA"
  • Fill in the Device Name (can be anything)
  • For device URI: insert something like:


  • Select the printer model and you're done!!

Unfortunately, CUPS uses smbspool, which does not currently support kerberos. I had to hardcode in the URI a generic printer account that I created locally on the print server for mac clients to use.

If you search on google, you'll find people have written patches for smbspool to allow for kerberos authentication. I didn't try any of them. Instead, I came across this thread which deterred me from even trying. Responses to the thread may yield some clues.

Here is a link to the patch in question

Posted by djc6 at 04:25 PM | Comments (2) | TrackBack (0)

July 20, 2005

How to Check Password Age before moving to AD

You can check the age of anyone's password by going to this site:

Which is also accessable from the ITS Network Tools page with the link titled "Verify Password".

Basically, type in a user's ID and then enter any string for the password. This will return the age of the password. If it's older than October 1st, 1999 you'll get this error:

"A new version of our authentication system was put into place on 10/01/1999. Since you last changed your password prior to that date, your account is lacking a "key salt" for the newer version. "

This tool has proven invaluable in figuring out which users are ready for Active Directory BEFORE I migrate their machine!

For a background on this active directory issue, see How come some users can't log in?

Posted by djc6 at 07:53 PM | Comments (0) | TrackBack (0)

January 11, 2006

Disable MSN Messenger Auto Run via Group Policy

At the request of several students, I put the latest version of MSN Messeger 7.5 on the Nord Lab computers. Unfortunately, The Group Policy settings for the old Windows Messenger don't work with this new IM Client. Specifically, the registry key:


is only applicable to Messenger 4.x and below. So, I came up with this ADM file to disable MSN Messenger 7.5 from automatically starting when the user logs in, but they can still run it if they choose to.

This ADM file uses a different method entirely for prevening MSN Messenger from automatically running when the user logs in. It clears out the entry for it from the User's "Run" list.

;; Remember in gpedit.msc to go View->Filtering ;; and uncheck "Only show policy settings that can be fully managed" ;; ;; David Carlin ( 1/11/2006 ;; ;; Disable MSN Messenger AutoRun CLASS USER CATEGORY !!MSN_Messenger_Policy POLICY !!DISABLE_MSN_AUTORUN KEYNAME "Software\Microsoft\Windows\CurrentVersion\Run" VALUENAME msnmsgr VALUEON "" END POLICY END CATEGORY [strings] MSN_Messenger_Policy="MSN Messenger Policy settings" DISABLE_MSN_AUTORUN="Disable MSN Messenger Autorun"

Posted by djc6 at 03:36 AM | Comments (2) | TrackBack (0)