A new GINA for Windows NT, version 0.9 beta, January 1998

This GINA brings new functionality to Windows NT which many users complained is missing:

• get rid of Ctrl-Alt-Del prior to logging on
• prevent password protected screen savers
• run a script at system shutdown
• run a script at logoff

Copyright (C) 1997-1998 by

This program is free software under the GNU General Public License. See the file LICENSE for details. The latest version of NEWGINA can be found at http://wwwthep.physik.uni-mainz.de/~frink/nt.html.

Contents

1. Introduction
2. Legal stuff
3. Concept
4. Installation
5. Configuration
6. Uninstallation
7. Troubleshooting
8. Implemented and tested platforms
9. Rebuilding from source
10. Files
11. Examples
12. Feedback/possible improvements

1. Introduction

However, most people consider this behavior simply as a nuisance, but there was no easy way to get rid of it... until now.

As as by-product, while programming this new feature, I found a convenient way to implement a logoff and shutdown script, as well as a really working method to prevent password protected screen savers. The latter option is very useful for PC pools in universities or schools, where users lock their NT workstations, leave, forget to come back, and thus effectively block the machine from being used by others.

The ordinary way to prevent password protected screen savers is to hide the Screen Saver tab from the Display icon in Control Panel with the Policy Editor. Then, you must disable the Registry Editing Tools as well, because otherwise the users can set their screen saver options directly through the registry. Then, you must remove the Run command from the Start Menu, or the users can run their own registry modification program. And you cannot use something like Microsoft Office, because with its macro language you can shell arbitrary programs... With my program, however, the password protection is prevented at a very deep level, and I am pretty sure ordinary users cannot bypass it (assuming you write-protected the Windows system directories and did not relax registry security; let me know if you find a way anyhow). Additionally, you must disable the Lock Workstation button in the Windows NT Security (Ctrl-Alt-Del) dialog. See my NOLOCKWS program to do this.

2. Legal stuff

For short, the main aspects of the GNU General Public License are in my personal interpretation which may not be 100% accurate (I am a physicist, not a lawyer):

• Everybody (private or commercial users) can use this program freely. However, there is no warranty of any kind, since this is free software. Use it at your own risk!
• Everybody may copy and distribute it, as long as you include the copyright notice, a disclaimer of warranty, the GNU License, and the source code (or make it freely available).
• You may modify the program or use parts of it in own programs, as long as you distribute it under this license as well (included, but not limited to making the source code available). Further include appropriate copyright notices and take responsibility for ALL bugs in this modified version.

3. Concept

Let me briefly explain how the program works and which registry entries it uses. Source code is included, so you may examine it on your own and modify it under the restrictions of the GNU General Public License. All options can be configured with the setup program. If you are not interested in the technical backgrounds, you can safely skip this section and go directly to the Installation section. This information can be useful if you plan to install the new GINA remotely on a larger number of computers (copy files to \\remotepc\admin$\system32, then connect the remote registry hives and make appropriate changes).

GINA stands for Graphical Identification aNd Authorization and describes an interface for the validation of logon credentials. The default implementation is msgina.dll. NT offers the possibility to replace this GINA with a custom one, e.g. to allow identification via smart cards, iris scanning etc. The interface (i.e. which functions any GINA must make available to the WINLOGON process and which WINLOGON functions it can call back) is described in gina.hlp found in directory \mstools\samples\win32\winnt\security\gina on the Win32 SDK CD-ROM. Besides completely rewriting all the GINA functionality, one has the possibility to put a shim between the WINLOGON process and the original GINA which intercepts all calls to the GINA, and so can react under certain conditions, while all other calls are passed to the original GINA without modifications. This way no functionality of the underlying GINA is lost, but new functionality can be added. A basic example how to do this can be found in \mstools\samples\win32\winnt\security\ginastub on the Win32 SDK CD-ROM. This sample was alse used as a skeleton for my new GINA. (At the time of writing one could find these samples on the Microsoft website in the MSDN Online section, but this changes frequently.)

To tell WINLOGON to call a new GINA instead of the original msgina.dll, one has to add a value GinaDLL, type REG_SZ, containing the filename (and path if not in %systemroot%\system32), under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon (...\Winlogon for short in the following). If you already use a non-standard GINA (e.g. Novell's IntraNetware Client), this value might be present. NEWGINA saves this entry in the value OriginalGinaDLL under the ...\Winlogon key and of course will use this GINA instead of msgina.dll as the underlying GINA (e.g. nwgina.dll for Novell).

a) Get rid of Ctrl-Alt-Del prior to logging on

This option can be configured with the NeedCtrlAltDel value under the ...\Winlogon key. It can be either REG_SZ or REG_DWORD. 1, yes or true (case insensitive) if you still want to press Ctrl-Alt-Del to log on, or 0, no or false if you want to get rid of it. If the value is not present, it defaults to 0!

It is implemented by hooking the WlxDisplaySASNotice() call. Instead of displaying the 'Press Ctrl + Alt + Delete to log on' message, WlxSasNotify() is called, which simulates a Ctrl-Alt-Del secure attention sequence and in turn brings up the logon dialog box.

b) Prevent password protected screen savers

This option can be configured with the AllowProtectedSS value under the ...\Winlogon key. It can take on the same values as NeedCtrlAltDel and defaults to 1, which means that protected screen savers are possible.

It is implemented by hooking the WlxIsLockOk() function, which WINLOGON calls when it wants to lock the screen. It gives the GINA the possibility to exercise a veto. If AllowProtectedSS is 1 or the current user is an Administrator, the decision is left to the underlying GINA, otherwise it returns FALSE.

c) Run a script at system shutdown

This option can be configured with the Script (the .exe or .bat file you want to execute), Logfile (a file where the output from the script is logged to), Timeout (REG_SZ or REG_DWORD in seconds after which time the script is killed, default 60 seconds, 0 means no timeout which is not recommended), Account (in the form DOMAIN\USER, no account means LOCAL_SYSTEM) and Password values under a newly added ...\Winlogon\Shutdown key. The password is not encrypted, but the key has read access for Administrators only. Take care that no users get hold of copies of the registry files (Emergency Repair Disk or files in %systemroot%\repair).

It is implemented by hooking the WlxShutdown() function.

d) Run a script at logoff

This option can be configured with the UserScript, SystemScript, Logfile and Timeout values (see c for details) under the ...\Winlogon\Logoff key.

It is implemented by hooking the WlxIsLogoffOk() function.

4. Installation

a) Precautions

Read this documentation carefully before you begin! IT IS *REALLY* DANGEROUS TO PLAY AROUND WITH GINAs. IF YOU INSTALL A CORRUPT GINA, YOUR SYSTEM WILL NO LONGER BOOT. I have experienced this several times while developing this program!

So, first the standard disclaimer:
This program is provided "as is" and comes without any warranty of any kind, either expressed or implied, including but not limited to fitness for a particular purpose or a particular system. In no case shall the author be liable for any damage or unwanted behavior of any computer hardware and/or software, including but not limited to data loss or time spent to recover your system. Do not test this program on your production machines without a backup you know you can restore!

As a minimum equipment to recover your system, prepare a NEW Emergency Repair Disk (with rdisk /s) and the three setup disks (winnt /ox, in the \i386 directory of your NT CD). In case of failure, boot from the setup disks, choose the repair option, and restore the SOFTWARE hive of your registry from the ERD.

If you have 200-300 MB left on your hard disk, I ADDITIONALLY recommend to make a local backup copy of the \winnt directory to \winntbak with 'scopy /o/a/s' from the Resource Kit. You must manually expand the registry hives which scopy could not copy from \winnt\repair to \winntbak\system32\config and \winntbak\profiles\administrator (ntuser.dat) resp. Then, duplicate the existing lines for Windows NT in c:\boot.ini and change c:\winnt to c:\winntbak. Test if you can boot your backup system. Now you can modify the original installation's registry with the Load Hive... option in RegEdt32 (c:\winnt\system32\config\software). (I silently assumed that %systemroot% is c:\winnt.)

For full safety, back up your complete system to a tape. (And verify that you can restore it!)

b) Unpacking the files

You must be logged on as a member of the Administrators group (not necessarily the Administrator itself). Unpack the distribution file with a unzip program which preserves long filenames and the directory structure. I recommend Info-ZIP's unzip 5.x for Alpha or Intel (the full package with documentatin and source can be downloaded for free from ftp://ftp.cdrom.com/pub/infozip/). You further need the Microsoft Foundation Classes library mfc40.dll for Alpha or mfc42.dll for Intel which are not included in this distribution, because you will probably already find them on your system (in %systemroot%\system32, where %systemroot% is your Windows directory, e.g. c:\winnt) and they are quite large (1MB for Intel, 2MB for Alpha). If they are not on your system, download and copy them to %systemroot%\system32.

c) Actual installation

