среда мар 28, 2007

SSL setup from CLI

The following text is based on the documentation from http://docs.sun.com/source/816-6698-10/ssl.html

This is something I never had an opportunity to do often, but whenever I did, I had to dig throughout heaps of notes and documents to find what I needed. Namely, if you want to set up Directory Server 5.2 for testing/piloting/playing purposes, SSL would definitely be something you would want to play with. However, not having certificate authority to generate certificates would certainly make it a lot harder for you to get the basic setup up and running.

Thing to be done first is to create the certificate database for DS by using certutil:

certutil -N -d ServerRoot/alias -P slapd-ServerID- 

Now we need to make a certificate request:

certutil -R -s "cn=serverName,ou=division,o=company,l=city,st=state,c=country" -a -d ServerRoot/alias -P slapd-serverID- -o cert.req

This will save the certificate request into file cert.req. At this point you should send the file to your certificate authority to sign it and to produce the actual certificate. Apart from the certificate for the server, the CA has to provide you root certificate of it's own and/or certificate chain so you could trust it. Importing is as follows:

certutil -A -n "certificateName" -t "u,," -a -i certFile -d ServerRoot/alias -P slapd-serverID- 

and for root CA:

certutil -A -n "CAcertificateName" -t "trust,," -a -i certFile -d ServerRoot/alias -P slapd-serverID-

where trust is one of the following:

  • T - This CA is trusted to issue client certificates. Use this code if your LDAP clients perform certificate-based client authentication by presenting certificates issued by this CA.
  • C - This CA is trusted to issue server certificates. Use this code if your server will play a replication supplier or chaining multiplexor role over SSL with another server that has a certificate issued by this CA.
  • CT - This CA is trusted to issue both client and server certificates. Use this code if both cases above apply to this CA.

In case you are playing with a test server and you do not have a CA, you can create a self-signed certificate and use it as CA:

certutil -S -x -s "cn=CA" -n ca -t "TC,,," -1 -2 -5 -d ServerRoot/alias -P slapd-serverID-

In case the certificate request file is not in ASCII format (as it should be if the above command was used to generate it) then from the following command -a should be removed:

certutil -C -a -i cert.req -o node1.crt -c ca -d ServerRoot/alias -P slapd-serverID-

Now you can add the generated certificate:

certutil -A -i node1.crt -n server -t "P,P,P" -d ServerRoot/alias -P slapd-serverID-

At this point, SSL database should be ready to be used. Next thing to follow is to reconfigure DS to use SSL. Edit DS configuration to enable SSL either by manually chaning dse.ldif or by LDIF. If you chose to edit dse.ldif file do not forget to shut down DS first! Either way, the LDIF file should look like this:

dn: cn=config
changetype: modify
nsslapd-security: on

dn: cn=encryption,cn=config
changetype: modify
nsSSL3: on
nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,
nsKeyfile: alias/slapd-nis-key3.db
nsCertfile: alias/slapd-nis-cert7.db

dn: cn=RSA,cn=encryption,cn=config
changetype: add
nsSSLToken: internal (software)
nsSSLPersonalitySSL: server-cert
nsSSLActivation: on
objectClass: top
objectClass: nsEncryptionModule
cn: RSA

In order for DS to start automatically you need to edit ServerRoot/alias/slapd-serverID-pin.txt and put the following content:

Internal (Software) Token:password

Now you can start your DS service. From now on DS should be listening also for SSL connections. It is important to note that the approach with self-signed certificates would work only with a single DS instance. For multiple instance s you would have to export CA certificate and import it to other DS instances. This is easily achievable with pk12util. For example:

pk12util -d ServerRoot/ -P slapd-nis- -o ca.crt -n ca

уторак мар 27, 2007

Indexing via CLI

In regards to the previous post, another task that you would want automated is indexing. Although reindexing is not an bigger issue, adding new indexes might be more tricky if you don't have GUI. With Sun Java System Directory Server 6.0 is not such an issue since it comes with nice CLI tools, but version 5.2 requires reconfiguring using LDIF if the GUI is not available. The actual LDIF is quite simple:

dn: cn=$ATTRIBUE,cn=index,cn=$BACKEND_DB,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: nsIndex
nsIndexType: pres
nsIndexType: eq
nsIndexType: sub
nsSystemIndex: false

$ATTRIBUTE - name of the attribute that you want to have indexed;

$BACKEND_DB - backend database which holds the suffix which will be indexed, e.g. by default backend database is "userRoot" for the root suffix;

nsIndexType - specifies the type of the index - it could be: pres(ence), eq(uality), sub(string) and approx(imate). If nsIndexType is left empty, it means all index types would be created for this attribute.


In response to Ludovic's comment below, I need to add a few notes. As Ludovic mentioned, and I failed stress it, this will only configure the indexes without actually creating them. The reindexing is easily performed from the CLI by running db2index\* tool, hence no additional toying with LDIF is needed.

Thanks for drawing my attention!

понедељак мар 26, 2007

MMR setup from CLI

Quite often I was in position which required automated configuration of multi-master replication on Sun Java Systems Directory Server 5.2, but I never got the chance to properly document it in a cheat-sheet form for the future reference.

If we would assume we have two DSAs, the process would be the following:

  • on both servers
    1. enable changelog on both servres;
    2. configure replication settings;
    3. set replication manager password;
    4. create replication agreements, and
  • on the primary master
    1. initialise the secondary master.

Here are the LDIF templates for each of the steps:

  • enabling changelog:

    dn: cn=changelog5, cn=config
    changetype: add
    objectclass: top
    objectclass: extensibleObject
    cn: changelog5
    nsslapd-changelogdir: $PATH_TO_CHANGELOG_DB

    $PATH_TO_CHANGELOG_DB - filesystem path where changelog database should be kept

  • replication settings:

    dn: cn=replica, cn=$SUFFIX, cn=mapping tree, cn=config
    changetype: add
    objectclass: top
    objectclass: nsDS5Replica
    cn: replica
    nsDS5ReplicaRoot: $SUFFIX
    nsDS5ReplicaID: $REPLICA_ID
    nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=config
    nsDS5Flags: 1
    nsDS5ReplicaType: 3
    nsDS5ReplicaPurgeDelay: 604800

    $SUFFIX - directory suffix which is being replicated $REPLICA_ID - unique integer value for each master, e.g. 1 for primary, 2 for secondary, etc. NOTES: "nsDS5ReplicaType: 3" configures this DSA as a replica master, while "nsDS5Flags: 1" regulates creation of changelog db.

  • replication manager password:

    dn: cn=Replication Manager, cn=replication, cn=config
    changetype: modify
    add: userPassword
    userpassword: $PASSWORD

    $PASSWORD - password which has to be used by the other masters in topology

  • replication agreement:

    dn: cn=$REP_AGREEMENT_NAME, cn=replica, cn=$SUFFIX, cn=mapping tree, cn=config
    changetype: add
    objectclass: top
    objectclass: nsDS5ReplicationAgreement
    description: $DESCRIPTION
    nsDS5ReplicaRoot: $SUFFIX
    nsDS5ReplicaHost: $DESTINATION
    nsDS5ReplicaPort: 389
    nsDS5ReplicaBindDN: cn=Replication Manager, cn=replication, cn=config
    nsDS5ReplicaCredentials: $PASSWORD
    nsDS5ReplicaBindMethod: SIMPLE

    $REP_AGREEMENT_NAME - short name to distinguish this agreement from other agreements $DESCRIPTION - brief description of the agreement $SUFFIX - directory suffix being replicated $DESTINATION - fully qualified domain name of the destination machine that recieves replication data $PASSWORD - password set for the replication manager on the destination machine

  • initialising the secondary master:

    dn: cn=$REP_AGREEMENT_NAME, cn=replica, cn=$SUFFIX, cn=mapping tree, cn=config
    changetype: modify
    replace: nsDS5BeginReplicaRefresh
    nsDS5BeginReplicaRefresh: start

    $REP_AGREEMENT_NAME - short name to distinguish this agreement from other agreements $SUFFIX - directory suffix being replicated


Publishing quirks of Sun software popped up during integration.


« јул 2016