ACL problem, restrict access to several attributes
by mheinric＠imn.htwk-leipzig.de
Hi
im trying to get an openldap server (2.3.) running with acl restricting access to special attributes
tb_READ should be allowed to search in the ou people but must not read any attributes then telephoneNumber, cn, sn, uid...
so i added this access rule to my slapd.conf :
..
access to dn.subtree="ou=people,dc=example,dc=com" attrs=telephoneNumber,cn,sn,mail,roomNumber,uid,givenName
by dn="cn=tb_READ,ou=functional,dc=example,dc=com" read
..
after restarting slapd I checked the result of ldapsearch but it returns nothing :
ldapsearch -x -D "cn=tb_READ,ou=functional,dc=example,dc=com" -b "ou=people,dc=example,dc=com" -W
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 3
result: 0 Success
accessing the attributes by ldapcompare works fine :
ldapcompare -x -D "cn=tb_READ,ou=functional,dc=example,dc=com" -W "uid=kheine,ou=people,dc=example,dc=com" telephoneNumber:1234
returns TRUE
so the rule seems to work for comparing, but not for searching entries in ou=people
i searched in the archives for more examples of using "attrs" and "dn.subtree", but found only configs where it seems to work this way
the admin guide (2.3.) itself shows this possibility on "6.3 Access Control" so i can not find the reason why my configuration is not working.
Please help me finding an approach to solve this problem, thanks for every advice
___________________________________
NOCC, http://nocc.sourceforge.net
15 years, 2 months
slap* tools require id2entry.bdb to run ?
by Josh Miller
Is it a requirement for the id2entry.bdb file to exist prior to any
slap* tools successfully running or would this be a bug?
OpenLDAP 2.4.7
Berkley-DB 4.6
CentOS 5
I get a Segmentation Fault every time I run slaptest or slapindex if I
have not yet started slapd (to prompt initial creation of id2entry.bdb
in my data directory).
Example:
# /etc/init.d/ldap stop
# rm -rf /var/lib/openldap-data/*
# rm -rf /etc/openldap/slapd.d && mkdir /etc/openldap/slapd.d
...(modify slapd.conf)...
# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
Seg Faults every time. I even get a seg fault if I simply run the
following:
# slaptest -f /etc/openldap/slapd.conf
(Possibly useless gdb output http://ditree.com/work/gdb.ol2.4.7.out )
TIA,
--
Joshua M. Miller - RHCE,VCP
15 years, 2 months
Propagating schema changes
by Lionel Kernux
Hi,
I have a master slapd 2.1.22 replicating to 5 slaves.
If I add a new attribute to the schema on the master, will that change
propagate to the slaves?
Thanks
M
15 years, 2 months
Problems using db4-utils on backend database files
by tamarin p
I'm currently attempting to use berkeley utils on the database files created
by openldap, such as db_stat -m . However, I get nothing but an error
message. I found this post in the archives, which seems to be the exact same
problem:
http://www.openldap.org/lists/openldap-software/200401/msg00540.html .
However, I don't see a solution, just that I might be inadvertently using
the wrong type of backend.Here's what I'm doing:
tamarin# pwd
/var/lib/ldap
tamarin# ls
alock __db.001 __db.003 __db.005 DB_CONFIG id2entry.bdb
member.bdb
ou.bdb
cn.bdb __db.002 __db.004 __db.006 dn2id.bdb log.0000000001
objectClass.bdb
tamarin# db_stat -m
db_stat: Program version 4.3 doesn't match environment version
db_stat: DB_ENV->open: DB_VERSION_MISMATCH: Database environment version
mismatch
tamarin# db_recover
db_recover: Program version 4.3 doesn't match environment version
db_recover: Unacceptable log file log.0000000001: unsupported log version 11
db_recover: Invalid log file: log.0000000001: Invalid argument
db_recover: PANIC: Invalid argument
db_recover: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database recovery
All the while openldap works perfectly and I can add entries to the
directory using ldapadd etc. No complaints in /var/log/local4 either.
The database directive in slapd.conf is set to type "hdb", and the directory
directive to /var/lib/ldap. When starting slapd with -d 4 the following line
is printed to stdout: "bdb_db_open: dc=test,dc=com". I've tried to specify
"bdb" as well, still same result when running db_stat. The way I understood
the docs, hdb is merely bdb with a special structure. Anyway: What I haven't
set in my slapd.conf is anything under the section "Load dynamic backend
modules". In particular, I've left the following directives commented out:
# modulepath /usr/lib64/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
I tried enabling the modulepath and moduleload directive for back_bdb.la but
openldap fails to launch saying the module can't be found, which is not very
strange as /usr/lib64/openldap does not exist. Are these modules needed to
successfully specify hdb in slapd.conf's database-directive, and does it
revert to back-ldbm if not found?
As far as program versions go, I'm not very proficient with *NIX, so I've
used yum installs for everything rather than attempt to compile things
myself. IHere are the versions:
- db4-utils-4.3.29-9.fc6 (db_stat etc)
- openldap-servers-2.3.27-8
- openldap-2.3.27-8
I'm obviously going wrong somewhere, but where?
15 years, 2 months
slapadd going for a very long time
by Lionel Kernux
Hi all,
I realize that the versions to which I am going to refer are somewhat
deprecated so please bear with me.....
2.2.13
I'm running RHEL4 and am bound by policy to only use RHEL4 packages so
this is why I am only using v2.2.13.
Anyway...
I need to add a new slave to the pool of LDAP servers. I ran slapcat
-l /tmp/myfile.ldif on the master.
Then copied the resultant ldif to the new slave.
Then ran slapadd -v -l myfile.ldif
myfile.ldif is ~250MB and the source LDAP directory contains #
numEntries: 427839
I started the slapadd 20 hours ago and it is still running....
Is this normal, given the number of entries?
Machine is Dell Poweredge 1750
Xeon 2.4GHz X 2
1024MB RAM
36GB RAID5
Thankx
M
15 years, 2 months
ppolicy "check_password" needs include files not available in install
by Chris Shenton
I'm finding the ppolicy overlay very useful for implementing our
enterprise's password policies. The build process is a bit of a
nuisance tho.
I'm using a modified version of Michael Steinmann's check_password,
based on:
http://open.calivia.com/projects/openldap/browser/check_password/
check_password.c?rev=5
It needs:
#include <portable.h>
#include <slap.h>
in order to reference structures like:
char *pPasswd, char **ppErrStr, Entry *pEntry)
{
char *szErrStr = (char *) ber_memalloc(128);
...
But those includes, and the files they include in turn, do not exist
in the installed LDAP include files. So in order to build this
little check_password.c program I have to untar and then ./configure
all the OpenLDAP source again.
I realize that check_password.c is not an official part of OpenLDAP
but would it be possible to put the include files that overlays like
this need into the installed locations so overlays wouldn't need to
get and config OpenLDAP all over again?
Or can you suggest other ways to get at the structure information
that 3rd party software like this needs to compile?
Thanks.
15 years, 2 months
crash in syncprov.c at line 1858
by Karsten Künne
Hi,
recently we ran into some problems with our OpenLDAP setup.
We're using syncrepl (not delta) and have two databases on the provider.
The first database is a LDAP database which accesses our AD and
is a subordinate of the main BDB database so that AD entries seamlessly
appear inside our main tree. The main database is replicated to
several consumers which also have the LDAP database for AD access
because we don't want to replicate the AD content in our servers.
Following are relevant pieces from our configuration:
provider:
database ldap
suffix "dc=ad,dc=our,dc=domain"
subordinate
[other directives like rootdn, uri ...]
chase-referrals yes
rebind-as-user yes
idassert-bind bindmethod=simple binddn="something" credentials="XXX"
mode=none
database bdb
suffix "dc=our,dc=domain"
[other stuff ...]
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 700
syncprov-reloadhint TRUE
(the syncprov is the last overlay)
consumer:
database ldap
suffix "dc=ad,dc=our,dc=domain"
subordinate
[other directives like rootdn, uri ...]
chase-referrals yes
rebind-as-user yes
idassert-bind bindmethod=simple binddn="something" credentials="XXX"
mode=none
database bdb
suffix "dc=our,dc=domain"
[other stuff ...]
syncrepl rid=1
provider=ldap://master.our.domain
type=refreshAndPersist
retry="10 10 300 +"
searchbase="dc=our,dc=domain"
filter="(objectclass=*)"
attrs="*,+"
schemachecking=off
scope=sub
bindmethod=sasl
saslmech=GSSAPI
authcid="something"
updateref ldap://master.our.domain
Now what happened is that the provider crashed with an assert at line 1858 in
syncprov.c. This is how this area looks like:
syncprov.c:
... 1856
if ( !rs->sr_entry ) {
assert( rs->sr_entry != NULL );
Debug( LDAP_DEBUG_ANY, "bogus referral in
context\n",0,0,0 );
return SLAP_CB_CONTINUE;
}
...
The reason for the crash is apparently that the search from the consumer went
into the LDAP database and accessed AD and AD did what it usually does and
sent back bogus referrals which triggered the assert :-(.
Now my question is, can we somehow avoid the replication search to travel into
the AD LDAP database and second, isn't the assert at that point kinda bogus?
It essentially tests for the same thing which the "if" statement before
already tested.
I also noticed that in our cn=config tree for the BDB database (which is what
we actually use for the configuration) the order of overlays in the provider
is:
{0}glue
{1}syncprov
Would it make a difference if we change that?
Karsten.
--
Another Glitch in the Call
------- ------ -- --- ----
(Sung to the tune of a recent Pink Floyd song.)
We don't need no indirection
We don't need no flow control
No data typing or declarations
Did you leave the lists alone?
Hey! Hacker! Leave those lists alone!
Chorus:
All in all, it's just a pure-LISP function call.
All in all, it's just a pure-LISP function call.
15 years, 2 months
slapcat from OL 2.3.34 -> slapadd to OL 2.4.7 fails
by Josh Miller
Good afternoon,
I'm testing OpenLDAP 2.4.7 in a lab and trying to import my production
data using slapcat/slapadd. Whenever I try to import the data into the
newly created database, I get the following error:
# slapadd -v -F /etc/openldap/slapd.d -l slapcat.out
str2entry: invalid value for attributeType objectClass #1 (syntax
1.3.6.1.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=1)
I've turned up debugging which gives no further information (that I'm
able to interpret as errors). I did see a message from a web search
which indicated that I might not have the proper schemas loaded, so I
generated another slapd.d after adding the following schemas:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/autofs.schema
include /etc/openldap/schema/calendar.schema
include /etc/openldap/schema/collective.schema
include /etc/openldap/schema/cron.schema
include /etc/openldap/schema/dhcp.schema
include /etc/openldap/schema/dnszone.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/evolutionperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/kerberosobject.schema
include /etc/openldap/schema/kolab.schema
include /etc/openldap/schema/krb5-kdc.schema
include /etc/openldap/schema/ldapns.schema
include /etc/openldap/schema/misc.schema
...so I believe I have the appropriate schemas loaded for this to work.
(I didn't see any information in the OpenLDAP admin guide which
documents this issue.)
Any ideas as to why this might be occurring or tips on troubleshooting?
TIA,
--
Joshua M. Miller - RHCE,VCP
15 years, 2 months
N-Way MultiMaster with 2.4
by Chris G. Sellers
Hello all. I've read the news posting at http://blog.suretecsystems.com/archives/40-OpenLDAP-Weekly-News-Issue-5.h...
for multimaster N-Way sync. Very good stuff.
I've configured the cn=config backend, and I can browse it with my
LDAP browser on both my Masters. (I have two servers)
I have created the replication agreements and are able to add them to
the cn=config as documented in the URL above. No problem on both
servers.
When I add the data sync, I get a little confused.
Below, for ${BACKEND} I assume I put something like bdb for the
database backend correct? If I do this it does not fail, but the sync
does not happen. I don't see a whole lot of errors either with the
sync.
dn: olcDatabase={1}$BACKEND,cn=config
objectClass: olcDatabaseConfig
objectClass: olc${BACKEND}Config
olcDatabase: {1}$BACKEND
olcSuffix: $BASEDN
olcDbDirectory: ./db
olcRootDN: $MANAGERDN
olcRootPW: $PASSWD
olcSyncRepl: rid=004 provider=$URI1 binddn="$MANAGERDN"
bindmethod=simple
credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly
interval=00:00:00:10 retry="5 5 300 5" timeout=1
olcSyncRepl: rid=005 provider=$URI2 binddn="$MANAGERDN"
bindmethod=simple
credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly
interval=00:00:00:10 retry="5 5 300 5" timeout=1
olcSyncRepl: rid=006 provider=$URI3 binddn="$MANAGERDN"
bindmethod=simple
credentials=$PASSWD searchbase="$BASEDN" type=refreshOnly
interval=00:00:00:10 retry="5 5 300 5" timeout=1
olcMirrorMode: TRUE
dn: olcOverlay=syncprov,olcDatabase={1}${BACKEND},cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
I end up with olcDatabase={1}bdb in there twice.
What should the $BACKEND value be if not bdb. (if by db backend is
bdb).
Thanks for any insight. For now, I am going to have to revert to
Master+Slave via syncrepl and referrals.
Sellers
|----------------------------------------------------------------------|
Chris G. Sellers, MLS Lead Internet Engineer
National Institute for Technology & Liberal Education
535 West William Street, Ann Arbor, Michigan 48103
chris.sellers(a)nitle.org 734.661.2318
15 years, 2 months
ldap_delete_s:Bus error
by Rakesh Yadav
Hi,
I am using ldap api's in the given sequence:
LDAP* ld = ldap_init()
......
ldap_set_options( ld,....)
......
ldap_bind_s( ld,.....)
......
ldap_search( ld,.....)
=============>till that function code is wroking fine.
ldap_delete_s( ld,....)
Here i am getting error :
Bus error
I have given the debug statements from ldap_search_s() to ldap_delete_s()
Debug statements:
---------------------------------------------------------------------------------------------------------------------------
connection_get(11): got connid=6
connection_read(11): checking for input on id=6
ber_get_next
ber_get_next: tag 0x30 len 82 contents:
ber_get_next
do_search
ber_scanf fmt ({miiiib) ber:
>>> dnPrettyNormal: <groupName=MIG,dc=cdac,dc=in>
<<< dnPrettyNormal: <groupName=MIG,dc=cdac,dc=in>, <groupName=mig,dc=cdac,dc=in>
ber_scanf fmt ({mm}) ber:
ber_scanf fmt ({M}}) ber:
=> bdb_search
bdb_dn2entry("groupName=mig,dc=cdac,dc=in")
=> send_search_entry: conn 6 dn="groupName=MIG,dc=cdac,dc=in"
ber_flush: 54 bytes to sd 11
<= send_search_entry: conn 6 exit.
send_ldap_result: conn=6 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=0
ber_flush: 14 bytes to sd 11
Returned dn: groupName=MIG,dc=cdac,dc=in
ggid: 1001
MMI_DELETE_USR_FROM_GROUP:gid=1001
MMI_DELETE_USR_FROM_GROUP:Want to delete=>ggid=1001,dc=cdac,dc=in
connection_get(11): got connid=6
connection_read(11): checking for input on id=6
ber_get_next
ber_get_next on fd 11 failed errno=0 (Success)
connection_closing: readying conn=6 sd=11 for close
connection_close: conn=6 sd=11
Bus error
--------------------------------------------------------------------------------------------------------------------------------------------
Slapd.conf:
------------------
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/new_core.schema
include /usr/local/etc/openldap/schema/gfsUserManage.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.
#referral ldap://root.openldap.org
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=cdac,dc=in"
rootdn "cn=Manager,dc=cdac,dc=in"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# 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/var/openldap-data
# Indices to maintain
index objectClass eq
olcAccess: to * by * write
-------------------------------------------------------------------------------------------------------------------------------------
Please tell why i am getting this error?
How can i overcome it?
Thanks
Rakesh Yadav
15 years, 2 months
