openldap-software January 2008

openldap-software@openldap.org

78 participants
79 discussions

ACL problem, restrict access to several attributes
by mheinric＠imn.htwk-leipzig.de 11 Jan '08

11 Jan '08

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

4 3

slap* tools require id2entry.bdb to run ?
by Josh Miller 11 Jan '08

11 Jan '08

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

6 9

Propagating schema changes
by Lionel Kernux 11 Jan '08

11 Jan '08

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

3 2

Problems using db4-utils on backend database files
by tamarin p 11 Jan '08

11 Jan '08

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?

4 4

slapadd going for a very long time
by Lionel Kernux 11 Jan '08

11 Jan '08

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

6 6

ppolicy "check_password" needs include files not available in install
by Chris Shenton 10 Jan '08

10 Jan '08

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.

2 1

crash in syncprov.c at line 1858
by Karsten Künne 10 Jan '08

10 Jan '08

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.

2 2

slapcat from OL 2.3.34 -> slapadd to OL 2.4.7 fails
by Josh Miller 10 Jan '08

10 Jan '08

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

5 8

N-Way MultiMaster with 2.4
by Chris G. Sellers 08 Jan '08

08 Jan '08

Hello all. I've read the news posting at http://blog.suretecsystems.com/archives/40-OpenLDAP-Weekly-News-Issue-5.htm… 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

4 14

ldap_delete_s:Bus error
by Rakesh Yadav 08 Jan '08

08 Jan '08

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software January 2008