NI PAM: Pluggable Authentication Module for Windows NT

A Directed Study Report

NI_PAM: Pluggable Authentication Module for Windows NT

Naomaru Itoi

Center for Information Technology Integration, University of Michigan

January 13, 1998

1Introduction

1.1Introduction

Security technologies are constantly evolving – for example, 1) network authentication protocols such as Kerberos 4 [SNS88], Kerberos 5 [KNT91], and Netware 4.0, and 2) authentication hardware such as smartcards and fingerprint recognition. It is desirable to provide high-level abstractions that hide low-level authentication mechanisms (or AMs) and their changes for application programmers, system administrators, and users. The Pluggable Authentication Module, or PAM, framework provides an attractive abstraction. PAM 1) makes authentication components replaceable, 2) defines generic API for authentication mechanisms, and 3) provides single sign-on for users [SS95]. PAM is implemented in Linux and Sun Solaris-2.X operating systems, and is a de facto standard authentication framework. PAM is also being standardized by OSF and IETF.

In Windows NT operating system, lack of PAM makes it hard to develop and configure an authentication program. Our project is an attempt to implement PAM in Windows NT. A replaceable part of the authentication program in Windows NT is called GINA [MS96]. We implement a subset of PAM in Windows NT (we refer to our PAM in Windows NT as NI_PAM), and integrated it into GINA. It turns out that NI_PAM greatly helps development and configuration of GINA.

1.2 Contents

Section 2 explains PAM. Section 3 explains the Windows NT authentication mechanism, especially GINA, and states problems with GINA. Section 4 describes our design of NI_PAM to improve GINA, and its detail. We discuss results of the project and conclude in Section 5.

2Pluggable Authentication Module (PAM)

PAM (Pluggable Authentication Module) is a framework that provides a generic way of authenticating users. PAM 1) makes authentication components replaceable, 2) defines a generic API for authentication mechanisms, and 3) provides single sign-on for users.

2.1 Replaceable authentication modules

A system administrator may want to replace an authentication mechanism and its components either because a new authentication mechanism is developed, or because her security policy is changed. PAM provides a dynamically configurable (or pluggable) authentication mechanism by splitting high-level application programs (e.g. login, ftp, telnet, etc.) and low-level authentication modules (e.g. Kerberos, Netware, etc.). PAM introduces a configuration table to define the behavior of application programs. The configuration table is maintained by system administrators. Figure 2.1 shows a simple example of the PAM configuration table.

The example shows a configuration for a “login” application program, which uses three authentication mechanisms: UNIX local, Kerberos, and Netware. The flag “required” means that a user must be authenticated by the listed authentication mechanism to be accepted by “login” program. Another flag “optional” means that the system tries to authenticate the user to the listed mechanism, but the user still can be accepted by “login” even if he is not authenticated by the mechanism. In the example, the “login” program requires a new user to be authenticated successfully in UNIX local authentication and Kerberos authentication. If he is authenticated by both, he could login to the computer. In addition, the login program attempts to authenticate the user to Netware. However, since the flag for Netware is optional, the user can still login, even if Netware authentication failed.

Changing behavior of an application program is accomplished by modifying a PAM configuration table. For example, one can make “login” program to use S/KEY authentication mechanism by adding a line to the configuration table:

loginauthrequiredpam_skey.so

One can also make “login” not ask for Kerberos authentication by removing one line for pam_kerberos.so. The modification can be done without writing, compiling, or installing any code.

2.2 Generic API for application programs

With PAM, application programs (e.g. login, ftp, telnet, and so on) do not call authentication mechanism specific functions (e.g. krb5_get_in_tkt()). Instead, they call PAM API functions such as pam_authenticate(). Figure 2.2 shows examples of PAM API.

The PAM API is a high-level abstraction that hides low-level authentication mechanism details. An application program written with PAM API is independent from authentication mechanisms. That is, modification in a configuration table does not affect application programs. In the example in Section 2.1, “login” program is not changed when an authentication mechanism is added, or removed.

2.3 Single Sign-On

When a computer system has multiple authentication mechanisms, a user is often required to remember various ways of authentication and remember multiple username and passwords. Ideally, a user is required to remember only one password, and she can get access to all resources by typing the password only once. This feature is called single sign-on [HAR95]. PAM provides single sign-on to users by sharing passwords among authentication mechanisms. In Figure 2.1, “use_first_pass” in the option field of Kerberos entry specifies that a password for UNIX local authentication is used as the password for Kerberos authentication. “use_mapped_pass” in Netware entry specifies that a password for UNIX local authentication is used to derive a password for Netware authentication. PAM gives passwords to all authentication mechanisms, while it asks a user to type a password only once.

2.4 Example

