openldap-bugs February 2009

openldap-bugs@openldap.org

47 participants
298 discussions

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > This clearly explains the assertion pcache is reporting. Well-intended > behavior or not, there is a problem here because pcache takes down the > server whenever it encounters attribute values of this form. No longer :) > Given > Kurt's later comments about the provenance and ancestry of this > "standard", it seems to me the right thing for back-meta (and back- > ldap, for that matter) to do might be to just make the attribute > completely disappear. Appropriate messages output in debug mode or at > a particular log level might announce the fact that the attribute is > being disappeared. The pcache overlay, for its part, instead of > asserting, might instead log a warning and refuse to cache the object. > > Sound reasonable? See latest commit. If this fixes your problem, a message like conn=X op=Y meta_send_entry("cn=smtg"): slap_bv2undef_ad("member;range=Z-W"): ... Maybe you're not seeing it because slapd dies before logging? I could recreate the issue by entering slapd with gdb, let it get the attribute name, modify it by putting a "=" in between, and letting things go through. What happened is that slapd does not recognizes the attribute and continues the cycle. The subsequent attribute is not recognized as well because it is actually the first value! This should now be handled correctly. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 07 Feb '09

07 Feb '09

On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> Some additional information: >> Some objects being returned from AD have very large multi-valued >> attributes (for example, member). AD is returning them in the >> ";range" format, but they are not getting past back-meta. For >> example, a direct search for the object in AD will return stuff >> like this: >> member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User >> Accounts,OU=Common,DC=my-company,DC=com >> but doing the same search through slapd/back-meta using the same >> credentials, the member attribute is not displayed at all. There >> are no attribute maps in place that would cause this. > > If this is the cause, then back-meta should try to register the > attribute name as a "proxied" attribute type, and slapd should be > unable to correctly decode it because it contains a "=". Back-meta > in the end should just ignore the whole attribute. > Thanks, Pierangelo. That led me to ITS#5472 and several other postings about the same issue. In particular: > [Petter Reinholdtsen said] >> This notation is not handled by ldap_get_values(), and it return >> NULL, resulting in a group with zero members. > [Kurt Zielenga replied] > This is proper and well-intended behavior. You asked for values of > returned under the attribute description "member", not the (invalid) > attribute description "member;range=0-1499". Two attribute > descriptions which share the same attribute type do not necessarily > refer to the same attribute. This clearly explains the assertion pcache is reporting. Well-intended behavior or not, there is a problem here because pcache takes down the server whenever it encounters attribute values of this form. Given Kurt's later comments about the provenance and ancestry of this "standard", it seems to me the right thing for back-meta (and back- ldap, for that matter) to do might be to just make the attribute completely disappear. Appropriate messages output in debug mode or at a particular log level might announce the fact that the attribute is being disappeared. The pcache overlay, for its part, instead of asserting, might instead log a warning and refuse to cache the object. Sound reasonable? -Matt > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- >

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > Some additional information: > > Some objects being returned from AD have very large multi-valued > attributes (for example, member). AD is returning them in the ";range" > format, but they are not getting past back-meta. For example, a direct > search for the object in AD will return stuff like this: > > member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User > Accounts,OU=Common,DC=my-company,DC=com > > but doing the same search through slapd/back-meta using the same > credentials, the member attribute is not displayed at all. There are > no attribute maps in place that would cause this. Apparently, that was it: back-meta (and back-ldap) was ignoring attribute names that cannot be parsed, but it was not discarding their values. Should be fixed now in HEAD. Please test. BTW, it seems that proxy backends could try to exploit this in order to intercept value ranges returned by AD and consolidate them in a single, LDAP compliant entry. Not something I'm too excited about, though. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5927) assertion error when using pcache
by ando＠sys-net.it 07 Feb '09

07 Feb '09

mhardin(a)symas.com wrote: > Some additional information: > > Some objects being returned from AD have very large multi-valued > attributes (for example, member). AD is returning them in the ";range" > format, but they are not getting past back-meta. For example, a direct > search for the object in AD will return stuff like this: > > member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User > Accounts,OU=Common,DC=my-company,DC=com > > but doing the same search through slapd/back-meta using the same > credentials, the member attribute is not displayed at all. There are > no attribute maps in place that would cause this. If this is the cause, then back-meta should try to register the attribute name as a "proxied" attribute type, and slapd should be unable to correctly decode it because it contains a "=". Back-meta in the end should just ignore the whole attribute. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5929) 'make test' uses installed libldap_r/liblber
by h.b.furuseth＠usit.uio.no 06 Feb '09

06 Feb '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: RedHat Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "make test" uses installed instead of newly built libraries, with ./configure --enable-dynamic LDFLAGS=<installed lib>. It works if either --enable-dynamic or LDFLAGS is omitted. Minimal test: p=/site/ldap/install # ...or wherever OpenLDAP is installed ./configure --quiet --prefix=$p --enable-dynamic \ --disable-databases --disable-overlays --enable-ldap \ CPPFLAGS="-I$p/include" LDFLAGS="-L$p/lib -Wl,-rpath,$p/lib" make -s depend all Edit servers/slapd/slapd (a wrapper script from libtool): Insert echo "" ldd "$progdir/$program" | grep libl >&2 printenv | egrep '^(GCC|[A-Z_0-9]*PATH).*/' >&2 before exec "$progdir/$program" ${1+"$@"} cd tests ./run -b ldif test029-ldapglue Now "./run -b ldif test029-ldapglue" shows libldap_r-2-devel.so.0 => /site/ldap/install/lib/libldap_r-2-devel.so.0 liblber-2-devel.so.0 => /site/ldap/install/lib/liblber-2-devel.so.0 LD_LIBRARY_PATH=/usit/bombur/site/ldap/HEAD-commit/tests/../libraries:/usit/bombur/site/ldap/HEAD-commit/tests/../libraries: slapd#2 crashes unless the installed OpenLDAP is from February, otherwise testrun/slapd.2.log says symbol ldap_pvt_search is missing.

1 0