After unpacking, you will find some documentation files in the current directory, subdirectories .\axp and .\x86 with the binaries for Alpha and Intel resp., and a subdirectory .\source with the source files. Change the current directory according to your architecture (cd axp or cd x86; see the section Rebuilding from source if you have neither Alpha nor Intel). Then start the ginasetup.exe program. It will test if the new GINA is already installed, if not prompts you to copy the files gina_(arch).dll and ginasetup.exe to %systemroot%\system32 (where (arch) is axp or x86 resp.). You will have to reboot now (sorry, it is really necessary).

5. Configuration

To configure the options of the new GINA once it is installed, start ginasetup.exe again. Since it is now in %systemroot%\system32 you do not have to specify a path.

The setup window is divided into three sections. Topmost you will find the General options, in the middle the Shutdown script options, and at the bottom the Logoff script options.

a) General options

• Ctrl-Alt-Del required before logon: controls if you have to press Ctrl-Alt-Del to bring up the logon box. Disabling this options makes your system vulnerable to Trojan Horse attacks: a malicious user could write a program that looks like the logon box, but captures the password you entered to a file. This is certainly not a problem for your home machine. Besides, if you have not yet set proper permissions for the files in %systemroot% and below (you are using NTFS, aren't you?), you have a severer security problem than this. One the other hand, you can still press Ctrl-Alt-Del to make sure WINLOGON receives your keyboard input.
• Change original and underlying Gina: this is primarily meant for informational purpose. It shows which Gina implementation does the actual work (usually msgina.dll, but e.g. nwgina.dll if you use Novell's IntraNetware Client). You can change it, but there is hardly a reason to do so.
• Allow password protected screen savers: controls if ordinary users may choose a password protected screen saver that prevents other users from using the machine (more precisely, the users can still choose protection in the Screen Saver tab in the Display icon in Control Panel, but it is ineffective: the screen saver will run unprotected without an error message). If the current user is a member of the Administrators group, he is still allowed to set a password protected screen saver. He might have good reasons to do so, and he could change this setting anyhow.

b) Shutdown options

• File name: you should use the full path to the file you want to execute. The file can be an executable or a batch file. It must be on a local drive or an UNC path (\\server\share\file), the latter only if you run the script under an account other than the System account.
• Log output to: specifies a file to which 'Standard Output' and 'Standard Error' of your script are redirected (due to buffering, stdout and stderr might not be chronologically). Additionally, start and end of the script is logged with a time and date stamp, as well as the exit code of the script.
  The logfile is created if it does not exists, otherwise output is appended. Delete it manually from time to time.
  To track down errors with failing scripts, put commands like ECHO ON, SET, NET USE, and WHOAMI (from the Resource Kit) at the beginning of your batch file.
• Terminate script after xxx seconds: In contrast to other some shutdown solutions, no 'Application is not responding' dialog pops up or the script is terminated by the system after 20 seconds. In principle your script may run virtually forever (e.g. you can make a full backup to a tape or network drive), however this is not recommended, because a buggy script may prevent a proper system shutdown. 60 seconds should be enough for most tasks, e.g. copying some important files to some backup location. Please note that it is not waited for (GUI) child processes spawned from your script. See START /WAIT instead.
• Run as: System: specifies that the script should run in the security context of the LocalSystem account which has full access to the local machine, but no access to the network. For short, any script that would run with the AT command should work as a shutdown script as well. See any good FAQ for the most common problems with the AT command.
• Run as: Other account: specify an account in the form DOMAIN\USER (.\USER or simply USER for a local user) if the LocalSystem account is not appropriate for you, e.g. if you need network access to save files. You can use any account, e.g. the local Administrator, a Domain Administrator, a low privileged user, depending on the rights the script needs. This is similar to the setup of the Startup Type of a service in Control Panel/Services.
• Password and Confirm: type in twice the password of the account under which the shutdown script should run (not needed for LocalSystem). Currently, the password is written unencrypted to the registry, but the key is readable only for administrators. I think encryption is useless in this case, because I would have to use a fixed (or deterministic) key to encrypt the password, which could be easily found out by anyone who reads the source code. Therefore, you must protect all copies of the registry files, which can be found (at least) on the Emergency Repair Disks and in %systemroot%\repair. Whenever you change the password of the account, you must change it here as well.
  A question to the experts: where and how does NT store the passwords for services running under non-system accounts? I guess they can be found decryptable in the binary structure under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Servicename\Security. Is this again a case of security by obscurity?

c) Logoff options

