Search results for "starttls" - openldap-technical

Problems using OpenLPAP for authentification of users: Client library issues STARTTLS but TLS is not configured

by Jörg Spilker

Hi, well, i don´t know what i´m doing wrong. I just want to authenticate unix and windows users against OpenLDAP Database. I followed some howtos to setup openldap, winbind etc. and nearly everything seems just fine. But authenticating unix users finally doesn´t work. I´ve attached the syslog output. START TLS extension not supportet. This is true, as i haven´t configured OpenLPAP for TLS. But my LDAP client configuration doesn´t specify an LDAPS URL. So what´s going wrong? Greeting, Jörg # # This is the configuration file for the LDAP nameservice # switch library, the LDAP PAM module and the shadow package. # # Your LDAP server. Must be resolvable without using LDAP. URI ldap://localhost # The distinguished name of the search base. base dc=jetsys,dc=de # The LDAP version to use (defaults to 3 # if supported by client library) ldap_version 3 # Don't try forever if the LDAP server is not reacheable bind_policy soft # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. binddn cn=Manager,dc=jetsys,dc=de # The credentials to bind with. # Optional: default is no credential. bindpw XXXXXXXXX # The distinguished name to bind to the server with # if the effective user ID is root. Password is # stored in /etc/ldap.secret (mode 600) rootbinddn cn=Manager,dc=jetsys,dc=de Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 fd=23 ACCEPT from IP=127.0.0.1:15332 (IP=0.0.0.0:389) Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=0 RESULT tag=120 err=2 text=unsupported extended operation Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 op=1 UNBIND Jul 9 07:32:26 xdaolin slapd[2241]: conn=702 fd=23 closed Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 fd=23 ACCEPT from IP=127.0.0.1:15333 (IP=0.0.0.0:389) Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=0 RESULT tag=120 err=2 text=unsupported extended operation Jul 9 07:32:26 xdaolin slapd[2241]: conn=703 op=1 UNBIND Jul 9 07:32:27 xdaolin slapd[2241]: conn=703 fd=23 closed Jul 9 07:32:27 xdaolin getent: nss_ldap: could not search LDAP server - Server is unavailable

16 years, 11 months

Re: syncprov_db_open: invalid config, lastmod must be enabled

by Howard Chu

Dieter Klünter wrote: > Am Mon, 16 Jan 2012 11:03:25 +0100 > schrieb "Angel L. Mateo"<amateo(a)um.es>: > >> Hi, >> >> I'm trying to configure chain overlay in a ldap replica >> consumer. My final purpose is that if this node receives an update, >> it directly tries to make it in the provider node, instead of >> returning the referrral. Is that possible? I think so... >> >> But I have a problem with the configuration. My config is >> >> ... >> moduleload back_ldap >> moduleload syncprov >> ... >> database hdb >> suffix dc=<mysuffix> >> ... >> overlay syncprov >> >> syncrepl rid=31 >> provider="ldap://<provider>" >> binddn="<replica user dn>" >> bindmethod=simple >> credentials=<password> >> searchbase="dc=<mysuffix>" >> type=refreshAndPersist >> interval=00:00:00:10 >> retry="5 5 300 +" >> timeout=1 >> >> overlay chain >> chain-max-depth 1 >> chain-return-error true >> >> chain-uri ldap://<provider> >> chain-rebind-as-user yes >> chain-idassert-bind bindmethod=simple >> binddn=<replica user dn> >> credentials=<password> >> starttls=no >> mode="self" >> >> But when I test configuration with slaptest, I get: >> >> root@canis32:/etc/ldap# slaptest -f /etc/ldap/slapd.conf >> syncprov_db_open: invalid config, lastmod must be enabled >> backend_startup_one (type=hdb, suffix="<mysuffix>"): bi_db_open >> failed! (-1) slap_startup failed (test would succeed using the -u >> switch) >> >> and I can't run slapd. Any idea? >> >> I'm running slapd 2.4.21 (ubuntu lucid package) >> > > The chain overlay has to be configured in the global part, prior to any > database declaration. That might be true, but the actual error here is that the syncprov overlay has been included even though there is no need for it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

13 years, 4 months

Re: Security between server and client nodes.

by Raffael Sahli

