Liferay and Active Directory integration

This section was omitted from the recent Linux Pro Mag article on Liferay: ... HOME STRETCH!!! Now we have Liferay running in Tomcat and Apache is handing off web requests for Liferay to Tomcat using mod_jk. The next phase is Active Directory authentication. We will assume that you already have a Windows domain controller to tie in to. First, download and install Jxplorer from www.jxplorer.org Start Jxplorer and enter the following information into the connection dialog: Host: 192.168.25.128 Protocol: LDAPv3 Base DN: DC=testdomain DC=com Level: User + Password User DN: CN=liferay-access,CN=Users,DC=testdomain,DC=comPassword: liferay-access Replace the host IP address with your AD server's IP. Replace all instances of DC=testdomain,DC=com with your domain information. My Liferay user's name is liferay-access and the account resides within the users container directly under testdomain.com in AD. Modify your User DN accordingly. This was the most difficult part of the process for me when I first tried to get anything (non Microsoft) to use an AD server for LDAP authentication. The MMC snap-ins water down the technology to the point that you initially don't have to understand LDAP object naming conventions to get up and running, or to manage a small domain. The complication comes in when you need to do any LDAP binding from a non-Microsoft platform. Once you are able to successfully bind to your AD server using the Liferay account's credentials, write down the information you used. Next, we will backup the Liferay database in case we need to quickly restore our settings. SSH into the Liferay server and mysqldump lportal -u lportal -p >pre-ldap-dump.sql Next, we will create the portal-ext.properties to contain all of our LDAP settings. For the configuration options, I relied heavily on the Liferay user forums. If you run into issues, especially with LDAP, that is the first place to go looking for a solution. The portal-ext.properties is meant to override the settings in portal.properties. the portal.properties file resides under liferay-4.4.2/webapps/ROOT/WEB-INF/classes and contains the defults for a ton of liferay settings. Don't see the file? It only exists there in the event you built Liferay from source. Why? Who knows. You can find portal.properties in the source tree under portal-impl/classes . If you intend to tweak Liferay further, it would be a good idea to place the portal.properties file in the liferay-4.4.2/webapps/ROOT/WEB-INF/classes directory and copy the values you want to change to the portal-ext.properties file in the same directory. vi /opt/liferay/liferay-4.4.2/webapps/ROOT/WEB-INF/classes/portal-ext.properties ____see portal-ext.properties________ Tweak the information here to coincide with your LDAP settings. Again, thanks to the Liferay user forums for the great explanation for these values. Because the change we just made is to a Liferay configuration file, we must bounce the portal to see the results. service liferay restart If all is well, you should be able to log in using the test@liferay.com credentials and use the Directory Portlet to see the users and groups imported from Active Directory. watch the catalina.out file for errors on startup with tail -f /opt/liferay-4.4.2/logs/catalina.out _____________portal-ext.properties___________ ldap.factory.initial=com.sun.jndi.ldap.LdapCtxFactory ldap.base.provider.url=ldap://192.168.25.128:389 ldap.base.dn=dc=testdomain,dc=com ldap.security.principal=liferay-access ldap.security.credentials=liferay-access ldap.auth.enabled=true ldap.auth.required=false ldap.auth.method=bind ldap.auth.password.encryption.algorithm= ldap.auth.password.encryption.algorithm.types=MD5,SHA #ldap.auth.search.filter=(cn=@screen_name@) ldap.auth.search.filter=(mail=@email_address@) ldap.user.mappings=screenName=sAMAccountName\npassword=userPassword\nemailAddress=mail\nfirstName=givenName\nlastName=sn\njobTitle=title\ngroup=memberOf\nfullName=cn #ldap.group.mappings=groupName=cn\ndescription=description\nuser=uniqueMember ldap.group.mappings=groupName=cn\ndescription=description\nuser=member ldap.import.enabled=true ldap.import.on.startup=true ldap.import.interval=10 ldap.import.user.search.filter=(&(objectCategory=Person)(sAMAccountName=*)) ldap.import.group.search.filter=(objectCategory=Group) ldap.import.method=user #ldap.import.method=group ldap.export.enabled=false ldap.password.policy.enabled=false

Google Dropping Emails?

I have had a bunch of trouble with script-generated emails timing out and not being sent through Google Apps. Not really sure why this is happening, but this is how I am fixing it... and it seems to work so far.

If you are using the article I wrote in Linux Pro Magazine a month or so ago to deploy Liferay, do not set up Liferay to connect to Google directly to send mail.

Instead:

1. Set up Sendmail as a relay on your Liferay application server (only accessible to localhost) and use the mail settings in Liferay (ROOT.xml) to send all outbound email through localhost. No password should be necessary (depending on how you set Sendmail up), but make sure that the username you are using does, in fact, exist in your Google Apps account.

2. In Google Applications mail control panel, be sure to allow the public IP address your mail will be relayed from.

3. Next, publish your SPF record if you have not already done so. see openspf.org for details. If your DNS provider does not offer txt records for your domain, move to someone who does or host your own public authoritative DNS.

   SPF adoption is growing and if you are not onboard you will be left behind with your communication being dropped into spam folders or altogether rejected. As of a few days ago, Network Solutions does not offer that service and do not have an ETA for when they will.

   Running your own authoritative DNS has other advantages, like enabling Jabber/Gtalk federation between tour domain and others. There is documentation on the Google Apps forums for this
4. Here is the hard part: if you consider these emails to be of critical importance you must contact Google (but only if you are a paying customer) and ask them nicely to remove spam filtering from the address you are using to send emails from Liferay.

Why does this work? Instead of having Liferay connect directly to Google's SMTP (meant for clients like Outlook), the messages are sent through a local relay that does not send to smtp.gmail.com. The relay looks up the MX records for your organization which should be pointed to Google's MXes (aspmxl.google.com etc...) to forward email. When you whitelisted the IP address in the GApps control panel, you were telling Google that you would be intentionally relaying email from that address. The SPF record essentially does the same thing for other mail servers. If there is a timeout situation getting the email from the relay to Google, the relay should continue to attempt to resend.

This documentation also goes for other technologies like Nagios that may generate a quantity of critically important email.

Best of luck... -Ash

Liferay LDAP issues

Using Liferay 4.3.3 in Tomcat, authenticating against MS Active Directory. I was having a strange problem... only one user would not authenticate, and was throwing "...Problem accessing LDAP server: Unprocessed Continuation Reference..." All accounts were importing and working perfectly. Using JXplorer and comparing accounts, I found that the account in question did not have an email address associated with it. Without an email address, Liferay will not authenticate... at least with the typical config.