Category Archives: OpenDJ

LDAP secondary group memberships with OpenDJ and Ubuntu 12.04

As a follow-up to this post, let’s now configure OpenDJ and Ubuntu to use LDAP for assigning secondary groups to user accounts.

This is a quick guide intended for testing only, and we are assuming the setup here has been followed. One change is that we are using Ubuntu 12.04 x86 as the client system.

 

First, let’s create a new test group in OpenDJ. We assign it the structural object class namedObject, and the auxiliary object class posixGroup. The group GID number is 130, and we add a memberUid entry, with the UID of an existing LDAP account:

Adding a new group in OpenDJ

Now, on our test Ubuntu 12.04 x86 client, we modify /etc/ldap.conf, adding the following entry:

nss_schema rfc2307bis

This enables rfc2307bis LDAP schema support for PAM (OpenDJ uses the rfc2307bis schema by default).

 

Next, again in /etc/ldap.conf we uncomment the nss_base_group setting in the section headed with the comment “RFC2307bis naming contexts”, and give it the value as shown:

nss_base_group ou=Groups,dc=example,dc=co,dc=nz

Obviously you would modify the domain components to suit.

 

We now restart the nscd service, and verify that the secondary group information can be retrieved for an LDAP user:

itadmin@turrican2:/etc$ sudo /etc/init.d/nscd restart
 * Restarting Name Service Cache Daemon nscd                             [ OK ] 
itadmin@turrican2:/etc$ 
itadmin@turrican2:/etc$ id davek
uid=1004(davek) gid=50(staff) groups=130(testgroup),50(staff)

We can see that the secondary group testgroup with the GID number of 130 is successfully retrieved from LDAP for this user.

About these ads

Fun with JSPWiki skins

I really love JSPWiki. It’s super-easy to install, doesn’t require any additional configuration for a back-end database, the native interface is quick and fast to use, and it just runs and runs. Great software.

If there’s one area however where it’s lacking, it’s in a nice selection of bundled good-looking themes. But hey, it’s free and open source software, so one is really in no position to complain – and new skins can be created using entirely standard and familiar HTML and CSS.

It’s worth noting the difference between JSPWiki templates and skins – described at http://www.jspwiki.org/wiki/JSPWikiSkinDesign

After a bit of tinkering with CSS and the bundled “Smart” theme, I came up with this:

JSPWiki - modified "Smart" theme

Not the stuff of professional web design, but a definite improvement on the default theme, in my humble opinion.

Enable LDAP authentication with Nuxeo

Authenticating Nuxeo users against an LDAP directory is straightforward but for a bug which I encountered.

The instructions for enabling LDAP authentication are here: http://doc.nuxeo.com/display/ADMINDOC/Using+a+LDAP+directory. I am using Tomcat in my case, with OpenDJ as the LDAP server.

The bug I encountered is here: https://jira.nuxeo.com/browse/NXP-6574

And, the workaround I had to implement to get LDAP authentication up and running is detailed here: http://answers.nuxeo.com/questions/701/ad-ldap-connection-issues.

With this in place, LDAP authentication works as expected.

Enable secure LDAP container based authentication with JSPWiki

A quick follow up on my post here. I will describe below the steps needed to enable secure LDAP authentication (both LDAPS and HTTPS). This is not intended for production use, obviously.

I’m using the same platform and environment described here, and also using this as the starting point for the following.

 

Verify that the LDAPS connection handler is enabled in OpenDJ

This can be checked using the OpenDJ Control Panel GUI, and modified if necessary using the CLI dsconfig utility.

 

Switch to the secure LDAP port in the GlassFish JSPWiki security realm

Make sure you are using the ldaps:// URL prefix, and specify the secure port number (1636 in this example):

Enable LDAPS in GlassFish

 

Enable security for the relevant GlassFish HTTP network listener port

Our JSPWiki application is listening over port 8080, configured in GlassFish under http-listener-1. Enable security for this port:

Enabling security for the GlassFish http-listener-1 network listener

 

Enable HTTPS connections to JSPWiki

This is performed via modification of the JSPWiki web.xml file. In a default state, the web.xml file contains the following entries which enable the use of SSL connections:

<user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

Ensure these exist in web.xml under the container managed authentication section.

 

Export the OpenDJ SSL certificate and import it into the JSPWiki JKS keystore

The keytool CLI utility is used for this step.

First, we export the OpenDJ certificate (which has a default alias of server-cert) to a file:

dave@mymachine:~/OpenDJ/config$ pfexec keytool -export -alias "server-cert" -keystore ~/OpenDJ/config/keystore -file /tmp/server-cert.cer
Enter keystore password:  

Certificate stored in file </tmp/server-cert.cer>

Next, we import the certificate file into the keystore of the GlassFish domain running our instance of JSPWiki, which in this example is at /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks:

dave@mymachine:~/OpenDJ/config$ pfexec keytool -import -v -trustcacerts -alias "server-cert" -keystore /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks -file /tmp/server-cert.cer 
Enter keystore password:  
Owner: CN=mymachine, O=OpenDS Self-Signed Certificate
Issuer: CN=mymachine, O=OpenDS Self-Signed Certificate
Serial number: 
Valid from: 
Certificate fingerprints:
	 MD5:  
	 SHA1: 
	 Signature algorithm name: SHA1withRSA
	 Version: 3
Trust this certificate? [no]:  yes
Certificate was added to keystore
[Storing /opt/glassfishv3/glassfish/domains/domain1/config/cacerts.jks]

 

Modify the jspwiki.baseURL value

This is required as the URL prefix will have changed from http:// to https://. This modification is performed in the jspwiki.properties file.

Assuming my existing jspwiki.baseURL value is:


http://192.168.1.1:8080/ITProjects/

This would need to be changed to:


https://192.168.1.1:8080/ITProjects/

 

Restart the GlassFish domain, and test LDAP logins…

…and if you don’t observe secure logins working as they should, leave a comment.

Container based authentication with JSPWiki, GlassFish and OpenDJ

In this blog entry I am going to describe configuring JSPWiki to use container based authentication to authenticate LDAP users existing in an OpenDJ directory. I am using GlassFish as my web application container, so this can be considered an alternative solution to using Tomcat, for example as described here.

 

I am running JSPWiki version 2.8.3, deployed in GlassFish Open Source Edition 3.1.1 (build 12) on OpenIndiana oi_151 x86. OpenDJ is version 2.4.4, and I am using Java 6 update 26.

I am assuming prior basic familiarity with installing, configuring, and managing GlassFish and OpenDJ. Our starting point will be a freshly deployed instance of JSPWiki, for which the initial first-run setup procedure has taken place and without any configuration to the JSPWiki configuration files.

This is an insecure setup intended for testing purposes.

 

Create user and admin groups for JSPWiki in OpenDJ

I have created the Groups OU under my Base DN, and within it created the groups wiki-admin and wiki-users.

Members of the wiki-admin group will be authorized with full permissions in JSPWiki once authenticated. Members of the wiki-users group however will have a lesser set of permissions, suitable for regular day-to-day use of the wiki. You can use LDIF commands if you wish to create the directory entries, however, I just use OpenDJ’s super-easy GUI to do the work. For example:

JSPWiki groups in OpenDJ

 

Create an LDAP security realm in GlassFish

This can be performed in the GlassFish admin BUI. Note that we perform this step under the Configurations -> server-config node in the BUI (not the Configurations -> default-config node):

GlassFish server-config node

I have created the LDAP realm JSPWikiUsers with the following settings:

GlassFish LDAP security realm settings

Some observations on the above can be noted here:

  • The search-bind-dn and search-bind-password properties may be optional for your OpenDJ installation: they are required in my case because I have disabled anonymous access to my OpenDJ server
  • The port used for access to your OpenDJ server may not necessarily be 1389 – change this as necessary.

 

Change the JACC provider from default to simple

I found that if this step is not performed, LDAP group lookup from GlassFish to OpenDJ will plain just not work.

Navigate to the Configurations -> server-config -> Security node of the GlassFish admin BUI and make the setting as illustrated:

GlassFish - set the JACC provider to Simple

 

This should be all the configuration needed in GlassFish using the admin BUI, so we can now proceed to making the required modifications to the following JSPWiki deployment descriptor and policy files:

  • web.xml
  • jspwiki.policy
  • glassfish-web.xml

 

In the following steps, we are assuming that JSPWiki has been deployed to the domain1 domain, and the path to the deployment descriptor and policy configuration files is:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

 

(Also, in my case no changes needed to be made at all to the jspwiki.properties file.)

 

Enable container based authentication in the web.xml file

In the web.xml file (in its unmodified state in JSPWiki v2.8.3), look for the section near the end of the file which begins with the following comment:

<!--  REMOVE ME TO ENABLE CONTAINER-MANAGED AUTH

 

Simply uncomment the section and replace it with the following:

<security-constraint>
       <web-resource-collection>
           <web-resource-name>Administrative Area</web-resource-name>
           <url-pattern>/Delete.jsp</url-pattern>
       </web-resource-collection>
       <auth-constraint>
           <role-name>wiki-admin</role-name>
       </auth-constraint>
   </security-constraint>
      
   <security-constraint>
       <web-resource-collection>
           <web-resource-name>Authenticated area</web-resource-name>
           <url-pattern>/Edit.jsp</url-pattern>
           <url-pattern>/Comment.jsp</url-pattern>
           <url-pattern>/Login.jsp</url-pattern>
           <url-pattern>/NewGroup.jsp</url-pattern>
           <url-pattern>/Rename.jsp</url-pattern>
           <url-pattern>/Upload.jsp</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>GET</http-method>
           <http-method>HEAD</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <web-resource-collection>
           <web-resource-name>Read-only Area</web-resource-name>
           <url-pattern>/attach</url-pattern>
           <http-method>DELETE</http-method>
           <http-method>POST</http-method>
           <http-method>PUT</http-method>
       </web-resource-collection>

       <auth-constraint>
           <role-name>wiki-admin</role-name>
           <role-name>wiki-users</role-name>
       </auth-constraint>
   </security-constraint>

   <login-config>
       <auth-method>FORM</auth-method>
       <realm-name>JSPWikiUsers</realm-name>
       <form-login-config>
           <form-login-page>/LoginForm.jsp</form-login-page>
           <form-error-page>/LoginForm.jsp</form-error-page>
       </form-login-config>
   </login-config>

   <security-role>
       <description>
           This logical role includes all authenticated users
       </description>
       <role-name>wiki-users</role-name>
   </security-role>

   <security-role>
       <description>
           This logical role includes all administrative users
       </description>
       <role-name>wiki-admin</role-name>
   </security-role>

 

Modify the jspwiki.policy file

This will allow users in the wiki-admin LDAP group to be granted full permissions upon authenticating to JSPWiki.

Look for the following section at the end of the jspwiki.policy file (in its unmodified state in a JSPWiki v2.8.3 installation):

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};
grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

 

And modify it to read:

// Administrators (principals or roles possessing AllPermission)
// are allowed to delete any page, and can edit, rename and delete
// groups. You should match the permission target (here, 'JSPWiki')
// with the value of the 'jspwiki.applicationName' property in
// jspwiki.properties. Two administative groups are set up below:
// the wiki group "Admin" (stored by default in wiki page GroupAdmin)
// and the container role "Admin" (managed by the web container).

// grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
// grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
//     permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
// };
grant principal com.ecyrd.jspwiki.auth.authorize.Role "wiki-admin" {
    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*";
};

 

Create the glassfish-web.xml file

The primary purpose of this file will be to map the security roles we defined in the web.xml file to the JSPWiki groups we created in OpenDJ. The file should be created at:

/opt/glassfishv3/glassfish/domains/domain1/applications/JSPWiki/WEB-INF

 

The glassfish-web.xml file should contain the following only:

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">

<glassfish-web-app>
 <security-role-mapping>
        <role-name>wiki-admin</role-name>
        <group-name>wiki-admin</group-name>
 </security-role-mapping>
 <security-role-mapping>
        <role-name>wiki-users</role-name>
        <group-name>wiki-users</group-name>
 </security-role-mapping>
</glassfish-web-app>

 

Restart the GlassFish domain, and test LDAP logins to JSPWiki

First, restart the domain either using the asadmin utility or the GlassFish admin BUI. Then test LDAP logins to JSPWiki.

In my case, we can observe that logging in as a user that is a member of the wiki-admin group in OpenDJ, I do indeed have full permissions in JSPWiki:

JSPWiki LDAP admin user

Whereas logging in as a user that is a member of the wiki-users group in OpenDJ, I am restricted from certain destructive actions:

JSPWiki LDAP standard user

LDAPCon 2011 presentation on OpenDJ

Great video here presented by Ludovic Poitou of ForgeRock, on the OpenDJ directory server project and its origins as OpenDS at Sun Microsystems:

 

One thing I found of particular interest (and also because I can’t resist yet another dig at Oracle – but only because they make it so very easy) comes right at the end of the presentation (here), which not only indicates that code commits to the OpenDS project which Oracle inherited are practically dead (i.e. death by neglect), but that in June 2011 they actually created a proprietary fork of it (gee, imagine that!), called “Oracle Unified Directory”.

It’s great to see that out of the two forks of OpenDS at least that I am aware of (the other is here), OpenDJ remains truly open, from the code to the documentation. No need to “contact sales” nor have to deal with a crummy “evaluation license”.

And if you need professional support, ForgeRock offer that too.

More PAM, LDAPS, and Policykit weirdness in Ubuntu 10.04 x86

Continuing on from http://blog.davekoelmeyer.co.nz/2011/11/19/pam-ldaps-and-policykit-weirdness-in-ubuntu-10-04-x86/, the second problem I have encountered with my test LDAP how-to is when LDAP users attempt to use a Policykit enabled application and have their otherwise valid credentials rejected.

In OpenDJ, my LDAP accounts are assigned the gidNumber attribute value of 119, which would place them into the admin group on Ubuntu and consequently allow them to make use of sudo and other applications requiring elevated privileges. Works great, except when using an application such as Ubuntu Software Center which makes use of Policykit.

Note that this is encountered when LDAP authentication is carried out regardless of whether SSL (LDAPS) is configured or not, but if it is then you have the added bonus of the local administrator account not being able to authenticate either…

My bug report may be found at this link:

https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/892680

PAM, LDAPS, and Policykit weirdness in Ubuntu 10.04 x86

Regarding my how-tos on using LDAP as a naming service for Ubuntu clients here and here, I seem to have bumped my head against an unusual and obscure scenario where if LDAP authentication has been configured with SSL, authenticating to Policykit-enabled applications as local administrator appears to break.

This has the weird effect of valid administrator credentials being rejected by applications such as Ubuntu Software Center – even though the same credentials can be used to log in to the system, with sudo on the command line, and in other applications that don’t use Policykit such as Synaptic Package Manager.

I have filed a bug report at the following link for reference:

https://bugs.launchpad.net/ubuntu/+source/policykit-1/+bug/892480

Secure (SSL) LDAP authentication between OpenDJ and Ubuntu

A quick update to my post here regarding using OpenDJ as an LDAP authentication service for Ubuntu 10.04 clients.

A commenter asked how to enable secure LDAP with this configuration, so what follows is a quick and dirty guide which explains how I got this working using SSL on my setup. This is only intended for testing purposes.

A couple of changes should be noted however: First, I am now using OpenDJ 2.4.2 (as opposed to 2.4.1), and second I am running OpenDJ on Ubuntu 10.04 x86 as well in this example (i.e. same OS for server and client).

 

1) Export the OpenDJ server certificate in PEM encoded file format

