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....
JonathanPosted at 03:44PM Sep 16, 2008 by Jonathan Gershater in Personal | Comments[1]
Thursday Jul 31, 2008
Troubleshooting 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>
<Parameter name="saint.msg.type"
value="AUTH_REQUEST"/>
<Parameter
name="saint.msg.auth.challenge"
value="1520478070584ee7fc8fff54b80e7be9"/>
<Parameter
name="saint.msg.auth.sessionKey"
value="wpCg7gdltYuk7HdS5DfZ8YUUObMdJDGVI46mqm9YHqvfKrQwXFprFg=="/>
<Parameter
name="saint.msg.requestID" value="0"/>
</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
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 <
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 <
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
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
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! :)
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
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.
Posted at 04:42PM Jun 26, 2008 by Jonathan Gershater in Identity & Directory Server |
Monday Jun 16, 2008
Anonymous access and Solaris native-ldap clients
Since anonymous access to an entire Directory tree can be a security risk, this blog posting clarifies exactly what anonymous access is required by Solaris native-ldap clients.
When Solaris native-ldap clients are initialized they require anonymous access to the Sun Java Directory Server's baseDN and ou=profile container. The following acis configure the appropriate access.
the baseDN - (target = ldap:///dc=example,dc=com) (targetscope = base) (targetattr="*") (version 3.0; acl "anonymousBaseDN"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) .
For super secure access, this aci could be modified thus to only allow access to the nisDomain attribute
(target = ldap:///dc=example,dc=com) (targetscope = base) (targetattr="nisdomain") (version 3.0; acl "anonymousBaseDN"; allow (read, compare, search) (userdn = "ldap:///anyone") ;) .
the profile container - (target = "ldap:///ou=profile,dc=example,dc=com") (targetscope = subtree) (targetattr="*") (version 3.0; acl "anonymousProfile"; allow (read,compare,search) (userdn = "ldap:///anyone") ;)
For super secure access, this aci could be modified thus to only allow access to the proxyagent user object
(target = "ldap:///cn=proxyagent,ou=profile,dc=example,dc=com") (targetscope = subtree) (targetattr="*") (version 3.0; acl "anonymousProfile"; allow (all) (userdn = "ldap:///anyone") ;)
When a native-ldap client is initialized, the access required is visible, per this session below:
In red font, the client is searching for, and found, the baseDN.
In blue font, the client is searching for the profile, and the prompt for the password indicates the profile was found, and read, successfully.
# ./init_client.sh
Parsing domainName=example.com
Parsing profileName=exampleprofile
Parsing proxyDN=cn=proxyagent,ou=profile,dc=example,dc=com
Arguments parsed:
domainName: example.com
proxyDN: cn=proxyagent,ou=profile,dc=example,dc=com
profileName: exampleprofile
defaultServerList: 10.100.1.1
Handling init option
About to configure machine by downloading a profile
findBaseDN: begins
findBaseDN: ldap not running
findBaseDN: calling __ns_ldap_default_config()
found 2 namingcontexts
findBaseDN: __ns_ldap_list(NULL, "(&(objectclass=nisDomainObject)(nisdomain=example.com))"
rootDN[0] cn=changelog
NOTFOUND:Could not find the nisDomainObject for DN cn=changelog
findBaseDN: __ns_ldap_list(NULL, "(&(objectclass=nisDomainObject)(nisdomain=example.com))"
rootDN[1] dc=example,dc=com
found baseDN dc=example,dc=com for domain example.com
Proxy DN: cn=proxyagent,ou=profile,dc=example,dc=com
Proxy password: NULL
Credential level: 1
Authentication method: 3
credentialLevel requires proxyPassword
Proxy Bind Password:
About to modify this machines configuration by writing the files
Stopping network services
Stopping sendmail
Stopping nscd
Stopping autofs
ldap not running
nisd not running
nis_cache not running
nispasswd not running
nis(yp) not running
file_backup: stat(/etc/nsswitch.conf)=0
file_backup: (/etc/nsswitch.conf -> /var/ldap/restore/nsswitch.conf)
file_backup: stat(/etc/defaultdomain)=0
file_backup: (/etc/defaultdomain -> /var/ldap/restore/defaultdomain)
file_backup: stat(/var/nis/NIS_COLD_START)=-1
file_backup: No /var/nis/NIS_COLD_START file.
file_backup: nis domain is "example.com"
file_backup: stat(/var/yp/binding/example.com)=-1
file_backup: No /var/yp/binding/example.com directory.
file_backup: stat(/var/ldap/ldap_client_file)=-1
file_backup: No /var/ldap/ldap_client_file file.
Starting network services
start: /usr/bin/domainname example.com... success
start: /usr/lib/ldap/ldap_cachemgr... success
start: /etc/init.d/autofs start... success
start: /etc/init.d/nscd start... success
start: /etc/init.d/sendmail start... success
System successfully configured
References
Sun Directory Server and native-ldap clients
ACIs - Access Control Instructions - Management
ACIs - Access Control Instruction - Reference
Posted at 03:03PM Jun 16, 2008 by Jonathan Gershater in Identity & Directory Server |
Friday May 16, 2008
The Internet and an American Girl
My daughter acquired a princess net for her room and was adamant that I install it this evening. Whilst I was looking for a suitable hook in the garage when she joined me and the following conversation ensued:
"Daddy, what's that blue flashing light?"
“That’s the Internet router.”
“What’s the Internet?
“Well it's a lot of wires that connect computers together.”
“Why?”
“So we can exchange information such as sending photos and email to grandpa.”
“Mommy said she ordered my princess net on her computer. Did she use the Internet?”
“Yes the Internet can also be used for shopping.”
“And the net arrived the next day!”
”Sometimes it is faster to shop using the Internet.”
“So, daddy, can I get a computer please I want to order a new American Girl?”
”Did you finish your homework?”
”But daddy……!”
Posted at 12:19AM May 16, 2008 by Jonathan Gershater in Personal |
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 PagePosted at 01:19PM May 13, 2008 by Jonathan Gershater in Identity & Directory Server |
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
stop the IMQ and ISW instances. (/etc/init.d/isw stop) & (/etc/init.d/imq stop)
backup /opt/SUNWisw/lib/connector.jar
Replace the connector.jar at the installation directory (/opt/SUNWisw/lib/connector.jar) with the one from support
Repeat this procedure on all the hosts which has the Connectors installed.
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�
Posted at 11:53AM May 02, 2008 by Jonathan Gershater in Identity & Directory Server |
Monday Apr 07, 2008
Blog until you drop
An interesting article in today's New York Times that blogging has become a very stressful 24x7 activity.
Rather ironic that the article is the most blogged story in the NYTimes today (April 7th) :) :)
Posted at 03:10PM Apr 07, 2008 by Jonathan Gershater in Personal |
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:
You have two or more Sun Directory servers in a multi-master replication configuration.
That the Directory servers are deployed as a naming service used by native-ldap clients ( for authentication etc.) configured for proxy-authentication
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
Proxy authentication – see “Using Proxy Credentials”
Posted at 08:35AM Apr 07, 2008 by Jonathan Gershater in Identity & Directory Server |
Monday Mar 31, 2008
two billion Directory entries - a misleading benchmark
Dave Kearns and Phil Hunt write about a two billion Directory entry benchmark recently published by Oracle. I wish to refute that benchmark as it does not simulate a real-world scenario for the following reasons:- Entries are read sequentially rather than random. Sequential reads almost guarantee that reads come from (faster) memory rather than (slower) file systems. How often in the real world is an LDAP or relational database read sequentially? Coming from a leading database vendor this scenario is very surprising and not reflective of the real world.
- The changelog is disabled and password policy is ignored.
- Who would implement two billion entries on a single non-replicated server. Everyone knows that replication provides high availability and failover and as a consequence creates an extra load (slower response) from an LDAP (or database) server.
Posted at 08:32PM Mar 31, 2008 by Jonathan Gershater in Identity & Directory Server |
Wednesday Mar 05, 2008
Migration guideline from Sun Directory Server 5.2 to 6.2
Although Sun Directory Server 6.2 has been out for many months, some users are only starting to get their feet wet with the new commands and Graphical User Interface. This is an outline of tasks in Directory Server 5.2 and their equivalent in Directory 6.2 . First a table of equivalent commands in 5.2 and 6.2, below that screenshots of equivalent tasks in 5.2 and 6.2Command line
|
Task |
Directory 5.2 command |
Directory 6.2 command |
|
Server management |
|
|
|
Create server |
N/A |
dsadm create |
|
Delete server |
N/A |
dsadm delete |
|
Start server |
start-slapd |
dsadm start |
|
Stop server |
stop-slapd |
dsadm stop |
|
Restart |
restart-slapd |
dsadm restart |
|
|
|
|
|
Backups |
|
|
|
Backup |
db2bak |
dsadm backup |
|
Restore |
bak2db |
dsadm restore |
|
Import |
ldif2db |
dsadm import |
|
Export |
db2ldif |
dsadm export |
|
|
|
|
|
Certificates |
|
|
|
Generate request |
N/A |
dsamd request-cert |
|
Import certificate |
N/A |
dsadm add-cert |
|
Key database |
|
|
|
|
|
|
|
Replication |
|
|
|
Create agreeement |
N/A |
dsconf create-repl-agmt |
|
Delete agreement |
N/A |
dsconf delete-repl-agmt |
|
Enable replication |
N/A |
dsconf enable-repl |
|
Replication status |
N/A |
dsconf show-repl-agmt-status |
|
|
|
|
|
Suffix |
|
|
|
Create |
N/A |
dsconf create-suffix |
|
Reindex |
N/A |
dsconf reindex |
|
Delete |
N/A |
dsconf delete-suffix |
|
Export |
N/A |
dsconf export |
|
Initialize/import |
N/A |
dsconf import |
|
|
|
|
|
Indexes |
|
|
|
Create index |
N/A |
dsconf create-index |
|
Delete index |
N/A |
dsconf delete-index |
|
Get index property |
N/A |
dsconf get-index-prop |
|
Set index property |
N/A |
dsconf set-index-prop |
|
List indexes |
N/A |
dsconf list-index |
|
Reindex |
N/A |
dsconf reindex |
|
|
|
|
|
Logs |
|
|
|
Manage properties |
N/A |
dsconf set-log-prop |
Graphical User Interface
Create server – version 5.2
Create server – version 6.2
Start & stop server – version 5.2
Start & stop server – version 6.2
Backup & restore server – version 5.2
Backup & restore server – version 6.2
Replication – version 5.2
Replication – version 6.2
Suffix management – version 5.2
Suffix management – version 6.2
LDIF import/export – version 5.2
LDIF import/export – version 6.2
Manage certificates – version 5.2
Manage certificates – version 6.2
Configure logs – version 5.2
Configure logs- version 6.2
Posted at 07:00AM Mar 05, 2008 by Jonathan Gershater in Identity & Directory Server |
Friday Feb 29, 2008
Happy Leap Day
When I was a kid I disdained leap years because it added one extra day before my birthday. Nowadays I don't mind the delay...As an avid reader of the foreign press, I came across a most interesting explanation for the 29th of February, this excerpted from an Israeli newspaper:
It was Julius Caesar who ultimately discovered, in 45 B.C.E., that time was out of joint. Following both Egyptian astronomers and his own experts, he decreed that that particular year would have 445 days, and from then on each year would have 12 months of 30 or 31 days each, including a short February with an additional day every four years. He also appropriated a month for himself - July (originally Quintilius, the fifth month, which now became the seventh). Augustus, who followed him on the Roman throne, added three more days to the year and named the eighth month (Sextilius, originally the sixth month) after himself: August. The Senate suggested that his successor, Tiberius, name a month after himself, but he was practical enough to refuse the honor by asking: "And what will you do by the time there will be 13 Caesars?"
Almost 1,600 years then passed before those who cared about matters calendrical, and had enough authority, decided that something had to be done to align the solar year (measured according to the number of rotations the sun made around the earth - at least that's what they thought then) with the lunar one (the time it took the moon to orbit the earth 12 times). In 1582 - counting from the year Jesus was born, although his birth was probably a couple of years earlier - Pope Gregorius XIII dropped 10 days from the calendar and decreed that from then on, every four years, February would have 29 days, not 28. The exception to this rule was that centenary years (i.e., 1700, 1800) would not have an extra day. The exception to this exception was that centenary years that are divisible by 400 would have an extra day.
As the pope was Catholic, it took the Protestant countries almost 200 years to follow suit. Russia and Greece came around only in the 20th century. That is why, in the history of the world's calendars, there was a 30th day in February - twice: Once in 1712 in Sweden, when they were trying to rectify errors made by their astronomers, and the second time when leaders of the Soviet Revolution wanted in 1929 to make a switch from the seven-day week to a five-day week and 30-day month. In 1931 they gave up the idea, and anyway, Pravda did not accept the ruling, kept faith with the Gregorian calendar, and there never was an issue dated February 30th in their history.
The Greek astronomer Meton, who dodged the Athenian draft in the fifth century B.C.E., calculated that 19 lunar years plus 209 days, which amounts to seven months (six of them with 30 days, and one with 29), equals 19 solar years.
This never works out correctly, as the solar year has a bit less than 365-and-one-quarter days (to be precise, it has approximately 365.242149 days), whereas the lunar year has a little more than 354-and-one-third days (precisely, approximately, 354.3734 days). They differ by little less than 11 days (10.8674, to be almost precise). But we valiantly and desperately will persist in showing that while the universe behaves mostly in a maddeningly arbitrary way, there is a method to it. In 3,000 years' time, we will have an extra day in the year, and this has to be fixed and fit into the calendar, and the sooner the better.
And here is some Irish trivia:
A tradition was introduced many centuries ago to allow women to propose to men during a leap year. This privilege of proposing was restricted to leap day in some areas. Leap day was sometimes known as “Bachelors’ Day”. A man was expected to pay a penalty, such as a gown or money, if he refused a marriage offer from a woman.
The tradition’s origin stemmed from an old Irish tale referring to St Bridget striking a deal with St Patrick to allow women to propose to men every four years. This old custom was probably made to balance the traditional roles of men and women in a similar way to how the leap day balances the calendar
Technorati Tags: Leap year
Posted at 10:31AM Feb 29, 2008 by Jonathan Gershater in Personal |
Monday Feb 11, 2008
Automating Directory Server 6 with Perl scripts
I am very grateful to Marina Sum for assisting with the publication of my article on SDN.Perl scripts, combined with the Sun Java Directory Server 6 command line interface, provide a powerful mechanism for automating the rollout and configuration of Sun Java Directory Server.
Get all the details here...
Thank you Marina...
Technorati Tags: Sun Directory Server, directory-server, perl
Posted at 08:00AM Feb 11, 2008 by Jonathan Gershater in Identity & Directory Server |