• File names: analogous to the File name for the Shutdown options, but here you can specify two scripts (one may be empty): The System context script is executed under the security context of the LocalSystem account (limitations see above), whereas the User's context script is executed under the user's security context. The user's network drives are available, however not all environment variables (USERNAME, USERDOMAIN, HOMEDRIVE, HOMEPATH, HOMESHARE, TEMP). The user's script is executed first.
• Log output to: see Shutdown options
• Terminate script after xxx seconds: see Shutdown options

6. Uninstallation

7. Troubleshooting

1. Terminate the Ginasetup program.
2. Make sure you are logged on as a member of the Administrators group.
3. If you do not have a backup, it is really high time. If you choose to create an Emergency Repair Disk, do not overwrite your last one!
4. Start the Registry Editor regedt32.exe from the Command Prompt (you should always use regedt32.exe with Windows NT, not regedit.exe, which is for Windows 95). Check the key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.
   The Registry Editor works similar to File Manager or Explorer: in the left half of the window you see the keys (which are like directories/folders), and in the right half you see which values (like files) are under a selected key. Keys and values are case-insensitive.
   • If you are using the normal Windows NT authorization (most likely):
     If there is a value 'GinaDLL', delete it .
   • If you are using non-standard authorization (e.g. through a Novell or Unix server, a smart card reader etc.):
     You must enter a valid string for the value 'GinaDLL'. You will find it in the documentation of your authorization package. A hint could be if there is still a value 'OriginalGinaDLL' present (I think for Novell it should be nwgina.dll). If you are unsure, you should delete the value 'GinaDLL'. Windows NT will use the original Microsoft msgina.dll. I hope you still know the Administrator password.
5. Test if msgina.dll is present in %systemroot%\system32 (%systemroot% means your Windows NT directory, e.g. c:\winnt). It should have a size of about 79000 Bytes for NT 3.51 and 122000 Bytes for NT 4.0 (exact size depends on your language). If not, restore it from the distribution CD with 'expand [cdrompath]msgina.dl_ %systemroot%\system32\msgina.dll' (where [cdrompath] is e.g. d:\i386, but do never mix up Intel/Alpha/PPC files). If it is there, but seems to be corrupt, you may have to do a 'ren %systemroot%\system32\msgina.dll msgina.dll_to_be_deleted' first since the file may be in use.
   If you are using non-standard authorization, consult your documentation on which files are needed.
6. Verify that the files from step 5 are not marked for deletion at the next reboot (i.e. they exist now, but may disappear). With regedt32.exe, check if there is a value 'PendingFileRenameOperations' under the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager (do not get confused with the key FileRenameOperations). Remove needed files from the Multi-String.
7. Now it should be safe to reboot.

8. Implemented and tested platforms

This distribution contains binaries for DEC Alpha and Intel x86.

The program is tested on NT 4.0 Server (U.S./Intel) and NT 4.0 Workstation (U.S./Alpha and German/Intel). I do not expect problems with international NT versions, because there are no language-specific system calls (at least for those versions based on Windows codepage 1250, as all American and Western European languages).

An older version was reported to run on NT 3.51 as well. The GINA specifications are backward compatible. But I doubt it will work on upcoming NT 5.0 without modifications, especially if it will really include multi-user capabilities (no use is currently made of the pWlxContext pointer that may serve to distinguish between users).

You should not notice any side effects, since all calls to the new gina are directly passed to the original msgina.dll. Therefore it should work as well with systems that have a replaced GINA, e.g. systems where authentication is performed on a Novell or Unix server. On these systems, you will already have a GinaDLL value in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon. The value from GinaDLL will be saved in a new value OriginalGinaDLL under ..\Winlogon.

9. Rebuilding from source

#ifdef _M_IX86

10. Files

11. Examples

Backup of registry files

%systemroot%\system32\rdisk.exe /s-
net use x: /delete
net use x: \\YourServer\RepairShare$ /persistent:no
if not exist x:\%computername% md x:\%computername%
copy %systemroot%\repair\* x:\%computername%
net use x: /delete

Clear temp directory at logoff

del /q c:\temp\*

12. Feedback/possible improvements

Thanks to Gary T. Desrosiers for his sample GINA source code.

If you have any suggestions, ideas for improvements, problems or anything else concerning the program or the documentation, send an e-mail to Alexander.Frink@Uni-Mainz.DE or snailmail to Alexander Frink, Hermann Schauss Str. 8, D-65232 Taunusstein, Germany.

A short list of possible improvements I have collected:

• make more environment variables available for logoff/shutdown script