User passwords may not be provided in pre-encoded form

One of the very first differences between the OpenDS and DSEE I have noticed
was the possibility of ldapmodifing the userPassword value. In OpenDS this feature is disabled by default.

$ ldapmodify -p 1389 -D cn=dirmgr -j ~/.odspwd
dn: cn=odsmgr,cn=Root DNs,cn=config
changetype: modify
replace: userpassword
userpassword: {SSHA512}1g9Byn7MOZ1TgZCNY8gw4NA6o8UguyYg0b48d89zJS+AyIs9OP2rHfbZ6aaqTluryTh3Ux1ZW5RSWuTjH9wvtBxFXCxJzyt0

Processing MODIFY request for cn=odsmgr,cn=Root DNs,cn=config
MODIFY operation failed
Result Code:  53 (Unwilling to Perform)
Additional Information:  User passwords may not be provided in pre-encoded form

$ ldapsearch -p 1389 -D cn=dirmgr -j ~/.odspwd -b cn=config "cn=Default Password Policy" ds-cfg-allow-pre-encoded-passwords
dn: cn=Default Password Policy,cn=Password Policies,cn=config
ds-cfg-allow-pre-encoded-passwords: false

$ ldapsearch -p 1389 -D cn=dirmgr -j ~/.odspwd -b cn=config "cn=Root Password Policy" ds-cfg-allow-pre-encoded-passwords
dn: cn=Root Password Policy,cn=Password Policies,cn=config
ds-cfg-allow-pre-encoded-passwords: false

I do not know the pro and con voices in this discussion, but for me there is only one disadvantage - the ability to observe
multiple instances of the same encoded password strings. And it is only the risk when the one who would notice this fact is the bad guy.
In contrast I see only the advantages.
So...

dn: cn=Root Password Policy,cn=Password Policies,cn=config
changetype: modify
replace: ds-cfg-allow-pre-encoded-passwords
ds-cfg-allow-pre-encoded-passwords: true

LDIF has been implemented.

$ encode-password -s SSHA512 -f ~/.odspwd
Encoded Password:  "{SSHA512}Gur7YkCGk4oP2sun+KqpXF4rB9wmzUgjhb3P6hBNmNRLBBQgTxSwLR5WuO41yytG9sUzslYc2HyUAM1otujRW+UkAOapbB7c"

$ ldapmodify -p 1389 -D cn=dirmgr -j ~/.odspwd
dn: cn=odsmgr,cn=Root DNs,cn=config
changetype: modify
replace: userpassword
userpassword: {SSHA512}Gur7YkCGk4oP2sun+KqpXF4rB9wmzUgjhb3P6hBNmNRLBBQgTxSwLR5WuO41yytG9sUzslYc2HyUAM1otujRW+UkAOapbB7c

Processing MODIFY request for cn=odsmgr,cn=Root DNs,cn=config
MODIFY operation successful for DN cn=odsmgr,cn=Root DNs,cn=config

$ ldapsearch -p 1389 -D cn=dsmgr -j ~/.dspwd -b cn=config "cn=odsmgr" +
The simple bind attempt failed
Result Code:  49 (Invalid Credentials)
$ ldapsearch -p 1389 -D cn=dsmgr -j ~/.odspwd -b cn=config "cn=odsmgr" +
dn: cn=odsmgr,cn=Root DNs,cn=config
modifiersName: cn=Directory Manager,cn=Root DNs,cn=config
modifyTimestamp: 20100927104857Z
createTimestamp: 20100924124513Z
pwdChangedTime: 20100927104857.435Z
creatorsName: cn=Directory Manager,cn=Root DNs,cn=config
entryDN: cn=odsmgr,cn=root dns,cn=config
entryUUID: 99296ddd-e705-468b-8112-afd19bb38821
hasSubordinates: false
subschemaSubentry: cn=schema
ds-pwp-password-policy-dn: cn=Root Password Policy,cn=Password Policies,cn=confi
 g
structuralObjectClass: inetOrgPerson
numSubordinates: 0

Directory Managers. Lots of Directory Managers.

Last week I have decided to take some OpenDS practise. The practical solving of a problem is better
then hundreds lines of reading about the others activity. At least that's the way I feel.
Task: Multiple the Directory Manager account to delegate administration without providing your secret password.

In theory it is possible without any problems.
The only requirement is the object class of ds-cfg-root-dn-user.
I have copied almost the all attributes from the current "root" account into a new one.

$ ldapsearch -p 1389 -D cn=dirmgr -j ~/.odspwd -b cn=config "cn=Directory Manager"
dn: cn=Directory Manager,cn=Root DNs,cn=config
sn: Manager
ds-cfg-alternate-bind-dn: cn=dirmgr
cn: Directory Manager
givenName: Directory
objectClass: ds-cfg-root-dn-user
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
userpassword: {SSHA512}1g9Byn7MOZ1TgZCNY8gw4NA6o8UguyYg0b48d89zJS+AyIs9OP2rHfbZ6
 aaqTluryTh3Ux1ZW5RSWuTjH9wvtBxFXCxJzyt0


$ ldapmodify -p 1389 -D cn=dirmgr -j ~/.odspwd
dn: cn=odsmgr,cn=Root DNs,cn=config
changetype: add
objectClass: ds-cfg-root-dn-user
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
cn: odsmgr
givenName: ODS
sn: Manager
userPAssword: secret

Processing ADD request for cn=odsmgr,cn=Root DNs,cn=config
ADD operation successful for DN cn=odsmgr,cn=Root DNs,cn=config

For the initial testing I have duplicated also the password.

$ ldappasswordmodify -p 1389 -D "cn=dirmgr" -j ~/.odspwd \
> -a "dn:cn=odsmgr,cn=Root DNs,cn=config" -c secret -N ~/.odspwd  
The LDAP password modify operation was successful

During the cut'n'copy session of ldapmodify I have omitted ds-cfg-alternate-bind-dn intentionally.
I thought the adjective "alternate" is self-explanatory.
Wrong!

$ ldapsearch -p 1389 -D cn=odsmgr -j ~/.odspwd -b cn=config cn=odsmgr
The simple bind attempt failed
Result Code:  49 (Invalid Credentials)

$ ldapmodify -p 1389 -D "cn=dirmgr" -j ~/.odspwd
dn: cn=odsmgr,cn=Root DNs,cn=config
changetype: modify
add: ds-cfg-alternate-bind-dn
ds-cfg-alternate-bind-dn: cn=odsmgr

Processing MODIFY request for cn=odsmgr,cn=Root DNs,cn=config
MODIFY operation successful for DN cn=odsmgr,cn=Root DNs,cn=config

$ ldapsearch -p 1389 -D cn=odsmgr -j ~/.odspwd -b cn=config cn=odsmgr
dn: cn=odsmgr,cn=Root DNs,cn=config
sn: Manager
ds-cfg-alternate-bind-dn: cn=odsmgr
cn: odsmgr
givenName: ODS
objectClass: top
objectClass: ds-cfg-root-dn-user
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: person
userPassword: {SSHA}gF7nQ6N6gmpuufM1/8FemlwH1/HikScaVOlP3Q==

Why not to test a case with multiple ds-cfg-alternate-bind-dn attibute values.

$ ldapmodify -p 1389 -D "cn=dirmgr" -j ~/.odspwd
dn: cn=odsmgr,cn=Root DNs,cn=config
changetype: modify
add: ds-cfg-alternate-bind-dn
ds-cfg-alternate-bind-dn: cn=dsmgr

Processing MODIFY request for cn=odsmgr,cn=Root DNs,cn=config
MODIFY operation successful for DN cn=odsmgr,cn=Root DNs,cn=config

$ ldapsearch -p 1389 -D cn=dsmgr -j ~/.odspwd -b cn=config cn=odsmgr
dn: cn=odsmgr,cn=Root DNs,cn=config
ds-cfg-alternate-bind-dn: cn=odsmgr
ds-cfg-alternate-bind-dn: cn=dsmgr
sn: Manager
cn: odsmgr
givenName: ODS
objectClass: ds-cfg-root-dn-user
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
userPassword: {SSHA}gF7nQ6N6gmpuufM1/8FemlwH1/HikScaVOlP3Q==

But wait a minute. Why the userPassword value is encoded with a SSHA password scheme, while
the Directory Manager and the default root scheme is pointing to SSHA512.

$ ldapsearch -p 1389 -D cn=dsmgr -j ~/.odspwd -b cn=config cn="Directory Manager" userpassword
dn: cn=Directory Manager,cn=Root DNs,cn=config
userpassword: {SSHA512}1g9Byn7MOZ1TgZCNY8gw4NA6o8UguyYg0b48d89zJS+AyIs9OP2rHfbZ6
 aaqTluryTh3Ux1ZW5RSWuTjH9wvtBxFXCxJzyt0
 
$ ldapsearch -p 1389 -D cn=dsmgr -j ~/.dspwd -b cn=config "cn=Root Password Policy" \
> ds-cfg-default-password-storage-scheme
dn: cn=Root Password Policy,cn=Password Policies,cn=config
ds-cfg-default-password-storage-scheme: cn=Salted SHA-512,cn=Password Storage Sc
 hemes,cn=config 

The answer has come with the hint from Ludovic Poitou.
The virtual attribute of ds-pwp-password-policy-dn should be set explicitly.

$ ldapmodify -p 1389 -D cn=dsmgr -j ~/.odspwd
dn: cn=odsmgr,cn=Root DNs,cn=config
changetype: modify
add: ds-pwp-password-policy-dn
ds-pwp-password-policy-dn: cn=Root Password Policy,cn=Password Policies,cn=config

Processing MODIFY request for cn=odsmgr,cn=Root DNs,cn=config
MODIFY operation successful for DN cn=odsmgr,cn=Root DNs,cn=config

$ openssl rand -base64 12 > ~/.dspwd

$ ldappasswordmodify -p 1389 -D cn=dsmgr -j ~/.odspwd -a "cn=odsmgr,cn=Root DNs,cn=config" \
> -C ~/.odspwd -N ~/.dspwd
The LDAP password modify operation was successful

$ ldapsearch -p 1389 -D cn=dsmgr -j ~/.dspwd -b cn=config cn=odsmgr userpassword
dn: cn=odsmgr,cn=Root DNs,cn=config
userpassword: {SSHA512}BxvZzrhuVpwOv6FMc9sI1infjPC7PQ0dXXdry4ZLNgq6FJbjCVfSiLwBO
 A1uzaXAscS7pkNbfkP4hG11L9DTPsRfpusta+4x

Nice.

Custom Service Packages

During each subsequent comms implementation I forget one or more steps from the following recipe.
So, here comes the milestones to remember.
For the complete documentation refer to the wikis.sun.com.

Template for basic set of packages - da.cos.skeleton.ldif can be found in directory:
/opt/sun/comms/da/lib/config-templates/
on Delegated Administrator default installation path.

Usually I use only the packages for MailUser, MailCalendarUser and MailGroup.
After the customization the file might look like:

dn: cn=wisniosMailUser,o=mailuser,o=cosTemplates,o=root
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: wisniosMailUser
mailMsgMaxBlocks: 5000
mailAllowedServiceAccess: +imap,imaps,pop,pops,smtp,smtps,http,smime:ALL
daServiceType: mail user

dn: cn=wisniosMailCalendarUser,o=mailcalendaruser,o=cosTemplates,o=root
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: wisniosMailCalendarUser
mailMsgMaxBlocks: 5000
mailAllowedServiceAccess: +imap,imaps,pop,pops,smtp,smtps,http,smime:ALL
daServiceType: calendar user
daServiceType: mail user

dn: cn=wisniosMailGroup,o=mailgroup,o=cosTemplates,o=root
changetype: add
objectclass: top
objectclass: LDAPsubentry
objectclass: extensibleobject
objectclass: cosTemplate
cn: wisniosMailGroup
mailMsgMaxBlocks: 5000
daServiceType: mail group

Dry run:

# ldapmodify -p 1389 -D cn=dirmgr -j /root/.dspwd -n -f da.cos.wisnios.ldif 
!adding new entry cn=wisniosMailUser,o=mailuser,o=cosTemplates,o=root

!adding new entry cn=wisniosMailCalendarUser,o=mailcalendaruser,o=cosTemplates,o=root

!adding new entry cn=wisniosMailGroup,o=mailgroup,o=cosTemplates,o=root

Wet run:

# ldapmodify -p 1389 -D cn=dirmgr -j /root/.dspwd -f da.cos.wisnios.ldif 
adding new entry cn=wisniosMailUser,o=mailuser,o=cosTemplates,o=root

adding new entry cn=wisniosMailCalendarUser,o=mailcalendaruser,o=cosTemplates,o=root

adding new entry cn=wisniosMailGroup,o=mailgroup,o=cosTemplates,o=root

Check:

# ldapsearch -p 1389 -D cn=dirmgr -j /root/.dspwd -b o=cosTemplates,o=root \
> "(&(cn=wisnios*)(objectclass=LDAPsubentry))" daServiceType
version: 1
dn: cn=wisniosMailUser,o=mailuser,o=cosTemplates,o=root
daServiceType: mail user

dn: cn=wisniosMailCalendarUser,o=mailcalendaruser,o=cosTemplates,o=root
daServiceType: calendar user
daServiceType: mail user

dn: cn=wisniosMailGroup,o=mailgroup,o=cosTemplates,o=root
daServiceType: mail group

To make sure that the changes (packages) will be visible restart the app/web container.

MakeLDIF.jar

Yesterday I have realized that I do not remember how to prepare the ldif file. But not just a simple ldif with a few lines of add/modify/delete subcommands. I have forgotten how to use the SLAMD project's tool - MakeLDIF. As far as I remember there was the jar - MakeLDIF. It was, but now there is not. It had taken a few moments before I found the solution. Here you go:

$ find . -name *.jar | grep -i make
$ cd tools/MakeLDIF
$ perl -e 's/(^define suffix=).*/\1o=ods/' -pi example.template
$ perl -e 's/(^define numusers)=.*/\1=1000/' -pi exa*
$ perl -e 's/(^define maildomain)=.*/\1=wisnios\.com/' -pi exa*
$ head -3 exa*
define suffix=o=ods
define maildomain=wisnios.com
define numusers=1000
$ cd ..
$ ./make-ldif.sh -t MakeLDIF/example.template -o ~/ods1k.ldif
Processed 1000 entries
Processing complete.
1002 total entries written.

And the process view of similar command execution:

/usr/jdk/instances/jdk1.5.0/bin/java -server -Xms512m -Xmx512m com.slamd.tools.makeldif.MakeLDIF
-r /export/home/slamd200-20090712/tools/MakeLDIF -t /tmp/ods.template -o /tmp/ods100k.ldif

Merry Xmas!

Create base64 jpegPhoto attribute

So, you wanna a picture in your user profile within the Directory Server entry?
Go for it.

Generate base-64 encoded value of the selected picture:

book [/tmp]# ldif -b jpegPhoto < marcin.jpg
jpegPhoto:: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAMgAA/+4ADkFkb2JlA
GTAAAAAAf/bAIQACAYGBgYGCAYGCAwIBwgMDgoICAoOEA0NDg0NEBEMDg0NDgwRDxITFBMSDxgYG
hoYGCMiIiIjJycnJycnJycnJwEJCAgJCgkLCQkLDgsNCw4RDg4ODhETDQ0ODQ0TGBEPDw8PERgWF
xQUFBcWGhoYGBoaISEgISEnJycnJycnJycn/8AAEQgBVAH0AwEiAAIRAQMRAf/EAK4AAAIDAQEBA
QAAAAAAAAAAAAMEAAIFAQYHCAEAAwEBAQAAAAAAAAAAAAAAAAECAwQFEAACAQMCBAMFBQUFBwMDB
[...]


Enter output to the ldif file or create the modification by hand:

book [~]$ ldapmodify -D cn=dirmgr
Enter bind password:
dn: uid=marcin,ou=People,o=wisnios.com,o=isp
changetype: modify
add: jpegPhoto
jpegPhoto:: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAMgAA/+4ADkFkb2JlA
GTAAAAAAf/bAIQACAYGBgYGCAYGCAwIBwgMDgoICAoOEA0NDg0NEBEMDg0NDgwRDxITFBMSDxgYG
hoYGCMiIiIjJycnJycnJycnJwEJCAgJCgkLCQkLDgsNCw4RDg4ODhETDQ0ODQ0TGBEPDw8PERgWF
xQUFBcWGhoYGBoaISEgISEnJycnJycnJycn/8AAEQgBVAH0AwEiAAIRAQMRAf/EAK4AAAIDAQEBA
QAAAAAAAAAAAAMEAAIFAQYHCAEAAwEBAQAAAAAAAAAAAAAAAAECAwQFEAACAQMCBAMFBQUFBwMDB
[...]
^D


Directory Server SSL Certificate

Recently, I've added the article about SSL configuration of Sun Java Commmunications Suite components (link).
Today I want to expand its content with Directory Server SSL preparation.

DS comes with self-signed certificate (it's valid for a period of three months). It name's defaultCert, and by defalt allow for secure connections through the port 636.
It's stored in alias directory under the instance path:

book [/]# ls /instances/ds1/alias
certmap.conf secmod.db slapd-cert8.db slapd-key3.db


book [/instances/ds1/alias]# dsconf get-server-prop -D cn=dirmgr ssl-rsa-cert-name
Enter "cn=dirmgr" password:  
ssl-rsa-cert-name  :  defaultCert

book [/]# /opt/SUNWdsee/ds6/bin/dsadm list-certs /instances/ds1/
Alias        Valid from        Expires on        Self-signed?  Issued by                                              Issued to  
-----------  ----------------  ----------------  ------------  -----------------------------------------------------  --------------  
defaultCert  2009/03/18 12:28  2009/06/18 12:28  y             CN=book,CN=636,CN=Directory Server,O=Sun Microsystems  Same as issuer  
1 certificate(s) found

book [/instances/ds1/alias]# /usr/sfw/bin/certutil -L -P slapd- -d .
defaultCert                                                  CTu,u,u

But, I want to use the same one as with other COMMS components - Server-Cert - issued by CA.

book [/instances/ds1/alias]# dsadm import-cert /instances/ds1/ /root/SSL/VeriSign.cert.pkcs12 
Enter the PKCS#12 file password:
The Directory Server will need to be restarted before being able to use the new certificate.
book [/instances/ds1/alias]# dsadm stop /instances/ds1
Directory Server instance '/instances/ds1' stopped
book [/instances/ds1/alias]# dsadm start /instances/ds1
Directory Server instance '/instances/ds1' started: pid=25150
book [/instances/ds1/alias]# /usr/sfw/bin/certutil -L -P slapd- -d .
defaultCert                                                  CTu,u,u
Server-Cert                                                  u,u,u

Now i have to change default rsa certificate name, within the DS configuration:

book [~]# dsconf set-server-prop -p 389 -D cn=dirmgr ssl-rsa-cert-name:Server-Cert
Enter "cn=dirmgr" password:  
Before setting SSL configuration, export Directory Server data. 
Do you want to continue [y/n] ?  y
Directory Server must be restarted for changes to take effect.

Restart DS one more time.

That's all folks.

book [~]# dsconf get-server-prop -p 389 -D cn=dirmgr ssl-rsa-cert-name
Certificate "CN=[...]" presented by the server is not trusted.
Type "Y" to accept, "y" to accept just once, "n" to refuse, "d" for more details: Y
Enter "cn=dirmgr" password:  
ssl-rsa-cert-name  :  Server-Cert