Monday Dec 07, 2009

Securing JBoss JMX console with OpenDS

Steve Millidge, founder of C2B2, has just published a nice and illustrated step by step tutorial for securing JBoss JMX console with LDAP and more specifically the OpenDS directory server. Similar steps could be used to secure all the different subsystems in JBoss, as illustrated in this already 2 years old tutorial about JBoss Portal, OpenSSO and OpenDS.

Technorati Tags: , , , , , ,

Tuesday Sep 18, 2007

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: , ,

Friday Apr 13, 2007

Directory Server 6 and ldappasswd

Sun Java System Directory Server 6.0 now supports RFC 3062 : LDAP Password Modify Extended Operation, and a new tool is delivered as part of Directory Server Enterprise Edition 6.0 to take advantage of it: ldappasswd.

ldappasswd allows a user or an administrator to change the password of any account. Of course, by default a set of restrictions is configure to prevent malicious use of this feature.

In order to be usable by users other than administrators, the Password Modify Extended Operation requires to add some specific ACI under cn=config.

An example of ACI for the Password Modify Extended operation is presented in the Directory Server Enterprise Edition Administration Manual.

But to allow any authenticated user to change its own password with this tool, the Directory Administrator must add the following entry and ACI, in addition to the usual ACI that allows self write on the userPassword attribute:

dn: oid=1.3.6.1.4.1.4203.1.11.1,cn=features,cn=config
objectClass: top
objectClass: directoryServerFeature
oid: 1.3.6.1.4.1.4203.1.11.1
cn: Password Modify Extended Op Access Control
aci: (targetattr != "aci";)(version 3.0; acl "Allow Password Change
Extended Op to all auth users"; allow( read , search, compare, proxy )
(userdn = "ldap:///all" and authmethod = "SSL";);)

Note that this ACI will require that ldappasswd be used with SSL (which is a good thing if you want to avoid passwords being transfered in cleartext on the network).

Now I can change my own password in LDAP with the tool:

ldappasswd -h <host> -p <port> -D "cn=Ludo,ou=Smart Engineers,dc=Sun,dc=Com" -A -S -Z \\
-P /home/ludo/security -N "LudoCert" -W keypasswd "cn=Ludo,ou=Smart Engineers,dc=Sun,dc=com"
Old Password: myOldPasswd
New Password: aNewOne
Re-enter new Password: aNewOne
ldappasswd: password successfully changed
About

This is the blog of a senior software engineer, specialized in LDAP, Directory Server and OpenDS. Ludovic Poitou works in France at the Grenoble Engineering Center, in the Directory Services Engineering team. Outside work, I love skiing and taking photo

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today