Using PGINA with LDAP

PGINA is an open-source extension to Windows that enables it to authenticate against a variety of external sources. PGINA has a plugin design, so people can provide plugins to connect it to a variety of information sources.

Plugins currently available include LDAP, Unix PAM, Slashdot accounts, MySQL, POP3, NIS, AFS, RADIUS, SecurID, and a Chaining plugin to allow for stacking any plugins. Additional plugins are planned.

Units at Rutgers are using PGINA to allow computers (particularly within labs) to authenticate with the Rutgers LDAP server. This is an easy way to let users login to your Windows systems using Rutgers NetID and password. The LDAP interface allows you to restrict the types of users who can login, based on attributes stored in the LDAP directory. You could for example accept only faculty/staff, only members of a specific department, or only people in a certain course. (Note however that there may be privacy issues with accessing certain information about people for this purpose.)

FAS setup

This section describes how the NB/P Faculty of Arts and Sciences are using PGINA to authenticate users. This is probably not their final setup, as they are looking to login both to the central LDAP server and to their own servers.

Please see Dave Motovidlak, motovidlak@admin.rutgers.edu, for more information.

This writeup is based on pGina v1.7.4 with ldapauth v1.4beta. See http://pgina.xpasystems.com for more information.

pGina has many, many options. All settings can be controlled via the registry - HKLM\software\pGina - or the configure.exe program. The ldap plugins settings are also available via the registry - HKLM\Software\pGina\ldapauth - or via the plugin_tester.exe program. Read the included pdf file for information about all the options.

Essentially, pGina lets you control access to 2000/XP machines by forcing users to first authenticate against a centralized account. Once successful authentication occurs, pGina will dynamically create a local Windows account for that user. pGina will then either delete the account and profile on logout or, if the "keepProfiles" option is set, will leave them there for subsequent use. On lab machines, it is recommended to set keepProfiles to 0, forcing each user to get a new profile upon each login. This will prevent the lab machines from getting "clogged" with old profiles. In addition, the chance of cracking a password will be greatly diminished since the users' credentials will not be left floating around on several machines. If keepProfiles is turned on, it is recommended that you enable pGina's "scramblepassword" and "forcelogin" features so that the password in the Windows database is scrambled and unscrambled on logout and login respectively. This will minimize exposure to attack even though the accounts are left on the local machine.

If keepProfiles is off (0), the main way for controlling the user's profile is by customizing the Default User profile. Each time a person logs on, the system will create a profile for them using Default User as a template.

Another notable option is the "Single User Logon" feature, which can force the local login to occur as some predetermined user -- e.g., a local labuser account. This might provide another means for controlling the profile each user gets: i.e., a local labuser account can be created and preconfigured. Users can then be logged into the labuser account after authenticating against ldap. In a lab setting, you'd probably want to take other measures to ensure that the profile remained pristine -- e.g., you'd set it up to use a "roaming" mandatory profile so that changes made to the profile are not persistent across login sessions.

At the time of this writing, the Single User Logon feature has a bug: if an account with no password is used, a blue screen occurs. In addition, all security auditing done on the local machine shows the generic account id (e.g., labuser) instead of the central account the user authenticated with at logon. Combined with the extra work of manually setting up a local account with the preconfigured profile and profile path property, this makes the SUL option less attractive than simply using keepProfiles=0 and a preconfigured Default User.

Running programs at logon

pGina has a registry entry called UserLoginScript. Currently this option doesn't seem to work. However, the ldap plugin has settings like these:

loginHook0
logoutHook0

These can be used to cause something to execute at login or logout. Theoretically, this can be anything the user has access to do -- e.g., map to some share or printer, write something to a log file (e.g., cmd /c time /T >> c:\temp\login.txt), automatically run a program.

Drive mappings

gGina offers a way (mapPaths option in registry) to automatically map drives. Of course, a supporting server is necessary.

Other options

You can enable or disable the Task Manager, Change Password, and Lock Workstation options in the Security screen (shown after pressing Ctrl-Alt-Del). Change Password actually changes the local account's password, not the centralized account's password. To avoid confusion, you should probably keep this off. In conjuction with the forcelogin and/or keepProfiles=0 options, the ability to change the local password is useless since it will never be used again (a new account and profile will either be created or the local password will be ignored as long as authentication against ldap occurs successfully).

Customized setup programs

Right now two customized setups exist: one to authenticate against ldap.rutgers.edu with netId and the other to authenticate against admin.rutgers.edu with FAS NDS id. The FAS package is currently configured to support accounts in these NDS contexts:

ou=users,ou=admin,o=fas
ou=users,ou=history,ou=cac-fas1,o=fas
ou=users,ou=econ,ou=cac-fas1,o=fas

Individual files: This contains all the files you'd need to re-roll your own packages with Inno Setup.
ldap.rutgers.edu. This is the package that configures pgina + ldap to login to ldap.rutgers.edu
Novell. This is the package that configures pgina + ldap to login to some of the FAS Novell contexts. This is probably not useful elsewhere, but it might be good for illustrative purposes.

To avoid confusion when installing the packages, the author recommends using the /silent switch -- e.g., pgina_rulink.exe /silent.

The setup routine, built with Inno Setup, can be customized to accomodate other contexts. Alternatively, the contexts can be modified post install by changing the appropriate entries in HKLM\software\pGina\ldapauth.

