There are notes throughout the configuration files that are used in this example which guide you to tailor this set of properties to your particular needs. The one most likely to change is noderootrdn, you will probably have some domain other than PLEX2 as the grouping for your nodes - this value is input into the system at Step 4. “Build the legacyRoot node”.
Notice that the example assumes a principal of 'cn=admin' exists on the LDAP server, with password 'adminpwd' and that this principal is authorised to perform any operation on the LDAP server.
If the LDAP server to be configured already has the WebSphere naming schema, this step can be skipped. An LDAP name server configured for WebSphere will already have this schema.
The LDAP server on OS/390 and z/OS needs to store the schema entries in the back-end store to which they apply. This is achieved by adding a suffix to the dn of each schema entry. The supplied WebSphereNamingSchema.ldif file does not specify a suffix on the schema entries, so you must add one. For example, if the suffix for the back-end store is “c=US”, you should change every instance of “dn:cn=schema” in the ldif file to “dn:cn=schema,c=US”.
ldapmodify -h <hostname>
-p <portnumber>
-D <authorized_principal>
-w <authorized_principal_password>
-f WebSphereNamingSchema.ldif
Where hostname and portnumber are those for the LDAP server and the authorised principal
is the distinguished name of a user with sufficient authority on the nameserver
to write entries. The ldapmodify command must be available for your chosen LDAP server. If it is not, consult your LDAP server documentation to determine how a new schema (in ldif form) should be installed.
ldapmodify -h wibble.ibm.com
-p 389
-D cn=admin
-w adminpwd
-f WebSphereNamingSchema.ldif
suffix “c=US”
An ldif file to build the root of the system name space (a node called the containerdn) is supplied with CICS in utils/namespace/dfhsns.ldif. This file contains comments describing how to tailor it for your environment. If it is used without alteration, it creates a containerdn of ibm-wsnTree=t1,o=wasnaming,c=US and also two CICS users on the LDAP namespace. The first CICS user has a distinguished name of cn=CICSSystems,c=US and the second is cn=CICSUser,c=US.
Two userids are defined. To understand how they are used, see Security considerations.
The ldapmodify command must be available for your chosen LDAP server, if it is not, consult your LDAP server documentation to determine how the root of the system name space should be built..
ldapmodify-h <hostname>
-p <portnumber>
-D <authorized_principal>
-w <authorized_principal_password>
-f dfhsns.ldif
Where hostname and portnumber are those for
the LDAP server and the authorised principal is the distinguished name of
a user with sufficient authority on the nameserver to write entries. ldapmodify-h wibble.ibm.com
-p 389
-D cn=admin
-w adminpwd
-f dfhsns.ldif
The legacyRoot node in the namespace is the point where CICS is usually configured to position itself when called to create a new InitialContext. For this step , the script DFHBuildSNS is shipped with CICS in the directory utils/namespace.
DFHBuildSNS -ldapserver <server_url>
[-node <node within the domain>]
-domain <domain_name>
-containerdn <Root of the namespace>
-principal <principal authorised to write to the namespace>
-credentials <password for that principal>
[-force]
For example:
DFHBuildSNS -ldapserver ldap://wibble.ibm.com:389
-domain PLEX2
-containerdn ibm-wsnTree=t1,o=WASNaming,c=US
-principal cn=admin
-credentials adminpwd
( The -force option is only used with the -node flag, but
neither are used in a CICS environment.