Plone 2.5 and OpenLDAP Integration for Users and Groups

How to have your Plone 2.5 site read from and write to your OpenLDAP Directory for users and groups on a Linux server

  • Install Zope 2.x.x (I used 2.9.3) and Plone 2.5 and create an instance of zope for yourself (this varies from distribution to distribution and other documents cover this in detail).
  • Install the products in the PloneLDAP bundle in your Zope instance. This will add the LDAPUserFolder, LDAPMultiPlugins and PloneLDAP products.
  • Start your zope instance and then, using the ZMI, add a plone instance (see other docs for details)
  • Restart your zope instance so that the new products will be available in the ZMI (varies from distribution to distribution; see other docs for this)
  • Navigate in the ZMI to the root of your Plone instance, then to the acl_users folder contained therein, and add an LDAP Multi Plugin to that folder.  You're presented with a form entitled: Add Plone LDAP Plugin to the PluggabbleAuthService."
  • Fill out the fields carefully: The first five (ID, Title, LDAP Server[:port], Use SSL, Read-only) should be self-explanatory---see plone docs for the first two and LDAP docs for the rest if they are not).  Note that you should consider security here.  Either use SSL or make sure it is a trusted network over which your data is traveling.  Most people would not want the contents of their Directory (especially if they contain lots of user credentials) traveling unencrypted over an untrusted network.
  • The next three fields are Login Name Attribute, User ID Attribute, and RDN Attribute.  What you choose for each of these will depend on your LDAP DIT that you're connecting this plone instance to and also the method of logging in to your plone instance that you've chosen for yourself.  My DIT looks generally as follows:
o=example.com
    ou=people
        uid=user1
        uid=user2
    ou=groups
        cn=group1
        cn=group2
  • from which, you might be able to deduce (accurately) that my user dn's in the DIT look like this: uid=username,ou=people,o=example.com
  • I wanted my users to login to plone as they login to other applications in the organization that authenticate against my Directory (that is to say, with the same credentials: username and password), and the uid attribute is what I use for the username in all these other applications, so I chose uid for the first of these three fields: Login Name Attribute.  I'm not absolutely certain that is how plone uses that field, but I'm pretty sure that's right.
  • I'm less sure about how plone uses the second of these three fields: User ID Attribute.  Given my circumstances, it only made sense to choose uid for that field also.
  • The third of these three fields is RDN Attribute, and I'm quite certain that I do understand how plone uses that field.  When adding a new user via the ZMI (the Users tab of the object we're considering now), whatever you choose here will be used by plone (concatenation-style) along with the next field (Users Base DN) to form the dn of the added user in the Directory.  For more details, read up on the Relative Distinguished Name concept of LDAP.  So again, given my circumstances and the form of my dn's, I chose uid here.  So I chose uid for all three of these fields, but your situation may differ from mine.
  • For the next field, Users Base DN, choose the node of your DIT where all your users are attached, and it should be listed in dn-type format.  For my circumstances, I filled this field with: ou=people,o=example.com
  • For the next field, Group Storage, I chose "Groups stored on LDAP server"
  • For the next field, Groups Base DN, choose the node of your DIT where all your groups are attached.  Note that your groups stored here must be of LDAP objectclass groupOfUniqueNames.  If you're new to LDAP and DIT-design, I recommend the following document to gain some familiarity with DIT-design and groups in particular: ldap-recipe.  Make sure you also follow and read the (very long but worthwhile) link that author refers you to when he writes: "STOP! Before you go on to read about Groups..." For my circumstances, I filled this field with: ou=groups,o=example.com
  • I left the Scopes fields at the default of SUBTREE.
  • The remaining four fields should be self-explanatory (make sure your Manager DN has the necessary privileges on the OpenLDAP server: read/write access to those portions of your Directory that will be linked with plone), so fill them out correctly and click the "Add" button.
  • Navigate to that new plugin by clicking on its ID as you named it above, then click on its Contents tab
  • Click on the acl_users folder contained therein.
  • Now your "ZMI path" (as I call it) at the top of the lower right frame of your ZMI should read: "LDAPUserFolder at /plone-ID/acl_users/pluginID/acl_users and the Configure tab should be selected (or on top).  Most of the configuration fields of this LDAPUserFolder are pulled from the configuration of your LDAP Multi Plugin that you configured above, but there are some new ones: Group mapping (Applies to LDAP group storage only), Manager DN Usage, User object classes.  Configure your LDAPUserFolder instance by filling out these additional fields (details below).
  • For the field entitled, Group mapping (Applies to LDAP group storage only), I chose "Manually map LDAP groups to Zope roles"
  • For the next new field, Manager DN Usage, I chose "Always."
  • The next new field (User object classes) is subtle, but very important.  You should fill it with all of the LDAP objectclasses that you will use in plone and that make up your user objects in your Directory.  That probably means you should fill it with all of the objectclasses that make up your user objects in your Directory.  Separate the entries by commas as is done with the default entry.
  • Click the "Apply Changes" button.
  • Click the LDAP Schema tab to bring it to the top.
  • There is an important relationship between this tab of this object and the Properties tab of the PlonePAS MemberData Tool at ZMI path /ploneID/portal_memberdata.  The default fields of the latter include the following properties (among others): email and fullname.  These property names are the targets of the "Map to Name (optional)" field of the LDAP Schema tab you're looking at now.  The LDAP Schema tab of your current ZMI path of LDAPUserFolder at /ploneID/acl_users/pluginID/acl_users has a four-column-table of (by default) three rows and these rows contain (by default) the LDAP Attribute Names of cn, sn, and uid with Friendly Names of Canonical Name, Last Name, and uid with no Mapped to Names and No for the Multi-valued column.
  • In order for plone to be properly connected to your LDAP Directory, you'll have to make some changes here.  Exactly what changes will depend on your circumstances, but I deleted cn from the table and added it again (using this tab), this time using the "Map to Name (optional)" field to map the LDAP attribute "cn" to the portal_memberdata property name "fullname".  I also added a new LDAP Attribute Name ("mail") to the table, using the "Map to Name (optional)" field to map it to the portal_memberdata property name "email".  Plone needs at least these two mappings in order to give you the most basic functionality that you're probably looking for.  Without these mappings, the User and Groups Administration page of the Plone Site Setup will see only uid and won't see the user's full name or his/her email address from the Directory, for which there are fields in Plone's User and Groups Administration page that you probably want filled with the content of those attributes from the Directory.
  • Additionally, depending on what LDAP objectclasses your DIT contains for the user object, you may need to add additional LDAP Attribute Names here (not necessarily mapping them to any portal_memberdata property names).  Specifically, if you wish to be able to add users to your Directory using the ZMI, then you will need to have an entry in this table for all of the required attributes called for by your user objects (which is determined by what objectclasses are used in making up your user objects).  For example, my user objects are made up of the following objectclasses: organizationalPerson, inetOrgPerson, krb5Principal, krb5KDCEntry, posixAccount, CourierMailAccount.  These objectclasses have the following required attributes (maybe some others too): cn, sn, krb5KeyVersionNumber, krb5PrincipalName, uidNumber, homeDirectory, gidNumber.  So I added all these LDAP Attribute Names to the table of the LDAP Schema tab (not all of them mapped to a property in portal_memberdata).
  • You may also want to add new property names (name them as you wish) in the portal_memberdata tool, and then add new (non-required) LDAP Attribute Names (homePhone, telephoneNumber, etc.) to your LDAP Schema using this tab, and mapping the LDAP Attribute Names to the names that you added to the portal_memberdata tool.  For example, I added the property names, "homephone" and "extension" to the portal_memberdata tool and then added LDAP Attribute Names, homePhone and telephoneNumber to the table, mapping them to the property names in doing so.
  • At the moment, plone apparently has no way of displaying any LDAP attributes beyond cn and mail (which are accessed as fullname and email in the portal_memberdata tool), but maybe soon that will change.
  • After configuring your LDAP Schema as desired, click on the Users tab and search for a user in your Directory.
  • Then click on the Groups tab and see if your Directory's groups are there.  They should be.
  • Some good tests to try in order to determine if all the linked functionality between Zope/Plone and your LDAP Directory that you want is actually present are as follows:
  1. try adding a user to your Directory from the Users tab of the LDAPUserFolder at ZMI path /ploneID/acl_users/pluginID/acl_users --- make sure that the user shows up in the DIT at the node you want.  If he doesn't, then your RDN or Users Base (or both) configurations are probably wrong;
  2. try deleting a user from your Directory using this tab;
  3. try adding a group to your Directory from the Groups tab of the LDAPUserFolder at ZMI path /ploneID/acl_users/pluginID/acl_users --- make sure that the groups shows up in the DIT at the node you want.  If not, then check your Groups Base configuration setting.
  4. try deleting a group from your Directory using this tab.
  • If those work, then you've probably got everything working as desired, and now two final steps:
  1. activating the plugins to work with plone itself (so far, everything we've done here has been in the ZMI).  For this, navigate to the /ploneID/acl_users/pluginID ZMI path.  The Activate tab should be on top, and you should put a check-mark in all of the boxes for which you want functionality in Plone.  I checked them all for my circumstances.
  2. adjusting the order in which acl_users plugins are referenced: for this, navigate in the ZMI to /ploneID/acl_users/plugins.  I don't know exactly which plugins are important to adjust here and which don't need to be adjusted, but I do know that you'll need to adjust at least one (maybe several) of the plugins of this Plugin Registry such that your LDAPMP is first in the list of plugins (whereas the default is to have source_users as the first in the list of plugins).  For my circumstances, I just clicked on all of the plugin types here and for any that showed my LDAPMP as available in the list of active plugins, I moved it to the top of the list.
  • I hope this helps some people.  Thanks very kindly to Wichert Akkerman (without whose help I could not have done this myself) and to all the developers of the Zope/Plone community for making Zope and Plone and all the other neat stuff that goes with them.
  • If you don't have everything working as desired, check Gmane for the thread on plone.user called "Plone 2.5 and LDAP" for more detail before posting to the list.  That thread has (I'm told) more than 50 posts in it, so there's alot of questions and answers contained therein that you should read before you ask a new one yourself.

Thank you very much

Posted by Florian Friesdorf at Jul 15, 2006 12:36 AM
It works! You saved me a lot of work! :)

Personal Preferences not showing Directory details

Posted by Josh Metcalfe at Jul 21, 2006 04:59 PM
Is your Personal Preference page not showing details from your Directory (even though it seems to be working elsewhere)?

Go to the acl_users/plugins

Select the "Properties Plugins"

Make your LDAPMultiPlugins top on the Active Plugins list.

NOTE: Only mappings that you created via the LDAP Schema tab for your plugin will be displayed. "Mapped to Name" options like: "fullname", "email", "location", etc. See ploneid/portal_memberdata Properties tab for the names of all of the mapping options.

Re: Personal Preferences not showing Directory details

Posted by Kevin at Jul 22, 2006 03:34 PM
I'll reply by asking a question (or several) of you:

Is your Personal Preference page not showing details from your Directory (even though it seems to be working elsewhere)?

I'm not mocking you, just making sure I understand your question because if I do, then I think it needs some more specificity to be answered. I'll make an assumption though, and maybe that will help you in spite of the lack of detail in your question.

If your answer to the above is, "Yes, my Personal Preference page is not showing details from my Directory."... then I'll respond by asking, which details are not showing? Although I may be mistaken, I believe that details beyond fullname and email (from the Properties tab from ploneid/portal_memberdata) are not implemented in Plone/LDAPMultiPlugins/LDAPUserFolder/elsewhere, so even if you've done the mapping described above, you won't get details showing up in plone beyond the fullname and email properties. I suspect that's true even for the Location field (third field down on the Personal Preferences page) even if you mapped physicalDeliveryOfficeName or roomNumber or some other Directory object attribute to a 'location' property (I'm only guessing that such a property, with that or another name, is used in plone). I think that more code needs to be written to get that kind of functionality. Care to take on that project? :)

If my assumption was wrong, and you asked and answered your own question, then I'm not even sure that you were looking for a reply, but if so, then why post?

Anyway... HTH.

Helping others with the same problem

Posted by Josh Metcalfe at Jul 24, 2006 04:01 PM
The question is posed to others having the same problem. You'll note that I posted the solution of how to fix the problem. The "location" works fine for me.

I was having this problem and didn't find this particular issue answered. It was also asked on the mailing list. I posted it so that others my find the solution faster than it took me to find it.

Enabling custom member data from LDAP in plone

Posted by Enrique Pablo Perez Arnaud at Oct 26, 2006 11:53 PM
If when you say "details from your Directory" you restrict yourself to LDAP attributes that you map to portal_memberdata properties present in the plone member preferences form, yes you can see them in plone. If you want to map LDAP attributes to custom member data, you won't get them in plone unless you go a little further.

The way to see -and edit- them through plone is no too complicated. It has consisted for me of three steps.

First step is to enable custom member data in plone's member data edit form (preferences form), and consists in customizing CMFPlone/skins/plone_prefs/personalize_form.pt. There seems to be a personalize_form.pt in LDAPUserFolder/skins/cmfldap, but it isn't installed by default and didn't work for me when manually installed, and I had already customized the one in plone_prefs when I saw it. To the one in plone_prefs, I simply added more fields, with my custom member data (calling it by the name set in portal_memberdata properties).

Second and third steps are to enable the custom member data in plone's member data view.
The second is to make a custom MembershipTool, in order to override the getMemberInfo method. I whent about it as explained in http://plone.org/[…]/custom-type-member-folder, though I extended from the MembershipTool in CMFPlone. In getMemberInfo, I simply copied the body of the method in CMFPlone.MembershipTool, and added my custom portal_memberdata properties to the memberinfo dictionary.

The third and last step is to customize author.pt in CMFPlone/skins/plone_content. Again, it is a simple matter of adding your custom member data to the template, in the exact same way as the default member data is laid out.

(There is a LDAPMembershipTool in LDAPUserFolder, but doesn't seem to be used, and extends CMFDefault.MembershipTool. I may be wrong, and it's too late to test it, but I think it should inherit from CMFPlone.MembershipTool, override getMemberInfo, and iterate over portal_memberdata properties. Same for author.pt and personalize_form.pt.)

Re: Enabling custom member data from LDAP in plone

Posted by Enrique Pablo Perez Arnaud at Oct 27, 2006 12:39 AM
Well I guess LDAPUserFolder doesn't want to depend on Plone. But the idea doesn't depend on ldap, it could just sit on top of plone as a product with a MembershipTool, an author.pt and a personalize_form.pt.

Re: Personal Preferences not showing Directory details

Posted by Olivier Nicole at Aug 28, 2006 10:33 AM
It is possibleto map some other properties, for example I am mapping Plone user home page with LDAP labeledURI for example.

What I find tricky is to guess the names of the properties used by Plone: for example I had to map home_page with labeledURI.

Eventually I am interested into mapping Plone picture with LDAP jpegPhoto, but once again how the picture is called inside Plone.

LDAP Patch bug

Posted by Kevin Kalupson at Aug 03, 2006 05:04 PM
I have errors when I apply the patch as described above.
http://www.zope.org/[…]/collector_issue_contents is a bug report that was filed which identifies my problem.
Has any progress been made with this bug that anyone knows of?
There seems to be some issue as to wether the bug is a PAS bug or not, according to the comments on the bug report.

RAMCache for LDAP

Posted by Troy Davis at Aug 15, 2006 07:29 PM
This info was originally posted by KurtB to http://paste.plone.org/10224

It details what's involved in setting up a RAMCache for your LDAP lookups. This greatly improves load times on sites that use LDAP for user login.

---

LDAP optimization ZMI Changes
=============================

 * Enable RAMCache for LDAPMP

 * Enable RAMCache for acl_users

 * Enable RAMCache for source_groups

'source_groups' doesn't have a 'Cache' tab like the LDAPMP plugin, even though it is 'RAMCacheable', so this part is a bit tricky.

Navigate to 'source_groups' in the ZMI. Right click on the 'Groups' tab and copy the url to the clipboard using your browser operation for this.
   
It should look something like '.../acl_users/source_groups/manage_groups'. Click on the address bar of your browser and paste the url.

Replace the last segment of the URL ('manage_groups') with 'ZCacheable_manage' and Press ENTER. Proceed as usual.

LDAPMultiPligin ver 1.3

Posted by Olivier Nicole at Aug 28, 2006 10:35 AM
Thanks, it saved my day.

It works well with LDAPUserFolder 2.7 and LDAPMultiPlugin 1.3.

No need to apply the patch.

If you plan to go SSL/TLS to access LDAP, you have to use revision 1361 (date Aug 27th) of LDAPMultiPlugin.

Mac OS X Server / Open Directory Integration

Posted by Mark Daniel at Sep 17, 2006 04:35 PM
Thanks for the walkthrough! I found that I needed to make a small change to LDAPUserFolder to make it work with Apple's Open Directory, however (Apple based Open Dir on OpenLDAP, and left it almost completely unchanged). LDAPUserFolder looks for groups only with the objectclass "groupOfUniqueNames," but Open Directory doesn't give groups an objectclass of such. It does, however, give it "posixGroup," so I simply did a search in every .py and .pyc file within the LDAPUserFolder product folder for every instance of "groupOfUniqueNames" and replaced it with "posixGroup." Plone was immediately able to see and use my LDAP groups, and I was able to manually map LDAP groups to ZMI roles. Now to figure out how to *write* to Open Directory.

what about writing to LDAP?

Posted by Maurizio Pinotti at Sep 18, 2006 12:47 PM
first of all thanks for this howto! I was wondering if it's possible to write to LDAP also! in particular, I need to change the email attribute on the LDAP every time a user changes his/her plone email attribute. Is it possible to do so? how?
I managed to connect the two attributes and if the user hasn't already set a plone email the cms uses the ldap email, but if I change my plone email the ldap email doesn't change!

at this moment I am trying to modify ldap attributes from the ZMI but I get the following error: STRONG_AUTH_REQUIRED LDAPDelegate.modify: {'info': 'modifications require authentication', 'desc': 'Strong(er) authentication required'} (2006-09-18 14:11)

should I ask to the ldap mantainer to give me more rights?

thanks in advanced
Maurizio

writing back to ldap

Posted by Maurizio Pinotti at Sep 18, 2006 04:50 PM
I solved the auth problem, and now I can change attributes from the ZMI. But I still can't change from PLone! if I change my email thru plone the matching ldap attribute remains unchanged

Strong auth required

Posted by Tom Hallam at Oct 23, 2006 06:24 AM
Sounds like your LDAP server has an acl that requires a stronger authentication (eg kerberos) to change an attribute.

Are you binding using ssl?

Tom

Bug Somewhere...

Posted by Nick Couchman at Oct 06, 2006 09:34 PM
This is a great tutorial, but there seems to be a bug somewhere (not in the tutorial). For some reason PlonePAS (or PluggableAuthServices) only enumerates users out of the first item in the list under acl_users/plugins/User_Enumeration Plugins. This is quite annoying, as I have several LDAP trees that I would like to read from, but can only grab users from the first tree. I think this is further evidenced by the fact that you have a step in the procedure to move the LDAP tree to the top of the list. This shouldn't be necessary - PlonePAS should enumerate users from the entire list, not just the first entry. Also, for some reason certain products (like PCNG, for example), still don't enumerate the users.

Work for Plone 2.5.1 but ...

Posted by Muhamad Abdulkadir at Oct 31, 2006 08:12 PM
After doing a patch to LDAPMultiPlugins as explained in the article, we have to edit LDAPPluginBase.py file in the Products/LDAPMultiPlugins directory. You will find a line:

from property import LDAPPropertySheet

Just add '#' so that it becomes

#from property import LDAPPropertySheet

I use LDAPMultiPlugins 1.4 and LDAPUserFolder 2.7.

Work for Plone 2.5.1 but ...

Posted by Muhamad Abdulkadir at Oct 31, 2006 08:45 PM
Sorry, still is not working. Before editing LDAPPluginBase.py, LDAPMultiPlugins is not listed in the ZMI, but after editing, I can add LDAPMultiPlugins, can search a user from ZMI, edit user data, etc., so I think everything is ok. But it turned out that it cannot do searching from inside Plone; only from ZMI.

It works for Plone 2.5.1

Posted by Muhamad Abdulkadir at Nov 01, 2006 04:19 PM
Yes, finally it works for Plone 2.5.1. Just follow carefully all the steps above BUT do not carry out a patch to LDAPMultiPlugins! Use the latest LDAPMultiPlugins (1.4 as of this writing) and LDAPUserFolder 2.7. Plone was installed on Zope 2.9.5.

Doesn't work for me

Posted by JS at Nov 06, 2006 11:19 AM
I use Plone 2.5.1, zope 2.8.8, LDAPMultiPlugin 1.4 and LDAPUserFolder 2.7.
When I go to portal_memberdata in the ZMI I've got :


File "/zope/dev_JS/Products/kupu/plone/plonelibrarytool.py", line 182, in isKupuEnabled
    if user.getProperty('wysiwyg_editor').lower() != 'kupu':
  File "/zope/dev_JS/Products/CMFCore/MemberDataTool.py", line 349, in getProperty
    raise ValueError, 'The property %s does not exist' % id
ValueError: The property wysiwyg_editor does not exist


And I've got the same when I try to see my plone site...
So I have tried to comment the line and I've got a new error :

 File "Python expression "mtool.getMemberInfo(user.getId())"", line 1, in <expression>
AttributeError: getMemberInfo


Seems like there is a probleme with fetching memberdata...

Doesn't work

Posted by Genadijus Promakovas at May 13, 2007 04:02 PM
the same with my instance..

* Module Products.CMFCore.MemberDataTool, line 349, in getProperty
ValueError: The property wysiwyg_editor does not exist (Also, the following error occurred while attempting to render the standard error message, please see the event log for full details: The property wysiwyg_editor does not exist)

(Zope 2.9.6-final, python 2.4.4, linux2)

Where's LDAPMultiPlugins?

Posted by Rob Hicks at Dec 04, 2006 01:34 PM
I can't find this product either within the Plone site or on the net using google.

Authentication working - question about role management

Posted by ak at Dec 07, 2006 04:31 PM
I have read-only access to LDAP, so I would like to only authenticate users using LDAP - but still mamange the whether they are a manager, etc within zope. I am hoping to accomplish something like, the first time a user logs in, we check ldap, if they can authenticate - make them a member. That seems to be working, however I can't seem to perform any user management, such as promotion to manager, etc. Is this possible? or will I have to have a proper roll mapping between LDAP and Zope? I really hope that's not the case.

Great job !

Posted by Francois DELABY at Jan 09, 2007 05:12 PM
Thanks for this very well done howto !!

Just one thing : you don't speek about python-ldap. I had to install (build) the package python-ldap... And, before, I had to install openldap sources. A previous small boring step (finding the sources, configuring, building, ...) ;-)

Using SSL

Posted by Rycharde Hawkes at Feb 05, 2007 06:32 PM
Has anyone got this working with SSL? One missing step is the provision of a CA certificate to enable the SSL handshake to take place. The only way I can find of doing this is modify LDAPUserFolder/LDAPDelegate.py and put this near the top:
ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, "/location/of/ca.pem")

