Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
The Solution
The answer to this problem is to use pGINA.
Before we talk about pGINA, let's talk specifically about how things work. Windows by default, uses something called GINA for authentication.
What is GINA?
GINA stands for Graphical Identification and Authentication. GINA is a dynamic-link library (DDL) that is part of the Windows operating system. GINA is loaded early in the boot process by Winlogon.exe. Once loaded, GINA handles the following functions:
SAS Recognition – Stands for secure attention sequence recognition. The GINA can have its own SAS, and carries the responsibility of recognizing the SAS. This is not required if the GINA decides to use the Standard SAS of the WinLogon.exe (Ctrl + Alt + Del). The GINA makes the appropriate calls, depending on the current state of the station. If the GINA uses the standard SAS, the WinLogon.exe automatically calls the appropriate routine.
User Interface – Since the GINA can provide an alternative identification mechanism, it is the responsibility of GINA to display the entire user interface that is needed to perform the logon authentication. The GINA has to display the user interface to collect data needed to perform the authentication, and all other user interfaces depending on the state of the station.
Shell Creation – When a user performs a successful logon, the GINA works with WinLogon.exe to create the initial processes and assign the processes that the user's access token obtained from the WinLogon.exe. This process must start the default shell for the user. Normally, userinit.exe is started as the initial process. This program is run in the user's context and the user's desktop. It sets up the user environment by restoring the network connection, loading the user's profile (color, font, screen savers, and so on) and running logon scripts. It then activates the shell programs with the same environment as itself. The standard shell for Windows NT is Explorer.exe. This program manages the desktop, taskbar, and so on. Once the shell is created with the user's access token, all other processes created by the user automatically inherit it, thus securing the resources.
Windows Authentication Architecture
During a power-on or boot-up sequence (FIGURE 3), the Winlogon.exe process is started. This process continues to run in the background during the entire time the OS is loaded.
When a user issues the SAS to logon, the Winlogon.exe process calls the GINA DLL to handle the user identification and authorization process. GINA presents a logon dialog for the user to fill out. Using this dialog, GINA acquires the information it needs to authenticate the user.
GINA then contacts either the Active Directory or the Domain Controller. After GINA has validated the user, it returns a token and control to the Winlogon.exe process, which in turn starts a user-level shell using the permissions of the user and then creates the user's environment using the authenticated user's environment settings and appropriate scripts.
Once the user's shell and environment is set up, Winlogon.exe turns control of the shell over to the user.
)
FIGURE 3
Windows Authentication Architecture
What is pGINA?
pGINA stands for Pluggable Graphical Identification and Authentication.
pGINA is an add-on DLL for the standard Microsoft GINA and provides a framework that allows different methods of authentication. These are implemented by the use of authentication plug-ins
Just as pluggable authentication module (PAM) technology brings different authentication methods to UNIX, pGINA brings this same functionality to the Windows environment.
pGINA provides the skeleton code necessary to quickly and easily implement many different methods of user authentication. Once a plug-in has been created for a particular authentication method, it can be easily installed on multiple systems. The new plug-in can be made available to other users without the users needing an in-depth understanding of the Windows logon process. Some of the plug-ins that already exist for pGINA are OpenLDAP and Radius. Available plug-ins are discussed later.
Windows Authentication Architecture With pGINA
When using pGINA, the process is the same as with GINA except the user issues a SAS to logon, the WinLogon.exe process calls the pGINA DLL to handle the user identification and authorization process. pGINA presents a logon dialog box for the user to fill out. Using this dialog box, pGINA acquires the information it needs to authenticate the user. pGINA passes any information or requests that it is not configured to handle to the GINA DLL for processing.
Depending on the configuration, pGINA then authenticates the user by using whichever authentication modules are needed. If pGINA is configured to use LDAP, pGINA uses the LDAP plug-in that authenticates through LDAP on behalf of the user—typically called a bind or referred to as binding to the directory. pGINA can also be configured to chain the authentication methods so that multiple methods are used. This is represented as by ellipsis in FIGURE 3.
Once pGINA has validated the user, it passes any configuration information and returns a token and control to the WinLogon.exe process (FIGURE 4). This, in turn, starts a user-level shell with the permissions of the user logging in and then creates the user's environment by using the authenticated users environment settings and appropriate scripts, and so on. Once the user's shell and environment is set up, WinLogon.exe turns control of the shell over to the user.
)
FIGURE 4 Windows
Authentication Architecture With pGINA
Available Plug-ins
There are currently a total of nine publicly available plug-ins from http://pgina.xpasystems.com
LDAPAuth – For authentication against an LDAP server
Chaining Plug-in – Allows you to stack individual plug-ins
PAM for pGINA – For authentication with UNIX PAM
MySQLAuth Plug-in – For authentication against a MySQL database
POP3 Plug-in – For authentication against a POP3 mail server
NIS Plug-in – For authentication against an NIS server
ACE (SecureID) Plug-in – For authentication to a domain with RSA's SecureID product
OpenAFS Plug-in – For authentication against an AFS realm
RADIUS Plug-in – For authentication and accounting with RADIUS
Good Situations for pGINA
There are several scenarios where pGINA is a good fit for a particular environment:
When you already have, or are going to implement, a mixed UNIX/Linux/Windows environment.
If you have already installed Active Directory and are struggling with it; or if you are in the planning stages of an Active Directory implementation.
If you are migrating away from Windows 95, Windows 98, or Windows Me to Windows XP or Windows Server 200X.
If you understand and appreciate the value of maintaining a single point of authentication.
Not So Good Situations for pGINA
There are also several scenarios where the implementation of pGINA might do more harm than good:
You have a Microsoft-only environment.
You don't want to use UNIX or Linux naming services.
You need Active Directory services for advanced Microsoft services such as Exchange.
You have an extremely large number of clients. While supporting a large number of clients with pGINA is not impossible, it requires more care in the implementation phase.
Things to Consider
Before installing and using pGINA, plan carefully. The following list describes some of the areas that you should take into account:
Policies – Determine which authentication policies you want to implement.
Features – What pGINA features do you plan to implement? Which plug-ins suit your needs?
Options – There are a number of options you can choose to implement. Do you want to replace the logo and other options?
Testing – Implement the plug-ins and features in a test environment before deploying to your production environment.
Piloting – It is a good idea to run a pilot program for pGINA with a select group of users.
Rollout – Finally, roll out the approved configuration. If necessary, roll it out in a phased manner.