openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

overlay "syncprov" not found
by Andrew Debenham 11 Jan '10

11 Jan '10

Hello - I am new to LDAP and I'm trying to setup Sync Replication on a Fedora Core 8 system (2.6.23.9-85.fc8). However, when I start the LDAP service, I get the following error message: Checking configuration files for slapd: [FAILED] overlay "syncprov" not found slaptest: bad configuration file! I've searched the archived threads for this group (as well as many others) and wasn't able to find any postings that matched what I'm seeing. If I missed an old post by mistake, I apologize in advance. I've included a copy of my slapd.conf file below. The interesting thing is that when I comment out the following lines, LDAP will start without any issues: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 This leads me to believe that the issue is with the replication process, but I can't figure out what I'm doing wrong. I've followed the examples given in the OpenLDAP Admin Guide, but it just doesn't seem to want to work for me. Also, in case anyone asks, here are the packages installed on the server in question: openldap-2.3.39-3.fc8 openldap-devel-2.3.39-3.fc8 openldap-servers-2.3.39-3.fc8 openldap-clients-2.3.39-3.fc8 Any information or recommendations to what is happening would be greatly appreciated. Also, please let me know if I need to supply more information. Thanks in advance. - Andy # # 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/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema loglevel -1 # 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/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la moduleload back_sql.la # moduleload denyop.la # moduleload dyngroup.la # moduleload dynlist.la moduleload lastmod.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la access to attrs=userPassword by self write by anonymous auth by dn.base="cn=Manager,dc=jets,dc=local" write by * none access to * by self write by dn.base="cn=Manager,dc=jets,dc=local" write by * read ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=jets,dc=local" rootdn "cn=Manager,dc=jets,dc=local" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw b0xster rootpw {SSHA}/5PsWrAXNKNKJmhiZAfUPLkMOUcgbtXN # 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 # 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 index entryUUID,entryCSN eq # Replicas of this database #replogfile /var/lib/ldap/openldap-slave-replog overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 #lastmod on serverID 2 syncrepl rid=002 provider=ldap://10.xx.x.xx type=refreshAndPersist searchbase="dc=jets,dc=local" schemachecking=on bindmethod=simple binddn="cn=mirrormode,dc=jets,dc=local" credentials=mirrormode retry="60 +" #updateref ldap://10.xx.x.xx mirrormode on ________________________________ This email and any attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient of this email, the following stipulations govern the use of this information: You may not take any action based upon its contents. You may not copy or show this message or attachments to anyone. You should contact the sender and subsequently delete this message and all attachments. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Special Operations Technology, Incorporated. While antivirus software has been applied, you should perform due diligence to check this email and attachments for the presence of viruses. No warranties or assurances are made in relation to the safety and content of this email and attachments. Special Operations Technology, Incorporated accepts no liability for any damages caused by any virus transmitted by or contained in this email and attachments. No liability is accepted for any consequences arising from this email transmission whatsoever. Special Operations Technology, Incorporated is a premier IT professional services firm focused in the government and law enforcement space.

3 3

OpenLDAP Baseline Security Analyzer
by Inmaculada Bravo 11 Jan '10

11 Jan '10

Hello My name is Inma Bravo, I work at the University of Salamanca (Spain) mainly administrating our OpenLDAP directory. I have done a project called OpenLDAP Baseline Security Analyzer.[1] The project website is written in Spanish and in English. The purpose of this project is to develop a list of criteria that should be taken into account for the initial plan of securing the directory, and to show the most common mistakes that we must try to avoid. It briefly documents the main attacks and threats that we face as directory administrators. It is written to be easy, straightforward, and useful. These criteria are encoded in XML Schema, adhering to OCIL to use the OCIL Interpreter. I presented this project in our technical winter meeting of the institutions that are affiliated with RedIRIS (the Spanish academic and research network) [2], and it was well-received by the technicians. In conclusion, the reason I am writing you is to announce the project and to ask you for suggestions to improve and to correct it. I hope the project will be of your interest. Thanks very much Inmaculada Bravo García [1] http://openldap-bsa.forja.rediris.es/ [2] http://www.rediris.es/

1 0

Problems allowing users to change their own passowrds
by James Hammett 09 Jan '10

09 Jan '10

I know this is an old issue and I've searched on the net and tried those, but haven't had any luck. I'm using openldap 2.3.43. In /etc/openldap/slapd.conf, I have set: access to attrs=userPassword,shadowLastChange by self write by anonymous auth by * none (Of course restarted the slapd), but no luck. Insufficient permissions. The logs shows the account binding successfully, but then: vm001 slapd[pid]: => access_allowed: backend default write access denied to "uid=james,ou=Users,o=dallas" The complete logs are below. As a test I even tried giving global write access to the password, but it still doesn't work. (The only one who is able to change a users password is the Directory administrator) General log: ------------ vm001 slapd[pid]: conn=2 fd=17 ACCEPT from IP=127.0.0.1:36479 (IP=0.0.0.0:389) vm001 slapd[pid]: conn=2 op=0 BIND dn="uid=james,ou=users,o=masprt" method=128 vm001 slapd[pid]: conn=2 op=0 BIND dn="uid=james,ou=users,o=masprt" mech=SIMPLE ssf=0 vm001 slapd[pid]: conn=2 op=0 RESULT tag=97 err=0 text= vm001 slapd[pid]: conn=2 op=1 PASSMOD id="uid=james,ou=users,o=masprt" new vm001 slapd[pid]: conn=2 op=2 UNBIND vm001 slapd[pid]: conn=2 op=1 RESULT oid= err=50 text= vm001 slapd[pid]: conn=2 fd=17 closed With Debuging with ACL Listing: -------------------------------- vm001 slapd[pid]: conn=5 fd=16 ACCEPT from IP=127.0.0.1:47612 (IP=0.0.0.0:389) vm001 slapd[pid]: conn=5 op=0 BIND dn="uid=james,ou=users,o=masprt" method=128 vm001 slapd[pid]: => access_allowed: auth access to "uid=james,ou=Users,o=masprt" "userPassword" requested vm001 slapd[pid]: => access_allowed: backend default auth access granted to "(anonymous)" vm001 slapd[pid]: conn=5 op=0 BIND dn="uid=james,ou=Users,o=masprt" mech=SIMPLE ssf=0 vm001 slapd[pid]: conn=5 op=0 RESULT tag=97 err=0 text= vm001 slapd[pid]: conn=5 op=1 PASSMOD id="uid=james,ou=users,o=masprt" new vm001 slapd[pid]: => access_allowed: backend default write access denied to "uid=james,ou=Users,o=masprt" vm001 slapd[pid]: conn=5 op=1 RESULT oid= err=50 text= vm001 slapd[pid]: conn=5 op=2 UNBIND vm001 slapd[pid]: conn=5 fd=16 closed Any help or idea would be appreciated. thanks, James

2 2

refint_repair: dependent modify failed: 16
by Hung Luu 08 Jan '10

08 Jan '10

Hello, I haven't had any luck getting referential integrity to work with OpenLDAP 2.4.19 (and BerkeleyDB 4.8). Neither delete nor modify operations on DN's are triggering referenced member attributes to be removed as expected. I've tried building the overlays statically into the slapd executable and loading the overlays as dynamic modules - neither way worked for me. Thanks in advance for any help you can provide. *Here's my OpenLDAP configure settings:* env CPPFLAGS="-I/opt/BerkeleyDB.4.8/include" LDFLAGS="-L/opt/BerkeleyDB.4.8/lib" ./configure --prefix=/opt/openldap-2.4.19 --with-tls --enable-crypt --enable-syslog --enable-modules --enable-overlays=mod *Here's my slapd.config:* include /opt/openldap-2.4.19/etc/openldap/schema/core.schema include /opt/openldap-2.4.19/etc/openldap/schema/cosine.schema include /opt/openldap-2.4.19/etc/openldap/schema/inetorgperson.schema moduleload refint.la loglevel 16383 database bdb suffix "dc=phoenix,dc=edu" rootdn "cn=Manager,dc=phoenix,dc=edu" rootpw secret directory /opt/openldap-2.4.19/var/openldap-data/phoenix-edu index default eq index cn,uid,member index objectClass eq cachesize 10000 checkpoint 128 15 overlay refint refint_attributes member refint_nothing "cn=Manager" *Here's the syslog entries - starting with the delete operation and ending with the refint error:* Jan 7 10:00:58 localhost slapd[28030]: conn=0 op=37 *do_delete* Jan 7 10:00:58 localhost slapd[28030]: >>> dnPrettyNormal: <l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu> Jan 7 10:00:58 localhost slapd[28030]: <<< dnPrettyNormal: <l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu>, <l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=ed$ Jan 7 10:00:58 localhost slapd[28030]: conn=0 op=37 DEL dn="l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" Jan 7 10:00:58 localhost slapd[28030]: bdb_dn2entry("l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu") Jan 7 10:00:58 localhost slapd[28030]: ==> bdb_delete: l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu Jan 7 10:00:58 localhost slapd[28030]: bdb_dn2entry("l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu") Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: delete access to "ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" "children" requested Jan 7 10:00:58 localhost slapd[28030]: <= root access granted Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: delete access granted by manage(=mwrscxd) Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: delete access to "l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" "entry" requested Jan 7 10:00:58 localhost slapd[28030]: <= root access granted Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: delete access granted by manage(=mwrscxd) Jan 7 10:00:58 localhost slapd[28030]: => bdb_dn2id_delete 0x8: "l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu" Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_delete_key: 8 @l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_delete_key: 8 %ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_delete_key: 8 @ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_delete_key: 8 @l=southwest,ou=regions,dc=phoenix,dc=edu Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_delete_key: 8 @ou=regions,dc=phoenix,dc=edu Jan 7 10:00:58 localhost slapd[28030]: <= bdb_dn2id_delete 0x8: 0 Jan 7 10:00:58 localhost slapd[28030]: => index_entry_del( 8, "l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" ) Jan 7 10:00:58 localhost slapd[28030]: => key_change(DELETE,8) Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_delete_key: 8 [4066d3f2] Jan 7 10:00:58 localhost slapd[28030]: <= key_change 0 Jan 7 10:00:58 localhost slapd[28030]: => key_change(DELETE,8) Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_delete_key: 8 [0096defd] Jan 7 10:00:58 localhost slapd[28030]: <= key_change 0 Jan 7 10:00:58 localhost slapd[28030]: <= index_entry_del( 8, "l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" ) success Jan 7 10:00:58 localhost slapd[28030]: ====> bdb_cache_delete( 8 ) Jan 7 10:00:58 localhost slapd[28030]: daemon: epoll: listen=7 active_threads=0 tvp=zero Jan 7 10:00:58 localhost slapd[28030]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jan 7 10:00:58 localhost slapd[28030]: daemon: activity on 1 descriptor Jan 7 10:00:58 localhost slapd[28030]: bdb_delete: deleted id=00000008 dn="l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" Jan 7 10:00:58 localhost slapd[28030]: send_ldap_result: conn=0 op=37 p=3 Jan 7 10:00:58 localhost slapd[28030]: send_ldap_result: err=0 matched="" text="" Jan 7 10:00:58 localhost slapd[28030]: send_ldap_response: msgid=38 tag=107 err=0 Jan 7 10:00:58 localhost slapd[28030]: conn=0 op=37 RESULT tag=107 err=0 text= Jan 7 10:00:58 localhost slapd[28030]: daemon: activity on: Jan 7 10:00:58 localhost slapd[28030]: Jan 7 10:00:58 localhost slapd[28030]: daemon: epoll: listen=7 active_threads=0 tvp=zero Jan 7 10:00:58 localhost slapd[28030]: daemon: epoll: listen=8 active_threads=0 tvp=zero Jan 7 10:00:58 localhost slapd[28030]: => bdb_search Jan 7 10:00:58 localhost slapd[28030]: bdb_dn2entry("dc=phoenix,dc=edu") Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: search access to "dc=phoenix,dc=edu" "entry" requested Jan 7 10:00:58 localhost slapd[28030]: <= root access granted Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:58 localhost slapd[28030]: search_candidates: base="dc=phoenix,dc=edu" (0x00000001) scope=2 Jan 7 10:00:58 localhost slapd[28030]: => bdb_dn2idl("dc=phoenix,dc=edu") Jan 7 10:00:58 localhost slapd[28030]: => bdb_filter_candidates Jan 7 10:00:58 localhost slapd[28030]: AND Jan 7 10:00:58 localhost slapd[28030]: => bdb_list_candidates 0xa0 Jan 7 10:00:58 localhost slapd[28030]: => bdb_filter_candidates Jan 7 10:00:58 localhost slapd[28030]: OR Jan 7 10:00:58 localhost slapd[28030]: => bdb_list_candidates 0xa1 Jan 7 10:00:58 localhost slapd[28030]: => bdb_filter_candidates Jan 7 10:00:58 localhost slapd[28030]: EQUALITY Jan 7 10:00:58 localhost slapd[28030]: => bdb_equality_candidates (objectClass) Jan 7 10:00:58 localhost slapd[28030]: => key_read Jan 7 10:00:58 localhost slapd[28030]: bdb_idl_fetch_key: [b49d1940] Jan 7 10:00:58 localhost slapd[28030]: <= bdb_index_read: failed (-30988) Jan 7 10:00:58 localhost slapd[28030]: <= bdb_equality_candidates: id=0, first=0, last=0 Jan 7 10:00:58 localhost slapd[28030]: <= bdb_filter_candidates: id=0 first=0 last=0 Jan 7 10:00:58 localhost slapd[28030]: => bdb_filter_candidates Jan 7 10:00:58 localhost slapd[28030]: OR Jan 7 10:00:58 localhost slapd[28030]: => bdb_list_candidates 0xa1 Jan 7 10:00:58 localhost slapd[28030]: => bdb_filter_candidates Jan 7 10:00:58 localhost slapd[28030]: EXT Jan 7 10:00:58 localhost slapd[28030]: <= bdb_filter_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: <= bdb_list_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: <= bdb_filter_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: <= bdb_list_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: <= bdb_filter_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: <= bdb_list_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: <= bdb_filter_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: bdb_search_candidates: id=-1 first=1 last=15 Jan 7 10:00:58 localhost slapd[28030]: => test_filter Jan 7 10:00:58 localhost slapd[28030]: OR Jan 7 10:00:58 localhost slapd[28030]: => test_filter_or Jan 7 10:00:58 localhost slapd[28030]: => test_filter Jan 7 10:00:58 localhost slapd[28030]: EXT Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: search access to "dc=phoenix,dc=edu" "member" requested Jan 7 10:00:58 localhost slapd[28030]: <= root access granted Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:58 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:58 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:58 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:58 localhost slapd[28030]: bdb_search: 1 does not match filter Jan 7 10:00:58 localhost slapd[28030]: => test_filter Jan 7 10:00:58 localhost slapd[28030]: OR Jan 7 10:00:58 localhost slapd[28030]: => test_filter_or Jan 7 10:00:58 localhost slapd[28030]: => test_filter Jan 7 10:00:58 localhost slapd[28030]: EXT Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: search access to "ou=people,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:58 localhost slapd[28030]: <= root access granted Jan 7 10:00:58 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:58 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:58 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:58 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:58 localhost slapd[28030]: bdb_search: 2 does not match filter Jan 7 10:00:58 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "ou=groups,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 3 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "ou=regions,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 4 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "l=Southwest,ou=regions,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 5 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 6 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "l=Phoenix,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 7 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "cn=enc,ou=groups,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 9 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "cn=enm,ou=groups,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 10 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "cn=aac,ou=groups,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 11 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "uid=alice,ou=people,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 12 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "uid=bob,ou=people,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 13 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "cn=enm,uid=alice,ou=people,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: >>> dnNormalize: <l=Southwest,ou=regions,dc=phoenix,dc=edu> Jan 7 10:00:59 localhost slapd[28030]: <<< dnNormalize: <l=southwest,ou=regions,dc=phoenix,dc=edu> Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 5 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 5 Jan 7 10:00:59 localhost slapd[28030]: bdb_search: 14 does not match filter Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: OR Jan 7 10:00:59 localhost slapd[28030]: => test_filter_or Jan 7 10:00:59 localhost slapd[28030]: => test_filter Jan 7 10:00:59 localhost slapd[28030]: EXT Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access to "cn=enc,uid=bob,ou=people,dc=phoenix,dc=edu" "member" requested Jan 7 10:00:59 localhost slapd[28030]: <= root access granted Jan 7 10:00:59 localhost slapd[28030]: => access_allowed: search access granted by manage(=mwrscxd) Jan 7 10:00:59 localhost slapd[28030]: >>> dnNormalize: <l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu> Jan 7 10:00:59 localhost slapd[28030]: <<< dnNormalize: <l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu> Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 6 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter_or 6 Jan 7 10:00:59 localhost slapd[28030]: <= test_filter 6 Jan 7 10:00:59 localhost slapd[28030]: refint_search_cb <cn=enc,uid=bob,ou=people,dc=phoenix,dc=edu> Jan 7 10:00:59 localhost slapd[28030]: refint_search_cb: member: l=Southern Arizona,ou=campuses,l=Southwest,ou=regions,dc=phoenix,dc=edu (#1) Jan 7 10:00:59 localhost slapd[28030]: send_ldap_result: conn=-1 op=0 p=0 Jan 7 10:00:59 localhost slapd[28030]: send_ldap_result: err=0 matched="" text="" Jan 7 10:00:59 localhost slapd[28030]: refint_search_cb <NOTHING> Jan 7 10:00:59 localhost slapd[28030]: bdb_modify: cn=enc,uid=bob,ou=people,dc=phoenix,dc=edu Jan 7 10:00:59 localhost slapd[28030]: bdb_dn2entry("cn=enc,uid=bob,ou=people,dc=phoenix,dc=edu") Jan 7 10:00:59 localhost slapd[28030]: bdb_modify_internal: 0x0000000f: cn=enc,uid=bob,ou=people,dc=phoenix,dc=edu Jan 7 10:00:59 localhost slapd[28030]: <= acl_access_allowed: granted to database root Jan 7 10:00:59 localhost slapd[28030]: bdb_modify_internal: delete member Jan 7 10:00:59 localhost slapd[28030]: dnMatch 0 "l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=edu" "l=southern arizona,ou=campuses,l=southwest,ou=regions,dc=phoenix,dc=e$ Jan 7 10:00:59 localhost slapd[28030]: bdb_modify_internal: replace modifiersName Jan 7 10:00:59 localhost slapd[28030]: bdb_modify_internal: delete member Jan 7 10:00:59 localhost slapd[28030]: bdb_modify_internal: 16 modify/delete: member: no such attribute Jan 7 10:00:59 localhost slapd[28030]: bdb_modify: modify failed (16) Jan 7 10:00:59 localhost slapd[28030]: send_ldap_result: conn=-1 op=0 p=0 Jan 7 10:00:59 localhost slapd[28030]: send_ldap_result: err=16 matched="" text="modify/delete: member: no such attribute" Jan 7 10:00:59 localhost slapd[28030]: *refint_repair: dependent modify failed: 16*

1 0

Error configuring monitor database
by Diego Lima 07 Jan '10

07 Jan '10

Hello all, I'm trying to set up monitoring via slapd.conf according to this guide: http://www.openldap.org/devel/admin/monitoringslapd.html However after setting it up and trying to test it I receive the following error message: root@gilead:/opt/fedora-ds# bin/ldapsearch -x -D "cn=Directory Manager,o=xxx,o=xxx,c=br" -W -b 'cn=monitor' -s base '(objectClass=*)' '*' '+' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <cn=monitor> with scope baseObject # filter: (objectClass=*) # requesting: * + # # search result search: 2 result: 32 No such object # numResponses: 1 This is what I've added to my slapd.conf: database monitor access to * by dn.exact="cn=Directory Manager,o=xxx,o=xxx,c=br" by * none I've restarted slapd after adding the entries above. Is there something else that must be done? Thanks! -- Diego Lima

2 2

Consumer ACLs
by Jaap Winius 07 Jan '10

07 Jan '10

Hi all, A question regarding ACLs on OpenLDAP consumer servers. If the ACLs on the provider give clients write access to some attributes, such as loginShell or userPassword, shouldn't the ACLs on the consumers do the same? I'm not sure about this, since consumer databases are always read-only, but it seems to me that the clients would otherwise have no way of knowing that changing certain attributes was possible (via the updateref option or the chain overlay). Thanks, Jaap

