Monday Jul 21, 2008

A useful script for troubleshooting UNIX processes and TCP ports

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

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

_________________________________________________________


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




List the newly imported certificates

To List the certificates you have stored in the key database:

# /usr/sfw/bin/certutil -L -d /var/ldap

RootCA CT,,

ServerCertificate CT,,


Test SSL connectivity

Using openSSL


Use the openSSL utility to test connectivity, where myserver.example.com is the name of your Directory Server. This command verifies connnectivity and displays all certificates, as I have highlighed in red font.


# /usr/sfw/bin/openssl s_client -host myserver.example.com -port 636 -showcerts -verify 3


verify depth is 3

CONNECTED(00000004)

depth=2 /C=US/O=example.com/OU=my organization/CN=Root CA

verify error:num=19:self signed certificate in certificate chain

verify return:1

depth=2 /C=US/O=example.com/OU=my organization/CN=Root CA

verify return:1

depth=1 /C=US/O=example.com/OU=my organization/CN=servercert

verify return:1

depth=0 /L=my City/ST=CA/C=US/O=example.com/OU=my organization/CN=myserver.example.com

verify return:1

---

Certificate chain

0 s:/L=my City/ST=CA/C=US/O=example.com/OU=my organization/CN=myserver.example.com

i:/C=US/O=example.com/OU=my organization/CN=servercert

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

MIID5jCCA0+gAwIBAgIQCTh7EiukoaUCIo4JE4L9ZTANBgkqhkiG9w0BAQUFADBi

MQswCQYDVQQGEwJVUzENMAsGA1UEChMEVklTQTEvMC0GA1UECxMmVmlzYSBJbnRl

cm5hdGlvbmFsIFNlcnZpY2UgQXNzb2NpYXRpb24xEzARBgNVBAMTClZJIENBVGVz

dDIwHhcNMDcwNzE3MTI1MTIxWhcNMTYwODIxMjI0NDQ1WjB8MRQwEgYDVQQHEwtG

b3N0ZXIgQ2l0eTELMAkGA1UECBMCQ0ExCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdJ

bm92YW50MRkwFwYDVQQLExBVTklYIEVuZ2luZWVyaW5nMR0wGwYDVQQDExRzczU1

c2pzZHNxMS52aXNhLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxjCg

g3ajsBRadLJo3pqlPyPT4Y4b/5NKA1qWYIEDdsbbL6yJ1hcFfvPrsklaku9yR2Tu

I8bD6jpSRzgI1y3dGijepKYjSVsHLRlOmS6o2+FuxjJ+/F01K2+Rf6xMkdxBzvtx

8ozbgXRJvpzqYno9Y9rX0fOR/xR1042nt5zHGRsCAwEAAaOCAYEwggF9MB8GA1Ud

IwQYMBaAFOU0kJQJkbC6bQoi16wbr80+rYdyMAwGA1UdEwEB/wQCMAAwZQYDVR0g

BF4wXDBaBgQqAwQFMFIwFQYIKwYBBQUHAgEWCTEuMi4zLjQuNTA5BggrBgEFBQcC

AjAtMBgWEVJlcGxhY2UgVGhpcyBUZXh0MAMCAQEaEVJlcGxhY2UgVGhpcyBUZXh0

MIG1BgNVHR8Ega0wgaowKaAnoCWGI2h0dHA6Ly8xMC4yMDMuMTAxLjE5Ni9WSUNB

VEVTVDIuY3JsMH2ge6B5hndsZGFwOi8vMTAuMjAzLjEwMS4xOTY6Mzg5L2NuPVZJ

IENBVEVTVDIsYz1VUyxvdT1WaXNhIEludGVybmF0aW9uYWwgU2VydmljZSBBc3Nv

Y2lhdGlvbixvPVZJU0E/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDAOBgNVHQ8B

Af8EBAMCAzgwHQYDVR0OBBYEFC+QNOgvl88QGNULG/a3qD6ZhdeCMA0GCSqGSIb3

DQEBBQUAA4GBAF4VU0P7Y77FCFePK7nWzO3up6rmKiclucbFnzLiplX3bGrjsowK

GhMQObZz8oqJUvxNYIj5NfE+yOv1a/pRCGl3ss0+oyomYs9HcYVUTWiZwz4xEzDq

rzlIN/RzR4COQoYjDKmhLjcM6y1NKi7FiAXoUNsrwgU1jimMfzKMes47

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

1 s:/C=US/O=example.com/OU=my organization/CN=servercert

i:/C=US/O=example.com/OU=my organization/CN=Root CA

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

MIIEGjCCAwKgAwIBAgIQdtBxrG5ZtJqGl96G5ZEtMzANBgkqhkiG9w0BAQUFADB3

MQswCQYDVQQGEwJVUzENMAsGA1UEChMEVklTQTEvMC0GA1UECxMmVmlzYSBJbnRl

cm5hdGlvbmFsIFNlcnZpY2UgQXNzb2NpYXRpb24xKDAmBgNVBAMTH1RFU1QgVmlz

YSBJbmZvIERlbGl2ZXJ5IFJvb3QgQ0EwHhcNMDYwNTIyMTgyNzAyWhcNMjUwODEy

MjI0OTE0WjBiMQswCQYDVQQGEwJVUzENMAsGA1UEChMEVklTQTEvMC0GA1UECxMm

VmlzYSBJbnRlcm5hdGlvbmFsIFNlcnZpY2UgQXNzb2NpYXRpb24xEzARBgNVBAMT

ClZJIENBVGVzdDIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJRgW5/5yLoo

hjTS2Z0fQdDWokTVZ5klhOty8X+VjfaZBaYwCMjVQFv5g8c23I17PB80kfXaOgte

/PTKFpnSUSOTkGby8IX0dbay+wuoCSLtyOziJvMsbuuru54HMZCcgG6BbfO0WoOD

ZINeuDGD7MvJwnXFFp0CedqrvqkXbHeXAgMBAAGjggE5MIIBNTAfBgNVHSMEGDAW

gBS9YtV/j2zkYg7yp/mhmOrCuJ7nBTASBgNVHRMBAf8ECDAGAQH/AgEAMBIGA1Ud

IAQLMAkwBwYFZ4EDAgEwgboGA1UdHwSBsjCBrzB0oHKgcIZuTERBUDovL3N3NTUw

cWFwa2lsZG0xLnFhY2EuY29tOjM4OS9DTj1WSSUyMENBVGVzdDIsT1U9VmlzYSUy

MEludGVybmF0aW9uYWwlMjBTZXJ2aWNlJTIwQXNzb2NpYXRpb24sTz1WSVNBLEM9

VVMwN6A1oDOGMWh0dHA6Ly93d3cuaW50bC52aXNhY2EuY29tL2NybC9URVNUVklT

QVJPT1RDQS5jcmwwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTlNJCUCZGwum0K

ItesG6/NPq2HcjANBgkqhkiG9w0BAQUFAAOCAQEArgbWFm1MJ22W/+M/M1Dg9eij

ecRsa7rj+Lw+/60ajssjzYcQlwWSOOnlpp8aMFYEojUABcPtSzb81SQy2kkONJw2

GtPNTkFeCKnO0O+EraPZ+YETPkOJhM8xzr0lkeisfIg7+i4PCJcWHLZpJAUB9LGW

ZaoAe/XhXiiU1bOKSmyGHx5cUKYiKHuETou6EgEOeHWr9zlZiP5kdiO/JieG/Fft

fLClx2uJslKXzbnOlxEZ2gPBg20Bz3ykUgVL3mgHSchAwSTFjn6ZD7A4LkAuSLiA

7k4DEQXqwT7nX8c92WbKTTwWIrRIPMwUv2FcYPUkSwrqrbDJEWS9KsXv6oVymA==

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

2 s:/C=US/O=example.com/OU=my organization/CN=Root CA

i:/C=US/O=example.com/OU=my organization/CN=Root CA

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

MIID7zCCAtegAwIBAgIQU1BiyIG7uNak0ERa1HN39TANBgkqhkiG9w0BAQUFADB3

MQswCQYDVQQGEwJVUzENMAsGA1UEChMEVklTQTEvMC0GA1UECxMmVmlzYSBJbnRl

cm5hdGlvbmFsIFNlcnZpY2UgQXNzb2NpYXRpb24xKDAmBgNVBAMTH1RFU1QgVmlz

YSBJbmZvIERlbGl2ZXJ5IFJvb3QgQ0EwHhcNMDUwODE2MjI0ODUzWhcNMjUwODE1

MjI0ODUzWjB3MQswCQYDVQQGEwJVUzENMAsGA1UEChMEVklTQTEvMC0GA1UECxMm

VmlzYSBJbnRlcm5hdGlvbmFsIFNlcnZpY2UgQXNzb2NpYXRpb24xKDAmBgNVBAMT

H1RFU1QgVmlzYSBJbmZvIERlbGl2ZXJ5IFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEB

AQUAA4IBDwAwggEKAoIBAQDcvYrZ3WNJc/H6UOhuu2im3KY18IZlTo86wn9ICgF8

KPqnmOZPLY1Ehn9xoxZNag7mCMBnvAdwW3/N/mWFPa+S023KvikhgYYwDnLXnwwN

cG1pZdETx6w9OVRl/C8xHoQUYIJ/HNSn/mDUELpljhs8uavAXYkOBQtRX3pD/9h4

uJSZWm8R/1QUx51AIq+ly9a6/AWn7qj+bwD8XxjPRVRyYs71MEmIlmkIz3jAfA2p

xH8ZZ3I820VvdhE1AL/ffwFiy7AgN+oVomIlZPwB06L20zL7+1EVp61pTWDF9nmp

bo3r0lKeyRy+81NL675sylzePjPN4z/5Qo1N9pVOH551AgMBAAGjdzB1MA8GA1Ud

EwEB/wQFMAMBAf8wEgYDVR0gBAswCTAHBgVngQMCATAOBgNVHQ8BAf8EBAMCAQYw

HwYDVR0jBBgwFoAUvWLVf49s5GIO8qf5oZjqwrie5wUwHQYDVR0OBBYEFL1i1X+P

bORiDvKn+aGY6sK4nucFMA0GCSqGSIb3DQEBBQUAA4IBAQAa0cCJEFGiDSF9D4UT

BPXkBrvGGZy94MwsN0YKsvLJTBxCXX/PQXS9JX29nsY4a5PAAhgdNV76tUiqUSkb

VEULQfNz8HtlBSVRxkQoglxu2zOGdXeXpsxzr2xoZP3NVLleBntcb3YfA3E3caHB

6I2V1MIS1scOw4xwmz9VOM1I9FnLEbNuNJsgXmpdO1YoSs0mgf+XpsxM00sQXuYO

4bFqv/GIDHd6z0mzKiXYytcF6bXRwoQr2LUBs5LwvpErcgiDDzCMyyXDI/2MJdPZ

Mkko/VaTlXMCX9dMY5d3fxZAlHTLA7OcJbeZjqV2SWeKSaVXjgmvNJNytfx/pZ3M

5qcy

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

---

Server certificate

subject=/L=my City/ST=CA/C=US/O=example.com/OU=my organization/CN=myserver.example.com

issuer=/C=US/O=example.com/OU=my organization/CN=servercert

---

Acceptable client certificate CA names

/C=US/O=example.com/OU=my organization/CN=servercert – CA signed server certificate received with our request

/C=US/O=example.com/OU=my organization/CN=Root CA – root CA signing certificate

/O=Sun Microsystems/CN=Directory Server/CN=636/CN=myserver – default self signed certificate

---

SSL handshake has read 3554 bytes and written 334 bytes

---

New, TLSv1/SSLv3, Cipher is AES256-SHA

Server public key is 1024 bit

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1

Cipher : AES256-SHA

Session-ID: 5DBEF47FCD5B642D41F4974690EA4A8FA1B7964242C39898E86AA3492496C6BB

Session-ID-ctx:

Master-Key: 75B8E8BA280D6794F7177416679C3170B7F1A45F21EF1461D230221872E157EF5F1822C28E5FFF327244E8B818FAAB7C

Key-Arg : None

Start Time: 1214502072

Timeout : 300 (sec)

Verify return code: 19 (self signed certificate in certificate chain)



---

Using secure LDAP search



  • Solaris 8 default ldapsearch does not have SSL capability, unless you have the the ldapclient patch 108993

  • Solaris 9 default ldapsearch does not have SSL capability, but the iplanet ldapseach does in /usr/iplanet/ds5/shared/bin/ldapsearch

  • Solaris 10 default ldapsearch does have SSL support .


/usr/bin/ldapsearch -v -h myserver.example.com -p 636 -Z -P /var/ldap/cert8.db -b "dc=example,dc=com"  -D "cn=directory manager" -w <password> "objectclass=\*"



Reference

OpenSSL


PKI reference guide


Formats

PEM

Can contain all of private keys (RSA and DSA), public keys (RSA and DSA) and (x509) certificates. It stores data Base64 encoded DER format, surrounded by ascii headers, so is suitable for text mode transfers between systems.

DER

Can contain all of private keys, public keys and certificates. It stored according to the ASN1 DER format. It is headerless - PEM is text header wrapped DER. It is the default format for most browsers.

PKCS#12

Also known as PFX files. Can contain all of private keys, public keys and certificates. It stores in a binary format.


Tuesday May 13, 2008

Two Directory servers listening on ports 389/636, on one server

The following procedure outlines how to configure a two (or more instances) of Sun Java Directory Server, both listening on non-secure port 389 and secure port 636.

This is useful in application testing where all applications require port 389/636 but you need two distinct Directories to ensure that data and configurations do not collide.

This procedure requires that you add a second virtual network interface.


View the current network settings

# ifconfig -a

lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1

inet 127.0.0.1 netmask ff000000

dmfe0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2

inet 10.200.131.36 netmask ffffff00 broadcast 10.200.131.255

ether 0:3:ba:7a:bb:ed


Create the second virtual interface

# ifconfig dmfe0:1 plumb


Assign an ip address to it

# ifconfig dmfe0:1 10.200.131.82 up


Add the secondhostname to /etc/hosts(or DNS)

# Internet host table

#

127.0.0.1 localhost

10.200.132.101 10.200.132.101

10.200.131.36 firsthostname.example.com firsthostname loghost

10.200.131.82 secondhostname.example.com secondhostname



Confirm the network interface is working

# ping 10.200.131.82

10.200.131.82 is alive


# ping secondhostname

secondhostname is alive


Create an instance of DSEE.

  • Ensure that you specify the second host name with the -h parameter

  • Temporarily provide a secure and non-secure port that is not in use (otherwise the create command will fail since ports 389 and 636 are already in use)


#/opt/SUNWdsee/ds6/bin/dsadm create -h secondhostname -p 1389 -P 1636 /var/opt/SUNWdsee/dsins2



Edit the dse.ldif of the new instance

  • Add the two lines in blue below

  • Change the the port numbers to 389 and 636 respectively.

#vi /var/opt/SUNWdsee/dsins2/config/dse.ldif


dn: cn=config

cn: config

.

.

.

nsslapd-enquote-sup-oc: off

nsslapd-listenhost: secondhostname

nsslapd-securelistenhost: secondhostname

nsslapd-localhost: secondhostname

nsslapd-schemacheck: on

nsslapd-syntaxcheck: off

nsslapd-requires-bind-password: on

nsslapd-rewrite-rfc1274: off

nsslapd-return-exact-case: on

nsslapd-port: 389

nsslapd-localuser: root

.

.

.

nsslapd-security: on

nsslapd-secureport: 636



Start the second instance

#/opt/SUNWdsee/ds6/bin/dsadm start /var/opt/SUNWdsee/dsins2

# Waiting for server to start...

Server started: pid=9570




References:

Directory Documentation Man Page

Friday May 02, 2008

Sun Java Identity Synchronization for Windows - bug fix!

If you are implementing Sun Java Identity Synchronization for Windows 6.0 and your user objects have auxiliary objects then you will likely hit bug 6691600. “Users with auxiliary objectclasses fail to link”


A fix is available, get it from Sun support


To implement the fix follow these steps


  1. stop the IMQ and ISW instances. (/etc/init.d/isw stop) & (/etc/init.d/imq stop)

  2. backup /opt/SUNWisw/lib/connector.jar

  3. Replace the connector.jar at the installation directory (/opt/SUNWisw/lib/connector.jar) with the one from support

  4. Repeat this procedure on all the hosts which has the Connectors installed.

  5. Start IMQ and ISW (/etc/init.d/imq start) & (/etc/init.d/isw start)


Java forums reference: http://forum.java.sun.com/thread.jspa?messageID=10234618&#10234618


Monday Apr 07, 2008

PwdLastAuthTime and cn=proxyagent

You might be wondering what the cryptic title to this blog entry is, allow me to explain:.

  • Sun Directory Server 6 introduced a new attribute in password policies, PwdLastAuthTime, that stores the last time a user authenticated to the Directory.

  • ProxyAgent is the default user in the profile used by native-ldap clients configured for proxy authentication.

Thus suppose:

  1. You have two or more Sun Directory servers in a multi-master replication configuration.

  2. That the Directory servers are deployed as a naming service used by native-ldap clients ( for authentication etc.) configured for proxy-authentication

  3. That you have configured a user-defined password policy to store PwdLastAuthTime.

The proxyAgent user object will authenticate to the Directory quite frequently to update the client profile etc. This proxy authentication is recorded by the Directory and in a replicated environment, you may notice your replication changelog file grows very quickly consuming disk-space. The documentation explicitly states “ Using this feature can affect performance. When you configure Directory Server to save pwdLastAuthTime timestamps, the server must perform an internal modify operation for each successful bind.

The solution to the problem of rapidly growing replication changelog files, is to apply a special password policy to the proxyagent user, not to record PwdLastAuthTime. See sample below:

LDIF file to create a custom password policy that logs PwdLastAuthTime and is assigned to all users by default

dn: cn=DirectorypwdPolicy,ou=ExamplePasswordPolicy,dc=visa,dc=com

changetype: add

objectclass: pwdPolicy

objectclass: sunPwdPolicy

objectclass: ldapsubentry

objectclass: top

cn: Example Password Policy

description: Example Password Policy

pwdAttribute: userPassword

pwdAllowUserChange: true

pwdGraceAuthNLimit: 0

pwdMustChange: False

pwdCheckQuality: 0

pwdMinAge: 0

pwdMaxAge: 2592000

pwdExpireWarning: 432000

pwdInHistory: 0

pwdSafeModify: true

pwdMaxFailure: 5

pwdFailureCountInterval: 0

pwdLockout: true

pwdLockoutDuration: 0

pwdIsLockoutPrioritized: true

pwdKeepLastAuthTime: true

passwordRootdnMayBypassModsChecks: on

passwordStorageScheme: SSHA

LDIF file to create a custom password policy that does not log PwdLastAuthTime

dn: cn=DirectorypwdPolicyPxyAgent,ou=ExamplePasswordPolicy,dc=Example,dc=com

changetype: add

objectclass: pwdPolicy

objectclass: sunPwdPolicy

objectclass: ldapsubentry

objectclass: top

cn: ExamplePassword Policy PxyAgent

description: Example Password Policy PxyAgent

pwdAttribute: userPassword

pwdAllowUserChange: true

pwdGraceAuthNLimit: 0

pwdMustChange: False

pwdCheckQuality: 0

pwdMinAge: 0

pwdMaxAge: 2592000

pwdExpireWarning: 432000

pwdInHistory: 0

pwdSafeModify: true

pwdMaxFailure: 5

pwdFailureCountInterval: 0

pwdLockout: false

pwdLockoutDuration: 0

pwdIsLockoutPrioritized: true

pwdKeepLastAuthTime: false

passwordRootdnMayBypassModsChecks: on

passwordStorageScheme: SSHA

LDIF file to assign the above password policy to the proxyagent user:

dn: cn=proxyagent,ou=profile,dc=example,dc=com

changetype: modify

add: pwdPolicySubentry

pwdPolicySubentry: cn=DirectorypwdPolicyPxyAgent,ou=ExamplePasswordPolicy,dc=Example,dc=com

For this blog entry, I decided to list the references below, rather than creating hyperlinks in the text above and thus distracting myself from the main text. I hope the reader finds this easier to read as well.

References:

Sun Directory Server 6 password policies

Applying password policies to an individual user

PwdLastAuthTime

LDAP as a naming service

Proxy authentication – see “Using Proxy Credentials”

Wednesday Feb 06, 2008

Israel Web Tour 2008 & בלוג רישון בעיברית

Sun Microsystems was a sponsor of the Israel Web Tour -representatives from 15 select Web 2.0 Israeli startups visiting Silicon Valley. Representatives from the startups visited the Sun Menlo Park campus, on Tuesday February 5th, where Juan Carlos Soto briefed them in the Sun Executive Business Center.
I was fortunate to get a ticket to the showcase which took place at Microsoft on Wednesday the 6th of February. Each of the 15 companies had five minutes to pitch their company's concept.
I was intrigued by:
1.5min    - user submitted content of “how to” guides.
2.AllofMe – you basically add photos and videos of yourself and your family and make an online movie of your life, relatives etc. What's neat is you can zoom in or out to view a snapshot of your life on a day or even over a century.
3.BlogTv – blogging via video. The IsraelWebTour showcase at Microsoft was broadcast via BlogTv.
4.Clicktale & nuConomy – web analytics beyond page views. In particular, Clicktale can make a video of a customer's entire interaction on your webpage. Thus for example, you can see why a customer completed half the shopping cart form and then discarded the transaction.  nuConomy will deliver reports on all customer interactions on your website.
5.Pageonce – an aggregation tool for all your finances, email, airline miles etc. It will also alert you, for example when a payment is due, when you are about to reach your maximum free cellular minutes or  when airline miles will expire.
6.Ply – a platform for video. They demo'd a cute video clip of the movie “When Harry met Sally” and the user can mouse over Sally and a little pop up window will display a brief bio of Meg Ryan.
7.Velingo (used to be Tagsense) – web search enhanced by tag words. Try it here: When I tried a search on Sun Microsystems, I got this: There is a firefox extension but for Windows only <sigh>

Now will have a go at blogging in Hebrew, painstakingly slow one letter at a time, as  I cannot touch-type in Hebrew

                                                                               סן מיפרו חברה טחנולוגי באמק הסיליקון נתמה חסות ל15 חברות ווב 2.0 לבקר אמק הסיליקון.

הם פגשו עים משקיעות וחברות.

נהנתי ליפגוש ישראלים וללמוד קצת ווב 2.0 תחנולוגים

Sunday Nov 11, 2007

Sun Directory Server 6.2 upgrade process



This blog entry outlines the process of upgrading the Sun Directory Server from version 6.0 to version 6.2


Assumptions

This procedure assumes the following:

  1. The operating system is Solaris SPARC.

  2. The PKG version of Directory Server 6.0 has been installed.

  3. The DCC is deployed in the Sun Java Web Console (not as a .war file in a J2EE container).

  4. The services are managed in SMF.

  5. The patches are downloaded to a directory “RequiredPatches”. Note: installation of the first patch requires a reboot, therefore do NOT download the patches to /tmp or /var/tmp (some systems) otherwise the files will be lost after the reboot.

  6. The installation paths are as follows:



Software

Instances

DSCC

Cacao

WebConsole

/opt/SUNWdsee

/var/opt/SUNWdsee/dsins1

/var/opt/SUNWdsee/dscc/ads

/var/cacao

/usr/share/webconsole


Patches required before upgrade

Inventory the patches on each server and establish what versions exist.

To inventory the patches, execute ‘showrev –p | grep “Patch: <patchnumber>”’

Example:

# showrev -p | grep "Patch: 119963"

Patch: 119963-05 Obsoletes: Requires: Incompatibles: Packages: SUNWlibC

Patch: 119963-08 Obsoletes: Requires: Incompatibles: Packages: SUNWlibC

#


The list of patches is in column one and is hyperlinked to enable download of the patch from sunsolve.sun.com


Patch to install

118833-36

119963-08

119254-44

125378-02

119810-04

119345-05

119044-03

123893-04

125937-05


Patches required to perform 6.2 upgrade



125276-05



Verify current version installed


Execute LDAPSEARCH to display the current version, substituting <PASSWORD> for the Directory Manager password.


# ldapsearch -h localhost -b cn=config -D "cn=directory manager" -w <PASSWORD> objectclass=nsslapdConfig nsslapd-versionstring

version: 1

dn: cn=config

nsslapd-versionstring: Sun-Java(tm)-System-Directory/6.0


Begin the upgrade process


Stop the processes


Disable DCC Directory server

# svcadm disable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dscc6-dcc-ads


Disable LDAP instance

# svcadm disable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1


Disable CACAO

#svcadm disable svc:/application/management/common-agent-container-1:default


Disable Java Web Console

#svcadm disable svc:/application/management/wbem:default

#svcadm disable svc:/system/webconsole:console


Installation of patches


Before installing patch 118836 a workaround for a small defect is required.

(see note here)


Workaround

#mkdir /var/tmp/118833-36.SUNWcslr


Click each of the following to view the output of the above patch installations



118833-36.txt see above workaround. Also, reboot after installing this patch.

119044-03.txt

119254-44.txt

119810-04.txt

123893-04.txt

125378-02.txt

125937-05.txt

Upgrade to Directory Server 6.2

Install patch 125276-05.txt


Restart Directory and Console services


Start cacaoagent

#svcadm enable svc:/application/management/common-agent-container-1:default


Start DCC

# svcadm enable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dscc6-dcc-ads


Start LDAP instance

# svcadm enable svc:/application/sun/ds:ds--var-opt-SUNWdsee-dsins1


Start Java Web Console

#svcadm enable svc:/application/management/wbem:default

#svcadm enable svc:/system/webconsole:console



Verify that server was upgraded

Execute LDAPSEARCH to display the current version, substituting <PASSWORD> for the Directory Manager password.


#ldapsearch -h localhost -b cn=config -D "cn=directory manager" -w <PASSWORD> objectclass=nsslapdConfig nsslapd-versionstring

version: 1

dn: cn=config

nsslapd-versionstring: Sun-Java(tm)-System-Directory/6.2


View the Directory Server documentation here

Friday Mar 09, 2007

Daylight savings time - software updates from Sun

Remember that daylight savings time begins this weekend

Ensure your software has the appropriate patches.






Technorati Tags: , , , ,

Monday Mar 05, 2007

A few Sun Java Directory Server 6.0 screenshots

  • Firstly the Sun Java Web Console, which you can use to manage all your applications installed on the server. Click here and you will see, the new Sun Directory Server 6.0 web console is simply a link from the Sun Java Web Console.
  • Secondly, here is a screenshot of the Sun Directory Server 6.0 web management console. Look at all the tools at your disposal in one web form.
  • Finally, actions you can perform on a Directory server. Now isn't that cool, changing the function of a server using a few browser clicks.

About

Jonathan Gershater

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