Tuesday Sep 16, 2008

SUNrise SUNset...

This is my final blog entry as my employment at Sun draws to a close.

I am reminded of one of my favourite songs growing up, from the musical "Fiddler on the Roof".

Some pertinent points from my employment at Sun

Sun rose for me (half of seven) years ago
I mostly worked in the seventh layer of the ISO Network Stack.
I averaged seven layers of management between myself and the CEO.
I worked with about seven different products.
I stopped eating seven layer cake when I turned 40 during my tenure at Sun!

I will update my linkedin LinkedIn profile with my next employer, but I am willing to bet some of my Liberty colleagues at Sun will guess who that is from the above list.

I hope I was able to provide some useful information, and occasional humour, in this blog. The Sun Directory Server is a wonderful product built by a talented engineering team.

See you in the blogosphere....

Jonathan

Posted at 03:44PM Sep 16, 2008 by Jonathan Gershater in Personal | Comments[1]

Thursday Jul 31, 2008

Troubleshooting ISW deployments

Troubelshooting ISW deployments

The following is a troubleshooting guideline for Sun Java Identity Synchronization for Windows Installations.

1. Sun Java Message Queue – IMQ

# /etc/init.d/imq start ( or /etc/init.d/stop to stop the IMQ)

.

Now telnet to the port number of IMQ (TCP port 7676 is default). All the messages below should appear.

# telnet localhost 7676

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

101 isw-broker 3.6

portmapper tcp PORTMAPPER 7676

admin tcp ADMIN 17595

jms tcp NORMAL 17594

ssljms tls NORMAL 17596

cluster tcp CLUSTER 17598

2. Sun Java Identity Synchronization for Windows – ISW

# /etc/init.d/isw start (or stop to stop ISW)

Note that the port 7890 below is the connector port selected during the install of the DS Connector.

Telnet to the local port

# telnet localhost 7890

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

®1v<?xml version="1.0" encoding="UTF-8"?>

</AuthRequestMessage>

Netstat should reveal the processes running on port 7890.

# netstat -ad | grep 7890

*.7890 *.* 0 0 49152 0 LISTEN

hostname.27844 hostname.7890 49152 0 49152 0 ESTABLISHED

hostname.7890 hostname.27844 49152 0 49152 0 ESTABLISHED

hostname.7890 hostname2.company.com.31029 49640 0 49640 0 ESTABLISHED

In addition, a really useful script

that will show what UNIX processes are using particular TCP ports, and vice-versa. This script is useful for troubleshooting Identity Synchronization for Windows connectors. The Directory Server connector runs as a Java process listening on a particular TCP port. The ISW plugin in the Sun Directory Server connects to the connector over that port number.

The script can be downloaded here

In this example, the Directory Server connector is listening on port 7890 and the corresponding Sun Directory Server is connected to the connector on port 7890

# sh pcp -p 7890

PID Process Name and Port

_________________________________________________________

7493 /usr/java/bin/java 7890 DS Connector

sockname: AF_INET 0.0.0.0 port: 7890

sockname: AF_INET 10.200.131.36 port: 7890

_________________________________________________________

7766 /opt/SUNWdsee/ds6/lib/64/ns-slapd 7890 Directory Server

peername: AF_INET 10.200.131.36 port: 7890

3. ISW Logs and relevant entries

View logs in this directory and sub-directories

#cd /var/opt/SUNWisw/logs

These errors can be ignored

# tail /var/opt/SUNWisw/logs/CNN100/error.log

[10/Jan/2008:23:22:35.606 +0000] WARNING 14 CNN100 hostname.company.com "ElementGenerator: Can't find element 'Parameters' in element map"

# tail /var/opt/SUNWisw/logs/central/error.log

[10/Jan/2008:23:22:35.606 +0000] WARNING 14 CNN100 hostname.company.com "ElementGenerator: Can't find element 'Parameters' in element map"

tail /var/opt/SUNWisw/logs/CNN101/error.log

[10/Jan/2008:18:01:13.491 +0000] INFO 10 "Log opened. Identity Synchronization for Windows build 2006.310.1625. Java runtime version is 1.5.0_09."

[10/Jan/2008:18:59:09.176 +0000] INFO 10 "Log opened. Identity Synchronization for Windows build 2006.310.1625. Java runtime version is 1.5.0_09."

If during an idsync resync, you get objectClass violation errors as follows then verify that the appropriate auxiliary, if any, objectClasses have been added in during the initial configuration.

# tail /var/opt/SUNWisw/logs/central/error.log

[31/Jul/2008:18:36:43 +0000] - ERROR<5897> - Schema - conn=-1 op=-1 msgId=-1 - User error: Entry "uid=user001,ou=people,dc=company,dc=com", attribute "gecos" is not allowed

[31/Jul/2008:17:00:52.680 +0000] SEVERE 33 CNN100 hostname.company.com "LDAP modify operation of entry uid=user001,ou=people,dc=company,dc=com failed at null. Error code: 65, reason: null" (Action ID=CNN101-11B7A05B0CA-274, SN=10)

Also verify that the hotfix for defect 6691600. (“Users with auxiliary objectclasses fail to link” has been applied – new connector.jar file). If the hotfix has been applied and you still get the errors, then make the following manual change

Execute the following ldapsearch command and look for the pswLinkAttributeRef:. entries. Make a note of the the corresponding “cn=???” value as below. (This value will vary on each installation.)

# ldapsearch -h <hostnameOfConfigurationDirectory> -p <port of ConfigurationDirectory> -b dc=company,dc=com -D "cn=directory manager" -w <password> objectclass=pswsundirectoryglobals

dn: cn=101,ou=Sun,ou=Globals,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswVersion: 4

pswUserObjectClass: inetOrgPerson

pswOtherObjectClass: companyUnixAccount

pswOtherObjectClass: shadowAccount

pswOtherObjectClass: posixAccount

pswNumOutboundConnectorThreads: 4

pswFlowInboundCreates: false

pswFlowInboundModifies: false

pswFlowInboundDeletes: false

pswFlowOutboundCreates: false

pswFlowOutboundModifies: true

pswFlowOutboundDeletes: false

pswCreatesAsModifies: false

pswModifiesAsCreates: false

pswPasswordAttributeName: userpassword

pswLocalRepositoryKey: nsuniqueid

pswRemoteRepositoryKey: dspswuserlink

pswSynchronizeDisables: false

pswPasswordKey: wW1dkRPGyapZIz2s+SvsAE9GYfyP0E2fczgfIIr1BhDyJZfhInr1xoNe12qBp/Yb

pswPasswordIV: goxvuULpkZpASxFBrjiD3tYf0E0hShbp

pswNoValueMeansEnabledInbound: true

pswOtherValuesMeanEnabledInbound: false

pswDisabledRoleRDN: cn=nsmanageddisabledrole

pswDisableMode: disabledRoleRDN

pswMetaAttributeDefaultRef: cn=115,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswMetaAttributeDefaultRef: cn=103,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswMetaAttributeDefaultRef: cn=112,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswSignificantAttributeRef: cn=105,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswCreationAttributeDefaultRef: cn=106,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswCreationAttributeRef: cn=113,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswCreationAttributeRef: cn=104,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswCreationAttributeRef: cn=107,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswCreationAttributeRef: cn=114,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswCreationAttributeRef: cn=109,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswCreationAttributeRef: cn=102,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswHostsTopologyConfigurationRef: cn=110,ou=TopoHosts,ou=Globals,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswSchemaLocationRef: cn=110,ou=TopoHosts,ou=Globals,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswSignificantAttributeDefaultRef: cn=116,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=c

om

pswLinkAttributeRef: cn=108,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

pswLinkAttributeRef: cn=112,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

cn: 101

objectClass: pswsundirectoryglobals

objectClass: top

For each of the blue entries in the prior search, search for the pswValue: dspswuser, entry as per below

#ldapsearch h <hostnameOfConfigurationDirectory> -p <port of ConfigurationDirectory> -b dc=company,dc=com -D "cn=directory manager" -w company2005 cn=108

version: 1

dn: cn=108,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=Ide

ntitySynchronization,ou=Services,dc=company,dc=com

pswVersion: 4

pswName: objectclass

pswSyntax: 1.3.6.1.4.1.1466.115.121.1.15

pswValue: dspswuser

pswValue: inetOrgPerson

pswPreferCreationAttributeDefaultToAction: true

cn: 108

objectClass: pswattributedescription

objectClass: top

Now, you have the DN required for modification (note that these portions of the DN may vary for your installation)

(cn=108,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=Ide

ntitySynchronization,ou=Services,dc=company,dc=com)

Stop ISW (/etc/init.d/isw stop)

Run ldapmodify against the ISW configuration Directory instance with the following LDIF file:

(Again the DN value in italics will vary for each installation).

dn: cn=108,ou=AttributeDescriptions,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

changetype: modify
replace: pswValue
pswValue: companyUnixAccount
pswValue: shadowAccount
pswValue: posixAccount
pswValue: dspswuser
pswValue: inetOrgPerson

Start ISW (/etc/init.d/isw start)

4. Workaround for defect 6709099. When installing ISW in an (multi-master replicated) MMR environment, the ISW plugins do not register with the ISW configuration Directory.

This is more of a cosmetic defect, since ISW may be functioning correctly but the status fails to show that the plugins are properly installed.

# sh printstat.sh

Exploring status of connectors, please wait...

Connector ID: CNN100

Type: Sun Java(TM) System Directory

Manages: dc=company,dc=com (ldap://hostname.company.com:389) (ldap://hostname2.company.com:389)

State: SYNCING

Installed on: hostname.company.com

<ISW plugin information does not display>

Connector ID: CNN101

Type: Active Directory

Manages: COMPANY.COM (ldap://ADDomainController.company.com:389)

State: SYNCING

Installed on: hostname.company.com

Sun Java(TM) System Message Queue Status: Started

Checking the System Manager status over the Sun Java(TM) System Message Queue.

System Manager Status: Started

There are two steps to complete:

Ensure that the SUBC entries match between dse.ldif of the Sun Directory Server 6.3 servers and the configuration server
Ensure that the plugin information is properly registered in the Sun Directory Server – Configuration Directory.

1. Ensure that the SUBC entries match

Proceed as follows.

View the dse.ldif file for the Sun Directory 6.x server that has the plugin installed. The entry for the ISW plugin in the dse.ldif contains the name of the plugin as defined in the configuration Directory; highlighted below:

dn: cn=config,cn=pswsync,cn=plugins,cn=config

objectClass: extensibleObject

objectClass: top

accessorhost: hostname.company.com

accessorport: 7890

accessoruser: gEQ8OUyzepyAX1lw

accessorpassword: nhyji5OQxlCyfvuOLyqwm1jmewwSDxA6Sdm4lWeG7dI=

subcomponentid: SUBC101

subcomponentsaintssloption: false

debugloglevel: INFO

cn: config

creatorsName: cn=directory manager

entrydn: cn=config,cn=pswsync,cn=plugins,cn=config

createTimestamp: 20080718192517Z

auditloglevel: FINE

modifiersName: cn=pswsync,cn=plugins,cn=config

modifyTimestamp: 20080728205759Z

The corresponding entry in the Configuration Directory must contain the identical information. If not make corrections as needed. See screenshot below.

Note: that the DN of the corresponding entry in the configuration Directory Server will vary per installation. In the examples below the DNs are:

cn=139,ou=SyncHosts,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

cn=17,ou=SyncHosts,cn=active[4],ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

The cn=active[4] component of the DN will vary for each installation.

Similary for any additional 6.x Directory Servers, make corrections as required. The additional Directory Server below has an entry of SUBC101.

2. Ensure that the plugins are registered

The second modification required is as follows:

The configuration Directory must be be configured for each plugin. In the screenshot below, notice that pswInstalledSubComponentInfo contains <none>. This is incorrect.

Modify the entry so that pswInstalledSubComponentInfo contains the names of each plugin as follows:

pswInstalledSubcomponentInfo: SUBC100?ldap://hostname.company.com:389

pswInstalledSubcomponentInfo: SUBC101?ldap://hostname2.company.com:389

Important, the SUBC100 number must match SUBC100 in the modification 1. above.(ensure subc entries match)

Note that there are two DNs to be modified:

cn=active_as_ADP101,ou=Status,ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

cn=active_as_ADP10,ou=Status,ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

Now the entry appears as follows:

And executing printstat shows that the plugins are installed.

# sh printstat.sh

Exploring status of connectors, please wait...

Connector ID: CNN100

Type: Sun Java(TM) System Directory

Manages: dc=company,dc=com (ldap://hostname.company.com:389) (ldap://hostname2.company.com:389)

State: SYNCING

Installed on: hostname.company.com

Plugin SUBC100 is installed on ldap://hostname22.company.com:389

Plugin SUBC101 is installed on ldap://hostname.company.com:389

Connector ID: CNN101

Type: Active Directory

Manages: .company.com (ldap://ADDomainController.company.com:389)

State: SYNCING

Installed on: hostname.company.com

Sun Java(TM) System Message Queue Status: Started

Checking the System Manager status over the Sun Java(TM) System Message Queue.

System Manager Status: Started

An alternative to using the DirectoryServer 5.2 console to register the plugins, is to execute ldapmodify at the command line with LDIF files similar to this: (Similar because the DN and SUBC numbers will vary)

dn: cn=active_as_ADP100,ou=Status,ou=GlobalConfig,ou=1.1,ou=IdentitySynchronization,ou=Services,dc=company,dc=com

changetype:modify

replace:pswInstalledSubComponentInfo

pswInstalledSubcomponentInfo::SUBC?ldap://hostname.company.com:389

pswInstalledSubComponemtInfo::SUBC101?ldap://hostname2.company.com:389

Posted at 02:46PM Jul 31, 2008 by Jonathan Gershater in Identity & Directory Server |

Thursday Jul 24, 2008

Installing OpenDS on my MacBook Pro in a cinch

After downloading the OpenDS zip file, I unzipped the file and exeucte setup in command line mode (not the graphical interface). This utility can be used to setup the Directory Server. Here are the global setup options:

Usage: setup {options}

where {options} include:

-i, --cli

Use the command line install. If not specified the graphical interface will be launched. The rest of the options (excluding help and version) will only be taken into account if this option is specified

-b, --baseDN {baseDN}

Base DN for user information in the Directory Server. Multiple base DNs may be provided by using this option multiple times

-a, --addBaseEntry

Indicates whether to create the base entry in the Directory Server database

-l, --ldifFile {ldifFile}

Path to an LDIF file containing data that should be added to the Directory Server database. Multiple LDIF files may be provided by using this option multiple times

-R, --rejectFile {rejectFile}

Write rejected entries to the specified file

--skipFile {skipFile}

Write skipped entries to the specified file

-d, --sampleData {numEntries}

Specifies that the database should be populated with the specified number of sample entries

-p, --ldapPort {port}

Port on which the Directory Server should listen for LDAP communication

-x, --jmxPort {jmxPort}

Port on which the Directory Server should listen for JMX communication

-S, --skipPortCheck

Skip the check to determine whether the specified ports are usable

-D, --rootUserDN {rootUserDN}

DN for the initial root user for the Directory Server

-w, --rootUserPassword {rootUserPassword}

Password for the initial root user for the Directory Server

-j, --rootUserPasswordFile {rootUserPasswordFile}

Path to a file containing the password for the initial root user for the Directory Server

-O, --doNotStart

Do not start the server when the configuration is completed

-q, --enableStartTLS

Enable StartTLS to allow secure communication with the server using the

LDAP port

-Z, --ldapsPort {port}

Port on which the Directory Server should listen for LDAPS communication. The LDAPS port will be configured and SSL will be enabled only if this argument is explicitly specified

--generateSelfSignedCertificate

Generate a self-signed certificate that the server should use when accepting SSL-based connections or performing StartTLS negotiation

--usePkcs11Keystore

Use a certificate in a PKCS#11 token that the server should use when accepting SSL-based connections or performing StartTLS negotiation

--useJavaKeystore {keyStorePath}

Path of a Java Key Store (JKS) containing a certificate to be used as the server certificate

--usePkcs12keyStore {keyStorePath}

Path of a PKCS#12 key store containing the certificate that the server should use when accepting SSL-based connections or performing StartTLS negotiation

-W, --keyStorePassword {keyStorePassword}

Certificate key store PIN. A PIN is required when you specify to use an existing certificate (JKS, PKCS#12 or PKCS#11) as server certificate

-u, --keyStorePasswordFile {keyStorePasswordFile}

Certificate key store PIN file. A PIN is required when you specify to use an existing certificate (JKS, PKCS#12 or PKCS#11) as server certificate

-N, --certNickname {nickname}

Nickname of the certificate that the server should use when accepting SSL-based connections or performing StartTLS negotiation

Utility Input/Output Options

-n, --no-prompt

Perform an installation in non-interactive mode. If some data in the command is missing the user will not be prompted and the tool will fail

-Q, --quiet

Run setup in quiet mode. Quiet mode will not output progress information to standard output

-v, --verbose

Use verbose mode

--propertiesFilePath {propertiesFilePath}

Path to the file containing default property values used for command line arguments

--noPropertiesFile

No properties file will be used to get default command line argument values

General Options

-V, --version

Display Directory Server version information

-?, -H, --help

Display this usage information

Since my install is a development environment I selected the following options:

-i – command line mode

-b – base DN of "dc=example,dc=com"

-a - create the baseDN

-d 500 – five hundred sample users

-p 1389 – insecure port 1389

-D "cn=directory manager" – directory administrator user

-w password – directory administrator password

-q -Z 1390 - secure port 1390

-v – verbose output

Herewith the installation session:

pcp002880pcs:~/opends/OpenDS-1.0.0 /$ ./setup -i -b "dc=example,dc=com" -a -d 500 -p 1389 -D "cn=directory manager" -w password -q -Z 1390 -v

OpenDS Directory Server 1.0.0

Please wait while the setup program initializes...

Certificate server options:

1) Generate self-signed certificate (recommended for testing purposes

only)

2) Use an existing certificate located on a Java Key Store (JKS)

3) Use an existing certificate located on a PKCS#12 key store

4) Use an existing certificate on a PKCS#11 token

Enter choice [1]:

Do you want to start the server when the configuration is completed? (yes /

no) [yes]:

Setup Summary

=============

LDAP Listener Port: 1389

LDAP Secure Access: Enable StartTLS

Enable SSL on LDAP Port 1390

Create a new Self-Signed Certificate

Root User DN: cn=directory manager

Directory Data: Create New Base DN dc=example,dc=com.

Base DN Data: Import Automatically-Generated Data (500 Entries)

Start Server when the configuration is completed

What would you like to do?

1) Setup the server with the parameters above

2) Provide the setup parameters again

3) Cancel the setup

Enter choice [1]:

Configuring Directory Server ..... Done.

Configuring Certificates ..... Done.

-----------------------------------------------------------------

Importing Automatically-Generated Data (500 Entries):

[24/Jul/2008:10:01:28 -0700] category=JEB severity=NOTICE msgID=8847544 msg=Available buffer memory 4479254 bytes is below the minimum value of 10485760 bytes. Setting available buffer memory to the minimum

[24/Jul/2008:10:01:28 -0700] category=JEB severity=NOTICE msgID=8847545 msg=Setting DB cache to 26875526 bytes and internal buffer to 10485760 bytes

[24/Jul/2008:10:01:29 -0700] category=JEB severity=NOTICE msgID=8847533 msg=OpenDS Directory Server 1.0.0 starting import (build 20080610152800Z, R4337)

[24/Jul/2008:10:01:29 -0700] category=JEB severity=NOTICE msgID=8847449 msg=Import Thread Count: 8 threads

[24/Jul/2008:10:01:29 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.5.0_13-b05-241 by Apple Computer, Inc., 32-bit architecture, 66650112 bytes heap size

[24/Jul/2008:10:01:29 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381714 msg=JVM Host: pcp002880pcs.visa.com, running Mac OS X 10.4.11 i386, 4294967296 bytes physical memory size, number of processors available 2

[24/Jul/2008:10:01:29 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381715 msg=JVM Arguments: "-Dorg.opends.server.scriptName=setup"

[24/Jul/2008:10:01:29 -0700] category=JEB severity=NOTICE msgID=8847518 msg=Processing LDIF

[24/Jul/2008:10:01:30 -0700] category=JEB severity=NOTICE msgID=8847519 msg=End of LDIF reached

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847537 msg=Begin substring buffer flush of 15913 elements. Buffer total access: 30458 buffer hits: 14545

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847538 msg=Substring buffer flush completed in 1 seconds

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847539 msg=Begin final cleaner run

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847541 msg=Cleaner run took 0 seconds 0 logs removed

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847454 msg=Processed 502 entries, imported 502, skipped 0, rejected 0 and migrated 0 in 1 seconds (average rate 255.1/sec)

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847455 msg=Number of index values that exceeded the entry limit: 0

[24/Jul/2008:10:01:31 -0700] category=JEB severity=NOTICE msgID=8847536 msg=Import LDIF environment close took 0 seconds

-----------------------------------------------------------------

Starting Directory Server:

[24/Jul/2008:10:01:33 -0700] category=CORE severity=INFORMATION msgID=132 msg=The Directory Server is beginning the configuration bootstrapping process

[24/Jul/2008:10:01:35 -0700] category=CORE severity=NOTICE msgID=458886 msg=OpenDS Directory Server 1.0.0 (build 20080610152800Z, R4337) starting up

[24/Jul/2008:10:01:35 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381713 msg=JVM Information: 1.5.0_13-b05-241 by Apple Computer, Inc., 32-bit architecture, 132775936 bytes heap size

[24/Jul/2008:10:01:35 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381714 msg=JVM Host: pcp002880pcs.visa.com, running Mac OS X 10.4.11 i386, 4294967296 bytes physical memory size, number of processors available 2

[24/Jul/2008:10:01:35 -0700] category=RUNTIME_INFORMATION severity=NOTICE msgID=20381715 msg=JVM Arguments: "-Xserver", "-Dorg.opends.server.scriptName=start-ds"

[24/Jul/2008:10:01:39 -0700] category=ACCESS_CONTROL severity=INFORMATION msgID=12582978 msg=Added 8 Global Access Control Instruction (ACI) attribute types to the access control evaluation engine

[24/Jul/2008:10:01:41 -0700] category=JEB severity=NOTICE msgID=8847402 msg=The database backend userRoot containing 502 entries has started

[24/Jul/2008:10:01:41 -0700] category=PROTOCOL severity=MILD_WARNING msgID=2163134 msg=The directory /Users/jgershater/Documents/Work/ISO images/opends/OpenDS-1.0.0/config/auto-process-ldif referenced by the LDIF connection handler defined in configuration entry cn=LDIF Connection Handler,cn=Connection Handlers,cn=config does not exist. The LDIF connection handler will start, but will not be able to process any changes until this directory is created

[24/Jul/2008:10:01:42 -0700] category=PROTOCOL severity=MILD_ERROR msgID=2294036 msg=Started listening for new connections on LDAP Connection Handler 0.0.0.0 port 1390

[24/Jul/2008:10:01:42 -0700] category=PROTOCOL severity=MILD_ERROR msgID=2294036 msg=Started listening for new connections on LDAP Connection Handler 0.0.0.0 port 1389

[24/Jul/2008:10:01:42 -0700] category=CORE severity=NOTICE msgID=458887 msg=The Directory Server has started successfully

[24/Jul/2008:10:01:42 -0700] category=CORE severity=NOTICE msgID=458891 msg=The Directory Server has sent an alert notification generated by class org.opends.server.core.DirectoryServer (alert type org.opends.server.DirectoryServerStarted, alert ID 458887): The Directory Server has started successfully

See /tmp/opends-setup-11588.log for a detailed log of this operation.

To see basic server configuration status and configuration you can launch /opends/OpenDS-1.0.0/bin/status

I now view the status of the server, per the final line of the installation session:

pcp002880pcs:~/opends/OpenDS-1.0.0/$ cd bin

pcp002880pcs:~/opends/OpenDS-1.0.0/bin/$./status

>>>> Specify OpenDS LDAP connection parameters

How do you want to connect?

1) LDAP

2) LDAP with SSL

3) LDAP with StartTLS

Enter choice [1]:

Administrator user bind DN [cn=Directory Manager]:

Password for user 'cn=Directory Manager':

--- Server Status ---

Server Run Status: Started

Open Connections: 1

--- Server Details ---

Host Name: pcp002880pcs.example.com

Administrative Users: cn=directory manager

Installation Path: /opends/OpenDS-1.0.0

OpenDS Version: OpenDS Directory Server 1.0.0

Java Version: 1.5.0_13-121

--- Connection Handlers ---

Address:Port : Protocol : State

-------------:----------:---------

0.0.0.0:1389 : LDAP : Enabled

0.0.0.0:1390 : LDAPS : Enabled

0.0.0.0:161 : SNMP : Disabled

0.0.0.0:1689 : JMX : Disabled

--- Data Sources ---

Base DN: dc=example,dc=com

Backend ID: userRoot

Entries: 502

Replication: Disabled

And here is a graphical screenshot of the DIT (Directory Information Tree), using jxplorer

Total installation time, about two minutes!

Kudos to Ludo's team and the OpenDS community.

References

OpenDS

jxplorer

Posted at 11:52AM Jul 24, 2008 by Jonathan Gershater in Identity & Directory Server |

Monday Jul 21, 2008

A useful script for troubleshooting UNIX processes and TCP ports

I found a really useful script that will show what UNIX processes are using particular TCP ports, and vice-versa. I found this useful for troubleshooting Identity Synchronization for Windows connectors. The Directory Server connector runs as a java process listening on a particular TCP port. The ISW plugin in the Sun Directory Server connects to the connector over that port number.

The script can be downloaded here

In this example, the Directory Server connector is listening on port 7890 and the corresponding Sun Directory Server is connected to the connector on port 7890

# sh pcp -p 7890

PID Process Name and Port

_________________________________________________________

7493 /usr/java/bin/java 7890 DS Connector

sockname: AF_INET 0.0.0.0 port: 7890

sockname: AF_INET 10.200.131.36 port: 7890

_________________________________________________________

7766 /opt/SUNWdsee/ds6/lib/64/ns-slapd 7890 Directory Server

peername: AF_INET 10.200.131.36 port: 7890

_________________________________________________________

Posted at 10:58AM Jul 21, 2008 by Jonathan Gershater in Identity & Directory Server |

Thursday Jun 26, 2008

Sun Directory Server 6.x and SSL - once and for all! :)

Sun Directory Server 6 and SSL

I have seen several postings requesting help for communicating with Sun Directory Server over SSL.

This posting serves to clarify confusion and provide tools and tips for testing SSL communication between Sun Directory Server and clients. This blog posting assumes basic SSL knowledge.Links to background information is provided in the references below.

For purposes of this blog posting assume:

Sun Directory Server commands: /opt/SUNWdsee/ds6/bin

Sun Directory Server instance: /var/opt/SUNWdsee/dsins1

Consequently, the Sun Directory Server certificate directory is : /var/opt/SUNWdsee/dsins1/alias

The following files are in the certificate directory:

cert8.db key3.db slapd-cert8.db

certmap.conf secmod.db slapd-key3.db

This blog posting uses

The Sun Directory commands located in /opt/SUNWdsee/ds6/bin
Certutil located in /usr/sfw/bin on Solaris 10. If certutil is not on your server, download the Sun Directory Resource kit

# unzip dsrk52-SunOS5.8_OPT.zip

# java DSRK

You can install the resource kit into any directory you choose. The following notes assume that the installation location is: the /opt/dsrk directory. Add /opt/dsrk/lib to your LD_LIBRARY_PATH environment variable.

Server configuration

List certificates in the database

Using dsadm:

# ./dsadm list-certs -i /var/opt/SUNWdsee/dsins1

Alias Valid from Expires on Self-signed? Issued by Issued to

----------- ---------------- ---------------- ------------ ------------------------------------------------------------------- -------------------------------------------------------------------------------------

defaultCert 2008/01/22 19:15 2008/04/22 19:15 y CN=myserver,CN=636,CN=Directory Server,O=Sun Microsystems Same as issuer

Using certutil

# /usr/sfw/bin/certutil -L -P slapd- -d /var/opt/SUNWdsee/dsins1/alias

defaultCert CTu,u,u

The certificate listed above, defaultCert, is the self-signed certificate, valid for 90 days, that is installed with the Directory Server.

View certificates

View the certificates in the certificate database as follows

Using dsadm

In humanly readable format

# cd /opt/SUNWdsee/ds6/bin

# ./dsadm show-cert -F readable /var/opt/SUNWdsee/dsins1 defaultCert

click here to view the certificate

In ASCII format

# ./dsadm show-cert -i -F ascii /var/opt/SUNWdsee/dsins1 defaultCert

-----BEGIN CERTIFICATE-----

MIICJjCCAY+gAwIBAgIFAIiKjf8wDQYJKoZIhvcNAQEEBQAwVzEZMBcGA1UEChMQ

U3VuIE1pY3Jvc3lzdGVtczEZMBcGA1UEAxMQRGlyZWN0b3J5IFNlcnZlcjEMMAoG

A1UEAxMDNjM2MREwDwYDVQQDEwhzczcyZWQwMTAeFw0wODAxMjIxOTE1NTNaFw0w

ODA0MjIxOTE1NTNaMFcxGTAXBgNVBAoTEFN1biBNaWNyb3N5c3RlbXMxGTAXBgNV

BAMTEERpcmVjdG9yeSBTZXJ2ZXIxDDAKBgNVBAMTAzYzNjERMA8GA1UEAxMIc3M3

MmVkMDEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOGafiLwFn+EK9T2w6+/

+165oUnLDm4c8XP+AOIxLJJzqEtP5Avti4294JBdcwTKnKoJ2Fn8xKnhwwOsH8/K

LzmbKh+GwGQ/4LMwmSo1CQBoDerqk6q6OqEdjdz3TFR/yy7bY4arrPSvcegizzfp

cJHH1pkm1tRyGu8b+8Dvtk7FAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAa3c6RN/E

X/rxR12c/LetR2Cwxw6lxmEE13zMkOg7HC1xxKvVrhvhV2/Zeen0cJyla3udu7aT

IwwItZgKJhupESFZtQR4GXETmJT/W3ctyJyUMf9HjELYqc2v8R/o+t3QaF16g6ZY

qyJXWHPSe45blfTKoXG6afXi2XJfvfzQ4jg=

-----END CERTIFICATE-----

(note that der format, ./dsadm show-cert -i -F der /var/opt/SUNWdsee/dsins1 defaultCert, the output is not humanly readable and thus not demonstrated here.)

Using Certutil

The CertUtil utility will also display the certificates

# /usr/sfw/bin/certutil -L -n defaultCert -P slapd- -d /var/opt/SUNWdsee/dsins1/alias

Request and install certs from your Certificate Authority

This procedure describes how you request and install digial certificates from a Certificate Authority.

Certificate request

To install certificates from a certificate authority, proceed as follows:

Generate the certificate request. The format of the request, der or ascii, may depend on your certificate authority. The example below is in der format which is not humanly readable. The request is PKCS 10 format.

/opt/SUNWdsee/ds6/bin/dsadm request-cert --city "My City" --country "US" -F der --name myserver --org "my org" -o /tmp/CertReq --state CA /var/opt/SUNWdsee/dsins1

The above request is in “DER” format (-F der) which is not humanly readable. If the request above was in ascii format (-F ascii) then the output file would read as follows:

# more /tmp/CertReq

Certificate request generated by Sun-Java(tm)-System-Directory/6.2

Common Name: myserver

Email: (not specified)

Phone: (not specified)

Organization:my organization

State: CA

Country: US

-----BEGIN NEW CERTIFICATE REQUEST-----

MIIBsDCCARkCAQAwcDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAkNBMRQwEgYDVQQHEwtGb3N0ZXIgQ2l0eTEZMBcGA1UECxMQVW5peCBFbmdpbmVlcmluZzEQMA4GA1UEChMHSW5vdmFudDERMA8GA1UEAxMIc3M3MmVkMDEwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANLpKOwMCjxcnYd5LUO30Z3+m7RRfypec59qDKwVxVMQVnvAVlhz5u6ZFijlpBozcxXJ6iz4fZ9y/arZx4J7jB+3xGd2eKpS2crQ1NX+NPj3GtmbIA+VphP1UOcCr3Jf4j8KC6b4y/ZJOAyQqihn9saO6aN8HRt4XgZ6/D8yYRHhAgMBAAGgADANBgkqhkiG9w0BAQQFAAOBgQBVWjxx6LBau5C/ew0+lmgQ37GBYvDd+iHfdMggpjiyQs4fRxhqr5iU3AwptfpWsZuAtM4cXTqcE/3eTz8GkUYnjy+7YrggrUsFIYYSineQ5OyMYXd2KenPRq1aQGXeBEapKNFwwsuX6pG7xts5oIJ3xPWvtGmrJjLIa+QKCPs78Q==

-----END NEW CERTIFICATE REQUEST-----

Send the above to your certificate authority (CA)

The CA will then send a digital certificate for you to install in your Directory Server. This certificate allows clients to communicate with your server over SSL.

You should also request the signing certificate from your CA. This allows clients to trust the server certificate requested above. You may need multiple signing certificates, the rootCA certificate and any intermediary signing certificates, depending on the configuration of your CA.

Install CA certificates

To install the server and CA signing certificates proceed as follows

Upload the file to the Directory Server as /tmp/CertFile

Upload these to the Directory Server as /tmp/CACert

Installing the server certificate:

Using certutil

# /usr/sfw/bin/certutil –A –n exampleCert –t u,u,u -d /var/opt/SUNWdsee/dsins1/alias –i /tmp/CertFile

Using dsadm:

#/opt/SUNWdsee/ds6/bin/dsadm add-cert /var/opt/sun/dsins1 server-cert /tmp/CertFile

Setting the default certificate

Set the above server certificate as the default server certificate. This is required so that when the client communicates with the server, the server will present the CA certificate to the client. The client can then authenticate the certificate presented:

/opt/SUNWEdsee/ds6/bin/dsconf set-server-prop -e -p 389 ssl-rsa-cert-name:exampleCert

Installing the CA signing certificates:

Using dsadm

/opt/SUNWdsee/ds6/bin dsadm add-cert -C /var/opt/sun/dsins1 CACert /tmp/CACert

Using certutil

# /usr/sfw/bin/certutil –A –n CA –t CT,, -d /var/opt/SUNWdsee/dsins1/alias –i /tmp/CACert

View the certificates :

Using certutil

/usr/sfw/bin/certutil -L -P slapd- -d /var/opt/SUNWdsee/dsins1/alias

defaultCert Ctu,u,u – default self signed certificate installed with Directory Server

ServerCert u,u,u – server certificate provided by your Certificate Authority

Root CA CT,, - RootCA signiing certificate

Using dsadm

# /opt/SUNWdsee/ds6/bin/dsadm list-certs /var/opt/SUNWdsee/dsins1

Restart Directory Server

/opt/SUNWdsee/dsadm restart /var/opt/SUNWdsee/dsins1

Clients

Now, you need to install the server and rootCA certificates on each client that wishes to communicate with the server over SSL

Create the certificate database.

Execute these commands as root to create the database in the directory: /var/ldap.

/opt/dsrk/lib/nss/bin/certutil -N -d /var/ldap

Set permissions to be readable by all.

chmod 644 /var/ldap/*.db

Note that Solaris 8 & 9 use certificate databases in cert7.db format. The certutil utility that ships with the Solaris 9 OS in /usr/sfw/bin creates a cert8.db database. To create a cert7.db database, you must use the certutil utility in the Sun Directory Resource Kit. See introduction to this blog posting.

Retrieve the certificates from your Directory server as follows:

Export the server certificate and CA signing certificate.

./dsadm export-cert -o /tmp/ServerCert /var/opt/SUNWdsee/dsins1 myserver

Choose the PKCS#12 file password:

Confirm the PKCS#12 file password:

Copy the certificates to each client

Copy the from the file /tmp/ServerCert from the Directory server to the client.

Also copy the RootCA certificate you received from your CA above to the client

Import the certificates into the databases created above

Import both the Directory Server SSL certificate and the CA signing certificate into the certificate database created above. The example’s certificates are in ASCII PEM format.

certutil -A -a –i /tmp/RootCert -n “RootCA” -t “CT” -d /var/ldap

certutil -A -n "ServerCertificate" -i /var/tmp/ServerCert-a -t “CT” -d /var/ldap