Hi all,
I am wondering if I am going about my setup the right way and am hoping someone can give me a bit of input.
Using openldap-2.4.23 on Debian Linux, I have nssov configured to retrieve host, user and group information on my primary server, with back-ldap and nssov configured on a secondary machine doing the same.
The back-ldap configuration is as follows:
database ldap suffix dc=zivios,dc=net uri "ldap://dev03.zivios.net" acl-bind bindmethod=simple binddn="" credentials=""
idassert-bind bindmethod=simple mode=self binddn="uid=zproxyauth,ou=zusers,ou=core control,ou=zivios,dc=zivios,dc=net" credentials="foo" idassert-authzFrom "dn.regex:.*"
overlay nssov nssov-map group uniqueMember member nssov-ssd passwd ldap:///dc=zivios,dc=net??sub nssov-ssd group ldap:///dc=zivios,dc=net??sub nssov-ssd hosts ldap:///dc=zivios,dc=net??sub nssov-pam hostservice nssov-pam-session sshd nssov-pam-session login
On the primary server, I have the authz policy set to "to", with an authzto rule as follows for the zproxyauth user:
{0}ldap:///dc=zivios,dc=net??sub?(objectClass=posixAccount)
I have setup appropriate ACLs that allow access to the authorizedService attribute for certain groups and, testing ssh & logins is working as required (on the primary server). However, when connections come in from the back-ldap server, the proxy auth works initially, with every "other" request failing. The back-ldap server log reports:
send_ldap_result: err=123 matched="" text="anonymous proxied authorization not allowed"
This is quite easily reproducible via simple getent passwd/group calls. Every second request fails with the aforementioned error. SSH access to the secondary server (with a successful regex, id-assertion and compare operation) works if I restart the back-ldap server, however, all subsequent requests fail.
Below is the complete log of a failed request from the back-ldap server on a getent passwd command:
dev02:/opt/zivios/openldap/etc/openldap# getent passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh sshd:x:101:65534::/var/run/sshd:/usr/sbin/nologin zopenldap:x:945:945::/home/zopenldap:/bin/false daemon: activity on 1 descriptor daemon: activity on: 10r daemon: read active on 10 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL connection_get(10) connection_get(10): got connid=0 nssov: connection from uid=0 gid=0 daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: epoll: listen=9 active_threads=0 tvp=NULL nssov_passwd_all() str2filter "(objectClass=posixAccount)" put_filter: "(objectClass=posixAccount)" put_filter: simple put_simple_filter: "objectClass=posixAccount" begin get_filter EQUALITY ber_scanf fmt ({mm}) ber: ber_dump: buf=0xf6e8f010 ptr=0xf6e8f010 end=0xf6e8f02d len=29 0000: a3 1b 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 04 ....objectClass. 0010: 0c 70 6f 73 69 78 41 63 63 6f 75 6e 74 .posixAccount end get_filter 0 =>ldap_back_getconn: conn 0x9398940 fetched refcnt=1. ldap_search_ext put_filter: "(objectClass=posixAccount)" put_filter: simple put_simple_filter: "objectClass=posixAccount" ldap_build_search_req ATTRS: uid userPassword uidNumber gidNumber gecos cn homeDirectory loginShell objectClass ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x9397070 ptr=0x9397070 end=0x939716f len=255 0000: 30 81 fc 02 01 13 63 81 9c 04 10 64 63 3d 7a 69 0.....c....dc=zi 0010: 76 69 6f 73 2c 64 63 3d 6e 65 74 0a 01 02 0a 01 vios,dc=net..... 0020: 00 02 01 00 02 01 00 01 01 00 a3 1b 04 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 04 0c 70 6f 73 69 78 jectClass..posix 0040: 41 63 63 6f 75 6e 74 30 5c 04 03 75 69 64 04 0c Account0..uid.. 0050: 75 73 65 72 50 61 73 73 77 6f 72 64 04 09 75 69 userPassword..ui 0060: 64 4e 75 6d 62 65 72 04 09 67 69 64 4e 75 6d 62 dNumber..gidNumb 0070: 65 72 04 05 67 65 63 6f 73 04 02 63 6e 04 0d 68 er..gecos..cn..h 0080: 6f 6d 65 44 69 72 65 63 74 6f 72 79 04 0a 6c 6f omeDirectory..lo 0090: 67 69 6e 53 68 65 6c 6c 04 0b 6f 62 6a 65 63 74 ginShell..object 00a0: 43 6c 61 73 73 a0 58 30 56 04 18 32 2e 31 36 2e Class.X0V..2.16. 00b0: 38 34 30 2e 31 2e 31 31 33 37 33 30 2e 33 2e 34 840.1.113730.3.4 00c0: 2e 31 38 04 3a 64 6e 3a 67 69 64 4e 75 6d 62 65 .18.:dn:gidNumbe 00d0: 72 3d 30 2b 75 69 64 4e 75 6d 62 65 72 3d 30 2c r=0+uidNumber=0, 00e0: 63 6e 3d 70 65 65 72 63 72 65 64 2c 63 6e 3d 65 cn=peercred,cn=e 00f0: 78 74 65 72 6e 61 6c 2c 63 6e 3d 61 75 74 68 xternal,cn=auth ber_scanf fmt ({) ber: ber_dump: buf=0x9397070 ptr=0x9397076 end=0x939716f len=249 0000: 63 81 9c 04 10 64 63 3d 7a 69 76 69 6f 73 2c 64 c....dc=zivios,d 0010: 63 3d 6e 65 74 0a 01 02 0a 01 00 02 01 00 02 01 c=net........... 0020: 00 01 01 00 a3 1b 04 0b 6f 62 6a 65 63 74 43 6c ........objectCl 0030: 61 73 73 04 0c 70 6f 73 69 78 41 63 63 6f 75 6e ass..posixAccoun 0040: 74 30 5c 04 03 75 69 64 04 0c 75 73 65 72 50 61 t0..uid..userPa 0050: 73 73 77 6f 72 64 04 09 75 69 64 4e 75 6d 62 65 ssword..uidNumbe 0060: 72 04 09 67 69 64 4e 75 6d 62 65 72 04 05 67 65 r..gidNumber..ge 0070: 63 6f 73 04 02 63 6e 04 0d 68 6f 6d 65 44 69 72 cos..cn..homeDir 0080: 65 63 74 6f 72 79 04 0a 6c 6f 67 69 6e 53 68 65 ectory..loginShe 0090: 6c 6c 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 a0 ll..objectClass. 00a0: 58 30 56 04 18 32 2e 31 36 2e 38 34 30 2e 31 2e X0V..2.16.840.1. 00b0: 31 31 33 37 33 30 2e 33 2e 34 2e 31 38 04 3a 64 113730.3.4.18.:d 00c0: 6e 3a 67 69 64 4e 75 6d 62 65 72 3d 30 2b 75 69 n:gidNumber=0+ui 00d0: 64 4e 75 6d 62 65 72 3d 30 2c 63 6e 3d 70 65 65 dNumber=0,cn=pee 00e0: 72 63 72 65 64 2c 63 6e 3d 65 78 74 65 72 6e 61 rcred,cn=externa 00f0: 6c 2c 63 6e 3d 61 75 74 68 l,cn=auth ber_flush2: 255 bytes to sd 13 0000: 30 81 fc 02 01 13 63 81 9c 04 10 64 63 3d 7a 69 0.....c....dc=zi 0010: 76 69 6f 73 2c 64 63 3d 6e 65 74 0a 01 02 0a 01 vios,dc=net..... 0020: 00 02 01 00 02 01 00 01 01 00 a3 1b 04 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 04 0c 70 6f 73 69 78 jectClass..posix 0040: 41 63 63 6f 75 6e 74 30 5c 04 03 75 69 64 04 0c Account0..uid.. 0050: 75 73 65 72 50 61 73 73 77 6f 72 64 04 09 75 69 userPassword..ui 0060: 64 4e 75 6d 62 65 72 04 09 67 69 64 4e 75 6d 62 dNumber..gidNumb 0070: 65 72 04 05 67 65 63 6f 73 04 02 63 6e 04 0d 68 er..gecos..cn..h 0080: 6f 6d 65 44 69 72 65 63 74 6f 72 79 04 0a 6c 6f omeDirectory..lo 0090: 67 69 6e 53 68 65 6c 6c 04 0b 6f 62 6a 65 63 74 ginShell..object 00a0: 43 6c 61 73 73 a0 58 30 56 04 18 32 2e 31 36 2e Class.X0V..2.16. 00b0: 38 34 30 2e 31 2e 31 31 33 37 33 30 2e 33 2e 34 840.1.113730.3.4 00c0: 2e 31 38 04 3a 64 6e 3a 67 69 64 4e 75 6d 62 65 .18.:dn:gidNumbe 00d0: 72 3d 30 2b 75 69 64 4e 75 6d 62 65 72 3d 30 2c r=0+uidNumber=0, 00e0: 63 6e 3d 70 65 65 72 63 72 65 64 2c 63 6e 3d 65 cn=peercred,cn=e 00f0: 78 74 65 72 6e 61 6c 2c 63 6e 3d 61 75 74 68 xternal,cn=auth ldap_write: want=255, written=255 0000: 30 81 fc 02 01 13 63 81 9c 04 10 64 63 3d 7a 69 0.....c....dc=zi 0010: 76 69 6f 73 2c 64 63 3d 6e 65 74 0a 01 02 0a 01 vios,dc=net..... 0020: 00 02 01 00 02 01 00 01 01 00 a3 1b 04 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 04 0c 70 6f 73 69 78 jectClass..posix 0040: 41 63 63 6f 75 6e 74 30 5c 04 03 75 69 64 04 0c Account0..uid.. 0050: 75 73 65 72 50 61 73 73 77 6f 72 64 04 09 75 69 userPassword..ui 0060: 64 4e 75 6d 62 65 72 04 09 67 69 64 4e 75 6d 62 dNumber..gidNumb 0070: 65 72 04 05 67 65 63 6f 73 04 02 63 6e 04 0d 68 er..gecos..cn..h 0080: 6f 6d 65 44 69 72 65 63 74 6f 72 79 04 0a 6c 6f omeDirectory..lo 0090: 67 69 6e 53 68 65 6c 6c 04 0b 6f 62 6a 65 63 74 ginShell..object 00a0: 43 6c 61 73 73 a0 58 30 56 04 18 32 2e 31 36 2e Class.X0V..2.16. 00b0: 38 34 30 2e 31 2e 31 31 33 37 33 30 2e 33 2e 34 840.1.113730.3.4 00c0: 2e 31 38 04 3a 64 6e 3a 67 69 64 4e 75 6d 62 65 .18.:dn:gidNumbe 00d0: 72 3d 30 2b 75 69 64 4e 75 6d 62 65 72 3d 30 2c r=0+uidNumber=0, 00e0: 63 6e 3d 70 65 65 72 63 72 65 64 2c 63 6e 3d 65 cn=peercred,cn=e 00f0: 78 74 65 72 6e 61 6c 2c 63 6e 3d 61 75 74 68 xternal,cn=auth ldap_result ld 0x9398980 msgid 19 wait4msg ld 0x9398980 msgid 19 (timeout 100000 usec) wait4msg continue ld 0x9398980 msgid 19 all 0 ** ld 0x9398980 Connections: * host: dev03.zivios.net port: 389 (default) refcnt: 2 status: Connected last used: Tue Aug 31 20:07:02 2010
** ld 0x9398980 Outstanding Requests: * msgid 19, origid 19, status InProgress outstanding referrals 0, parent count 0 ld 0x9398980 request count 1 (abandoned 0) ** ld 0x9398980 Response Queue: Empty ld 0x9398980 response count 0 ldap_chkResponseList ld 0x9398980 msgid 19 all 0 ldap_chkResponseList returns ld 0x9398980 NULL ldap_int_select read1msg: ld 0x9398980 msgid 19 all 0 ber_get_next ldap_read: want=8, got=8 0000: 30 37 02 01 13 65 32 0a 07...e2. ldap_read: want=49, got=49 0000: 01 7b 04 00 04 2b 61 6e 6f 6e 79 6d 6f 75 73 20 .{...+anonymous 0010: 70 72 6f 78 69 65 64 20 61 75 74 68 6f 72 69 7a proxied authoriz 0020: 61 74 69 6f 6e 20 6e 6f 74 20 61 6c 6c 6f 77 65 ation not allowe 0030: 64 d ber_get_next: tag 0x30 len 55 contents: ber_dump: buf=0x93988f0 ptr=0x93988f0 end=0x9398927 len=55 0000: 02 01 13 65 32 0a 01 7b 04 00 04 2b 61 6e 6f 6e ...e2..{...+anon 0010: 79 6d 6f 75 73 20 70 72 6f 78 69 65 64 20 61 75 ymous proxied au 0020: 74 68 6f 72 69 7a 61 74 69 6f 6e 20 6e 6f 74 20 thorization not 0030: 61 6c 6c 6f 77 65 64 allowed read1msg: ld 0x9398980 msgid 19 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x93988f0 ptr=0x93988f3 end=0x9398927 len=52 0000: 65 32 0a 01 7b 04 00 04 2b 61 6e 6f 6e 79 6d 6f e2..{...+anonymo 0010: 75 73 20 70 72 6f 78 69 65 64 20 61 75 74 68 6f us proxied autho 0020: 72 69 7a 61 74 69 6f 6e 20 6e 6f 74 20 61 6c 6c rization not all 0030: 6f 77 65 64 owed ldap_chase_referrals read1msg: V2 referral chased, mark request completed, id = 19 read1msg: ld 0x9398980 0 new referrals read1msg: mark request completed, ld 0x9398980 msgid 19 request done: ld 0x9398980 msgid 19 res_errno: 123, res_error: <anonymous proxied authorization not allowed>, res_matched: <> ldap_free_request (origid 19, msgid 19) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x93988f0 ptr=0x93988f3 end=0x9398927 len=52 0000: 65 32 0a 01 7b 04 00 04 2b 61 6e 6f 6e 79 6d 6f e2..{...+anonymo 0010: 75 73 20 70 72 6f 78 69 65 64 20 61 75 74 68 6f us proxied autho 0020: 72 69 7a 61 74 69 6f 6e 20 6e 6f 74 20 61 6c 6c rization not all 0030: 6f 77 65 64 owed ber_scanf fmt (}) ber: ber_dump: buf=0x93988f0 ptr=0x9398927 end=0x9398927 len=0
ldap_msgfree send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=123 matched="" text="anonymous proxied authorization not allowed"
---- The primary server log shows only one line:
Aug 31 20:13:53 dev03 slapd[32705]: conn=1604 op=19 do_search: get_ctrls failed ----
I am not sure why an anonymous request is made by back-ldap -- probably my lack of understanding on how it should be configured. If anyone can point out where I am going wrong, it would be greatly appreciated.
Mustafa.
Hi all,
I am wondering if I am going about my setup the right way and am hoping someone can give me a bit of input.
Using openldap-2.4.23 on Debian Linux, I have nssov configured to retrieve host, user and group information on my primary server, with back-ldap and nssov configured on a secondary machine doing the same.
The back-ldap configuration is as follows:
database ldap suffix dc=zivios,dc=net uri "ldap://dev03.zivios.net" acl-bind bindmethod=simple binddn="" credentials=""
idassert-bind bindmethod=simple mode=self binddn="uid=zproxyauth,ou=zusers,ou=core control,ou=zivios,dc=zivios,dc=net" credentials="foo" idassert-authzFrom "dn.regex:.*"
Hi, I can't speak for the nssov, but the back-ldap configuration looks fine to me. I'm very interested in addressing the issue you note. I have recently committed some fixes to address something that might be related, could you try HEAD code? Also, since you find the issue so easily reproducible, could you send detailed logs of the server too? stats,trace,args should be best. If they get pretty big, could you please upload them to ftp://ftp.openldap.org following guidelines here http://www.openldap.org/devel/contributing.html#submitting?
Thanks, p.
On Tue, Aug 31, 2010 at 9:31 PM, masarati@aero.polimi.it wrote:
Hi all,
I am wondering if I am going about my setup the right way and am hoping someone can give me a bit of input.
Using openldap-2.4.23 on Debian Linux, I have nssov configured to retrieve host, user and group information on my primary server, with back-ldap and nssov configured on a secondary machine doing the same.
The back-ldap configuration is as follows:
database ldap suffix dc=zivios,dc=net uri "ldap://dev03.zivios.net" acl-bind bindmethod=simple binddn="" credentials=""
idassert-bind bindmethod=simple mode=self binddn="uid=zproxyauth,ou=zusers,ou=core control,ou=zivios,dc=zivios,dc=net" credentials="foo" idassert-authzFrom "dn.regex:.*"
Hi, I can't speak for the nssov, but the back-ldap configuration looks fine to me. I'm very interested in addressing the issue you note. I have recently committed some fixes to address something that might be related, could you try HEAD code? Also, since you find the issue so easily reproducible, could you send detailed logs of the server too? stats,trace,args should be best. If they get pretty big, could you please upload them to ftp://ftp.openldap.org following guidelines here http://www.openldap.org/devel/contributing.html#submitting?
Will do first thing tomorrow. Many thanks.
Mustafa.
On Wed, Sep 1, 2010 at 12:11 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Tue, Aug 31, 2010 at 9:31 PM, masarati@aero.polimi.it wrote:
Hi all,
I am wondering if I am going about my setup the right way and am hoping someone can give me a bit of input.
Using openldap-2.4.23 on Debian Linux, I have nssov configured to retrieve host, user and group information on my primary server, with back-ldap and nssov configured on a secondary machine doing the same.
The back-ldap configuration is as follows:
database ldap suffix dc=zivios,dc=net uri "ldap://dev03.zivios.net" acl-bind bindmethod=simple binddn="" credentials=""
idassert-bind bindmethod=simple mode=self binddn="uid=zproxyauth,ou=zusers,ou=core control,ou=zivios,dc=zivios,dc=net" credentials="foo" idassert-authzFrom "dn.regex:.*"
Hi, I can't speak for the nssov, but the back-ldap configuration looks fine to me. I'm very interested in addressing the issue you note. I have recently committed some fixes to address something that might be related, could you try HEAD code? Also, since you find the issue so easily reproducible, could you send detailed logs of the server too? stats,trace,args should be best. If they get pretty big, could you please upload them to ftp://ftp.openldap.org following guidelines here http://www.openldap.org/devel/contributing.html#submitting?
Will do first thing tomorrow. Many thanks.
Hi,
I've uploaded the log file named: mustafa-hashmi-20110901-slapd-backldap-log.txt to the incoming folder. Please let me know if you need additional information.
I am going to give the code in HEAD a shot and report back (hopefully within a few hours).
Thanks, Mustafa.
On Wed, Sep 1, 2010 at 11:14 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Wed, Sep 1, 2010 at 12:11 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Tue, Aug 31, 2010 at 9:31 PM, masarati@aero.polimi.it wrote:
I've uploaded the log file named: mustafa-hashmi-20110901-slapd-backldap-log.txt to the incoming folder. Please let me know if you need additional information.
I am going to give the code in HEAD a shot and report back (hopefully within a few hours).
I have everything compiled on a new xen and will be start testing shortly. Just a small note:
when compiling php-5.3.3 against openldap, php configure bails with the following error:
configure:53475: checking for LDAP support configure:53522: checking for LDAP Cyrus SASL support configure:55867: checking for 3 arg ldap_set_rebind_proc ... long link list removed ... /opt/zivios/openldap/lib/libldap.so: undefined reference to `lutil_atoix' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_getline' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_countlines' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_parse_line2' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_debug' collect2: ld returned 1 exit status
The same configure script works fine with openldap-2.4.23. Couldn't find anything relevant except:
http://www.openldap.org/its/index.cgi/Build?id=6517;page=1
I'll start the back-ldap tests shortly.
Thanks, Mustafa.
On Wed, Sep 1, 2010 at 11:14 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Wed, Sep 1, 2010 at 12:11 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Tue, Aug 31, 2010 at 9:31 PM, masarati@aero.polimi.it wrote:
I've uploaded the log file named: mustafa-hashmi-20110901-slapd-backldap-log.txt to the incoming folder. Please let me know if you need additional information.
Thanks for the logs, I'll let you know.
I am going to give the code in HEAD a shot and report back (hopefully within a few hours).
I have everything compiled on a new xen and will be start testing shortly. Just a small note:
when compiling php-5.3.3 against openldap, php configure bails with the following error:
configure:53475: checking for LDAP support configure:53522: checking for LDAP Cyrus SASL support configure:55867: checking for 3 arg ldap_set_rebind_proc ... long link list removed ... /opt/zivios/openldap/lib/libldap.so: undefined reference to `lutil_atoix' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_getline' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_countlines' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_parse_line2' /opt/zivios/openldap/lib/libldap.so: undefined reference to `ldif_debug' collect2: ld returned 1 exit status
The same configure script works fine with openldap-2.4.23. Couldn't find anything relevant except:
http://www.openldap.org/its/index.cgi/Build?id=6517;page=1
I'll start the back-ldap tests shortly.
Those functions belong to libldif (except for lutil_atoix, not sure what it's doing there); not sure what the issue is...
p.
On Wed, Sep 1, 2010 at 7:33 PM, masarati@aero.polimi.it wrote:
On Wed, Sep 1, 2010 at 11:14 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Wed, Sep 1, 2010 at 12:11 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Tue, Aug 31, 2010 at 9:31 PM, masarati@aero.polimi.it wrote:
I've uploaded the log file named: mustafa-hashmi-20110901-slapd-backldap-log.txt to the incoming folder. Please let me know if you need additional information.
Thanks for the logs, I'll let you know.
Great, thank you.
Please note that when using code from HEAD, I cannot replicate the issue and all works perfectly. For testing, I pointed the same secondary system to the new primary (the secondary was still on 2.4.23-release).
Mustafa.
On Wed, Sep 1, 2010 at 7:33 PM, masarati@aero.polimi.it wrote:
On Wed, Sep 1, 2010 at 11:14 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Wed, Sep 1, 2010 at 12:11 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Tue, Aug 31, 2010 at 9:31 PM, masarati@aero.polimi.it wrote:
I've uploaded the log file named: mustafa-hashmi-20110901-slapd-backldap-log.txt to the incoming folder. Please let me know if you need additional information.
Thanks for the logs, I'll let you know.
Great, thank you.
Please note that when using code from HEAD, I cannot replicate the issue and all works perfectly. For testing, I pointed the same secondary system to the new primary (the secondary was still on 2.4.23-release).
The logs you provide do not reveal anything specific; the fixes in HEAD essentially address the issue that a retry under some circumstances could result in reconnect anonymously a connection previously bound as some specific identity. As a consequence, subsequent attempts to use proxied authorization within identity assertion would fail because anonymous can never authorize. Those fixes will likely be released in 2.4.24.
Thanks for testing. p.
On Tue, Sep 7, 2010 at 7:20 AM, masarati@aero.polimi.it wrote:
On Wed, Sep 1, 2010 at 7:33 PM, masarati@aero.polimi.it wrote:
On Wed, Sep 1, 2010 at 11:14 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Wed, Sep 1, 2010 at 12:11 AM, Mustafa A. Hashmi mahashmi@gmail.com wrote:
On Tue, Aug 31, 2010 at 9:31 PM, masarati@aero.polimi.it wrote:
I've uploaded the log file named: mustafa-hashmi-20110901-slapd-backldap-log.txt to the incoming folder. Please let me know if you need additional information.
Thanks for the logs, I'll let you know.
Great, thank you.
Please note that when using code from HEAD, I cannot replicate the issue and all works perfectly. For testing, I pointed the same secondary system to the new primary (the secondary was still on 2.4.23-release).
The logs you provide do not reveal anything specific; the fixes in HEAD essentially address the issue that a retry under some circumstances could result in reconnect anonymously a connection previously bound as some specific identity. As a consequence, subsequent attempts to use proxied authorization within identity assertion would fail because anonymous can never authorize. Those fixes will likely be released in 2.4.24.
Thanks for looking into it.
Testing code in HEAD I couldn't replicate the issue, so looking forward to the next release :)
Mustafa.
openldap-technical@openldap.org