Setting up Plone 3 to Authenticate Using Active Directory

Purpose

I've found it very difficult to get current documentation on using current versions of Active Directory and Plone (3.1.4 at the time of this writing) to work well together. This is a short tutorial that aims to remedy that. There is a product out there called simplon.plone.ldap that makes a good attempt at providing a good way to configure LDAP and Active Directory for the masses, but it simply does not work correctly for Active Directory. DO NOT USE IT.

Prerequisities

1. A Plone Site
2. python-ldap
   • apt-get install python-ldap, yum install python-ldap, or your system's equivalent if using your system python
   • If you are using a separate python install to run your Zope/Plone instance, use the associated easy_install, for example: /opt/Plone-[version]/Python-2.4/bin/easy_install python-ldap
   • You should be able to type the following in your console: python2.4 -c "import ldap" and not get an error for whichever python you are using to run your Zope/Plone site
     
3. A user account on that has permission to bind to your Active Directory (more on this later)

Step by step

Stuff to Download

NOTE: At the time of this writing, you will get version 1.1 with buildout, and 1.0 with the bundle available on the Plone.org products page.

If you are not running buildout, use the bundle from the PloneLDAP product page.

If you are running your plone site with buildout, add Products.PloneLDAP to the eggs portion of your [buildout] section. Your buildout.cfg will have something like the following:

[buildout]
... snip ...
eggs =
   elementtree
   Products.PloneLDAP

acl_users, and plugins and the ZMI (oh my!)

So now you have a Plone site with your products properly installed. You don't need to do anything with the Add/Remove Products control panel in the Plone Site Setup interface. In fact, you shouldn't see any additional products listed there. Instead, head for the ZMI. And inside the ZMI, acl_users:

This all may seem a bit daunting at first, but there's less to think about than at first glance as the authors of PloneLDAP have some pretty intelligent defaults built in.

ID

Put anything you want here, skip out on spaces just to be nice

Title

Again, put whatever you want here.

LDAP Server[:port]

This is when stuff starts getting tricky. This is NOT the Active Directory domain name, it is instead the name of one of your domain controllers. Port is only needed if you've changed the default (likely not)

Use SSL

The default for this will work, but it simply means that communication between your web server and domain controller will not be encrypted. If they are on the same network (in your office for example) then you aren't worried about this. If your web server and domain controller talk over the internet, SSL is a MUST HAVE. Please read the available documentation for your server.

Read Only

I always use this setting. This makes it so Plone never attempts to write information back to your Active Directory server, so you maintain control over your user information.

Login Name Attribute

Leave this alone. sAMAccountName is the setting you want.

User ID Attribute

Leave this alone. sAMAccountName is the setting you want.

RDN

Leave this alone. You only have one option anyway. 

Users Base DN

This is where things get fun. Depending on your Active Directory setup this can be short and sweet or long and maddening. The basics will be the path to your FQDN of your Active Directory domain. Likely in the following form: cn=Users,dc=mydomain,dc=mycompany,dc=com.

Scope - Users Base DN

The scope is how Plone will search in the "Base" for users. Subtree will search starting at the "Base" and any folders contained within, recursively. Onelevel will search in the "Base", and up to one container in depth. Base will search within the "Base" as defined and will not find any user objects inside any containers defined there.

Group storage

Do you want to get groups (and group memberships from your Active Directory? I usually don't because there's a TON of groups that can confuse users in there. On the other hand, if the content contributors, editors and reviewers are used to wading through lots of AD Groups to share things, this may be quite useful. If you have the Read Only attribute set (mentioned above), you will NOT be able to manage groups within Plone, but instead they will need to be managed through the AD users & groups interface.

Groups Base DN

Essentially the same as the "Users Base DN" but it will look for groups instead of users.

Scope - Group Storage

Same as Scope - Users Base DN.

Manager DN

This is the account that Plone will use to connect (bind) to your Domain Controller(s). It can be in the form of a DN path to your user, or can simply be MYDOMAIN\my_ldap_user. I find the latter to be easier to read. Note: You might need to use an account with more rights than a normal account on your domain depending on your current security policy.

Password

The password for the Manager DN account.

User Password encryption

What method of encryption should user logins be encrypted with before being sent to the Domain Controller. SHA is supported and fairly secure; you shouldn't need to modify this.

Default User Roles

When people log in to your Plone site using their domain account, what roles in Plone should they receive. I usually set this to just "Member".

Plugin Settings

) through Plone. I personally view this as a security hole as well as the fact that our Active Directory setup doesn't reflect how we want to manage our web site.

Further information

If there is anywhere else the reader can go for more information on this topic, include some links or pointers here.