To show the advantages of using PAM, we look at an example of how PAM simplifies login with multiple authentication mechanisms. Figure 2.3 shows a computer system without PAM. A “login” program requires UNIX Local and Kerberos authentication. A program for authentication for both UNIX Local and Kerberos is hard coded in the “login” program. Suppose a system administrator wants to add Netware authentication to the “login” program because some users of his system elect to use Netware file service. He must hard code an authentication program for Netware in the “login” program. Worse yet, when the users want to use ftp that accesses Netware, he must write a new code for the “ftp”, although he already wrote the authentication code for the “login” program.

Figure 2.4 shows how PAM solves the problem. Since application programs are written with generic PAM API, the system administrator can add Netware authentication to the “login” program without writing any code in the “login”. Instead, he adds one line in the PAM configuration table:

loginauthrequiredpam_netware.souse_first_pass

As shown in the example, PAM simplifies task of system administrators, application programmers, and users. PAM is now a part of Linux and Solarix-2.X operating systems, and widely used.

3Windows NT authentication scheme – GINA and its problems.

A component of Microsoft Windows NT operating system that is responsible for interactive logon is called Winlogon.exe. To allow software developers to modify the authentication system of Windows NT (e.g. to use new authentication mechanisms), some part of Winlogon is designed to be replaceable. The replaceable part is called Graphical Identification and Authentication DLL, or GINA [MS96].

3.1 GINA

GINA is a dynamic link library that is loaded by Winlogon, and is responsible for authenticating users. When authentication action is required (e.g. a user tries to logon, screen lock, a user logoff, etc.), Winlogon calls certain functions of GINA. In Windows NT, a user types SAS (Ctrl-Alt-Del keys combination) to indicate she wants to logon, logoff, or lock screen. Figure 3.1 shows some examples of GINA APIs called by Winlogon.

To explain how GINA works, Figure 3.2 shows interaction among a user, Winlogon.exe, and GINA.dll.

3.2 Problems with GINA

Since it is replaceable, GINA allows software developer to develop their own authentication mechanism.

Many GINA’s are written for various authentication mechanisms, e.g. University of Michigan Kerberos4-GINA (or GINA UM), Novell netware-GINA, etc. However, GINA still has some problems, which we address to solve.

Problem 1: GINA is not PAM

While GINA is replaceable from Winlogon, GINA does not have features of PAM. That is, authentication mechanisms are not replaceable in GINA. Figure 3.3 shows Microsoft GINA, which authenticates a user to Windows NT local security system. Figure 3.4 shows Kerberos4-GINA, which authenticates a user to Kerberos4, in addition to Windows NT local. Consider GINA as a UNIX application program “login” in Figure 2.3. GINA has the same problem we discussed about “login” in section 2, i.e. “login” depends on authentication mechanisms.

By implementing PAM in Windows NT, we can solve the problem. Figure 3.5 shows our view of GINA with PAM. We call the PAM in Windows NT as “NI_PAM”.

Problem 2: GINA is hard to develop

Compared with application programs in UNIX, such as login and telnet, GINA is harder to develop because it is heavily dependent of Windows NT operating system. First, the GINA developer has to reboot the workstation every time he wants to test his GINA. If the GINA does not work correctly, the workstation hangs up and cannot be restarted by usual methods. In addition, he needs a special way to use a debugger because GINA runs before he logon to the workstation. Generally speaking, developing GINA is very time consuming. We found that GINA with NI_PAM (we call the GINA as NI_GINA) is much easier to develop than GINA without NI_PAM because we can develop authentication mechanism specific code independently from GINA code.

Problem 3: Lack of cross-platform security administration method

The way the authentication system is configured in Windows NT is much different from in UNIX operating systems. GINA replacement is a usual way to change authentication policy in Windows NT, while PAM configuration table is popular in UNIX. This difference burdens system administrators because they have to be familiar with both administration methods to configure cross-platform security administration. By installing NI_PAM in Windows NT, system administrators can use the common configuration method in UNIX and Windows NT.

Our design of NI_PAM is described in detail in the following section.

4Design of NI_PAM

As we saw in the previous section, implementing PAM in Windows NT helps development and configuration of Windows NT authentication program. The following is our design policy of NI_PAM:

• NI_PAM employs the identical configuration table as PAM.

We believe the configuration table of PAM is powerful enough and easy to use for our purpose. Furthermore, the identical configuration table simplifies cross-platform security administration as described in Section 3.2.

• The configuration table is stored in the Windows NT registry.

Registry is the place we put configuration information in Windows NT.

• In addition to GINA, other application programs can call NI_PAM.

• NI_PAM assumes only one password for all authentication mechanisms.

We do not employ password mapping scheme in PAM. Instead, we are looking for a way to 1) use secure directory service to store keys that are encrypted by one password, or 2) store encrypted keys in a smartcard.

• Windows NT local authentication is not pluggable.

GINA is responsible for local authentication because we do not find a way to take the local authentication part out of GINA.

4.1 NI_PAM components

Our system consists of three components; NI_PAM, NI_GINA, and authentication mechanism specific modules. We describe these three here:

NI_PAM

NI_PAM.dll is a dynamic link library that implements our version of PAM in Windows NT. It is called by an application program (e.g. GINA). After receiving the call with a (username, realm, password) combination, NI_PAM reads the configuration table in registry, and calls appropriate functions of authentication specific modules with the combination. (In Windows NT, registry contains several configuration information for both operating system and application software, e.g. a version number of software, paths, name of a DLL called by the operating system, etc. It is appropriate to store security configuration information such as NI_PAM configuration table in registry.) It receives return value from each authentication specific module, and returns to the application if the authentication is succeeded.

For example, let us assume the configuration table is shown in Figure 4.1. When GINA calls a function ni_authenticate(username, realm, password), NI_PAM reads the configuration table, and knows it should call Kerberos-4 specific module, ni_krb4.dll, and Netware specific module, ni_nw.dll. NI_PAM calls ni_sm_authenticate(username, realm, password) of ni_krb4.dll and ni_nw.dll. Since a flag in the configuration table for ni_nw.dll is “optional”, NI_PAM returns NI_SUCCESS if ni_krb4.dll succeeds to authenticate the user.

NI_GINA

NI_GINA is a GINA used with NI_PAM. It calls NI_PAM functions in addition to do Windows NT local authentication. By replacing Microsoft GINA with NI_GINA, system administrators can integrate NI_PAM into their Windows NT computers. NI_GINA is called by Winlogon.

For example, Winlogon calls WlxLoggedOutSAS() of NI_GINA, indicating a user wants to logon. NI_GINA asks username, realm, and password to a user, and send the information to NI_PAM by calling ni_authenticate(username, realm, password). If NI_PAM returns NI_SUCCESS, NI_GINA does post-authentication work, and returns SUCCESS to Winlogon.

Authentication Mechanism Specific Module (AMSM)

Authentication Mechanism Specific Module, or AMSM implements mechanism specific authentication, for example AMSM for Kerberos-5 (ni_krb5.dll) calls krb5_get_in_tkt() to get an initial credential from Kerberos-5 KDC, AMSM for Netware-4.0 (ni_nw.dll) calls NWDSLogin(), etc.

Figure 4.2 shows the structure of the whole system.

4.2 NI_PAM APIs

DLLs in NI_PAM structure export the following functions.

NI_GINA.dllExports all functions defined in GINA [MS96].

NI_PAM.dllDefines data structure and exports functions in the following.

// Data Structure

typedef struct _ni_struct {

WCHARusername[StrLen];// user name

WCHARdomain[StrLen];// domain name

WCHARpassword[StrLen];// password

WCHARoldPassword[StrLen];// old password, for change pw.

WCHARnewPassword[StrLen];// new password, for change pw.

INTvalue;// used for smartcard.

} NISTRUCT;

// prototypes

BOOL WINAPI ni_start(HANDLE hWlx, PVOID pWinlogonFunctions);

// Start NI_PAM transaction, read configuration tables.

BOOL WINAPI ni_obtainpass(NISTRUCT *nistruct);

// Attempt to obtain username and password from smartcard AMSM.

BOOL WINAPI ni_authenticate(NISTRUCT *);

// Attempt authentication to AM’s, following the configuration tables.

BOOL WINAPI ni_logout();

// Logout from AM’s.

BOOL WINAPI ni_end();

// END NI_PAM transaction.

AMSMExports the following functions.

BOOL WINAPI ni_sm_authenticate(NISTRUCT *niStruct);

// Authenticate a user to an authentication mechanism.

BOOL WINAPI ni_sm_logout();

// Logout from an authentication mechanism; destroy credentials.

BOOL WINAPI ni_sm_obtainpass(NISTRUCT *nistruct);

// Returns username and password if this is smartcard AMSM. Else, it returns NULL.

4.3 NI_PAM interaction

To show how the whole system works, we follow the function calls taken place in user authentication. See Figure 4.2.

• User issues SAS. Winlogon receives SAS. Winlogon.exe calls WlxLoggedOffSAS() of NI_GINA.
• NI_GINA.dll receives WlxLoggedOffSAS(). It calls ni_start() of NI_PAM.
• NI_PAM.dll receives ni_start(). It initializes global valuables, and reads configuration table. (In this example, let us say the configuration table for authentication is as follows.) NI_PAM returns.

