|
|
|
|
|
|
|
  |
||||||
|
|
|||||
|
       |
|||||
|
||||||
|
 |
|||||
|
WolfCall Auto-Login Procedure: Technical Summary and Usage Instructions |
|||||
Ben Creech
ITECS, NCSU College of Engineering
The auto-login feature included in WolfCall version 0.5.3+ is intended to provide a single sign-on for Windows machines, eliminating the “second login” currently associated with Kerberos authentication. The present document explains the inner workings of this feature, as well as how to properly implement the auto-login feature in a lab environment.
If you are only interested with how to use the auto-login feature, see Usage below.
Background
As of this writing, a user who logs into a Microsoft Windows machine on the NCSU campus is usually authenticating to multiple services: a Novell or Active Directory tree, the local machine, and the Kerberos system. The former two are handled by the machine’s GINA DLL, whether it be Microsoft’s stock msgina.dll or the Novell Client’s nwgina.dll. After a successful Windows login and session creation, a Kerberos authenticator (KAUTH or WolfCall) is started, usually by a login script. Here, the user must again enter username and password to gain access to Kerberos services and AFS.
In the days of Windows NT4, NCSU used a custom GINA to do all three authentication steps in one. This method worked fairly well, but because of the inherent difficulty of maintaining a custom GINA, the NCSUGINA was never ported to Windows 2000 or XP.
Methodology
The WolfCall auto-login feature is composed of two components: a Network Provider Dll, and a ticket file service (krb_tfnp.dll and tfservice.exe, respectively). These work together to get Kerberos tickets and deliver them to the user’s session.
See auto-login.pdf for a diagram illustrating the following.
The Network Provider Dll
The WolfCall auto-login uses a Windows feature called the “Network Provider API” (Application Programming Interface). The NPAPI provides an interface for network-related add-ons to Windows, which come in the form of user-made Network Provider Dlls. This API was introduced in NT4 and has been largely unchanged since then. Since it is a part of Winlogon (which is hierarchically above the GINA), custom login procedures such as Novell’s do not affect its operation.
NP Dlls can perform two groups of tasks: connection notification (drive mapping, device redirection, etc), and credential management. WolfCall’s NP Dll does the latter of these.
By registering as a credential manager, the WolfCall NP Dll receives notification of all successful Windows logins. This notification comes with various parameters, which include the username and password. These can then be sent off to WolfCall’s existing login procedures to automatically authenticate to Kerberos, removing the need to authenticate again.
Ticket File Service
Unfortunately, things are not quite that simple. Windows calls the NP Dll in the context of LocalSystem (i.e., the operating system), before the user’s login session is even created. Since the MIT Kerberos ticket file is stored in a process running in the login session, authenticating from the Network Provider Dll will end up giving the Kerberos tickets to LocalSystem, but not the user. This is fairly useless.
Therefore, after the NP Dll gets its Kerberos tickets (stopping at the v5 and v4 TGT for simplicity), it packs them up and sends them to WolfCall’s Ticket File Service. There, they are stored while the NP Dll exits, Winlogon proceeds, and the user’s login session is finally created.
The Ticket File Service is rather simple in nature. It merely allows users to store data in it, holding it in a secure fashion, and only letting specific users get that data back out. When the NP Dll sends its tickets to the TF Service, the TF Service checks that the other side is indeed running as LocalSystem, then stores the data with a tag indicating the target user (identified by the unique login session ID generated by Windows). After the data is stored, the service will only let the target user read that particular bit of data back out. This should provide a completely secure ticket cache, even on a multiple-user system (such as a Terminal Server).
Once the user’s login session is created, WolfCall is started with a parameter (/tfsl_login) which instructs it to fetch the k5 and k4 TGT from the TF Service, move those tickets to the (normal) MIT ticket cache, and complete the usual Kerberos authentication procedure (getting AFS tickets and mapping drives).
Usage
Installing
To use the auto-login feature, do a “custom” install of WolfCall and change the feature to the installed state. The service and NP Dll should automatically be registered.
Using with Novell
The auto-login does not work out-of-the-box with Novell.
The difficulty is with the second part of the login procedure, described above. At some point after the user’s session is created, WolfCall must be called with “/tfsl_login” to complete the authentication, moving tickets into the MIT ticket cache. By default, this is done automatically using the login script functionality built into the Network Provider interface. However, this method does not appear to work well with Novell, which seems never to call WolfCall as requested.
Therefore, WolfCall must be put into the user’s Novell login script:
1) Set the following key to “0”:
-
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ krb_tfnp\Parameters\DoFinish
This will stop WolfCall from attempting to kick off the second part of the authentication itself.
2) Next, put a call to “wolfcall.exe /tfsl_login” in the user’s login
script.
For an example of a working login statement, with if/thens for KAUTH and
WolfCall without auto-login, see .COE.scripts.users in NCSUNDS.
Extra Registry Options
There are a couple extra options not listed in the GUI that may be useful for administrators:
-
HKEY_LOCAL_MACHINE\SOFTWARE\ NC State University\
WolfCall\FinishAutoAuth
-Set to “0” to disable or “1” to enable the second stage of the auto-login for all users on this machine.
-
HKEY_CURRENT_USER\SOFTWARE\ NC State University\
WolfCall\FinishAutoAuth
-Set to “0” to disable or “1” to enable the second stage of the auto-login for this user.
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\ krb_tfnp\Parameters\NoUserContinue
-If there is an “unknown user” error in the initial part of the login, the NP Dll will is set to "0" stop with an error, "1" automatically continue after a two-second pause, or "2" continue silently with no error. This is so that the “administrator” (or similar) account does not stop with an error every time.
Problems?
If there are any problems with the auto-login feature, a Control-Alt-Delete on login will make Windows skip it, and unchecking the feature in WolfCall will disable it. Also, the WolfCall Service can be set to "manual,” although this should be unnecessary.
Technical Documents
Auto-login White Paper
![< to Top]](../Media/graphics/footer_links/top_arrow.gif){kind=icon}
![[ ENGR Template ]](../Interface/images/banner.gif){kind=small}