From pGina

About

The LDAP Auth plugin is maintained by Micah Cooper (coopermj@muohio.edu) of Miami University, Ohio. The latest version includes bug fixes, enhancements such as support for group schema (ldapGroupAttr) and alternate network ports (ldapPort). Odd numbered releases (1.5.x for example) will have a gui configuration tool is behind a bit, it is perfectly good for standard configuration, but some of the new and advanced features require registry editing - see the Readme.txt included in the install for more details.

  Latest Version (x86): 1.5.3
  Latest Version (x64): 1.5.3

     Configuration GUI: Yes
Includes Documentation: Yes

            Written By: Micah Cooper

Prerequisites

Coming Soon.

Download

Latest version of LDAPAuth: 1.5.3

Latest Activity

Micah Cooper has been hard at work on the LDAPAuth plugin and version 1.5 has been released! Lots of new features and fixes are included, so download today!

Included with this release:

* Search filters with up to 5 %s’s to be filled with the username
* Files libdes.dll and mkntpwd.dll no longer have to be in your 
  system32 dir, but registry entries should point to their location
* Included installer so that 1.4 is not required, also updates 1.4 
  installations at the end of the install
* Updated Readme text with full registry changes
* Numeric values now set as DWORDs in registry — REQUIRES changing 
  how values are stored. I recommend just deleting 
  HKLM\software\pgina\ldapauth and starting fresh
* Login and Admin authoriation now available as filters (registry 
  tweaking required)
* Rewrite of some functions (causing homeAutomount crash, unfortunately)
* Better registry calls allowing for greater values (not that anyone 
  needed larger values)
* Completely LDAP v3 (and will probably not work with LDAP v2 — let me 
  know if this causes a problem)
* Default minimum password length is 6 (instead of 8 in the previous 
  version), but can be changed
* ldapWriteServer so that password changes go to a different LDAP server 
  than the one used for login
* locally crypting passwords (DES) to be stored in OpenLDAP
* Setting hashes in the directory for use with Samba
* Code to retrieve a home directory already in UNC format
* Code to retrieve driveLetter from LDAP if not set in the registry
* Many little code improvements here and there
* ldapAdmin username and password values encrypted in the registry

Note that when installing 1.5.2 you must reconfigure your admin username and password should you use these values - as the latest code expects the values to be encrypted

Our continued thanks to Micah for his hard work and dedication! and to Marc Fortier for helping help with coding.

FAQ

The following is a FAQ relating to the LDAP Auth pGina plugin as provided by Micah Cooper:

What is ldapauth?

ldapauth is an LDAP authentication plugin for pGina. For more information about pgina, please check out http://pgina.cs.plu.edu. Although pGina may support Windows NT, ldapauth requires functionality in Windows 2000 and Windows XP and is incompatible with Windows NT. In fact, some APIs used seem to only work best with Windows 2000 sp1 or later.

What version of LDAP does ldapauth support?

ldapauth supports LDAP v3, but may be able to work with LDAP v2 servers if SSL is not required.

How do I use it?

Copy the ldapauth.dll into \plugins and configure pgina for this plugin. Then fill out the registry settings listed later.

Why doesnt the GUI configurator work?

Time, time, time and more time. It’s on the TODO.

Does ldapauth support SSL?

Yes, it relies upon the SSL functionality of the underlying operating system, however, which can be tricky to configure. More information in later in the faq.

How do I get started?

Open regedit and go to HKeyLocalMachine\Software\pGina\ and create a new key ldapauth. Create the following string values (I put examples after them, but you will want to replace these with what is appropriate for your site).

• ldapServer ldap.muohio.edu
• ldapPrePend cn=
• ldapMethod 1
• ldapContext0 ou=users,o=mu

If you are unsure of values and have access to a UNIX box with ldapsearch, type the following (replacing the ldap server with yours and bob as your login id):

• ldapsearch -h ldap.muohio.edu uid=bob dn

This should return you a string such as the following:

• cn=bob,ou=users,o=mu

Put whatever is before bob as the ldapPrePend and whatever is after bob as the ldapContext0. Add additional ldapContextx (incrementing x) as needed. There is currently a limit of 255 contexts through which this will iterate – after that (or before), you should be doing ldap searching

What are all the registry configuration settings?

• ldapPort (optional) By default, uses 389 for plain and 636 for SSL, but putting a value in here overrides what TCP port is used for LDAP.
• ldapGroupAttr(optional, advanced and untested) By default, this is groupMembership. This is the attribute on the user that determines the groups to which the user is a member.
• ldapMethod 1 = Multimap, 2 = search, 3 = map
• useSSL pGina attempts to do everything through SSL, but you must have the OS configured before this will work.
• ldapPrePend For map and multimap, what it puts before the username
• ldapAppend For map, what goes after the username
• ldapContext0-255 For multimap, all the different contexts to try
• ldapAdminUsername (optional) A user with read/scan rights to the directory if you do not allow anonymous binds. If left blank, anonymous bind is attempted.
• ldapAdminPassword (optional) Password for ldapAdminUsername. If left blank, you will get an anonymous bind.
• userOK0-255 (optional) LDAP Group(s) in which user must exist to be successfully authenticated. If left blank (or set to all), all may use the workstation.
• adminOK0-255 (optional) LDAP Group(s) in which if user is a member, is placed in Administrators group on workstation. If set to blank, no one is created as an administrator.
• ldapFilter (optional, advanced and untested) By default, the filter used in LDAP queries is (uid=%s) where %s is the username entered in the GINA. You could change this to something fancier such as (&(uid=%s)(class=inetOrgPerson)) if you really wanted to or if your LDAP server did not support uid.

When do I use which mode?

If you only have one context to search, map is the most efficient. If you have multiple contexts to search, you can use search or multimap. Multimap gives you more control and may be faster, depending on whether a search or multiple bind attempts is faster on your server. Search is the “most LDAP” way of doing things as it does a search for the UID and then attempts to bind as the first result.

What if an LDAP search would return more than one result for a given username?

You have a faulty directory implementation. ;) Seriously, if you have more than one result for an attribute called UNIQUE ID, then you should figure out what would make a user unique (not unique = special like your mamma called you, but unique). Alternatively, use multimap. It will bind in the order of contexts.

Do I need a custom schema?

I hope not, but that depends on if you already have a custom schema (it seems when people deviate from the norm, they call the norm custom). I’ve tried to write the plugin as flexible as possible, but if there is a purer way of doing this, please let me know (or recode it and submit your mods or volunteer to take over the project). If you do searching, uid (indicating a unique, alphanumeric username, not a Unix number) is required unless you change the filter. For the binds, it literally attempts a bind with username, so bracket the username with whatever you call these attributes. For userOK and adminOK, the user class must support the attribute groupMembership as the user will be queried, not the group. If your users have full control over their own attributes, this is not secure. If your directory does not implement this, and instead requires querying the group, support for that is not yet written (and may never be as it is somewhat silly).

How do I configure SSL on my workstation?

• set useSSL to 1
• If your certificate is signed by a CA already acknowledged by your workstation, you should be fine at this point. If you are unsure, testing instructions are below. If you rolled your own certificate because it’s cheaper or your LDAP administrator doesn’t know how to buy a Verisign cert, please keep following these instructions.
• Obtain the public key certificate from your LDAP administrator. If he is unaware of how to obtain this, let his management know and repeat. This process varies by implementation and product. Ideally, he created a webpage with it.
• As a workstation administrator, double click on the certificate file.
• Select Next, but stay focused.
• DO NOT select Automatically select the certificate store; select “Place all certificates in the following store”
• Click on Browse.
• Check the “Show physical stores” checkbox.
• Expand “Trusted Root Certification Authorities” and then highlight “Local Computer”.
• Then hit OK.
• How do I know if my LDAP server’s SSL certificate is correctly recognized on my computer? —
• First, since the GINA runs in a different user context than you, even if you’re logged in as administrator, you must become “system” to test things out. Instructions for becoming system and doing the test are below, but to test LDAP from the client, install ldp from the Windows 2000 CD (it’s under \support\tools — run the install and be sure to install the “Active Directory” components. This will install ldap under \program files\support tools).

• Launch cmd.
• At the cmd prompt type the following where xx:xx is 1 minute from your current system time: “at xx:xx /interactive cmd”.
• Wait 1 minute. ;)
• cmd should pop up in a new session. This one is running as System.
• Change directories to c:\program files\support tools\ and launch ldp.
• Connection -> connect
• Server: , Port: 636, and then hit OK
• If it fails to connect, try again on port 389. If that works, but 636 does not, you have a certificate problem.
• If it succeeds, go ahead and testing binding by Connection->Bind
• Click the Advanced button and set the radio button to Generic instead of Simple (OK)
• User: cn=username,ou=..; Password: your password; UNCHECK DOMAIN (OK)
• If you connect and bind, everything should work.
• Using LDP failes to my directory server. What should I do?
• LDP is essentially a wrapper for the Microsoft Windows LDAP client calls. If it fails, so will pGina, and perhaps many other things. You need to work with your LDAP directory administrator and/or vendor to figure out what’s going wrong.

Whom should I sue if this causes widespread problems?

Neither pGina nor ldapauth are provided with any warranty, express or implied. Your use of it (and all open source software) carries the same risk and responsibility as if you had written and implemented the code entirely on your own. In other words, you are given the fruits of someone else’s labor for free, provided with everything you need to use and extend it, and even benefit from it and receive recognition and promotion or promote your organization’s core processes. If it doesn’t work out for you, you should not attempt or even consider harming those who have so willingly given to you.