openldap24: schema replica with syncrepl

Store configuration in the directory itself

One of the hot feature of openldap24 is to store configuration in the same ldap directory. Advantages are:

• runtime modification of configuration with ldapmodify without service restart;


• leverage of the syncprov replica of configuration branches, as schema or acl.

To enable storage of configuration in the directory itself, just start slapd with the -F switch, which points to a slapd.d directory, owned by ldap:ldap, usually located ad /etc/ldap/slapd.d (debian):

/usr/local/libexec/slapd -u ldap -g ldap -f slapd.conf -F slapd.d -d-1

(later remove the -f switch; older debian startup scripts do require -f so it could be necessary modify them).

How to replicate schema branch

First of all enable overlay syncprov over cn=config on the master server: this is the needed ldif to achieve that:

dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
olcOverlay: syncprov

Or, if the configuration has not yet been migrated, edit slapd.conf:

database    config
rootpw         {SSHA}WGWXrWf/RG99aVWs3VBMn5nyJGzhCfkS
overlay            syncprov

Than add to master server a acl to enable a user to read cn=config like:

access to dn.subtree="cn=config" by dn="cn=confreplica,dc=example,dc=com" read

slapd.conf on the slave should look:

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include        /usr/local/etc/openldap/schema/core.schema
#core.schema has to be included anyhow
#include        /usr/local/etc/openldap/schema/cosine.schema
#include        /usr/local/etc/openldap/schema/inetorgperson.schema
#include        /usr/local/etc/openldap/schema/openldap.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral    ldap://root.openldap.org

pidfile        /var/run/openldap/slapd.pid
argsfile    /var/run/openldap/slapd.args

# Load dynamic backend modules:
modulepath    /usr/local/libexec/openldap
moduleload    back_bdb
# moduleload    back_hdb
# moduleload    back_ldap

[...] acl go here

loglevel     stats ACL sync

database    config
rootdn        "cn=admin,cn=config"
rootpw         {SSHA}WGWXrWf/RG99aVWs3VBMn5nyJGzhCfkS   
syncrepl        rid=002
    provider=ldap://master.example.com:389
    type=refreshAndPersist
     interval=00:00:10:00
    searchbase="cn=schema,cn=config"
    filter="objectClass=olcSchemaConfig"
    scope="sub"
    binddn="cn=confreplica,dc=example,dc=com"
    bindmethod=simple
    credentials="secret"
# next database sections

Than, migrate configuration on slave from slapd.conf to slapd.d as usual.

SASL/EXTERNAL with openldap

SASL EXTERNAL mechanism allows passwordless authentication with x509 user certificates.

I believe it could prove very useful for replication, where, with simple bind, bind_dn and bind_pw were to be written in cleartext in slapd.conf.

This mechanism is also very handy because it requires encryption to work, and a clear text connection can't work.

Steps are:

• apt-get install libsasl2-modules-ldap on the server;


• modify slapd.conf to use TLS and to try verify peer;


• modify user .ldaprc to include user certificate.

slapd.conf should include:

TLSCACertificateFile  /etc/ssl/certs/ca-cert.pem
TLSCertificateFile /etc/ssl/certs/server.pem
TLSCertificateKeyFile /etc/ssl/private/server.key
TLSVerifyClient try

where server.pem and server.key and server certificate and unprotected key, while ca-cert.pem is the certificate file of the CA under which is issued the client user certificate.

.ldaprc:

TLS_CACERT /etc/ssl/certs/server-ca-chain.pem
TLS_CACERTDIR /etc/ssl/certs
TLS_CERT /home/user/client.pem
TLS_KEY /home/user/client.key
SASL_MECH EXTERNAL

where client.key can be protected or unprotected key and server-ca-chain is cert file of the CA which issued the server cert.

An error like this one:

ldapsearch -x -ZZ -h server.test.com 'uid=user'
ldap_start_tls: Connect error (-11)
 additional info: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca

means the client is using a certificate with a different CA from TLSCACertificateFile.

If everything is in order:

ldapsearch -x -ZZ -H ldap://server.test.com -b "" -LLL -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: EXTERNAL

And it possible to launch:

ldapsearch -ZZ -h server.test.com 'uid=user'

to read in /var/log/ldap.log:

Jan 14 12:08:12 server slapd[15308]: conn=38 op=1 BIND authcid="cn=bacedifo,dc=test,dc=com" authzid="cn=bacedifo,dc=test,dc=com"
Jan 14 12:08:12 server slapd[15308]: conn=38 op=1 BIND dn="cn=bacedifo,dc=test,dc=com" mech=EXTERNAL ssf=0

Upgrade from shibboleth idp 2.1.0 to 2.1.2

This upgrade has proved to be very smooth.

I was scared by the upgrade ad hoc page. Actually it was about upgrade from 2.0 to 2.1 version.

Instead it was enought to download the tar.gz, verify signature, unzip run

sh install.sh

No need to backup configuration data, if you choose not to overwrite it.

It's only needed to build again the link with libraries not included in the war bundle, ad example the jdbc ones:

sudo ln -s /usr/share/java/mysql-connector-java.jar $IDP_HOME/lib/

copy personalized login pages from old source to new source path:

 cp -va shibboleth-identityprovider-2.1.0/src/main/webapp/login.jsp 
 shibboleth-identityprovider-2.1.2/src/main/webapp/

and restart tomcat.

Block ssh connection by IP

The subject is rather lame, as blocking ssh by IP source is really last resource. But sometimes can be handy.

• Modify sshd_config
  Just add in /etc/ssh/sshd_config
  

  
  AllowUsers *@192.169.1.1
  

  
  People non connecting from 192.168.1.1 will be prompted for username and password, but they could try forever as none will work.
  


• Use inetd
  Add in /etc/hosts.deny:
  

  
  sshd: ALL
  

  
  and in /etc/hosts.allow:
  

  
  sshd: 192.169.1.1
  

  
  People outside 192.168.1.1 receive a: ssh_exchange_identification: Connection closed by remote host, while nmap states port 22 as "open".
  


• Use iptables
  Add to INPUT chain, with a default deny, something like:
  

  
  iptables -A INPUT -p tcp -m tcp -s 192.169.1.1/32 --dport 22 --syn -j ACCEPT
  

  
  People outside 192.168.1.1 will have connection hanged, and nmap says port 22 is "filtered".