(ITS#5928) build without SSL fails
by quanah＠OpenLDAP.org 06 Feb '09

06 Feb '09

Full_Name: Quanah Gibson-Mount Version: HEAD/RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If you build OpenLDAP with --without-tls and --without-cyrus-sasl, the build fails: Entering subdirectory libldap make[3]: Entering directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries/libldap' /bin/sh ../../libtool --mode=compile cc -g -O0 -I../../include -I../../include -I/opt/zimbra/bdb-4.7.25.3/include -I/opt/zimbra/libtool-2.2.6a/include -DLDAP_LIBRARY -c tls2.c cc -g -O0 -I../../include -I../../include -I/opt/zimbra/bdb-4.7.25.3/include -I/opt/zimbra/libtool-2.2.6a/include -DLDAP_LIBRARY -c tls2.c -fPIC -DPIC -o .libs/tls2.o tls2.c: In function `ldap_pvt_tls_ctx_free': tls2.c:81: error: `tls_imp' undeclared (first use in this function) tls2.c:81: error: (Each undeclared identifier is reported only once tls2.c:81: error: for each function it appears in.) tls2.c: At top level: tls2.c:85: error: syntax error before '*' token tls2.c: In function `tls_ctx_ref': tls2.c:87: error: `ctx' undeclared (first use in this function) tls2.c:89: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_destroy': tls2.c:102: error: structure has no member named `ldo_tls_ctx' tls2.c:103: error: structure has no member named `ldo_tls_ctx' tls2.c:104: error: structure has no member named `ldo_tls_ctx' tls2.c:107: error: structure has no member named `ldo_tls_certfile' tls2.c:108: error: structure has no member named `ldo_tls_certfile' tls2.c:109: error: structure has no member named `ldo_tls_certfile' tls2.c:111: error: structure has no member named `ldo_tls_keyfile' tls2.c:112: error: structure has no member named `ldo_tls_keyfile' tls2.c:113: error: structure has no member named `ldo_tls_keyfile' tls2.c:115: error: structure has no member named `ldo_tls_dhfile' tls2.c:116: error: structure has no member named `ldo_tls_dhfile' tls2.c:117: error: structure has no member named `ldo_tls_dhfile' tls2.c:119: error: structure has no member named `ldo_tls_cacertfile' tls2.c:120: error: structure has no member named `ldo_tls_cacertfile' tls2.c:121: error: structure has no member named `ldo_tls_cacertfile' tls2.c:123: error: structure has no member named `ldo_tls_cacertdir' tls2.c:124: error: structure has no member named `ldo_tls_cacertdir' tls2.c:125: error: structure has no member named `ldo_tls_cacertdir' tls2.c:127: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:128: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:129: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:131: error: structure has no member named `ldo_tls_crlfile' tls2.c:132: error: structure has no member named `ldo_tls_crlfile' tls2.c:133: error: structure has no member named `ldo_tls_crlfile' tls2.c: In function `ldap_pvt_tls_destroy': tls2.c:148: error: `tls_imp' undeclared (first use in this function) tls2.c: At top level: tls2.c:156: error: syntax error before '*' token tls2.c: In function `tls_init': tls2.c:166: error: `impl' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_init': tls2.c:182: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_init_ctx': tls2.c:192: error: `tls_impl' undeclared (first use in this function) tls2.c:192: error: `ti' undeclared (first use in this function) tls2.c:192: error: `tls_imp' undeclared (first use in this function) tls2.c:193: error: variable `lts' has initializer but incomplete type tls2.c:193: error: structure has no member named `ldo_tls_info' tls2.c:193: error: storage size of 'lts' isn't known tls2.c:195: error: structure has no member named `ldo_tls_ctx' tls2.c:237: error: structure has no member named `ldo_tls_ctx' tls2.c:238: error: structure has no member named `ldo_tls_ctx' tls2.c:249: error: structure has no member named `ldo_tls_ctx' tls2.c:250: error: structure has no member named `ldo_tls_ctx' tls2.c:251: error: structure has no member named `ldo_tls_ctx' tls2.c: At top level: tls2.c:283: error: syntax error before '*' token tls2.c: In function `alloc_handle': tls2.c:286: error: `tls_ctx' undeclared (first use in this function) tls2.c:286: error: `ctx' undeclared (first use in this function) tls2.c:287: error: `tls_session' undeclared (first use in this function) tls2.c:287: error: `ssl' undeclared (first use in this function) tls2.c:294: error: structure has no member named `ldo_tls_ctx' tls2.c:297: error: `tls_imp' undeclared (first use in this function) tls2.c: At top level: tls2.c:306: error: syntax error before "tls_session" tls2.c: In function `update_flags': tls2.c:308: error: `sb' undeclared (first use in this function) tls2.c:311: error: `tls_imp' undeclared (first use in this function) tls2.c:311: error: `ssl' undeclared (first use in this function) tls2.c:311: error: `rc' undeclared (first use in this function) tls2.c: In function `ldap_int_tls_connect': tls2.c:332: error: `tls_session' undeclared (first use in this function) tls2.c:332: error: `ssl' undeclared (first use in this function) tls2.c:338: error: `tls_ctx' undeclared (first use in this function) tls2.c:338: error: `ctx' undeclared (first use in this function) tls2.c:340: error: structure has no member named `ldo_tls_ctx' tls2.c:350: error: `tls_imp' undeclared (first use in this function) tls2.c:355: error: structure has no member named `ldo_tls_ctx' tls2.c:356: error: structure has no member named `ldo_tls_ctx' tls2.c:359: error: structure has no member named `ldo_tls_connect_cb' tls2.c:360: error: structure has no member named `ldo_tls_connect_cb' tls2.c:361: error: structure has no member named `ldo_tls_connect_arg' tls2.c:362: error: structure has no member named `ldo_tls_connect_cb' tls2.c:362: error: structure has no member named `ldo_tls_connect_cb' tls2.c:363: error: structure has no member named `ldo_tls_connect_cb' tls2.c:364: error: structure has no member named `ldo_tls_connect_cb' tls2.c:364: error: structure has no member named `ldo_tls_connect_arg' tls2.c: In function `ldap_pvt_tls_accept': tls2.c:414: error: `tls_session' undeclared (first use in this function) tls2.c:414: error: `ssl' undeclared (first use in this function) tls2.c:426: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_get_peer_dn': tls2.c:483: error: `tls_session' undeclared (first use in this function) tls2.c:483: error: `session' undeclared (first use in this function) tls2.c:487: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_check_hostname': tls2.c:498: error: `tls_session' undeclared (first use in this function) tls2.c:498: error: `session' undeclared (first use in this function) tls2.c:500: error: `tls_imp' undeclared (first use in this function) tls2.c: In function `ldap_pvt_tls_get_option': tls2.c:604: error: structure has no member named `ldo_tls_mode' tls2.c:607: error: structure has no member named `ldo_tls_ctx' tls2.c:608: error: structure has no member named `ldo_tls_ctx' tls2.c:609: error: structure has no member named `ldo_tls_ctx' tls2.c:613: error: structure has no member named `ldo_tls_cacertfile' tls2.c:614: error: structure has no member named `ldo_tls_cacertfile' tls2.c:617: error: structure has no member named `ldo_tls_cacertdir' tls2.c:618: error: structure has no member named `ldo_tls_cacertdir' tls2.c:621: error: structure has no member named `ldo_tls_certfile' tls2.c:622: error: structure has no member named `ldo_tls_certfile' tls2.c:625: error: structure has no member named `ldo_tls_keyfile' tls2.c:626: error: structure has no member named `ldo_tls_keyfile' tls2.c:629: error: structure has no member named `ldo_tls_dhfile' tls2.c:630: error: structure has no member named `ldo_tls_dhfile' tls2.c:633: error: structure has no member named `ldo_tls_crlfile' tls2.c:634: error: structure has no member named `ldo_tls_crlfile' tls2.c:637: error: structure has no member named `ldo_tls_require_cert' tls2.c:640: error: structure has no member named `ldo_tls_crlcheck' tls2.c:643: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:644: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:647: error: structure has no member named `ldo_tls_protocol_min' tls2.c:650: error: structure has no member named `ldo_tls_randfile' tls2.c:651: error: structure has no member named `ldo_tls_randfile' tls2.c:666: error: structure has no member named `ldo_tls_connect_cb' tls2.c:669: error: structure has no member named `ldo_tls_connect_arg' tls2.c: In function `ldap_pvt_tls_set_option': tls2.c:710: error: structure has no member named `ldo_tls_mode' tls2.c:718: error: structure has no member named `ldo_tls_ctx' tls2.c:719: error: structure has no member named `ldo_tls_ctx' tls2.c:720: error: structure has no member named `ldo_tls_ctx' tls2.c:721: error: structure has no member named `ldo_tls_ctx' tls2.c:724: error: structure has no member named `ldo_tls_connect_cb' tls2.c:727: error: structure has no member named `ldo_tls_connect_arg' tls2.c:730: error: structure has no member named `ldo_tls_cacertfile' tls2.c:730: error: structure has no member named `ldo_tls_cacertfile' tls2.c:731: error: structure has no member named `ldo_tls_cacertfile' tls2.c:734: error: structure has no member named `ldo_tls_cacertdir' tls2.c:734: error: structure has no member named `ldo_tls_cacertdir' tls2.c:735: error: structure has no member named `ldo_tls_cacertdir' tls2.c:738: error: structure has no member named `ldo_tls_certfile' tls2.c:738: error: structure has no member named `ldo_tls_certfile' tls2.c:739: error: structure has no member named `ldo_tls_certfile' tls2.c:742: error: structure has no member named `ldo_tls_keyfile' tls2.c:742: error: structure has no member named `ldo_tls_keyfile' tls2.c:743: error: structure has no member named `ldo_tls_keyfile' tls2.c:746: error: structure has no member named `ldo_tls_dhfile' tls2.c:746: error: structure has no member named `ldo_tls_dhfile' tls2.c:747: error: structure has no member named `ldo_tls_dhfile' tls2.c:750: error: structure has no member named `ldo_tls_crlfile' tls2.c:750: error: structure has no member named `ldo_tls_crlfile' tls2.c:751: error: structure has no member named `ldo_tls_crlfile' tls2.c:761: error: structure has no member named `ldo_tls_require_cert' tls2.c:771: error: structure has no member named `ldo_tls_crlcheck' tls2.c:776: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:776: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:777: error: structure has no member named `ldo_tls_ciphersuite' tls2.c:782: error: structure has no member named `ldo_tls_protocol_min' tls2.c:788: error: structure has no member named `ldo_tls_randfile' tls2.c:788: error: structure has no member named `ldo_tls_randfile' tls2.c:789: error: structure has no member named `ldo_tls_randfile' tls2.c:794: error: structure has no member named `ldo_tls_ctx' tls2.c:795: error: structure has no member named `ldo_tls_ctx' tls2.c:796: error: structure has no member named `ldo_tls_ctx' tls2.c: In function `ldap_int_tls_start': tls2.c:822: error: `tls_imp' undeclared (first use in this function) tls2.c:838: error: structure has no member named `ldo_tls_require_cert' tls2.c: In function `ldap_pvt_tls_get_strength': tls2.c:863: error: `tls_session' undeclared (first use in this function) tls2.c:863: error: `session' undeclared (first use in this function) tls2.c:865: error: `tls_imp' undeclared (first use in this function) make[3]: *** [tls2.lo] Error 1 make[3]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries/libldap' make[2]: *** [all-common] Error 1 make[2]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z/libraries' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/build/p4/main/ThirdParty/openldap/openldap-2.4.14.2z' make: *** [build] Error 2

1 0

RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 06 Feb '09

06 Feb '09

michael(a)stroeder.com wrote: > I'd recommend not to mess around with the hostport portion of the LDAP > URL. In opposite to Hallvard I'm not even sure whether a distinction is > really needed when invoking ldap_initialize(). ok ... The rfc 2255 defined the LDAP URL syntaxe as : scheme "://" [hostport] ["/" [dn etc... where host (rfc1738) must be a fully qualified domain name of a network host or IP address. (a fully qualified domain name cannot effectiely begin with a '.' ;-) Therefore, transforming a fully qualified domain name in a IP adress remains to be a DNS job. But, "My.domain.[:port]" is actually a fully qualified domain name and produce effectively one (at least) IP address of a network host when a SRV rr is defined and an authoritative answer can be obtained from a DNS. Of course I admit it could be not very efficient to try systematically a SRV resolution on every domain name of a LDAP URLS chain ... So I propose to add an extension (something like "forceSrvSearch") which will indicate that the library must perform a SRV request on this URL to find the IP address from the hostname (or hostport) parameter specified. It'll be a bit more complex to patch up ... :( -- PE

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 06 Feb '09

06 Feb '09

Some additional information: Some objects being returned from AD have very large multi-valued attributes (for example, member). AD is returning them in the ";range" format, but they are not getting past back-meta. For example, a direct search for the object in AD will return stuff like this: member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User Accounts,OU=Common,DC=my-company,DC=com but doing the same search through slapd/back-meta using the same credentials, the member attribute is not displayed at all. There are no attribute maps in place that would cause this. -Matt

1 0

Re: (ITS#5927) assertion error when using pcache
by mhardin＠symas.com 06 Feb '09

06 Feb '09

On Feb 6, 2009, at 12:29 AM, Pierangelo Masarati wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.13 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> Hi All, >> We have an LDAP server that is proxying for Active Directory. >> Periodically slapd >> throws an assertion: >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: >> octetStringIndexer: >> Assertion `i > 0' failed. >> /etc/init.d/solserver: line 192: 6620 Aborted >> (core dumped) >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS >> Howard Chu's examination of the core file showed that the remote AD >> server >> returned a member attribute with no values. This is only legal in >> LDAP when a >> client sets the attrsonly flag in its search request, and that flag >> was not set >> here. >> The indexer rightly asserts because pcache handed it an attribute >> with nothing >> to index. >> I'm not sure what the correct thing to do might be here, but it >> should not take >> down the slapd. > > The entry should not be cached, IMHO. Fair enough, I think. -Matt > > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- >

1 0

Re: (ITS#5927) assertion error when using pcache
by michael＠stroeder.com 06 Feb '09

06 Feb '09

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> mhardin(a)symas.com wrote: >>> Howard Chu's examination of the core file showed that the remote AD server >>> returned a member attribute with no values. This is only legal in LDAP when a >>> client sets the attrsonly flag in its search request, and that flag was not set >>> here. > [..] > AD is flaky enough already, but it's possible that back-meta may have dropped > the attr values during rewriting, etc. FWIW: I never saw an empty attribute value list returned by AD. I've added code to web2ldap to handle that case since I had this issue with various other LDAP servers but not AD. Ciao, Michael.

1 0

← Newer
1
...
21
22
23
24
25
26
27
...
30
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2009