Re: Problems binding to LDAP
- From: kevin wright <k.d.wright@xxxxxxxxxxxx>
- Date: Tue, 07 Nov 2006 15:31:58 GMT
All fixed by modifying the java.schema file with the
following change:
objectclass ( 1.3.6.1.4.1.42.2.27.4.2.1
NAME 'javaContainer'
DESC 'Container for a Java object'
SUP top
STRUCTURAL
MAY ( o $ cn) )
# MUST cn )
I have continued with the tutorial and I am now successfully
binding Java objects to the LDAP service!
Kevin Wright
On Tue, 07 Nov 2006 12:39:57 +0000, kevin wright wrote:
Hi Guys,
My problem has moved on:
I am now following the tutorial:
http://www.cris.com/~adhawan/tutorial/
The first step to using openLDAP is apparently to create a root
context in the LDAP naming services. I have modified the slapd.conf
accordingly and now have this:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# 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!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
#suffix "dc=my-domain,dc=com"
suffix "o=jndiTest"
rootdn "cn=Manager,o=jndiTest"
#rootdn "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
schemacheck off
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@xxxxxxxxxxx
Having restarted the Ldap service the following code
should create a new context.
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.naming.NameAlreadyBoundException;
import javax.naming.directory.*;
import java.util.*;
public class MakeRoot {
final static String ldapServerName = "localhost";
final static String rootdn = "cn=Manager, o=jndiTest";
final static String rootpass = "secret";
final static String rootContext = "o=jndiTest";
public static void main( String[] args ) {
// set up environment to access the server
Properties env = new Properties();
env.put( Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.ldap.LdapCtxFactory" );
env.put( Context.PROVIDER_URL, "ldap://"; + ldapServerName + "/" );
env.put( Context.SECURITY_PRINCIPAL, rootdn );
env.put( Context.SECURITY_CREDENTIALS, rootpass );
try {
// obtain initial directory context using the environment
DirContext ctx = new InitialDirContext( env );
// now, create the root context, which is just a subcontext
// of this initial directory context.
ctx.createSubcontext( rootContext );
} catch ( NameAlreadyBoundException nabe ) {
System.err.println( rootContext + " has already been bound!" );
} catch ( Exception e ) {
System.err.println( e );
}
}
}
// end MakeRoot.java
The code compiles but at runtime:
javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - object class 'javaContainer' requires attribute 'cn']; remaining name 'o=jndiTest'
Any takers?
Kevin Wright
.
- References:
- Problems binding to LDAP
- From: kevin wright
- Re: Problems binding to LDAP
- From: kevin wright
- Problems binding to LDAP
- Prev by Date: Re: Fabonicseries Program required
- Next by Date: Re: Problems binding to LDAP
- Previous by thread: Re: Problems binding to LDAP
- Next by thread: Re: Problems binding to LDAP
- Index(es):
Relevant Pages
|
