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.

Saturday, July 17, 2010

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.

Friday, July 9, 2010

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)

Thursday, July 8, 2010

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.

Wednesday, July 7, 2010

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.