Author Topic: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth  (Read 55558 times)


  • Zen Monk
  • **
  • Posts: 61
  • Karma: +4/-0
    • View Profile
Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« on: March 14, 2012, 06:36:19 pm »
Document Goals:
 1. zentyal 2.0 install configured as ldap slave (warning: passwords will be passed in the clear. both master and slave are on my local network, so i'm not too worried. However, I would never configure it this way on the internet, i would use a VPN tunnel to sync between master and slave, eventually, i'll configure the vpn and document it here)
 2. liferay 6.1 bundle w/ ldap auth to localhost

My skill level is laughable at best as i spend most of my days quagmired heavy with confusion.  I have patience, persistence and many people on IRC helping me, as well as many web and forum postings to guide me.  The information in this document might be wildly incorrect.. but it's my roundabout way to get this shit working.  I welcome any constructive criticism improving what I have.  I appreciate learning.  Hopefully this will be helpful to someone else.

apologies, there should be more references here.

_breath life into new machine with kvm/libvirt_
create a volume big enough; name it after the machine.

sudo virt-install  --name=portal --ram=4192 --vcpus=4 --cpuset=0-3 --os-variant=ubuntulucid --cdrom=ubuntu-10.04-server-amd64.iso --disk path=/dev/cleopatra/portal --network=bridge=br0,model=virtio --vnc

run through the install dialogs

select ssh server

finish the install, reboot

_run updates_
ssh into it.
sudo apt-get update && sudo apt-get upgrade
sudo apt-get install unzip

_install Zentyal 2.0_
sudo apt-get install -y python-software-properties && sudo add-apt-repository ppa:zentyal/2.0 && sudo apt-get update

sudo apt-get install zentyal
 - at this point in my time, i like to keep the admin page on 4430 so i can ssl the regular website

open your browser
head over to https://portal:4430
accept self-signed security certificate
login to zentyal
select "skip install"

install the LDAP part of zenny:
once at the main dashboard, select 'software management' -> 'zentyal components' -> 'users and groups'; click 'install'; confirm the extra packages

configure the network:
eth0 is internal, so click 'next'
it gets a dhcp address, so click 'next'
Select the type of ldap server: "Advanced configuration (Master/Slave/AD Sync)", click next.
Click on "Save Changes"

configure module status:
at the dashboard, select 'Module Status'.  Turn all the modules that can be turned on and select accept at each module dialog.  Save changes.

configure firewall to allow ldap:
at the dashboard, select 'Firewall' -> 'Packet Filter' -> 'Internal networks to Zentyal'
Edit the 'LDAP' entry, change from 'Deny' to 'Accept'

_Configure LDAP as slave_
reset users and groups for whatever reason:
go to your terminal and run: sudo /usr/share/ebox-usersandgroups/ebox-usersandgroups-reinstall

after that is finished, go back to your browser, refresh the zentyal admin page and select 'users and groups', then 'mode'
From the "Mode" dropdown box select "Slave".

type the address of your master (i've been having to type in my actual ip address, not hostname for whatever reason... i'm pretty sure my dns is fine) and master password

go to the module, enable 'users and groups'

_Add the service and configure firewall for tomcat7/liferay_
add a service called tomcat7 on port 8080
From the Dashboard, select "Services" -> Add New:
 Service Name: tomcat7
 Description: tomcat7/liferay portal
 Tick the internal checkbox.
 Select Add.
  Under "Editing Service":
  Protocol: TCP
  Source Port: Any
  Destination Port: Single Port: 8080
  Save Changes!
 Now Select "Firewall" -> "Packet Filter" -> "Filtering rules from internal networks to Zentyal" -> "Add New"
   Decision: ACCEPT
   Source: Any
   Service: tomcat7
   Select "Add"
   Save Changes

_install oracle java jdk v6_


for whatever reason it worked better for 'sudo -i' to begin with

