I’m terribly disappointed that I won’t be able to make it, but I wanted to pass it on: There’s an Alfresco/Liferay Meetup in Ontario, California on July 18th. The format will be a collection of small roundtables. It should be a great opportunity for people who are exploring Alfresco and Liferay (together or separately) to learn more and for others to share their knowledge and experiences. If you are on or near the West Coast you should check it out. Learn more and sign up at http://web.meetup.com/44/.

Today the Optaros web site has a press release announcing that Alfresco has made us a Platinum partner of theirs. We’re obviously very excited to earn this distinction and we look forward to continued delivery of critical solutions built on Alfresco. The press release also briefly mentions a solution we built for the Swiss Federal Court.

You can read more about how we work with Alfresco here.

Getting Alfresco to authenticate against LDAP is a pretty straightforward task that’s documented on the Alfresco wiki. But this week I’ve had to play around with a few specific implementation details beyond just users in a directory with plain-text passwords and simple authentication. Here are some rough notes that might save others some time.

Alfresco-LDAP notes

• If “admin” is still your administrative user, don’t forget to set up a corresponding entry for the admin user in your LDAP directory.
• “Simple” authentication works when OpenLDAP stores either plain text passwords or MD5 passwords (Base64-encoded). If your MD5 passwords happen to be in hex you can convert them to Base64 using your favorite programming language. I used perl.
• “DIGEST-MD5” authentication works when OpenLDAP stores plain text passwords but I could not get it to work when using MD5 passwords.
• “DIGEST-MD5” authentication only works when OpenLDAP is configured to support DIGEST-MD5 as a SASL mechanism. Query the LDAP server’s “Supported SASL Mechanisms” property to see if DIGEST-MD5 is listed.
• If you are compiling OpenLDAP from source, you must configure it with the –with-cyrus-sasl flag. In order to be able to do this, you must already have Cyrus SASL installed.
• There are two ways user home folders can get created: (1) When a user logs in for the first time, but before a user sync has occurred or (2) When a user sync occurs. How the user folder gets created is configured differently in each case. In the first case, the bean referenced by the defaultProvider property of the homeFolderManager bean configured in authentication-services-context.xml is used. For the sync, the cm:homeFolderProvider key value in the ldap authentication context XML file references the HomeFolderProvider bean. If you want the behavior to be consistent, you’ll need to make sure to point to the same HomeFolderProvider bean in both places.
• There are several HomeFolderProvider beans configured OOTB. For example, the userHomesHomeFolderProvider bean creates the user’s home folder as a folder under User Homes named using the user’s user ID.
• If you want to store a password in SASL’s database, use saslpasswd2 -c
• If a user does not exist in SASL’s database it will look for the userPassword attribute in the LDAP directory.
• You must add authz-regexp entries to slapd.conf to map the SASL authorization requests to actual LDAP entries.
• Once your openldap server is running with SASL enabled, you may need to use the -x command-line switch when using things like ldapsearch, ldapadd, and ldapmodify if you still want to use simple authentication.

If I get some time I may reorganize these rough notes into an easier-to-follow step-by-step setup guide.