Setting up LAM Pro with SELinux

Been a while since I had to install LAM Pro and now that I have the new version, I ran into a couple of issues. First there is SELinux, which has saved my butt a couple of times, so I work to always have it enabled. I cringe whenever I see the first step in someone’s howto is to disable it. Its complicated and I do not profess to be anywhere near an expert in it, but I get by. Second is to secure the install, and while SELinux helps in that regard, there are still steps to take.


LAM Pro is the paid version of LAM, LDAP Account Manager. Starting with a fresh install of CentOS 6.4, I downloaded the LAM Pro source and use its install script:

# ./configure --with-httpd-user=apache \
              --with-httpd-group=apache \
# make install

By default it will install everything into /usr/local/lam and use httpd as user/group name. Here I fix that to use the CentOS default of apache as user/group. Also it’s recommend to separate the web interface from the more sensitive parts, like the config files and session information.

SELinux Configuration:

If you were to start up a browser to load up LAM, even with SELinux disabled, there is the issue of writing config files. They are stored in /usr/local/lam/etc, where the web server doesn’t have permission. Also there is the session and tmp directory in var it uses to cache data from ldap. So use chmod to fix that:

# chmod -R apache:apache /usr/local/lam/etc
# chmod -R apache:apache /usr/local/lam/var/sess
# chmod -R apache:apache /usr/local/lam/var/tmp

But with SELinux enabled, apache still doesn’t have permissions to write outside of its own root directory. We need to tell the system the right context to use to allow apache access.

# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/var(/.*)?"
# semanage fcontext -a -t httpd_sys_content_t "/usr/local/lam/etc(/.*)?"

Next is to apply these settings to the files themselves:

# restorecon -R /usr/local/lam/var
# restorecon -R /usr/local/lam/etc

Now apache can run LAM with SELinux enable and not run into any issues.

Apache Configuration:

The next part is to secure the installation. LAM comes with htaccess files ready to use to protect the config files and other sensitive files. Its my preference and you can do it differently, but I start with creating /etc/httpd/conf.d/lam.conf to hold these directives.

<Directory /var/www/html/lam>
   AllowOverride All

Now you could just change the server wide setting in httpd.conf, but I like to follow the principle of least privilege.

Next would be to set it up to use SSL to keep prying eyes from grabbing your passwords and user information, but that’s a whole other topic.


CentOS 6.4: NSS, MD5 Certificates, and Authentication Problems: UPDATE

In tinkering with setting up a kickstart script to get a basic workstation installed just like I want I decided to revisit the authentication issue related to certificates with an MD5 signature. Thankfully there is a workaround to enable MD5 support in the nss package that worked for me. Simply add ‘export NSS_HASH_ALG_SUPPORT=+MD5’ to /etc/sysconfig/init and reboot. Thanks go to @NewLifeMark and this blog posting.

CentOS 6.4: NSS, MD5 Certificates, and Authentication Problems

CentOS just released 6.4, so I decided to update the office server and as it was the end of the day, left it at that. Bad form on my end as I come in the next day to find I’m unable to connect to the samba server. Checking the logs I see samba is unable to connect to LDAP via TLS. I also quickly discover that the server itself is unable to get user information. First guess was to check the ldap server, but its running fine.

Second guess is to try ldapsearch from the office server and I get my first hint. Ldapsearch was not accepting my Certificate Authority and was giving a bad signature algorithm error. Researching that lead me to the following bug report: Unable to authenticate to legacy LDAP server due to “not secure” certificate signature.

It becomes clear that due to the decision at Mozilla, who develop the NSS(Network Security Services) library to stop accepting MD5 hashes is the root issue. I then set out to downgrade NSS to pre 6.4 release. The following packages were the ones I downgraded to get my system working again: nss nss-sysinit nss-tools nss-util nss-pam-ldapd mod_nss.

Now some may ask why not just upgrade your certificates to a newer and thus more secure signing algorithm? Well to anyone who has ever worked with OpenSSL and creating certs for a multitude of servers, its not a trivial task. I’ll put it on my todo list, but for now its at the bottom.