• NI_GINA demands (username, realm, password) from the user. Since no smartcard AMSM is listed in the configuration table, the user does not have an option to use a smartcard. She types the required information in.
• NI_GINA.dll calls ni_authenticate() of NI_PAM.
• NI_PAM.dll receives ni_authenticate(). It calls ni_sm_authenticate() of NI_KRB4.dll, NI_KRB5.dll, and NI_NW.dll.
• NI_KRB4.dll, NI_KRB5.dll, NI_NW.dll attempt to authenticate the user and get the initial credential. They return NI_SUCCESS if they succeed. Else they return NI_FAILURE.
• If NI_KRB4.dll and NI_KRB5.dll succeed, NI_PAM.dll returns NI_SUCCESS. Else it returns NI_FAILURE.
• If NI_PAM.dll returns NI_SUCCESS, NI_GINA.dll attempts to logon to local machine. If the attempt succeeds, NI_GINA returns SUCCESS to Winlogon, else authentication fails, and NI_GINA returns FAILURE to Winlogon.
• Winlogon receives the result from NI_GINA. If success, user can logon. If not, she is rejected.

5Conclusion.

Here we describe status of the project, discuss the result, state future directions, and conclude.

5.1NI_PAM status

The following is the current status of NI_PAM.

• NI_PAM.dll is implemented and tested. We have one bug not yet fixed, that is, it runs in Debug mode, but not in Release mode.
• NI_KRB4.dll and NI_NW.dll are implemented and tested. They support authentication and changing password.
• NI_KRB5.dll is implemented and tested. It supports authentication.
• NI_SC.dll (Smartcard AMSM) is implemented and tested. Currently, it stores password in clear text. It should store password in encrypted form in the near future.
• NI_GINA.dll is implemented and tested, but it needs more work to be used in public, e.g. password changing, screen lock, static account, etc.

5.2Result

Separation of NI_GINA and the other part (NI_PAM and AMSM’s) is pretty helpful for developing them because we can develop NI_PAM and AMSM’s independent from NI_GINA. Without NI_PAM, because of poor debugging facilities, GINA is the hardest part to develop. However, in our project, modification to NI_GINA is minimized; we added 10 – 20 lines of code to an already working GINA. We can use the powerful debugging tool of Windows NT to develop NI_PAM and AMSMs. Adding and modifying AMSMs in the future will be straightforward. Dynamic configuration of authentication system is as easy as in PAM because NI_PAM has the same configuration table as PAM. NI_PAM provides single sign-on to a user. With the smartcard module, a user does not have to type password even once. NI_PAM can be used in security application programs other than NI_GINA. Although we have not implemented any application program that uses NI_PAM but NI_GINA, we believe NI_PAM API is generic and rich enough to be used by several application programs.

5.3 Problems and Future Directions

Static Account

NI_PAM does not support static account and profile that are necessary for large computing environment like universities. Since there are many (1,000 – 100,000) users in such an environment, it is not desirable to keep all users’ account information in all Windows NT machines. One way to solve this problem is static account. A user is authenticated with static account (e.g. “guest”) to Windows NT operating system. A system keeps users’ account and profiles information in server machines, and protects the database with some authentication mechanism (e.g. kerberos-4). Upon logon to Windows NT computer, the user authenticates to the server, receives profile information from it, and uses the information in Windows NT. Static account is essential in large environments and we should address this problem.

Key Ring

Consistency in the password (or key) database is a hard problem. In the current NI_PAM, the password is stored in each authentication mechanism; e.g. Kerberos has its own password database. In this scheme, it is hard to keep consistency in passwords in AMs. When a user attempts password changing, some AMs can fail, although the others succeed. For example, a user wants to change password in both Kerberos and Netware. NI_PAM calls ni_chpass(old_password, new_password). After successfully changing Kerberos password, the system suffers temporal network failure, and Netware fails to change the user’s password entry. Now the system has inconsistent password databases (new password for Kerberos, but old password for Netware), and NI_PAM cannot guarantee single sign-on anymore. To use a single password for all AM’s has other problems.

• Security strength of the whole system is weakened to the strength of the weakest AM, because once a password is compromised in the weakest AM, the intruder has a password to all AMs.

• Requirements for passwords are different among AMs. For example, some AM may require a password length more than 8 letters, while another AM may require less than 8 letters.

NI_PAM should provide a way to have a different password for each AM, while it reserves single sign-on. One scheme to solve the problem is called Key Ring. In Key Ring, multiple passwords for a user are stored in a secure database, and the database is protected by an AM. The user has to type the password of the database. After authenticated to the AM guarding the database, a system can obtain all passwords for the other AM’s from the Key Ring. We may employ this approach.