The main difference between the FAS and rulink packages is due primarily to the differences in the ldap structures. For instance, the rulink context structure looks like this:

ou=people,dc=rutgers,dc=edu

This will avoid prompting the installer with choices they might not understand. Account names are prefaced with uid=, so that user davemoto's DN looks like this:

uid=davemoto,ou=people,dc=rutgers,dc=edu

In contrast, DN in the FAS NDS system might look like this:

cn=davemoto,ou=users,ou=history,ou=fas-cac1,o=fas

The ldapauth authentication plugin requires a "prepend" string to know how to build the full DN. Because of the different naming conventions, there is no way to make settings for both FAS and rulink co-exist. Hence the different packages.

Both packages import the FAS and rulink root certificates to allow the use of SSL during authentication. SSL is the default option in both packages.

Ldap modes

The ldapauth plugin supports different modes for using ldap: search, map, multimap. The search option does not seem to work particularly well. Map is good when only a single context is necessary. Multimap If /silent is not used, the installer needs to make choices as they step through the process.works with one or more contexts. Both packages default to multimap.

Interaction with Novell client.

It is possible to make pGina work in conjuction with the Novell client without additional authentications under certain circumstances. Chances are that if pGina is necessary, it is because the users don't have NDS accounts -- e.g., because they're undergrads. If they did have NDS accounts and you wanted them to authenticate to NDS, you probably wouldn't need pGina -- you'd just use the Novell client with a DLU policy.

In this circumstance, if you wanted to have people authenticate with netID in order to use the machine but still wanted to use a Novell server for application delivery, you could point pGina to nwgina.dll instead of the default msgina.ll and then set up an NDS autologon to occur with a generic account -- e.g., labuser with no password. (A script for NDS autologon appears below.)

'Set up NDS autologon.
'Dave Motovidlak
'02/19/04
'See TID 10087621

'Number of reg entries.
intCount=9

Set objShl=CreateObject("WScript.Shell")

'Interactive:
If WScript.Arguments.Count=0 Then
	blnInteractive=True

	strUsername=InputBox("Username to login to NDS with:")
	If strUsername="" Then WScript.Quit

	strPassword=InputBox("Password:")
'	If strPassword="" Then WScript.Quit

	strContext=InputBox("NDS Context:")
	If strContext="" Then WScript.Quit

	strServer=InputBox("Default Server:")
	If strServer="" Then WScript.Quit

	strTree=InputBox("Tree:")
	If strTree="" Then WScript.Quit
Else
	If InStr(WScript.Arguments(0),"?")<>0 OR WScript.Arguments.Count<>5 Then
		WScript.Echo "Syntax:  " & WScript.ScriptName & "     "
		WScript.Quit
	End If

	strUsername=WScript.Arguments(0)
	strPassword=WScript.Arguments(1)
	strContext=WScript.Arguments(2)
	strServer=WScript.Arguments(3)
	strTree=WScript.Arguments(4)
End If


strRegPath1="HKEY_LOCAL_MACHINE\Software\Novell\Login\AutoAdminLogon"
strRegValu1="1"
strRegType1="REG_SZ"

strRegPath2="HKEY_LOCAL_MACHINE\Software\Novell\Login\DefaultLocationProfile"
strRegValu2="Default"
strRegType2="REG_SZ"

strRegPath3="HKEY_LOCAL_MACHINE\Software\Novell\Login\DefaultPassword"
strRegValu3=strPassword
strRegType3="REG_SZ"

strRegPath4="HKEY_LOCAL_MACHINE\Software\Novell\Login\AutoAdminQueryNDS"
strRegValu4="0"
strRegType4="REG_DWORD"

strRegPath5="HKEY_LOCAL_MACHINE\Software\NOVELL\Location Profiles\Services\{1E6CEEA1-FB73-11CF-BD76-00001B27DA23}\Default\UserName"
strRegValu5=strUsername
strRegType5="REG_SZ"

strRegPath6="HKEY_LOCAL_MACHINE\Software\NOVELL\Location Profiles\Services\{1E6CEEA1-FB73-11CF-BD76-00001B27DA23}\Default\Tab1\Context"
strRegValu6=strContext
strRegType6="REG_SZ"

strRegPath7="HKEY_LOCAL_MACHINE\Software\NOVELL\Location Profiles\Services\{1E6CEEA1-FB73-11CF-BD76-00001B27DA23}\Default\Tab1\Server"
strRegValu7=strServer
strRegType7="REG_SZ"

strRegPath8="HKEY_LOCAL_MACHINE\Software\NOVELL\Location Profiles\Services\{1E6CEEA1-FB73-11CF-BD76-00001B27DA23}\Default\Tab1\Tree"
strRegValu8=strTree
strRegType8="REG_SZ"

strRegPath9="HKEY_LOCAL_MACHINE\Software\NOVELL\Location Profiles\Services\{1E6CEEA1-FB73-11CF-BD76-00001B27DA23}\Default\Tab3\DefaultUserName"
strRegValu9=strUsername
strRegType9="REG_SZ"


For intX=1 to intCount
	strRegPath=Eval("strRegPath" & intX)
	strRegValu=Eval("strRegValu" & intX)
	strRegType=Eval("strRegType" & intX)

	'WScript.Echo strRegPath & "," & strRegValu & "," & strRegType
	objShl.RegWrite strRegPath,strRegValu,strRegType
Next

If blnInteractive=True Then WScript.Echo "Done!"

Set objShl=Nothing