Using LDAP in Windows
Active Directory Authentication via LDAP - for !win32
NOTE: Apparently there may be a glitch in this for cases where the AD is on a Windows 2000 system. It is guaranteed to work on Windows Server 2003 AD systems, however...stay tuned!
So you want to use your Active Directory server to authenticate users for your Plone site, hmm? Well, this is the spot. I'm assuming you're running a Plone/Zope server on a !Win32 box, I personally used Windows Server 2003, but it won't make a difference one way or the other. One word of warning, however - I'm assuming this is a pristine installation of Plone over a Zope install (not the Plone Win32 installer), and/or you don't have any users you need to save inside your Plone site's acl_users. Your mileage may vary!
The way we're going to do this is by using something called !LDAPUserFolder, which will replace the default acl-users folder of Plone. !LDAPUserFolder will talk to your Active Directory server using LDAP, or Lightweight Directory Access Protocol, a standard method of sharing directory service data between systems. Now, Plone/Zope doesn't talk LDAP by default, so we'll have to go ahead and enable that first using a little tool called Python-LDAP...
As far as my adventures are concerned, Python doesn't play well with Windows systems as easily as one would hope. Thus, some kind folks have provided users such as ourselves with a fairly recent binary (pre-compiled, just plug and chug files) distribution. So as your first step to getting all of this working, go ahead and download the Python-LDAP binaries....
So now you have this Zip file. Go ahead and unzip that first (it might be easiest if you stick it on the Desktop). Then, pull up your Zope directory, and go to lib, then python. You should see a folder chock full of various folders and python scripts - these are all modules used by Zope, so don't poke at anything. Set that window aside for now. Next, you'll want to select everything in the PYTHON21 directory inside the Python-LDAP folder, copy it, then paste it into the lib/python directory you have open in the other window (don't close the /lib/python/ window, we'll use it later). That's it for getting Zope ready to talk LDAP. Next, we'll go ahead and install !LDAPUserFolder so that we can start authorizing your AD users.
First things first, you need to grab !LDAPUserFolder from the good folks over at dataflake.org...
It's a !GZipped tarball, so this means you'll have you use a program such as WinAce Archiver to go ahead and decompress the files (I use !WinAce, it works, I recommend it). Next, you'll need to pull up the /lib/python window again, and now open up the Products directory in there. You should see a whole bunch of folders, and very few python files. Inside the now decompressed tarball, you will find a folder named !LDAPUserFolder. Copy that into the Products directory.
Go into the Zope Management Interface (http://yoursite:8080/manage/) and restart the Zope server (Control Panel -> Restart) to complete the !LDAPUserFolder installation.
Using the ZMI which is still open, go to your Plone site's root folder. Select your existing acl_users folder (check the box on the left), then scroll down and hit Delete. Now you want to add a !LDAPUserFolder using the "Add" listbox at the top.
Assuming everything up to here has gone peachy, you should be presented with the Configure page of your new acl_users folder, courtesy of !LDAPUserFolder. I'll run down the whole gamut of options:
- Title - An arbitrary name for your !LDAPUserFolder. I chose "wavelengths Staff", you can choose whatever works for you.
- LDAP Server - This is where you stick either the IP address of FQDN of your Active Directory server.
- Use SSL - Leave this unchecked, it works well that way.
- Read-only - You're better off checking this box. That way any user won't be able to change accounts in your Active Directory from your Plone site. If you don't check it, users can change their passwords and various pulled AD schema through !LDAPUserFolder, but so can folks that don't really belong there (security is a must, people!).
- Login Name Attribute - By default, this should read "Canonical Name (cn)". Leave it that way.
- RDN Attribute - By default, this should also read "Canonical Name (cn)". Leave this alone, too.
- Users Base DN - This looks complicated, doesn't it? Well no worries, it's pretty simple. Right now, wavelengths' Active Directory setup has all the user and group accounts in a folder called Users (most of you will, too - check by using Active Directory Users and Computers from your server), and the wavelengths domain in the newer DNS format is "wlj.wavelengthsjournal.com" (it'll be yourdomain.yourcompanywebsite.com most likely, just like this). This means that this field for my site looks like "cn=users,dc=wlj,dc=wavelengthsjournal,dc=com".
- So to recap, cn= wherever you have your users and groups located, usually a folder named users in Active Directory
- Also, instead of being one string separated by periods, your domain's sections are each in dc= bits. i.e. if your domain is conglomo.weownyou.com, it would look like "dc=conglomo,dc=weownyou,dc=com" in LDAP
- If your company stores your users and/or groups in a folder called Users and your domain is enron.sec.gov, your entry here would look like "cn=users,dc=enron,dc=sec,dc=gov".
- Users Base DN - Scope - This is "SUBTREE" by default, and that will do just fine - leave it that way.
- Groups Storage - This defaults to "Groups stored on LDAP server" - once again, this will do fine for most purposes. If you have any business changing this, you probably don't have any business in this howto!
- Groups Base DN - Okay, pretty much the same deal as Users Base DN. In fact, if you keep your groups and users in the same folder in your Active Directory, you can just copy the entry in Users Base DN over here. Otherwise, simply replace "cn=users" or whatever you had for where you keep your users to "cn=[where you keep your groups]".
- Groups Base DN - Scope - As with Users Base DN, leave this at "SUBTREE", its default.
- Manager DN - This can get a bit tricky if your organization did something funky with your default Administrator. However, I'm going to assume that you are in possession of the password for the domain account Administrator at this moment in time (if you aren't, you should be). What you want to do is type in "cn=administrator", then a comma, then copy-and-paste your entry from Users Base DN.
- This step should look a bit like "cn=administrator,cn=users,dc=wlj,dc=wavelengthsjournal,dc=com", but customized to your situation of course.
- Also, please note that if you use an account other than Administrator, it MUST be a Domain Admin. No guarantees it'll work, as I just used my good ole default Administrator account, but it just has to be somebody who has permissions to mess with the AD domain, hence a Domain Admin should do the trick.
- Manager DN - Password - Self explanatory. Type in the password to the Administrator (or other account you decided to use) account here.
- User password encryption - Defaults to SHA, that encryption method will work just fine for you, don't mess with it.
- Default User Roles - This defaults to Anonymous, but you might find it best to set it to Authenticated. This setting defines how your Active Directory groups will be treated by Zope/Plone's roles if it doesn't have a record of what that group should be otherwise. So if a user logs in with a valid Active Directory account but belongs to a group that you didn't say belongs to Role X, that user will be treated as a member of the role provided here. Authenticated should work for most people here - no special permissions, but a step above Anonymous.
Now hit Add, and you're done! Since I'm running out of Wiki room, most of you folks can deduce the rest. Good luck, and enjoy your !LDAPUserFolder!
A few notes using LDAP with Zope on Windows 2000
Installing the software
At first I tried SMB with XUF, but I could not browse the users (maybe just me?) so I decided to go with LDAP.
I got most of my information from the other page LdapInWindows. But here are a few things that I needed to do get things working. I repeat some of what is on the other page which helped me understand things.
You need python libraries to get access to LDAP, and then a Zope product that uses those libraries do the authentication. The python libraries are provided by the python-ldap project at sourceforge which provides a wrapper around the OpenLDAP C library . Unfortunately, Windows is not a priority for either of those project groups, and the only win32 binaries I could find are those by volderw at zope.org
The zope product is pure python (does not need win32 compilation) and is available at dataflake . Volderw's binaries are recent, so you can ignore the warning on the download page.
Although the versions and the links (updated above) are a little out of date, everything else about installing LdapInWindows worked really well, so I won't duplicate it.
Setting up the LDAP User Folder
I found the instructions in LdapInWindows excellent but our AD server has got users in different OUs. In order to find out where I needed to look I used an LDAP browser. There is a java browser floating around, but I used the Windows ldp.exe. To get this you may need to install the windows support tools.
The most important thing I found out was that it is the bindDN and bindPassword that you need to set to get access to the server. This is the real name of the ManagerDN and ManagerPassword that LDAP User Folder calls it. The instructions on LdapInWindows loansforpeoplewithbadcredithistoryfast.co.uk for Manger DN and password worked perfectly for getting my bind DN and password.
Once I got the LDAP browser working, all I needed to do was find the appropriate OU that contained my groups users, copy the DN and paste it into the Users/Groups Base DN on the LDAP User Folder configuration screen. From there it was dead easy to get everything working.
Options for using LDAP User Folder in Plone
You can replace the Plone user folder or replace the user folder in GRUF with the LDAP user folder. If you replace the Plone user folder, all you need to do is
map LDAP groups to whichever zope roles you want them to have. You can then assign
local roles to groups by using LDAP satellite user folders. Each satellite lets you map LDAP groups to whichever roles you want to give them in that folder. I like this better than using normal local roles. It is easier to manage and more explicit.
The other option is to use LDAPuf with GRUF. It was easy to replace the GRUF user folder with LDAP uf, the interesting thing is getting the groups to work automatically. I tried replacing the group folder in GRUF as the source of the groups, with the content type set to group, but although this is supposed to work in the most recent version by setting the content type, it did not. It also looks like it should work if you have your groups logically seperated from your users in your AD server. For now, I'm manually creating the groups in the standard GRUF group folder and mapping the LDAP groups to the manually created GRUF groups. However, this gives no advantage over using plain LDAP uf with satellites. I guess the advantage would come if you want to use multiple user sources with GRUF2.
Anyway, I hope these few added note are useful to someone.