How does NWGINA work?

(Last modified: 09Oct2002)

This document (10059511) is provided subject to the disclaimer at the end of this document.

goal

fact

Novell NetWare Client for NT

Formerly TID 2951738

fix

In order to understand how NWGINA works you need to understand Winlogon and NT's associated security/authentication pieces as well, because NWGINA is a piece of a larger process with which it interoperates.

During the system boot process the subsystem calls Winlogon. Winlogon is responsible for all security aspects involving user interaction, namely logon, logoff, and locking the workstation. Winlogon in turn calls other processes that assist in these functions, particularly NWGINA.DLL and LSASS, as well as the network providers. The modularization of these processes allow for 3rd party value-adds such as biometrics, or Novell's NDS capabilities such as workstation manager and Zenworks policy management. Below is an ASCII diagram of the modular Winlogon:

Winlogon Structure

Winlogon.exe
___________________________________________________________
gina.dll | network provider.dll | novnpnt.dll | ntlanman.dll | ...

When Winlogon starts it is responsible for security in the desktop environment. The three types of desktop security environments are the Winlogon (secure) desktop, application desktop, and screen saver desktop. When you start the machine it creates the security desktop where the only services anyone can access is the screen, the keyboard, and the mouse. These three items comprise what is called a windows station, a virtualized machine, to which Winlogon attaches a unique security identifier to prevent other processes from accessing it without Winlogon's permission. Applications such as Terminal Server can allow multiple concurrent instances of windows stations. With this condition any user or process is strictly isolated from the desktop - everything must go through Winlogon . As Winlogon is initializing and preparing this environment it calls the APIs WlxNegotiate() and WlxInitialize(). This is where the GINA comes into play because it is responsible for these functions. In the case of NWGINA all it does is check the version of Winlogon; initialize some environmental tables, and load the welcome screen.

Now that GINA is loaded it waits for SAS (Secure Attention Sequence) to invoke the authentication process. By default the SAS is the Control ' Alt ' Delete key combination. Other potential examples could be a smart card insertion or biometric reading. When this key combination is pressed GINA calls WlxSasNotify() to indicate a SAS has been entered. Winlogon delivers SAS back to NWGINA by calling NWGINA's WlxLoggedOutSas(). This begins the process of authentication to the local machine and any network services involved.

When WlxLoggedOutSas() is called LGNWNT32.DLL and LOGINW32.DLL are loaded which display and process the login screen. NWGINA pulls the login information from the registry and it is displayed. The registry location is \\HKLM\Software\Novell\Graphical Login and \Login for much of this information. When the user presses the 'OK' button NWFS.SYS, which is already loaded and initialized at this point, finds the network using the drivers found in %SystemRoot\system32\NetWare, which the NT boot process has also already loaded. Which ones it loads depends on your preferred protocol and the protocol component settings. Examples would be nwdns.sys, nwdhcp.sys, nwhost.sys, etc. These do the work of finding and contacting the network under the direction of NWFS.SYS. At this point the initial authentication to the tree is made.

When this happens, assuming the first part is successful, NWGINA then checks to see if Workstation Manager is configured on the machine. If so, it will look to see if a Workstation Management object is associated with the user. If so it will create the account locally if necessary and include the new user in whichever groups are specified in the Zen policy.

Thereafter begins local machine login where NWGINA passes this information to LSASS.EXE via an API called LSALogonUser, which in turn passes it on to the NT authentication package, MSV1_0, which handles that portion of the authentication duties. LSASS.EXE comprises two main components: The Local Security Authority Server (LSAS) and the Security Accounts Manager Server (SAMS). The former is responsible for the security authority, namely who has access to what and various policies. The database resides in \\HKLM\Security. The other component, the SAM server, will check the local SAM in \\HKLM\SAM to see if it contains the user and group names for the local machine or domain if it is a domain controller. MSV1_0 is in charge of matching the password to the user ID, and if it does returns information specific to that user. If it's a domain logon then Netlogon (a service, part of SERVICES.EXE) is called by the LSA. Netlogon passes the same information back to LSA and then Winlogon. The LSA also creates the access token and passes that to Winlogon.

If all goes well LSALogonUser returns success to NWGINA. The access token contains the summation of user rights granted via the group memberships of the user. NWGINA checks for the expiration of NT password and verifies that they're synced. If they're not it will synchronize them if the user has checked the box in the NT tab to do so. NWGINA then examines the access token that LSA created. At this point the login dlls are unloaded (the login box disappears) and NWGINA synchronizes time with the network.

Now NWGINA starts working on profiles and policies. The first thing it does is call functions within the WMPM.DLL library to look for an NT NDS policy object associated with the user. If that fails it checks for a default policy NTCONFIG.POL at the user's defined default server. Next it looks for an NDS profile (WINNT User Package and NT Desktop Preferences objects). If it hasn't found anything at this point it checks if the NT profile path is local or remote and sets it accordingly. It also checks to see if NT policies are configured and if so, where they are located - locally or on an NT server.

NWGINA momentarily switches from working on profiles to look for WINNT User Packages and Workstation Creation Policies associated with the user. It records the NDS path/context and the registration interval, and flags the Workstation Scheduler WM.EXE to schedule registration. This information is stored at \\HKLM\SOFTWARE\Novell\Workstation Manager\Identification.

NWGINA now returns to the profile setup where if the profile is local, it determines exactly where it is and if any actions will need to be taken, such as creating a new profile directory, making a new user profile using the default one, and determining whether to use a local default profile or domain default profile. These actions are performed now after the determinations have been made. Then it looks for the profile itself, first for a .MAN extension and then .DAT and temporarily loads it. It then checks again for WINNT User Package and NT Desktop references objects associated with the user. If the profile has changed since the last time it was processed it is processed now, reading in all the profile attributes. NWGINA then calls a helper dll, WMUSPOL.DLL, to push the policy attributes into the temporary user hive. Another helper dll that may be loaded at this time is WMPRTNT.DLL which loads workstation inventory information to the NDS workstation object.

After those things are done the temporary profile hive is unloaded. If there are any changes applied to it they're saved first. Winlogon will then load the profile itself. Now WlxLoggedOutSas exits and returns back to Winlogon. Winlogon updates the state to remove the secure desktop and switches over to the application desktop. It calls WlxActivateUserShell() which is supported by NWGINA. GINA begins monitoring for successful boot completion. While this is happening NWGINA verifies the SID and checks that NWTRAY.EXE is in listed in the registry key \\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, and if not will place it there. This will force it to run when the desktop is loaded which brings up the red 'N' icon and Workstation Scheduler. If Volatile User Caching is enabled NWGINA stamps it so anything that exceeds the limit can be removed.

NWGINA checks \\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList to get the current profile path and re-checks the SID. Using this it looks at \\HKU\{SID}\SOFTWARE\Novell\Graphical Login\ENVPATH for any paths that may have been placed there and removes them. Then it reads and caches the network user environment, such as the location of the NT logon script, home directory, and local default directory.

Once this is done NDDEAGNT.EXE is loaded to start some of the Windows networking functionality as well as NWLSCRPT.EXE is called to process the NetWare login script. As the login script is finishing NWGINA calls USERINIT to load the explorer shell and copies over the user environment, such as paths and environmental variables.

Flow when locking workstation:

Winlogon calls WlxLoggedOnSas, which is owned by NWGINA. NWGINA calls LoggedOnSasDialogInit which displays the task manager screen which you see. NWGINA checks the access token to verify that the user has the rights to lock the workstation. If the user presses OK it displays the locked workstation notice and sends a flag back to Winlogon which changes the state to locked. When the user returns to unlock the workstation NWGINA notifies Winlogon of the SAS again, which in turn calls WlxWkstaLockedSas. NWGINA then loads LGNWNT32.DLL which displays the login GUI. If the password is correct WlxWkstaLockedSas returns a flag to Winlogon to unlock workstation. Winlogon restores the user environment..

document

Document Title:	How does NWGINA work?
Document ID:	10059511
Solution ID:	NOVL36822
Creation Date:	05Jan2001
Modified Date:	09Oct2002
Novell Product Class:	NetWare Novell eDirectory

disclaimer

The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.