How to disable SSL on Sun Directory Server?

I got a call from my customer asking how to manually disable the SSL on his faulty Directory Server.

Edit dse.ldif. Locate dn: cn=config:

nsslapd-security: on
nsslapd-secureport: 636

Solution:

1. Stop Directory Server

2. Remove the above 2 lines

3. Add the following line:

nsslapd-security: off

4. Start Directory Server

Done!

.

Why a Directory Consumer is not read-only? - Part II

Continue from my previous post ...

Master: ds-master.singapore.sun.com:389
Consumer: ds-slave.singapore.sun.com:1389


Let's perform a modification operation on the Consumer. I modified the entry for CLow2.

Below is what you'll observe in the access log of the Consumer:


[20/Jul/2010:02:26:28 +0800] conn=0 op=99 msgId=2098 - MOD dn="uid=CLow2,ou=People,dc=singapore,dc=sun,dc=com"
[20/Jul/2010:02:26:28 +0800] conn=0 op=99 msgId=2098 - RESULT err=10 tag=103 nentries=0 etime=0

The consumer rejects modification operation (err=10). It kicks started the referral process to redirect the MOD request to the master.

Below is what you'll observe in the access log of the Master:

[20/Jul/2010:02:26:28 +0800] conn=63 op=1 msgId=2100 - MOD dn="uid=CLow2,ou=People,dc=singapore,dc=sun,dc=com"

[20/Jul/2010:02:26:28 +0800] conn=63 op=1 msgId=2100 - RESULT err=0 tag=103 nentries=0 etime=0

The master process the modification request successfully (err=0).

Below is the dse.ldif file on the Consumer:

dn: cn="dc=singapore,dc=sun,dc=com",cn=mapping tree,cn=config

objectClass: top

objectClass: extensibleObject

objectClass: nsMappingTree

cn: "dc=singapore,dc=sun,dc=com"

nsslapd-backend: userRoot

nsslapd-referral: ldap://ds-master.singapore.sun.com:389/dc%3Dsingapore,dc%3Dsun,dc%3Dcom

nsslapd-state: referral on update

modifiersName: cn=server,cn=plugins,cn=config

modifyTimestamp: 20090923115909Z

numSubordinates: 1

Below is the dse.ldif file on the Master:

dn: cn="dc=singapore,dc=sun,dc=com",cn=mapping tree,cn=config

objectClass: top

objectClass: extensibleObject

objectClass: nsMappingTree

cn: "dc=singapore,dc=sun,dc=com"

nsslapd-state: backend

nsslapd-backend: userRoot

.

Why a Directory Consumer is not read-only?

This is an interesting question.

In my customer's environment, he has a pair of Sun Directory Servers acting as Masters. The data in the pair is kept in-sync via Multi-Master Replication (MMR).

There are 4 Sun Directory Servers acting as consumers. The data are replicated from the 2 Masters.

Recently, he found out that when he modifies entries on any of the Consumers, the modified entries are updated to the Masters!

This violates the concept of a Consumer, according to what he understands of the term.


Well, let's take a close look at the following diagram:

The diagram illustrates a Master-Consumer deployment architecture. 

Did you notice there is a dotted arrow pointing from the Consumer back to the Master? This is the Referral that is causing the "side-effect". 

Ok, it's not "side-effect". It's a product feature of Sun Directory Server. 

Whenever there is a modification request on the Consumer, the Referral will redirect the request back to the Master. The Master will be the one that actually updates the entries. The Consumer can never process a modification request, it can only perform a search request. 

.

OpenSSO Multi-Servers Mode

There are at least 2 data stores in OpenSSO - Configuration and User data stores.

The older version of OpenSSO, which is Sun Java System Access Manager, does not utilize an embedded Configuration Data Store. As such, we usually utilize the same Sun Java System Directory Server to store both the configuration and users information. (unless, the users information are stored in Active Directory)

In OpenSSO, OpenDS is embedded to store Configuration information. It comes pre-installed with every OpenSSO bundle.

In fact, the recommended deployment approach is not to change this embedded data store.

Using the OpenSSO Enterprise embedded configuration data store can lower response time and ensure service availability when machine failure occurs.

What I like about this embedded data store is: if you scale by adding another node, there is nothing you need to do to ensure the configuration information are replicated and always in-sync. Replication is taken care of, transparently.

Nice!

.

OpenSSO Authentication and Authorization Interactions

While refreshing myself with OpenSSO, I came across this diagram that illustrates very clearly how OpenSSO and Policy Agent operates in a Access Control environment.

I love diagram that is simply, yet tells a complete story of a product's capability.

.

How to reset DSCC Directory Service Manager password?

I was with a customer the other day. He has another Sun Directory Server setup by another vendor long time ago. He attempted to login to DSCC, but he was not able to remember the "admin" (Directory Service Manager) password.

Some forums I searched talked about resetting the Service Manager password via the DSCC console. What a joke! :) I can't even login, how am I able to reset password via DSCC console?

Changing password via DSCC console

There are 2 ways to resolve this issue:


1. To dismantle and initialize DSCC again

bash-3.00# ./dsccsetup dismantle
:
bash-3.00# ./dsccsetup initialize
:
Registration is on-going. Please wait...
DSCC is registered in Sun Java(TM) Web Console
:
DSCC agent has been successfully registered in Cacao.
***
Choose password for Directory Service Manager:
Confirm password for Directory Service Manager:
Creating DSCC registry...
DSCC Registry has been created successfully
***

Simple. But of course, previous configuration of registered servers are gone. You need to register again.



2. Change password via CLI

Some basic concepts first.

bash-3.00# ./dsccsetup status

***

:

DSCC Registry has been created

Path of DSCC registry is /var/opt/SUNWdsee/dscc6/dcc/ads

Port of DSCC registry is 3998

***

• DSCC configuration are stored in a LDAP database at port 3998
• Service Manager is known as cn=admin,cn=Administrators,cn=dscc in this LDAP database (see screenshot above)
• "cn=Directory Manager" credential is required to modify the Service Manager password 
• The funny thing is the default password for "cn=Directory Manager" is the same as Directory Service Manager. (see dsccsetup initialize above. the steps are so simple. it assumes both to have the same password) 

So we need to perform 2 steps:


Step 1 - Change the Directory Manager password


bash-3.00# /opt/SUNWdsee/ds6/bin/pwdhash -D /var/opt/SUNWdsee/dscc6/dcc/ads -s SHA password2
{SSHA}qFcXDQCKZ4u4GyrM8Uw4uGOHdsnVPP9MaC0WeQ==


bash-3.00# cd /var/opt/SUNWdsee/dscc6/dcc/ads/
bash-3.00# ./stop-slapd
bash-3.00# cd /var/opt/SUNWdsee/dscc6/dcc/ads/config
bash-3.00# cp dse.ldif dse.ldif.OLD
bash-3.00# vi dse.ldif
At dn: cn=config
Replace:
nsslapd-rootpw: {SSHA}guaZfnFtTHeT8EpWpBhuRlBCMLWpdgt0tBvfBw==
with:
nsslapd-rootpw: {SSHA}qFcXDQCKZ4u4GyrM8Uw4uGOHdsnVPP9MaC0WeQ==


bash-3.00# ./start-slapd



Step 2 - Change the Service Manager password

bash-3.00# ldapmodify -p 3998 -D "cn=Directory Manager"
Enter bind password:
dn: cn=admin,cn=Administrators,cn=dscc
changetype: modify
replace: userPassword
userPassword: password2 <-- Rest assured. This password will be hashed during modification.


modifying entry cn=admin,cn=Administrators,cn=dscc


Done!

.

DSCC deployment with firewall

In a production environment, there are always firewalls. This is for sure.

Below is a typical deployment of a pair of Sun Directory Servers deployed in 2 data centers. They are configured for Multi-Master Replication (MMR).

This deployment is simple. Only port 389 (bi-directional) is required to be enabled on the firewall.

Now, if the Administrators are all stationed in Data Center 1 where DS 1 is and they would like to manage all Directory Servers via DSCC (Directory Server Control Control), we have a challenge.

We need to understand how DSCC, Cacao and Directory Server works.

Basically, DSCC manages Directory Server instances through Cacao agent. On each physical server where Directory Server is installed, we need a Cacao agent installed as well. This agent runs on port 11162 by default.

Now, if we make changes to the Directory Server configuration, there is a need to update the DSCC registry. This ensures the states are kept intact. DSCC registry runs on port 3998 and 3999 (SSL) by default.

So, what do we need to configure on the firewall?

1. Port 11162 (uni-directional) from DS1 to DS2
2. Port 3998 and 2999 (uni-directional) from DS2 to DS1
3. Port 636 (bi-directional) <- for starting/stopping Directory Server via DSCC (Thanks, Teck Meng!)

.

Bind to specific IP address for Sun Directory Server

Some customers have powerful machines. It would be a waste to install a single instance of Sun Directory Server on each machine.

When you have more than 1 instance of Directory Server running, you'll end-up having the following architecture most of the time. Port 389 will be assigned to the 1st instance; while Port 1389 will be assigned to the 2nd instance.

Some application developers do not like to use port other than 389. Or corporate policy does not encourage that. I have encountered customers who dictate Directory Service to be only served via port 389, and nothing else.

So, we'll end up having to redesign the architecture to be the one shown below:

Now, the prerequisite is that the machine has to either support multi-home or have more than 1 NIC interface. This is to ensure that port 389 will not clash when both instances attempt to start.

In addition, we need to add the following entries into the dse.ldif for DS1 and DS2.

nsslapd-listenhost: ip-address-[1,2]
nsslapd-securelistenhost: ip-address-[1,2]


Remember to stop DS first; add entries; start DS.


Note: By default, both entries are missing from dse.ldif, which implies 0.0.0.0 is taken as default value.


.