chmod +x jdk-6u31-linux-x64.bin


    sudo mkdir -p /usr/local/java
    sudo mv jdk1.6.0_31 /usr/local/java/jdk1.6.0_31
    sudo ln -s /usr/local/java/jdk1.6.0_31 /usr/local/java/latest
    sudo mv /etc/environment /etc/environment.bak
    sudo echo "JAVA_HOME=\"/usr/local/java/latest\"" > ~/environment
    sudo echo "JRE_HOME=\"/usr/local/java/latest/jre\"" >> ~/environment
    sudo echo "PATH=\"\$JAVA_HOME/bin:$PATH\"" | cat >> ~/environment
    sudo mv ~/environment /etc/environment
    sudo echo "export JAVA_HOME=\"/usr/local/java/latest\"" > /etc/profile.d/
    sudo echo "export JRE_HOME=\"/usr/local/java/latest/jre\"" >> /etc/profile.d/
    sudo echo "export PATH=\"\$JAVA_HOME/bin:$PATH\"" | cat >> /etc/profile.d/
    sudo chmod +x /etc/profile.d/
again for whatever reason, i had to reboot to get this to work

_install mysql_

sudo apt-get install mysql-server

_create liferay mysql user and db_
mysql -p -u root
CREATE USER 'lportal'@'localhost' IDENTIFIED BY 'lportal';

_d/l liferay bundle_

wget "" -O

_expand liferay into /opt/liferay_
sudo mkdir /opt/liferay
sudo mv liferay-portal-6.1.0-ce-ga1 /opt/liferay

_create config file_
sudo vim /opt/liferay/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/webapps/ROOT/WEB-INF/classes/

put this in it:

_remove sevencogs-hook_
There is only one application included in the bundle that you need to remove. It's called sevencogs-hook. It's a Liferay plugin that copies the 7Cogs data into the database when Liferay is started. To remove it, all you have to do is undeploy it. The method for doing this differs by application server and that, of course, depends on the bundle you have chosen. For example, on Tomcat you delete the application from the [Tomcat Home]/webapps folder

sudo rm -rf /opt/liferay/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/webapps/sevencogs-hook
keep the sevencogs-theme if you want, it might be useful.

_configure tomcat to be a service_
sudo vim /etc/init.d/tomcat7
# Tomcat auto-start
# description: Auto-starts tomcat 7
# processname: tomcat7
# pidfile: /var/run/

export JAVA_HOME=/usr/local/java/latest

case $1 in
        sh /opt/liferay/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/bin/
        sh /opt/liferay/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/bin/
        sh /opt/liferay/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/bin/
        sh /opt/liferay/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/bin/
exit 0

Change the mode of the file:
sudo chmod 755 /etc/init.d/tomcat7

create links in the rc.d
sudo ln -s /etc/init.d/tomcat7 /etc/rc1.d/K99tomcat
sudo ln -s /etc/init.d/tomcat7 /etc/rc2.d/S99tomcat

reboot to test

_check the tomcat log_
watch the machine come up, it may take a while, so be patient, it takes a coupla minutes on my machine.
sudo tail -f /opt/liferay/liferay-portal-6.1.0-ce-ga1/tomcat-7.0.23/logs/catalina.out

_configure the machine in the browser_
open your browser and head to http://portal:8080
finish off the install here.

_Configure LDAP_
After installed, login with: / password
Control Panel -> Portal Settings -> Authentication -> LDAP:
  Tick "Enabled" check box, hit save.
  Under "LDAP Servers" click the "Add" button
    Server Name: Local (arbitrary, i chose Local cause I'm boring)
    At first I was confused by the "Default Values interface" but now I understand that it simply just resets the settings to match the which ever directory paradigm.  You can simply ignore this.
    Under "Connection"
      Base Provider URL: ldap://localhost:1389  (please note, that port 389 is used to bind to the ldap master, and 1389 is used to bind onto the ldap slave, thank you exekias for your constant reminder, maybe one day, I'll remember)
      Base DN: dc=zabulon,dc=casanueva,dc=com
      Principal: cn=ebox,dc=zabulon,dc=casanueva,dc=com
      Credentials: ZeeZecretPassword
    Go ahead and test the connection
    Under "Users"
      Authentication Search Filter: (mail=@email_address@)
      Import Search Filter: (objectClass=inetOrgPerson)
      User Mapping:
        Screen Name: uid
        Password: userPassword
        Email Address: mail (From what I remember, which is not to be trusted, I had to manually edit my Zentyal LDAP and add my mail address to the master, and i believe it propogates it to the slaves without a hitch - to edit i use jxplorer or luma (i can't remember which app i used specifically), this is something to be aware of when upgrading or re-installing the master from scratch.. something i have yet to do)
        Full Name: <empty>
        First Name: givenName
        Middle Name: <empty>
        Last Name: sn
        Job Title: <empty>
        Portrait: <empty>
        Group: <empty>
        UUID: <empty>
      Go ahead and test the LDAP Users, see if it works; adjust the settings if needed. 
      Import Search Filter: (objectClass=posixGroup)
      Group Mapping:
        Group Name: cn
        Description: description (i don't know if this is needed.. but i kept it so far, seems fine, can't hurt)
        User: memberUid   
      Test the Groups.
    I left the whole Export section alone, I don't want to export from Liferay, as far as I can tell at this moment.
    Click the "Save" button
  Import / Export
    I ticked the "Import Enabled" checkbox, i don't know if this is correct.
    I left "Import on Startup Enabled" and "Export Enabled" unticked.
  Password Policy
    I ticked "Use LDAP Password Policy" checkbox.
Aight, that's it; good luck and happy authing.
« Last Edit: March 14, 2012, 08:53:28 pm by andygraybeal »


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #1 on: March 14, 2012, 08:20:43 pm »
Karma point from me Andy. Have been looking at Liferay and looks impressive.


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #2 on: March 15, 2012, 07:35:25 am »
Just curious: why such LDAP filter based on mail address? Is it because of any specific need?


  • Zen Monk
  • **
  • Posts: 61
  • Karma: +4/-0
    • View Profile
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #3 on: March 15, 2012, 11:42:09 am »
I don't know :)  Basically I didn't mess with this search filter.

Maybe instead, it would be better to have:
Authentication Search Filter: (uid=@user_id@)

Okay, so I just changed it to uid=@user_id@ and from what I can tell it works fine.

Generally speaking, the mail attribute is one of 5 required attributes for Liferay to auth against LDAP.  The 5 attributes are: Screen Name, Password, Email Address, First Name, and Last Name.

Let me know your thoughts.


« Last Edit: March 15, 2012, 11:46:52 am by andygraybeal »


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #4 on: March 15, 2012, 11:58:28 am »
My feeling is that [uid] is mandatory as soon as you create an account in LDAP while [mail] might not be. It depends on your own decision to create, automatically or manually, this mail address.
Based on this, I always feel suspicious when [mail] attribute is used for authentication elsewhere than mail related application. Even there, I tend not to like it  ;)


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #5 on: March 17, 2012, 12:29:43 pm »
On IRC we had this discussion about the risk of bundling features in Zentyal that directly authenticate against LDAP. The risk here looks like to be that when an integrated application gets compromised, your LDAP database is compromised and thus your server.
The options mentioned to overcome direct authentication against LDAP would be using kerberos or Radius.

Now I stumbled upon Apache Syncope: an identity manager. I still am not a programmer and don't know if this can help Zentyal and integrating packages, but at first sight it looks promising.
« Last Edit: March 17, 2012, 12:31:37 pm by robb »


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #6 on: March 18, 2012, 03:38:37 pm »
Robb I would like to discuss this and maybe a new thread is required with everybody putting forward an opinion.

I have still failed to connect to the beta Samba4 offering which is normal enough as it is under development. I might of confused matters as I run a hybrid of Ubuntu-Server with ubuntu-desktop installed on top. My interest is the actual LDAP structure we will end up with.

I most admit that I am confused to the structure slightly. If anyone can give me some guidance on "Non unique CN constructions" & "MS AD structure & Linux in-operability" then you have a clearer path than I.

To be honest I think the Apache product slightly bloated and overkill for the purposes required. It could be used I guess. All I see is some form of simple mechanism to add schema variables to user administration.
Some simple control to allow additions but no changes to core schema. That wouldn't be massive but something Zentyal would more than likely need to supply.

Thats only an idea and don't know what the community thinks?


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #7 on: March 19, 2012, 09:40:13 pm »
« Last Edit: March 19, 2012, 09:52:01 pm by robb »


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #8 on: March 20, 2012, 07:57:42 am »
Let me start this reply with apologies: my reply is going to be a bit long but I don't know how to elaborate using only few simple words  :-[
On the other hand, I can't refrain myself launching debate on above comment  ;)

Basically, Rob's point is: "Using LDAP for authentication creates weakness and security hole. Radius should be used instead"

The short answer (from my standpoint  8) ) is YES it can.... but I'm afraid root cause is misunderstood and impact of such decision is not well understood too. Saying that, I didn't take part to the IRC debate. Let me explain.

LDAP uses base64 scheme to send password when client performs "LDAP BIND". This is NOT secure and this is one of the reason, in fact the main one, why LDAPS exists. TLS (LDAP over SSL) is a must when LDAP is used for authentication.
Does Radius solve this issue? yes and no. Yes because there is no more use of base64  :) and no because such approach would mean to store in LDAP either only attributes that can be read anonymously or to rely on complex ACI (LDAP access control rules) implementing proxy mode or dedicated mechanism which make use of LDAP even more complex thus at the end not used. To bad, LDAP concept is the right one when it comes to manage account related data to be shared between multiple applications. Why? Because LDAP is a standardize protocol (IEEE and RFCs) (keep in mind there is no such standard whit access to databases).

So what?  ??? ???

Some implementations permit to benefit from the best of these two worlds.
Technically speaking, one can deploy LDAP based authentication using... one time password so that capturing base64 password becomes useless (it works well, I did it in a previous life  ;D) but this means use of such OTP mechanism. Not le lighter approach for all applications.
LDAP is able, as transport layer, to handle authentication that is then performed against external backend, thanks to SASL implementation. This would permit, e.g. to implement Radius authentication over LDAP transport  :D Here again this is a bit complex and heavy  :-\

Then, to add more entropy  ;) , at this stage we should take in account identity management. I will  not because this post will be too long (I'll elaborate on this later).

So what do I propose ?  Kerberos  ;D

Why Kerberos rather than Radius? basically because the second "A" of "AAA" is, kind of, conflicting with modern Identity management approach (back to my previous point hehehe).  I mean that Radius authorization is fine when it comes to control remote access or provide simple "profile" but this is rather poor (or complex) when it comes to provide real profiling either explicit or implicit. This deserves to be elaborated, again, but I will not here.

LDAP + Kerberos permit secure authentication and powerful profiling that can be managed using Identity management front-end.

Keep also in mind that Kerberos can be easily implemented using mechanisms like CAS to make it almost transparent to al lot of applications (e.g. web based applications), bringing also SSO.

TTFN  8)

(sorry for this long story that is obviously reflecting only my own view)


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #9 on: March 20, 2012, 03:51:21 pm »
Christian in respects to Kerberos & Samba4 how will LDAP (AD) work with apps say LifeRay?


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #10 on: March 20, 2012, 04:56:37 pm »
Samba4: I don't know. I haven't spend enough time on it to understand how Samba4 will be able to rely on external LDAP server since they decided to promote their own LDAP instance. for sure no technical issues here but potentially some constraints with schema, DIT or ACI. Samba4 is also bringing its own Kerberos server. Well, if such implementation is flexible enough to accept external Kerberos server, that's fine, otherwise they are thinking to be centre of the world and we are back to another Microsoft like model  :-X
Principle they follow makes sense as goal id to replace Windows landscape made of Kerberos and LDAP. Thus no choice in term of protocols. Then in term of implementation, I don't know and need to read some documentation (not done yet).

Liferay does support Kerberos as authentication mechanism. So one may decide to go for LDAP or Kerberos from Liferay standpoint.


  • Guest
Re: Liferay 6.1 bundle, Zentyal 2.0 LDAP auth
« Reply #11 on: March 21, 2012, 12:13:15 pm »
Any of the Devs got any input to how the new roadmap 3.0 Kerberos / Samba 4 scheme will be implemented.

Is there any info you can provide the community?

Personally I wouldn't do that much work with the current LDAP. Just my opinion but the win7 / AD Samba 4 fix will prob be high on the agenda for many.
Sept my servers will be => 3.0 Roadmap but I am very unsure how LDAP / Kerberos / Samba4 will actually work ?

This is one of the reasons I am unsure about the Apache product that Rob mentioned. Its to foggy to decide and my only input for LDAP / AD manipulation would be to see what the devs propose.

« Last Edit: March 21, 2012, 12:19:59 pm by stuartiannaylor »