LDAP Auth

The LDAP Auth plugin is maintained by Micah Cooper (coopermj@muohio.edu) of Miami University, Ohio. The latest version includes bug fixes, enchancements such as support for group schemas (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 of LDAPAuth: 1.5.2

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 changinghow values are 0stored. 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

he 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.