Re: is_entry_objectclass() no objectClass attribute
by Howard Chu
Dave Horsfall wrote:
> OpenLDAP 2.3.27
>
> We have a mesh of servers replicating (with SyncRepl) to each other; they
> master their own bit of the tree and slave everyone else's, making it hard
> at times to pick the culprit in case of problems (but I'm stuck with it).
>
> Anyway, I've started seeing these weird errors in the logs, just after
> start-up:
>
> is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute
> is_entry_objectclass("", "2.5.17.0") no objectClass attribute
> is_entry_objectclass("", "2.5.6.1") no objectClass attribute
>
> Now, I know what the message means, and I know those OIDs are basically
> internal, but given the DN is null how do I go looking for the problem?
>
Most likely there is no problem, it's just looking at a stub/glue entry.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years
Re: is_entry_objectclass() no objectClass attribute
by Pierangelo Masarati
Dave Horsfall wrote:
> OpenLDAP 2.3.27
>
> We have a mesh of servers replicating (with SyncRepl) to each other; they
> master their own bit of the tree and slave everyone else's, making it hard
> at times to pick the culprit in case of problems (but I'm stuck with it).
>
> Anyway, I've started seeing these weird errors in the logs, just after
> start-up:
>
> is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute
> is_entry_objectclass("", "2.5.17.0") no objectClass attribute
> is_entry_objectclass("", "2.5.6.1") no objectClass attribute
>
> Now, I know what the message means, and I know those OIDs are basically
> internal, but given the DN is null how do I go looking for the problem?
>
That's harmless. I think it was fixed in HEAD but likely not ported to
re23. Basically, when the suffix entry is "", a dummy Entry structure
is used, which has no attributes and thus no objectClass attribute.
Those checks should be skipped but they're not, but the main drawback is
that few cycles are wasted.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years
2.3 back-bdb, cachesize, idlcachesize, and real memory usage
by matthew sporleder
This has been asked before, but I didn't find any answers on it.
I'm trying to find a good way to predict the size of a slapd process
based on cachesize and idlcachesize. (db_stat -m already gives me
info on the DB_CONFIG part of memory usage).
I was hoping to come up with a formula based on the <average text size
of an entry in my database> * <SOMESTUFF> * <(idl)cachesize setting>=
XXX bytes.
Do I just figure out the "sizeof" the structs below?
Any tips are appreciated.
In back-bdb.h, I found this:
/* for the in-core cache of entries */
typedef struct bdb_cache {
int c_maxsize;
int c_cursize;
int c_minfree;
int c_eiused; /* EntryInfo's in use */
int c_leaves; /* EntryInfo leaf nodes */
EntryInfo c_dntree;
EntryInfo *c_eifree; /* free list */
Avlnode *c_idtree;
EntryInfo *c_lruhead; /* lru - add accessed entries here */
EntryInfo *c_lrutail; /* lru - rem lru entries from here */
ldap_pvt_thread_rdwr_t c_rwlock;
ldap_pvt_thread_mutex_t lru_head_mutex;
ldap_pvt_thread_mutex_t lru_tail_mutex;
u_int32_t c_locker; /* used by lru cleaner */
#ifdef SLAP_ZONE_ALLOC
void *c_zctx;
#endif
} Cache;
typedef struct bdb_idl_cache_entry_s {
struct berval kstr;
ldap_pvt_thread_rdwr_t idl_entry_rwlock;
ID *idl;
DB *db;
struct bdb_idl_cache_entry_s* idl_lru_prev;
struct bdb_idl_cache_entry_s* idl_lru_next;
} bdb_idl_cache_entry_t;
When I looked at an old core file with strings, I found a lot of dn's,
so I assume this was part of the cache.
16 years
password validation
by Douglas B. Jones
I have two ldap servers:
1) on machine A, a tru64 platform with openldap-2.2.20
2) on machine B, a rhel4 platform with openldap-2.3.27
We are trying to migrate to the rhel4 machine with the more
recent ldap. The problem is that sometimes the validation
fails. Due to the number of failures of validation against
the rhel4 machine, we set up a program that:
a) checks the encrypted password against the tru64 password
file (the source) and against both ldap servers. Understand,
this is comparing the encrypted password to see if they are
the same.
b) tries to validate against all three locations.
The strange thing is that a high number of instances, the encrypted
password matches on all three locations, the password (via this
test program) validates against the password file and the tru64
ldap, but fails to validate with err=49 (invalid credentials) against
the rhel4 box. The best I can tell, it is random. Most work, but a
high percentage fail. We rebuild both ldaps each night. I was building
the tru64 one with ldapadd and the rhel4 with slapadd. I then switched
to 'slapdd -q'. Still had the problems, although they seemed a little
better, so last night I switch to ldapadd as in the rhel4 machine. I am
not seeing some that are following this same patter, validate against the
password file and tru64 ldap, but fail against the rhel4 ldap.
One other note, both ldaps are built from the same ldif files. Any ideas?
Thanks for any help!
16 years
OpenLDAP Search Problem
by Matt Brown
Hi,
I have an issue that just started a few days ago where when I search our
LDAP for the field employeeNumber a number of my accounts will come back as
not found even though they are in there, I can search by the uid and find
the person and looking at the record the employeeNumber is exactly what I
was searching for.
I can however do a search for (employeeNumber=*000111222) and find the
employee where a search for (employeeNumber=000111222) will not find
anything. On other accounts the search returns the expected result.
Comparing 2 accounts, one that works as expected and one that doesn't both
and an employeeNumber field and both are set to a text value of 9
characters.
Thanks,
--
Matt Brown
Information Technology System Specialist V
Eastern Washington University
16 years
LDAP search issue.
by Gökhan
Hello;
I have a question on LDAP search issue.
I want to disable full search on the LDAP tree.
Eg:
My LDAP Tree is:
c=US, o=Dept1, cn=John Smith
c=US, o=Dept1, cn=Ann Adams
I want to deny to read full listing of the tree but only allow when the
search condition meets only the required person.
In the example above I want nobody to be listed. But when the search
criteria is "c=US, o=Dept1, cn=Ann Adams" this entry must be listed. When a
search on "c=US" comes, nothing must be listed.
What is the correct Access Control Information for this request??
Thanks.
16 years
Unable to add non root DNs
by JP Singh
Hi all,
I am not able to add non root dns.
I am getting invalid credentails (49).
I have added root dn manager with ease.
I am not able to add any new entry with manager as root dn
If I make new entry as root dn then I am able to add it.
Or in other words if I make employee as root dn
and rootpw whatever was given previously.
It will add cn=employee without any problem
I will welcome any help in this direction.
Thanks & Regards
JP
---------------------------------
Sponsored Link
Mortgage rates near 39yr lows. $420,000 Mortgage for $1,399/mo - Calculate new house payment
16 years
Re: slap_global_control - ppolicy
by Prakash Velayutham
>>> "Pierangelo Masarati" <ando(a)sys-net.it> 11/19/06 10:21 AM >>>
> Hello All,
>
> I configured OpenLDAP-2.3.29 with the following options.
>
> ./configure --with-threads=posix --with-tls=openssl --enable-dynamic
> --with-cyrus-sasl --enable-modules--enable-ldbm=mod --enable-crypt
> --enable-lmpasswd --enable-ldap=mod --enable-meta=mod --enable-rewrite
> --enable-null=mod --enable-monitor=mod --enable-accesslog
> --enable-denyop --enable-dyngroup --enable-dynlist --enable-lastmod
> --enable-ppolicy --enable-proxycache --enable-refint --enable-retcode
> --enable-rwm --enable-syncprov --enable-translucent --enable-unique
> --enable-valsort --enable-aci --enable-bdb=mod --enable-hdb=mod
> --enable-ldbm-api=berkeley --enable-spasswd --enable-wrappers
> --prefix=/usr/local/encap/openldap
>
> My slapd.conf is:
>
> include
> /usr/local/encap/openldap/etc/openldap/schema/core.schema
> include
> /usr/local/encap/openldap/etc/openldap/schema/cosine.schema
> include
> /usr/local/encap/openldap/etc/openldap/schema/inetorgperson.schema
> include
> /usr/local/encap/openldap/etc/openldap/schema/openldap.schema
> include
/usr/local/encap/openldap/etc/openldap/schema/nis.schema
> include
> /usr/local/encap/openldap/etc/openldap/schema/samba3.schema
> include
> /usr/local/encap/openldap/etc/openldap/schema/ppolicy.schema
>
> allow bind_anon_dn
>
> pidfile /usr/local/encap/openldap/var/run/slapd.pid
> argsfile /usr/local/encap/openldap/var/run/slapd.args
>
> database bdb
> suffix "dc=my-domain,dc=com"
> rootdn "cn=Manager,dc=my-domain,dc=com"
>
> rootpw secret
>
> directory /usr/local/encap/openldap/var/openldap-data
>
> index objectClass eq
>
> overlay ppolicy
> ppolicy_default "cn=Standard Policy,ou=Policies,dc=my-domain,dc=com"
> ppolicy_use_lockout
>
> access to attrs=userpassword
> by self write
> by * auth
>
> access to *
> by self write
> by * read
>
> loglevel -1
>
>
########################################################################
>
> Now when I try to do this:
>
> prakash@linux:~> ldapsearch -H ldap://localhost -D
> "cn=Manager,dc=my-domain,dc=com" -x -W -b "dc=my-domain,dc=com" -e
> ppolicy "cn=Manager"
> Enter LDAP Password:
>
> I get the proper result.
>
> # extended LDIF
> #
> # LDAPv3
> # base <dc=my-domain,dc=com> with scope subtree
> # filter: cn=Manager
> # requesting: ALL
> #
>
> # Manager, my-domain.com
> dn: cn=Manager,dc=my-domain,dc=com
> objectClass: organizationalRole
> cn: Manager
> description: LDAP Directory Manager
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> But in the server logs, I see,
>
> Nov 18 09:55:31 linux slapd[11135]: => get_ctrls:
> oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical)
> Nov 18 09:55:31 linux slapd[11135]: <= get_ctrls: n=1 rc=0 err=""
> Nov 18 09:55:31 linux slapd[11135]: attrs:
> Nov 18 09:55:31 linux slapd[11135]:
> Nov 18 09:55:31 linux slapd[11135]: conn=0 op=1 SRCH
> base="dc=my-domain,dc=com" scope=2 deref=0 filter="(cn=manager)"
> Nov 18 09:55:31 linux slapd[11135]: slap_global_control: unavailable
> control: 1.3.6.1.4.1.42.2.27.8.5.1
>
> Is this the reason, why I am not able to get my ppolicy controls to
> work? How do I make this control available?
That message is only telling you that ppolicy is not recognized as a
global control; in fact, it's only supported within the naming context
you
configured the ppolicy overlay for. As a consequence, handling of that
control is deferred. You're simply logging at a too verbose level, and
erroneously interpreting the resulting logs. The control does nothing
in
the operation above likely because there's nothing to do (i.e. you
didn't
provide an incorrect password multiple times, and your password is not
about to expire, or simply because you auth'ed as the rootdn).
Did you read the man page and the draft that control is about? What are
you expecting it to do, otherwise?
p.
Hello,
Thanks for the reply. Makes sense. Actually my issue was initially
getting ppolicy overlay to work. Should I open a new thread on that or
should I use this thread for that too?
Prakash
16 years
slap_global_control - ppolicy
by Prakash Velayutham
Hello All,
I configured OpenLDAP-2.3.29 with the following options.
./configure --with-threads=posix --with-tls=openssl --enable-dynamic
--with-cyrus-sasl --enable-modules--enable-ldbm=mod --enable-crypt
--enable-lmpasswd --enable-ldap=mod --enable-meta=mod --enable-rewrite
--enable-null=mod --enable-monitor=mod --enable-accesslog
--enable-denyop --enable-dyngroup --enable-dynlist --enable-lastmod
--enable-ppolicy --enable-proxycache --enable-refint --enable-retcode
--enable-rwm --enable-syncprov --enable-translucent --enable-unique
--enable-valsort --enable-aci --enable-bdb=mod --enable-hdb=mod
--enable-ldbm-api=berkeley --enable-spasswd --enable-wrappers
--prefix=/usr/local/encap/openldap
My slapd.conf is:
include
/usr/local/encap/openldap/etc/openldap/schema/core.schema
include
/usr/local/encap/openldap/etc/openldap/schema/cosine.schema
include
/usr/local/encap/openldap/etc/openldap/schema/inetorgperson.schema
include
/usr/local/encap/openldap/etc/openldap/schema/openldap.schema
include /usr/local/encap/openldap/etc/openldap/schema/nis.schema
include
/usr/local/encap/openldap/etc/openldap/schema/samba3.schema
include
/usr/local/encap/openldap/etc/openldap/schema/ppolicy.schema
allow bind_anon_dn
pidfile /usr/local/encap/openldap/var/run/slapd.pid
argsfile /usr/local/encap/openldap/var/run/slapd.args
database bdb
suffix "dc=my-domain,dc=com"
rootdn "cn=Manager,dc=my-domain,dc=com"
rootpw secret
directory /usr/local/encap/openldap/var/openldap-data
index objectClass eq
overlay ppolicy
ppolicy_default "cn=Standard Policy,ou=Policies,dc=my-domain,dc=com"
ppolicy_use_lockout
access to attrs=userpassword
by self write
by * auth
access to *
by self write
by * read
loglevel -1
########################################################################
Now when I try to do this:
prakash@linux:~> ldapsearch -H ldap://localhost -D
"cn=Manager,dc=my-domain,dc=com" -x -W -b "dc=my-domain,dc=com" -e
ppolicy "cn=Manager"
Enter LDAP Password:
I get the proper result.
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: cn=Manager
# requesting: ALL
#
# Manager, my-domain.com
dn: cn=Manager,dc=my-domain,dc=com
objectClass: organizationalRole
cn: Manager
description: LDAP Directory Manager
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
But in the server logs, I see,
Nov 18 09:55:31 linux slapd[11135]: => get_ctrls:
oid="1.3.6.1.4.1.42.2.27.8.5.1" (noncritical)
Nov 18 09:55:31 linux slapd[11135]: <= get_ctrls: n=1 rc=0 err=""
Nov 18 09:55:31 linux slapd[11135]: attrs:
Nov 18 09:55:31 linux slapd[11135]:
Nov 18 09:55:31 linux slapd[11135]: conn=0 op=1 SRCH
base="dc=my-domain,dc=com" scope=2 deref=0 filter="(cn=manager)"
Nov 18 09:55:31 linux slapd[11135]: slap_global_control: unavailable
control: 1.3.6.1.4.1.42.2.27.8.5.1
Is this the reason, why I am not able to get my ppolicy controls to
work? How do I make this control available?
Thanks,
Prakash
16 years
Search not working
by timothy johnson
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 fd=12 ACCEPT from IP=
10.250.108.116:1206 (IP=0.0.0.0:389)
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=0 BIND
dn="cn=root,dc=moss,dc=org" method=128
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=0 BIND
dn="cn=root,dc=moss,dc=org" mech=SIMPLE ssf=0
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=0 RESULT tag=97 err=0
text=
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=1 SRCH
base="ou=People,dc=moss,dc=org" scope=0 deref=0 filter="(objectClass=*)"
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=1 SRCH attr=objectClass
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=1 SEARCH RESULT tag=101
err=0 nentries=1 text=
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=2 SRCH
base="ou=People,dc=moss,dc=org" scope=2 deref=3
filter="(&(givenName=*tim*))"
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=2 SRCH attr=cn
commonName mail roleOccupant display-name displayname sn surname co
organizationName o giv$
Nov 16 13:05:48 MOSSPDC1 slapd[15532]: conn=5595 op=2 SEARCH RESULT tag=101
err=53 nentries=0 text=critical control unavailable in context
Nov 16 13:05:50 MOSSPDC1 slapd[15532]: conn=5595 op=3 UNBIND
Nov 16 13:05:50 MOSSPDC1 slapd[15532]: conn=5595 fd=12 closed
Trying to lookup emails for a user, any ideas
16 years