2 1

Password Policy setting
by Saavedra, Gisella 07 Jan '10

07 Jan '10

I read the entry in Chapter 6 http://www.zytrax.com/books/ldap/ch6/ppolicy.html#examples regarding setting the Password Policy Control. I have installed OpenLDAP through Cygwin. OpenLDAP is version 2.3.43 I created my db and included the Password Policy control schema, but I am getting the following error when I try to load my default and user policies: $ ldapadd -H ldap://localhost:666 -x -D "cn=Manager,dc=zes_example,dc=com" -w secret -f /etc/openldap/data/ppolicy.ldif adding new entry "ou=pwdpolicies,dc=zes_example,dc=com" adding new entry "cn=default,ou=pwdpolicies,dc=zes_example,dc=com" ldapadd: Object class violation (65) additional info: no structural object class provided Any idea? Do I need to add the password policy (ldif file) before I give the directive in slapd.conf? ----------------------------------------- The policy.ldif: dn: ou=pwdpolicies,dc=zes_example,dc=com ou: pwdpolicies description: All password Policies objectclass: organizationalunit # Default Password Policy dn: cn=default,ou=pwdpolicies,dc=zes_example,dc=com objectClass: pwdPolicy cn: default # User can change his/her password pwdAllowUserChange: TRUE # Return warning to bind attempt (seconds) -- 3 days pwdExpireWarning: 259200 # Interval in seconds to reset failure pwd count pwdFailureCountInterval: 100 # Do not allow to bind on expired passwords pwdGraceAuthNLimit: 0 # Reject any password changes in this list pwdInHistory: 3 # Lock out account when user tries more than x attempts using invalid password pwdLockout: TRUE # Do not allow the system to unlock the account pwdLockoutDuration: 0 # Consecutinve # of failure attempts pwdMaxFailure: 5 # How long the password lasts before user has to change it (seconds) -- 90 days pwdMaxAge: 77760000 # Password length pwdMinLength: 6 The commands in my slapd.conf are: ... include /etc/openldap/schema/ppolicy.schema ... (not usre if I need the next line) loadmodule ppolicy.la # invokes password policies for this DIT only overlay ppolicy # Default ppolicy ppolicy_default "cn=default,ou=pwdpolicies,dc=zes_example,dc=com" # Some ppolicy directives ppolicy_use_lockout Gisella Saavedra Sr. Software Engineer gsaavedra(a)zebra.com<mailto:gsaavedra@zebra.com> [cid:image001.gif@01CA8D67.CCDB6A40] 1000 Broadway, Suite 150, Oakland, CA 94607 | T+1 510 267 5123 T Main+1 510 267 5000 F+1 510 267 5100 | http://www.zebra.com/zes ________________________________ - CONFIDENTIAL- This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.

3 2

Server Side sort and the cn attribute
by Edward Capriolo 06 Jan '10

06 Jan '10

We use openldap as a back end for many things. One of the thing, it can be used for is an address book for outlook. Recently we upgrade to 2.4.16->2.4.20 from 2.(who knows how old). Outlook 2003 clients stopped working: http://support.microsoft.com/kb/555536 So I followed the instructions here to enable server side sorting: http://bacedifo.blogspot.com/2009/09/server-side-sort-with-openldap2418.html I was able to add the ordering to the sn attribute. attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' ORDERING caseIgnoreOrderingMatch SUP name ) Unfortunately outlook is looking at the cn attribute @400000004b21316a0e808064 sssvlv: no ordering rule specified and no default ordering rule for attribute cn @400000004b21316a0e808834 <= get_ctrls: n=1 rc=18 err="serverSort control: No ordering rule" That unfortunately is not defined in the core.schema # system schema #attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) # DESC 'RFC2256: common name(s) for which the entity is known by' # SUP name ) I am sure there is a good reason why cn does not have an ordering, but I am guessing it used to have this in the distant past since this previously worked. So how would I go about changing the system schema? Or does anyone have a better way to deal with this. (I know I could play with client registry (kb) article but I would like to handle this server side) Thank you for your insights.

1 1

Password Policy - Password Modification
by SAGNIMORTE Thomas (CAMPUS) 06 Jan '10

06 Jan '10

Hello, I get some trouble with the password policy settings. I try to modify an user password when I am connected as an admin, but I can't due tu "User Alteration of Password is not allowed". I connect with an "Admin profile" who have right to write on all the directory Jan 5 15:06:25 clawma01 slapd[4363]: conn=94459 op=0 BIND dn="cn=adm_alecle23,ou=administrator,ou=security,o=oxylane" mech=SIMPLE ssf=0 Jan 5 15:06:25 clawma01 slapd[4363]: conn=94459 op=0 RESULT tag=97 err=0 text= When I try to change a password for a standard user, I get this error message. Jan 5 15:06:43 clawma01 slapd[4363]: conn=94459 op=12 MOD dn="uid=o2alecle23,ou=o2,ou=people,o=oxylane" Jan 5 15:06:43 clawma01 slapd[4363]: conn=94459 op=12 MOD attr=userPassword Jan 5 15:06:43 clawma01 slapd[4363]: conn=94459 op=12 RESULT tag=103 err=50 text=User alteration of password is not allowed Here is the password policy used for this user dn: cn=userDefault,ou=policy,ou=security,o=oxylane objectClass: top objectClass: pwdPolicy objectClass: person cn: userDefault pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 1 pwdExpireWarning: 432000 pwdFailureCountInterval: 1800 pwdGraceAuthNLimit: 0 pwdInHistory: 10 pwdLockout: TRUE pwdLockoutDuration: 0 pwdMaxAge: 2764800 pwdMaxFailure: 15 pwdMinAge: 172800 pwdMinLength: 6 pwdMustChange: FALSE sn: default_user Could I change password for an user with an other account instead of rootdn? How can I allow admin user to change password of standard user? Regards, Thomas

1 0

ldap_modify_s Insufficient access
by Fujisan 04 Jan '10

04 Jan '10

Users in my LDAP database have trouble changing passwords. $ passwd Changing password for user XXX. Enter login(LDAP) password: New password: Retype new password: LDAP password information update failed: Insufficient access passwd: Authentication token manipulation error In /var/log/message, I have: passwd: pam_ldap: ldap_modify_s Insufficient access In slapd.conf on the server, I have the following: database bdb suffix dc=mydomain,dc=fr checkpoint 1024 15 rootdn cn=Manager,dc=mydomain,dc=fr rootpw {SSHA}XXXXX access to attrs=userPassword by self write by * none access to dn.subtree="dc=mydomain,dc=fr" by dn="cn=Manager,dc=mydomain,dc=fr" write by self write by * read Any idea what is wrong? Thanks in advance. F.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical