MQ + OpenLdap: Any working example of LDAP configuration?

Hi,

I'm afraid we only test with Sun's directory server (version 5.2 if

I'm not mistaken) - after installation, it is pretty much

ready to be used by imqobjmgr - no need for any schema

configuration (ie to allow Java objects to be stored in it).

Having said that, have you tried storing any Java objects in

OpenLdap or is it just MQ java objects that are causing the

problem here ?

I found a page of interest in the JNDI tutorial:

http://java.sun.com/products/jndi/tutorial/basics/directory/hybrid.html

The above mentions something about not being compatible

with OpenLDAP if you are using something older than

Java 2 SDK, v1.4.

The bottom line I think is that if a particular LDAP server

supports storing of Java objects, then MQ objects can be

stored there as well.

If the LDAP server does not support storing Java objects by

default, then the schema for Java Objects needs to be added to

the LDAP server. The JNDI tutorial talks about this a little at:

http://java.sun.com/products/jndi/tutorial/basics/prepare/content.html

regards,

-isa

http://www.sun.com/software/products/message_queue/index.xml

isahashim at 2007-7-3 18:43:34 >

Hi Ken-shi,

Appreciate your input very much on this.

I am not familiar with OpenLDAP so have no idea

on the amount/size of config files that are relevant

here. If they are small in size/number, you can try

copying/pasting them onto a reply posting. I admit

that that might get messy.

If not, you can send it to mq-feedback@sun.com with

instructions (bear in mind we are not as familiar with

OpenLDAP) and I can:

- forward it to Silvano

- potentially keep the files around so that in the future (time

permitting), someone here can write an SunSolve article on

how to configure OpenLDAP for MQ use

Silvano, if you want to get the above config files, please

send a request to mq-feedback@sun.com.

Ken-shi/Silvano: When sending email to mq-feedback@sun.com

put this in the subject so I don't miss it:

MQ + OpenLdap: Any working example of LDAP configuration?

-i

http://www.sun.com/software/products/message_queue/index.xml

isahashim at 2007-7-3 18:43:34 >

Thank you Ken-shi and Isa for your timely and helpful information.

The example files received have been very useful and a successful configuration of MQ working together with an OpenLDAP has come out.

I think it is worth to add such hints in MQ manuals too.

Regards,

Silvano

xss at 2007-7-3 18:43:34 >

Agreed.

I've been wanting to test the steps and write a tech article on this

and post it to somewhere on sunsolve.sun.com but have not had

time yet.

In any case, the instructions Ken-shi gave are below including

the 3 files (etang.ldif objectstore.properties slapd.conf). Not sure

how messy this posting can get due to size of files.

I'd much rather point you to a sunsolve article but don't want

to make you wait. When I do post the sunsolve article, this thread

will be updated with a ptr to it.

===Begin instructions===

Attached please see my working configuation files.

1.Modify your OpenLdap configuration. (see slapd.conf)

start OpenLdap: ./slapd

2.Modify you initial data.( see etang.ldif)

load initial data: ldapadd -x -D "cn=Manager,dc=etang,dc=com" -W -f

etang.ldif

3.ObjectStore properties ( see objectstore.properties )

create your object store with "Administration" GUI on windows;

while creating destinations or connection factories, be sure that the

lookup names start with "cn=".

===End instructions===

===Begin etang.ldif===

dn: dc=etang,dc=com

objectClass: dcObject

objectClass: organization

dc: etang

o: Etang Corporation

description: The etang corporation

dn: cn=Manager,dc=etang,dc=com

objectClass: organizationalRole

cn: Manager

description: Directory Manager

dn: o=IMQ,dc=etang,dc=com

objectClass: organization

o: IMQ

dn: ou=imqusers,o=IMQ,dc=etang,dc=com

objectClass: organizationalUnit

ou: imqusers

dn: cn=admin,ou=imqusers,o=IMQ,dc=etang,dc=com

objectClass: person

cn: admin

sn: admin

userPassword: admin

dn: cn=guest,ou=imqusers,o=IMQ,dc=etang,dc=com

objectClass: person

cn: guest

sn: guest

userPassword: guest

===End etang.ldif===

===Begin objectstore.properties===

java.naming.provider.urlldap://10.1.0.195:389/o=IMQ,dc=etang,dc=com

java.naming.factory.initial com.sun.jndi.ldap.LdapCtxFactory

java.naming.security.principal cn=admin,ou=imqusers,o=IMQ,dc=etang,dc=com

java.naming.security.authenticationsimple

java.naming.security.credentialsadmin

===End objectstore.properties===

===Begin slapd.conf===

#

# See slapd.conf(5) for details on configuration options.

# This file should NOT be world readable.

#

include/usr/local/openldap/etc/schema/core.schema

include /usr/local/openldap/etc/schema/cosine.schema

include /usr/local/openldap/etc/schema/inetorgperson.schema

include /usr/local/openldap/etc/schema/dyngroup.schema

include /usr/local/openldap/etc/schema/java.schema

include /usr/local/openldap/etc/schema/nis.schema

include /usr/local/openldap/etc/schema/misc.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory

# service AND an understanding of referrals.

#referralldap://root.openldap.org

pidfile/usr/local/openldap/var/run/slapd.pid

argsfile/usr/local/openldap/var/run/slapd.args

# Load dynamic backend modules:

# modulepath/usr/local/openldap/libexec

# moduleloadback_bdb.la

# moduleloadback_ldap.la

# moduleloadback_ldbm.la

# moduleloadback_passwd.la

# moduleloadback_shell.la

# Sample security restrictions

#Require integrity protection (prevent hijacking)

#Require 112-bit (3DES or better) encryption for updates

#Require 63-bit encryption for simple bind

# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:

#Root DSE: allow anyone to read it

#Subschema (sub)entry DSE: allow anyone to read it

#Other DSEs:

#Allow self write access

#Allow authenticated users read access

#Allow anonymous users to authenticate

#Directives needed to implement policy:

# access to dn.base="" by * read

# access to dn.base="cn=Subschema" by * read

# access to *

#by self write

#by users read

#by anonymous auth

#

# if no access controls are present, the default policy

# allows anyone and everyone to read anything but restricts

# updates to rootdn. (e.g., "access to * by * read")

#

# rootdn can always read and write EVERYTHING!

access to * by * write

#######################################################################

# ldbm database definitions

#######################################################################

databasebdb

suffix"dc=etang,dc=com"

rootdn"cn=Manager,dc=etang,dc=com"

# Cleartext passwords, especially for the rootdn, should

# be avoid. See slappasswd(8) and slapd.conf(5) for details.

# Use of strong authentication encouraged.

rootpwsecret

# The database directory MUST exist prior to running slapd AND

# should only be accessible by the slapd and slap tools.

# Mode 700 recommended.

directory/usr/local/openldap/var/openldap-data

# Indices to maintain

indexobjectClasseq

===End slapd.conf===

isahashim at 2007-7-3 18:43:34 >

Just one more piece of information to complete the picture. When adding a connection factory or destination, the lookup name must be specified as cn=yourobjectname. The "cn=" is required. Otherwise, it will give you the "com.sun.messaging.jmq.admin.objstore.GeneralNamingException: A general naming exception is caught." error.

It may be obvious for experienced LDAP users but certainly not for new comers.

andy01 at 2007-7-3 18:43:35 >