You are currently browsing the category archive for the ‘LDAP’ category.

The Howto:MultiMasterReplication wiki page for the 389 Directory Server documents use of the mmr.pl script for setting up replication.

The mmr.pl --with-ssl option is used to setup SSL for replication. I have seen a couple of postings on various forums that the script hangs when using --with-ssl option. That happened to me as well at first. I haven’t seen any answers on how to resolve this so I posting my patch to the script. (Maybe someone will submit it to the script’s maintainer, I’m too lazy. Update 1/14/2011: the maintainer, Rich Megginson, accepted the patch so refer to his repository for the latest version.)

The problem is that in the current version of the script the --with-ssl option also sets the port used for connections – port 636 by default. Just setting the port to 636 is not sufficient to inform the script’s underlying Net::LDAP perl library that SSL communication is expected. Specifying a ldaps scheme with the host name triggers the required SSL support in Net::LDAP.

So, I prepended ldaps:// to the server in each occurrence of Net::LDAP->new(). For example,

my $ldap = Net::LDAP->new(“ldaps://$server”, port => $prt) || die “$@”;

(full source is provided below)

Note that the --with-ssl servers two purposes. One is to tell the script to configure the directory to use SSL for all future replication transactions. That is, the communication between the two directory servers will be encrypted. The other action of --with-ssl is to encrypt the communications the script makes to each directory server during the setup and querying (the Net::LDAP business we just resolved). So, you will also want to use both the --with-ssl option for the script’s other subcommands, such as --display and --remove so those communications are consistently held over secure channels.

Related:

Another MMR setup script. I’ve not used it.
Read the rest of this entry »

Advertisements

Having successfully enabled Hudson security with authentication against an LDAP server, I wanted to tweak the configuration to use a secure connection.

I tried using the ldaps scheme, ‘ldaps://ds1.crashingdaily.com’, as per the inline documentation but was confronted with the error “Syntax of this field is SERVER or SERVER:PORT”. I puzzled over this message for awhile, triple checked the syntax, consulted the support forums and then the source code to confirm that the syntax was indeed supported. Finally, I ignored the error, saved the configuration and tried a login. Then Hudson spit out a helpful exception in its Tomcat log:

hudson.security.AuthenticationProcessingFilter2
onUnsuccessfulAuthentication
INFO: Login attempt failed
org.acegisecurity.AuthenticationServiceException: Unable to connect to
LDAP server; nested exception is javax.naming.CommunicationException:
simple bind failed: ds1.crashingdaily.com:636 [Root exception is
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target]; nested exception is
org.acegisecurity.ldap.LdapDataAccessException: Unable to connect to
LDAP server; nested exception is javax.naming.CommunicationException:
simple bind failed: ds1.crashingdaily.com:636 [Root exception is
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to
find valid certification path to requested target]
	at
org.acegisecurity.providers.ldap.LdapAuthenticationProvider.retrieveUser
(LdapAuthenticationProvider.java:238)

The key phrase to me there was ‘unable to find valid certification’. I suspected the Java classes used to negotiate the ldap connection were balking at my self-signed certificate coming from the ldap server. This wasn’t really a failure of Hudson specifically but rather a common issue for many language libraries and SSL applications. Typically the solution is as simple as pointing the library and/or application at the Certificate of Authority (CA) that was used to self-sign the server’s SSL cert. A quick Google search turned up sufficient information for me to import our CA into a keystore for Tomcat’s JVM.

For starters, I made a copy of the cacerts that ships with the JDK. This keystore contains a set of common, trusted CA certs. I don’t need them for Hudson but they may come in handy for future use.

$ cp $JAVA_HOME/jre/lib/security/cacerts /usr/local/tomcat/conf/

Now, I need to get the CA certificate for the ldap server. I have that file around here somewhere but rather than digging it up it’s simple to just get it from the ldap server using openssl.

$ openssl s_client -connect ds1.crashingdaily.com:636 -showcerts

This openssl command prints a list of certificates from the server, the last certificate is the CA. I copy that last certificate to a file, my-ca.crt, and import it into the cacerts keystore.

$ $JAVA_HOME/bin/keytool -import -alias myca -keystore cacerts \
-trustcacerts -file my-ca.crt

The -alias is not too important, it just has to be unique in the keystore. You can list the keys in the store with

$ $JAVA_HOME/bin/keytool -list -keystore  cacerts

Then I add a system property for Tomcat’s JVM that specifies the trustStore as my new cacert. For example, this can be added to the CATALINA_OPTS environment variable if you use the catalina.sh script that ships with Tomcat.

-Djavax.net.ssl.trustStore=/usr/local/tomcat/conf/cacerts

I restart the Tomcat instance for my Hudson installation and now Hudson is able to authenticate over a secure channel.

Related:

Apache Tomcat 5.5 SSL Configuration HOW-TO
Troubleshooting javax.net.ssl.SSLHandshakeException

Enabling security to my Hudson installation was a fairly straight-foward task although it did take a little trial and error to get it all straight. I chose to authenticate against our existing LDAP directory. One of the things that caught me off guard at first was the ‘User search base’ and ‘Group search base’. These settings are Relative Distinguished Names (ou=People), not the full Distinguished Name (ou=People,dc=crashingdaily,dc=com). Not a big deal; in fact I could have (should have, but I like to tinker) just left these fields empty and Hudson would have figured it out on its own.

Here is my almost final configuration (my final configuration makes use of StartTLS for a secure connection to the LDAP server – more on that in a later post).

hudson_ldap.gif

The Manager DN is an account that has read-only search permissions. This is required because our LDAP directory is not searchable with anonymous binds.

The LDAP group configuration took me a bit more effort and debugging. I have an HudsonAdmin LDAP group in my directory. The DN for it is cn=HudsonAdmin,ou=Groups,dc=crashingdaily,dc=com

To get this work I had to upgrade to the 1.261 release which adds uniqueMember, memberUid to the existing member in the search filter (my HudsonAdmin group has ‘uniqueMember’ entries). Incidentally, one of the things I love about Hudson is when I run into a bug or missing feature I can usually count on it be addressed in a newer release – and upgrading to a new release is quick and painless.

A not-so-obvious aspect to the configuration is that, when adding an LDAP group, Hudson wants the group name in all uppercase and with ‘ROLE_‘ prefixed to it. So, ‘cn=HudsonAdmin,...‘ becomes ‘ROLE_HUDSONADMIN‘. I did find this requirement documented after a little Google searching, it’s just not spelled out in the admin form’s help.

Tip: When screwing around with your Hudson Authorization, make frequent backups of the working $HUDSON_HOME/config.xml so if you make a mistake and lock yourself out you can restore a working configuration from backup, reload Hudson and be back in business. The Hudson documentation does include a note about recovering from a lockout by setting useSecurity to false in the config.xml file but I find that doing that causes a loss of all your security settings and you’ll have to re-enter all the LDAP values and Authorization settings.

I have some installations of Fedora Directory Server (FDS) running as the user nobody. It is generally preferred that services like FDS run under a dedicated user and certainly not the nobody account. The user is configured during an initial scripted interactive setup but I wanted to change the user for the existing installations. I could not find a how-to for doing this (though did not look very hard) so I did a new installation on a beater box and during setup configured it to run as user ldapperuser and group ldappergroup. I used this installation to experiment with reconfiguring the user.

I shutdown the slapd service and changed ownership of the files owned by ldapperuser and/or ldappergroup.

find /opt/fedora-ds -user ldapperuser | xargs chown ldap
find /opt/fedora-ds -group ldappergroup | xargs chgrp ldap

By grep’ing for the silly user and group names I found these text files needed to be edited to change the user and/or group.

/opt/fedora-ds/admin-serv/config/console.conf 
/opt/fedora-ds/shared/config/ssusers.conf
/opt/fedora-ds/slapd-pepper/config/dse.ldif

I restarted the slapd process and confirmed in a process list that it was running as the new user.

Finally, I exported the entire directory to an ldif file and grep’ed it for the user and group names. There I found that I needed to change the nsSuiteSpotUser attribute in "cn=slapd-pepper, cn=Fedora Directory Server, cn=Server Group, cn=pepper.crashingdaily.com, ou=crashingdaily.com, o=NetscapeRoot"

I made this change to nsSuiteSpotUser via the Admin console.

There may very well be an official way to change the user for an installed FDS but this brute force method is simple enough.

Categories

October 2017
M T W T F S S
« May    
 1
2345678
9101112131415
16171819202122
23242526272829
3031  

Latest del.icio.us