That works, but any attempt to connect using SSL results in a SERVER_DOWN error. Why? I don't need an account to access the ED for authentication so I'm assuming I don't need to provide a Manager DN and password - in fact I can't have one for the ED I'm using.
Can anyone help?

Re: Using SSL

Posted by Boll Weevil at Sep 19, 2007 08:42 AM
In a setup with a single LDAP server, I got this working via the horrible hack of simply putting

ldap.set_option(ldap.OPT_X_TLS_CACERTFILE, "/location/of/ca.pem")

in line 206 of Products/LDAPUserFolder/LDAPDelegate.py in version 2.8 of LDAPUserFolder

ldap SSL

Posted by jens jensen at Oct 26, 2007 09:29 AM
this is not a zope or python problem. you have to setup your openldap correctly.

1. put your ca-cert in /etc/openldap/cacerts and do a openssl-hash on it:
 openssl x509 -hash -noout -in ca.crt
and make a link to the result hash:
 ln -s ca.crt <the_hash>.0
in this directory, note the trailing .0 in addition to the hash, important!
2. edit /etc/openldap/ldap.conf and add this:
 TLS_CACERTDIR /etc/openldap/cacerts
 TLS_REQCERT hard

second is optional i guess.

thats all, test the SSL-connect with the ldapsearch-tool:

ldapsearch -Zx -h ldaphost -b "searchbase" "(uid=*anything)"

and test it with python (the zope python binary):

a=ldap.initialize('ldaps://ldapserver:636')
a.search('base',2,'filter',[attr])

tested for CentOs4, php will work now also in tls.

jens

Use the latest LDAPMultiplugins (1.5)

Posted by David Bain at Mar 03, 2007 07:52 PM
The latest patch at antiloop.plone.org works with LDAPMultiplugins 1.5

I had no success with older versions of LDAPMultiplugins

Very good HOWTO - used it as base for my own experiments

Posted by Erik Forsberg at Mar 04, 2007 05:32 PM
Thank you for this HOWTO - it's very useful.

I spent part of my weekend experimenting with Plone and LDAP. Based on your HOWTO, I actually succeeded doing most of the things I wanted to do.

My notes are here:

http://efod.se/[…]/plone-2-5-2-and-ldap-revisited

Problem with LDAP groups and OS X

Posted by Trevor Elbourne at May 08, 2007 01:10 AM
It seems to me that LDAPUserFolder has a shortcoming with respect to groups in that for users, it allows you to define both the LDAP schema, and the object hierarchy, but does not allow this for groups. This has the effect of not being able to add groups (certainly not under OS X) from the ZMI.

After changing "groupOfUniqueNames" in the python source to "posixGroup" I was able to see all of my Open Directory groups, but without being able to define the schema, I cannot add new groups. And I am not sure if role mapping to Open Directory groups is working properly either.

OD posixGroups

Posted by Ryan Stasel at Aug 06, 2007 09:05 PM
yeah, this method is half-baked at best. While it does let you see the groups, it does not know a user is a member of those groups, and therefore is nearly useless.

There was a patch a while back, but it doesn't work since about LDAPUserFolder 2.6.

Anyone know how to get this working? With Plone3, LUF 2.6 doesn't work anymore... so it would be nice to have a solution for those of us running OpenDirectory.

OpenLDAP ppolicy check_password requires 'clear' encryption

Posted by Chris Shenton at Sep 24, 2007 06:41 PM
We're using OpenLDAP's ppolicy overlay to implement password aging, expiration, lockout and such. You can configure it to use an external C module to check password complexity. But if PloneLDAP is configured to use anything but 'clear' for User Password Encrytion, plone sends a pre-hashed string to LDAP which ppolicy realizes can't be processed by check_password.


 So I use 'clear' since my LDAP is on the same box as my Plone; if they were on different boxes, use LDAPS transport. LDAP actually does store the userPassword with the default hash defined for slapd so you're not exposing them there.

I haven't seen any other damage this might cause.

Introspection Groups Error

Posted by unset at Sep 25, 2007 03:08 PM
Hello

I applied patch for LDAPMultiPlugins, and i enabled groups, group_introspection and group_enumeration. If i check group_introspection and click in groups tab (in plone group management) i received the next error:

'NoneType' object has no attribute '__of__'

BUT if i go to the members of group link (example), it's work:

http://host:port/plone/prefs_group_members?groupname=GroupName

If i go to groups of member, it's nothing

And for finish, and the most important for my, if i applied rol propietary for a group in a private folder, and login in the portal with an user of this group, the rol it's not applied.

I try with PloneLDAP, but it's not work

Some ideas?

Introspection Groups Error

Posted by unset at Sep 25, 2007 03:16 PM
And if i try to access to private folder url, i received the next error in the log:

  ...
  ..
  .
  Module Products.PageTemplates.Expressions, line 185, in __call__
  Module Products.PageTemplates.Expressions, line 173, in _eval
  Module Products.PageTemplates.Expressions, line 127, in _eval
   - __traceback_info__: group
  Module Products.PageTemplates.Expressions, line 334, in restrictedTraverse
   - __traceback_info__: {'path': ['getGroupName'], 'TraversalRequestNameStack': []}
AttributeError: 'NoneType' object has no attribute 'getGroupName'

a patch for this problem

Posted by redcor at Nov 13, 2007 03:47 PM
I had the same problem. this patch helped:
PlonePAS
--------
in groups.py:
    *add the if condition bleow marked with <---*
    def listGroups(self):
        # potentially not all groups may be found by this interface
        # if the underlying group source doesn't support introspection
        groups = []
        introspectors = self._getGroupIntrospectors()
        for iid, introspector in introspectors:
            groups.extend(introspector.getGroups())
        return [self.wrapGroup(elt) for elt in groups if elt] <-- if elt