LDAP: unable to enter DIT LDIF: LDAP_NO_SUCH_OBJECT error

I think you need to import the trusted root certificate, (possibly any intermediary certs as well) into the Java keystore that JBoss is using. (When running on Linux, only place I have run JBoss, it uses Tomcat to run JBoss in it).

I am not sure where the default Java key store would be for Tomcat. You can use keytool from any Java JDK install, and import the trusted root that way. The keystore password should be 'default' since there is nothing secret about trusted root public keys.

Sample Keytool syntax might be:

keytool -importcert -keystore Path/to/store -storepass Password (Usually default or changeit) -alias Something -file FileWithPublicKey

To get the trusted root, an easy way is if the same cert is used for an HTTP interface. But I think IE will let you try ldaps://serverIP/ and then in the icon with a lock, you can see certificate details.

There is a tab for the certification chain. The top item is the CA who signed this cert (aka the Root that we need to Trust, to make it a Trusted Root).

If all this is too much, then here is a funny trick! Get the 600K Java based LDAP browser, called LBE and delete the local file lbecacert then run the LDAP Browser, make a config for your LDAP server, with SSL enabled, and when you first connect it will get the Trusted Root, prompt you to Trust it once, always, or never. Select Always, and exit.

The newly created lbecacert file now has just the one trusted root in it. Cute eh? I use this when I am lazy and it works fine.

Now where should the Tomcat cacerts be? Well it might be sufficient in your JVM install, lib/security to either add the trusted root to the cacerts there, or else replace that file with this one (which is not the best option, since you might want some of those default trusted roots).

The pedant in me is forced to point out that what you're creating here is not a schema, but a layout. A schema defines objects-types and attributes on the objects, a layout defines where the objects are and what values are assigned to the attributes.

That out of the way...

When you add people you'll be associating them with the OrganizationalRoles you're defining, and people can belong to many of them. In fact, where their object actually resides doesn't confer any rights; it's the act of associating an OR with them. When they bind, they'll gain the rights of the ORs they're a member of, regardless of where their object is.

To answer your question of figuring out what rights they get, they should be listed in two places:

• On their user-object
• On the organizationalRole object

You'd form the LDAP query to pull either the orMember attribute from the user object, or query all organizationalRole objects with a member of the user. The exact name of the attribute on the user depends on your actual LDAP schema in use.