During setup of our test OpenDJ server, we elected to generate a self-signed certificate for secure LDAP connectivity. We need to export this certificate in a format that ultimately will be installed in our Ubuntu client, such that it can trust the OpenDJ server for secure authentication.

We use the Java keytool utility to do this. More on keytool may be found here: http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html

In the case of my sample OpenDJ server, the OpenDJ Java keystore file (which contains the certificate) is found at /opt/OpenDJ/config/keystore

We can then use the keytool command to export the self-signed certificate in the keystore as a PEM encoded certificate file. In my example there is no password for the keystore, so when promtped one can just press Enter without providing a password. The alias refers to the particular certificate as referenced in the keystore file, which for a self-signed certificate in a default OpenDJ installation is named server-cert. Finally we are exporting the certificate to the Desktop as opendjserver.pem:

$ keytool -keystore /opt/OpenDJ/config/keystore -export -alias server-cert -rfc -file ~/Desktop/opendjserver.pem
Enter keystore password:  

*****************  WARNING WARNING WARNING  *****************
* The integrity of the information stored in your keystore  *
* has NOT been verified!  In order to verify its integrity, *
* you must provide your keystore password.                  *
*****************  WARNING WARNING WARNING  *****************

Certificate stored in file </home/dave/Desktop/opendjserver.pem>

 

If you like, you can view the contents of a certificate by also using the keytool command. To view the certificate generated in the above step for example:

$ keytool -printcert -v -file opendjserver.pem 
Owner: CN=opendjserver, O=OpenDS Self-Signed Certificate
Issuer: CN=opendjserver, O=OpenDS Self-Signed Certificate
Serial number: 
Valid from: Sat Sep 10 00:34:27 NZST 2011 until: Mon Sep 09 00:34:27 NZST 2013
Certificate fingerprints:
	 MD5:  
	 SHA1: 
	 Signature algorithm name: SHA1withRSA
	 Version: 3

 

2) Copy the certificate to the Ubuntu client

We simply copy this certificate to the test Ubuntu VM and place it at /usr/share/ca-certificates

We also want to make the certificate owned by root and world readable:

$ ls -al opendjserver.pem 
-rw-r--r-- 1 root root 731 2011-09-15 17:03 opendjserver.pem

 

3) Modify the client LDAP configuration file

We now make some modifications to /etc/ldap.conf. There are many options which can be set or uncommented, however, I have found that only the below two modifications need to be made to an otherwise unmodified file in its default state. This is especially noteworthy considering that entries such as “#ssl on” apparently do not need to be uncommented.

First, specify a secure LDAP URI. In our example, OpenDJ running on the server named opendjserver is being accessed securely over port 1636:

# Another way to specify your LDAP server is to provide an
uri ldaps://opendjserver:1636

(Note that if you are using a server host name instead of an IP address, and you are not running DNS, you will need to modify /etc/hosts so that the server hostname is pointing to the server IP address.)

 

Next, point to the server certificate. Create the following entry:

TLS_CACERTFILE /usr/share/ca-certificates/opendjserver.pem

 

3) Test connectivity

From the command line on the client we can see if we can retrieve account information for LDAP users:

$ id dave
uid=1001(dave) gid=119(admin) groups=119(admin)
$ 
$ getent passwd dave
dave:*:1001:119:Dave Koelmeyer:/home/dave:

(Note that if testing in this way it may be useful to uninstall nscd if it has been installed beforehand – as it may have cached successful lookups leading to potentially misleading results if something isn’t working as it should.)

That should be it, and you should now have a basic setup that securely authenticates host logins to the system.

Thunderbird 3.1 on Ubuntu 10.04 segfaults on launch with LDAP users

Quick post – I have an Ubuntu 10.04 system configured to authenticate LDAP users. I found that after installing Thunderbird, LDAP users cannot launch the application without it crashing with a segmentation fault instead.

Turns out this is a known and widespread issue, and the workaround (which worked in my case) is to install nscd.

This thread has some more detail: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/571308