Thanks to following blog post by Matt Micene that was the break in this case.

Setting up Git on Apache+SSL+LDAP

I used the following post as a way to get things started.

Setup your repos. Adding the EPEL repo to CentOS will knock out some base packages, so as a rule, its good to setup priorities, but thats not part of this howto and can be found here. Anyways install git.

I decided to place the repository within /var/www/html simply because its my preference, but it could go anywhere.

mkdir -d /var/www/html/git/project

cd /var/www/html/git/project

git —bare init

Then I set the permissions so the webserver has ownership:

chown -R apache:apache /var/www/html/git

Then run update-server-info:

sudo -u apache git update-server-info

Next is to configure apache. Remember to have your SSL certs prepared before hand. Also each distro is different in how it lays out the apache configuration, especially in regards to extra modules like SSL and WebDAV. Consult your documentation.

First I make sure I have the modules I need set to load, such as SSL, WebDAV, and ldap(authz). I want all traffic to be encrypted so I set it to route all http requests to https:

<VirtualHost *:80>
        Redirect permanent /

Also I’m using LDAP with TLS so Apache needs to know the CA cert:

LDAPTrustedGlobalCert CA_BASE64 /path/to/cacert.pem

On a side note, its good to protect your webserver by hiding the version numbers via:

Servertokens ProductOnly
ServerSignature Off

Then I setup ssl, which for my system, its in /etc/httpd/conf/extra/httpd-ssl.conf I then setup the following virtual host:

<VirtualHost _default_:443>

ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log

SSLEngine on
SSLProtocol all -SSLv2
SSLCertificateFile /path/to/server-cert.pem
SSLCertificateKeyFile /path/to/server-key.pem
SSLCACertificateFile /path/to/cacert.pem
<Directory /var/www/html/git/>
        DAV On
        Options ExecCGI FollowSymLinks Indexes
        Deny from all
        AuthType Basic
        AuthName “Git Repository”
        AuthBasicProvider ldap
        AuthzLDAPAuthoritative on
        AuthLDAPURL “ldap://,dc=example,dc=com?uid” TLS
        AuthLDAPBindDN cn=binduser,ou=DSA,dc=example,dc=com
        AuthLDAPBindPassword password
        AuthLDAPGroupAttribute memberUid
        AuthLDAPGroupAttributeIsDN off
        Require valid-user

<Directory /var/www/html/git/project>
        Allow from all
        Order allow,deny
        <Limit GET>
                Require ldap-group cn=groupname,ou=group,dc=example,dc=com
                Require ldap-group cn=groupname,ou=group,dc=example,dc=com

Here authentication is handled by Apache against LDAP, which in our case is very nice as all our user information is in LDAP. Next on the client side you’ll have to set the username and password and the certificates.

To set the username/password for git to use, create a file in your top level home directory called .netrc and add the following:


login username

password password

Then to setup the certificates, download the CA cert and place somewhere, like ~/.certs. Then it must be in the x509 format, this can be down via the following:

openssl x509 -in cacert.pem -out cacert.crt

Then tell git to use this via:

git config —global http.sslcapath .certs/

git config —global http.sslcainfo .certs/cacert.crt

Now you should have a working git repository password protected and encrypted in transit.

LDAP Crash and Recovery

So it looks like I’m running out of memory on our ldap machine, not sure why but the kernel’s oom-killer then takes out slapd, the ldap server daemon. This can leave, and in this morning’s case, the backend database in a dirty state and thus unable to load. 

Checking configuration files for slapd: bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.

Luckily I wasn’t the only one who had this problem and found a solution in this blog post.

[root@ldap]# /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
Finding last valid log LSN: file: 1 offset 5315883
Recovery starting from [1][5315755]
Recovery complete at Sun Jul 30 11:31:56 2006
Maximum transaction ID 8000040d Recovery checkpoint [1][5315883]