openldap-technical

openldap-technical@openldap.org

22 participants
9789 discussions

syncrepl - Base DN is not within the database naming context.
by Brad T Waldorf 10 Sep '08

10 Sep '08

Sorry in advance if i'm missed something obvious (which is what the text of this error makes me think), but i've spent 2 days on this and could use another set of eyes. I hit the error in the subject when trying to set up basic refreshAndPersist replication with 2 separate BDB databases defined and populated. The error happens on only 1 of the databases (replication works fine on the other.) (slapd.conf for Master....) include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=exampleb1,dc=com" rootdn "cn=kingb1,dc=exampleb1,dc=com" rootpw password directory /usr/local/var/openldap-data/bdb1 index objectClass,sn,mail,street,pager eq database bdb suffix "o=baseballs" rootdn "cn=admin,o=baseballs" rootpw password directory /usr/local/var/openldap-data/bdb2 index objectClass,sn,mail,street,pager eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 database monitor (slapd.conf for Slave...) include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=exampleb1,dc=com" rootdn "cn=kingb1,dc=exampleb1,dc=com" rootpw password directory /usr/local/var/openldap-data/bdb1 index objectClass,sn,mail,street,pager eq database bdb suffix "o=baseballs" rootdn "cn=admin,o=baseballs" rootpw password directory /usr/local/var/openldap-data/bdb2 index objectClass,sn,mail,street,pager eq syncrepl rid=492 provider=ldap://9.00.00.000:389 type=refreshAndPersist retry="120 +" searchbase="dc=exampleb1,dc=com" bindmethod=simple binddn="cn=kingb1,dc=exampleb1,dc=com" credentials=password database monitor I get the Master up and populated before starting the Slave. When i start the Slave, i get the error. Here's the output with -d 256... (line 38 is the end of the syncrepl chunk... the "credentials=password" line) OpenLDAP 2.4.6 Standalone LDAP Server (slapd)/test/slapd_multibackendsS.conf: li ne 38: Base DN "dc=exampleb1,dc=com" is not within the database naming context.+ CSMP0097I 22.50.28 CPU-C SS-BSS SSU-HPN IS-01 failed to add syncinfo+ CSMP0097I 22.50.28 CPU-C SS-BSS SSU-HPN IS-01 slapd stopped.+ CSMP0097I 22.50.28 CPU-C SS-BSS SSU-HPN IS-01 connections_destroy: nothing to destroy.+ If i modify the syncrepl statement in the slave to replicate the other database, replication of "o=baseballs" works... syncrepl rid=493 provider=ldap://9.00.00.000:389 type=refreshAndPersist retry="120 +" searchbase="o=baseballs" bindmethod=simple binddn="cn=admin,o=baseballs" credentials=password The data in "dc=exampleb1,dc=com" is straight from the output of the MakeLDIF utility. I've added/searched/modified it a bunch before trying this particular replication scenario. So... how stupid am i?? Do you see anything i'm missing? Thanks for your help...

3 4

Openldap force replication
by Govind c 10 Sep '08

10 Sep '08

Hi, Is there a way to force the replication between Master and the slave?. The number of objects and entries are the same in both master and slave,however the some fields don`t have the same content (eg : last login time)Wondering if there is way to keep both in sync in terms of content and objects/entries. Cheers CG

3 6

Check errors from Jexplore!
by Nguyen Quang Huy 10 Sep '08

10 Sep '08

Hi all! Im Setup Openldapv2.x, Im setup following guide: http://www.linuxmail.info/openldap-setup-howto/ Im connect from Jexplore to Openldap --> OK, I can open no-ip..vv, but I open org --> error appear: Im dont know check location.. Help me! ************************************************* Nguyen Quang Huy Add: Tang 4 - Trung Tâm Tin Hoc So 8 Le Thai To - Hoan Kiem - Ha Noi Mob: 0914-257-830 Tel: 04-9288858 ext 425 Fax: + 84 4 928 9213 Email: <mailto:quanghuy@vpb.com.vn> quanghuy(a)vpb.com.vn LinQ: <mailto:kquanghuy@web.vpb.com.vn> quanghuy(a)web.vpb.com.vn

2 1

Problem With postfix
by LITLE TUX 09 Sep '08

09 Sep '08

Hi peoples .... i'm tryng configure openldap with postfix but qhen try add the below entry i receive next error: gheorghe:~/difs # ldapadd -f base.ldif -x -D cn=Administrator,dc=domain,dc=com-w 123456 adding new entry "relativeDomainName=@, ou=dns,dc=domain,dc=com" ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax My ldif file: dn: relativeDomainName=@, ou=dns,dc=domain,dc=com objectClass: dNSZone relativeDomainName: @ zoneName: domain.com dNSTTL: 3600 dNSClass: IN sOARecord: ns3.domain.com. administrator.domain.com. 2001030201 3600 1800 604800 86400 nSRecord: ns3.domain.com. mXRecord: 30 mail.domain.com. My include schemas: 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/samba3.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/qmail.schema include /etc/openldap/schema/postfix.schema Any help is welcome...!!!! Best Regards!

3 2

Help: Slow LDAP search with high %iowait
by Victor 08 Sep '08

08 Sep '08

Hi , I did quite a bit reading and research before I send email to this list for help. If I have missed some basic concepts here, please execuse my ignorance. Thanks for your help and time in advance. 1. Summary The initial search in my prototyping with OpenLDAP (slapd + BDB) seemed to be slow. What is the reason and How could I fix it? 2. Configuration 2.1 Environment Linux CentOS, 1 hard disk (therefore unfortunately the BDB transaction logs and database files are written to the same disk), 120GB disk space (80% unused), 1GB RAM, reserved for this prototyping, OpenLDAP 2.3.39 with default BDB installation 2.2 slapd.conf (modified trivially for discussion purpose) # global configuration loglevel 0 # BDB database bdb suffix "dc=test,dc=dummy,dc=com" rootdn "cn=Manager,dc=test,dc=dummy,dc=com" # 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 #Other DB configuration idlcachesize 60000 cachesize 20000 # Indices to maintain # the indexes are to support search in first name, last name and email for both exact match and wild cards in the end index objectClass eq index gn pres,eq,sub index sn pres,eq,sub index mail pres,eq,sub 2.3 DB_CONFIG (for BDB) set_cachesize 0 52428800 1 set_lg_bsize 2097512 set_flags DB_LOG_AUTOREMOVE set_lg_regionmax 262144 2.4 Data setup 2 million records (users with gn, sn, email, mobile, street address, etc. in the BDB; all records are indexed using the index in the above slapd.conf; grouped by the first character of lastName. For example, dn: ou=Z,dc=test,dc=dummy,dc=com objectclass: organizationalUnit ou: Z Sample LDIF entry: #Directory Entry dn: uid=ABCDEFGHIJKLMNOPQRSTUVWXYZ123459,ou=F,dc=test,dc=dummy,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: ABCDEFGHIJKLMNOPQRSTUVWXYZ123459 ...... (details omitted) 3. Symptom/Problem It was very slow in the first (fresh) search if I searched by wildcard firstname only like "Larry*" (which returned 478 entries/users). The response time was generally higher than 5 seconds Depending the count of records found, the response time might exceed 20 or even 50 seconds. During the search, the "iostat" result showed +95% %iowait, await was much higher that svctm, the device %util was over 96%. Here is the "iostat" output: Time: 10:51:34 AM avg-cpu: %user %nice %sys %iowait %idle 3.10 0.00 1.40 95.50 0.00 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util hda 0.00 2.90 64.94 65.33 1322.68 580.22 661.34 290.11 14.61 51.99 343.51 7.44 96.92 dm-0 0.00 0.00 64.94 72.53 1322.68 580.22 661.34 290.11 13.84 55.44 330.62 7.06 96.99 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 However, The subsequent search (using the exact search criteria) is much faster (within 200ms). I believe it is because of the cache. I did a "db_stat -m" check and saw +90% cache hit rate (I guess it is normal?). The detailed output is in the attachment. 4. Questions The "iostat" output showed obvious I/O bottleneck. Assuming I can't upgrade my hardware (for example, adding another disk specifically for writing transaction logs to), assuming I won't set a limit to the max number of entried returned, is there anything else I can do (typically BDB/slapd tuning or configuration) to make the fresh/first search much faster (say within 2 seconds for the worst case)? Did I do anything wrong? Please advise. Thanks a lot! Vic

1 0

AW: Re: AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Hauke Coltzau 08 Sep '08

08 Sep '08

Hi Quanah, thanks again for your answer. > Did you make sure the GSSAPI module was installed with Cyrus-SASL? IIRC, > it's a separate package under Ubuntu. > > p libgssapi2-heimdal > - Heimdal Kerberos - GSSAPI support library > p libsasl2-modules-gssapi-heimdal > - Pluggable Authentication Modules for SASL (GSSAPI) > p libsasl2-modules-gssapi-mit > - Cyrus SASL - pluggable authentication modules (GSSAPI) ii libsasl2-modules-gssapi-mit 2.1.22.dfsg1-18ubuntu2 \\ Cyrus SASL - pluggable authentication module > > (b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be > > running saslauthd for SASL/GSSAPI to work. > > Now I'm confused. I always understood the way to use > > Kerberos authentication for accessing the ldap directory > > to be: > > > > LDAP->SASL->Kerberos > > > > and that I have to fill the SASL part with something real, > > like saslauthd. What did I miss here? > > SASL/GSSAPI uses the existing Kerberos ticket to auth a user to LDAP > > When using saslauthd, you do a simple bind to the LDAP server, which then > connects to the KDC, gets a ticket, and auths the user. > > Two very different things. I.e., the first, the user already has authed to > the KDC. In the second, they haven't. I see the difference, but still have some questions: - In the first approach, the user already has a TGT and asks the KDC for a "ldap/fqdn@REALM-ticket"? This is done by ldapsearch, not by slapd? Hence, slapd "only" needs access to its keytab to be able to decrypt the clients messages? - And in the second one, the user provides username and password (plain), slapd converts the username into a principle (user@REALM) and forwards this to saslauthd? So this should be secured via TLS? I'm just looking for a setup that restricts access to LDAP to authenticated users (except, of course, information neccessary for authentication purposes). I need to use Kerberos for authentication, because I want to use NFSv4. There used to be a well-known howto for all this at http://www.bayour.com/LDAPv3-HOWTO.html but the site is offline for some days now. Thanks again for your help, Hauke --

1 0

AW: Re: SASL bind with Kerberos: (was: Simple binds with SASL/GSSAPI (Resource temporarily unavailable))
by Hauke Coltzau 08 Sep '08

08 Sep '08

Hi Quanah, thank you for your immediate reply. (a) Which Kerberos implementation are you using? MIT Kerberos 5 as shipped with Hardy (1.6.dfsg.3~beta1-2ubuntu1) (b) saslauthd and SASL/GSSAPI are unrelated. I.e., you don't need to be running saslauthd for SASL/GSSAPI to work. Now I'm confused. I always understood the way to use Kerberos authentication for accessing the ldap directory to be: LDAP->SASL->Kerberos and that I have to fill the SASL part with something real, like saslauthd. What did I miss here? Thanks again, Hauke p.s.: ZCS fan here ;-) --

2 1

Simple binds with SASL/GSSAPI (Resource temporarily unavailable)
by Hauke Coltzau 08 Sep '08

08 Sep '08

Hi all, I have a problem to make simple binds with authentication done by kerberos5. I use OpenLDAP to store all user account information and have everything set up so far that users can login: $ su - testuser Password: $ klist Ticket cache: FILE:/tmp/krb5cc_2000_yukVIJ Default principal: testuser@REALM Valid starting Expires Service principal 09/08/08 16:54:16 09/09/08 02:54:16 krbtgt/REALM@REALM renew until 09/09/08 16:54:16 Kerberos 4 ticket cache: /tmp/tkt2000 klist: You have no tickets cached $ id uid=2000(testuser) gid=2000(dusers) groups=2000(dusers) uid, gid,etc. have been successfully taken from the LDAP directory. But then, ldapsearch fails: $ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) $ Details: ======== Currently, the KDC and the LDAP-Server reside on the same host, running Ubuntu 8.04 x64_64. I made sure that principals exist for <fqdn>@REALM ldap/<fqdn>@REALM host/<fqdn>@REALM and exported them to /etc/krb5.keytab as well as /etc/ldap/ldap.keytab, which is now owned by the openldap user. # ktutil ktutil: rkt /etc/krb5.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 6 ldap/<fqdn>@REALM 2 6 ldap/<fqdn>@REALM 3 4 host/<fqdn>@REALM 4 4 host/<fqdn>@REALM 5 4 <fqdn>@REALM 6 4 <fqdn>@REALM ktutil: ktutil: clear ktutil: rkt /etc/ldap/ldap.keytab ktutil: l slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 6 ldap/<fqdn>@REALM 2 6 ldap/<fqdn>@REALM 3 4 host/<fqdn>@REALM 4 4 host/<fqdn>@REALM 5 4 <fqdn>@REALM 6 4 <fqdn>@REALM # ll /etc/ldap/ldap.keytab -rw------- 1 openldap openldap 512 2008-09-08 15:23 /etc/ldap/ldap.keytab (Even tried 666, but that didn't change anything. If I move this file, slapd complains, so I'm pretty sure it's actually been used) Next, I set START=yes and MECHANISMS="kerberos5" in /etc/default/saslauthd, started saslauthd and tested: # testsaslauthd -u testuser -p <secret> 0: OK "Success." As recommended, I used sasl-sample-server and /-client to test the configuration SASSL/GSSAPI <-> Kerberos: # sasl-sample-client -s ldap -m GSSAPI -n <fqdn> (partial output) service=ldap Waiting for mechanism list from server... Forcing use of mechanism GSSAPI Choosing best mechanism from: GSSAPI Using mechanism GSSAPI Preparing initial. Sending initial response... C: .... ... Username: testuser@REALM SSF: 56 Waiting for encoded message... recieved decoded message 'srv message 1' sending encrypted message 'client message 1' On the sample-server side, it's the same, 'client message 1' was successfully decoded. Next thing I did was to add following lines to /etc/ldap/slapd.conf sasl-secprops noplain,noactive,noanonymous sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth ldap:///dc=...??sub?uid=$1 sasl-regexp uid=(.*),cn=<domain>,cn=gssapi,cn=auth uid=$1,dc=... and created /usr/lib/sasl2/slapd.conf mech_list: gssapi digest-md5 cram-md5 external pwcheck_method: saslauthd saslauthd_path: /var/run/saslauthd/mux keytab: /etc/ldap/ldap.keytab Then I chgrouped /var/run/saslauthd to openldap and gave g=rwx permissions to the directory: # ls -al /var/run/saslauthd/ total 0 drwxrwxr-x 2 root openldap 100 2008-09-08 16:36 . drwxr-xr-x 15 root root 580 2008-09-08 12:13 .. srwxrwxrwx 1 root root 0 2008-09-08 16:36 mux -rw------- 1 root root 0 2008-09-08 16:36 mux.accept -rw------- 1 root root 0 2008-09-08 16:36 saslauthd.pid.lock But now, when trying ldapsearch on the same machine, it fails: $ klist Ticket cache: FILE:/tmp/krb5cc_2000_tA7220 Default principal: testuser@REALM Valid starting Expires Service principal 09/08/08 16:33:05 09/09/08 02:33:05 krbtgt/REALM@REALM renew until 09/09/08 16:33:05 09/08/08 16:33:46 09/09/08 02:33:05 ldap/<fqdn>@REALM renew until 09/09/08 16:33:05 Kerberos 4 ticket cache: /tmp/tkt2000 klist: You have no tickets cached $ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) $ And on the server side: # echo $KRB5_KTNAME /etc/ldap/ldap.keytab # slapd -d127 -h "ldap:///" -u openldap -g openldap ... >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=GSSAPI datalen=583 SASL [conn=0] Failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable) send_ldap_result: conn=0 op=1 p=3 send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Resource temporarily unavailable)" send_ldap_response: msgid=2 tag=97 err=80 ber_flush2: 158 bytes to sd 13 ... and saslauthd is not contacted at all: # saslauthd -d -a kerberos5 saslauthd[7243] :main : num_procs : 5 saslauthd[7243] :main : mech_option: NULL saslauthd[7243] :main : run_path : /var/run/saslauthd saslauthd[7243] :main : auth_mech : kerberos5 saslauthd[7243] :ipc_init : using accept lock file: /var/run/saslauthd/mux.accept saslauthd[7243] :detach_tty : master pid is: 0 saslauthd[7243] :ipc_init : listening on socket: /var/run/saslauthd/mux saslauthd[7243] :main : using process model saslauthd[7244] :get_accept_lock : acquired accept lock saslauthd[7243] :have_baby : forked child: 7244 saslauthd[7243] :have_baby : forked child: 7245 saslauthd[7243] :have_baby : forked child: 7246 saslauthd[7243] :have_baby : forked child: 7247 <no more output> What did I do wrong this time ;-) ? Best regards, Hauke --

2 2

ldapadd of LDIF files with attribute 'apple-generateduid' not allowed [Resolved]
by Alexander Hartner 07 Sep '08

07 Sep '08

At it turns out the problem was with the objectClasses. I should have used : objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: extensibleObject Instead of objectClass: top objectClass: person objectClass: inetOrgPerson Adding the extra attributes to the objectClass resolved this problem. Thanks for all your help. Regards Alex On 21 Feb 2008, at 11:56, Alexander Hartner wrote: > I am trying to import a simple LDIF file into OpenDirectory on OS X > 10.5.2 Leopard Server. > > However when I issue the following ldapadd command I get an error : > > ldapadd -D [rootdn] -x -w [secretPassword] -f Import.ldif > > Error : 65 Object class violation" > attribute 'apple-generateduid' not allowed > > > I would have thought that I had specified apple-generateduid, but I > didn't. > > This is my import file > -----------BEGIN----------- > # Alexander Hartner > dn: cn=Alexander Hartner2,cn=people,dc=macbook-znet,dc=local > objectClass: top > objectClass: person > objectClass: inetOrgPerson > displayName: Alexander Hartner2 > cn: Alexander Hartner2 > givenName: Alexander > sn: Hartner > mail: alex(a)j2anywhere.com > initials: A > o: j2anywhere.com > -----------END----------- > > I know this might not be the best forum for OS X support, but I am a > bit stuck on this. > Thanks in advance. > Alex > > >

2 2

anish_patil wants to keep up with you on Twitter
by anish_patil 07 Sep '08

07 Sep '08

To find out more about Twitter, visit the link below: http://twitter.com/i/6de68cfefa92375374ca938a55b8e865fa2162ab Thanks, -The Twitter Team About Twitter Twitter is a unique approach to communication and networking based on the simple concept of status. What are you doing? What are your friends doing—right now? With Twitter, you may answer this question over SMS, IM, or the Web and the responses are shared between contacts. This message was sent by a Twitter user who entered your email address. If you'd prefer not to receive emails when other people invite you to Twitter, click here: http://twitter.com/i/optout/dd31dad00025fa765c3307138c272038991bea18

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical