openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Re: Borked olcDatabase={1}hdb.ldif
by Jan Geep 13 Oct '11

13 Oct '11

On Thu, Oct 13, 2011 at 10:57 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > I would suggest you go and read the LDIF specification, so you can realize > this is not a bug nor a problem. Mea culpa, a rather naive question I guess, still cutting my teeth with openldap. I was aware of the line spanning, but it was I perceived as an errant space in "anonymou s" that threw me. Looks like the ldapmodify will do after all...

1 0

Borked olcDatabase={1}hdb.ldif
by Jan Geep 13 Oct '11

13 Oct '11

Somewhere along the way I've discovered that somehow my olcDatabase={1}hdb.ldif is missing "olcAccess:" for samba* entries. To fix this I wanted to update using ldapmodify and the following ldif: ----- modify.ldif ------------ dn: olcDatabase={1}hdb,cn=config changetype: modify delete: olcAccess olcAccess: {0} - add: olcAccess olcAccess: {0} to attrs=userPassword,shadowLastChange,sambaPwdMustChange,sambaLMPassword,sambaPwdLastSet,sambaNTPassword by dn="cn=admin,dc=domain,dc=tld" write by anonymous auth by self write by * none - ----- modify.ldif ------------ The "olcAccess: {0}...." contents all being on one line. (adding via: ldapmodify -x -D "cn=admin,dc=domain,dc=tld" -W -f modify.ldif) But manually looking at my current olcDatabase={1}hdb.ldif I see that somehow the current "olcAccess: {0}" entry that I want to update has been split into two lines, as follows: ----- oldAccess: {0} ------------ olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=frontline" write by * none ----- oldAccess: {0} ------------ As this is a live system at the moment, is there any way, other than stopping slapd and manually viming olcDatabase={1}hdb.ldif to fix the split line and add the samba* entries? For what it's worth: OS: Ubuntu 11.04 OpenLDAP 2.4.23 Samba: 3.5.8 t.i.a Jan

2 1

authentication failure: bad digest-uri: doesn't match service
by Juergen.Sprenger＠swisscom.com 12 Oct '11

12 Oct '11

