Monday, October 31, 2011

Identity & access management product's


VendorProduct
CACA Identity Manager
CA Role & Compliance Manager
CA SiteMinder
CA SOA Security Manager
CA Federation Manager
CA Embedded Entitlements Manager
CA Single Sign-On
CA Directory
CA Access Control
CourionAccountCourier
RoleCourier
ComplianceCourier
PasswordCourier
CertificateCourier
Hitachi ID SystemsHitachi ID Management Suite
IBMTivoli Identity Manager
Tivoli Federated Identity Manager
Tivoli Security Policy Manager
Tivoli Access Manager for Enterprise Single Sign-On
Tivoli Directory Server
Tivoli Directory Integrator
Tivoli Compliance Insight Manager
Tivoli Security Information and Event Manager
Tivoli Access Manager for e-business
Sun Microsystems(Now Oracle)Sun Identity Manager(Oracle Waveset)
Sun Role Manager(OA)
Sun Compliance Manager
Sun OpenSSO Enterprise(Oracle Open SSO)
Sun Directory Server Enterprise Edition(ODSEE)
Microsoft Active Directory Domain Services
Active Directory Federation Services
Active Directory Lightweight Directory Services
Active Directory Certificate Services
Forefront Identity Manager
Intelligent Application Gateway
SAPSAP NetWeaver Identity Management
SAP BusinessObjects Access Control application
NovellCompliance Management Platform
Identity Manager and Roles Based Provisioning Module
Designer for Identity Manager
Access Manager
eDirectory
OracleOracle Identity Manager
Oracle Access Manager
Oracle Identity Federation
Oracle Internet Directory
Oracle Virtual Directory

Tuesday, October 11, 2011

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

Sun Directory Server certificate installation and renewal

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



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=\*"

Seeting up SSL on Tomcat

Setting up SSL on Tomcat is easy and you don’t have to do much for converting your web application to work with the Https protocol. But however, the problem you would find to set up SSL is the documentation available over the web. The documentation source is available on the Apache site but it starts off good and ends with a lot of confusion. Especially I was confused on the OpenSSL part where it says to use OpenSSL.
It might be good in a production environment to use OpenSSL but if you just want to test out SSL with Tomcat alone then it is more than enough to just have your JDK and Tomcat setups. So I would make you walk through the same steps which I did while getting SSL up and running and building a secured web app within a matter of minutes.
The things which I have used to setup SSL consists of:
  • JDK 1.6
  • Tomcat 6
Even though I have used the latest version I don’t see any problems which you might face in carrying out the same set of steps for JDK 1.5 which I am about to explain. JDK comes shipped with a keytool executable which is required to generate a keystore. The keytool can be found in the earlier version of JDK too. The 3 steps which would make you to get started with setting up SSL are:
  1. Generating the Keystore file
  2. Configuring Tomcat for using the Keystore file
  3. Configuring your web application to work with SSL
Let’s get this party started now.
1. Generating the KeyStore file
The keystore file is the one which would store the details of the certificates necessary to make the protocol secured. Certificates contain the information as to who is the source from which you are receiving the application data and to authenticate whether it is the intended party or not. To make this keystore you would have to use the keytool. So open command prompt in Windows or the shell in Linux and type:
cd %JAVA_HOME%/bin on Windows
cd $JAVA_HOME/bin on Linux
You would land up in the Java bin directory. Now time to run the keytool command. You have to provide some parameters to the command as follows :
keytool -genkey -alias trace -keypass testadmin -keystore trace.bin -storepass testadmin
The highlighted words are the ones which you would have to change according to your requirements. But keep one thing in mind that both the keypass and storepass passwords should be the same. The .bin file is actually your keystore file. It would now start a questionnaire. So fill in the relevant details accordingly. Look below for a reference as to what to answer for the questions.
What is your first and last name?
[Unknown]: pankaj api
What is the name of your organizational unit?
[Unknown]: home
What is the name of your organization?
[Unknown]: trace
What is the name of your City or Locality?
[Unknown]: Delhi
What is the name of your State or Province?
[Unknown]: India
What is the two-letter country code for this unit?
[Unknown]: IN
Is CN=pankaj api, OU=home, O=trace, L=Delhi, ST=India, C=IN correct?
[no]: yes

The command would then conclude. It would make a .bin file with the name you had provided inside the bin directory itself. In my case it was trace.bin which was located in
C:\Program Files\Java\jdk1.6.0_02\bin\
Put the .bin file in the webapps directory of Tomcat. This is required to avoid the need to give an absolute path of the file in the next step.
2. Configuring Tomcat for using the Keystore file
Here we would be making some changes to the server.xml file inside tomcat to tell it to use the keystore which was created in the earlier step for configuring SSL. Open the file server.xml which can be found as:
<CATALINA_HOME>/conf/server.xml
Now you have to modify it. Find the Connector element which has port=”8443″ and uncomment it if already not done. Add two lines. The highlighted lines are the newly added ones.
<Connector port=”8443″
maxThreads=”150″ minSpareThreads=”25″ maxSpareThreads=”75″
enableLookups=”true” disableUploadTimeout=”true”
acceptCount=”100″ debug=”0″ scheme=”https” secure=”true”
clientAuth=”false” sslProtocol=”TLS”
keystoreFile=”../webapps/trace.bin”
keystorePass=”testadmin” />

You can notice that I have given the path to the keystoreFile property as relative to tomcat bin directory because the startup command will look for the .bin file. Now all you have to do is start your server and check the working of SSL by pointing your browser to the URL to:
https://localhost:8443/
Now that you have your tomcat running in the SSL mode you are ready to deploy an application to test its working. You must note that still your tomcat can run in normal mode too at the same time i.e on port 8080 with http. So it is but obvious that any application deployed to the server will be running on http and https at the same time. This is something that we don’t want. We want our application to run only in the secured mode.
3. Configuring your web application to work with SSL
In order to do this for our test, take any application which has already been deployed successfully in Tomcat and first access it through http and https to see if it works fine. If yes, then open the web.xml of that application and just add this XML fragment before web-app ends i.e </web-app>
<security-constraint>
<web-resource-collection>
<web-resource-name>securedapp</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

Explanation of the fragment is beyond the scope of this tutorial but all you should notice is that the /* indicates that now, any resource in your application can be accessed only with https be it Servlets or JSP’s. The term CONFIDENTIAL is the term which tells the server to make the application work on SSL. If you want to turn the SSL mode for this application off then just turn don’t delete the fragment. Just put the value as NONE instead of CONFIDENTIAL. That’s it!
Conclusion
These were the 3 easy steps in which you can make Tomcat to work in the SSL mode and also it tells you how easily you can turn the SSL mode on and off. If you find any difficulty or are not clear on any of the above steps feel free to drop in your queries. If you like this tutorial it would be nice of you to drop in a comment of appreciation or feedback as to how this tutorial can be improved.

Maven for Java Application's

Maven for java

Maven is a Java tool, so you must have Java installed in order to proceed.

First, download Maven and follow the installation instructions. After that, type the following in a terminal or in a command prompt:
mvn --version
It should print out your installed version of Maven, for example:
Maven version: 2.0.8
Java version: 1.5.0_12
OS name: "windows 2003" version: "5.2" arch: "x86" Family: "windows"
Depending upon your network setup, you may require extra configuration. Check out the Guide to Configuring Maven if necessary.

Creating a Project

On your command line, execute the following Maven goal:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
If you have just installed Maven, it may take a while on the first run. This is because Maven is downloading the most recent artifacts (plugin jars and other files) into your local repository. You may also need to execute the command a couple of times before it succeeds. This is because the remote server may time out before your downloads are complete. Don't worry, there are ways to fix that.
You will notice that the generate goal created a directory with the same name given as the artifactId. Change into that directory.
cd my-app
Under this directory you will notice the following standard project structure.
my-app
|-- pom.xml
`-- src
    |-- main
    |   `-- java
    |       `-- com
    |           `-- mycompany
    |               `-- app
    |                   `-- App.java
    `-- test
        `-- java
            `-- com
                `-- mycompany
                    `-- app
                        `-- AppTest.java
The src/main/java directory contains the project source code, the src/test/java directory contains the test source, and the pom.xml is the project's Project Object Model, or POM.

The POM

The pom.xml file is the core of a project's configuration in Maven. It is a single configuration file that contains the majority of information required to build a project in just the way you want. The POM is huge and can be daunting in its complexity, but it is not necessary to understand all of the intricacies just yet to use it effectively. This project's POM is:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>Maven Quick Start Archetype</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

What did I just do?

You executed the Maven goal archetype:generate, and passed in various parameters to that goal. The prefix archetype is the plugin that contains the goal. If you are familiar with Ant, you may conceive of this as similar to a task. This goal created a simple project based upon an archetype. Suffice it to say for now that a plugin is a collection of goals with a general common purpose. For example the jboss-maven-plugin, whose purpose is "deal with various jboss items".

Build the Project

mvn package
The command line will print out various actions, and end with the following:
 ...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 seconds
[INFO] Finished at: Thu Oct 05 21:16:04 CDT 2006
[INFO] Final Memory: 3M/6M
[INFO] ------------------------------------------------------------------------
Unlike the first command executed (archetype:generate) you may notice the second is simply a single word - package. Rather than a goal, this is a phase. A phase is a step in the build lifecycle, which is an ordered sequence of phases. When a phase is given, Maven will execute every phase in the sequence up to and including the one defined. For example, if we execute the compile phase, the phases that actually get executed are:
1.    validate
2.    generate-sources
3.    process-sources
4.    generate-resources
5.    process-resources
6.    compile
You may test the newly compiled and packaged JAR with the following command:
java -cp target/my-app-1.0-SNAPSHOT.jar com.mycompany.app.App
Which will print the quintessential:
Hello World!

Running Maven Tools

Maven Phases

Although hardly a comprehensive list, these are the most common default lifecycle phases executed.
  • validate: validate the project is correct and all necessary information is available
  • compile: compile the source code of the project
  • test: test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
  • package: take the compiled code and package it in its distributable format, such as a JAR.
  • integration-test: process and deploy the package if necessary into an environment where integration tests can be run
  • verify: run any checks to verify the package is valid and meets quality criteria
  • install: install the package into the local repository, for use as a dependency in other projects locally
  • deploy: done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
There are two other Maven lifecycles of note beyond the default list above. They are
  • clean: cleans up artifacts created by prior builds
  • site: generates site documentation for this project
Phases are actually mapped to underlying goals. The specific goals executed per phase is dependant upon the packaging type of the project. For example, package executes jar:jar if the project type is a JAR, and war:war is the project type is - you guessed it - a WAR.
An interesting thing to note is that phases and goals may be executed in sequence.
mvn clean dependency:copy-dependencies package
This command will clean the project, copy dependencies, and package the project (executing all phases up to package, of course).

Generating the Site

mvn site
This phase generates a site based upon information on the project's pom. You can look at the documentation generated under target/site.

Conclusion

We hope this quick overview has piqued your interest in the versitility of Maven. Note that this is a very truncated quick-start guide. Now you are ready for more comprehensive details concerning the actions you have just performed. Check out the Maven Getting Started Guide.


Monday, October 10, 2011

How to improve disk I/O performances with VMware Workstation


Even on a 2 GB RAM workstation (as mine) VMware virtual machines can run slowly. Too slowly sometimes.
This can depend on a large amount of factors but we can reduce the number to 4 critical issues:
1.                 Antivirus real-time protection
You probably run VMware Workstation on your everyday working computer, and you probably want to stay secure running an antivirus software.

The most useful feature of any AV is the real-time protection, catching and monitoring I/O accesses of every process for suspicious activities. This feature can greatly impact on your VMs performances and should be fine-tuned for virtualization.

So be sure to create an exclusion filter on your real-time protection settings for .vmdk (VMware virtual disk) and .vmem (VMware virtual memory) files. In this way countinous I/O operations on your virtual machines will not be hit by antivirus checking.

Note: if you plan to run liveCD operating systems (like Knoppix) inside your VMs or simply often use CD images for installing new software, I highly recommend to exclude .iso files too from AV checking.
2.                 HostOS disk fragmentation
A really performance hitter for virtual machines is a fragmented host OS disk.

VMs virtual disks are very large (4 GBs at minimum on the average) and are created by default as non preallocated. In other words your virtual disk grow as you install more software on the guest OS till reaching your defined disk limit.
If you use only one physical disk for everyday work and VMs storing, you probably will use space around a growing virtual disk, obliging your host OS to fragment virtual machines more and more.

So be sure to:
1.       Create a dedicated partition for virtual machines only
2.       Create guest OSes virtual disks with Allocate all disk space now option
3.       Schedule a daily defragmentation for your virtual machines directories (maybe at launch time or during the night)
3.                 Memory trimming
Workstation checks which part of the guest OS virtual memory is not used and allocates it back to the host OS. This permits to have more concurrent virtual machines running but everytime the guest OS asks back for its memory it suffers a performance degradation.

So, if you have enough free RAM for all planned concurrent VMs, be sure to disable memory trimming for guest OSes adding the following line to the virtual machine configuration (.vmx) file:

MemTrimRate=0

Note: Memory trimming can be disabled through GUI since Workstation 6.0.
4.                 Page sharing (quoted from VMware documentation)
VMware uses a page sharing technique to allow guest memory pages with identical contents to be stored as a single copy-on-write page. Page sharing decreases host memory usage, but consumes system resources, potentially including I/O bandwidth.

You may want to avoid this overhead for guests for which host memory is plentiful and I/O latency is important. To disable page sharing, add the following line to the virtual machine configuration (.vmx) file:

sched.mem.pshare.enable=FALSE option
These suggestions will work well for every VMware Workstation 5.x and Player 1.x since both share same engine.