On 11/30/2011 08:01 AM, Jayavant Patil wrote: > > > On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil > <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote: > > > >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli > <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote: > >>Hi > > >>I think you mean SSL connection or the STARTTLS Layer...? > >>Please read the manual http://www.openldap.org/doc/admin24/tls.html > >Ok. > > >>And tree security: > >>On my server, a client user can only see his own object: > >Are you using simple authentication mechanism? > > >>Maybe create a rule like this: > >>access to filter=(objectClass= > >>simpleSecurityObject) > >> by self read > >> by * none > > >I am not getting what the ACL rule specifies. Any suggestions? > > > I have two users ldap_6 and ldap_7. I want to restrict a user to > see his own data only. > In slapd.conf, I specified the rule as follows: > access to * > by self write > by * none > > But ldap_6 can see the ldap_7 user entries (or vice versa) with > $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b > "ou=People,dc=abc,dc=com" "uid=ldap_7" > > Any suggestions? > Yes, that's exactly the rule I wrote above. access to filter=(objectClass=simpleSecurityObject) by self read by * none Maybe you have to change the objectClass to posixAccount, or both or whatever.... access to filter=(|(objectClass=simpleSecurityObject)(objectClass=posixAccount)) by self read by * none Just add this rule before the global rule "access to *" >ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b "ou=People,dc=abc,dc=com" "uid=ldap_7" And if you search like this with bind "admin dn", you will see every object.... You have to bind with user ldap_6 and not with root > > > -- > > Thanks & Regards, > > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. > > > > > -- > > Thanks & Regards, > Jayavant Ningoji Patil > Engineer: System Software > Computational Research Laboratories Ltd. > Pune-411 004. > Maharashtra, India. > +91 9923536030. > -- Raffael Sahli public(a)raffaelsahli.com

13 years, 6 months

Proper Way To Securely Bind With LDAP Server

by Douglas Duckworth

Hi As I have read the StartTLS extended operation seems to be preferred over SSL: http://www.openldap.org/faq/data/cache/605.html Therefore* I have always* used -ZZ with ldap://URI to bind to my server. Eg: ldapsearch -ZZ -b base -H ldap://server -D uid=admin,ou=users,base -W cn=search I thought this would thus encrypt my password by encapsulating the TCP 389 connection with TLS encryption. However, to my severe dismay, I can see my password in "-d3" debug output, using the above command, as well as when dropping the -ZZ and using ldaps:// Can you please provide guidance? ldap_url_parse_ext(ldap://ldap.server.domain) ldap_create ldap_url_parse_ext(ldap://ldap.server.domain:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP ldap.server.domain:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying LDAP_SERVER:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_write: want=31, written=31 0000: 30 1d 02 01 01 77 18 80 16 31 2e 33 2e 36 2e 31 0....w...1.3.6.1 0010: 2e 34 2e 31 2e 31 34 36 36 2e 32 30 30 33 37 .4.1.1466.20037 ldap_result ld 0xdea060 msgid 1 wait4msg ld 0xdea060 msgid 1 (infinite timeout) wait4msg continue ld 0xdea060 msgid 1 all 1 ** ld 0xdea060 Connections: * host: ldap.server.domain port: 389 (default) refcnt: 2 status: Connected last used: Fri Sep 22 10:23:35 2017 TLS certificate verification: subject: CN=ldap.server.domain,OU=BLAH,issuer: CN=InCommon RSA Server CA,OU=InCommon,O=Internet2,L=Ann Arbor,ST=MI,C=US, cipher: *AES-256*, *security level: high*, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 Enter LDAP Password: <-- I Enter Password The server logs show: Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin" method=128 Sep 22 10:27:41 server slapd[21471]: conn=131126 op=1 BIND dn="admin" mech=SIMPLE ssf=0 The password then appears in -d3 output after I authenticate. However, I do not see the password in tcpdump using a full packet capture on both the client and ldap server. As expected I do see the password in tcpdump when dropping the -ZZ and using -x for simple bind. So in summary seeing credentials when using -ZZ and -d3 should not bring concern as they're encrypted over the wire. So I guess can you explain how "-d3" works? Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690

7 years, 8 months

Re: Openldap for proxy AD

by Peter Gietz

Hi, since it is working for a lot of people (including some of our customers) it seems that you are doing something wrong. What about the contents of your entries: Are you sure that you have the attribute userPassword with the value {SASL}<username>@<AD-realm> set in all entries that are to bind via AD? Cheers, Peter Am 22.11.2013 15:05, schrieb Willy Ramos: > Em 22/11/2013 09:21, Andrew Findlay escreveu: >> On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote: >> >>> Subject: Re: Openldap for proxy AD >> Have you tried following the examples in the Admin Guide? >> >> http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentica… >> >> >> There is a detailed setup and diagnosic guide there which should help >> you >> to isolate the problem. >> >> Andrew > > Thanks Andrew, > > I was testing based in this Admin Guide. > > When I Check that the user can bind to AD: > > ldapsearch -x -H ldap://dc1.example.com/ \ > -D cn=user,cn=Users,DC=ad,DC=example,DC=com \ > -w userpassword \ > -b cn=user,cn=Users,DC=ad,DC=example,DC=com \ > Or with > -s base \ > "(objectclass=*)" > Or > > testsaslauthd -u user -p userpassword > > It´s works. > > I was reading about and Seems don´t find the schemas of objectclass or > userPassword attribute; > > But I could not resolve yet. > > See the logs > > > Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from > IP=127.0.0.1:51698 (IP=0.0.0.0:636) > Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established > tls_ssf=256 ssf=256 > Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT > oid=1.3.6.1.4.1.1466.20037 > Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS > Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1 > text=TLS already started > Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND > Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed > > Thanks. > -- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz(a)daasi.de web: www.daasi.de Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz

11 years, 6 months

LDAP Replica TLS problem

by Elmopi, Stefano

Hi, I'm having trouble to run the replica LDAP with TLS, without TLS, all works !! Provider and Consumer are identical CentOS release 6.5 rpm -qa | grep ldap openldap-clients-2.4.23-34.el6_5.1.x86_64 openldap-2.4.23-34.el6_5.1.x86_64 apr-util-ldap-1.3.9-3.el6_0.1.x86_64 nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64 mod_authz_ldap-0.26-16.el6.x86_64 pam_ldap-185-11.el6.x86_64 openldap-servers-2.4.23-34.el6_5.1.x86_64 Provider config, file cn\=config.ldif olcTLSCACertificateFile: /etc/openldap/certs/ldapscert.pem olcTLSCertificateFile: /etc/openldap/certs/ldapscert.pem olcTLSCertificateKeyFile: /etc/openldap/certs/keys/ldapskey.pem olcTLSCipherSuite: TLSv1+RSA:!EXPORT:!NULL olcTLSVerifyClient: never Consumer config: olcSyncrepl: {0}rid=000 provider=ldap://ldpsoc01devpom.sociale.it starttls=yes type=refreshonly retry="5 5 300 +" searchbase="dc=example,dc=it" attrs="*,+" bindmethod=simple binddn="uid=xxxxxxxx,ou=admin_bind,ou=Utenze_Amministratori,dc=example,dc=it" credentials=xxxxxxx interval=60 and, in /etc/openldap/ldap.conf TLS_CACERT /etc/openldap/certs/ldapscert.pem TLS_REQCERT never the certificate is self-signed On the slave, if I try the following command: ldapsearch -ZZ -x -H ldap://ldpsoc01devpom -D 'uid=xxxxxxx,ou=admin_bind,ou=Utenze_Amministratori,dc=example,dc=it' -W 'objectclass=*' -v everything is ok but when I try to use TLS in replication, the process goes wrong. In the Provider log: connection_get(16) connection_get(16): got connid=1030 connection_read(16): checking for input on id=1030 connection_read(16): TLS accept failure error=-1 id=1030, closing connection_closing: readying conn=1030 sd=16 for close connection_close: conn=1030 sd=16 daemon: activity on 1 descriptor daemon: activity on: In the Consumer log: slapd[6508]: =>do_syncrepl rid=000 slap_client_connect: URI=ldap://ldpsoc01devpom.sociale.it Warning, ldap_start_tls failed (-11) slap_client_connect: URI=ldap://ldpsoc01devpom.sociale.it DN="uid=bind_replica,ou=admin_bind,ou=utenze_amministratori,dc=sociale,dc=it" ldap_sasl_bind_s failed (-1) do_syncrepl: rid=000 rc -1 retrying (3 retries left) daemon: activity on 1 descriptor daemon: activity on: Help, I do not know where to turn !!!! Thanks Ing. Stefano Elmopi Cooperativa Capodarco - Resp. Area ICT Gestione Esercizio Via Ostiense 131/L Corpo B, 00154 Roma cell. 3466147165 tel. 0657060500 email:stefano.elmopi@sociale.it -- "Ai sensi e per gli effetti della legge sulla tutela dei dati personali (D.lgs 196/2003), le informazioni contenute nella presente @mail sono di natura riservata e destinate ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso personale; come tali, pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E' proibito leggere, copiare, usare o diffondere il contenuto della presente @mail senza autorizzazione. Se avete ricevuto questa @mail per errore, siete pregati di rispedire la stessa al mittente. Grazie"

10 years, 7 months

Re: 回复： mirror mode question

by Dieter Klünter

Hi, http://pastebin.de/41448 -Dieter Am Wed, 5 Mar 2014 22:04:05 +0800 schrieb "Eileen(=^ω^=)" <123784635(a)qq.com>: > Hi Michael and Dieter, > > > Thanks for your kindly replies. > In my case, I didn't use any SASL or TLS but "simple" method with > operation mode of user/password authenticated. However, I need the > rootpw hashed (not cleartext) and the 2 servers (master & slave) > synchronized. Could you pls advise how i should modify the syncrepl > part? or could you pls provide a sample of the slapd.conf file > configuration? > > > Best regards, > > > Eileen > > > ------------------ 原始邮件 ------------------ > 发件人: "Michael Ströder";<michael(a)stroeder.com>; > 发送时间: 2014年3月5日(星期三) 下午4:09 > 收件人: "Dieter Klünter"<dieter(a)dkluenter.de>; > "openldap-technical"<openldap-technical(a)openldap.org>; > > 主题: Re: mirror mode & sasl question > > > > Dieter Klünter wrote: > > Am Wed, 5 Mar 2014 14:38:04 +0800 > > schrieb "Eileen(=^ω^=)" <123784635(a)qq.com>: > >> This is Eileen from China SINAP. I am a beginner for openldap > >> soft. I encountered a problem in my study on two LDAP services > >> replication. I have 2 LDAP services, one name LDPA1, the other is > >> LDAP2 . I want to make them synchronously in mirror mode. But when > >> I set LDAP services rootpw both in hash, the 2 LDAP serivces can’t > >> be synchronous. My question is > >> 1. if I set my rootpw in hash, my bindmethod must be SASL? If > >> I must use sasl method, can I put the sasl service in the same ldap > >> service? If bindmethod=sasl then what is the saslmech should be? > >> 2. If I change to sasl method, do I need change my database > >> record? > > > > In order to use sasl, passwords must be cleartext and you should > > configure an apropriate authz-regexp, see man slapd.conf(5) > > You may use any sasl mechanism that you sasl framework provides. > > [...] > > To be more precise: In order to use password-based SASL mechs the > passwords have to be stored in clear-text. > > Well, if working with SASL and TLS (LDAPS, StartTLS) one should > consider using client certs and SASL/EXTERNAL for replication. > > Ciao, Michael. -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

11 years, 3 months

Problem getting monitor backend and syncrepl overlay to work

by DeMoNs＠web.de

Hi all, i have a problem getting openldap to run monitor backend AND syncrepl overlay. i'm running freebsd-7.2-release-p6 in combination with openldap-server-2.4.19 with sasl support compiled in. i use the following slapd config: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/ldapns.schema include /usr/local/etc/openldap/schema/radius.schema pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args logfile /var/log/slapd.log password-hash {SSHA} modulepath /usr/local/libexec/openldap moduleload back_bdb moduleload back_monitor access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by ssf=128 dn="cn=admin,dc=example,dc=de" write by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read by anonymous auth by * none access to attrs=userPassword by self write by anonymous auth by * none database bdb suffix "dc=example,dc=de" rootdn "dc=example,dc=de" directory /var/db/openldap-data index objectClass,entryCSN,entryUUID eq index uid pres,eq,sub index memberUID eq index uidNumber,gidNumber eq index host eq database monitor rootdn "cn=monitoring,cn=Monitor" rootpw monitoring access to dn.subtree="cn=Monitor" by dn="cn=nssadmin,dc=example,dc=de" by * none syncrepl rid=041 provider=ldap://ldap-master.example.de type=refreshOnly interval=00:00:35:00 searchbase="dc=example,dc=de" schemachecking=off bindmethod=simple starttls=yes binddn="cn=syncuser,dc=example,dc=de" credentials="strongsecretpassword" TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem loglevel 256 now, when i run slaptest i receive following error: /usr/local/etc/openldap/slapd.conf: line 59: database monitor does not support operations required for syncrepl slaptest: bad configuration file! Line 59 corresponds to the credentials option in the synrepl statement. i can't figure out whats wrong, so if anyone can point me in the right direction that would be really helpful. thanks in advance, david

15 years, 3 months

Re: TLSVerifyClient => no login possible

by Dieter Kluenter

Hello Sebastian, Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes: > Dieter Kluenter schrieb: >> Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes: >> >> >>> Hello, >>> >>> I have configured an openSUSE 11.0 (x86_64) with openldap- server. Also >>> the TLS is activated. All clients are set to "TLS_REQCERT demand" >>> and is working. >>> Then I created client certificates by using the servers Yast2 CA- >>> management. I copied teh client certificates and also the servers >>> "cacert" into the "/etc/openldap/" directory on client computer. With >>> "TLSVerifyClient allow" clients can login, but if I activate the >>> "TLSVerifyClient demand" option in servers slapd.conf no user can >>> perform an login and it causes errors in /var/log/messages: >>> >> [...] >> >> >>> What is wrong? The clients certificate "common name" is set to the >>> clients hostname. Is this ok? >>> >> >> Clients don't read slapd.conf(5) but only ldap.conf(5), run slapd with >> debug level 3 to analyse the tls session. >> >> -Dieter >> >> > Hello Dieter, > > Now I have set the loglevel to "3" and I get the following output if I > try to login (still fails): loglevel is != debug level, man slapd(8), run slapd -d3 > -------------------/var/log/messages--------------------------------------------------------------------- [...] > Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search > LDAP server - Server is unavailable [...] > Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s: > Connect error > -------------------/var/log/messages--------------------------------------------------------------------- > > I am not sure, if this is an configuration or certificate error? Do You > understand this output above? The clients are nss_ldap and pam_ldap, check the clients configuration for starttls parameters. With debug level 3 you should see something like TLS trace: SSL_accept:before/accept initialization tls_read: want=11, got=11 TLS trace: SSL_accept:SSLv3 read client hello A TLS trace: SSL_accept:SSLv3 write server hello A TLS trace: SSL_accept:SSLv3 write certificate A TLS trace: SSL_accept:SSLv3 write certificate request A tls_write: want=1931, written=1931 TLS trace: SSL_accept:SSLv3 flush data TLS trace: SSL3 alert write:warning:close notify -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html sip: +49.180.1555.7770535 GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

16 years, 3 months

adding new databases and olc*dbconfig must attributes

by ben thielsen

i was experimenting a bit with adding new databases to the config, and found that if the olcsuffix attribute was not provided, it would fail: >cat db.ldif dn: olcDatabase=hdb,cn=config changetype: add objectClass: olcHdbConfig olcDatabase: hdb olcDbDirectory: /var/lib/ldap/example.org >ldapadd -xWZZH 'ldap://dsa.example.com/' -D 'uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com' -f db.ldif Enter LDAP Password: adding new entry "olcDatabase=hdb,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: <olcDbDirectory> failed startup >tail -F slapd.log Feb 21 19:39:41 flip slapd[19134]: conn=1535 fd=64 ACCEPT from IP=192.168.1.1:36891 (IP=0.0.0.0:389) Feb 21 19:39:41 flip slapd[19134]: conn=1535 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 21 19:39:41 flip slapd[19134]: conn=1535 op=0 STARTTLS Feb 21 19:39:41 flip slapd[19134]: conn=1535 op=0 RESULT oid= err=0 text= Feb 21 19:39:41 flip slapd[19134]: conn=1535 fd=64 TLS established tls_ssf=128 ssf=128 Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" method=128 Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" mech=SIMPLE ssf=0 Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=1 RESULT tag=97 err=0 text= Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=2 ADD dn="olcDatabase=hdb,cn=config" Feb 21 19:39:43 flip slapd[19134]: hdb_db_open: need suffix. Feb 21 19:39:43 flip slapd[19134]: backend_startup_one (type=hdb, suffix="(null)"): bi_db_open failed! (-1) Feb 21 19:39:43 flip slapd[19134]: olcDbDirectory: value #0: <olcDbDirectory> failed startup (0?:?X#024c?/ldap/example.org)! Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=2 RESULT tag=105 err=80 text=<olcDbDirectory> failed startup Feb 21 19:39:43 flip slapd[19134]: conn=1535 op=3 UNBIND Feb 21 19:39:43 flip slapd[19134]: conn=1535 fd=64 closed providing an olcSuffix attribute in the ldif allowed the new database to be added without error: >ldapadd -xWZZH 'ldap://dsa.example.com/' -D 'uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com' -f db.ldif Enter LDAP Password: adding new entry "olcDatabase=hdb,cn=config" >tail -F slapd.log Feb 21 19:43:21 flip slapd[19134]: conn=1537 fd=44 ACCEPT from IP=192.168.1.1:36900 (IP=0.0.0.0:389) Feb 21 19:43:21 flip slapd[19134]: conn=1537 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 21 19:43:21 flip slapd[19134]: conn=1537 op=0 STARTTLS Feb 21 19:43:21 flip slapd[19134]: conn=1537 op=0 RESULT oid= err=0 text= Feb 21 19:43:21 flip slapd[19134]: conn=1537 fd=44 TLS established tls_ssf=128 ssf=128 Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" method=128 Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=1 BIND dn="uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=com" mech=SIMPLE ssf=0 Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=1 RESULT tag=97 err=0 text= Feb 21 19:43:23 flip slapd[19134]: conn=1537 op=2 ADD dn="olcDatabase=hdb,cn=config" Feb 21 19:43:24 flip slapd[19134]: conn=1537 op=2 RESULT tag=105 err=0 text= Feb 21 19:43:24 flip slapd[19134]: conn=1537 op=3 UNBIND this behavior wasn't really all that surprising to me, as i don't really know in what capacity there might be a database without a suffix defined, even if it were just "", but what i am curious about is the schema definition for the olcHdbConfig object class. the best i can tell, only olcDatabase and olcDbDirectory are MUST attributes, while olcSuffix is not: >ldapsearch -xH 'ldap://dsa.example.com/' -s base -b 'cn=subschema' '*' '+' | grep -iFA 5 "NAME 'olcHdbConfig'" objectClasses: ( 1.3.6.1.4.1.4203.1.12.2.4.2.1.2 NAME 'olcHdbConfig' DESC 'HDB backend configuration' SUP olcDatabaseConfig STRUCTURAL MUST olcDbDirectory MAY ( olcDbCacheSize $ olcDbCheckpoint $ olcDbConfig $ olcDbCryptFile $ olcDb CryptKey $ olcDbNoSync $ olcDbDirtyRead $ olcDbIDLcacheSize $ olcDbIndex $ ol cDbLinearIndex $ olcDbLockDetect $ olcDbMode $ olcDbSearchStack $ olcDbShmKey $ olcDbCacheFree $ olcDbDNcacheSize $ olcDbPageSize ) ) >ldapsearch -xH 'ldap://dsa.example.com/' -s base -b 'cn=subschema' '*' '+' | grep -iFA 7 "NAME 'olcDatabaseConfig'" objectClasses: ( 1.3.6.1.4.1.4203.1.12.2.4.0.4 NAME 'olcDatabaseConfig' DESC ' OpenLDAP Database-specific options' SUP olcConfig STRUCTURAL MUST olcDatabase MAY ( olcHidden $ olcSuffix $ olcSubordinate $ olcAccess $ olcAddContentAcl $ olcLastMod $ olcLimits $ olcMaxDerefDepth $ olcPlugin $ olcReadOnly $ olcRe plica $ olcReplicaArgsFile $ olcReplicaPidFile $ olcReplicationInterval $ olc ReplogFile $ olcRequires $ olcRestrict $ olcRootDN $ olcRootPW $ olcSchemaDN $ olcSecurity $ olcSizeLimit $ olcSyncUseSubentry $ olcSyncrepl $ olcTimeLimi t $ olcUpdateDN $ olcUpdateRef $ olcMirrorMode $ olcMonitoring ) ) why is olcSuffix not a MUST attribute if the database can't be added without it? are there cases different than my exercise where a database might be added without the need for a suffix? it's not anything that's causing an insurmountable hurdle, just mostly curious if this was intended. -ben

13 years, 3 months

openldap-technical search results for query "starttls"