Hi, I am trying to authenticate an Oracle db user against OpenLDAP. Porting of schema information is ok, ssl-handshake ok, sasl-bind seems ok, SASL works: ldapwhoami -U testuser -R us.oracle.com -H ldap:/// -Y DIGEST-MD5 SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: testuser SASL SSF: 128 SASL data security layer installed. dn:cn=testuser,cn=users,dc=its Trying to authenticate the oracle-client throws a 'bad digest-uri'-error assuming digest-uri="ldap:/us.oracle.com": ber_dump: buf=60b898 ptr=60b8c7 end=60b9e3 len=284 0000: 00 82 01 18 04 0a 44 49 47 45 53 54 2d 4d 44 35 ......DIGEST-MD5 0010: 04 82 01 08 64 69 67 65 73 74 2d 75 72 69 3d 22 ....digest-uri=" 0020: 6c 64 61 70 3a 2f 75 73 2e 6f 72 61 63 6c 65 2e ldap:/us.oracle. 0030: 63 6f 6d 22 2c 6d 61 78 62 75 66 3d 36 35 35 33 com",maxbuf=6553 0040: 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 38 2c 6,charset=utf-8, 0050: 71 6f 70 3d 61 75 74 68 2c 75 73 65 72 6e 61 6d qop=auth,usernam 0060: 65 3d 22 63 6e 3d 6c 64 61 70 74 65 73 74 2c 63 e="cn=ldaptest,c 0070: 6e 3d 6f 72 61 63 6c 65 63 6f 6e 74 65 78 74 2c n=oraclecontext, 0080: 64 63 3d 69 74 73 22 2c 6e 6f 6e 63 65 3d 22 30 dc=its",nonce="0 0090: 2f 41 41 52 37 47 39 48 39 2f 44 72 34 56 36 32 /AAR7G9H9/Dr4V62 00a0: 6f 50 54 6c 45 48 75 36 56 72 6b 41 46 6f 33 52 oPTlEHu6VrkAFo3R 00b0: 66 31 56 30 6b 73 35 47 71 6f 3d 22 2c 63 6e 6f f1V0ks5Gqo=",cno 00c0: 6e 63 65 3d 22 38 35 33 32 33 35 45 30 44 39 38 nce="853235E0D98 00d0: 41 32 37 39 43 43 30 36 30 34 45 45 39 31 36 31 A279CC0604EE9161 00e0: 34 42 39 30 38 22 2c 6e 63 3d 30 30 30 30 30 30 4B908",nc=000000 00f0: 30 31 2c 72 65 73 70 6f 6e 73 65 3d 37 33 61 64 01,response=73ad 0100: 37 38 31 33 64 31 39 38 34 37 38 63 34 39 37 65 7813d198478c497e 0110: 64 66 30 63 31 36 61 36 61 32 34 36 df0c16a6a246 ber_scanf fmt (m) ber: ber_dump: buf=60b898 ptr=60b8d7 end=60b9e3 len=268 0000: 00 82 01 08 64 69 67 65 73 74 2d 75 72 69 3d 22 ....digest-uri=" 0010: 6c 64 61 70 3a 2f 75 73 2e 6f 72 61 63 6c 65 2e ldap:/us.oracle. 0020: 63 6f 6d 22 2c 6d 61 78 62 75 66 3d 36 35 35 33 com",maxbuf=6553 0030: 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 38 2c 6,charset=utf-8, 0040: 71 6f 70 3d 61 75 74 68 2c 75 73 65 72 6e 61 6d qop=auth,usernam 0050: 65 3d 22 63 6e 3d 6c 64 61 70 74 65 73 74 2c 63 e="cn=ldaptest,c 0060: 6e 3d 6f 72 61 63 6c 65 63 6f 6e 74 65 78 74 2c n=oraclecontext, 0070: 64 63 3d 69 74 73 22 2c 6e 6f 6e 63 65 3d 22 30 dc=its",nonce="0 0080: 2f 41 41 52 37 47 39 48 39 2f 44 72 34 56 36 32 /AAR7G9H9/Dr4V62 0090: 6f 50 54 6c 45 48 75 36 56 72 6b 41 46 6f 33 52 oPTlEHu6VrkAFo3R 00a0: 66 31 56 30 6b 73 35 47 71 6f 3d 22 2c 63 6e 6f f1V0ks5Gqo=",cno 00b0: 6e 63 65 3d 22 38 35 33 32 33 35 45 30 44 39 38 nce="853235E0D98 00c0: 41 32 37 39 43 43 30 36 30 34 45 45 39 31 36 31 A279CC0604EE9161 00d0: 34 42 39 30 38 22 2c 6e 63 3d 30 30 30 30 30 30 4B908",nc=000000 00e0: 30 31 2c 72 65 73 70 6f 6e 73 65 3d 37 33 61 64 01,response=73ad 00f0: 37 38 31 33 64 31 39 38 34 37 38 63 34 39 37 65 7813d198478c497e 0100: 64 66 30 63 31 36 61 36 61 32 34 36 df0c16a6a246 ber_scanf fmt (}}) ber: ber_dump: buf=60b898 ptr=60b9e3 end=60b9e3 len=0 >>> dnPrettyNormal: <cn=ldaptest,cn=oraclecontext,dc=its> => ldap_bv2dn(cn=ldaptest,cn=oraclecontext,dc=its,0) <= ldap_bv2dn(cn=ldaptest,cn=oraclecontext,dc=its)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=ldaptest,cn=oraclecontext,dc=its)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=ldaptest,cn=oraclecontext,dc=its)=0 <<< dnPrettyNormal: <cn=ldaptest,cn=oraclecontext,dc=its>, <cn=ldaptest,cn=oraclecontext,dc=its> conn=1014 op=1 BIND dn="cn=ldaptest,cn=oraclecontext,dc=its" method=163 do_bind: dn (cn=ldaptest,cn=oraclecontext,dc=its) SASL mech DIGEST-MD5 ==> sasl_bind: dn="cn=ldaptest,cn=oraclecontext,dc=its" mech=<continuing> datalen=264 SASL [conn=1014] Debug: DIGEST-MD5 server step 2 SASL [conn=1014] Failure: bad digest-uri: doesn't match service send_ldap_result: conn=1014 op=1 p=3 send_ldap_result: err=49 matched="" text="SASL(-13): authentication failure: bad digest-uri: doesn't match service" send_ldap_response: msgid=2 tag=97 err=49 ber_flush2: 86 bytes to sd 16 0000: 30 54 02 01 02 61 4f 0a 01 31 04 00 04 48 53 41 0T...aO..1...HSA 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure: 0030: 20 62 61 64 20 64 69 67 65 73 74 2d 75 72 69 3a bad digest-uri: 0040: 20 64 6f 65 73 6e 27 74 20 6d 61 74 63 68 20 73 doesn't match s 0050: 65 72 76 69 63 65 ervice tls_write: want=146, written=146 0000: 17 03 00 00 18 c7 75 ac 06 20 dd 58 b7 38 55 82 ......u.. .X.8U. 0010: ab f0 ea 72 79 d0 22 ad 95 dc ab 26 d3 17 03 00 ...ry."....&.... 0020: 00 70 64 23 8e ce fc 05 73 d5 16 a2 cc 62 e4 ae .pd#....s....b.. 0030: ee 02 96 ff 16 3d 42 15 54 25 54 7b 60 6d 25 ef .....=B.T%T{`m%. 0040: e3 82 84 1f 42 ec 38 96 82 78 8c 09 b4 be 96 e5 ....B.8..x...... 0050: b9 95 01 e0 58 f3 a4 49 a0 58 53 6d 24 8e 0a 9b ....X..I.XSm$... 0060: 8b cd 4b fd cd 0e cd 51 0b e0 89 73 c6 b6 88 2f ..K....Q...s.../ 0070: 66 05 49 4a 89 0e 29 0e 53 5a 0c 0d ce 1d 8e 40 f.IJ..).SZ.....@ 0080: 90 dd 9f b2 4d b4 6e 7d 2b cf a1 ed 13 96 df 1a ....M.n}+....... 0090: 44 1c D. ldap_write: want=86, written=86 0000: 30 54 02 01 02 61 4f 0a 01 31 04 00 04 48 53 41 0T...aO..1...HSA 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure: 0030: 20 62 61 64 20 64 69 67 65 73 74 2d 75 72 69 3a bad digest-uri: 0040: 20 64 6f 65 73 6e 27 74 20 6d 61 74 63 68 20 73 doesn't match s 0050: 65 72 76 69 63 65 ervice conn=1014 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication failure: bad digest-uri: doesn't match service <== slap_sasl_bind: rc=49 daemon: activity on 1 descriptor daemon: activity on: 16r daemon: read activity on 16 daemon: select: listen=7 active_threads=0 tvp=NULL connection_get(16) daemon: select: listen=8 active_threads=0 tvp=NULL connection_get(16): got connid=1014 daemon: select: listen=9 active_threads=0 tvp=NULL connection_read(16): checking for input on id=1014 ber_get_next daemon: select: listen=10 active_threads=0 tvp=NULL tls_read: want=5, got=5 0000: 17 03 00 00 20 .... tls_read: want=32, got=32 0000: 93 5b 37 05 07 4b dd 2b a9 1c 7e 70 db b4 8f c7 .[7..K.+..~p.... 0010: a5 f7 d7 d0 b8 e0 17 cf b9 08 dd a2 c9 df 28 7b ..............({ ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=5f7de0 ptr=5f7de0 end=5f7de5 len=5 0000: 02 01 03 42 00 ...B. op tag 0x42, time 1317892029 ber_get_next tls_read: want=5, got=5 0000: 15 03 00 00 18 ..... tls_read: want=24, got=24 0000: d7 de f4 58 8a 4e fc 6b d5 6f 93 55 ee 5e 72 cd ...X.N.k.o.U.^r. 0010: 3c 8b a2 e1 ba 87 94 5a <......Z TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 16 failed errno=0 (Error 0) connection_read(16): input error=-2 id=1014, closing. connection_closing: readying conn=1014 sd=16 for close connection_close: deferring conn=1014 sd=16 daemon: activity on 1 descriptor conn=1014 op=2 do_unbind daemon: waked conn=1014 op=2 UNBIND daemon: select: listen=7 active_threads=0 tvp=NULL daemon: select: listen=8 active_threads=0 tvp=NULL connection_resched: attempting closing conn=1014 sd=16 connection_close: conn=1014 sd=16 daemon: select: listen=9 active_threads=0 tvp=NULL daemon: select: listen=10 active_threads=0 tvp=NULL daemon: removing 16 tls_write: want=29, written=29 0000: 15 03 00 00 18 1c 8a dd b1 bb 30 32 1b ca c2 a1 ..........02.... 0010: 2d e8 33 fc 9e 7b 6b e4 49 cf ce f2 fb -.3..{k.I.... TLS trace: SSL3 alert write:warning:close notify conn=1014 fd=16 closed On the Oracle client: SQL> connect testuser Enter password: ERROR: ORA-28043: invalid bind credentials for DB-OID connection Warning: You are no longer connected to ORACLE. SQL> Any suggestions how to make digest-uri match service? Regards Juergen

3 4

syncrepl tls_cert file not red ?
by Olivier 12 Oct '11

12 Oct '11

I now have a new issue with TLS : certificate files are even not red and presented to the server anymore. I have this on server ldap2 : syncrepl rid=211 provider=ldap://ldap1.example.fr:389 searchbase="dc=example,dc=fr" schemachecking=on type=refreshOnly interval=00:00:00:05 retry="10 +" bindmethod=sasl saslmech=external authcid="cn=replicator,ou=system,dc=example,dc=fr" authzid="dn:cn=replicator,ou=system,dc=example,dc=fr" tls_cacert=/etc/openldap/cacerts/CA.crt tls_cert=/etc/openldap/cacerts/syncrepl.crt tls_key=/etc/openldap/cacerts/syncrepl.key tls_reqcert=demand I get this as error : "ldap_sasl_interactive_bind_s failed (-6)" and if I launch slapd through strace I see that /etc/openldap/cacerts/syncrepl.crt is never opened (then never presented to the server). Note that on the server I have configured : TLSVerifyClient demand To be sure that the server ask for the certificate. What have I forgotten ? Please help me to diag where is the problem. --- Olivier P.S : I can't be absolutely affirmative since I'm under testing, but I think that worked before, and I start to beleive that update from openldap-servers-2.4.23-15.el6_1.1.x86_64 to openldap-servers-2.4.23-15.el6_1.3.x86_64 on redhat 6 produces problems.

3 4

Re: TLS very strange behaviour
by Rich Megginson 12 Oct '11

12 Oct '11

On 10/11/2011 02:38 AM, Olivier Guillard wrote: > Thanks Rich, see below : > >> -12272 is SSL_ERROR_BAD_MAC_ALERT and -12273 is SSL_ERROR_BAD_MAC_READ >> I've seen this when the client and server do not have the same SSL >> certificate signature algorithm support. Is everything running on RHEL6 >> and/or Fedora 14 and later? > [root@ldap2 ~]# cat /etc/issue > Red Hat Enterprise Linux Server release 6.1 (Santiago) > Kernel \r on an \m > > [root@ldap2 ~]# rpm -qa | grep -i openldap > openldap-2.4.23-15.el6_1.3.x86_64 > openldap-servers-2.4.23-15.el6_1.3.x86_64 > openldap-debuginfo-2.4.23-15.el6_1.1.x86_64 > openldap-clients-2.4.23-15.el6_1.3.x86_64 > > [root@ldap1 ~]# cat /etc/issue > Red Hat Enterprise Linux Server release 6.1 (Santiago) > Kernel \r on an \m > > [root@ldap1 ~]# rpm -qa | grep -i openldap > openldap-debuginfo-2.4.23-15.el6_1.1.x86_64 > openldap-clients-2.4.23-15.el6_1.3.x86_64 > openldap-2.4.23-15.el6_1.3.x86_64 > openldap-servers-2.4.23-15.el6_1.3.x86_64 > > [root@ldap2 cacerts]# rpm -qa | grep openssl > openssl-1.0.0-10.el6_1.4.x86_64 > > [root@ldap1 ldap1]# rpm -qa | grep openssl > openssl-1.0.0-10.el6_1.4.x86_64 > > Not sure if that made a difference but I "yum-updated" > on last friday and openldap servers version passed : > > from > openldap-servers-2.4.23-15.el6_1.1.x86_64 > to > openldap-servers-2.4.23-15.el6_1.3.x86_64 Was it working before you yum updated? > --- > Olivier > > On Mon, Oct 10, 2011 at 9:54 PM, Rich Megginson > <rich.megginson(a)gmail.com> wrote: > >>> here is what I get : >>> >>> ldap1 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync >>> ... >>> TLS: error: accept - force handshake failure: errno 11 - moznss error >>> -12273 >>> TLS: can't accept: TLS error -12273:Unknown code ___P 15. >>> TLS: error: connect - force handshake failure: errno 0 - moznss error >>> -12272 >>> TLS: can't connect: TLS error -12272:Unknown code ___P 16. >>> slap_client_connect: URI=ldap://ldap2.example.fr Warning, >>> ldap_start_tls failed (-11) >>> slap_client_connect: URI=ldap://ldap2.example.fr >>> ldap_sasl_interactive_bind_s failed (-6) >>> do_syncrepl: rid=121 rc -6 retrying >>> >>> ldap2 # /usr/sbin/slapd -f slapd.conf -h ldap:/// -u ldap -d Sync >>> ... >>> TLS: error: connect - force handshake failure: errno 0 - moznss error >>> -12272 >>> TLS: can't connect: TLS error -12272:Unknown code ___P 16. >>> slap_client_connect: URI=ldap://ldap1.eaxample.fr:389 Warning, >>> ldap_start_tls failed (-11) >>> slap_client_connect: URI=ldap://ldap1.example.fr:389 >>> ldap_sasl_interactive_bind_s failed (-6) >>> do_syncrepl: rid=211 rc -6 retrying >>> TLS: error: accept - force handshake failure: errno 11 - moznss error >>> -12273 >>> TLS: can't accept: TLS error -12273:Unknown code ___P 15. >>> >>> Any idea ? >>

1 0

adding module with cn=config and bdd
by Hubert Chomette 12 Oct '11

12 Oct '11

Hi folks, I'm newbie on openldap and try to add memberof overlay to my openldap configuration. I use cn=config and have a bdb database. All documentations I fund uses hdb database. I add memberof.la to module {0}. I fund that I should add too this entry: " cn=config/olcDatabase={1}hdb/olcOverlay\=\{0\}member of " What will be the equivalent using bdb frontend? Thank's for your Help,

1 0

syncrepl failing with TLS negotiation failure
by Iain Georgeson 12 Oct '11

12 Oct '11

Hello, I'm trying to get syncrepl working, using simple bind over TLS. TLS is failing with Consumer: Oct 12 17:21:53 auth-01 slapd[23241]: slap_client_connect: URI=ldap://auth-00.vis.kaust.edu.sa Error, ldap_start_tls failed (-11) Oct 12 17:21:53 auth-01 slapd[23241]: do_syncrepl: rid=000 rc -11 retrying (3 retries left) Provider: Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 fd=137 ACCEPT from IP=109.171.138.17:39458 (IP=0.0.0.0:389) Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 op=0 STARTTLS Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 op=0 RESULT oid= err=0 text= Oct 12 17:21:53 auth-00 slapd[7190]: conn=451 fd=137 closed (TLS negotiation failure) TLS is working for other uses of the server including ldapsearch: auth-01$ ldapsearch -ZZ -x -D cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa -W -H ldap://auth-00.vis.kaust.edu.sa uid=iain Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 fd=137 ACCEPT from IP=109.171.138.17:39460 (IP=0.0.0.0:389) Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 op=0 STARTTLS Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 op=0 RESULT oid= err=0 text= Oct 12 17:23:58 auth-00 slapd[7190]: conn=466 fd=137 TLS established tls_ssf=256 ssf=256 Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 BIND dn="cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa" method=128 Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 BIND dn="cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa" mech=SIMPLE ssf=0 Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=1 RESULT tag=97 err=0 text= Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 SRCH base="dc=vis,dc=kaust,dc=edu,dc=sa" scope=2 deref=0 filter="(uid=iain)" Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 ENTRY dn="uid=iain,ou=people,dc=vis,dc=kaust,dc=edu,dc=sa" Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 op=3 UNBIND Oct 12 17:24:15 auth-00 slapd[7190]: conn=466 fd=137 closed and any number of clients are cheerfully using it through {pam,nss}_ldap and sssd. I'm not sure where to attack this from. The TLS settings should be identical. Any thoughts on how to proceed would be appreciated. consumer: $ lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: Scientific Description: Scientific Linux release 6.1 (Carbon) Release: 6.1 Codename: Carbon $ rpm -q openldap-servers openldap-servers-2.4.23-15.el6.x86_64 >From slapd.conf: syncrepl rid=000 provider=ldap://auth-00.vis.kaust.edu.sa searchbase=dc=vis,dc=kaust,dc=edu,dc=sa bindmethod=simple binddn=cn=syncrepl,dc=vis,dc=kaust,dc=edu,dc=sa credentials=mysecret type=refreshOnly retry="10 3 120 5 600 +" tls_cacert=/etc/ssl/VisLabCA.pem tls_reqcert=allow starttls=critical provider: $ lsb_release -a LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch Distributor ID: CentOS Description: CentOS release 5.6 (Final) Release: 5.6 Codename: Final $ rpm -q openldap-servers openldap-servers-2.3.43-12.el5_5.3 Iain. -- Systems Engineer KAUST Visualisation Laboratory

1 0

Removing cn=config elements (Not at runtime)
by Jeffrey Crawford 12 Oct '11

12 Oct '11

I have seen in the list archives that using ldapmodify to remove cn=config elements while openldap is running is not supported. However I do need to be able to disable overlays in certain cases sometimes (Even if it's for testing). I tried shutting down the server and then modifying the cn=config directory area, by renaming the .ldif file to ldif.disable. That seems to work but I'm wondering if there are other caveats I should be considering when performing actions like that. One thing I did notice is that it seems like the openldap server goes ahead and re-numbers the overlays so there are no gaps. however the cn=config filesystem area did NOT renumber the files and the server behaved strangely when I tried to ldapmodify the "disabled" config back into the running system. (I got a err=32 no such object using openldap 2.4.26) Stopping the server again and then renaming the extension .disable to .ldif brought everything back to where it was. As a side note the ldif I used to create the overlay is the same I tried to use in this last step. If I disable using the above method and then renumber the files myself before restarting the server I'm able to add the the config back in using ldapmodify but it prompts the question what else should I be considering. Thanks Jeffrey

2 1

howto distribute logs in multiple files
by Olivier 12 Oct '11

12 Oct '11

Hi, is there a way to distribute various openldap loglevels in different files ? Let say, I want ACL Stats and Sync so I add: olcLogLevel: sync stats ACL Is there any way to distribute logs into files : /var/log/ldap/ldap-sync /var/log/ldap/ldap-stats /var/log/ldap/ldap-ACL Thanks, --- Olivier

3 5

Partial and Fractional Replication Details
by Jeffrey Crawford 11 Oct '11

11 Oct '11

I've been playing around with replication trying to prepare a deployment into our enterprise so I've been trying to put syncrepl through it's paces. As such I've been discovering some behaviors that may be intended but have me scratching my head a little. Since Openldap is using replication accounts and we have some pretty specific security models it's desirable to have partial and fractional replication restrictions placed on the replication account itself and the syncrepl filter simply use the default 'objectClass=*'. The "scratching my head" part shows up if I want to try to modify the permissions of the replication account to see more or less of the supplier database. There doesn't seem to be a way to get the replica to just ignore session/accesslogs and perform a comparative sync to match it's data to the view it has of the source. Process intensive I know but would only need to be done when we make those kinds of changes I then assumed since syncrepl is on the "client" side of things, it might try to re-sync if the syncrepl filter was updated. However that also didn't bring the replication accounts view of thing in sync with it's local database. even starting slapd with -c "rid=##,csn=0" didn't work. Furthermore when I took permissions away from the replication account so it could no longer see record(s), if that record was still present from it's earlier sync it would receive changes (presumibly from the accesslog delta-syncrepl access) and apply them to the replica. That means that there is no way to really restrict a replication accounts access to sensitive data if it needs read access to cn=accesslog. Does the synclog act in a simmilar manner? (I didn't seem like it but I didn't get all the details yet about how that works). If the sessionlog and accesslog are not configured then everything falls back to present and delete states which can be a lot of traffic if we have a batch job run that only changes a few attributes. however it looks like that may be the safest way to proceed. Any other ideas about what to try or to clarify my understanding of this system would be appreciated. Sorry to be so long winded but I want to make sure that I'm considering all the variables in this project since we may be stuck with it for a while ;) Thanks Jeffrey

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical