Rationale for compulsory objectClass top in RFC2256 5.1
by Christian Kratzer
Hi,
I have always wondered about directories that have included objectClass top
in every entry even though practically any usefull objectClass inherits
from top eventually.
Apparantly RFC2256 5.1 requests this:
5.1. objectClass
The values of the objectClass attribute describe the kind of object
which an entry represents. The objectClass attribute is present in
every entry, with at least two values. One of the values is either
"top" or "alias".
( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
It seems RFC4512 addresses the matter in:
A.3. Changes to RFC 2256
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
2256.
Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
attribute type. This was integrated into Section 2.4.1 of this
document. The statement "One of the values is either 'top' or
'alias'" was replaced with statement that one of the values is 'top'
as entries belonging to 'alias' also belong to 'top'.
So this means objectClass top is still compulsory in every entry as in:
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
which means somehting like the following would be illegal:
dn: cn=Hugo,dc=example,dc=com
objectClass: person
Can anybody comment on the rationale why this is needed ?
I somehow completely fail to see the purpose.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
7 years, 11 months
standalone and master slave ldap behave differently
by Desiree Klecker
Hello,
to update entry persistend in a master slave openldap environment the
following steps are performed using Java :
1. The entry is removed.
2. The entry is created again.
This does not result in faulty behavior using a single/simple OpenLdap
directory.
Using a master slave configuration this results in unpredictable
errors claiming that the item still exists (the remove statement has ran
immediately before) if it is recreated.
I cannot see why the master slave environment should not behave in a
tranparent way. It seems the remove statement was not
executed in complete allthough the call is synchronous.
Which additional information are required to analyse the problem?
Do similar problems exist/ is this a known problem?
Regards,
Desiree
7 years, 11 months
olcAccess replication - error 80 attributes not within database namespace
by Igor Zinovik
Hello.
I'm trying to replicate access rules and limits for one of my databases, but
with no success:
suse:~ # cat olcAccess-syncrepl.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {1}rid=002
provider=ldap://ldap1.local
bindmethod=simple
binddn="cn=admin,cn=config"
credentials="TopSecret"
searchbase="olcDatabase={1}mdb,cn=config"
attrs="olcAccess,olcLimits"
timeout=3
network-timeout=0
starttls=yes
tls_cert="/etc/openldap/ldap.pem"
tls_key="/etc/openldap/ldap.key"
tls_cacert="/etc/ssl/local-ca.pem"
tls_reqcert=demand
tls_crlcheck=none
suse:~ # ldapmodify -H ldap://ldap2.local -ZZxWD cn=admin,cn=config -f
olcAccess-syncrepl.ldif
Enter LDAP Password:
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)
additional info: Base DN "olcAccess,olcLimits" is not within the
database naming context
slapd-2.4.33 if it matters.
7 years, 11 months
translucent overlay - bogus local entries
by Steve Eckmann
We noticed that adding a local entry for which there is no corresponding remote entry doesn't cause an error to be reported, but the bogus local entry cannot then be found or deleted, as far as I can tell. I realize it was a mistake to add such an entry, but is it possible to configure the translucent overlay to prevent the client from making this mistake, or is it up to the client to ensure a remote entry exists before adding a local entry? And is there some way to find and delete such bobus local entries, either via LDAP commands or by directly querying and managing the local mdb instance?
Thanks.
Steve
7 years, 11 months
Re: ldap_add: Invalid syntax (21) additional info: objectclass: value #0 invalid per syntax
by Quanah Gibson-Mount
--On Friday, May 17, 2013 12:38 AM +0100 Youssef Said Khloufi
<mragrid(a)yahoo.fr> wrote:
>
> - stoping and restarting slapd does not resolve the problem.
> - i checked all schemes loaded in the configuration DIT using the command
> :
> sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=schema,cn=config"
> and my scheme is not there (it seems to be the problem).
> - i am using openldap-2.4.28 on Ubuntu 12.04.2 LTS.
Please do not top post.
Please always copy the list in replies if you want further help.
I don't see any obvious changes between OpenLDAP 2.4.28 and current release
(2.4.35) addressing why your schema wasn't added, but my first step would
be to confirm whether or not you see this behavior if you use a release of
OpenLDAP that isn't a year and a half old.
It certainly works (in general) for me with OpenLDAP 2.4.35:
zimbra@zre-ldap002:~$ ldapadd -x -H ldapi:/// -D cn=config -w zimbra
dn: cn=stSchema,cn=schema,cn=config
objectClass: olcSchemaConfig
olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.1 NAME 'stPerson' SUP
inetOrgPerson STRUCTURAL MUST correo)
olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.2 NAME 'correo' SUP mail)
adding new entry "cn=stSchema,cn=schema,cn=config"
zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w
zimbra -b "cn=schema,cn=config" 1.1
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}inetorgperson,cn=schema,cn=config
dn: cn={3}dyngroup,cn=schema,cn=config
dn: cn={4}zimbra,cn=schema,cn=config
dn: cn={5}amavisd,cn=schema,cn=config
dn: cn={6}opendkim,cn=schema,cn=config
dn: cn={7}stSchema,cn=schema,cn=config
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 11 months
ldap_add: Invalid syntax (21) additional info: objectclass: value #0 invalid per syntax
by Youssef Said Khloufi
I have the problem that the title mention. I am trying to create this entry :
dn: cn=usuario2,ou=st,o=um,c=es
changetype: add
objectclass: stPerson
sn: usuario2
mobile: 657132819
correo: usuario2(a)st.um
using the command :
ldapmodify -D "cn=admin,o=um,c=es" -W -H ldap://ldap -f st.ldif
if i only change the objectclass to "inetOrgPerson" and the attribute "correo" to "mail", everything works well so my DIT is just fine and it's my objectclass "stPerson" that is giving me the problem.
This is my definition of the "stPerson" objectclass :
#Definición de ObjectClass "stPerson" y atributo "correo"
dn: cn=stSchema,cn=schema,cn=config
objectClass: olcSchemaConfig
olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.1 NAME 'stPerson' SUP inetOrgPerson STRUCTURAL MUST correo)
olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.2 NAME 'correo' SUP mail)
I already added this scheme to the configuration DIT using the command :
ldapadd -Y EXTERNAL -H ldapi:/// -f stSchema.ldif
and it says :
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=stSchema,cn=schema,cn=config"
I do not see where is the problem.
7 years, 11 months
Re: getting bindDN in perl script
by Benin Technologies
yes I'm using Net::LDAP in my back-perl to access a back-hdb server and
it works, but I always use the same hardcorded $bindDN and $password
(for example : $binddn = cn=admin,dc=my-domain and $password = secret)
But I'd like to use the same bindDN and the same password as the one
that has been used to bind to the back-perl backend
Le 15/05/2013 17:14, Brian Reichert a écrit : >
On Wed, May 15, 2013 at 03:42:44PM +0100, Benin Technologies wrote:
>> thanks, but I'm surprised, I don't see the bindDN and password in
the >> parameter list of the perl subs
> This has nothing to to with OpenLDAP.
> > > From perl, you fird get an LDAP object:
> > my $ldap = Net::LDAP->new($uri->as_string);
> > then bind:
> > my $mesg = $ldap->bind($bindDN, password=> $passwd);
> > then search:
> > $mesg = $ldap->search( @search_args );
> > once the bind has completed, nothing retains that information; it >
was only needed to bind.
> > I have no idea what the architecture of your project is, but you'd
> be better off asking on one of the perl lists to work this stuff out. >
7 years, 11 months
openldap client wasn't able to authenticate SSH
by ded1＠MyBSD.org.my
Hi,
I have issue with my openldap client to authenticate on SSH using openldap
server. It's failed to authenticate using account that i create on openldap
server OR default user !. I have to reboot to single mode and change everything
back to default. The SSH account that i use is "labu"
Output from /etc/passwd on openldap server (10.1.1.1):
# more /etc/passwd | grep labu
labu:x:1003:1003::/home/labu:/bin/sh
Here's what i'm using on the setup:
Server (10.1.1.1):
i. openldap 2.4.28-1.1 on Linux Ubuntu 12.04
Client (10.1.1.2):
i. libpam-ldapd 0.8.4 on Linux Ubuntu 12.04
Here's the output when i do on openldap server itself:
# ldapsearch -h localhost -D "cn=admin,dc=ROSAK,dc=COM" -w openiam -b
"dc=ROSAK,dc=COM" -s sub "objectclass=*"
ldap_bind: Invalid credentials (49)
_BUT_ i'm am able to login using admin account on phpldapadmin.
Here's my /etc/ldap/slapd.conf
##############################################################
# S L A P D . C O N F
#
##############################################################
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
password-hash {CLEARTEXT}
allow bind_v2
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
modulepath /usr/lib/ldap
moduleload back_bdb.la
#moduleload back_@BACKEND@
access to dn.exact="cn=admin,ou=Roles,dc=ROSAK,dc=COM" by * manage
access to dn.exact="cn=admin,ou=Roles,dc=ROSAK,dc=COM" by * read
access to attrs=userPassword by self write
by anonymous auth
by * none
access to * by self write
by users read
by anonymous auth
database bdb
suffix "dc=ROSAK,dc=COM"
rootdn "cn=admin,dc=ROSAK,dc=COM"
rootpw {CLEARTEXT}123456
directory "/var/lib/ldap"
index objectClass eq
loglevel 2048
Here's /etc/nsswitch.conf from my openldap client:
# /etc/nsswitch.conf
passwd: files ldap
group: files ldap
shadow: files ldap
sudoers: files ldap
services: files ldap
automount: files ldap
Here's /etc/pam.d/sshd from my openldap client:
# auth include system-auth
account required pam_nologin.so
account include system-auth
password include system-auth
session optional pam_keyinit.so force revoke
session include system-auth
session required pam_loginuid.so
Appreciate anyone help / advice.
Thanks.
---
ded1
"The end is the beginning, the beginning is the end"
7 years, 11 months
Re: getting bindDN in perl script
by Pierangelo Masarati
Please reply on the mailing list.
On 05/16/2013 01:00 AM, Benin Technologies wrote:
> yes but...where is this perl function called for binds ??? it isn't in
> SampleLDAP.pm...
>
servers/slapd/back-perl/bind.c calls a method "bind" as much as
servers/slapd/back-perl/search.c calls a method "search". Apparently,
who wrote "SampleLDAP.pm" did not provide a "bind" example. Note that
I've been working for 15 years with OpenLDAP and I never used back-perl;
I discovered all of this last night by opening 2 files and reading about
10 lines of code. You should probably try to do something like this
yourself.
p.
> Le 15/05/2013 22:20, Pierangelo Masarati a écrit :
>> binddn and bindpw are the first two parameters of the perl function
>> called for binds.
>>
>
>
--
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano
7 years, 11 months
