Directory Server 5.2 patch 6…

As Mark already pointed out, Directory Server 5.2 patch 6 is now available either as a full partial download from the Directory Server Enterprise Edition Download page, or in the form of patches from Sun Solve.

5.2patch6

115610-25 – AS Solaris Sparc Native

115614-28 – DS Solaris Sparc Native

115611-25 – AS Solaris X86 Native

115615-28 – DS Solaris X86 Native

118079-12 – AS Linux Native

118080-13 – DS Linux Native

121392-04 – DS MSI Windows

121529-03 – AS MSI Windows

121393-03 – DS HPUX Native

121515-03 – AS HPUX Native

117665-05 – Solaris SPARC ZIP

117666-05 – Solaris X86 ZIP

117667-05 – Windows ZIP

117668-05 – Linux ZIP

117669-05 – HPUX ZIP

117670-05 – >AIX ZIP

Release notes :

Patch6 Release Notes

Update on October 1st 2007: I stand corrected, DS5.2patch6 is only available as a patch. On the download page, there is also a link to the most recent FULL package on which to apply the patches.

Technorati Tags: , , ,

DSEE 6.2

Sun Java System Directory Server Enterprise Edition 6.2 has been released with Sun Java Enterprise System 5 Update 1 about two weeks ago.

Now the full install and the Zip archives can be downloaded from the DSEE Download page.

On a side note, it has been reported a couple of times, that Directory Server failed to restart after installing the 6.2 patch. It seems that it is linked with a specific hot-fix being applied to the Directory Server binaries prior to install 6.2 patch. If you have applied a hot-fix to DS 6 and want to install DS 6.2 patches, make sure that in the /opt/SUNWdsee/ds6/lib and /opt/SUNWdsee/ds6/lib/sparcv9 directories, the libslapd.so is a symbolic link to libslapd.so.1 (and the later is in fact the real dynamic library).

Enjoy !

Technorati Tags: , , , ,

Directory Server 6.1 and Unix Crypt…

Sun Java System Directory Server has supported for many years the ability to hash the userPassword attribute with the crypt(3C) algorithm.

But the crypt function has evolved from the basic standard Unix crypt algorithm (which truncates password to 8 characters) to support MD5, Blowfish and other stronger algorithms.

Until Directory Server 6.1, there was very limited support for those algorithms (it happened that a password hashed with MD5 – outside DS – could be used for authentication, but the server itself would never hash a password this way).

Starting with Directory Server 6.1, there is now a way to tune the CRYPT password storage plugin to specify which crypt algorithm to use, and on Solaris only, it is even possible to delegate the choice of algorithm to the OS via the /etc/security/policy.conf (and the CRYPT_DEFAULT directive).

The way to configure with algorithm is used by the crypt library when hashing a userPassword to store in Directory Server is to add an argument to the "CRYPT password storage" plugin configuration entry.

# dsconf set-plugin-prop CRYPT argument:<Pattern>



where <Pattern> is a choice of (but not limited to):



%.2s – Default unix crypt algorithm (and the default

when no argument is defined)

$1$%.8s – bsd md5

$2a$04$%.22s – Blowfish

$md5$%.8s$ – Sun md5

If <Pattern> maps to an algorithm that is not supported by the OS (for example $2$, old variants of blowfish), then a warning message is logged and the hash will be done using the default Unix algorithm

This guarantee that the password is always hashed even if the configured salt does not match an existing algorithm.

On Solaris only, a special value of "auto" is allowed to specify that CRYPT will use the system’s default mechanism, as configured in /etc/security/policy.conf

Notes:

  • Changing the plugin configuration requires a restart of Directory Server to be taken into account.
  • You should use this new capability carefully, especially in a heterogeneous and replicated environment where some algorithms might not be present or enabled.
  • Make sure that CRYPT is the password Storage mechanism defined in the Password Policy configuration (the default is SSHA).

Example:

> dsconf set-plugin-prop -p 1389 CRYPT ‘argument=$md5$%.8s$’

Enter "cn=Directory Manager" password:

Directory Server must be restarted for changes to take effect.

> dsadm restart /local/demo/ds

> dsconf get-plugin-prop -p 1389 CRYPT

Enter "cn=Directory Manager" password:

argument : $md5$%.8s$

depends-on-named :

depends-on-type :

desc : Unix crypt algorithm (CRYPT)

enabled : on

feature : crypt-password-storage-scheme

init-func : crypt_pwd_storage_scheme_init

lib-path : /opt/SUNWdsee/ds6/lib/pwdstorage-plugin.so

type : pwdstoragescheme

vendor : Sun Microsystems, Inc.

version : 6.2

>

Technorati Tags: , ,

Glassfish v2 and Directory Services… with OpenDS

While on the same subject of the interaction between Glassfish and directory servers, Trey Drake posted a few months ago details on how to integrate OpenDS and Glassfish for authentication and authorization.

But there are other ways to leverage OpenDS and Glassfish. As OpenDS is a pure Java application, it can be embedded in other Java application or web application, running in the same JVM. And with its built-in multi-master replication, OpenDS can provide high-availability for users and groups within a cluster of Sun Java System Application Servers.

Technorati Tags: , , , , ,

Glassfish v2 and Directory Services…

Glassfish v2 and its companion Sun branded product Sun Java System Application Server 9.1 are being released today, delivering enterprise grade application servers.

Glassfish and Sun Directory Server Enterprise Edition have been playing well with each other for a long time now.

On one side, Glassfish v2 delivers by default an LDAP realm allowing centralization of Users and Groups into Sun Directory Server, integrating the application server with enterprises identity management solutions.

On the other side, Directory Server Enterprise Edition 6.x contains a couple of web applications (the Directory Service Control Center and Directory Editor) that can be easily deployed in Glassfish v2. The following blog posts are providing the details:

Technorati Tags: , , , , , ,

DSCC deployed as war file for a Java ES Install…

Directory Server Enterprise Edition 6.1 main feature is the ability to deploy the Console GUI from a War file in your favorite Application Server (within a choice of Sun App Server or Tomcat 5.5).

In a previous post, I demonstrated how to do this with a Zip installation of DSEE. Here I am explaining how to obtain and install DSCC war file for a Java Enterprise System installation (also known as the Native package installation, depending on the OS either SVR4 packages, RPMs, Depot or MSI).

Because packages are providing a greater integration with Solaris system features, most of the commands must be run as "root" (or "Administrator" for Windows).

Once you have installed Directory Server Enterprise Edition 6.1 or 6.2, the console is probably already registered in Sun Web Console. You can leave it as is, or you can un-configure it using dsccsetup:

# pwd

/opt/SUNWdsee/dscc6/bin

# dsccsetup console-unreg

Unregistering DSCC Application from Sun Java(TM) Web Console…

This operation is going to stop Sun Java(TM) Web Console.

Do you want to continue ? [y,n] y

Stopping Sun Java(TM) Web Console…

Unregistration is on-going. Please wait…

/var/opt/SUNWdsee/dscc6/dcc has not been removed

DSCC Application has been unregistered from Sun Java(TM) Web Console

Restarting Sun Java(TM) Web Console

Please wait : this may take several seconds…

Sun Java(TM) Web Console restarted successfully

Now you can check the status and it should like this.

# dsccsetup status

***

DSCC Application is not registered in Sun Java (TM) Web Console

***

DSCC Agent is registered in Cacao

***

DSCC Registry has been created

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

Port of DSCC registry is 3998

***

To generate the DSCC war file, use the following command (note that this command is undocumented and unsupported for the time being. Still it works and produces the ).

# dsccsetup war-file-create /tmp/dscc.war

# ls -la /tmp/dscc.war

-rw-r–r– 1 root root 7303074 Jul 9 14:33 /tmp/dscc.war

You can now deploy the WAR file in your favorite Application Server, and follow the instructions for the zip deployment. There is one pitfall though. Because, DSEE and DSCC are installed as root, and so is the DSCC Registry, the WAR file should be deployed in an Application Server which as the ability to run commands with the root privileges. Otherwise, DSCC will not be able to access its registry and thus will not start properly.

Technorati Tags: , , ,