- openldap-bugs - openldap.org

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 04 Jun '09

04 Jun '09

Howard Chu wrote: > Andrew Bartlett wrote: >> I agree, we might be jumping at different shadows here, but your patches >> did fix something... > > I see what you're describing now, with the kvm set with 2 CPUs. It appears to > be a bug caused by the recent patch for connection_hangup() processing. > Running slapd with -d15 in your test shows that a connection is closed shortly > after being established and becoming readable. The bug is (probably) that we > queued the reader but processed the hangup immediately, thus closing the > connection before the reader executes. I'm not exactly sure why this is > causing the problem on your test, since it looks like your client is closing > the socket before waiting for the reply. But certainly this is the right area. > With the connection problem out of the way, the remaining slapd crash appeared to be due to some type of heap corruption, but the usual suite of tools (valgrind, efence, LBER_MEMORY_DEBUG, etc.) didn't ever reproduce the problem. On the assumption that this was related to a stack overwrite I recompiled libldap_r with a 12MB stack size instead of the default 8MB and that still didn't change the outcome. On the assumption that there was some other race condition involved, I set slapd to only 2 threads (from default of 16) to try and limit the possibilities there. This caused the crash to occur much more quickly, and using libumem it became obvious that refint was accessing already-freed memory. So it turns out that the patch for rev 1.41 (ITS#5428) to make this into a global overlay was incorrect; it moved the loop that processed its work queue into a new function so that it could be called multiple times, but it was still using that code basically as-is, which freed its queue as it operated. (Because originally the queue was only walked once.) Part of the reason the bug was so hard to reproduce is because it tended to only show up when the queue got fairly long, and that only happened if slapd was too busy. (Thus, forcing only 2 threads made it occur sooner.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 04 Jun '09

04 Jun '09

On Jun 4, 2009, at 9:15 AM, masarati(a)aero.polimi.it wrote: > Just in case, before it becomes totally incompatible with HEAD code, I > have a patch I never committed, it's about making pcache admin- > friendly if > it makes any sense. > > It adds: > > - a (persistent) counter that reports, for each query, how many > times it > evaluated to answerable That's very useful. Any thoughts about how to determine pcache's overall 'hit rate'? > > > - "proxycache-" prefixed statements are passed to the private > database. > This allows to avoid ambiguities when applying general database > directives > in slapd.conf. In fact, it is not clear whether they apply to the > proxy > database or to the cache database. Also useful. > > > If they make sense, I'd like to commit them before slapo-pcache > enhancement begins. I agree. > > > p. > > > -Matt

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 04 Jun '09

04 Jun '09

Just in case, before it becomes totally incompatible with HEAD code, I have a patch I never committed, it's about making pcache admin-friendly if it makes any sense. It adds: - a (persistent) counter that reports, for each query, how many times it evaluated to answerable - "proxycache-" prefixed statements are passed to the private database. This allows to avoid ambiguities when applying general database directives in slapd.conf. In fact, it is not clear whether they apply to the proxy database or to the cache database. If they make sense, I'd like to commit them before slapo-pcache enhancement begins. p.

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 03 Jun '09

03 Jun '09

On a related note, any solution using pcache for disconnected operation should also be able to cache bind operations. This is a digest of a conversation I had with Howard about that: Currently pcache always forwards binds to the db beneath it. These will fail in disconnected cases. One solution is to give the pcache identity read privs to the userpassword, but for security and design reasons that won't fly in most installations. Another solution is to add bind caching to pcache, and that is what is described below. Bind caching functionality can be integrated with pcache, provided that we can meet some conditions: 1. Guarantee that the object being bound against is already in pcache when it passes the bind through. 2. Have an attribute in the cached object where pcache can store a hashed version (e.g. SSHA) of the password it got from the user and verified against the underlying database. Remember that we must verify it against the underlying db before we can write it to cache. Most applications performing LDAP authentication will first search for the object to which they're intending to bind. This will cause condition (1) to be satisfied, but this is not good enough because it is not guaranteed that all applications will first search for the object to which they're binding- some applications build the bind DN 'blindly' using string substitution rules or even hard-coded bind DNs. This is wrong, but it's the way things are. Therefore, pcache itself should search for the object being being bound to and populate the cache with the search result. The details of how the object is added to the cache remain to be determined. Satisfying (1) provides the opportunity to construct an proxyattrset that includes a (possibly dummy) attribute in which the hashed validated password can be stored, thus satisfying condition (2). The userPassword attribute can probably be used most of the time for this, since it will either be returned form the server either empty or with a value of '*'. The "do bind caching directive" might refer to a proxyattrset constructed for this purpose. Bind caching will interact with TTR, but the details are as yet undetermined. To round out the solution, we should also process pwdModify exops as follows: For pwdModify exops, pcache would could operate as a 'write-through' cache, first making sure the object in the cache is current. If the write-through to the underlying database succeeds, then the object in the cache is also updated. Otherwise the exop fails and any cached copy is left unaltered. -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by quanah＠zimbra.com 03 Jun '09

03 Jun '09

--On Wednesday, June 03, 2009 7:22 AM +0000 jonathan(a)phillipoux.net wrote: > Will this patch make it into RE23 for a possible maintenance release of > 2.3? There will be no further releases of OpenLDAP 2.3. You should at this point be working on migrating to the OpenLDAP 2.4 release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 03 Jun '09

03 Jun '09

Suggested partual fix - add this possible value for o_cancel: #define SLAP_CANCEL_INVALID 0x04 /* like 0 but prevents Cancel */ Something like this: http://folk.uio.no/hbf/OpenLDAP/cancel-cancel.txt Does not reject abandon(Cancel/StartTLS), would need to extend o_cancel with yet another value. That's ugly enough already, so I let that wait. connection_abandon() in particular isn't invalid client action, but it shouldn't be worse than causing a surprising result code or not response before closing the connection. Does not address syncprov's Cancel handler. I don't know if the bconfig.c pathces are correct, but need to reject cancel before (reacting to) thread pool pauses there and maybe in syncrepl/syncprov. -- Hallvard

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by jonathan＠phillipoux.net 03 Jun '09

03 Jun '09

On 02.06.2009 18:23, Howard Chu wrote: > jonathan(a)phillipoux.net wrote: >> OK, I've spent some more time trying to understand this part of >> syncprov.c. From what I understand : >> >> - the assert failure in ldap_pvt_runqueue_resched is caused by the fact >> syncprov_qstart is trying to "reschedule" a task that is no longer in >> the task_list >> - the only time the task is removed from the task_list (via >> ldap_pvt_runqueue_remove) is when the task is being run, in >> syncprov_qtask, if syncprov_qplay returns !=0 >> - the next time syncprov_qstart is called, it finds "so->s_qtask" is not >> NULL, and tries to reschedule the task, but it's no longer in the >> task_list. >> >> I've written a patch that sets "so->s_qtask" to NULL in syncprov_qtask, >> just after removing the task from the task_list. So that when >> syncprov_qstart is called again, it goes into >> ldap_pvt_runqueue_insert... The patch is attached. >> >> Unfortunately, I can't confirm it fixes the bug since I can't reproduce >> it... For those who understand the logic behind this, does this make any >> sense? :) > > Ah, you want rev 1.249 of syncprov.c. Closing this as a dup of ITS#5776. Indeed, that's great. Thanks a lot! > Of course, all of this code has been removed from RE24 as of 1.265. Will this patch make it into RE23 for a possible maintenance release of 2.3? Regards, Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

(ITS#6159) olcLimits has no replace/delete
by mbackes＠symas.com 02 Jun '09

02 Jun '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.88.99.93) olcLimits only accepts modify ADD suboperations; replace and delete fail, making any changes to existing olcLimits specifications impossible without stopping and editing LDIF.

1 0

Re: (ITS#6138) Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by h.b.furuseth＠usit.uio.no 02 Jun '09

02 Jun '09

back-ldap:extended.c also does "suppress response, it has been sent", but does it by returning and setting rs->sr_err = SLAPD_ABANDON. Might break assumptions somewhere that SLAPD_ABANDON implies o_abandon was set. And I guess the hack fails if the operation gets cancelled. ======================================================================== I think these are the Operation states related to Cancel and Abandon: op->o_abandon is set for these - could extend to multiple values: A) Operation Abandoned/Cancelled by client. B) Operation implicitly abandoned by client. (Bind or lost connection) C) Operation abandoned by server. (It wants to close the connection) D) Suppress response - a duplicate of the operation will proceed. (syncprov) E) Suppress response - final send_ldap_response() was done. (retcode overlay) rs->sr_err == SLAPD_ABANDON if: F) The backend obeyed o_abandon. (Cancel op, if any, will succeed) G=E) Suppress response - final send_ldap_response() was done. (back-ldap) op->o_cancel packs these states/values: H) The o_abandon is due to a Cancel. I) Cancel operation wants a result, cancelled op must set it and wait. J) Result is available to the Cancel operation. K) Result. (LDAP result code, or SLAP_CANCEL_ACK for success) L) Cancel operation has fetched result, cancelled operation can proceed. States that fit in none of the above, or poorly so: M) Operation must not be waited for, e.g. by Cancel. Operation is itself waiting for others, e.g. cn=config update. N) Operation invisible to Abandon/Cancel/internal abandon. msgID reusable due to result sent to client. Also case D (syncprov)? Fix by removing the op from op->o_conn->c_ops? Or does that just move the problem around? Would need to do something to o_conn to prevent connection_close() from doing connection_destroy(). O) Operation result has been committed, do not abandon. ITS#6059. But o_abandon can be set while trying to commit, unless this flag is set before trying - in which case we can't abandon an operation which is failing to commit, which may be when it's most relevant. Could reset o_abandon, if anyone can keep straight the consequences. Or replace the 'if ( op->o_abandon )' tests with some macro call. Still, interactions with other states could be a problem. About the o_abandon values above: B can be treated like A, I think. C differs in that Cancel/Abandon(operation) should not say "already abandoned" since the client doen't know about the abandon. Could be solved with a vague error message. D-E differ in that o_abandon gets set even though the backends' cancel/abandon handlers were not called. Unsure of the effects of that. D Syncprov duplicating a Persistent Search operation. Handled similar to a server-initiated abandon? Except if the operation cannot be "invisible to Abandon/Cancel" above it must remain possible to Abandon/Cancel it. E Suppress response - response has been sent: Set when exiting slap_send_ldap_result() & co? Handled similar to a server-initiated abandon? At the time slap_send_ldap_result() is called again, the operation may have set up things which need to be cleaned up in the normal way. Yet it has already gone through that function once, doing callbacks etc. Must "final response" code be prepared to be called twice? Beyond that, the main problem would be code which transitions to one state to another, it needs to handle the other cases. -- Hallvard

1 0

Re: (ITS#6152) proxycache enhancements
by mhardin＠symas.com 02 Jun '09

02 Jun '09

It might be less intrusive codewise and more flexible if we left the behavior of cache expiration the same and added a parameter to each template called "Time to Refresh" (TTR). Then you set long or unlimited cache expirations, which are always in effect, but set a shorter TTR that would trigger an asynchronous refresh when the TTR expired. If the db is not available these refreshes will simply fail, but the data will remain in the cache at least until it's expired by the usual means. This gives the solution designer the option of deciding how long a system can run disconnected while still being able to separately determine how stale the contents of the cache will get when connected. It also means that pcache itself doesn't need to switch modes based on whether it thinks it's connected to a db or not, and it fact may not need to even know if it is connected or not. There is still room in this design for a flag that controls whether pcache should behave as if it's disconnected or connected, but I'm not sure how useful that is given the changes described above. Cheers, -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by hyc＠symas.com 02 Jun '09

02 Jun '09

jonathan(a)phillipoux.net wrote: > OK, I've spent some more time trying to understand this part of > syncprov.c. From what I understand : > > - the assert failure in ldap_pvt_runqueue_resched is caused by the fact > syncprov_qstart is trying to "reschedule" a task that is no longer in > the task_list > - the only time the task is removed from the task_list (via > ldap_pvt_runqueue_remove) is when the task is being run, in > syncprov_qtask, if syncprov_qplay returns !=0 > - the next time syncprov_qstart is called, it finds "so->s_qtask" is not > NULL, and tries to reschedule the task, but it's no longer in the task_list. > > I've written a patch that sets "so->s_qtask" to NULL in syncprov_qtask, > just after removing the task from the task_list. So that when > syncprov_qstart is called again, it goes into > ldap_pvt_runqueue_insert... The patch is attached. > > Unfortunately, I can't confirm it fixes the bug since I can't reproduce > it... For those who understand the logic behind this, does this make any > sense? :) Ah, you want rev 1.249 of syncprov.c. Closing this as a dup of ITS#5776. Of course, all of this code has been removed from RE24 as of 1.265. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6158) syncprov: assert causing slapd to core dump
by jonathan＠phillipoux.net 02 Jun '09

02 Jun '09

This is a multi-part message in MIME format. --------------080204020206070201080405 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 02.06.2009 12:28, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: 2.3.43 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.41.243.192) > > > Hi, > > I have a 2.3.43 running on a Solaris Sparc server, which crashes occasionally - > once every week or two, always during the night. At this particular time a large > number of operations are performed, including mass deletes and adds. I haven't > been able to reproduce this bug, just watch it happen on the production server > every now and again... > > I managed to obtain a coredump, and a backtrace (at the end of this message). I > realize this isn't much to go on, but I'm rather unfamiliar with this part of > the code, so I wondered if anyone has an idea what's going on here? > > FWIW, the dynlist and chain overlays are in use on the server, and the database > is bdb, with a syncrepl consumer as well as syncprov overlay. > > > Backtrace follows: > 8<------------------------------------------------------------- > Thread 1 (process 1054014 ): > #0 0xfee4aa58 in _lwp_kill () from /lib/libc.so.1 > #1 0xfede5a64 in raise () from /lib/libc.so.1 > #2 0xfedc1954 in abort () from /lib/libc.so.1 > #3 0xfedc1b90 in _assert () from /lib/libc.so.1 > #4 0xff30ef44 in ldap_pvt_runqueue_resched (rq=0x16c630, entry=0xee6c0a0, > defer=0) at rq.c:165 > #5 0xfe7f4a94 in syncprov_qstart (so=0x10acb540) at syncprov.c:933 > #6 0xfe7f4d6c in syncprov_qresp (opc=0x1b1bfaf8, so=0x10acb540, mode=2) at > syncprov.c:982 > #7 0xfe7f5aa4 in syncprov_matchops (op=0xf6bffa50, opc=0x1b1bfaf8, saveit=0) at > syncprov.c:1175 > #8 0xfe7f7490 in syncprov_op_response (op=0xf6bffa50, rs=0xf6bff644) at > syncprov.c:1561 > #9 0x000575cc in ?? () > #10 0x000575cc in ?? () > 8<------------------------------------------------------------- > > Thanks in advance for any pointers! > OK, I've spent some more time trying to understand this part of syncprov.c. From what I understand : - the assert failure in ldap_pvt_runqueue_resched is caused by the fact syncprov_qstart is trying to "reschedule" a task that is no longer in the task_list - the only time the task is removed from the task_list (via ldap_pvt_runqueue_remove) is when the task is being run, in syncprov_qtask, if syncprov_qplay returns !=0 - the next time syncprov_qstart is called, it finds "so->s_qtask" is not NULL, and tries to reschedule the task, but it's no longer in the task_list. I've written a patch that sets "so->s_qtask" to NULL in syncprov_qtask, just after removing the task from the task_list. So that when syncprov_qstart is called again, it goes into ldap_pvt_runqueue_insert... The patch is attached. Unfortunately, I can't confirm it fixes the bug since I can't reproduce it... For those who understand the logic behind this, does this make any sense? :) Regards, Jonathan -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org -------------------------------------------------------------- --------------080204020206070201080405 Content-Type: text/x-patch; name="patch-syncprov-20090602.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="patch-syncprov-20090602.patch" Index: servers/slapd/overlays/syncprov.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v retrieving revision 1.56.2.51 diff -u -p -r1.56.2.51 syncprov.c --- servers/slapd/overlays/syncprov.c 9 Jul 2008 20:53:13 -0000 1.56.2.51 +++ servers/slapd/overlays/syncprov.c 2 Jun 2009 15:57:21 -0000 @@ -908,6 +908,7 @@ syncprov_qtask( void *ctx, void *arg ) } else { /* bail out on any error */ ldap_pvt_runqueue_remove( &slapd_rq, rtask ); + if ( so ) so->s_qtask = NULL; } ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex ); --------------080204020206070201080405--

1 0

Re: (ITS#6153) Segfault during Heimdal's kadmin -l init Realm
by hyc＠symas.com 02 Jun '09

02 Jun '09

dewayne_freebsd(a)yahoo.com wrote: > Full_Name: Dewayne Geraghty > Version: 2.4.16 > OS: FreeBSD 7.2R > URL: http://www.consciuminternational.com.au/ldap > Submission from: (NULL) (58.172.112.108) > > > FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16 > Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend. > Segmentation fault during > kadmin -l > init HS Use Heimdal 1.2.2. https://roundup.it.su.se/jira/browse/HEIMDAL-220 > > slapd and heimdal work correctly, independently. > > slapd is running at debug 1019, logs are at enclosed URL along with the full gdb > trace, and configuration files. If I can assist please advise. > > This is a single Pentium CPU, and gcc flags > CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5 > -DDO_SAMBA -DHAVE_OPENSSL > > #0 0x286447b6 in memmove () from /lib/libc.so.7 > #1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6 > #2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6 > #3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6 > #4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6 > #5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6 > #6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6 > #7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0, > entry=0xbfbfe790) at hdb-ldap.c:1600 > #8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0, > princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") > at create_s.c:182 > #9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0, > princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") > at common_glue.c:64 > #10 0x0804e496 in ?? () > #11 0x2871b0c0 in ?? () > #12 0xbfbfea3c in ?? () > #13 0x00000011 in ?? () > #14 0xbfbfe830 in ?? () > #15 0x28084000 in ?? () > #16 0x28084200 in ?? () > #17 0x28084400 in ?? () > #18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 > #19 0x0804e8c9 in ?? () > #20 0x2870c0e0 in ?? () > #21 0x00000000 in ?? () > #22 0x00000000 in ?? () > #23 0x00000000 in ?? () > #24 0x2870c085 in ?? () > #25 0x00000000 in ?? () > #26 0x28650030 in ?? () from /lib/libc.so.7 > > I have spent weeks trying to get this to work. (Because I'm using and modifing > the FreeBSD ports system to build and use the latest version of LDAP and > Heimdal.) > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6158) syncprov: assert causing slapd to core dump
by jonathan＠phillipoux.net 02 Jun '09

02 Jun '09

Full_Name: Jonathan Clarke Version: 2.3.43 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Hi, I have a 2.3.43 running on a Solaris Sparc server, which crashes occasionally - once every week or two, always during the night. At this particular time a large number of operations are performed, including mass deletes and adds. I haven't been able to reproduce this bug, just watch it happen on the production server every now and again... I managed to obtain a coredump, and a backtrace (at the end of this message). I realize this isn't much to go on, but I'm rather unfamiliar with this part of the code, so I wondered if anyone has an idea what's going on here? FWIW, the dynlist and chain overlays are in use on the server, and the database is bdb, with a syncrepl consumer as well as syncprov overlay. Backtrace follows: 8<------------------------------------------------------------- Thread 1 (process 1054014 ): #0 0xfee4aa58 in _lwp_kill () from /lib/libc.so.1 #1 0xfede5a64 in raise () from /lib/libc.so.1 #2 0xfedc1954 in abort () from /lib/libc.so.1 #3 0xfedc1b90 in _assert () from /lib/libc.so.1 #4 0xff30ef44 in ldap_pvt_runqueue_resched (rq=0x16c630, entry=0xee6c0a0, defer=0) at rq.c:165 #5 0xfe7f4a94 in syncprov_qstart (so=0x10acb540) at syncprov.c:933 #6 0xfe7f4d6c in syncprov_qresp (opc=0x1b1bfaf8, so=0x10acb540, mode=2) at syncprov.c:982 #7 0xfe7f5aa4 in syncprov_matchops (op=0xf6bffa50, opc=0x1b1bfaf8, saveit=0) at syncprov.c:1175 #8 0xfe7f7490 in syncprov_op_response (op=0xf6bffa50, rs=0xf6bff644) at syncprov.c:1561 #9 0x000575cc in ?? () #10 0x000575cc in ?? () 8<------------------------------------------------------------- Thanks in advance for any pointers! Regards, Jonathan

1 0

Re: (ITS#6133) back-relay issues
by h.b.furuseth＠usit.uio.no 01 Jun '09

01 Jun '09

Questions: * relay_back_operational() sets up callbacks. Should it? Looks harmless, but as far as I can tell, be->be_operational() functions do not use them, since they (should) send no response. * There is no relay_back_chk_controls(). Should there be? Though I think DNs would then be rewritten four times the same way for each operation:-( Already operational, has_subordinates and finally the operation itself does. And possibly for access controls. I've factored op.c code out to table-driven handlers and a macro, and cleaned away those '#if 0's. Fixed more problems: * Search referrals should have a scope. * relay_back_op_extended() was (still) broken. The handler should return a result which caller should send, so it must set sr->sr_ref without freeing it. Setting REP_REF_MUSTBEFREED instead, and droping the RB_SEND requirement in fail_mode. * For readability, fixed return values from relay_back_chk_referrals() and other unused handlers. (chk_referrals may be unfixable.) * relay_back_entry_<get/release>_rw() returned operationsError for failure. Failing with noSuchObject/unwillingToPerform instead. * relay_back_entry_release_rw() leaked entries when bd->be_release==0. For paranoia, fixed it only when the entry's e_private == NULL. > * The handlers for Abandon, Cancel and connection-init/destroy > should not exist, as far as I can tell. They forward the call to the > underlying backend database, but that means it receives the call twice: So does Unbind. Removed the handler. > * back-relay can be configured to cause infinite recursion. (...) > Anyway, recursion can now be properly caught with op->o_extra. (...) Needed a unique key per <operation type, relay database> combination. Otherwise things like backend_group() called from another operation failed when looking up a relayed DN via relay_back_entry_get_rw(). That fixed relay_back_operational() and relay_back_has_subordinates(), or at least I assume that's what their FIXMEs were about. -- Hallvard

1 0

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by subbarao＠computer.org 01 Jun '09

01 Jun '09

Howard Chu wrote: >> I was just looking around for a possible explanation to the problem that >> I'm encountering. >> >> I double-checked the version that I was running and it's actually >> 2.4.15, not 2.4.16. Would there be a significant difference between >> these two versions with respect to TLS certificate handling? > > Yes. Read the 2.4.16 CHANGES. Ok, I see the following: Fixed libldap GnuTLS TLSVerifyCilent try (ITS#5981) Looking at ITS #5981, that seems to be exactly the same problem that I'm having. I tried searching the openldap.org site before for similar keywords, but I guess I missed this. Thanks, -Kartik

1 0

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by hyc＠symas.com 01 Jun '09

01 Jun '09

Kartik Subbarao wrote: > Howard Chu wrote: >> This bug report makes no sense; the code you quoted is not part of >> OpenLDAP 2.4.16. The relevant code is in function tlsg_session_accept() >> in tls_g.c, and there is no such bug in that function. > > Well, according to the CVS head branch, the code that I cited in tls.c > is still there: > > http://www.openldap.org/devel/cvsweb.cgi/~checkout~/libraries/libldap/tls.c… > > But I certainly defer to your knowledge of which code is relevant Read the Makefile; tls.c is not used any more. > -- I > was just looking around for a possible explanation to the problem that > I'm encountering. > > I double-checked the version that I was running and it's actually > 2.4.15, not 2.4.16. Would there be a significant difference between > these two versions with respect to TLS certificate handling? Yes. Read the 2.4.16 CHANGES. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by subbarao＠computer.org 01 Jun '09

01 Jun '09

Howard Chu wrote: > This bug report makes no sense; the code you quoted is not part of > OpenLDAP 2.4.16. The relevant code is in function tlsg_session_accept() > in tls_g.c, and there is no such bug in that function. Well, according to the CVS head branch, the code that I cited in tls.c is still there: http://www.openldap.org/devel/cvsweb.cgi/~checkout~/libraries/libldap/tls.c… But I certainly defer to your knowledge of which code is relevant -- I was just looking around for a possible explanation to the problem that I'm encountering. I double-checked the version that I was running and it's actually 2.4.15, not 2.4.16. Would there be a significant difference between these two versions with respect to TLS certificate handling? Again, here is the error I'm getting on the server side with TLSVerifyClient set to "try" and I do an ldapsearch over SSL without a client certificate: TLS: gnutls_certificate_verify_peers2 failed -49 TLS: can't accept: (unknown error code). connection_read(24): TLS accept failure error=-1 id=3, closing Thanks, -Kartik

1 0

(ITS#6157) unAbandonable operations aren't.
by h.b.furuseth＠usit.uio.no 01 Jun '09

01 Jun '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFCs 3909 (Cancel) and 4511 (LDAP protocol) say some operations cannot be cancelled/abandoned: Abandon, Bind, Unbind, StartTLS, Cancel. Clients can cancel least Cancel. That lets a client deadlock slapd, or all slapd threads but one, by spamming slapd with pairs of Cancels that cancel each other. If both are started, each waits for the other. Also cn=config operations need to be at least unCancelable: The same happens if you send pairs of (cn=config op, Cancel that op). Regarding Cancel, one fix resembling current code would be: * Before an operation waits for (an)other operation(s): - Fail if o_cancel, and if o_abandon when the op is abandonable, - Make it uncancellable: set o_cancel = tooLate even when !o_abandon. * Cancel and Abandon operations: - Fail if the targeted operation already has tooLate/cannotCancel. Actually Cancel already does, but with wrong result code + message. I include Abandon to keep the number of cancel/abandon-related states down. Also, (o_abandon, o_cancel) = (1, tooLate) would otherwise mean two things with the fix above: The op was Cancelled but completed anyway, or the op was Abandoned and is uncancellable (but not necessarily unabandonable).

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by Kurt＠OpenLDAP.org 01 Jun '09

01 Jun '09

On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------080004030402080700020504 > Content-Type: text/plain; charset=3DISO-8859-1 > Content-Transfer-Encoding: 8bit > > Updated schema file cosine-update.schema attached. I note that differs are generally preferred, even where the file is =20 mostly changed. This helps ensure changes that others might make to =20 the file you started with are not lost. > Note that some schema > descriptions were copied from old cosine.schema to preserve backward > compability since RFC 4524 does not contain all schema descriptions =20= > e.g. > needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior > class for 'OpenLDAPperson'. Also some aliases were added to NAME of > attribute type descriptions. > > IPR notice: > This patch file is derived from OpenLDAP Software and RFC 4524 and RFC > 1274. All of the modifications to OpenLDAP Software represented in the > attached file were developed by Michael Str=F6der =20 > <michael(a)stroeder.com>. > I have not assigned rights and/or interest in this work to any party. While this notice of origin is fine, you did not include a rights =20 statement. > > > --------------080004030402080700020504 > Content-Type: text/plain; > name=3D"cosine-update.schema" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename=3D"cosine-update.schema" > > # RFC 4524: COSINE LDAP/X.500 Schema > # $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.26 =20 > 2009/01/21 23:40:40 kurt Exp $ > ## This work is part of OpenLDAP Software <http://www.openldap.org/>. > ## > ## Copyright 1998-2009 The OpenLDAP Foundation. > ## All rights reserved. > ## > ## Redistribution and use in source and binary forms, with or without > ## modification, are permitted only as authorized by the OpenLDAP > ## Public License. > ## > ## A copy of this license is available in the file LICENSE in the > ## top-level directory of the distribution or, alternatively, at > ## <http://www.OpenLDAP.org/license.html>. > # > # RFC 4524: COSINE LDAP/X.500 Schema > # This file is mainly based on the schema descriptions found in RFC =20= > 4524. > # To preserve backwards compability with 'pilotPerson' schema some =20 > attribute > # types and object classes not declared in RFC 4524 were copied from > # (obsoleted) RFC 1274 and some attribute type descriptions were =20 > extended > # with aliases for NAME. > # > # Depends on core.schema > > # =20 > = --------------------------------------------------------------------------= > # 2. COSINE Attribute Types > # =20 > = --------------------------------------------------------------------------= > # > # This section details COSINE attribute types for use in LDAP. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.1. associatedDomain > # > # The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] > # host names [RFC1123] that are associated with an object. That =20= > is, > # values of this attribute should conform to the following ABNF: > # > # domain =3D root / label *( DOT label ) > # root =3D SPACE > # label =3D LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] > # LETDIG =3D %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / =20= > "a"-"z" > # SPACE =3D %x20 ; space (" ") > # HYPHEN =3D %x2D ; hyphen ("-") > # DOT =3D %x2E ; period (".") > # > # For example, the entry in the DIT with a DN <DC=3Dexample,DC=3Dcom>= =20 > might > # have an associated domain of "example.com". > # > # (OpenLDAP-specific: Declared in core.schema) > # attributetype ( 0.9.2342.19200300.100.1.37 > # NAME 'associatedDomain' > # EQUALITY caseIgnoreIA5Match > # SUBSTR caseIgnoreIA5SubstringsMatch > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > # > # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the > # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are > # described in [RFC4517]. > # > # Note that the directory will not ensure that values of this =20 > attribute > # conform to the <domain> production provided above. It is the > # application's responsibility to ensure that domains it stores =20 > in this > # attribute are appropriately represented. > # > # Also note that applications supporting Internationalized Domain =20= > Names > # SHALL use the ToASCII method [RFC3490] to produce <label> =20 > components > # of the <domain> production. > > # =20 > = --------------------------------------------------------------------------= > # 2.2. associatedName > # > # The 'associatedName' attribute specifies names of entries in the > # organizational DIT associated with a DNS domain [RFC1034]=20 > [RFC2181]. > # > > attributetype ( 0.9.2342.19200300.100.1.38 > NAME 'associatedName' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.3. buildingName > # > # The 'buildingName' attribute specifies names of the buildings =20 > where > # an organization or organizational unit is based, for example, =20 > "The > # White House". > # > > attributetype ( 0.9.2342.19200300.100.1.48 > NAME 'buildingName' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.4. co > # > # The 'co' (Friendly Country Name) attribute specifies names of > # countries in human-readable format, for example, "Germany" and > # "Federal Republic of Germany". It is commonly used in =20 > conjunction > # with the 'c' (Country Name) [RFC4519] attribute (whose values are > # restricted to the two-letter codes defined in [ISO3166]). > # > > attributetype ( 0.9.2342.19200300.100.1.43 > NAME 'co' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.5. documentAuthor > # > # The 'documentAuthor' attribute specifies the distinguished =20 > names of > # authors (or editors) of a document. For example, > # > > attributetype ( 0.9.2342.19200300.100.1.14 > NAME 'documentAuthor' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.6. documentIdentifier > # > # The 'documentIdentifier' attribute specifies unique identifiers =20= > for a > # document. A document may be identified by more than one unique > # identifier. For example, RFC 3383 and BCP 64 are unique =20 > identifiers > # that (presently) refer to the same document. > # > > attributetype ( 0.9.2342.19200300.100.1.11 > NAME 'documentIdentifier' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.7. documentLocation > # > # The 'documentLocation' attribute specifies locations of the =20 > document > # original. > # > > attributetype ( 0.9.2342.19200300.100.1.15 > NAME 'documentLocation' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.8. documentPublisher > # > # The 'documentPublisher' attribute is the persons and/or =20 > organizations > # that published the document. Documents that are jointly =20 > published > # have one value for each publisher. > # > > attributetype ( 0.9.2342.19200300.100.1.56 > NAME 'documentPublisher' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.9. documentTitle > # > # The 'documentTitle' attribute specifies the titles of a document. > # Multiple values are allowed to accommodate both long and short > # titles, or other situations where a document has multiple =20 > titles, for > # example, "The Lightweight Directory Access Protocol Technical > # Specification" and "The LDAP Technical Specification". > # > > attributetype ( 0.9.2342.19200300.100.1.12 > NAME 'documentTitle' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.10. documentVersion > # > # The 'documentVersion' attribute specifies the version =20 > information of > # a document. > # > > attributetype ( 0.9.2342.19200300.100.1.13 > NAME 'documentVersion' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.11. drink > # > # The 'drink' (favouriteDrink) attribute specifies the favorite =20 > drinks > # of an object (or person), for instance, "cola" and "beer". > # > > attributetype ( 0.9.2342.19200300.100.1.5 > NAME ( 'drink' 'favouriteDrink' ) > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.12. homePhone > # > # The 'homePhone' (Home Telephone Number) attribute specifies home > # telephone numbers (e.g., "+1 775 555 1234") associated with a =20 > person. > # > > attributetype ( 0.9.2342.19200300.100.1.20 > NAME ( 'homePhone' 'homeTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and =20= > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' =20 > rules are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.13. homePostalAddress > # > # The 'homePostalAddress' attribute specifies home postal =20 > addresses for > # an object. Each value should be limited to up to 6 directory =20 > strings > # of 30 characters each. (Note: It is not intended that the =20 > directory > # service enforce these limits.) > # > > attributetype ( 0.9.2342.19200300.100.1.39 > NAME 'homePostalAddress' > EQUALITY caseIgnoreListMatch > SUBSTR caseIgnoreListSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) > > # > # The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the > # 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules =20= > are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.14. host > # > # The 'host' attribute specifies host computers, generally by their > # primary fully qualified domain name (e.g., my-host.example.com). > # > > attributetype ( 0.9.2342.19200300.100.1.9 > NAME 'host' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.15. info > # > # The 'info' attribute specifies any general information =20 > pertinent to > # an object. This information is not necessarily descriptive of =20= > the > # object. > # > # Applications should not attach specific semantics to values of =20= > this > # attribute. The 'description' attribute [RFC4519] is available =20= > for > # specifying descriptive information pertinent to an object. > # > > attributetype ( 0.9.2342.19200300.100.1.4 > NAME 'info' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.16. mail > # > # The 'mail' (rfc822mailbox) attribute type holds Internet mail > # addresses in Mailbox [RFC2821] form (e.g., user(a)example.com). > # > # (OpenLDAP-specific: Declared in core.schema) > # attributetype ( 0.9.2342.19200300.100.1.3 > # NAME 'mail' > # EQUALITY caseIgnoreIA5Match > # SUBSTR caseIgnoreIA5SubstringsMatch > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > # > # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the > # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are > # described in [RFC4517]. > # > # Note that the directory will not ensure that values of this =20 > attribute > # conform to the <Mailbox> production [RFC2821]. It is the > # application's responsibility to ensure that domains it stores =20 > in this > # attribute are appropriately represented. > # > # Additionally, the directory will compare values per the matching > # rules named in the above attribute type description. As these =20= > rules > # differ from rules that normally apply to <Mailbox> comparisons, > # operational issues may arise. For example, the assertion > # (mail=3Djoe(a)example.com) will match "JOE(a)example.com" even though = =20 > the > # <local-parts> differ. Also, where a user has two <Mailbox>es =20 > whose > # addresses differ only by case of the <local-part>, both cannot be > # listed as values of the user's mail attribute (as they are =20 > considered > # equal by the 'caseIgnoreIA5Match' rule). > # > # Also note that applications supporting internationalized domain =20= > names > # SHALL use the ToASCII method [RFC3490] to produce <sub-domain> > # components of the <Mailbox> production. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.17. manager > # > # The 'manager' attribute specifies managers, by distinguished =20 > name, of > # the person (or entity). > # > > attributetype ( 0.9.2342.19200300.100.1.10 > NAME 'manager' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.18. mobile > # > # The 'mobile' (mobileTelephoneNumber) attribute specifies mobile > # telephone numbers (e.g., "+1 775 555 6789") associated with a =20 > person > # (or entity). > # > > attributetype ( 0.9.2342.19200300.100.1.41 > NAME ( 'mobile' 'mobileTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and =20= > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' =20 > rules are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.19. organizationalStatus > # > # The 'organizationalStatus' attribute specifies categories by =20 > which a > # person is often referred to in an organization. Examples of =20 > usage in > # academia might include "undergraduate student", "researcher", > # "professor", and "staff". Multiple values are allowed where the > # person is in multiple categories. > # > # Directory administrators and application designers SHOULD =20 > consider > # carefully the distinctions between this and the 'title' and > # 'userClass' attributes. > # > > attributetype ( 0.9.2342.19200300.100.1.45 > NAME 'organizationalStatus' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.20. pager > # > # The 'pager' (pagerTelephoneNumber) attribute specifies pager > # telephone numbers (e.g., "+1 775 555 5555") for an object. > # > > attributetype ( 0.9.2342.19200300.100.1.42 > NAME ( 'pager' 'pagerTelephoneNumber' ) > EQUALITY telephoneNumberMatch > SUBSTR telephoneNumberSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) > > # > # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and =20= > the > # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' =20 > rules are > # described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.21. personalTitle > # > # The 'personalTitle' attribute specifies personal titles for a =20 > person. > # Examples of personal titles are "Frau", "Dr.", "Herr", and > # "Professor". > # > > attributetype ( 0.9.2342.19200300.100.1.40 > NAME 'personalTitle' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.22. roomNumber > # > # The 'roomNumber' attribute specifies the room number of an =20 > object. > # During periods of renumbering, or in other circumstances where =20= > a room > # has multiple valid room numbers associated with it, multiple =20 > values > # may be provided. Note that the 'cn' (commonName) attribute type > # SHOULD be used for naming room objects. > # > > attributetype ( 0.9.2342.19200300.100.1.6 > NAME 'roomNumber' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.23. secretary > # > # The 'secretary' attribute specifies secretaries and/or =20 > administrative > # assistants, by distinguished name. > # > > attributetype ( 0.9.2342.19200300.100.1.21 > NAME 'secretary' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) > > # > # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax =20 > and the > # 'distinguishedNameMatch' rule are described in [RFC4517]. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.24. uniqueIdentifier > # > # The 'uniqueIdentifier' attribute specifies a unique identifier =20= > for an > # object represented in the Directory. The domain within which the > # identifier is unique and the exact semantics of the identifier =20= > are > # for local definition. For a person, this might be an =20 > institution- > # wide payroll number. For an organizational unit, it might be a > # department code. > # > > attributetype ( 0.9.2342.19200300.100.1.44 > NAME 'uniqueIdentifier' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > # Note: X.520 also describes an attribute called 'uniqueIdentifier' > # (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP > # [RFC4519]. The attribute detailed here ought not be =20 > confused > # with 'x500UniqueIdentifier'. > # > > # =20 > = --------------------------------------------------------------------------= > # 2.25. userClass > # > # The 'userClass' attribute specifies categories of computer or > # application user. The semantics placed on this attribute are for > # local interpretation. Examples of current usage of this =20 > attribute in > # academia are "student", "staff", and "faculty". Note that the > # 'organizationalStatus' attribute type is now often preferred, =20 > as it > # makes no distinction between persons as opposed to users. > # > > attributetype ( 0.9.2342.19200300.100.1.8 > NAME 'userClass' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # > # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and =20= > the > # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are =20 > described > # in [RFC4517]. > # > > > # =20 > = --------------------------------------------------------------------------= > # Attribute types from RFC 1274 which are missing in RFC 4524 > # =20 > = --------------------------------------------------------------------------= > # > # 9.3.2. Text Encoded O/R Address > # > # The Text Encoded O/R Address attribute type specifies a text =20 > encoding > # of an X.400 O/R address, as specified in RFC 987. The use of this > # attribute is deprecated as the attribute is intended for interim =20= > use > # only. This attribute will be the first candidate for the attribute > # expiry mechanisms! > # > # textEncodedORAddress ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # caseIgnoreStringSyntax > # (SIZE (1 .. ub-text-encoded-or-address)) > # ::=3D {pilotAttributeType 2} > # > > attributetype ( 0.9.2342.19200300.100.1.2 > NAME 'textEncodedORAddress' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.7. Photo > # > # The Photo attribute type specifies a "photograph" for an object. > # This should be encoded in G3 fax as explained in recommendation T.=20= > 4, > # with an ASN.1 wrapper to make it compatible with an X.400 =20 > BodyPart as > # defined in X.420. > # > # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules > # information-objects } > # > # photo ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # CHOICE { > # g3-facsimile [3] G3FacsimileBodyPart > # } > # (SIZE (1 .. ub-photo)) > # ::=3D {pilotAttributeType 7} > # > > attributetype ( 0.9.2342.19200300.100.1.7 > NAME 'photo' > DESC 'RFC1274: photo (G3 fax)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.18. Other Mailbox > # > # The Other Mailbox attribute type specifies values for electronic > # mailbox types other than X.400 and rfc822. > # > # otherMailbox ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # SEQUENCE { > # mailboxType PrintableString, -- e.g. Telemail > # mailbox IA5String -- e.g. X378:Joe > # } > # ::=3D {pilotAttributeType 22} > # > > attributetype ( 0.9.2342.19200300.100.1.22 > NAME 'otherMailbox' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.22. DNS ARecord > # > # The A Record attribute type specifies a type A (Address) DNS =20 > resource > # record [6] [7]. > # > # aRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 26} > # > ## incorrect syntax? > attributetype ( 0.9.2342.19200300.100.1.26 > NAME 'aRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > ## missing from RFC1274 > ## incorrect syntax? > attributetype ( 0.9.2342.19200300.100.1.27 > NAME 'mDRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.23. MX Record > # > # The MX Record attribute type specifies a type MX (Mail Exchange) =20= > DNS > # resource record [6] [7]. > # > # mXRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 28} > # > ## incorrect syntax!! > attributetype ( 0.9.2342.19200300.100.1.28 > NAME 'mXRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.24. NS Record > # > # The NS Record attribute type specifies an NS (Name Server) DNS > # resource record [6] [7]. > # > # nSRecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 29} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.29 > NAME 'nSRecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.25. SOA Record > # > # The SOA Record attribute type specifies a type SOA (Start of > # Authority) DNS resorce record [6] [7]. > # > # sOARecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # DNSRecordSyntax > # ::=3D {pilotAttributeType 30} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.30 > NAME 'sOARecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.26. CNAME Record > # > # The CNAME Record attribute type specifies a type CNAME (Canonical > # Name) DNS resource record [6] [7]. > # > # cNAMERecord ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # iA5StringSyntax > # ::=3D {pilotAttributeType 31} > # > ## incorrect syntax!! > > attributetype ( 0.9.2342.19200300.100.1.31 > NAME 'cNAMERecord' > EQUALITY caseIgnoreIA5Match > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.36. Janet Mailbox > # > # The Janet Mailbox attribute type specifies an electronic mailbox > # attribute following the syntax specified in the Grey Book of the > # Coloured Book series. This attribute is intended for the =20 > convenience > # of U.K users unfamiliar with rfc822 and little-endian mail =20 > addresses. > # Entries using this attribute MUST also include an rfc822Mailbox > # attribute. > # > # janetMailbox ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # caseIgnoreIA5StringSyntax > # (SIZE (1 .. ub-janet-mailbox)) > # ::=3D {pilotAttributeType 46} > # > attributetype ( 0.9.2342.19200300.100.1.46 > NAME 'janetMailbox' > DESC 'RFC1274: Janet mailbox' > EQUALITY caseIgnoreIA5Match > SUBSTR caseIgnoreIA5SubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.37. Mail Preference Option > # > # An attribute to allow users to indicate a preference for =20 > inclusion of > # their names on mailing lists (electronic or physical). The absence > # of such an attribute should be interpreted as if the attribute was > # present with value "no-list-inclusion". This attribute should be > # interpreted by anyone using the directory to derive mailing lists, > # and its value respected. > # > # mailPreferenceOption ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX ENUMERATED { > # no-list-inclusion(0), > # any-list-inclusion(1), -- may be added to any lists > # professional-list-inclusion(2) > # -- may be added to lists > # -- which the list provider > # -- views as related to the > # -- users professional inter- > # -- ests, perhaps evaluated > # -- from the business of the > # -- organisation or keywords > # -- in the entry. > # } > # ::=3D {pilotAttributeType 47} > # > > attributetype ( 0.9.2342.19200300.100.1.47 > NAME 'mailPreferenceOption' > DESC 'RFC1274: mail preference option' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.43. Personal Signature > # > # The Personal Signature attribute type allows for a representation =20= > of > # a person's signature. This should be encoded in G3 fax as =20 > explained > # in recommendation T.4, with an ASN.1 wrapper to make it compatible > # with an X.400 BodyPart as defined in X.420. > # > # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules > # information-objects } > # > # personalSignature ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # CHOICE { > # g3-facsimile [3] G3FacsimileBodyPart > # } > # (SIZE (1 .. ub-personal-signature)) > # ::=3D {pilotAttributeType 53} > # > > attributetype ( 0.9.2342.19200300.100.1.53 > NAME 'personalSignature' > DESC 'RFC1274: Personal Signature (G3 fax)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 ) > > # =20 > = --------------------------------------------------------------------------= > # 9.3.45. Audio > # > # The Audio attribute type allows the storing of sounds in the > # Directory. The attribute uses a u-law encoded sound file as used =20= > by > # the "play" utility on a Sun 4. This is an interim format. > # > # audio ATTRIBUTE > # WITH ATTRIBUTE-SYNTAX > # Audio > # (SIZE (1 .. ub-audio)) > # ::=3D {pilotAttributeType 55} > # > > attributetype ( 0.9.2342.19200300.100.1.55 > NAME 'audio' > DESC 'RFC1274: audio (u-law)' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} ) > > > # =20 > = --------------------------------------------------------------------------= > # 3. COSINE Object Classes > # =20 > = --------------------------------------------------------------------------= > # > # This section details COSINE object classes for use in LDAP. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.1. account > # > # The 'account' object class is used to define entries representing > # computer accounts. The 'uid' attribute SHOULD be used for naming > # entries of this object class. > # > > objectclass ( 0.9.2342.19200300.100.4.5 > NAME 'account' > SUP top STRUCTURAL > MUST uid > MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) > > # > # The 'top' object class is described in [RFC4512]. The =20 > 'description', > # 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are =20 > described in > # [RFC4519]. The 'host' attribute type is described in Section 2 =20= > of > # this document. > # > # Example: > # > # dn: uid=3Dkdz,cn=3DAccounts,dc=3DExample,dc=3DCOM > # objectClass: account > # uid: kdz > # seeAlso: cn=3DKurt D. Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCO= M > # > > # =20 > = --------------------------------------------------------------------------= > # 3.2. document > # > # The 'document' object class is used to define entries that =20 > represent > # documents. > # > > objectclass ( 0.9.2342.19200300.100.4.6 > NAME 'document' > SUP top STRUCTURAL > MUST documentIdentifier > MAY ( cn $ description $ seeAlso $ l $ o $ ou $ > documentTitle $ documentVersion $ documentAuthor $ > documentLocation $ documentPublisher ) ) > > # > # The 'top' object class is described in [RFC4512]. The 'cn', > # 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are > # described in [RFC4519]. The 'documentIdentifier', =20 > 'documentTitle', > # 'documentVersion', 'documentAuthor', 'documentLocation', and > # 'documentPublisher' attribute types are described in Section 2 of > # this document. > # > # Example: > # > # dn: documentIdentifier=3DRFC 4524,cn=3DRFC,dc=3DExample,dc=3DCOM= > # objectClass: document > # documentIdentifier: RFC 4524 > # documentTitle: COSINE LDAP/X.500 Schema > # documentAuthor: cn=3DKurt D. =20 > Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCOM > # documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt > # documentPublisher: Internet Engineering Task Force > # description: A collection of schema elements for use in LDAP > # description: Obsoletes RFC 1274 > # seeAlso: documentIdentifier=3DRFC = 4510,cn=3DRFC,dc=3DExample,dc=3DCOM > # seeAlso: documentIdentifier=3DRFC = 1274,cn=3DRFC,dc=3DExample,dc=3DCOM > # > > # =20 > = --------------------------------------------------------------------------= > # 3.3. documentSeries > # > # The 'documentSeries' object class is used to define an entry that > # represents a series of documents (e.g., The Request For Comments > # memos). > # > > objectclass ( 0.9.2342.19200300.100.4.9 > NAME 'documentSeries' > SUP top STRUCTURAL > MUST cn > MAY ( description $ l $ o $ ou $ seeAlso $ telephonenumber ) ) > > # > # The 'top' object class is described in [RFC4512]. The =20 > 'description', > # 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute =20 > types are > # described in [RFC4519]. > # > # Example: > # > # dn: cn=3DRFC,dc=3DExample,dc=3DCOM > # objectClass: documentSeries > # cn: Request for Comments > # cn: RFC > # description: a series of memos about the Internet > # > > # =20 > = --------------------------------------------------------------------------= > # 3.4. domain > # > # The 'domain' object class is used to define entries that =20 > represent > # DNS domains for objects that are not organizations, =20 > organizational > # units, or other kinds of objects more appropriately defined =20 > using an > # object class specific to the kind of object being defined (e.g., > # 'organization', 'organizationUnit'). > # > # The 'dc' attribute should be used for naming entries of the =20 > 'domain' > # object class. > # > > objectclass ( 0.9.2342.19200300.100.4.13 > NAME 'domain' > SUP top STRUCTURAL > MUST dc > MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ > x121Address $ registeredAddress $ destinationIndicator $ > preferredDeliveryMethod $ telexNumber $ > teletexTerminalIdentifier $ telephoneNumber $ > internationaliSDNNumber $ facsimileTelephoneNumber $ street $ > postOfficeBox $ postalCode $ postalAddress $ > physicalDeliveryOfficeName $ st $ l $ description $ o $ > associatedName ) ) > > # > # The 'top' object class and the 'dc', 'userPassword', =20 > 'searchGuide', > # 'seeAlso', 'businessCategory', 'x121Address', =20 > 'registeredAddress', > # 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', > # 'teletexTerminalIdentifier', 'telephoneNumber', > # 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', > # 'postOfficeBox', 'postalCode', 'postalAddress', > # 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' =20= > types > # are described in [RFC4519]. The 'associatedName' attribute =20 > type is > # described in Section 2 of this document. > # > # Example: > # > # dn: dc=3Dcom > # objectClass: domain > # dc: com > # description: the .COM TLD > # > > # =20 > = --------------------------------------------------------------------------= > # 3.5. domainRelatedObject > # > # The 'domainRelatedObject' object class is used to define =20 > entries that > # represent DNS domains that are "equivalent" to an X.500 domain, =20= > e.g., > # an organization or organizational unit. > # > > objectclass ( 0.9.2342.19200300.100.4.17 > NAME 'domainRelatedObject' > SUP top AUXILIARY > MUST associatedDomain ) > > # > # The 'top' object class is described in [RFC4512]. The > # 'associatedDomain' attribute type is described in Section 2 of =20= > this > # document. > # > # Example: > # > # dn: dc=3Dexample,dc=3Dcom > # objectClass: organization > # objectClass: dcObject > # objectClass: domainRelatedObject > # dc: example > # associatedDomain: example.com > # o: Example Organization > # > # The 'organization' and 'dcObject' object classes and the 'dc' =20 > and 'o' > # attribute types are described in [RFC4519]. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.6. friendlyCountry > # > # The 'friendlyCountry' object class is used to define entries > # representing countries in the DIT. The object class is used to =20= > allow > # friendlier naming of countries than that allowed by the object =20= > class > # 'country' [RFC4519]. > # > > objectclass ( 0.9.2342.19200300.100.4.18 > NAME 'friendlyCountry' > SUP country STRUCTURAL > MUST co ) > > # > # The 'country' object class is described in [RFC4519]. The 'co' > # attribute type is described in Section 2 of this document. > # > # Example: > # > # dn: c=3DDE > # objectClass: country > # objectClass: friendlyCountry > # c: DE > # co: Deutschland > # co: Germany > # co: Federal Republic of Germany > # co: FRG > # > # The 'c' attribute type is described in [RFC4519]. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.7. rFC822LocalPart > # > # The 'rFC822LocalPart' object class is used to define entries that > # represent the local part of Internet mail addresses [RFC2822]. =20= > This > # treats the local part of the address as a 'domain' object. > # > > objectclass ( 0.9.2342.19200300.100.4.14 > NAME 'rFC822localPart' > SUP domain STRUCTURAL > MAY ( cn $ description $ destinationIndicator $ > facsimileTelephoneNumber $ internationaliSDNNumber $ > physicalDeliveryOfficeName $ postalAddress $ postalCode $ > postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ > seeAlso $ sn $ street $ telephoneNumber $ > teletexTerminalIdentifier $ telexNumber $ x121Address ) ) > > # > # The 'domain' object class is described in Section 3.4 of this > # document. The 'cn', 'description', 'destinationIndicator', > # 'facsimileTelephoneNumber', 'internationaliSDNNumber, > # 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', > # 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', > # 'seeAlso', 'sn, 'street', 'telephoneNumber', > # 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address' > # attribute types are described in [RFC4519]. > # > # Example: > # > # dn: dc=3Dkdz,dc=3Dexample,dc=3Dcom > # objectClass: domain > # objectClass: rFC822LocalPart > # dc: kdz > # associatedName: cn=3DKurt D. =20 > Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCOM > # > # The 'dc' attribute type is described in [RFC4519]. > # > > # =20 > = --------------------------------------------------------------------------= > # 3.8. room > # > # The 'room' object class is used to define entries representing =20= > rooms. > # The 'cn' (commonName) attribute SHOULD be used for naming =20 > entries of > # this object class. > # > > objectclass ( 0.9.2342.19200300.100.4.7 > NAME 'room' > SUP top STRUCTURAL > MUST cn > MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) > > # > # The 'top' object class is described in [RFC4512]. The 'cn', > # 'description', 'seeAlso', and 'telephoneNumber' attribute types =20= > are > # described in [RFC4519]. The 'roomNumber' attribute type is =20 > described > # in Section 2 of this document. > # > # dn: cn=3Dconference room,dc=3Dexample,dc=3Dcom > # objectClass: room > # cn: conference room > # telephoneNumber: +1 755 555 1111 > # > > # =20 > = --------------------------------------------------------------------------= > # 3.9. simpleSecurityObject > # > # The 'simpleSecurityObject' object class is used to require an =20 > entry > # to have a 'userPassword' attribute when the entry's structural =20= > object > # class does not require (or allow) the 'userPassword attribute'. > # > # (OpenLDAP-specific: Declared in core.schema) > # objectclass ( 0.9.2342.19200300.100.4.19 > # NAME 'simpleSecurityObject' > # SUP top AUXILIARY > # MUST userPassword ) > # > # The 'top' object class is described in [RFC4512]. The =20 > 'userPassword' > # attribute type is described in [RFC4519]. > # > # dn: dc=3Dkdz,dc=3DExample,dc=3DCOM > # objectClass: account > # objectClass: simpleSecurityObject > # uid: kdz > # userPassword: My Password > # seeAlso: cn=3DKurt D. Zeilenga,cn=3DPersons,dc=3DExample,dc=3DCO= M > # > > # =20 > = --------------------------------------------------------------------------= > # Object classes from RFC 1274 which are missing in RFC 4524 > # =20 > = --------------------------------------------------------------------------= > # > # 8.3.2. Pilot Person > # > # The PilotPerson object class is used as a sub-class of person, to > # allow the use of a number of additional attributes to be assigned =20= > to > # entries of object class person. > # > # pilotPerson OBJECT-CLASS > # SUBCLASS OF person > # MAY CONTAIN { > # userid, > # textEncodedORAddress, > # rfc822Mailbox, > # favouriteDrink, > # roomNumber, > # userClass, > # homeTelephoneNumber, > # homePostalAddress, > # secretary, > # personalTitle, > # preferredDeliveryMethod, > # businessCategory, > # janetMailbox, > # otherMailbox, > # mobileTelephoneNumber, > # pagerTelephoneNumber, > # organizationalStatus, > # mailPreferenceOption, > # personalSignature} > # ::=3D {pilotObjectClass 4} > # > > objectclass ( 0.9.2342.19200300.100.4.4 > NAME ( 'pilotPerson' 'newPilotPerson' ) > SUP person STRUCTURAL > MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ > favouriteDrink $ roomNumber $ userClass $ > homeTelephoneNumber $ homePostalAddress $ secretary $ > personalTitle $ preferredDeliveryMethod $ businessCategory $ > janetMailbox $ otherMailbox $ mobileTelephoneNumber $ > pagerTelephoneNumber $ organizationalStatus $ > mailPreferenceOption $ personalSignature ) ) > > # 8.3.9. DNS Domain > # > # The DNS Domain (Domain NameServer) object class is used to define > # entries for DNS domains. The usage of this object class is =20 > described > # in more detail in [3]. > # > # dNSDomain OBJECT-CLASS > # SUBCLASS OF domain > # MAY CONTAIN { > # ARecord, > # MDRecord, > # MXRecord, > # NSRecord, > # SOARecord, > # CNAMERecord} > # ::=3D {pilotObjectClass 15} > # > > objectclass ( 0.9.2342.19200300.100.4.15 > NAME 'dNSDomain' > SUP domain STRUCTURAL > MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ > SOARecord $ CNAMERecord ) ) > > > --------------080004030402080700020504-- > >

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 01 Jun '09

01 Jun '09

This is a multi-part message in MIME format. --------------080004030402080700020504 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Updated schema file cosine-update.schema attached. Note that some schema descriptions were copied from old cosine.schema to preserve backward compability since RFC 4524 does not contain all schema descriptions e.g. needed for 'pilotPerson'. Note that 'pilotPerson' is used as superior class for 'OpenLDAPperson'. Also some aliases were added to NAME of attribute type descriptions. IPR notice: This patch file is derived from OpenLDAP Software and RFC 4524 and RFC 1274. All of the modifications to OpenLDAP Software represented in the attached file were developed by Michael Ströder <michael(a)stroeder.com>. I have not assigned rights and/or interest in this work to any party. --------------080004030402080700020504 Content-Type: text/plain; name="cosine-update.schema" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cosine-update.schema" # RFC 4524: COSINE LDAP/X.500 Schema # $OpenLDAP: pkg/ldap/servers/slapd/schema/cosine.schema,v 1.26 2009/01/21 23:40:40 kurt Exp $ ## This work is part of OpenLDAP Software <http://www.openldap.org/>. ## ## Copyright 1998-2009 The OpenLDAP Foundation. ## All rights reserved. ## ## Redistribution and use in source and binary forms, with or without ## modification, are permitted only as authorized by the OpenLDAP ## Public License. ## ## A copy of this license is available in the file LICENSE in the ## top-level directory of the distribution or, alternatively, at ## <http://www.OpenLDAP.org/license.html>. # # RFC 4524: COSINE LDAP/X.500 Schema # This file is mainly based on the schema descriptions found in RFC 4524. # To preserve backwards compability with 'pilotPerson' schema some attribute # types and object classes not declared in RFC 4524 were copied from # (obsoleted) RFC 1274 and some attribute type descriptions were extended # with aliases for NAME. # # Depends on core.schema # -------------------------------------------------------------------------- # 2. COSINE Attribute Types # -------------------------------------------------------------------------- # # This section details COSINE attribute types for use in LDAP. # # -------------------------------------------------------------------------- # 2.1. associatedDomain # # The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181] # host names [RFC1123] that are associated with an object. That is, # values of this attribute should conform to the following ABNF: # # domain = root / label *( DOT label ) # root = SPACE # label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ] # LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z" # SPACE = %x20 ; space (" ") # HYPHEN = %x2D ; hyphen ("-") # DOT = %x2E ; period (".") # # For example, the entry in the DIT with a DN <DC=example,DC=com> might # have an associated domain of "example.com". # # (OpenLDAP-specific: Declared in core.schema) # attributetype ( 0.9.2342.19200300.100.1.37 # NAME 'associatedDomain' # EQUALITY caseIgnoreIA5Match # SUBSTR caseIgnoreIA5SubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are # described in [RFC4517]. # # Note that the directory will not ensure that values of this attribute # conform to the <domain> production provided above. It is the # application's responsibility to ensure that domains it stores in this # attribute are appropriately represented. # # Also note that applications supporting Internationalized Domain Names # SHALL use the ToASCII method [RFC3490] to produce <label> components # of the <domain> production. # -------------------------------------------------------------------------- # 2.2. associatedName # # The 'associatedName' attribute specifies names of entries in the # organizational DIT associated with a DNS domain [RFC1034][RFC2181]. # attributetype ( 0.9.2342.19200300.100.1.38 NAME 'associatedName' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.3. buildingName # # The 'buildingName' attribute specifies names of the buildings where # an organization or organizational unit is based, for example, "The # White House". # attributetype ( 0.9.2342.19200300.100.1.48 NAME 'buildingName' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.4. co # # The 'co' (Friendly Country Name) attribute specifies names of # countries in human-readable format, for example, "Germany" and # "Federal Republic of Germany". It is commonly used in conjunction # with the 'c' (Country Name) [RFC4519] attribute (whose values are # restricted to the two-letter codes defined in [ISO3166]). # attributetype ( 0.9.2342.19200300.100.1.43 NAME 'co' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.5. documentAuthor # # The 'documentAuthor' attribute specifies the distinguished names of # authors (or editors) of a document. For example, # attributetype ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.6. documentIdentifier # # The 'documentIdentifier' attribute specifies unique identifiers for a # document. A document may be identified by more than one unique # identifier. For example, RFC 3383 and BCP 64 are unique identifiers # that (presently) refer to the same document. # attributetype ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.7. documentLocation # # The 'documentLocation' attribute specifies locations of the document # original. # attributetype ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.8. documentPublisher # # The 'documentPublisher' attribute is the persons and/or organizations # that published the document. Documents that are jointly published # have one value for each publisher. # attributetype ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.9. documentTitle # # The 'documentTitle' attribute specifies the titles of a document. # Multiple values are allowed to accommodate both long and short # titles, or other situations where a document has multiple titles, for # example, "The Lightweight Directory Access Protocol Technical # Specification" and "The LDAP Technical Specification". # attributetype ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.10. documentVersion # # The 'documentVersion' attribute specifies the version information of # a document. # attributetype ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.11. drink # # The 'drink' (favouriteDrink) attribute specifies the favorite drinks # of an object (or person), for instance, "cola" and "beer". # attributetype ( 0.9.2342.19200300.100.1.5 NAME ( 'drink' 'favouriteDrink' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.12. homePhone # # The 'homePhone' (Home Telephone Number) attribute specifies home # telephone numbers (e.g., "+1 775 555 1234") associated with a person. # attributetype ( 0.9.2342.19200300.100.1.20 NAME ( 'homePhone' 'homeTelephoneNumber' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) # # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.13. homePostalAddress # # The 'homePostalAddress' attribute specifies home postal addresses for # an object. Each value should be limited to up to 6 directory strings # of 30 characters each. (Note: It is not intended that the directory # service enforce these limits.) # attributetype ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress' EQUALITY caseIgnoreListMatch SUBSTR caseIgnoreListSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) # # The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the # 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.14. host # # The 'host' attribute specifies host computers, generally by their # primary fully qualified domain name (e.g., my-host.example.com). # attributetype ( 0.9.2342.19200300.100.1.9 NAME 'host' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.15. info # # The 'info' attribute specifies any general information pertinent to # an object. This information is not necessarily descriptive of the # object. # # Applications should not attach specific semantics to values of this # attribute. The 'description' attribute [RFC4519] is available for # specifying descriptive information pertinent to an object. # attributetype ( 0.9.2342.19200300.100.1.4 NAME 'info' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.16. mail # # The 'mail' (rfc822mailbox) attribute type holds Internet mail # addresses in Mailbox [RFC2821] form (e.g., user(a)example.com). # # (OpenLDAP-specific: Declared in core.schema) # attributetype ( 0.9.2342.19200300.100.1.3 # NAME 'mail' # EQUALITY caseIgnoreIA5Match # SUBSTR caseIgnoreIA5SubstringsMatch # SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) # # The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the # 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are # described in [RFC4517]. # # Note that the directory will not ensure that values of this attribute # conform to the <Mailbox> production [RFC2821]. It is the # application's responsibility to ensure that domains it stores in this # attribute are appropriately represented. # # Additionally, the directory will compare values per the matching # rules named in the above attribute type description. As these rules # differ from rules that normally apply to <Mailbox> comparisons, # operational issues may arise. For example, the assertion # (mail=joe(a)example.com) will match "JOE(a)example.com" even though the # <local-parts> differ. Also, where a user has two <Mailbox>es whose # addresses differ only by case of the <local-part>, both cannot be # listed as values of the user's mail attribute (as they are considered # equal by the 'caseIgnoreIA5Match' rule). # # Also note that applications supporting internationalized domain names # SHALL use the ToASCII method [RFC3490] to produce <sub-domain> # components of the <Mailbox> production. # # -------------------------------------------------------------------------- # 2.17. manager # # The 'manager' attribute specifies managers, by distinguished name, of # the person (or entity). # attributetype ( 0.9.2342.19200300.100.1.10 NAME 'manager' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.18. mobile # # The 'mobile' (mobileTelephoneNumber) attribute specifies mobile # telephone numbers (e.g., "+1 775 555 6789") associated with a person # (or entity). # attributetype ( 0.9.2342.19200300.100.1.41 NAME ( 'mobile' 'mobileTelephoneNumber' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) # # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.19. organizationalStatus # # The 'organizationalStatus' attribute specifies categories by which a # person is often referred to in an organization. Examples of usage in # academia might include "undergraduate student", "researcher", # "professor", and "staff". Multiple values are allowed where the # person is in multiple categories. # # Directory administrators and application designers SHOULD consider # carefully the distinctions between this and the 'title' and # 'userClass' attributes. # attributetype ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.20. pager # # The 'pager' (pagerTelephoneNumber) attribute specifies pager # telephone numbers (e.g., "+1 775 555 5555") for an object. # attributetype ( 0.9.2342.19200300.100.1.42 NAME ( 'pager' 'pagerTelephoneNumber' ) EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) # # The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the # 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are # described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.21. personalTitle # # The 'personalTitle' attribute specifies personal titles for a person. # Examples of personal titles are "Frau", "Dr.", "Herr", and # "Professor". # attributetype ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.22. roomNumber # # The 'roomNumber' attribute specifies the room number of an object. # During periods of renumbering, or in other circumstances where a room # has multiple valid room numbers associated with it, multiple values # may be provided. Note that the 'cn' (commonName) attribute type # SHOULD be used for naming room objects. # attributetype ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # 2.23. secretary # # The 'secretary' attribute specifies secretaries and/or administrative # assistants, by distinguished name. # attributetype ( 0.9.2342.19200300.100.1.21 NAME 'secretary' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) # # The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the # 'distinguishedNameMatch' rule are described in [RFC4517]. # # -------------------------------------------------------------------------- # 2.24. uniqueIdentifier # # The 'uniqueIdentifier' attribute specifies a unique identifier for an # object represented in the Directory. The domain within which the # identifier is unique and the exact semantics of the identifier are # for local definition. For a person, this might be an institution- # wide payroll number. For an organizational unit, it might be a # department code. # attributetype ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # Note: X.520 also describes an attribute called 'uniqueIdentifier' # (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP # [RFC4519]. The attribute detailed here ought not be confused # with 'x500UniqueIdentifier'. # # -------------------------------------------------------------------------- # 2.25. userClass # # The 'userClass' attribute specifies categories of computer or # application user. The semantics placed on this attribute are for # local interpretation. Examples of current usage of this attribute in # academia are "student", "staff", and "faculty". Note that the # 'organizationalStatus' attribute type is now often preferred, as it # makes no distinction between persons as opposed to users. # attributetype ( 0.9.2342.19200300.100.1.8 NAME 'userClass' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # # The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the # 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described # in [RFC4517]. # # -------------------------------------------------------------------------- # Attribute types from RFC 1274 which are missing in RFC 4524 # -------------------------------------------------------------------------- # # 9.3.2. Text Encoded O/R Address # # The Text Encoded O/R Address attribute type specifies a text encoding # of an X.400 O/R address, as specified in RFC 987. The use of this # attribute is deprecated as the attribute is intended for interim use # only. This attribute will be the first candidate for the attribute # expiry mechanisms! # # textEncodedORAddress ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # caseIgnoreStringSyntax # (SIZE (1 .. ub-text-encoded-or-address)) # ::= {pilotAttributeType 2} # attributetype ( 0.9.2342.19200300.100.1.2 NAME 'textEncodedORAddress' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) # -------------------------------------------------------------------------- # 9.3.7. Photo # # The Photo attribute type specifies a "photograph" for an object. # This should be encoded in G3 fax as explained in recommendation T.4, # with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as # defined in X.420. # # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules # information-objects } # # photo ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # CHOICE { # g3-facsimile [3] G3FacsimileBodyPart # } # (SIZE (1 .. ub-photo)) # ::= {pilotAttributeType 7} # attributetype ( 0.9.2342.19200300.100.1.7 NAME 'photo' DESC 'RFC1274: photo (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23{25000} ) # -------------------------------------------------------------------------- # 9.3.18. Other Mailbox # # The Other Mailbox attribute type specifies values for electronic # mailbox types other than X.400 and rfc822. # # otherMailbox ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # SEQUENCE { # mailboxType PrintableString, -- e.g. Telemail # mailbox IA5String -- e.g. X378:Joe # } # ::= {pilotAttributeType 22} # attributetype ( 0.9.2342.19200300.100.1.22 NAME 'otherMailbox' SYNTAX 1.3.6.1.4.1.1466.115.121.1.39 ) # -------------------------------------------------------------------------- # 9.3.22. DNS ARecord # # The A Record attribute type specifies a type A (Address) DNS resource # record [6] [7]. # # aRecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 26} # ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.26 NAME 'aRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ## missing from RFC1274 ## incorrect syntax? attributetype ( 0.9.2342.19200300.100.1.27 NAME 'mDRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.23. MX Record # # The MX Record attribute type specifies a type MX (Mail Exchange) DNS # resource record [6] [7]. # # mXRecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 28} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.28 NAME 'mXRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.24. NS Record # # The NS Record attribute type specifies an NS (Name Server) DNS # resource record [6] [7]. # # nSRecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 29} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.29 NAME 'nSRecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.25. SOA Record # # The SOA Record attribute type specifies a type SOA (Start of # Authority) DNS resorce record [6] [7]. # # sOARecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # DNSRecordSyntax # ::= {pilotAttributeType 30} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.30 NAME 'sOARecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.26. CNAME Record # # The CNAME Record attribute type specifies a type CNAME (Canonical # Name) DNS resource record [6] [7]. # # cNAMERecord ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # iA5StringSyntax # ::= {pilotAttributeType 31} # ## incorrect syntax!! attributetype ( 0.9.2342.19200300.100.1.31 NAME 'cNAMERecord' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) # -------------------------------------------------------------------------- # 9.3.36. Janet Mailbox # # The Janet Mailbox attribute type specifies an electronic mailbox # attribute following the syntax specified in the Grey Book of the # Coloured Book series. This attribute is intended for the convenience # of U.K users unfamiliar with rfc822 and little-endian mail addresses. # Entries using this attribute MUST also include an rfc822Mailbox # attribute. # # janetMailbox ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # caseIgnoreIA5StringSyntax # (SIZE (1 .. ub-janet-mailbox)) # ::= {pilotAttributeType 46} # attributetype ( 0.9.2342.19200300.100.1.46 NAME 'janetMailbox' DESC 'RFC1274: Janet mailbox' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) # -------------------------------------------------------------------------- # 9.3.37. Mail Preference Option # # An attribute to allow users to indicate a preference for inclusion of # their names on mailing lists (electronic or physical). The absence # of such an attribute should be interpreted as if the attribute was # present with value "no-list-inclusion". This attribute should be # interpreted by anyone using the directory to derive mailing lists, # and its value respected. # # mailPreferenceOption ATTRIBUTE # WITH ATTRIBUTE-SYNTAX ENUMERATED { # no-list-inclusion(0), # any-list-inclusion(1), -- may be added to any lists # professional-list-inclusion(2) # -- may be added to lists # -- which the list provider # -- views as related to the # -- users professional inter- # -- ests, perhaps evaluated # -- from the business of the # -- organisation or keywords # -- in the entry. # } # ::= {pilotAttributeType 47} # attributetype ( 0.9.2342.19200300.100.1.47 NAME 'mailPreferenceOption' DESC 'RFC1274: mail preference option' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) # -------------------------------------------------------------------------- # 9.3.43. Personal Signature # # The Personal Signature attribute type allows for a representation of # a person's signature. This should be encoded in G3 fax as explained # in recommendation T.4, with an ASN.1 wrapper to make it compatible # with an X.400 BodyPart as defined in X.420. # # IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules # information-objects } # # personalSignature ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # CHOICE { # g3-facsimile [3] G3FacsimileBodyPart # } # (SIZE (1 .. ub-personal-signature)) # ::= {pilotAttributeType 53} # attributetype ( 0.9.2342.19200300.100.1.53 NAME 'personalSignature' DESC 'RFC1274: Personal Signature (G3 fax)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.23 ) # -------------------------------------------------------------------------- # 9.3.45. Audio # # The Audio attribute type allows the storing of sounds in the # Directory. The attribute uses a u-law encoded sound file as used by # the "play" utility on a Sun 4. This is an interim format. # # audio ATTRIBUTE # WITH ATTRIBUTE-SYNTAX # Audio # (SIZE (1 .. ub-audio)) # ::= {pilotAttributeType 55} # attributetype ( 0.9.2342.19200300.100.1.55 NAME 'audio' DESC 'RFC1274: audio (u-law)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.4{25000} ) # -------------------------------------------------------------------------- # 3. COSINE Object Classes # -------------------------------------------------------------------------- # # This section details COSINE object classes for use in LDAP. # # -------------------------------------------------------------------------- # 3.1. account # # The 'account' object class is used to define entries representing # computer accounts. The 'uid' attribute SHOULD be used for naming # entries of this object class. # objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST uid MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) # # The 'top' object class is described in [RFC4512]. The 'description', # 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in # [RFC4519]. The 'host' attribute type is described in Section 2 of # this document. # # Example: # # dn: uid=kdz,cn=Accounts,dc=Example,dc=COM # objectClass: account # uid: kdz # seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # # -------------------------------------------------------------------------- # 3.2. document # # The 'document' object class is used to define entries that represent # documents. # objectclass ( 0.9.2342.19200300.100.4.6 NAME 'document' SUP top STRUCTURAL MUST documentIdentifier MAY ( cn $ description $ seeAlso $ l $ o $ ou $ documentTitle $ documentVersion $ documentAuthor $ documentLocation $ documentPublisher ) ) # # The 'top' object class is described in [RFC4512]. The 'cn', # 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are # described in [RFC4519]. The 'documentIdentifier', 'documentTitle', # 'documentVersion', 'documentAuthor', 'documentLocation', and # 'documentPublisher' attribute types are described in Section 2 of # this document. # # Example: # # dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM # objectClass: document # documentIdentifier: RFC 4524 # documentTitle: COSINE LDAP/X.500 Schema # documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt # documentPublisher: Internet Engineering Task Force # description: A collection of schema elements for use in LDAP # description: Obsoletes RFC 1274 # seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM # seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM # # -------------------------------------------------------------------------- # 3.3. documentSeries # # The 'documentSeries' object class is used to define an entry that # represents a series of documents (e.g., The Request For Comments # memos). # objectclass ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries' SUP top STRUCTURAL MUST cn MAY ( description $ l $ o $ ou $ seeAlso $ telephonenumber ) ) # # The 'top' object class is described in [RFC4512]. The 'description', # 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are # described in [RFC4519]. # # Example: # # dn: cn=RFC,dc=Example,dc=COM # objectClass: documentSeries # cn: Request for Comments # cn: RFC # description: a series of memos about the Internet # # -------------------------------------------------------------------------- # 3.4. domain # # The 'domain' object class is used to define entries that represent # DNS domains for objects that are not organizations, organizational # units, or other kinds of objects more appropriately defined using an # object class specific to the kind of object being defined (e.g., # 'organization', 'organizationUnit'). # # The 'dc' attribute should be used for naming entries of the 'domain' # object class. # objectclass ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL MUST dc MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description $ o $ associatedName ) ) # # The 'top' object class and the 'dc', 'userPassword', 'searchGuide', # 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress', # 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber', # 'teletexTerminalIdentifier', 'telephoneNumber', # 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street', # 'postOfficeBox', 'postalCode', 'postalAddress', # 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types # are described in [RFC4519]. The 'associatedName' attribute type is # described in Section 2 of this document. # # Example: # # dn: dc=com # objectClass: domain # dc: com # description: the .COM TLD # # -------------------------------------------------------------------------- # 3.5. domainRelatedObject # # The 'domainRelatedObject' object class is used to define entries that # represent DNS domains that are "equivalent" to an X.500 domain, e.g., # an organization or organizational unit. # objectclass ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' SUP top AUXILIARY MUST associatedDomain ) # # The 'top' object class is described in [RFC4512]. The # 'associatedDomain' attribute type is described in Section 2 of this # document. # # Example: # # dn: dc=example,dc=com # objectClass: organization # objectClass: dcObject # objectClass: domainRelatedObject # dc: example # associatedDomain: example.com # o: Example Organization # # The 'organization' and 'dcObject' object classes and the 'dc' and 'o' # attribute types are described in [RFC4519]. # # -------------------------------------------------------------------------- # 3.6. friendlyCountry # # The 'friendlyCountry' object class is used to define entries # representing countries in the DIT. The object class is used to allow # friendlier naming of countries than that allowed by the object class # 'country' [RFC4519]. # objectclass ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry' SUP country STRUCTURAL MUST co ) # # The 'country' object class is described in [RFC4519]. The 'co' # attribute type is described in Section 2 of this document. # # Example: # # dn: c=DE # objectClass: country # objectClass: friendlyCountry # c: DE # co: Deutschland # co: Germany # co: Federal Republic of Germany # co: FRG # # The 'c' attribute type is described in [RFC4519]. # # -------------------------------------------------------------------------- # 3.7. rFC822LocalPart # # The 'rFC822LocalPart' object class is used to define entries that # represent the local part of Internet mail addresses [RFC2822]. This # treats the local part of the address as a 'domain' object. # objectclass ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart' SUP domain STRUCTURAL MAY ( cn $ description $ destinationIndicator $ facsimileTelephoneNumber $ internationaliSDNNumber $ physicalDeliveryOfficeName $ postalAddress $ postalCode $ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $ seeAlso $ sn $ street $ telephoneNumber $ teletexTerminalIdentifier $ telexNumber $ x121Address ) ) # # The 'domain' object class is described in Section 3.4 of this # document. The 'cn', 'description', 'destinationIndicator', # 'facsimileTelephoneNumber', 'internationaliSDNNumber, # 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode', # 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress', # 'seeAlso', 'sn, 'street', 'telephoneNumber', # 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address' # attribute types are described in [RFC4519]. # # Example: # # dn: dc=kdz,dc=example,dc=com # objectClass: domain # objectClass: rFC822LocalPart # dc: kdz # associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # # The 'dc' attribute type is described in [RFC4519]. # # -------------------------------------------------------------------------- # 3.8. room # # The 'room' object class is used to define entries representing rooms. # The 'cn' (commonName) attribute SHOULD be used for naming entries of # this object class. # objectclass ( 0.9.2342.19200300.100.4.7 NAME 'room' SUP top STRUCTURAL MUST cn MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) ) # # The 'top' object class is described in [RFC4512]. The 'cn', # 'description', 'seeAlso', and 'telephoneNumber' attribute types are # described in [RFC4519]. The 'roomNumber' attribute type is described # in Section 2 of this document. # # dn: cn=conference room,dc=example,dc=com # objectClass: room # cn: conference room # telephoneNumber: +1 755 555 1111 # # -------------------------------------------------------------------------- # 3.9. simpleSecurityObject # # The 'simpleSecurityObject' object class is used to require an entry # to have a 'userPassword' attribute when the entry's structural object # class does not require (or allow) the 'userPassword attribute'. # # (OpenLDAP-specific: Declared in core.schema) # objectclass ( 0.9.2342.19200300.100.4.19 # NAME 'simpleSecurityObject' # SUP top AUXILIARY # MUST userPassword ) # # The 'top' object class is described in [RFC4512]. The 'userPassword' # attribute type is described in [RFC4519]. # # dn: dc=kdz,dc=Example,dc=COM # objectClass: account # objectClass: simpleSecurityObject # uid: kdz # userPassword: My Password # seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM # # -------------------------------------------------------------------------- # Object classes from RFC 1274 which are missing in RFC 4524 # -------------------------------------------------------------------------- # # 8.3.2. Pilot Person # # The PilotPerson object class is used as a sub-class of person, to # allow the use of a number of additional attributes to be assigned to # entries of object class person. # # pilotPerson OBJECT-CLASS # SUBCLASS OF person # MAY CONTAIN { # userid, # textEncodedORAddress, # rfc822Mailbox, # favouriteDrink, # roomNumber, # userClass, # homeTelephoneNumber, # homePostalAddress, # secretary, # personalTitle, # preferredDeliveryMethod, # businessCategory, # janetMailbox, # otherMailbox, # mobileTelephoneNumber, # pagerTelephoneNumber, # organizationalStatus, # mailPreferenceOption, # personalSignature} # ::= {pilotObjectClass 4} # objectclass ( 0.9.2342.19200300.100.4.4 NAME ( 'pilotPerson' 'newPilotPerson' ) SUP person STRUCTURAL MAY ( userid $ textEncodedORAddress $ rfc822Mailbox $ favouriteDrink $ roomNumber $ userClass $ homeTelephoneNumber $ homePostalAddress $ secretary $ personalTitle $ preferredDeliveryMethod $ businessCategory $ janetMailbox $ otherMailbox $ mobileTelephoneNumber $ pagerTelephoneNumber $ organizationalStatus $ mailPreferenceOption $ personalSignature ) ) # 8.3.9. DNS Domain # # The DNS Domain (Domain NameServer) object class is used to define # entries for DNS domains. The usage of this object class is described # in more detail in [3]. # # dNSDomain OBJECT-CLASS # SUBCLASS OF domain # MAY CONTAIN { # ARecord, # MDRecord, # MXRecord, # NSRecord, # SOARecord, # CNAMERecord} # ::= {pilotObjectClass 15} # objectclass ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL MAY ( ARecord $ MDRecord $ MXRecord $ NSRecord $ SOARecord $ CNAMERecord ) ) --------------080004030402080700020504--

1 0

Re: (ITS#6156) Translucent overlay not working correctly when not asking for attributes included in search filter
by isaac＠ebox-platform.com 30 May '09

30 May '09

> But it will fail if it's an 'and' and both parts match (which was my > original case). This one fails: > $LDAPSEARCH -H $URI2 -b "o=translucent" > "(|(employeeType=foo)(carlicense=right))" preferredLanguage > > $SEARCHOUT 2>&1 Sorry, I meant to write this in the last one: $LDAPSEARCH -H $URI2 -b "o=translucent" "(&(employeeType=consultant)(carlicense=right))" preferredLanguage > $SEARCHOUT 2>&1 -- Isaac Clerencia - Developer isaac(a)ebox-platform.com http://people.warp.es/~isaac/blog/ eBox - Managing Computer Networks Was Never This Easy Download eBox at www.ebox-platform.com

1 0

Re: (ITS#6156) Translucent overlay not working correctly when not asking for attributes included in search filter
by isaac＠ebox-platform.com 30 May '09

30 May '09

I also just realized that if the part that matches is the local filter part, then it works, thus, this one works correctly: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=consultant)(carlicense=aaaa))" preferredLanguage > $SEARCHOUT 2>&1 But it will fail if it's an 'and' and both parts match (which was my original case). This one fails: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" preferredLanguage > $SEARCHOUT 2>&1 -- Isaac Clerencia - Developer isaac(a)ebox-platform.com http://people.warp.es/~isaac/blog/ eBox - Managing Computer Networks Was Never This Easy Download eBox at www.ebox-platform.com

1 0

(ITS#6156) Translucent overlay not working correctly when not asking for attributes included in search filter
by isaac＠ebox-platform.com 30 May '09

30 May '09

Full_Name: Isaac Clerencia Version: 2.4.15 OS: Ubuntu URL: Submission from: (NULL) (88.26.177.14) The translucent overlay doesn't return entries if any of the attributes included in the search filter is remote and is not requested. The easiest way to reproduce this is modifying slightly test034-translucent. The ldapsearch in line 786 looks originally like this: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" > $SEARCHOUT 2>&1 The original test works correctly because it requests all the attributes, including carLicense. If we change it to request a specific attribute such as preferredLanguage: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" preferredLanguage > $SEARCHOUT 2>&1 the test fails. If we just ask for the carLicense attribute, the test passes: $LDAPSEARCH -H $URI2 -b "o=translucent" "(|(employeeType=foo)(carlicense=right))" carLicense > $SEARCHOUT 2>&1 As long as carLicense is included in the request attributes the test will pass, otherwise it will fail.

1 0

(ITS#6155) Segfault during Heimdal's kadmin -l init Realm
by dewayne_freebsd＠yahoo.com 30 May '09

30 May '09

Full_Name: Dewayne Geraghty Version: 2.4.16 OS: FreeBSD 7.2R URL: http://www.consciuminternational.com.au/ldap Submission from: (NULL) (58.172.112.108) FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16 Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend. Segmentation fault during kadmin -l init HS slapd and heimdal work correctly, independently. slapd is running at debug 1019, logs are at enclosed URL along with the full gdb trace, and configuration files. If I can assist please advise. This is a single Pentium CPU, and gcc flags CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5 -DDO_SAMBA -DHAVE_OPENSSL #0 0x286447b6 in memmove () from /lib/libc.so.7 #1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6 #2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6 #3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6 #4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6 #5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6 #6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6 #7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0, entry=0xbfbfe790) at hdb-ldap.c:1600 #8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at create_s.c:182 #9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at common_glue.c:64 #10 0x0804e496 in ?? () #11 0x2871b0c0 in ?? () #12 0xbfbfea3c in ?? () #13 0x00000011 in ?? () #14 0xbfbfe830 in ?? () #15 0x28084000 in ?? () #16 0x28084200 in ?? () #17 0x28084400 in ?? () #18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #19 0x0804e8c9 in ?? () #20 0x2870c0e0 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x2870c085 in ?? () #25 0x00000000 in ?? () #26 0x28650030 in ?? () from /lib/libc.so.7 I have spent weeks trying to get this to work. (Because I'm using and modifing the FreeBSD ports system to build and use the latest version of LDAP and Heimdal.)

1 0

(ITS#6154) response/cleanup callback mismatch
by h.b.furuseth＠usit.uio.no 29 May '09

29 May '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard result.c:slap_send_search_entry() calls slap_cleanup_play() without having called slap_response_play() if backend_operational() failed. This breaks back-relay's cleanup handler relay_back_swap_bd() - or rather, I suppose it makes that handler break cleanup handlers called after it. It restores op->o_bd from o_callback->sc_private, which was supposedly set by the o_callback->sc_response call.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 29 May '09

29 May '09

Pierangelo Masarati wrote: > hyc(a)OpenLDAP.org wrote: > >> Some ideas that came out of discussions at the Ubuntu Developer Summit this >> week... >> >> It would be nice for pcache to detect when connectivity to the remote server has >> been lost. In that case, cache expiration should be stopped, and the cache >> contents should remain intact until connectivity is restored. > > Sounds fair. > >> Also, when connectivity is restored, pcache should explicitly refresh all the >> entries it currently holds, rather than allowing them to be immediately expired. > > Sounds an overkill? Perhaps. It is certainly likely that any entries in the cache will be stale; when connectivity is restored and expiration is re-enabled the cached entries will probably be immediately removed. While it will be no problem to retrieve the entries again since the network is available, the concern is that only a subset of the originally cached entries will be retrieved through normal user activity, but the entire set needs to be preserved in anticipation of the next disconnect event. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6152) proxycache enhancements
by masarati＠aero.polimi.it 29 May '09

29 May '09

hyc(a)OpenLDAP.org wrote: > Some ideas that came out of discussions at the Ubuntu Developer Summit this > week... > > It would be nice for pcache to detect when connectivity to the remote server has > been lost. In that case, cache expiration should be stopped, and the cache > contents should remain intact until connectivity is restored. Sounds fair. > Also, when connectivity is restored, pcache should explicitly refresh all the > entries it currently holds, rather than allowing them to be immediately expired. Sounds an overkill? Cheers, p.

1 0

Re: (ITS#6152) proxycache enhancements
by rhafer＠suse.de 29 May '09

29 May '09

Am Donnerstag 28 Mai 2009 18:29:55 schrieb hyc(a)openldap.org: > Full_Name: Howard Chu > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.67.104.102) > Submitted by: hyc > > > Some ideas that came out of discussions at the Ubuntu Developer Summit this > week... > > It would be nice for pcache to detect when connectivity to the remote > server has been lost. In that case, cache expiration should be stopped, and > the cache contents should remain intact until connectivity is restored. Yes that sound reasonable. It's probably also worth to think about a mechanism to explicitly set pcache to "offline" mode. That way on a client machine a hook could be provided for e.g. NetworkManager to bring pcache to offline mode immediately when the network goes offline. That mechanism could either be offered through back-config (back-monitor as for readonly?) and/or through the nssov Socket as that would most probably be the main user of this disconnected pcache mode. > Also, when connectivity is restored, pcache should explicitly refresh all > the entries it currently holds, rather than allowing them to be immediately > expired. -- Ralf

1 0

(ITS#6153) Segfault during Heimdal's kadmin -l init Realm
by dewayne_freebsd＠yahoo.com 29 May '09

29 May '09

Full_Name: Dewayne Geraghty Version: 2.4.16 OS: FreeBSD 7.2R URL: http://www.consciuminternational.com.au/ldap Submission from: (NULL) (58.172.112.108) FreeBSD version 7.2; Heimdal V1.2.1; OpenLDAP 2.4.16 Heimdal and OpenLDAP are built for heimdal to use OpenLDAP as backend. Segmentation fault during kadmin -l init HS slapd and heimdal work correctly, independently. slapd is running at debug 1019, logs are at enclosed URL along with the full gdb trace, and configuration files. If I can assist please advise. This is a single Pentium CPU, and gcc flags CFLAGS= -pipe -g3 -ggdb3 -O0 -march=pentium4 -mtune=pentium4 -DDO_KRB5 -DDO_SAMBA -DHAVE_OPENSSL #0 0x286447b6 in memmove () from /lib/libc.so.7 #1 0x282a10e8 in ber_write () from /usr/local/lib/liblber-2.4.so.6 #2 0x2829ebf7 in ber_put_ostring () from /usr/local/lib/liblber-2.4.so.6 #3 0x2829ed14 in ber_put_berval () from /usr/local/lib/liblber-2.4.so.6 #4 0x2829faca in ber_printf () from /usr/local/lib/liblber-2.4.so.6 #5 0x2821a0ee in ldap_add_ext () from /usr/local/lib/libldap-2.4.so.6 #6 0x2821a378 in ldap_add_ext_s () from /usr/local/lib/libldap-2.4.so.6 #7 0x280ad493 in LDAP_store (context=0x287050b0, db=0x2870e040, flags=0, entry=0xbfbfe790) at hdb-ldap.c:1600 #8 0x2809875b in kadm5_s_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at create_s.c:182 #9 0x2808da1c in kadm5_create_principal (server_handle=0x2871b0c0, princ=0xbfbfea3c, mask=17, password=0xbfbfe830 "bQdxg9drKf") at common_glue.c:64 #10 0x0804e496 in ?? () #11 0x2871b0c0 in ?? () #12 0xbfbfea3c in ?? () #13 0x00000011 in ?? () #14 0xbfbfe830 in ?? () #15 0x28084000 in ?? () #16 0x28084200 in ?? () #17 0x28084400 in ?? () #18 0x285b3c8d in _pthread_mutex_init_calloc_cb () from /lib/libc.so.7 #19 0x0804e8c9 in ?? () #20 0x2870c0e0 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x2870c085 in ?? () #25 0x00000000 in ?? () #26 0x28650030 in ?? () from /lib/libc.so.7 I have spent weeks trying to get this to work. (Because I'm using and modifing the FreeBSD ports system to build and use the latest version of LDAP and Heimdal.)

1 0

(ITS#6152) proxycache enhancements
by hyc＠OpenLDAP.org 28 May '09

28 May '09

Full_Name: Howard Chu Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.102) Submitted by: hyc Some ideas that came out of discussions at the Ubuntu Developer Summit this week... It would be nice for pcache to detect when connectivity to the remote server has been lost. In that case, cache expiration should be stopped, and the cache contents should remain intact until connectivity is restored. Also, when connectivity is restored, pcache should explicitly refresh all the entries it currently holds, rather than allowing them to be immediately expired.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 28 May '09

28 May '09

Andrew Bartlett wrote: > On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: >> abartlet(a)samba.org wrote: >>> Full_Name: Andrew Bartlett >>> Version: CVS HEAD >>> OS: Fedora 10 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (59.167.251.137) >>> >>> >>> Samba4's provision and 'make test' seems to create some internal situation in >>> OpenLDAP slapd where it will not accept any more connections over ldapi:/// >>> >>> This is best seen by building Samba4, and running >>> >>> TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test >>> >>> The slapd does not crash, but simply stops accepting new connections. Samba4 >>> currently then crashes due to some other bug (the LDAP backend not responding is >>> clearly untested code in Samba4). >>> >>> It isn't a Samba4 client bug, as ldapsearch also fails to respond. >>> >>> This seems very, very similar to ITS#5261 >> >> Further testing with Andrew's kvm image shows the hang only occurs when Cyrus >> SASL's libsasldb2.so plugin is present. I always remove that plugin from my >> installs, since I only use in-directory SASL secrets. That's probably why I >> wasn't seeing the reported behavior before. >> >> Also a note - it's still not clear we've been talking about the same thing up >> to this point. Even when the samba test suite hangs, I see that ldapsearch >> still works fine against slapd. At any rate, currently all of the samba4 tests >> pass for me. > > Hmm. Using that KVM image, with the libsasldb moved aside (and with it > left in place), I still get errors. > > However, there is an important difference: Where previously, once it > locked up nothing proceeded, now it proceeds - as if the failure is > temporary now. The error has changed too - instead of a failure to > connect, it is an inability to successfully read the rootDSE. > > I agree, we might be jumping at different shadows here, but your patches > did fix something... I see what you're describing now, with the kvm set with 2 CPUs. It appears to be a bug caused by the recent patch for connection_hangup() processing. Running slapd with -d15 in your test shows that a connection is closed shortly after being established and becoming readable. The bug is (probably) that we queued the reader but processed the hangup immediately, thus closing the connection before the reader executes. I'm not exactly sure why this is causing the problem on your test, since it looks like your client is closing the socket before waiting for the reply. But certainly this is the right area. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.80.206) cosine.schema is still based on obsoleted RFC 1274. It should be updated to RFC 4524.

1 0

Re: (ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Pierangelo Masarati wrote: > Added to HEAD. Please test. Wow! This was fast! It simply works. I want it in 2.4.17. ;-) Ciao, Michael.

1 0

Re: (ITS#6150) schema compliance checking tool
by masarati＠aero.polimi.it 28 May '09

28 May '09

Added to HEAD. Please test. p.

1 0

(ITS#6150) schema compliance checking tool
by michael＠stroeder.com 28 May '09

28 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.68.118) masarati(a)aero.polimi.it wrote: > Comes to mind that something like a schema compliance checking tool, > either off- or on-line could be useful. Sort of a "slapschema" that > checks the schema compliance of each entry (matching a filter or > within a subtree specification) in a given database. The result could contain the DNs of non-compliant entries each with the diagnostic message which would have been returned to a client adding such a non-compliant entry.

1 0

(ITS#6149) ldapsearch is not really script-friendly (patch included)
by bugreporter＠udmvt.ru 28 May '09

28 May '09

Full_Name: Alexey Version: 2.4.15 (LDAP library: OpenLDAP 20415) OS: Debian GNU/Linux URL: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch Submission from: (NULL) (78.85.1.13) Good day, everyone. ldapsearch have such important (mis)feature, like output format conforming to LDIF standard in some or other way. You should already know, that line length in LDIF-output is limited to 76 characters and if line is larger, it is wrapped with space-padding. Also output is sometimes base64 encoded, based on it's "printability". Printability is tested, using single-byte functions, like isgraph(), but when values is multibyte encoded with UTF-8, that sometimes produce random results. That together makes ldapsearch very script-unfriendly and here is why: to limit randomness in output's encoding, one would use -tt switch to always write field values to files and then use some simple script to parse the output and substitute file urls with their contents. But here comes to play line length limit, that will sometimes wrap urls for fields with long names (that is common for AD). Here is example: msExchHomeServerName:< file:///tmp/ldapsearch-msExchHomeServerName-ZhHdx2 msExchMailboxSecurityDescriptor:< file:///tmp/ldapsearch-msExchMailboxSecurit yDescriptor-c4gGc1 msExchUserAccountControl:< file:///tmp/ldapsearch-msExchUserAccountControl-FM UbSZ msExchMailboxGuid:< file:///tmp/ldapsearch-msExchMailboxGuid-6bLIxY End of example. That introduces extra unneeded complexity in otherwise simple script, since now it should parse LDIF, combine whole lines from broken ones, etc. Making it no longer an one-line script. Since wrapping of -tt output is nonsense, but changing that may seem unfeasible for some of you, let me suggest additional option -ttt, that does the same as -tt, but without line wrapping (perhaps, violating some standard). Patch is here, as your ITS asks: http://bugreport.udmvt.ru/attachment/ldapsearch-ttt.patch PS: manpage does not changed to reflect additional option Thanks a lot.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 27 May '09

27 May '09

--=-0SnOgocYLpYqWd2pGoMe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (59.167.251.137) > > > > > > Samba4's provision and 'make test' seems to create some internal situat= ion in > > OpenLDAP slapd where it will not accept any more connections over ldapi= :/// > > > > This is best seen by building Samba4, and running > > > > TEST_LDAP=3Dyes OPENLDAP_ROOT=3D/usr/local make test > > > > The slapd does not crash, but simply stops accepting new connections. = Samba4 > > currently then crashes due to some other bug (the LDAP backend not resp= onding is > > clearly untested code in Samba4). > > > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > > > This seems very, very similar to ITS#5261 >=20 > Further testing with Andrew's kvm image shows the hang only occurs when C= yrus=20 > SASL's libsasldb2.so plugin is present. I always remove that plugin from = my=20 > installs, since I only use in-directory SASL secrets. That's probably why= I=20 > wasn't seeing the reported behavior before. >=20 > Also a note - it's still not clear we've been talking about the same thin= g up=20 > to this point. Even when the samba test suite hangs, I see that ldapsearc= h=20 > still works fine against slapd. At any rate, currently all of the samba4 = tests=20 > pass for me. Hmm. Using that KVM image, with the libsasldb moved aside (and with it left in place), I still get errors. =20 However, there is an important difference: Where previously, once it locked up nothing proceeded, now it proceeds - as if the failure is temporary now. The error has changed too - instead of a failure to connect, it is an inability to successfully read the rootDSE.=20 I agree, we might be jumping at different shadows here, but your patches did fix something... Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-0SnOgocYLpYqWd2pGoMe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKHeuvz4A8Wyi0NrsRAoaGAJ9olpo9+ni006pt9kK5CkXJObYNCQCgorgP DswBOLRtdrlhFHibmX4XrC4= =bjw6 -----END PGP SIGNATURE----- --=-0SnOgocYLpYqWd2pGoMe--

1 0

Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 27 May '09

27 May '09

hyc(a)symas.com writes: >Hallvard B Furuseth wrote: >> The send_ldap_response() fix is still incomplete: [Reversing the quoteed message] >> Also, this: >> rc = rs->sr_err; >> if ( rc == SLAPD_ABANDON&& op->o_cancel ) >> rc = LDAP_CANCELLED; >> will send a negative result code (SLAPD_ABANDON) if !o_cancel. > > No, it won't. That is all bypassed at the top of the function. If so, the quoted op->o_cancel test could be skipped. But an overlay could set rs->sr_err = SLAPD_ABANDON during slap_response_play(). Though that ought to mean o_abandon is set, so send_ldap_ber() will drop the message. So you're right after all that it won't be sent. >> Note, not just when the function itself sets rc = LDAP_CANCELLED, >> since syncprov can set rs->sr_err = LDAP_CANCELLED too. >> Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when >> sr_ref != NULL is rather dubious. Maybe sr_ref should just >> be ignored when sending something else than LDAP_REFERRAL. > > Leave the assert() in place until you have proof one way or the other. Haven't tested with an example of an overlay setting SLAPD_ABANDON; could check syncprov or retcode I suppose. Faked it with nanosleep(&((struct timespec){0,2E8}), 0); /*gcc or C99 code*/ if ( op->o_abandon ) rs->sr_err = SLAPD_ABANDON; after the op->o_callback->sc_response in slap_response_play(). Then, with this slapd.conf: include servers/slapd/schema/core.schema referral ldap://elsewhere/ database frontend overlay valsort send Delete "cn=urgle" <wait 0.1 second> Abandon <previous request> lt-slapd: result.c:479: send_ldap_response: Assertion `rs->sr_err == 0x0a' failed. One more detail, looking at result.c rev 1.330 send_ldap_response(): I presume the LDAP_CONNECTIONLESS branch should also ber_printf rc rather than rs->sr_err to the response. Not sure if Cancel makes sense in cldap (and after V2 Bind which has no extended operation at that), but OpenLDAP does let through Cancel after a V2 Bind. >> When rc == LDAP_CANCELLED, the function should not send sr_matched, >> sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems >> slap_cleanup_play() should still see them if they are not sent? > > Dunno what you mean. I thought that was obvious, but since it isn't maybe I should ask ldapext instead. Cancel does seem underspecified in this regard. Anyway, I meant: Either an operation gets cancelled/abandoned, or it doesn't and comletes. If these fields are set, they most likely relate to a completed operation. Nowhere SLAPD_ABANDON gets set, are the others set - possibly except with back-meta/back-ldap, I haven't looked too closely. OTOH, code setting SLAPD_ABANDON rarely _clears_ those fields, so I imagine they can convey information which would have been removed (access controls maybe?) or updated before they were sent, if the operation had completed. Clearing a critical control can be a bit doubtful, I'll grant. But for not obeying critical controls it's a choice between which error code to return - unavailableCriticalExtension, cancelled, or something else. Or some controls could mark the operation as "uncancellable" (another flag needed...) But come to think of it, an Extended Response has some of the same problem. By the above reasoning, responseName and responseValue should be dropped in a Cancelled response, as when sending protocolError to an unrecognized reqest. Might be a bit extreme. -- Hallvard

1 0

Re: (ITS#6103) canceled operations do not respond
by hyc＠symas.com 27 May '09

27 May '09

Hallvard B Furuseth wrote: > The send_ldap_response() fix is still incomplete: > > When rc == LDAP_CANCELLED, the function should not send sr_matched, > sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems > slap_cleanup_play() should still see them if they are not sent? Dunno what you mean. > Note, not just when the function itself sets rc = LDAP_CANCELLED, > since syncprov can set rs->sr_err = LDAP_CANCELLED too. > Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when > sr_ref != NULL is rather dubious. Maybe sr_ref should just > be ignored when sending something else than LDAP_REFERRAL. Leave the assert() in place until you have proof one way or the other. > Also, this: > rc = rs->sr_err; > if ( rc == SLAPD_ABANDON&& op->o_cancel ) > rc = LDAP_CANCELLED; > will send a negative result code (SLAPD_ABANDON) if !o_cancel. No, it won't. That is all bypassed at the top of the function. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6103) canceled operations do not respond
by h.b.furuseth＠usit.uio.no 27 May '09

27 May '09

The send_ldap_response() fix is still incomplete: When rc == LDAP_CANCELLED, the function should not send sr_matched, sr_text, sr_ref, and sr_ctrls. Looking at how Abandon works, it seems slap_cleanup_play() should still see them if they are not sent? Note, not just when the function itself sets rc = LDAP_CANCELLED, since syncprov can set rs->sr_err = LDAP_CANCELLED too. Which also suggests the assert( rs->sr_err == LDAP_REFERRAL ) when sr_ref != NULL is rather dubious. Maybe sr_ref should just be ignored when sending something else than LDAP_REFERRAL. Also, this: rc = rs->sr_err; if ( rc == SLAPD_ABANDON && op->o_cancel ) rc = LDAP_CANCELLED; will send a negative result code (SLAPD_ABANDON) if !o_cancel. I guess it should be if ( rc == SLAPD_ABANDON ) { if ( !op->o_cancel ) goto <cleanup or clean2>; rc = LDAP_CANCELLED; } While we're at it, I suggest to generalize this to avoid sending result codes < 0. Send LDAP_OTHER instead. That's ITS#5328 again. -- Hallvard

1 0

Re: (ITS#6108) unique overlay and rootdn
by hyc＠symas.com 27 May '09

27 May '09

mfn(a)fs-etit.de wrote: > Full_Name: Christopher Dyck > Version: 2.4.11 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (130.83.183.3) > > > I found a strange behavior in the unique overlay. > > unique overlay only works, when a rootdn is specified in the slapd.conf, because > the unique_search function uses the rootdn for searching. (took me hours to > determine why my configuration didn't do it's job) > > Isn't it more reasonable to use the dn with which the add or modify is > performed? Definitely not. The user performing the write may not have sufficient access to see all of the instances of the attribute in question. > Or mention this circumstance at least in the manpage?! Probably. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#6141 published: SECURITY: Dynamic configuration perfomance issue
by openldap-its＠OpenLDAP.org 27 May '09

27 May '09

Private ITS#6141 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6141

1 0

ITS#6143 published: SECURITY: Dynamic configuration perfomance issue
by openldap-its＠OpenLDAP.org 27 May '09

27 May '09

Private ITS#6143 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6143

1 0

(ITS#6148) Need smbk5pwd to support MIT KDC
by hyc＠OpenLDAP.org 27 May '09

27 May '09

Full_Name: Howard Chu Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.102) Submitted by: hyc This is a reminder to me to investigate how the MIT KDC's LDAP backend works, and how to manage password synchronization there.

1 0

(ITS#6147) slapd should explicitly configure SASL auxprop
by hyc＠OpenLDAP.org 26 May '09

26 May '09

Full_Name: Howard Chu Version: 2.4.16/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.67.104.110) Submitted by: hyc we need a config option for controlling which auxprop plugins the Cyrus SASL library uses, and it should default to just "slapd". See ITS#6056, the sasldb plugin causes problems and generally isn't useful anyway. (And yes, we probably need to investigate why those problems arise.) Also see ITS#6129, we should take more explicit steps to prevent the ldapdb auxprop from loading.

1 0

(ITS#6146) Note output format in ldapsearch man page DESCRIPTION
by rra＠stanford.edu 26 May '09

26 May '09

Full_Name: Russ Allbery Version: 2.4.11 OS: Debian URL: Submission from: (NULL) (171.66.157.16) A Debian user had some difficulty finding the output format of ldapsearch in the current man page. It's there, under -L, but it's not noted in the DESCRIPTION section. Would it be reasonable to add the sentence: The attributes are displayed using an extended version of LDIF. to the end of the DESCRIPTION section?

1 0

Re: (ITS#6145) Resource leaks shown when running cppcheck against openldap
by hyc＠symas.com 26 May '09

26 May '09

palbert1(a)yahoo.com wrote: > Full_Name: Paul Albert > Version: 2.4.16 > OS: SUSE Linux > URL: N/A > Submission from: (NULL) (198.24.6.168) > > > As part of working on a new project, I'm running cppcheck against various pieces > of code that we'll be using. I downloaded cppcheck version 1.32 and ran it > against open LDAP version 2.4.16. cppcheck reported 18 file descriptor/memory > leaks in the open LDAP code base in addition to 2 bad programming practices > (labeled as style). Visual inspection of the code verified these errors. > > The results are shown below and can be verified by running cppcheck against the > open ldap code: None of which matters, since these are all one-shot commands... > > sleepy code/openldap-2.4.16> ../cppcheck-1.32/cppcheck -q . > [./clients/tools/ldapdelete.c:230]: (error) Resource leak: fp > [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: entrydn > [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: rdn > [./clients/tools/ldapmodrdn.c:233]: (error) Resource leak: fp > [./contrib/slapd-modules/dsaschema/dsaschema.c:260]: (error) Memory leak: > saveline > [./libraries/libldap_r/thr_debug.c:575]: (error) Memory leak: t > [./libraries/liblutil/getpass.c:128]: (style) Found 'scanf'. You should use > 'fgets' instead > [./libraries/liblutil/getpass.c:153]: (style) Found 'scanf'. You should use > 'fgets' instead > [./servers/slapd/slapi/slapi_utils.c:2511]: (error) Wrong assignement of an > auto-variable to an effective parameter of a function > [./tests/progs/slapd-addel.c:192]: (error) Memory leak: manager > [./tests/progs/slapd-addel.c:192]: (error) Memory leak: filename > [./tests/progs/slapd-modify.c:194]: (error) Memory leak: manager > [./tests/progs/slapd-modify.c:194]: (error) Memory leak: entry > [./tests/progs/slapd-modrdn.c:177]: (error) Memory leak: manager > [./tests/progs/slapd-read.c:227]: (error) Memory leak: manager > [./tests/progs/slapd-read.c:227]: (error) Memory leak: entry > [./tests/progs/slapd-read.c:227]: (error) Memory leak: filter > [./tests/progs/slapd-search.c:250]: (error) Memory leak: manager > [./tests/progs/slapd-search.c:250]: (error) Memory leak: sbase > [./tests/progs/slapd-search.c:250]: (error) Memory leak: filter > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 26 May '09

26 May '09

--=-Qa9s282ZNKloqhE3QHt5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 15:40 +0200, Michael Str=C3=B6der wrote: > abartlet(a)samba.org wrote: > > Samba4 always uses SASL credentials these days (trying to avoid simple > > binds). >=20 > libsasldb2.so is not required for a SASL bind with password-based > mechanism. You can store the passwords in attribute userPassword (in > clear-text). So the security consideration is more about password > storage than SASL vs. simple bind on the wire. Which we already use. Regardless, Howard's great detective work shows it still gets in the way.=20 > > Perhaps it's time to investigate EXTERNAL >=20 > That would be good anyway since in Samba4 the result of standard > provision is LDAPI access anyway. So you could directly map the Unix > user smbd is running as (root?) with authz-regexp to directory user > samba-admin. Well, we already discussed that.. ;-) We did. =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-Qa9s282ZNKloqhE3QHt5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKHJj0z4A8Wyi0NrsRAqkfAJ4jsghUdEiUTnOHsmG2Bg9njDe6agCeN4hF aNRmEnt5qtFNRw7WtnaXqto= =midd -----END PGP SIGNATURE----- --=-Qa9s282ZNKloqhE3QHt5--

1 0

(ITS#6145) Resource leaks shown when running cppcheck against openldap
by palbert1＠yahoo.com 26 May '09

26 May '09

Full_Name: Paul Albert Version: 2.4.16 OS: SUSE Linux URL: N/A Submission from: (NULL) (198.24.6.168) As part of working on a new project, I'm running cppcheck against various pieces of code that we'll be using. I downloaded cppcheck version 1.32 and ran it against open LDAP version 2.4.16. cppcheck reported 18 file descriptor/memory leaks in the open LDAP code base in addition to 2 bad programming practices (labeled as style). Visual inspection of the code verified these errors. The results are shown below and can be verified by running cppcheck against the open ldap code: sleepy code/openldap-2.4.16> ../cppcheck-1.32/cppcheck -q . [./clients/tools/ldapdelete.c:230]: (error) Resource leak: fp [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: entrydn [./clients/tools/ldapmodrdn.c:233]: (error) Memory leak: rdn [./clients/tools/ldapmodrdn.c:233]: (error) Resource leak: fp [./contrib/slapd-modules/dsaschema/dsaschema.c:260]: (error) Memory leak: saveline [./libraries/libldap_r/thr_debug.c:575]: (error) Memory leak: t [./libraries/liblutil/getpass.c:128]: (style) Found 'scanf'. You should use 'fgets' instead [./libraries/liblutil/getpass.c:153]: (style) Found 'scanf'. You should use 'fgets' instead [./servers/slapd/slapi/slapi_utils.c:2511]: (error) Wrong assignement of an auto-variable to an effective parameter of a function [./tests/progs/slapd-addel.c:192]: (error) Memory leak: manager [./tests/progs/slapd-addel.c:192]: (error) Memory leak: filename [./tests/progs/slapd-modify.c:194]: (error) Memory leak: manager [./tests/progs/slapd-modify.c:194]: (error) Memory leak: entry [./tests/progs/slapd-modrdn.c:177]: (error) Memory leak: manager [./tests/progs/slapd-read.c:227]: (error) Memory leak: manager [./tests/progs/slapd-read.c:227]: (error) Memory leak: entry [./tests/progs/slapd-read.c:227]: (error) Memory leak: filter [./tests/progs/slapd-search.c:250]: (error) Memory leak: manager [./tests/progs/slapd-search.c:250]: (error) Memory leak: sbase [./tests/progs/slapd-search.c:250]: (error) Memory leak: filter

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by michael＠stroeder.com 26 May '09

26 May '09

abartlet(a)samba.org wrote: > Samba4 always uses SASL credentials these days (trying to avoid simple > binds). libsasldb2.so is not required for a SASL bind with password-based mechanism. You can store the passwords in attribute userPassword (in clear-text). So the security consideration is more about password storage than SASL vs. simple bind on the wire. > Perhaps it's time to investigate EXTERNAL That would be good anyway since in Samba4 the result of standard provision is LDAPI access anyway. So you could directly map the Unix user smbd is running as (root?) with authz-regexp to directory user samba-admin. Well, we already discussed that.. ;-) Ciao, Michael.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 26 May '09

26 May '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Further testing with Andrew's kvm image shows the hang only occurs when Cyrus >> SASL's libsasldb2.so plugin is present. > > Probably you already checked whether there's a BDB library mix. Yes, the version is the same, BDB 4.7. However it's possible that BDB 4.7 doesn't like being initialized multiple times, as occurs here. I haven't yet looked more deeply to see what the real cause is. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by abartlet＠samba.org 26 May '09

26 May '09

--=-oqpE6PlbXuzML9/ubGjQ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-05-26 at 04:26 -0700, Howard Chu wrote: > abartlet(a)samba.org wrote: > > Full_Name: Andrew Bartlett > > Version: CVS HEAD > > OS: Fedora 10 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (59.167.251.137) > > > > > > Samba4's provision and 'make test' seems to create some internal situat= ion in > > OpenLDAP slapd where it will not accept any more connections over ldapi= :/// > > > > This is best seen by building Samba4, and running > > > > TEST_LDAP=3Dyes OPENLDAP_ROOT=3D/usr/local make test > > > > The slapd does not crash, but simply stops accepting new connections. = Samba4 > > currently then crashes due to some other bug (the LDAP backend not resp= onding is > > clearly untested code in Samba4). > > > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > > > This seems very, very similar to ITS#5261 >=20 > Further testing with Andrew's kvm image shows the hang only occurs when C= yrus=20 > SASL's libsasldb2.so plugin is present. I always remove that plugin from = my=20 > installs, since I only use in-directory SASL secrets. That's probably why= I=20 > wasn't seeing the reported behavior before. Very interesting result! > Also a note - it's still not clear we've been talking about the same thin= g up=20 > to this point. Even when the samba test suite hangs, I see that ldapsearc= h=20 > still works fine against slapd. At any rate, currently all of the samba4 = tests=20 > pass for me. Samba4 always uses SASL credentials these days (trying to avoid simple binds). Perhaps it's time to investigate EXTERNAL if it would avoid some of this pain (but we should also try and fix the real bug here, if at all possible). =20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com --=-oqpE6PlbXuzML9/ubGjQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBKG99Zz4A8Wyi0NrsRAmqZAJ9Oh4eSbVP7nbGAn0b8tp2hVMbWKQCfZ4Lr pIs94kn/tBYQYq0Qr1uSX44= =CZuG -----END PGP SIGNATURE----- --=-oqpE6PlbXuzML9/ubGjQ--

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by michael＠stroeder.com 26 May '09

26 May '09

hyc(a)symas.com wrote: > Further testing with Andrew's kvm image shows the hang only occurs when Cyrus > SASL's libsasldb2.so plugin is present. Probably you already checked whether there's a BDB library mix. Ciao, Michael.

1 0

Re: (ITS#6056) Samba4 breaks OpenLDAP over ldapi
by hyc＠symas.com 26 May '09

26 May '09

abartlet(a)samba.org wrote: > Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.167.251.137) > > > Samba4's provision and 'make test' seems to create some internal situation in > OpenLDAP slapd where it will not accept any more connections over ldapi:/// > > This is best seen by building Samba4, and running > > TEST_LDAP=yes OPENLDAP_ROOT=/usr/local make test > > The slapd does not crash, but simply stops accepting new connections. Samba4 > currently then crashes due to some other bug (the LDAP backend not responding is > clearly untested code in Samba4). > > It isn't a Samba4 client bug, as ldapsearch also fails to respond. > > This seems very, very similar to ITS#5261 Further testing with Andrew's kvm image shows the hang only occurs when Cyrus SASL's libsasldb2.so plugin is present. I always remove that plugin from my installs, since I only use in-directory SASL secrets. That's probably why I wasn't seeing the reported behavior before. Also a note - it's still not clear we've been talking about the same thing up to this point. Even when the samba test suite hangs, I see that ldapsearch still works fine against slapd. At any rate, currently all of the samba4 tests pass for me. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

LDAP add *.ldif errors
by Pastore Annamaria 25 May '09

25 May '09

Goodmornig, I load a version 2.4 of LDAP (that support overlay-memberof). Ldap it start ok, and the network was ok. I start to configure a memberof scenarios and after few errors started. For don't touch anymore, I cleanup all /var/lib/ldap...and I try to load A single *.ldif.... but when I try to load a .ldif (core, cosine..) I have few errors : 1. With ldap online : ldapadd -x -D "cn=Manager,dc=pippo,dc=it" -W -f core.ldif Enter LDAP Password: adding new entry "cn=core,cn=schema,cn=config" ldap_add: Insufficient access (50) In /var/lib/ldap there is a DB_CONFIG (before DB_CONFIG.exemple) and the owner of directory is ldap, just I read few threads about this sort of bug. The access in slapd.con is : #access to dn="" by * read access to attrs=userPassword by anonymous auth by self write by * auth # by * none access to * by self write by * read # by * none But anymore I try also whit "by * write" and nothing change. Other parameter is : directory /var/lib/ldap 2. With ldap offline : [root@itmit2vl5 schema]# slapadd -l core.ldif -f ../slapd.conf bdb(dc=telecom,dc=it): Program version 4.4 doesn't match environment version 4.6 bdb_db_open: Database cannot be opened, err -30971. Restore from backup! bdb(dc=pippo,dc=it): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem bdb(dc=pippo,dc=it): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_close: txn_checkpoint failed: Invalid argument (22) backend_startup_one: bi_db_open failed! (-30971) slap_startup failed But the bdb version not appears anywhere!!! I try also the command "od -j12 -N8 -tx4 log.0000000001" and the result was 4.6! What I must to do, for going on ? Thank you very much at all, and sorry for my newbie expierence..... Internet E. Mail Confidentiality Footer ----------------------------------------------------------------------------------------------------- La presente comunicazione, con le informazioni in essa contenute e ogni documento o file allegato, e' rivolta unicamente alla/e persona/e cui e' indirizzata ed alle altre da questa autorizzata/e a riceverla. Se non siete i destinatari/autorizzati siete avvisati che qualsiasi azione, copia, comunicazione, divulgazione o simili basate sul contenuto di tali informazioni e' vietata e potrebbe essere contro la legge (art. 616 C.P., D.Lgs n. 196/2003 Codice in materia di protezione dei dati personali). Se avete ricevuto questa comunicazione per errore, vi preghiamo di darne immediata notizia al mittente e di distruggere il messaggio originale e ogni file allegato senza farne copia alcuna o riprodurne in alcun modo il contenuto. This e-mail and its attachments are intended for the addressee(s) only and are confidential and/or may contain legally privileged information. If you have received this message by mistake or are not one of the addressees above, you may take no action based on it, and you may not copy or show it to anyone; please reply to this e-mail and point out the error which has occurred.

1 0

Re: (ITS#6139) slapd: password-hash rejects multiple values
by michael＠stroeder.com 25 May '09

25 May '09

fumiyas(a)osstech.co.jp wrote: > My /etc/openldap/slapd.conf has the following line: > password-hash {CRYPT} {SSHA} What exactly do you want to achieve by this? Ciao, Michael.

1 0

Compile error on tru64 5.1b
by Didier Godefroy 25 May '09

25 May '09

Hello, Compiling openldap 2.4.26 on tru64 unix v5.1b, using the native compilers and gmake. I'm getting an error as follows: Entering subdirectory liblunicode gmake[2]: Entering directory `/usr/local/openldap/openldap-2.4.16/libraries/liblunicode' cc -O4 -g3 -w -I../../include -I../../include -pthread -I/usr/local/include -pthread -I/usr/local/include -c -o ure.o ure.c cc: Fatal: A memory access violation (bus error or segmentation fault) has occurred. Please submit a problem report. gmake[2]: *** [ure.o] Error 1 I retried, just in case, and got the same error again. I'm not a C programmer and I have no idea how to fix this. What can I try and send to get this fixed? Thanks, -- Didier Godefroy mailto:dg@ulysium.net Support anti-Spam legislation. Join the fight http://www.cauce.org/

2 1

Re: (ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by hyc＠symas.com 25 May '09

25 May '09

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.16 > OS: Debian 5.0.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.99.175.5) > > > When TLSVerifyClient is set to "try", OpenLDAP improperly rejects SSL > connections without a client certificate. The problem appears to start with this > section of code in tls.c around line 1564: > > #ifdef HAVE_GNUTLS > if ( ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_NEVER ) { > err = tls_cert_verify( ssl ); > if ( err&& ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_ALLOW > ) > return err; > } > #endif > > tls_cert_verify() calls gnutls_certificate_verify_peers2(), which appears to > return error 49 when no client certificate is presented. tls_cert_verify() > doesn't seem to distinguish between this case, and the case of an invalid client > certificate, returning -1 in both cases. > This bug report makes no sense; the code you quoted is not part of OpenLDAP 2.4.16. The relevant code is in function tlsg_session_accept() in tls_g.c, and there is no such bug in that function. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by michael＠stroeder.com 25 May '09

25 May '09

Full_Name: Michael Ströder Version: RE24 OS: Linux URL: Submission from: (NULL) (84.163.124.107) When including nadf.schema slapd does not start and prints error message: /opt/openldap-RE24/etc/openldap/schema/nadf.schema: line 111 objectclass: AttributeType not found: "lastModifiedTime" /etc/openldap/slapd.conf: line 17: <include> handler exited with 1! Analyzing this I found this commented declaration in cosine.schema: ## Deprecated in favor of modifyTimeStamp #attributetype ( 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime' # DESC 'RFC1274: time of last modify, replaced by modifyTimestamp' # OBSOLETE # SYNTAX 1.3.6.1.4.1.1466.115.121.1.53 # USAGE directoryOperation ) So it seems nadf.schema is not usable at the moment.

1 0

(ITS#6139) slapd: password-hash rejects multiple values
by fumiyas＠osstech.co.jp 25 May '09

25 May '09

Full_Name: SATOH Fumiyasu Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.176.213.88) My /etc/openldap/slapd.conf has the following line: password-hash {CRYPT} {SSHA} On OpenLDAP 2.4.16, slapd (slaptest) rejects this config: # /usr/sbin/slaptest /etc/openldap/slapd.conf: line 36: <password-hash> extra cruft after <hash>. slaptest: bad configuration file! On OpenLDAP 2.3.43, slapd (slaptest) accept this config. The slapd.conf(5) (included in OpenLDAP 2.3.43/2.4.16) manpage said: password-hash <hash> [<hash>...] This option configures one or more hashes to be used in generation of user passwords stored in the userPassword attribute during processing of LDAP Password Modify Extended Operations (RFC 3062).

1 0

Re: (ITS#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 23 May '09

23 May '09

hyc(a)symas.com writes: >> Bitflags should be unnecessary as such, just need a set of values. >> Though it wouldn't hurt if they were chosen so one could use bit >> operations to reduce checks for "o_abandon == A or B". "Suppress >> response" value mentioned in ITS#6138 also needed, maybe that must be a >> bitflag when combined with Cancel stuff. > > Yes, it still seems some bitflags will be more appropriate. As long as we decide which flag combinations are (not) valid. Problem with "unrestricted" bitflags compared to a list of values is that they allow and thus require support for flag combinations we have no real need to support. >> Question: >> syncprov_op_abandon() holds&si->si_ops_mutex when setting >> so->s_op->o_abandon. Does it need that? The function needs to >> grab op->o_conn->c_mutex when called as Cancel, but must not do >> that while holding&si->si_ops_mutex since Abandon grabs the >> locks in the opposite order. > > syncprov_op_abandon() can remove ops from the list, so yes, it must > hold si_ops_mutex. Right, but does it need si_ops_mutex while setting o_abandon? Cancel could remove the op, unlock si_ops_mutex, lock c_mutex, update o_abandon. Alternative: Lock c_mutex first (that must be safe since Abandon is doing it anyway), then lock si_ops_mutex. So it's not a critical difference, just that a lock must be held a bit longer. -- Hallvard

1 0

Re: (ITS#6104) race condition with cancel operation
by hyc＠symas.com 22 May '09

22 May '09

h.b.furuseth(a)usit.uio.no wrote: > Well, this turned out a lot of problems. Currently blocked by > ITS#6138 Bad Cancel/Abandon/"internal abandon"/Syncprov interactions. > > back-relay/op.c done (ITS#6133). syncprov/retcode issues may fit better > under ITS#6138. > > Bitflags should be unnecessary as such, just need a set of values. > Though it wouldn't hurt if they were chosen so one could use bit > operations to reduce checks for "o_abandon == A or B". "Suppress > response" value mentioned in ITS#6138 also needed, maybe that must be a > bitflag when combined with Cancel stuff. Yes, it still seems some bitflags will be more appropriate. > Some tidbits uglifying a fix: > * op->o_conn->c_mutex is locked when be->be_abandon() is called, > but not when be->be_cancel() is called. > * send_ldap_ber() needs the lock while it holds&conn->c_write1_mutex, > but code elsewhere indicates the reverse lock order. > > Question: > syncprov_op_abandon() holds&si->si_ops_mutex when setting > so->s_op->o_abandon. Does it need that? The function needs to > grab op->o_conn->c_mutex when called as Cancel, but must not do > that while holding&si->si_ops_mutex since Abandon grabs the > locks in the opposite order. syncprov_op_abandon() can remove ops from the list, so yes, it must hold si_ops_mutex. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 22 May '09

22 May '09

Well, this turned out a lot of problems. Currently blocked by ITS#6138 Bad Cancel/Abandon/"internal abandon"/Syncprov interactions. back-relay/op.c done (ITS#6133). syncprov/retcode issues may fit better under ITS#6138. Bitflags should be unnecessary as such, just need a set of values. Though it wouldn't hurt if they were chosen so one could use bit operations to reduce checks for "o_abandon == A or B". "Suppress response" value mentioned in ITS#6138 also needed, maybe that must be a bitflag when combined with Cancel stuff. Some tidbits uglifying a fix: * op->o_conn->c_mutex is locked when be->be_abandon() is called, but not when be->be_cancel() is called. * send_ldap_ber() needs the lock while it holds &conn->c_write1_mutex, but code elsewhere indicates the reverse lock order. Question: syncprov_op_abandon() holds &si->si_ops_mutex when setting so->s_op->o_abandon. Does it need that? The function needs to grab op->o_conn->c_mutex when called as Cancel, but must not do that while holding &si->si_ops_mutex since Abandon grabs the locks in the opposite order. -- Hallvard

1 0

(ITS#6138) Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by h.b.furuseth＠usit.uio.no 22 May '09

22 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Might make this a tracking issue for Cancel/Abandon problems. And/or copy some to separate ITSes, but they all seem interconnected: Cancel(abandoned operation)-requests are not rejected. Thus slapd sets o_cancel and turns an active Abandon into a Cancel. Presumably that can confuse Cancel/Abandon handlers, like that in Syncprov. Similarly, Abandon(abandoned/cancelled operation) is not ignored. connection_abandon() re-abandons abandoned/cancelled operations too. However Syncprov:RefreshAndPersist abuses op->o_abandon: It sets it to mean "Suppress the response. A copy of this operation will send it." So if Cancel(op with o_abandon!=0) is fixed to respond protocolError "already abandoned", presumably that breaks Cancel(RefreshAndPersist). I'm not touching it with a flagpole - I don't know syncprov. Help? Overlay retcode does something similar - sends a response and then sets o_abandon. Cancel/Abandon can in any case fail by targeting the wrong operation though: A connection can have multiple messages with the same IDs when the response is sent and the client reuses the message ID, before the old operation in slapd can clean up and finish. syncprov_op_abandon() identifies messages by (connid, msgid). Can multiple messages with the same ID break that, or more importantly, break what gets sent/written with syncrepl? Anyway, the current code needs an o_abandon value which means "suppress response". Or maybe "abandoned, except as far as future Abandon and Cancel operations are concerned". Syncprov and Retcode need to handle the various possible orderings of Cancel/Abandon vs Suppress, including when they forward o_abandon from one operation to another. I haven't looked too closely at that code either. ITS#6104 (race condition with cancel operation) also calls for multiple o_abandon values (joining some or all of o_cancel into o_abandon), and must be considered when picking a value. However I suggest to consider just the various possible values first and get that right, and deal with the race condition later. Source and binary compatibility with third-party modules complicates this, if we're trying to support both and old compiled slapd + new compiled module and vice versa. Might try a minimal solution now.

1 0

Re: (ITS#6137) Cancel(pending operation) acts like Abandon
by h.b.furuseth＠usit.uio.no 22 May '09

22 May '09

Confirmed & fixed. Responds "too busy for Cancel, try Abandon instead". If someone wants to, they could improve that. As noted in the commit: /* TODO: We could instead remove the cancelled operation * from c_pending_ops like Abandon does, and send its * response here. Not if it is pending because of a * congested connection though. */ -- Hallvard

1 0

Re: (ITS#6137) Cancel(pending operation) acts like Abandon
by h.b.furuseth＠usit.uio.no 21 May '09

21 May '09

Correction: the Cancel operation responds, since the frontend sends the response to extended operations. But the cancelled operation doesn't. -- Hallvard

1 0

(ITS#6137) Cancel(pending operation) acts like Abandon
by h.b.furuseth＠usit.uio.no 21 May '09

21 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Looking at the code (not sure how to reproduce): Cancel(pending operation) abandons the operation, without responding to either Cancel or the cancelled operation. That code in slapd/cancel.c is copied from the equivalent abandon.c code. Cancel as currently written must wait for the cancelled operation to complete. But an active operation must not wait for a pending one, all threads could block. For now we can make Cancel respond with LDAP_CANNOT_CANCEL: "can't handle Cancel now, try Abandon". Repeating myself, a better fix (RE25?) would be to make the cancelled operation send the Cancel response. Don't how deep surgery that'd need to slapd.

1 0

Re: (ITS#5328) backends sending/setting results
by masarati＠aero.polimi.it 21 May '09

21 May '09

h.b.furuseth(a)usit.uio.no wrote: > Fixed relay_back_has_subordinates(). > I've lost track of what I thought to do with back-ldap. I think you should just ignore it, otherwise all you could do is to to perform a onelevel search for each entry (!) that requests the attribute. We (dunno if it's documented) do not guarantee hasSubordinates is correct, all in all. p.

1 0

(ITS#6136) replicated slapd.d interrupts syncrepl refresh
by mbackes＠symas.com 20 May '09

20 May '09

Full_Name: Matthew Backes Version: 2.4, probably head? OS: any URL: Submission from: (NULL) (12.49.250.67) If you modify an object in cn=config in a multi-master environment with replicated cn=config, other databases on replicating other-masters in the refresh-state will be interrupted when they receive the change. Applying any change to their local cn=config resumes the syncrepl refresh operation.

1 0

(ITS#6135) Changed TLS settings in cn=config require a restart
by hyc＠OpenLDAP.org 20 May '09

20 May '09

Full_Name: Howard Chu Version: 2.4.16/HEAD OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc I thought we already had an ITS for this but didn't find it... slapd's global TLS settings are stored in an SSL context that only gets initialized at startup time. So changes to these settings via cn=config take no effect until the next restart. Changes to the other TLS users (syncrepl, back-ldap, back-meta) take effect immediately, as expected. bconfig.c's config_tls_config needs to check whether slapd is online or not, and reinitialize the global context after these changes if so.

1 0

(ITS#6134) Missing ITS state/directory documentation
by h.b.furuseth＠usit.uio.no 20 May '09

20 May '09

Full_Name: Hallvard B Furuseth Version: OS: URL: http://www.openldap.org/lists/openldap-commit/200902/msg00172.html Submission from: (NULL) (129.240.6.233) Submitted by: hallvard https://www.openldap.org/its/help.html does not document states Active and Partial. From the enclosed commit URL: Active - bug is being worked on Partial - a partial fix was released Also the help page's directory list shows "Archive.*", but the ITS system seems to have no match for that.

1 0

Re: (ITS#5328) backends sending/setting results
by h.b.furuseth＠usit.uio.no 20 May '09

20 May '09

Fixed relay_back_has_subordinates(). I've lost track of what I thought to do with back-ldap. -- Hallvard

1 0

(ITS#6133) back-relay issues
by h.b.furuseth＠usit.uio.no 20 May '09

20 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Back-relay issues - fixing some, awaiting confirmation/discussion of others: * The handlers for Abandon, Cancel and connection-init/destroy should not exist, as far as I can tell. They forward the call to the underlying backend database, but that means it receives the call twice: Slapd calls these handlers for all databases anyway (unless one returns success in case of Cancel), since there's no DN on which to dispatch. See abandon.c:fe_op_abandon(), cancel.c:cancel_extop(), and backend.c:backend_connection_init()/backend_connection_destroy(). The Cancel handler seems broken anyway. It sets op->o_cancel = LDAP_CANNOT_CANCEL on the Cancel operation. Presumably it intended the to-be-cancelled operation. I'm "#if 0"ing these out for now in case I've missed something. Can remove the code later. * Fixing RB_ERR (set rs->sr_err) and RB_SEND (send if error) handling: relay_back_select_backend() did not obey (!(fail_mode & RB_ERR)) except when it caught recursion. LDAP_SUCCESS makes no sense combined with these flags. relay_back_operational() could set rs->sr_err = success on failure, which seemed a bit excessive. (Though it should return success.) Removing the RB_ERR flag. relay_back_chk_referrals() can send success on failure. Except the function is not used, so I'm just #if 0ing and commenting it. This also means relay_back_select_backend() without these flags could just as well get SlapReply rs == NULL, which again means rs==NULL could function as a !RB_ERR flag. Not doing that yet, in case the changes below lead to some reason not to. * Fixing relay_back_select_backend() crash when select_backend()==NULL: include servers/slapd/schema/core.schema database relay suffix cn=relay,cn=test overlay rwm rwm-suffixmassage cn=nowhere ldapsearch -b cn=urgle,cn=relay,cn=test -s base * back-relay can be configured to cause infinite recursion. This dumps core with the above search: include servers/slapd/schema/core.schema database relay subordinate suffix cn=relay,cn=test relay cn=relay,cn=test database null suffix cn=test There are some tests to catch that, but half-hearted ones. And some comments about it, like this: /* FIXME: this test only works if there are no overlays, so * it is nearly useless; if made stricter, no nested back-relays * can be instantiated... too bad. */ if ( bd == NULL || bd == op->o_bd ) { return LDAP_SUCCESS; } I don't know how that's worse in this case than in other cases, nor what exactly how that snippet is supposed to work, so I don't know if the suggestion below fixes it and the test can be removed. The 'bd == op->o_bd' part can be removed since relay_back_select_backend() now returns bd==NULL when that happens: (bd->be_private == op->o_bd->be_private) implies (bd == op->o_bd). Anyway, recursion can now be properly caught with op->o_extra. Wrap calls to the underlying backend (e.g. in relay_back_op) in - untested: OpExtraDB oex; oex.oe_db = op->o_bd; oex.oe.oe_key = op->o_bd->be_private; LDAP_SLIST_INSERT_HEAD( &op->o_extra, &oex.oe, oe_next ); ... LDAP_SLIST_REMOVE( &op->o_extra, &oex.oe, OpExtra, oe_next ); and check in relay_back_select_backend() with relay_back_info *ri = (relay_back_info *)op->o_bd->be_private; OpExtra *oex; LDAP_SLIST_FOREACH( oex, &op->o_extra, oe_next ) { if ( oex->oe_key == ri ) <caught recursion, fail and return NULL>; } However, does the comment quoted above mean that it's desirable to allow a few rounds of recursion (a back-relay instance calling itself)? If so, define a config parameter relay-max-recursion with default=0, and define a struct with the OpExtra members + a counter which says how many rounds of recursion the operation has had so far for this database. See the OpExtra comment in slap.h.

1 0

(ITS#6132) slapi_entry_has_children broken
by h.b.furuseth＠usit.uio.no 20 May '09

20 May '09

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapi_entry_has_children() does not check for errors, and also calls the database's be_has_subordinates handler even when it does not exist. Finally, when there is no be_has_subordinates to call, it builds and destroys a pblock which isn't used for anyting. I don't know what a pblock is, but it looks like a waste of time. Fixing.

1 0

(ITS#6131) "TLSVerifyClient try" not working with GNU TLS
by subbarao＠computer.org 20 May '09

20 May '09

Full_Name: Kartik Subbarao Version: 2.4.16 OS: Debian 5.0.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.99.175.5) When TLSVerifyClient is set to "try", OpenLDAP improperly rejects SSL connections without a client certificate. The problem appears to start with this section of code in tls.c around line 1564: #ifdef HAVE_GNUTLS if ( ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_NEVER ) { err = tls_cert_verify( ssl ); if ( err && ld->ld_options.ldo_tls_require_cert != LDAP_OPT_X_TLS_ALLOW ) return err; } #endif tls_cert_verify() calls gnutls_certificate_verify_peers2(), which appears to return error 49 when no client certificate is presented. tls_cert_verify() doesn't seem to distinguish between this case, and the case of an invalid client certificate, returning -1 in both cases.

1 0

Re: (ITS#6129) slapd seg faults on shut-down
by michael＠stroeder.com 17 May '09

17 May '09

Howard Chu wrote: > This appears to be a Cyrus/SASL issue. > > In particular, your trace of thread 1 shows that slapd is shutting down > the SASL library and SASL is trying to tear down libldap. Inside slapd, > the Cyrus SASL library should never be touching libldap. As such, you > should check your SASL configuration, you probably have a plugin enabled > that shouldn't be. You're right. Removing cyrus-sasl-ldap-auxprop solved this problem. Sorry for the noise. Ciao, Michael.

1 0

Re: (ITS#6129) slapd seg faults on shut-down
by hyc＠symas.com 17 May '09

17 May '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.72.172) This appears to be a Cyrus/SASL issue. In particular, your trace of thread 1 shows that slapd is shutting down the SASL library and SASL is trying to tear down libldap. Inside slapd, the Cyrus SASL library should never be touching libldap. As such, you should check your SASL configuration, you probably have a plugin enabled that shouldn't be. > gdb output: > > [New Thread 3953] > Core was generated by `/opt/openldap-RE24/libexec/slapd -d 0 -h > ldap://0.0.0.0:2072 -n slapd-ffg2009-2'. > Program terminated with signal 11, Segmentation fault. > #0 0xb799eef5 in free () from /lib/libc.so.6 > (gdb) info threads > 2 Thread 3953 0xffffe430 in __kernel_vsyscall () > * 1 Thread 3951 0xb799eef5 in free () from /lib/libc.so.6 > (gdb) thread apply all bt > > Thread 2 (Thread 3953): > #0 0xffffe430 in __kernel_vsyscall () > #1 0xb7ce37b9 in __lll_lock_wait () from /lib/libpthread.so.0 > #2 0xb7cdece0 in _L_lock_286 () from /lib/libpthread.so.0 > #3 0xb7cde705 in pthread_mutex_lock () from /lib/libpthread.so.0 > #4 0xb7a387c9 in dl_iterate_phdr () from /lib/libc.so.6 > #5 0xb7a3ada5 in _Unwind_Find_FDE () from /lib/libc.so.6 > #6 0xb544764d in ?? () from /lib/libgcc_s.so.1 > #7 0xb5447e88 in ?? () from /lib/libgcc_s.so.1 > #8 0xb544818e in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1 > #9 0xb7ce5aa6 in _Unwind_ForcedUnwind () from /lib/libpthread.so.0 > #10 0xb7ce3491 in __pthread_unwind () from /lib/libpthread.so.0 > #11 0xb7cdd5c0 in pthread_exit () from /lib/libpthread.so.0 > #12 0xb7ed1593 in ldap_pvt_thread_exit (retval=0x0) at thr_posix.c:186 > #13 0xb7ed0574 in ldap_int_thread_pool_wrapper (xpool=0x81d2fc8) at tpool.c:691 > #14 0xb7cdd1b5 in start_thread () from /lib/libpthread.so.0 > #15 0xb7a023be in clone () from /lib/libc.so.6 > > Thread 1 (Thread 3951): > #0 0xb799eef5 in free () from /lib/libc.so.6 > #1 0xb7ebad4d in ber_memfree_x (p=0x7fffffff, ctx=0x0) at memory.c:152 > #2 0xb77af997 in ?? () from /usr/lib/libldap-2.4.so.2 > #3 0xb7791a68 in ?? () from /usr/lib/libldap-2.4.so.2 > #4 0xb77c0210 in _fini () from /usr/lib/libldap-2.4.so.2 > #5 0xb7f28aff in ?? () from /lib/ld-linux.so.2 > #6 0xb7f29447 in ?? () from /lib/ld-linux.so.2 > #7 0xb7cb8cf4 in ?? () from /lib/libdl.so.2 > #8 0xb7f239f6 in ?? () from /lib/ld-linux.so.2 > #9 0xb7cb911c in ?? () from /lib/libdl.so.2 > #10 0xb7cb8d2a in dlclose () from /lib/libdl.so.2 > #11 0xb7ccf411 in _sasl_done_with_plugins () from /usr/lib/libsasl2.so.2 > #12 0xb7cc7c90 in sasl_done () from /usr/lib/libsasl2.so.2 > #13 0x080d9fb7 in slap_sasl_destroy () > #14 0x080aed1b in slap_destroy () > #15 0x08059fe2 in main () > (gdb) bt full > #0 0xb799eef5 in free () from /lib/libc.so.6 > No symbol table info available. > #1 0xb7ebad4d in ber_memfree_x (p=0x7fffffff, ctx=0x0) at memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #2 0xb77af997 in ?? () from /usr/lib/libldap-2.4.so.2 > No symbol table info available. > #3 0xb7791a68 in ?? () from /usr/lib/libldap-2.4.so.2 > No symbol table info available. > #4 0xb77c0210 in _fini () from /usr/lib/libldap-2.4.so.2 > No symbol table info available. > #5 0xb7f28aff in ?? () from /lib/ld-linux.so.2 > No symbol table info available. > #6 0xb7f29447 in ?? () from /lib/ld-linux.so.2 > No symbol table info available. > #7 0xb7cb8cf4 in ?? () from /lib/libdl.so.2 > No symbol table info available. > #8 0xb7f239f6 in ?? () from /lib/ld-linux.so.2 > No symbol table info available. > #9 0xb7cb911c in ?? () from /lib/libdl.so.2 > No symbol table info available. > #10 0xb7cb8d2a in dlclose () from /lib/libdl.so.2 > No symbol table info available. > #11 0xb7ccf411 in _sasl_done_with_plugins () from /usr/lib/libsasl2.so.2 > No symbol table info available. > #12 0xb7cc7c90 in sasl_done () from /usr/lib/libsasl2.so.2 > No symbol table info available. > #13 0x080d9fb7 in slap_sasl_destroy () > No symbol table info available. > #14 0x080aed1b in slap_destroy () > No symbol table info available. > #15 0x08059fe2 in main () > No symbol table info available. > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6130) Remove rootdn requirement for monitor
by ghenry＠suretecsystems.com 15 May '09

15 May '09

Full_Name: Gavin Henry Version: n/a OS: n/a URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.186.20.160) Not needed in the "Upgrading from 2.3" section in the guide appendix.

1 0

Re: (ITS#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 15 May '09

15 May '09

Howard Chu writes: > I'd prefer to condense it all into a bitfield. Right... keep both o_abandon and o_cancel (maybe renamed to o_dummy) for RE24 though, otherwise we have a silent binary incompatible change with already-compiled slapd modules. The change will in any case break modules that play with o_cancel though. > We already ensure that > the c_mutex is held when setting these flags. Not yet, but c_mutex it is:-) Must protect the following code. Or rather, bitflag code which will replace it: - o_cancel access in cancel.c, connection.c:connection_operation(), back-relay/op.c. - o_abandon setting in overlays/syncprov.c:syncprov_op_abandon(), and in overlays/retcode.c where hopefully the first case should have been if ( op2.o_abandon ) op->o_abandon = 1; so that we can never reset o_abandon once it is set. > It would be a lot of > overhead to grab the mutex just to read the flag, > and would require additional analysis to make sure the new locking > behavior doesn't introduce new deadlocks. Checking o_abandon!=0 works unmutexed. (Well, technically any such unmutexed access is wrong, but in practice we should be OK.) As long as we: - never reset o_abandon like retcode above can do, and - never unmutexed assume consistency betweeen abandon-related variables set by different threads. So the equivalent of this should be OK: if ( op->o_abandon ) rs->sr_err = SLAPD_ABANDON; ... if ( rs->sr_err == SLAPD_ABANDON ) { lock c_mutex; more careful o_abandon checks; unlock c_mutex; } While I'm looking at this: The ldap_pvt_thread_yield() in cancel.c is really ugly. There is no cond to attach to it to without breaking binary compatibility, but even a even a global mutex+cond might be better, with threads broadcasting on it when it might be relevant. It's still ugly though. Cancelling an expensive operation ought to be a friendly operation, but instead it is unfriendly in that yet another thread is occupied, solely to wait for that operation. What would make sense (for RE25) would be to redo Cancel so that the cancelled thread is responsible for sending the Cancel response or resubmitting an operation which will. Also, the be_cancel implementation in at least back-relay looks wrong. Cancel isn't dispatched on DN, and back-relay with no 'relay' directive configured cannot know where to dispatch. I haven't checked how it works, but it seems a call to be_cancel means the Cancel operation _might_ belong to this backend. But it might not, which means back-relay shouldn't set op->o_cancel in this case. What it should do I don't know though. And I don't know if syncprov is doing any better. -- Hallvard

1 0

(ITS#6129) slapd seg faults on shut-down
by michael＠stroeder.com 15 May '09

15 May '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.72.172) gdb output: [New Thread 3953] Core was generated by `/opt/openldap-RE24/libexec/slapd -d 0 -h ldap://0.0.0.0:2072 -n slapd-ffg2009-2'. Program terminated with signal 11, Segmentation fault. #0 0xb799eef5 in free () from /lib/libc.so.6 (gdb) info threads 2 Thread 3953 0xffffe430 in __kernel_vsyscall () * 1 Thread 3951 0xb799eef5 in free () from /lib/libc.so.6 (gdb) thread apply all bt Thread 2 (Thread 3953): #0 0xffffe430 in __kernel_vsyscall () #1 0xb7ce37b9 in __lll_lock_wait () from /lib/libpthread.so.0 #2 0xb7cdece0 in _L_lock_286 () from /lib/libpthread.so.0 #3 0xb7cde705 in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0xb7a387c9 in dl_iterate_phdr () from /lib/libc.so.6 #5 0xb7a3ada5 in _Unwind_Find_FDE () from /lib/libc.so.6 #6 0xb544764d in ?? () from /lib/libgcc_s.so.1 #7 0xb5447e88 in ?? () from /lib/libgcc_s.so.1 #8 0xb544818e in _Unwind_ForcedUnwind () from /lib/libgcc_s.so.1 #9 0xb7ce5aa6 in _Unwind_ForcedUnwind () from /lib/libpthread.so.0 #10 0xb7ce3491 in __pthread_unwind () from /lib/libpthread.so.0 #11 0xb7cdd5c0 in pthread_exit () from /lib/libpthread.so.0 #12 0xb7ed1593 in ldap_pvt_thread_exit (retval=0x0) at thr_posix.c:186 #13 0xb7ed0574 in ldap_int_thread_pool_wrapper (xpool=0x81d2fc8) at tpool.c:691 #14 0xb7cdd1b5 in start_thread () from /lib/libpthread.so.0 #15 0xb7a023be in clone () from /lib/libc.so.6 Thread 1 (Thread 3951): #0 0xb799eef5 in free () from /lib/libc.so.6 #1 0xb7ebad4d in ber_memfree_x (p=0x7fffffff, ctx=0x0) at memory.c:152 #2 0xb77af997 in ?? () from /usr/lib/libldap-2.4.so.2 #3 0xb7791a68 in ?? () from /usr/lib/libldap-2.4.so.2 #4 0xb77c0210 in _fini () from /usr/lib/libldap-2.4.so.2 #5 0xb7f28aff in ?? () from /lib/ld-linux.so.2 #6 0xb7f29447 in ?? () from /lib/ld-linux.so.2 #7 0xb7cb8cf4 in ?? () from /lib/libdl.so.2 #8 0xb7f239f6 in ?? () from /lib/ld-linux.so.2 #9 0xb7cb911c in ?? () from /lib/libdl.so.2 #10 0xb7cb8d2a in dlclose () from /lib/libdl.so.2 #11 0xb7ccf411 in _sasl_done_with_plugins () from /usr/lib/libsasl2.so.2 #12 0xb7cc7c90 in sasl_done () from /usr/lib/libsasl2.so.2 #13 0x080d9fb7 in slap_sasl_destroy () #14 0x080aed1b in slap_destroy () #15 0x08059fe2 in main () (gdb) bt full #0 0xb799eef5 in free () from /lib/libc.so.6 No symbol table info available. #1 0xb7ebad4d in ber_memfree_x (p=0x7fffffff, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #2 0xb77af997 in ?? () from /usr/lib/libldap-2.4.so.2 No symbol table info available. #3 0xb7791a68 in ?? () from /usr/lib/libldap-2.4.so.2 No symbol table info available. #4 0xb77c0210 in _fini () from /usr/lib/libldap-2.4.so.2 No symbol table info available. #5 0xb7f28aff in ?? () from /lib/ld-linux.so.2 No symbol table info available. #6 0xb7f29447 in ?? () from /lib/ld-linux.so.2 No symbol table info available. #7 0xb7cb8cf4 in ?? () from /lib/libdl.so.2 No symbol table info available. #8 0xb7f239f6 in ?? () from /lib/ld-linux.so.2 No symbol table info available. #9 0xb7cb911c in ?? () from /lib/libdl.so.2 No symbol table info available. #10 0xb7cb8d2a in dlclose () from /lib/libdl.so.2 No symbol table info available. #11 0xb7ccf411 in _sasl_done_with_plugins () from /usr/lib/libsasl2.so.2 No symbol table info available. #12 0xb7cc7c90 in sasl_done () from /usr/lib/libsasl2.so.2 No symbol table info available. #13 0x080d9fb7 in slap_sasl_destroy () No symbol table info available. #14 0x080aed1b in slap_destroy () No symbol table info available. #15 0x08059fe2 in main () No symbol table info available.

1 0

(ITS#6128) slapd pcache assert
by luca＠OpenLDAP.org 15 May '09

15 May '09

Full_Name: Luca Scamoni Version: RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Slapd configured as proxy with pcache hits assert and dumped core. Here the interesting log lines: May 15 12:55:11 ficus01 slapd[14753]: conn=42385 fd=60 ACCEPT from IP=213.205.2.82:38177 (IP=10.12.160.23:9011) May 15 12:55:11 ficus01 slapd[14753]: conn=42385 op=0 SRCH base="ou=Actalis CA per Firma Digitale Qualificata,o=CNIPA" scope=0 deref=0 filter="(objectClass=* )" [...] May 15 12:55:21 ficus01 slapd[14753]: connection_input: conn=42385 deferring operation: awaiting write May 15 12:55:21 ficus01 slapd[14753]: connection_operation: conn 42385 unknown LDAP request 0x70 May 15 12:55:22 ficus01 slapd[14753]: conn=42385 op=1 DISCONNECT tag=120 err=2 text=unknown LDAP request May 15 12:55:22 ficus01 slapd[14753]: send_search_entry: conn 42385 ber write failed. Note the 10 seconds gap between the lines. In the meantime 6 more identical request completed without problems. Here the backtrace: #0 0x006207a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x0022e7a5 in raise () from /lib/tls/libc.so.6 No symbol table info available. #2 0x00230209 in abort () from /lib/tls/libc.so.6 No symbol table info available. #3 0x00227d91 in __assert_fail () from /lib/tls/libc.so.6 No symbol table info available. #4 0x080782b8 in connection_destroy (c=0xb7f57638) at ../../../servers/slapd/connection.c:623 connid = 2397679448 close_reason = 0x816e740 "\210ã\026\bøtc" sb = (Sockbuf *) 0x816e740 sd = 158208128 __PRETTY_FUNCTION__ = "connection_destroy" #5 0x08078d29 in connection_close (c=0xb7f57638) at ../../../servers/slapd/connection.c:828 __PRETTY_FUNCTION__ = "connection_close" #6 0x0807af2e in connection_resched (conn=0xb7f57638) at ../../../servers/slapd/connection.c:1679 op = (Operation *) 0x9ace698 __PRETTY_FUNCTION__ = "connection_resched" #7 0x08079a97 in connection_operation (ctx=0x1e5e210, arg_v=0x8ee9ae80) at ../../../servers/slapd/connection.c:1160 rc = -1025 op = (Operation *) 0x8ee9ae80 rs = {sr_type = REP_EXTENDED, sr_tag = 120, sr_msgid = 0, sr_err = 2, sr_matched = 0x0, sr_text = 0x812a91f "unknown LDAP request", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_sasl = {r_sasldata = 0x812cf25}, sru_extended = {r_rspoid = 0x812cf25 "1.3.6.1.4.1.1466.20036", r_rspdata = 0x0}, sru_search = {r_entry = 0x812cf25, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 4294967295 opidx = SLAP_OP_LAST conn = (Connection *) 0xb7f57638 memctx = (void *) 0x0 memctx_null = (void *) 0x0 memsiz = 3086312752 __PRETTY_FUNCTION__ = "connection_operation" #8 0x00b84389 in ldap_int_thread_pool_wrapper (xpool=0x9705ab0) at ../../../libraries/libldap_r/tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x9705ab0 task = (ldap_int_thread_task_t *) 0x99e6730 work_list = (ldap_int_tpool_plist_t *) 0x9705b30 ctx = {ltu_id = 31845280, ltu_key = {{ltk_key = 0x80793b5, ltk_data = 0x99c1308, ltk_free = 0x80791a5 <conn_counter_destroy>}, { ltk_key = 0x80e68c5, ltk_data = 0x99c13f8, ltk_free = 0x80e66d8 <slap_sl_mem_destroy>}, {ltk_key = 0x149f90, ltk_data = 0x99cae98, ltk_free = 0x141f67 <meta_back_candidates_keyfree>}, {ltk_key = 0x984d878, ltk_data = 0x99c7ed8, ltk_free = 0x94a4eb <bdb_reader_free>}, { ltk_key = 0x8092d23, ltk_data = 0x9933440, ltk_free = 0x8092c80 <slap_op_q_destroy>}, {ltk_key = 0x93a983, ltk_data = 0x8dd36008, ltk_free = 0x93a958 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 273 hash = 6007057 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #9 0x008893cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #10 0x002cfc3e in clone () from /lib/tls/libc.so.6 No symbol table info available. Any further info available

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by luca.scamoni＠sys-net.it 14 May '09

14 May '09

quanah(a)zimbra.com ha scritto: > --On May 14, 2009 9:10:27 AM +0000 hyc(a)symas.com wrote: > >> Luca Scamoni wrote: >>> Howard Chu ha scritto: >>>> In frame 1 print *ap >>>> >>> p *ap >>> $1 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags >>> = 0, a_next = 0x54149adc} >> Your frame 1 is pretty much impossible - you have oldattrs == newattrs, >> but in frame 2 the attr list was replaced by a duplicate (using >> attrs_dup, modify.c:94). Perhaps you've got a compiler bug. > > Hm, do you build with compiler optimizations enabled? I build all of my > OpenLDAP builds with -O0 at this point, due to too many issues cropping up > when optimized builds were used. > No. Optimization is disabled in my builds too Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. Gruppo Partners Associates via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by quanah＠zimbra.com 14 May '09

14 May '09

--On May 14, 2009 9:10:27 AM +0000 hyc(a)symas.com wrote: > Luca Scamoni wrote: >> Howard Chu ha scritto: >>> >>> In frame 1 print *ap >>> >> p *ap >> $1 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags >> = 0, a_next = 0x54149adc} > > Your frame 1 is pretty much impossible - you have oldattrs == newattrs, > but in frame 2 the attr list was replaced by a duplicate (using > attrs_dup, modify.c:94). Perhaps you've got a compiler bug. Hm, do you build with compiler optimizations enabled? I build all of my OpenLDAP builds with -O0 at this point, due to too many issues cropping up when optimized builds were used. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6127) sizelimit/timelimit ldap.conf(5) don't specify units
by quanah＠OpenLDAP.org 14 May '09

14 May '09

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.47.0.2) The descriptions for the sizelimit and timelimit directives don't specify the units in use, in contrast to the timeout directive. It's entirely possible new users may not know what those limits imply. For example, is the timelimit milliseconds? seconds? etc. Same with sizelimit -- Entries, kbs? >From Debian bug#528695. --Quanah

1 0

Problems with slapd-meta
by sebastian.mattheis＠education-siemens.com 14 May '09

14 May '09

Hello OpenLDAP-Developers, configuring an meta-proxy i got 2 problems: The situation: I have a meta-proxy with a saslauthd that forwards the authentication-identities to meta-proxy. The meta-proxy resolves the uid to a dn and should look up the credentials in the targets. To do this the meta-proxy should authenticate to the target via sasl (idassert-bind with bindmethod sasl). 1. That works so far, but either the proxy authenticates with the binddn=cn and credential=secret of the idassert-bind directives using simple bind to look up the users credentials and forward all search requests only with this binddn-identity and not the users identity(this happens with mode=legacy) or the proxy only uses anonymous bind to look up the users entry for authentication (this happens with mode=self or mode=legacy flags=override). In no case the users identity is used to authenticate and authorize. The result is that the ACLs at the target dont matter for the user. I thought, okay no problem then I configure the proxy with the ACLs and let him authenticate at the target with what identity he wants. But now there is the 2nd problem. To the situation of problem 2: I have to implement a contact-directory for my student research project. In this directory every user shall have a contact-list with members. Only the user itself and the members of his individual contact-list should have access to the users data. I solved it in a test only on a slapd with bdb-backend by adding an entry with the objectclass groupOfNames and added a ACL with set.regex (You can see this in the config-files). In the test it works fine. 2. But the problem comes with the meta-proxy. I used the same ACLs to implement the mentioned user-contact-list-member-permission-feature but the slapd cant resolve the authenticating identity as member and cant grant the necessary permission i.e. read access to this identity despite it is added as a member in the groupOfNames. In the log-output i noticed, that the membership is ignored and the next rule-pattern is used (*) and only this permissions are granted (auth). Can you help me to fix this problem? Im sure I have some mistakes in the configurations. But where and what? In other case it would help to know that it is a bug and I can promise in my research project it would work if there isnt a bug. Thanks a lot Sebastian Mattheis Appending: The long long lists of configuration files and logfiles Proxy slapd.conf: # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow bind_v2 # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel none logfile slapd.logfile # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap #moduleload back_hdb #moduleload back_bdb moduleload back_monitor #moduleload syncprov moduleload back_ldap moduleload back_meta # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # The server-ID must identify the server in one logical replication # domain as unique. (A ServerID should not be used in logical # replication-domain twice!) serverID 1 # In use the referral-directive refers to a server on a higher # hierarchical level or to a server on the same hierarchical # level in the DIT. (To refer to a server, that represents # subtree use a referral-entry in the DIT of this server. # For this you have to use the objectclass referral and # maybe in combination with the objectclass extensibleObject. #referral ldap://192.168.112.14 # Access Control Lists to verify Users and set access-rights # and permissions. #access to * # by dn="cn=datadmin,dc=gac" write # by anonymous auth # by * none #access to * # by self auth access to attrs=userPassword by dn.subtree="cn=datadmin,dc=gac" write by * auth access to attrs=cn by users read by * auth access to dn.regex="cn=([^,]*),o=([^,]*),dc=gac" attrs=gn,sn,l,mail,mobile by self read by set.regex="[cn=contacts,cn=$1,o=$2,dc=gac]/member" read by * auth access to dn.regex="cn=([^,]*),o=([^,]*),dc=gac" by users read by * auth access to dn.regex="cn=contacts,cn=([^,]*),o=([^,]*),dc=gac" by dn.regex="cn=$1,o=$2,dc=gac" write by set.regex="[cn=contacts,cn=$1,o=$2,dc=gac]/member" read by * none #access to dn.regex="cn=requests,cn=([^,]*),o=([^,]*),dc=gac" # by users write # by * none access to dn.sub="dc=gac" by users search access to * by dn.subtree="cn=datadmin,dc=gac" write by * auth ####################################################################### # Specific Backend Directives for "config": # Backend specific directives apply to this backend until another # 'backend' directive occurs database config rootdn "cn=config" rootpw "confpass" ####################################################################### # Specific Backend Directives for "monitor": # Backend specific directives apply to this backend until another # 'backend' directive occurs database monitor ####################################################################### # Specific Directives for database #1, of type hdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database meta # The base of your directory in database #1 suffix "dc=gac" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=datadmin,dc=gac" #rootpw "datadminpass" # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only #access to attrs=userPassword,shadowLastChange # by dn="cn=datadmin,dc=gac" write # by anonymous auth # by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read # SASL Authentication authz-regexp uid=datadmin,cn=digest-md5,cn=auth cn=datadmin,dc=gac authz-regexp uid=([^,@]*)@([^,]*),cn=digest-md5,cn=auth cn=$1,o=$2,dc=gac # Following directives refer to the encapsulated LDAP-server holding # bdb's. The subtree-exclude directive specifies the subtree in the # base described by the URI closer. uri ldap://192.168.112.11/dc=gac acl-authcDN cn=datadmin,dc=gac acl-passwd datadminpass idassert-bind bindmethod=sasl binddn="cn=datadmin,dc=gac" credentials=datadminpass saslmech=digest-md5 # authzId=u:datadmin mode=legacy # flags=override #acl-bind # bindmethod=sasl # credentials=datadminpass # saslmech=digest-md5 # authcID=datadmin subtree-exclude o=fr,dc=gac #uri ldap://192.168.112.12/dc=gac #acl-authcDN cn=datadmin,dc=gac #acl-passwd datadminpass #subtree-exclude o=fr,dc=gac #uri ldap://192.168.112.13/o=fr,dc=gac #acl-authcDN cn=datadmin,dc=gac #acl-passwd datadminpass Target-slapd.conf # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ####################################################################### # Global Directives: # Features to permit #allow proxy_authz_anon # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values loglevel none logfile /etc/ldap/slapd.logfile # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap #moduleload back_hdb moduleload back_bdb moduleload back_monitor moduleload syncprov # The maximum number of entries that is returned for a search operation sizelimit 500 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # The server-ID must identify the server in one logical replication # domain as unique. (A ServerID should not be used in logical # replication-domain twice!) serverID 1 # In use the referral-directive refers to a server on a higher # hierarchical level or to a server on the same hierarchical # level in the DIT. (To refer to a server, that represents # subtree use a referral-entry in the DIT of this server. # For this you have to use the objectclass referral and # maybe in combination with the objectclass extensibleObject. #referral ldap://192.168.112.14 # Security settings to encrypt passwords and use a strong bind via # SASL authentication. #require SASL #password-hash {SSHA} # Allow LDAP-Proxy to authenticate users by their self identity. #authz-policy both ####################################################################### # Specific Backend Directives for "config": # Backend specific directives apply to this backend until another # 'backend' directive occurs database config rootdn "cn=config" rootpw "confpass" ####################################################################### # Specific Backend Directives for "monitor": # Backend specific directives apply to this backend until another # 'backend' directive occurs database monitor ####################################################################### # Specific Directives for database #1, of type bdb: # Database specific directives apply to this databasse until another # 'database' directive occurs database bdb # The base of your directory in database #1 suffix "dc=gac" # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=datadmin,dc=gac" rootpw "datadminpass" # Where the database file are physically stored for database #1 directory "/var/ldap/node1.gac" # The dbconfig settings are used to generate a DB_CONFIG file the first # time slapd starts. They do NOT override existing an existing DB_CONFIG # file. You should therefore change these settings in DB_CONFIG directly # or remove DB_CONFIG and restart slapd for changes to take effect. # For the Debian package we use 2MB as default but be sure to update this # value if you have plenty of RAM dbconfig set_cachesize 0 2097152 0 # Sven Hartge reported that he had to set this value incredibly high # to get slapd running at all. See http://bugs.debian.org/303057 for more # information. # Number of objects that can be locked at the same time. dbconfig set_lk_max_objects 1500 # Number of locks (both requested and granted) dbconfig set_lk_max_locks 1500 # Number of lockers dbconfig set_lk_max_lockers 1500 # Indexing options for database #1 index objectClass eq index entryCSN,entryUUID eq # Save the time that the entry gets modified, for database #1 lastmod on # Checkpoint the BerkeleyDB database periodically in case of system # failure and to speed slapd shutdown. checkpoint 512 30 # Where to store the replica logs for database #1 # replogfile /var/lib/ldap/replog # The userPassword by default can be changed # by the entry owning it if they are authenticated. # Others should not be able to see it, except the # admin entry below # These access lines apply to database #1 only #access to attrs=userPassword,shadowLastChange # by dn="cn=datadmin,dc=gac" write # by anonymous auth # by * none # Ensure read access to the base for things like # supportedSASLMechanisms. Without this you may # have problems with SASL not knowing what # mechanisms are available and the like. # Note that this is covered by the 'access to *' # ACL below too but if you change that as people # are wont to do you'll still need this if you # want SASL (and possible other things) to work # happily. access to dn.base="" by * read #SASL Authentication authz-regexp uid=datadmin,cn=([^,]*),cn=auth cn=datadmin,dc=gac authz-regexp uid=root,cn=([^,]*),cn=auth cn=datadmin,dc=gac authz-regexp uid=([^,]*),cn=digest-md5,cn=auth cn=$1,o=de,dc=gac # Access Control Lists to verify Users and set access # and permissions. #access to * # by dn.sub="cn=datadmin,dc=gac" write # by * read access to attrs=userPassword by dn.subtree="cn=datadmin,dc=gac" write by * search by * auth access to attrs=cn by users read by * search by * auth access to dn.regex="cn=([^,]*),o=([^,]*),dc=gac" attrs=gn,sn,l,mail,mobile by self read by set.regex="[cn=contacts,cn=$1,o=$2,dc=gac]/member" read by * search by * auth access to dn.regex="cn=([^,]*),o=([^,]*),dc=gac" by users read by * search by * auth access to dn.regex="cn=contacts,cn=([^,]*),o=([^,]*),dc=gac" by dn.regex="cn=$1,o=$2,dc=gac" write by set.regex="[cn=contacts,cn=$1,o=$2,dc=gac]/member" read by * none #access to dn.regex="cn=requests,cn=([^,]*),o=([^,]*),dc=gac" # by users write # by * none access to dn.sub="dc=gac" by users search access to * by dn.subtree="cn=datadmin,dc=gac" write by * search by * auth # For Netscape Roaming support, each user gets a roaming # profile for which they have write access to #access to dn=".*,ou=Roaming,o=morsnet" # by dn="cn=admin,dc=gac" write # by dnattr=owner write # Directives for Mulit-Master-SyncReplication #syncrepl rid=01 # provider="ldap://192.168.112.12" # sizelimit=unlimited # binddn="cn=datadmin,dc=gac" # credentials=datadminpass # bindmethod=simple # searchbase="dc=gac" # schemachecking=off # type=refreshAndPersist # retry="10 +" # scope=sub # filter="(objectclass=*)" # attrs="*" #mirrormode on #overlay syncprov #syncprov-checkpoint 100 10 #syncprov-sessionlog 100 ####################################################################### # Specific Directives for database #2, of type 'other' (can be hdb too): # Database specific directives apply to this databasse until another # 'database' directive occurs #database <other> # The base of your directory for database #2 #suffix "dc=gac" Proxy-Log daemon: activity on: slap_listener_activate(8): >>> slap_listener(ldap:///) daemon: listen=8, new connection on 11 daemon: added 11r (active) listener=(nil) conn=3 fd=11 ACCEPT from IP=192.168.112.12:42372 (IP=0.0.0.0:389) daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL 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: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ber_get_next ldap_read: want=8, got=8 0000: 30 18 02 01 01 60 13 02 0....`.. ldap_read: want=18, got=18 0000: 01 03 04 00 a3 0c 04 0a 44 49 47 45 53 54 2d 4d ........DIGEST-M 0010: 44 35 D5 ber_get_next: tag 0x30 len 24 contents: ber_dump: buf=0x88ede60 ptr=0x88ede60 end=0x88ede78 len=24 0000: 02 01 01 60 13 02 01 03 04 00 a3 0c 04 0a 44 49 ...`..........DI 0010: 47 45 53 54 2d 4d 44 35 GEST-MD5 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=3 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x88ede60 ptr=0x88ede63 end=0x88ede78 len=21 0000: 60 13 02 01 03 04 00 a3 0c 04 0a 44 49 47 45 53 `..........DIGES 0010: 54 2d 4d 44 35 T-MD5 ber_scanf fmt ({m) ber: ber_dump: buf=0x88ede60 ptr=0x88ede6a end=0x88ede78 len=14 0000: 00 0c 04 0a 44 49 47 45 53 54 2d 4d 44 35 ....DIGEST-MD5 ber_scanf fmt (}}) ber: ber_dump: buf=0x88ede60 ptr=0x88ede78 end=0x88ede78 len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> conn=3 op=0 BIND dn="" method=163 do_bind: dn () SASL mech DIGEST-MD5 ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0 SASL [conn=3] Debug: DIGEST-MD5 server step 1 send_ldap_sasl: err=14 len=181 send_ldap_response: msgid=1 tag=97 err=14 ber_flush2: 228 bytes to sd 11 0000: 30 81 e1 02 01 01 61 81 db 0a 01 0e 04 00 04 1c 0.....a......... 0010: 53 41 53 4c 28 30 29 3a 20 73 75 63 63 65 73 73 SASL(0): success 0020: 66 75 6c 20 72 65 73 75 6c 74 3a 20 87 81 b5 6e ful result: ...n 0030: 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a 7a 43 4b once="RGB4/njzCK 0040: 65 42 59 38 62 36 35 69 77 48 70 47 77 64 6e 37 eBY8b65iwHpGwdn7 0050: 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a 70 5a 4d dK14UwoZjboIzpZM 0060: 45 3d 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e E=",realm="node. 0070: 67 61 63 22 2c 71 6f 70 3d 22 61 75 74 68 2c 61 gac",qop="auth,a 0080: 75 74 68 2d 69 6e 74 2c 61 75 74 68 2d 63 6f 6e uth-int,auth-con 0090: 66 22 2c 63 69 70 68 65 72 3d 22 72 63 34 2d 34 f",cipher="rc4-4 00a0: 30 2c 72 63 34 2d 35 36 2c 72 63 34 2c 64 65 73 0,rc4-56,rc4,des 00b0: 2c 33 64 65 73 22 2c 6d 61 78 62 75 66 3d 36 35 ,3des",maxbuf=65 00c0: 35 33 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 536,charset=utf- 00d0: 38 2c 61 6c 67 6f 72 69 74 68 6d 3d 6d 64 35 2d 8,algorithm=md5- 00e0: 73 65 73 73 sess ldap_write: want=228, written=228 0000: 30 81 e1 02 01 01 61 81 db 0a 01 0e 04 00 04 1c 0.....a......... 0010: 53 41 53 4c 28 30 29 3a 20 73 75 63 63 65 73 73 SASL(0): success 0020: 66 75 6c 20 72 65 73 75 6c 74 3a 20 87 81 b5 6e ful result: ...n 0030: 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a 7a 43 4b once="RGB4/njzCK 0040: 65 42 59 38 62 36 35 69 77 48 70 47 77 64 6e 37 eBY8b65iwHpGwdn7 0050: 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a 70 5a 4d dK14UwoZjboIzpZM 0060: 45 3d 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e E=",realm="node. 0070: 67 61 63 22 2c 71 6f 70 3d 22 61 75 74 68 2c 61 gac",qop="auth,a 0080: 75 74 68 2d 69 6e 74 2c 61 75 74 68 2d 63 6f 6e uth-int,auth-con 0090: 66 22 2c 63 69 70 68 65 72 3d 22 72 63 34 2d 34 f",cipher="rc4-4 00a0: 30 2c 72 63 34 2d 35 36 2c 72 63 34 2c 64 65 73 0,rc4-56,rc4,des 00b0: 2c 33 64 65 73 22 2c 6d 61 78 62 75 66 3d 36 35 ,3des",maxbuf=65 00c0: 35 33 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 536,charset=utf- 00d0: 38 2c 61 6c 67 6f 72 69 74 68 6d 3d 6d 64 35 2d 8,algorithm=md5- daemon: activity on 1 descriptor 00e0: 73 65 73 73 sess conn=3 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: <== slap_sasl_bind: rc=14 daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ber_get_next ldap_read: want=8, got=8 0000: 30 82 01 29 02 01 02 60 0..)...` ldap_read: want=293, got=293 0000: 82 01 22 02 01 03 04 00 a3 82 01 19 04 0a 44 49 .."...........DI 0010: 47 45 53 54 2d 4d 44 35 04 82 01 09 75 73 65 72 GEST-MD5....user 0020: 6e 61 6d 65 3d 22 75 73 65 72 32 40 64 65 22 2c name="user2@de", 0030: 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 realm="node.gac" 0040: 2c 6e 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a 7a ,nonce="RGB4/njz 0050: 43 4b 65 42 59 38 62 36 35 69 77 48 70 47 77 64 CKeBY8b65iwHpGwd 0060: 6e 37 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a 70 n7dK14UwoZjboIzp 0070: 5a 4d 45 3d 22 2c 63 6e 6f 6e 63 65 3d 22 7a 32 ZME=",cnonce="z2 0080: 69 6c 2f 6c 32 61 39 77 72 47 73 7a 2b 6b 32 2b il/l2a9wrGsz+k2+ 0090: 59 67 6d 56 46 39 55 4d 72 5a 55 6a 59 6a 70 54 YgmVF9UMrZUjYjpT 00a0: 62 54 56 5a 6f 68 7a 45 67 3d 22 2c 6e 63 3d 30 bTVZohzEg=",nc=0 00b0: 30 30 30 30 30 30 31 2c 71 6f 70 3d 61 75 74 68 0000001,qop=auth 00c0: 2d 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 34 -conf,cipher=rc4 00d0: 2c 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 35 ,maxbuf=16777215 00e0: 2c 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 61 ,digest-uri="lda 00f0: 70 2f 6e 6f 64 65 2e 67 61 63 22 2c 72 65 73 70 p/node.gac",resp 0100: 6f 6e 73 65 3d 38 33 35 62 65 33 64 32 62 65 66 onse=835be3d2bef 0110: 30 31 32 34 35 62 66 66 61 33 35 66 30 64 39 39 01245bffa35f0d99 0120: 64 66 32 62 34 df2b4 ber_get_next: tag 0x30 len 297 contents: ber_dump: buf=0x89233e8 ptr=0x89233e8 end=0x8923511 len=297 0000: 02 01 02 60 82 01 22 02 01 03 04 00 a3 82 01 19 ...`.."......... 0010: 04 0a 44 49 47 45 53 54 2d 4d 44 35 04 82 01 09 ..DIGEST-MD5.... 0020: 75 73 65 72 6e 61 6d 65 3d 22 75 73 65 72 32 40 username="user2@ 0030: 64 65 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e de",realm="node. 0040: 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 52 47 42 34 gac",nonce="RGB4 0050: 2f 6e 6a 7a 43 4b 65 42 59 38 62 36 35 69 77 48 /njzCKeBY8b65iwH 0060: 70 47 77 64 6e 37 64 4b 31 34 55 77 6f 5a 6a 62 pGwdn7dK14UwoZjb 0070: 6f 49 7a 70 5a 4d 45 3d 22 2c 63 6e 6f 6e 63 65 oIzpZME=",cnonce 0080: 3d 22 7a 32 69 6c 2f 6c 32 61 39 77 72 47 73 7a ="z2il/l2a9wrGsz 0090: 2b 6b 32 2b 59 67 6d 56 46 39 55 4d 72 5a 55 6a +k2+YgmVF9UMrZUj 00a0: 59 6a 70 54 62 54 56 5a 6f 68 7a 45 67 3d 22 2c YjpTbTVZohzEg=", 00b0: 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f 70 3d nc=00000001,qop= 00c0: 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 65 72 auth-conf,cipher 00d0: 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 37 37 =rc4,maxbuf=1677 00e0: 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 69 3d 7215,digest-uri= 00f0: 22 6c 64 61 70 2f 6e 6f 64 65 2e 67 61 63 22 2c "ldap/node.gac", 0100: 72 65 73 70 6f 6e 73 65 3d 38 33 35 62 65 33 64 response=835be3d 0110: 32 62 65 66 30 31 32 34 35 62 66 66 61 33 35 66 2bef01245bffa35f 0120: 30 64 39 39 64 66 32 62 34 0d99df2b4 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=3 op=1 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x89233e8 ptr=0x89233eb end=0x8923511 len=294 daemon: activity on 1 descriptor 0000: 60 82 01 22 02 01 03 04 00 a3 82 01 19 04 0a 44 `.."...........D 0010: 49 47 45 53 54 2d 4d 44 35 04 82 01 09 75 73 65 IGEST-MD5....use 0020: 72 6e 61 6d 65 3d 22 75 73 65 72 32 40 64 65 22 rname="user2@de" 0030: 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 ,realm="node.gac 0040: 22 2c 6e 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a ",nonce="RGB4/nj 0050: 7a 43 4b 65 42 59 38 62 36 35 69 77 48 70 47 77 zCKeBY8b65iwHpGw 0060: 64 6e 37 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a dn7dK14UwoZjboIz 0070: 70 5a 4d 45 3d 22 2c 63 6e 6f 6e 63 65 3d 22 7a pZME=",cnonce="z 0080: 32 69 6c 2f 6c 32 61 39 77 72 47 73 7a 2b 6b 32 2il/l2a9wrGsz+k2 0090: 2b 59 67 6d 56 46 39 55 4d 72 5a 55 6a 59 6a 70 +YgmVF9UMrZUjYjp 00a0: 54 62 54 56 5a 6f 68 7a 45 67 3d 22 2c 6e 63 3d TbTVZohzEg=",nc= 00b0: 30 30 30 30 30 30 30 31 2c 71 6f 70 3d 61 75 74 00000001,qop=aut 00c0: 68 2d 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 h-conf,cipher=rc 00d0: 34 2c 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 4,maxbuf=1677721 00e0: 35 2c 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 5,digest-uri="ld 00f0: 61 70 2f 6e 6f 64 65 2e 67 61 63 22 2c 72 65 73 ap/node.gac",res 0100: 70 6f 6e 73 65 3d 38 33 35 62 65 33 64 32 62 65 ponse=835be3d2be 0110: 66 30 31 32 34 35 62 66 66 61 33 35 66 30 64 39 f01245bffa35f0d9 0120: 39 64 66 32 62 34 9df2b4 ber_scanf fmt ({m) ber: ber_dump: buf=0x89233e8 ptr=0x89233f4 end=0x8923511 len=285 0000: 00 82 01 19 04 0a 44 49 47 45 53 54 2d 4d 44 35 ......DIGEST-MD5 0010: 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 75 73 ....username="us 0020: 65 72 32 40 64 65 22 2c 72 65 61 6c 6d 3d 22 6e er2@de",realm="n 0030: 6f 64 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 ode.gac",nonce=" 0040: 52 47 42 34 2f 6e 6a 7a 43 4b 65 42 59 38 62 36 RGB4/njzCKeBY8b6 0050: 35 69 77 48 70 47 77 64 6e 37 64 4b 31 34 55 77 5iwHpGwdn7dK14Uw 0060: 6f 5a 6a 62 6f 49 7a 70 5a 4d 45 3d 22 2c 63 6e oZjboIzpZME=",cn 0070: 6f 6e 63 65 3d 22 7a 32 69 6c 2f 6c 32 61 39 77 once="z2il/l2a9w 0080: 72 47 73 7a 2b 6b 32 2b 59 67 6d 56 46 39 55 4d rGsz+k2+YgmVF9UM 0090: 72 5a 55 6a 59 6a 70 54 62 54 56 5a 6f 68 7a 45 rZUjYjpTbTVZohzE 00a0: 67 3d 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c g=",nc=00000001, 00b0: 71 6f 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 qop=auth-conf,ci 00c0: 70 68 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d pher=rc4,maxbuf= 00d0: 31 36 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 16777215,digest- 00e0: 75 72 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2e 67 uri="ldap/node.g 00f0: 61 63 22 2c 72 65 73 70 6f 6e 73 65 3d 38 33 35 ac",response=835 0100: 62 65 33 64 32 62 65 66 30 31 32 34 35 62 66 66 be3d2bef01245bff 0110: 61 33 35 66 30 64 39 39 64 66 32 62 34 a35f0d99df2b4 ber_scanf fmt (m) ber: ber_dump: buf=0x89233e8 ptr=0x8923404 end=0x8923511 len=269 0000: 00 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 75 73 ....username="us 0010: 65 72 32 40 64 65 22 2c 72 65 61 6c 6d 3d 22 6e er2@de",realm="n 0020: 6f 64 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 ode.gac",nonce=" 0030: 52 47 42 34 2f 6e 6a 7a 43 4b 65 42 59 38 62 36 RGB4/njzCKeBY8b6 0040: 35 69 77 48 70 47 77 64 6e 37 64 4b 31 34 55 77 5iwHpGwdn7dK14Uw 0050: 6f 5a 6a 62 6f 49 7a 70 5a 4d 45 3d 22 2c 63 6e oZjboIzpZME=",cn 0060: 6f 6e 63 65 3d 22 7a 32 69 6c 2f 6c 32 61 39 77 once="z2il/l2a9w 0070: 72 47 73 7a 2b 6b 32 2b 59 67 6d 56 46 39 55 4d rGsz+k2+YgmVF9UM 0080: 72 5a 55 6a 59 6a 70 54 62 54 56 5a 6f 68 7a 45 rZUjYjpTbTVZohzE 0090: 67 3d 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c g=",nc=00000001, 00a0: 71 6f 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 qop=auth-conf,ci 00b0: 70 68 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d pher=rc4,maxbuf= 00c0: 31 36 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 16777215,digest- 00d0: 75 72 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2e 67 uri="ldap/node.g 00e0: 61 63 22 2c 72 65 73 70 6f 6e 73 65 3d 38 33 35 ac",response=835 00f0: 62 65 33 64 32 62 65 66 30 31 32 34 35 62 66 66 be3d2bef01245bff 0100: 61 33 35 66 30 64 39 39 64 66 32 62 34 a35f0d99df2b4 ber_scanf fmt (}}) ber: ber_dump: buf=0x89233e8 ptr=0x8923511 end=0x8923511 len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> conn=3 op=1 BIND dn="" method=163 do_bind: dn () SASL mech DIGEST-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=265 SASL [conn=3] Debug: DIGEST-MD5 server step 2 SASL Canonicalize [conn=3]: authcid="user2@de" slap_sasl_getdn: conn 3 id=user2@de [len=8] => ldap_dn2bv(16) <= ldap_dn2bv(uid=user2@de,cn=DIGEST-MD5,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=user2@de,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=user2@de,cn=DIGEST-MD5,cn=auth> => ldap_bv2dn(uid=user2@de,cn=DIGEST-MD5,cn=auth,0) <= ldap_bv2dn(uid=user2@de,cn=DIGEST-MD5,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=user2@de,cn=digest-md5,cn=auth)=0 <<< dnNormalize: <uid=user2@de,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=user2@de,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=user2@de,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=datadmin,cn=digest-md5,cn=auth' string='uid=user2@de,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_rule_apply rule='uid=([^,@]*)@([^,]*),cn=digest-md5,cn=auth' string='uid=user2@de,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'cn=user2,o=de,dc=gac'} [rw] authid: "uid=user2@de,cn=digest-md5,cn=auth" -> "cn=user2,o=de,dc=gac" slap_parseURI: parsing cn=user2,o=de,dc=gac ldap_url_parse_ext(cn=user2,o=de,dc=gac) >>> dnNormalize: <cn=user2,o=de,dc=gac> => ldap_bv2dn(cn=user2,o=de,dc=gac,0) <= ldap_bv2dn(cn=user2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnNormalize: <cn=user2,o=de,dc=gac> <==slap_sasl2dn: Converted SASL name to cn=user2,o=de,dc=gac slap_sasl_getdn: dn:id converted to cn=user2,o=de,dc=gac SASL Canonicalize [conn=3]: slapAuthcDN="cn=user2,o=de,dc=gac" conn=3 op=1: meta_back_getconn[0] conn=3 op=1 meta_back_getconn: candidates=1 conn=-1 fetched conn=3 op=1 >>> meta_back_search_start[0] conn=3 op=1 >>> meta_search_dobind_init[0] conn=3 op=1 <<< meta_search_dobind_init[0]=1 [rw] searchBase: "cn=user2,o=de,dc=gac" -> "cn=user2,o=de,dc=gac" [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" ldap_search_ext put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x8924c28 ptr=0x8924c28 end=0x8924c63 len=59 0000: 30 39 02 01 05 63 34 04 14 63 6e 3d 75 73 65 72 09...c4..cn=user 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 0a 01 00 2,o=de,dc=gac... 0020: 0a 01 00 02 01 01 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 30 00 jectClass0. ber_scanf fmt ({) ber: ber_dump: buf=0x8924c28 ptr=0x8924c2d end=0x8924c63 len=54 0000: 63 34 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 c4..cn=user2,o=d 0010: 65 2c 64 63 3d 67 61 63 0a 01 00 0a 01 00 02 01 e,dc=gac........ 0020: 01 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 43 .........objectC 0030: 6c 61 73 73 30 00 lass0. ber_flush2: 59 bytes to sd 12 0000: 30 39 02 01 05 63 34 04 14 63 6e 3d 75 73 65 72 09...c4..cn=user 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 0a 01 00 2,o=de,dc=gac... 0020: 0a 01 00 02 01 01 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 30 00 jectClass0. ldap_write: want=59, written=59 0000: 30 39 02 01 05 63 34 04 14 63 6e 3d 75 73 65 72 09...c4..cn=user 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 0a 01 00 2,o=de,dc=gac... 0020: 0a 01 00 02 01 01 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 30 00 jectClass0. conn=3 op=1 <<< meta_back_search_start[0]=1 conn=3 op=1 meta_back_search: ncandidates=1 cnd="*" ldap_result ld 0x8900620 msgid 5 wait4msg ld 0x8900620 msgid 5 (timeout 0 usec) wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: Empty ld 0x8900620 response count 0 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 NULL ldap_int_select daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL ldap_result ld 0x8900620 msgid 5 wait4msg ld 0x8900620 msgid 5 (timeout 100000 usec) wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: Empty ld 0x8900620 response count 0 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 NULL ldap_int_select read1msg: ld 0x8900620 msgid 5 all 2 ber_get_next ldap_read: want=8, got=8 0000: 30 81 8a 02 01 05 64 81 0.....d. ldap_read: want=133, got=133 0000: 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d 64 65 ...cn=User2,o=de 0010: 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f 62 6a ,dc=gac0l0...obj 0020: 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 74 ectClass1...inet 0030: 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 6e 31 OrgPerson0...cn1 0040: 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 07 ...User20...sn1. 0050: 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 6e ..User20...given 0060: 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 04 Name1...User20.. 0070: 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 .userPassword1.. 0080: 04 70 61 73 73 .pass ber_get_next: tag 0x30 len 138 contents: ber_dump: buf=0x89000f8 ptr=0x89000f8 end=0x8900182 len=138 0000: 02 01 05 64 81 84 04 14 63 6e 3d 55 73 65 72 32 ...d....cn=User2 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e ,o=de,dc=gac0l0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d .inetOrgPerson0. 0040: 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d 04 ..cn1...User20.. 0050: 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 09 .sn1...User20... 0060: 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 givenName1...Use 0070: 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f r20...userPasswo 0080: 72 64 31 06 04 04 70 61 73 73 rd1...pass read1msg: ld 0x8900620 msgid 5 message type search-entry wait4msg ld 0x8900620 0 s 94885 us to go wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: * msgid 5, type 100 ld 0x8900620 response count 1 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 msgid 5, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x89000f8 ptr=0x89000fb end=0x8900182 len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f de,dc=gac0l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e bjectClass1...in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 31 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n1...User20...sn 0050: 31 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 1...User20...giv 0060: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0080: 06 04 04 70 61 73 73 ...pass [rw] searchResult: "cn=User2,o=de,dc=gac" -> "cn=User2,o=de,dc=gac" >>> dnPrettyNormal: <cn=User2,o=de,dc=gac> => ldap_bv2dn(cn=User2,o=de,dc=gac,0) <= ldap_bv2dn(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=User2,o=de,dc=gac>, <cn=user2,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900116 end=0x8900182 len=108 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0030: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0040: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0050: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0060: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x8900125 end=0x8900182 len=93 0000: 00 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f ....inetOrgPerso 0010: 6e 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 n0...cn1...User2 0020: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0030: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0040: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0050: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900136 end=0x8900182 len=76 0000: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0010: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0020: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0030: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0040: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x890013c end=0x8900182 len=70 0000: 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 ....User20...sn1 0010: 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 ...User20...give 0020: 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 nName1...User20. 0030: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 ..userPassword1. 0040: 04 04 70 61 73 73 ..pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900145 end=0x8900182 len=61 0000: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0010: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0020: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0030: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x890014b end=0x8900182 len=55 0000: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0010: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0020: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0030: 06 04 04 70 61 73 73 ...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900154 end=0x8900182 len=46 0000: 30 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 0...givenName1.. 0010: 05 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 .User20...userPa 0020: 73 73 77 6f 72 64 31 06 04 04 70 61 73 73 ssword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x8900161 end=0x8900182 len=33 0000: 00 07 04 05 55 73 65 72 32 30 16 04 0c 75 73 65 ....User20...use 0010: 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 rPassword1...pas 0020: 73 s ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x890016a end=0x8900182 len=24 0000: 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 0...userPassword 0010: 31 06 04 04 70 61 73 73 1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x890017a end=0x8900182 len=8 0000: 00 06 04 04 70 61 73 73 ....pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900182 end=0x8900182 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x89000f8 ptr=0x89000fb end=0x8900182 len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 00 6c 30 1e 04 0b 6f de,dc=gac.l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 00 0f 04 0d 69 6e bjectClass....in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n....User20...sn 0050: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0060: 65 6e 4e 61 6d 65 00 07 04 05 55 73 65 72 32 30 enName....User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 00 ...userPassword. 0080: 06 04 04 70 61 73 73 ...pass => access_allowed: auth access to "cn=User2,o=de,dc=gac" "userPassword" requested => dn: [1] => acl_get: [2] attr userPassword => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "userPassword" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: cn=datadmin,dc=gac <= check a_dn_pat: * <= acl_mask: [2] applying auth(=xd) (stop) <= acl_mask: [2] mask: auth(=xd) => slap_access_allowed: auth access granted by auth(=xd) => access_allowed: auth access granted by auth(=xd) slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined ldap_msgfree ldap_result ld 0x8900620 msgid 5 wait4msg ld 0x8900620 msgid 5 (timeout 0 usec) wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: Empty ld 0x8900620 response count 0 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 NULL ldap_int_select read1msg: ld 0x8900620 msgid 5 all 2 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 05 65 07 0a 0....e.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x88ecb80 ptr=0x88ecb80 end=0x88ecb8c len=12 0000: 02 01 05 65 07 0a 01 00 04 00 04 00 ...e........ read1msg: ld 0x8900620 msgid 5 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x88ecb80 ptr=0x88ecb83 end=0x88ecb8c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ read1msg: ld 0x8900620 0 new referrals read1msg: mark request completed, ld 0x8900620 msgid 5 request done: ld 0x8900620 msgid 5 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 5, msgid 5) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x88ecb80 ptr=0x88ecb83 end=0x88ecb8c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ ber_scanf fmt (}) ber: ber_dump: buf=0x88ecb80 ptr=0x88ecb8c end=0x88ecb8c len=0 conn=3 op=1 meta_back_search[0] match="" err=0. ldap_msgfree send_ldap_result: conn=3 op=1 p=3 send_ldap_result: err=0 matched="" text="" SASL Canonicalize [conn=3]: authzid="user2@de" SASL proxy authorize [conn=3]: authcid="user2@de" authzid="user2@de" conn=3 op=1 BIND authcid="user2@de" authzid="user2@de" SASL Authorize [conn=3]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=40 conn=3 op=1 BIND dn="cn=user2,o=de,dc=gac" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 do_bind: SASL/DIGEST-MD5 bind: dn="cn=user2,o=de,dc=gac" sasl_ssf=128 send_ldap_response: msgid=2 tag=97 err=0 ber_flush2: 56 bytes to sd 11 0000: 30 36 02 01 02 61 31 0a 01 00 04 00 04 00 87 28 06...a1........( 0010: 72 73 70 61 75 74 68 3d 36 34 64 32 34 61 33 66 rspauth=64d24a3f 0020: 35 36 32 65 64 62 62 64 35 66 39 61 33 61 62 62 562edbbd5f9a3abb 0030: 36 34 35 39 34 62 37 61 64594b7a ldap_write: want=56, written=56 0000: 30 36 02 01 02 61 31 0a 01 00 04 00 04 00 87 28 06...a1........( 0010: 72 73 70 61 75 74 68 3d 36 34 64 32 34 61 33 66 rspauth=64d24a3f 0020: 35 36 32 65 64 62 62 64 35 66 39 61 33 61 62 62 562edbbd5f9a3abb 0030: 36 34 35 39 34 62 37 61 64594b7a conn=3 op=1 RESULT tag=97 err=0 text= <== slap_sasl_bind: rc=0 daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ldap_pvt_sasl_install ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 3d ...= sasl_read: want=61, got=61 0000: 61 16 8b 42 1b 22 4d 2a 76 d5 8a 4c ae c0 47 ea a..B."M*v..L..G. 0010: 15 10 7e 7f a7 72 20 20 d9 cc d5 f6 47 ca e4 01 ..~..r ....G... 0020: 9f 09 d0 1e 86 e0 a2 7e 23 a4 fd 64 2d 1b 7e b7 .......~#..d-.~. 0030: 7a 9b f5 35 56 1b dd 00 01 00 00 00 00 z..5V........ ldap_read: want=8, got=8 0000: 30 2b 02 01 03 63 26 04 0+...c&. ldap_read: want=37, got=37 0000: 06 64 63 3d 67 61 63 0a 01 02 0a 01 00 02 01 00 .dc=gac......... 0010: 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c ........objectcl 0020: 61 73 73 30 00 ass0. ber_get_next: tag 0x30 len 43 contents: ber_dump: buf=0x8923fa0 ptr=0x8923fa0 end=0x8923fcb len=43 0000: 02 01 03 63 26 04 06 64 63 3d 67 61 63 0a 01 02 ...c&..dc=gac... 0010: 0a 01 00 02 01 00 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0020: 6a 65 63 74 63 6c 61 73 73 30 00 jectclass0. ber_get_next sasl_read: want=4 error=Resource temporarily unavailable ldap_read: want=8 error=Resource temporarily unavailable conn=3 op=2 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=0x8923fa0 ptr=0x8923fa3 end=0x8923fcb len=40 0000: 63 26 04 06 64 63 3d 67 61 63 0a 01 02 0a 01 00 c&..dc=gac...... 0010: 02 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 ...........objec 0020: 74 63 6c 61 73 73 30 00 tclass0. >>> dnPrettyNormal: <dc=gac> => ldap_bv2dn(dc=gac,0) <= ldap_bv2dn(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 <<< dnPrettyNormal: <dc=gac>, <dc=gac> SRCH "dc=gac" 2 0 0 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=0x8923fa0 ptr=0x8923fbc end=0x8923fcb len=15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=*) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x8923fa0 ptr=0x8923fc9 end=0x8923fcb len=2 0000: 00 00 .. attrs: conn=3 op=2 SRCH base="dc=gac" scope=2 deref=0 filter="(objectClass=*)" ==> limits_get: conn=3 op=2 dn="cn=user2,o=de,dc=gac" ldap_create ldap_url_parse_ext(ldap://192.168.112.11) conn=3 op=2: meta_back_getconn[0] conn=3 op=2 meta_back_getconn: candidates=1 conn=3 inserted conn=3 op=2 >>> meta_back_search_start[0] conn=3 op=2 >>> meta_search_dobind_init[0] ldap_sasl_interactive_bind_s: user selected: digest-md5 ldap_int_sasl_bind: digest-md5 ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.112.11:389 ldap_new_socket: 13 ldap_prepare_socket: 13 ldap_connect_to_host: Trying 192.168.112.11:389 ldap_pvt_connect: fd: 13 tm: -1 async: 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 ldap_int_sasl_open: host=node-2.local ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x8920818 ptr=0x8920818 end=0x8920957 len=319 0000: 30 82 01 3b 02 01 01 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 78 77 e.gac",nonce="xw 0060: 4b 72 6a 59 52 4a 65 48 72 65 41 49 66 46 37 65 KrjYRJeHreAIfF7e 0070: 55 61 33 2b 4c 64 31 39 78 78 74 4b 76 61 34 38 Ua3+Ld19xxtKva48 0080: 6e 39 4c 39 38 46 56 71 41 3d 22 2c 63 6e 6f 6e n9L98FVqA=",cnon 0090: 63 65 3d 22 43 33 59 47 59 47 72 34 76 56 41 4f ce="C3YGYGr4vVAO 00a0: 61 71 63 48 59 48 47 44 76 4e 44 77 4a 54 30 46 aqcHYHGDvNDwJT0F 00b0: 6f 59 47 77 51 75 42 52 49 68 58 4f 73 5a 41 3d oYGwQuBRIhXOsZA= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 32 2c 71 6f ",nc=00000002,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 31 ocal",response=1 0120: 39 34 63 34 63 64 36 32 33 30 36 66 30 38 61 32 94c4cd62306f08a2 0130: 61 38 30 64 36 31 32 65 32 61 65 36 63 37 38 a80d612e2ae6c78 ber_scanf fmt ({i) ber: ber_dump: buf=0x8920818 ptr=0x892081f end=0x8920957 len=312 0000: 60 82 01 34 02 01 03 04 12 63 6e 3d 64 61 74 61 `..4.....cn=data 0010: 64 6d 69 6e 2c 64 63 3d 67 61 63 a3 82 01 19 04 dmin,dc=gac..... 0020: 0a 44 49 47 45 53 54 2d 4d 44 35 04 82 01 09 75 .DIGEST-MD5....u 0030: 73 65 72 6e 61 6d 65 3d 22 72 6f 6f 74 22 2c 72 sername="root",r 0040: 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c ealm="node.gac", 0050: 6e 6f 6e 63 65 3d 22 78 77 4b 72 6a 59 52 4a 65 nonce="xwKrjYRJe 0060: 48 72 65 41 49 66 46 37 65 55 61 33 2b 4c 64 31 HreAIfF7eUa3+Ld1 0070: 39 78 78 74 4b 76 61 34 38 6e 39 4c 39 38 46 56 9xxtKva48n9L98FV 0080: 71 41 3d 22 2c 63 6e 6f 6e 63 65 3d 22 43 33 59 qA=",cnonce="C3Y 0090: 47 59 47 72 34 76 56 41 4f 61 71 63 48 59 48 47 GYGr4vVAOaqcHYHG 00a0: 44 76 4e 44 77 4a 54 30 46 6f 59 47 77 51 75 42 DvNDwJT0FoYGwQuB 00b0: 52 49 68 58 4f 73 5a 41 3d 22 2c 6e 63 3d 30 30 RIhXOsZA=",nc=00 00c0: 30 30 30 30 30 32 2c 71 6f 70 3d 61 75 74 68 2d 000002,qop=auth- 00d0: 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 34 2c conf,cipher=rc4, 00e0: 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 35 2c maxbuf=16777215, 00f0: 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 61 70 digest-uri="ldap 0100: 2f 6e 6f 64 65 2d 32 2e 6c 6f 63 61 6c 22 2c 72 /node-2.local",r 0110: 65 73 70 6f 6e 73 65 3d 31 39 34 63 34 63 64 36 esponse=194c4cd6 0120: 32 33 30 36 66 30 38 61 32 61 38 30 64 36 31 32 2306f08a2a80d612 0130: 65 32 61 65 36 63 37 38 e2ae6c78 ber_flush2: 319 bytes to sd 13 0000: 30 82 01 3b 02 01 01 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 78 77 e.gac",nonce="xw 0060: 4b 72 6a 59 52 4a 65 48 72 65 41 49 66 46 37 65 KrjYRJeHreAIfF7e 0070: 55 61 33 2b 4c 64 31 39 78 78 74 4b 76 61 34 38 Ua3+Ld19xxtKva48 0080: 6e 39 4c 39 38 46 56 71 41 3d 22 2c 63 6e 6f 6e n9L98FVqA=",cnon 0090: 63 65 3d 22 43 33 59 47 59 47 72 34 76 56 41 4f ce="C3YGYGr4vVAO 00a0: 61 71 63 48 59 48 47 44 76 4e 44 77 4a 54 30 46 aqcHYHGDvNDwJT0F 00b0: 6f 59 47 77 51 75 42 52 49 68 58 4f 73 5a 41 3d oYGwQuBRIhXOsZA= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 32 2c 71 6f ",nc=00000002,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 31 ocal",response=1 0120: 39 34 63 34 63 64 36 32 33 30 36 66 30 38 61 32 94c4cd62306f08a2 0130: 61 38 30 64 36 31 32 65 32 61 65 36 63 37 38 a80d612e2ae6c78 ldap_write: want=319, written=319 0000: 30 82 01 3b 02 01 01 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 78 77 e.gac",nonce="xw 0060: 4b 72 6a 59 52 4a 65 48 72 65 41 49 66 46 37 65 KrjYRJeHreAIfF7e 0070: 55 61 33 2b 4c 64 31 39 78 78 74 4b 76 61 34 38 Ua3+Ld19xxtKva48 0080: 6e 39 4c 39 38 46 56 71 41 3d 22 2c 63 6e 6f 6e n9L98FVqA=",cnon 0090: 63 65 3d 22 43 33 59 47 59 47 72 34 76 56 41 4f ce="C3YGYGr4vVAO 00a0: 61 71 63 48 59 48 47 44 76 4e 44 77 4a 54 30 46 aqcHYHGDvNDwJT0F 00b0: 6f 59 47 77 51 75 42 52 49 68 58 4f 73 5a 41 3d oYGwQuBRIhXOsZA= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 32 2c 71 6f ",nc=00000002,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 31 ocal",response=1 0120: 39 34 63 34 63 64 36 32 33 30 36 66 30 38 61 32 94c4cd62306f08a2 0130: 61 38 30 64 36 31 32 65 32 61 65 36 63 37 38 a80d612e2ae6c78 ldap_result ld 0x88f5380 msgid 1 wait4msg ld 0x88f5380 msgid 1 (infinite timeout) wait4msg continue ld 0x88f5380 msgid 1 all 1 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 1 all 1 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 81 e1 02 01 01 61 81 0.....a. ldap_read: want=220, got=220 0000: db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 3a ........SASL(0): 0010: 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 75 successful resu 0020: 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 49 6a lt: ...nonce="Ij 0030: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0040: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0050: 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 61 6c aHFtRDLCA=",real 0060: 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 6f 70 m="node.gac",qop 0070: 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e 74 2c ="auth,auth-int, 0080: 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 68 65 auth-conf",ciphe 0090: 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d 35 36 r="rc4-40,rc4-56 00a0: 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 2c 6d ,rc4,des,3des",m 00b0: 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 61 72 axbuf=65536,char 00c0: 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f 72 69 set=utf-8,algori 00d0: 74 68 6d 3d 6d 64 35 2d 73 65 73 73 thm=md5-sess ber_get_next: tag 0x30 len 225 contents: ber_dump: buf=0x89242a8 ptr=0x89242a8 end=0x8924389 len=225 0000: 02 01 01 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 ...a.........SAS 0010: 4c 28 30 29 3a 20 73 75 63 63 65 73 73 66 75 6c L(0): successful 0020: 20 72 65 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 result: ...nonc 0030: 65 3d 22 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a e="Ijq+Ki4kJzVIz 0040: 74 6c 33 47 51 36 78 37 51 79 6e 77 73 4f 52 6a tl3GQ6x7QynwsORj 0050: 6f 64 47 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 odGzTaHFtRDLCA=" 0060: 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 ,realm="node.gac 0070: 22 2c 71 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 ",qop="auth,auth 0080: 2d 69 6e 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c -int,auth-conf", 0090: 63 69 70 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 cipher="rc4-40,r 00a0: 63 34 2d 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 c4-56,rc4,des,3d 00b0: 65 73 22 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 es",maxbuf=65536 00c0: 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 ,charset=utf-8,a 00d0: 6c 67 6f 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 lgorithm=md5-ses 00e0: 73 s read1msg: ld 0x88f5380 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x8924389 len=222 0000: 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 a.........SASL(0 0010: 29 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 ): successful re 0020: 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 sult: ...nonce=" 0030: 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 Ijq+Ki4kJzVIztl3 0040: 47 51 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 GQ6x7QynwsORjodG 0050: 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 zTaHFtRDLCA=",re 0060: 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 alm="node.gac",q 0070: 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e op="auth,auth-in 0080: 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 t,auth-conf",cip 0090: 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d her="rc4-40,rc4- 00a0: 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 56,rc4,des,3des" 00b0: 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 ,maxbuf=65536,ch 00c0: 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f arset=utf-8,algo 00d0: 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 73 rithm=md5-sess read1msg: ld 0x88f5380 0 new referrals read1msg: mark request completed, ld 0x88f5380 msgid 1 request done: ld 0x88f5380 msgid 1 res_errno: 14, res_error: <SASL(0): successful result: >, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x8924389 len=222 0000: 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 a.........SASL(0 0010: 29 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 ): successful re 0020: 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 sult: ...nonce=" 0030: 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 Ijq+Ki4kJzVIztl3 0040: 47 51 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 GQ6x7QynwsORjodG 0050: 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 zTaHFtRDLCA=",re 0060: 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 alm="node.gac",q 0070: 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e op="auth,auth-in 0080: 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 t,auth-conf",cip 0090: 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d her="rc4-40,rc4- 00a0: 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 56,rc4,des,3des" 00b0: 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 ,maxbuf=65536,ch 00c0: 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f arset=utf-8,algo 00d0: 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 73 rithm=md5-sess ber_scanf fmt (O) ber: ber_dump: buf=0x89242a8 ptr=0x89242d1 end=0x8924389 len=184 0000: 87 81 b5 6e 6f 6e 63 65 3d 22 49 6a 71 2b 4b 69 ...nonce="Ijq+Ki 0010: 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 36 78 37 51 4kJzVIztl3GQ6x7Q 0020: 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 61 48 46 74 ynwsORjodGzTaHFt 0030: 52 44 4c 43 41 3d 22 2c 72 65 61 6c 6d 3d 22 6e RDLCA=",realm="n 0040: 6f 64 65 2e 67 61 63 22 2c 71 6f 70 3d 22 61 75 ode.gac",qop="au 0050: 74 68 2c 61 75 74 68 2d 69 6e 74 2c 61 75 74 68 th,auth-int,auth 0060: 2d 63 6f 6e 66 22 2c 63 69 70 68 65 72 3d 22 72 -conf",cipher="r 0070: 63 34 2d 34 30 2c 72 63 34 2d 35 36 2c 72 63 34 c4-40,rc4-56,rc4 0080: 2c 64 65 73 2c 33 64 65 73 22 2c 6d 61 78 62 75 ,des,3des",maxbu 0090: 66 3d 36 35 35 33 36 2c 63 68 61 72 73 65 74 3d f=65536,charset= 00a0: 75 74 66 2d 38 2c 61 6c 67 6f 72 69 74 68 6d 3d utf-8,algorithm= 00b0: 6d 64 35 2d 73 65 73 73 md5-sess ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x8924389 len=222 0000: 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 a.........SASL(0 0010: 29 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 ): successful re 0020: 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 sult: ...nonce=" 0030: 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 Ijq+Ki4kJzVIztl3 0040: 47 51 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 GQ6x7QynwsORjodG 0050: 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 zTaHFtRDLCA=",re 0060: 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 alm="node.gac",q 0070: 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e op="auth,auth-in 0080: 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 t,auth-conf",cip 0090: 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d her="rc4-40,rc4- 00a0: 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 56,rc4,des,3des" 00b0: 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 ,maxbuf=65536,ch 00c0: 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f arset=utf-8,algo 00d0: 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 73 rithm=md5-sess ber_scanf fmt (x) ber: ber_dump: buf=0x89242a8 ptr=0x89242d1 end=0x8924389 len=184 0000: 87 81 b5 6e 6f 6e 63 65 3d 22 49 6a 71 2b 4b 69 ...nonce="Ijq+Ki 0010: 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 36 78 37 51 4kJzVIztl3GQ6x7Q 0020: 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 61 48 46 74 ynwsORjodGzTaHFt 0030: 52 44 4c 43 41 3d 22 2c 72 65 61 6c 6d 3d 22 6e RDLCA=",realm="n 0040: 6f 64 65 2e 67 61 63 22 2c 71 6f 70 3d 22 61 75 ode.gac",qop="au 0050: 74 68 2c 61 75 74 68 2d 69 6e 74 2c 61 75 74 68 th,auth-int,auth 0060: 2d 63 6f 6e 66 22 2c 63 69 70 68 65 72 3d 22 72 -conf",cipher="r 0070: 63 34 2d 34 30 2c 72 63 34 2d 35 36 2c 72 63 34 c4-40,rc4-56,rc4 0080: 2c 64 65 73 2c 33 64 65 73 22 2c 6d 61 78 62 75 ,des,3des",maxbu 0090: 66 3d 36 35 35 33 36 2c 63 68 61 72 73 65 74 3d f=65536,charset= 00a0: 75 74 66 2d 38 2c 61 6c 67 6f 72 69 74 68 6d 3d utf-8,algorithm= 00b0: 6d 64 35 2d 73 65 73 73 md5-sess ber_scanf fmt (}) ber: ber_dump: buf=0x89242a8 ptr=0x8924389 end=0x8924389 len=0 ldap_msgfree sasl_client_step: 1 ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x89304a0 ptr=0x89304a0 end=0x89305df len=319 0000: 30 82 01 3b 02 01 02 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 49 6a e.gac",nonce="Ij 0060: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0070: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0080: 61 48 46 74 52 44 4c 43 41 3d 22 2c 63 6e 6f 6e aHFtRDLCA=",cnon 0090: 63 65 3d 22 50 50 39 72 32 38 6e 37 2b 55 6f 41 ce="PP9r28n7+UoA 00a0: 49 35 76 48 61 50 63 58 45 6a 6d 4b 68 73 34 37 I5vHaPcXEjmKhs47 00b0: 6d 79 2f 75 6d 57 70 65 61 52 4f 48 79 45 30 3d my/umWpeaROHyE0= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f ",nc=00000001,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 34 ocal",response=4 0120: 31 38 35 35 38 30 32 63 36 38 63 62 32 38 61 66 1855802c68cb28af 0130: 35 34 31 31 63 66 32 37 66 66 31 38 31 65 36 5411cf27ff181e6 ber_scanf fmt ({i) ber: ber_dump: buf=0x89304a0 ptr=0x89304a7 end=0x89305df len=312 0000: 60 82 01 34 02 01 03 04 12 63 6e 3d 64 61 74 61 `..4.....cn=data 0010: 64 6d 69 6e 2c 64 63 3d 67 61 63 a3 82 01 19 04 dmin,dc=gac..... 0020: 0a 44 49 47 45 53 54 2d 4d 44 35 04 82 01 09 75 .DIGEST-MD5....u 0030: 73 65 72 6e 61 6d 65 3d 22 72 6f 6f 74 22 2c 72 sername="root",r 0040: 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c ealm="node.gac", 0050: 6e 6f 6e 63 65 3d 22 49 6a 71 2b 4b 69 34 6b 4a nonce="Ijq+Ki4kJ 0060: 7a 56 49 7a 74 6c 33 47 51 36 78 37 51 79 6e 77 zVIztl3GQ6x7Qynw 0070: 73 4f 52 6a 6f 64 47 7a 54 61 48 46 74 52 44 4c sORjodGzTaHFtRDL 0080: 43 41 3d 22 2c 63 6e 6f 6e 63 65 3d 22 50 50 39 CA=",cnonce="PP9 0090: 72 32 38 6e 37 2b 55 6f 41 49 35 76 48 61 50 63 r28n7+UoAI5vHaPc 00a0: 58 45 6a 6d 4b 68 73 34 37 6d 79 2f 75 6d 57 70 XEjmKhs47my/umWp 00b0: 65 61 52 4f 48 79 45 30 3d 22 2c 6e 63 3d 30 30 eaROHyE0=",nc=00 00c0: 30 30 30 30 30 31 2c 71 6f 70 3d 61 75 74 68 2d 000001,qop=auth- 00d0: 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 34 2c conf,cipher=rc4, 00e0: 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 35 2c maxbuf=16777215, 00f0: 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 61 70 digest-uri="ldap 0100: 2f 6e 6f 64 65 2d 32 2e 6c 6f 63 61 6c 22 2c 72 /node-2.local",r 0110: 65 73 70 6f 6e 73 65 3d 34 31 38 35 35 38 30 32 esponse=41855802 0120: 63 36 38 63 62 32 38 61 66 35 34 31 31 63 66 32 c68cb28af5411cf2 0130: 37 66 66 31 38 31 65 36 7ff181e6 ber_flush2: 319 bytes to sd 13 0000: 30 82 01 3b 02 01 02 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 49 6a e.gac",nonce="Ij 0060: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0070: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0080: 61 48 46 74 52 44 4c 43 41 3d 22 2c 63 6e 6f 6e aHFtRDLCA=",cnon 0090: 63 65 3d 22 50 50 39 72 32 38 6e 37 2b 55 6f 41 ce="PP9r28n7+UoA 00a0: 49 35 76 48 61 50 63 58 45 6a 6d 4b 68 73 34 37 I5vHaPcXEjmKhs47 00b0: 6d 79 2f 75 6d 57 70 65 61 52 4f 48 79 45 30 3d my/umWpeaROHyE0= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f ",nc=00000001,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 34 ocal",response=4 0120: 31 38 35 35 38 30 32 63 36 38 63 62 32 38 61 66 1855802c68cb28af 0130: 35 34 31 31 63 66 32 37 66 66 31 38 31 65 36 5411cf27ff181e6 ldap_write: want=319, written=319 0000: 30 82 01 3b 02 01 02 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 49 6a e.gac",nonce="Ij 0060: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0070: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0080: 61 48 46 74 52 44 4c 43 41 3d 22 2c 63 6e 6f 6e aHFtRDLCA=",cnon 0090: 63 65 3d 22 50 50 39 72 32 38 6e 37 2b 55 6f 41 ce="PP9r28n7+UoA 00a0: 49 35 76 48 61 50 63 58 45 6a 6d 4b 68 73 34 37 I5vHaPcXEjmKhs47 00b0: 6d 79 2f 75 6d 57 70 65 61 52 4f 48 79 45 30 3d my/umWpeaROHyE0= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f ",nc=00000001,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 34 ocal",response=4 0120: 31 38 35 35 38 30 32 63 36 38 63 62 32 38 61 66 1855802c68cb28af 0130: 35 34 31 31 63 66 32 37 66 66 31 38 31 65 36 5411cf27ff181e6 ldap_result ld 0x88f5380 msgid 2 wait4msg ld 0x88f5380 msgid 2 (infinite timeout) wait4msg continue ld 0x88f5380 msgid 2 all 1 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 2 all 1 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 2 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 36 02 01 02 61 31 0a 06...a1. ldap_read: want=48, got=48 0000: 01 00 04 00 04 00 87 28 72 73 70 61 75 74 68 3d .......(rspauth= 0010: 35 36 65 64 61 37 65 64 32 65 62 38 63 38 39 32 56eda7ed2eb8c892 0020: 66 30 34 62 32 30 34 65 65 34 64 30 35 35 34 37 f04b204ee4d05547 ber_get_next: tag 0x30 len 54 contents: ber_dump: buf=0x89242a8 ptr=0x89242a8 end=0x89242de len=54 0000: 02 01 02 61 31 0a 01 00 04 00 04 00 87 28 72 73 ...a1........(rs 0010: 70 61 75 74 68 3d 35 36 65 64 61 37 65 64 32 65 pauth=56eda7ed2e 0020: 62 38 63 38 39 32 66 30 34 62 32 30 34 65 65 34 b8c892f04b204ee4 0030: 64 30 35 35 34 37 d05547 read1msg: ld 0x88f5380 msgid 2 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x89242de len=51 0000: 61 31 0a 01 00 04 00 04 00 87 28 72 73 70 61 75 a1........(rspau 0010: 74 68 3d 35 36 65 64 61 37 65 64 32 65 62 38 63 th=56eda7ed2eb8c 0020: 38 39 32 66 30 34 62 32 30 34 65 65 34 64 30 35 892f04b204ee4d05 0030: 35 34 37 547 read1msg: ld 0x88f5380 0 new referrals read1msg: mark request completed, ld 0x88f5380 msgid 2 request done: ld 0x88f5380 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x89242de len=51 0000: 61 31 0a 01 00 04 00 04 00 87 28 72 73 70 61 75 a1........(rspau 0010: 74 68 3d 35 36 65 64 61 37 65 64 32 65 62 38 63 th=56eda7ed2eb8c 0020: 38 39 32 66 30 34 62 32 30 34 65 65 34 64 30 35 892f04b204ee4d05 0030: 35 34 37 547 ber_scanf fmt (O) ber: ber_dump: buf=0x89242a8 ptr=0x89242b4 end=0x89242de len=42 0000: 87 28 72 73 70 61 75 74 68 3d 35 36 65 64 61 37 .(rspauth=56eda7 0010: 65 64 32 65 62 38 63 38 39 32 66 30 34 62 32 30 ed2eb8c892f04b20 0020: 34 65 65 34 64 30 35 35 34 37 4ee4d05547 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x89242de len=51 0000: 61 31 0a 01 00 04 00 04 00 87 28 72 73 70 61 75 a1........(rspau 0010: 74 68 3d 35 36 65 64 61 37 65 64 32 65 62 38 63 th=56eda7ed2eb8c 0020: 38 39 32 66 30 34 62 32 30 34 65 65 34 64 30 35 892f04b204ee4d05 0030: 35 34 37 547 ber_scanf fmt (x) ber: ber_dump: buf=0x89242a8 ptr=0x89242b4 end=0x89242de len=42 0000: 87 28 72 73 70 61 75 74 68 3d 35 36 65 64 61 37 .(rspauth=56eda7 0010: 65 64 32 65 62 38 63 38 39 32 66 30 34 62 32 30 ed2eb8c892f04b20 0020: 34 65 65 34 64 30 35 35 34 37 4ee4d05547 ber_scanf fmt (}) ber: ber_dump: buf=0x89242a8 ptr=0x89242de end=0x89242de len=0 ldap_msgfree sasl_client_step: 0 ldap_pvt_sasl_install conn=3 op=2 <<< meta_search_dobind_init[0]=1 [rw] searchBase: "dc=gac" -> "dc=gac" [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" ldap_search_ext put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x89314e8 ptr=0x89314e8 end=0x8931517 len=47 0000: 30 2d 02 01 03 63 28 04 06 64 63 3d 67 61 63 0a 0-...c(..dc=gac. 0010: 01 02 0a 01 00 02 02 01 f4 02 02 0e 10 01 01 00 ................ 0020: 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 00 ..objectClass0. ber_scanf fmt ({) ber: ber_dump: buf=0x89314e8 ptr=0x89314ed end=0x8931517 len=42 0000: 63 28 04 06 64 63 3d 67 61 63 0a 01 02 0a 01 00 c(..dc=gac...... 0010: 02 02 01 f4 02 02 0e 10 01 01 00 87 0b 6f 62 6a .............obj 0020: 65 63 74 43 6c 61 73 73 30 00 ectClass0. ber_flush2: 47 bytes to sd 13 0000: 30 2d 02 01 03 63 28 04 06 64 63 3d 67 61 63 0a 0-...c(..dc=gac. 0010: 01 02 0a 01 00 02 02 01 f4 02 02 0e 10 01 01 00 ................ 0020: 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 00 ..objectClass0. sasl_write: want=67, written=67 0000: 00 00 00 3f 30 03 26 1a c6 d2 e0 d3 73 5a 16 f7 ...?0.&.....sZ.. 0010: 14 f8 04 b2 0a e8 79 e3 0c ea ec 99 c6 24 ff 09 ......y......$.. 0020: f5 56 8e 48 69 83 39 95 bf ed 32 b7 0d 1e 8c fe .V.Hi.9...2..... 0030: 43 f2 f3 cb 20 cb e7 88 87 0a ce 3e ea 00 01 00 C... ......>.... 0040: 00 00 00 ... ldap_write: want=47, written=47 0000: 30 2d 02 01 03 63 28 04 06 64 63 3d 67 61 63 0a 0-...c(..dc=gac. 0010: 01 02 0a 01 00 02 02 01 f4 02 02 0e 10 01 01 00 ................ 0020: 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 00 ..objectClass0. conn=3 op=2 <<< meta_back_search_start[0]=1 conn=3 op=2 meta_back_search: ncandidates=1 cnd="*" ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 37 ...7 sasl_read: want=55, got=55 0000: 13 01 fe 47 77 d4 71 21 9b 42 1d 85 74 36 e7 ce ...Gw.q!.B..t6.. 0010: b3 66 a5 15 94 42 5e 09 19 23 d2 a4 c3 43 e8 4f .f...B^..#...C.O 0020: bd f5 12 ac c9 8d 4d 5c fc 3e 52 cc c6 45 60 8a ......M\.>R..E`. 0030: 1d 00 01 00 00 00 00 ....... ldap_read: want=8, got=8 0000: 30 25 02 01 03 64 20 04 0%...d . ldap_read: want=31, got=31 0000: 06 64 63 3d 67 61 63 30 16 30 14 04 0b 6f 62 6a .dc=gac0.0...obj 0010: 65 63 74 43 6c 61 73 73 31 05 04 03 74 6f 70 ectClass1...top ber_get_next: tag 0x30 len 37 contents: ber_dump: buf=0x89246f0 ptr=0x89246f0 end=0x8924715 len=37 0000: 02 01 03 64 20 04 06 64 63 3d 67 61 63 30 16 30 ...d ..dc=gac0.0 0010: 14 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 05 ...objectClass1. 0020: 04 03 74 6f 70 ..top read1msg: ld 0x88f5380 msgid 3 message type search-entry wait4msg ld 0x88f5380 0 s 97635 us to go wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x89246f0 ptr=0x89246f3 end=0x8924715 len=34 0000: 64 20 04 06 64 63 3d 67 61 63 30 16 30 14 04 0b d ..dc=gac0.0... 0010: 6f 62 6a 65 63 74 43 6c 61 73 73 31 05 04 03 74 objectClass1...t 0020: 6f 70 op [rw] searchResult: "dc=gac" -> "dc=gac" >>> dnPrettyNormal: <dc=gac> => ldap_bv2dn(dc=gac,0) <= ldap_bv2dn(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 <<< dnPrettyNormal: <dc=gac>, <dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x89246f0 ptr=0x89246ff end=0x8924715 len=22 0000: 30 14 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 05 04 03 74 6f 70 ...top ber_scanf fmt ([W]) ber: ber_dump: buf=0x89246f0 ptr=0x892470e end=0x8924715 len=7 0000: 00 05 04 03 74 6f 70 ....top ber_scanf fmt ({m) ber: ber_dump: buf=0x89246f0 ptr=0x8924715 end=0x8924715 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x89246f0 ptr=0x89246f3 end=0x8924715 len=34 0000: 64 20 04 06 64 63 3d 67 61 63 00 16 30 14 04 0b d ..dc=gac..0... 0010: 6f 62 6a 65 63 74 43 6c 61 73 73 00 05 04 03 74 objectClass....t 0020: 6f 70 op => send_search_entry: conn 3 dn="dc=gac" => access_allowed: read access to "dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [6] cn=contacts,cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dn: [7] dc=gac => acl_get: [7] matched => acl_get: [7] attr entry => acl_mask: access to entry "dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying search(=scxd) (stop) <= acl_mask: [1] mask: search(=scxd) => slap_access_allowed: read access denied by search(=scxd) => access_allowed: no more rules send_search_entry: conn 3 access to entry (dc=gac) not allowed ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 6a ...j sasl_read: want=106, got=106 0000: 52 3b c0 02 7c b2 5c d6 b8 c1 1a 03 48 02 c5 29 R;..|.\.....H..) 0010: 6c 8c 11 4d 62 3c 58 0d 55 6c 8d 93 43 4f 52 1c l..Mb<X.Ul..COR. 0020: 57 f2 80 ae 0b 13 6c 9b 20 7f c6 68 59 ab 3d e4 W.....l. ..hY.=. 0030: f0 f9 5e 0d 46 45 56 14 a1 f3 47 6e 0a 69 81 7f ..^.FEV...Gn.i.. 0040: 48 97 8a 50 84 c0 cb 7c e2 71 23 36 0b 27 8a 81 H..P...|.q#6.'.. 0050: 57 be 29 39 a1 3d 95 f1 15 8c 21 c2 f9 85 59 76 W.)9.=....!...Yv 0060: 2e da 89 1a 00 01 00 00 00 01 .......... ldap_read: want=8, got=8 0000: 30 58 02 01 03 64 53 04 0X...dS. ldap_read: want=82, got=82 0000: 0b 6f 3d 64 65 2c 64 63 3d 67 61 63 30 44 30 1d .o=de,dc=gac0D0. 0010: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0e 04 ..objectClass1.. 0020: 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 30 09 04 .organization0.. 0030: 01 6f 31 04 04 02 64 65 30 18 04 0b 64 65 73 63 .o1...de0...desc 0040: 72 69 70 74 69 6f 6e 31 09 04 07 64 65 2e 67 61 ription1...de.ga 0050: 63 2e c. ber_get_next: tag 0x30 len 88 contents: ber_dump: buf=0x89209d0 ptr=0x89209d0 end=0x8920a28 len=88 0000: 02 01 03 64 53 04 0b 6f 3d 64 65 2c 64 63 3d 67 ...dS..o=de,dc=g 0010: 61 63 30 44 30 1d 04 0b 6f 62 6a 65 63 74 43 6c ac0D0...objectCl 0020: 61 73 73 31 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 ass1...organizat 0030: 69 6f 6e 30 09 04 01 6f 31 04 04 02 64 65 30 18 ion0...o1...de0. 0040: 04 0b 64 65 73 63 72 69 70 74 69 6f 6e 31 09 04 ..description1.. 0050: 07 64 65 2e 67 61 63 2e .de.gac. read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x89209d0 ptr=0x89209d3 end=0x8920a28 len=85 0000: 64 53 04 0b 6f 3d 64 65 2c 64 63 3d 67 61 63 30 dS..o=de,dc=gac0 0010: 44 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 D0...objectClass 0020: 31 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 1...organization 0030: 30 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 0...o1...de0...d 0040: 65 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 escription1...de 0050: 2e 67 61 63 2e .gac. [rw] searchResult: "o=de,dc=gac" -> "o=de,dc=gac" >>> dnPrettyNormal: <o=de,dc=gac> => ldap_bv2dn(o=de,dc=gac,0) <= ldap_bv2dn(o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=de,dc=gac)=0 <<< dnPrettyNormal: <o=de,dc=gac>, <o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x89209e4 end=0x8920a28 len=68 0000: 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 30 ...organization0 0020: 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 65 ...o1...de0...de 0030: 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 2e scription1...de. 0040: 67 61 63 2e gac. ber_scanf fmt ([W]) ber: ber_dump: buf=0x89209d0 ptr=0x89209f3 end=0x8920a28 len=53 0000: 00 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e ....organization 0010: 30 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 0...o1...de0...d 0020: 65 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 escription1...de 0030: 2e 67 61 63 2e .gac. ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x8920a03 end=0x8920a28 len=37 0000: 30 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 0...o1...de0...d 0010: 65 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 escription1...de 0020: 2e 67 61 63 2e .gac. ber_scanf fmt ([W]) ber: ber_dump: buf=0x89209d0 ptr=0x8920a08 end=0x8920a28 len=32 0000: 00 04 04 02 64 65 30 18 04 0b 64 65 73 63 72 69 ....de0...descri 0010: 70 74 69 6f 6e 31 09 04 07 64 65 2e 67 61 63 2e ption1...de.gac. ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x8920a0e end=0x8920a28 len=26 0000: 30 18 04 0b 64 65 73 63 72 69 70 74 69 6f 6e 31 0...description1 0010: 09 04 07 64 65 2e 67 61 63 2e ...de.gac. ber_scanf fmt ([W]) ber: ber_dump: buf=0x89209d0 ptr=0x8920a1d end=0x8920a28 len=11 0000: 00 09 04 07 64 65 2e 67 61 63 2e ....de.gac. ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x8920a28 end=0x8920a28 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x89209d0 ptr=0x89209d3 end=0x8920a28 len=85 0000: 64 53 04 0b 6f 3d 64 65 2c 64 63 3d 67 61 63 00 dS..o=de,dc=gac. 0010: 44 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 D0...objectClass 0020: 00 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e ....organization 0030: 30 09 04 01 6f 00 04 04 02 64 65 30 18 04 0b 64 0...o....de0...d 0040: 65 73 63 72 69 70 74 69 6f 6e 00 09 04 07 64 65 escription....de 0050: 2e 67 61 63 2e .gac. => send_search_entry: conn 3 dn="o=de,dc=gac" => access_allowed: read access to "o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [6] cn=contacts,cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dn: [7] dc=gac => acl_get: [7] matched => acl_get: [7] attr entry => acl_mask: access to entry "o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying search(=scxd) (stop) <= acl_mask: [1] mask: search(=scxd) => slap_access_allowed: read access denied by search(=scxd) => access_allowed: no more rules send_search_entry: conn 3 access to entry (o=de,dc=gac) not allowed ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 99 .... sasl_read: want=153, got=153 0000: b1 6f c7 5b a9 ac c5 68 79 16 5a f6 1f dd 67 98 .o.[...hy.Z...g. 0010: da d3 ce ae b5 2f 65 1d df 64 48 63 f7 e6 34 72 ...../e..dHc..4r 0020: 99 f1 a8 48 e3 60 b5 e7 2b 95 e0 5e 26 f3 ac cc ...H.`..+..^&... 0030: f6 f5 e8 af 29 68 f5 42 6b 14 69 25 46 28 92 0f ....)h.Bk.i%F(.. 0040: 71 b4 5b 67 f8 2d ae 29 a3 07 05 a4 19 2e 25 f5 q.[g.-.)......%. 0050: ff 99 9d 27 f7 37 b0 88 2b fd 81 a3 d8 ef 3d d8 ...'.7..+.....=. 0060: 69 36 0b 0e 92 a0 5b ba 67 ee 3d 07 72 77 9e 28 i6....[.g.=.rw.( 0070: 80 56 1f e2 fc b1 11 70 8f 74 d8 b6 ad 2c 92 d0 .V.....p.t...,.. 0080: 9a 75 96 aa e9 50 57 82 6c 56 aa 89 db 86 fd 95 .u...PW.lV...... 0090: b9 9e cd 00 01 00 00 00 02 ......... ldap_read: want=8, got=8 0000: 30 81 86 02 01 03 64 81 0.....d. ldap_read: want=129, got=129 0000: 80 04 13 63 6e 3d 55 73 65 72 2c 6f 3d 64 65 2c ...cn=User,o=de, 0010: 64 63 3d 67 61 63 30 69 30 1e 04 0b 6f 62 6a 65 dc=gac0i0...obje 0020: 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 74 4f ctClass1...inetO 0030: 72 67 50 65 72 73 6f 6e 30 0c 04 02 63 6e 31 06 rgPerson0...cn1. 0040: 04 04 55 73 65 72 30 0c 04 02 73 6e 31 06 04 04 ..User0...sn1... 0050: 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e 61 6d User0...givenNam 0060: 65 31 06 04 04 55 73 65 72 30 16 04 0c 75 73 65 e1...User0...use 0070: 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 rPassword1...pas 0080: 73 s ber_get_next: tag 0x30 len 134 contents: ber_dump: buf=0x8920ac0 ptr=0x8920ac0 end=0x8920b46 len=134 0000: 02 01 03 64 81 80 04 13 63 6e 3d 55 73 65 72 2c ...d....cn=User, 0010: 6f 3d 64 65 2c 64 63 3d 67 61 63 30 69 30 1e 04 o=de,dc=gac0i0.. 0020: 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d .objectClass1... 0030: 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0c 04 inetOrgPerson0.. 0040: 02 63 6e 31 06 04 04 55 73 65 72 30 0c 04 02 73 .cn1...User0...s 0050: 6e 31 06 04 04 55 73 65 72 30 13 04 09 67 69 76 n1...User0...giv 0060: 65 6e 4e 61 6d 65 31 06 04 04 55 73 65 72 30 16 enName1...User0. 0070: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 ..userPassword1. 0080: 04 04 70 61 73 73 ..pass read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b46 len=131 0000: 64 81 80 04 13 63 6e 3d 55 73 65 72 2c 6f 3d 64 d....cn=User,o=d 0010: 65 2c 64 63 3d 67 61 63 30 69 30 1e 04 0b 6f 62 e,dc=gac0i0...ob 0020: 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 jectClass1...ine 0030: 74 4f 72 67 50 65 72 73 6f 6e 30 0c 04 02 63 6e tOrgPerson0...cn 0040: 31 06 04 04 55 73 65 72 30 0c 04 02 73 6e 31 06 1...User0...sn1. 0050: 04 04 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e ..User0...givenN 0060: 61 6d 65 31 06 04 04 55 73 65 72 30 16 04 0c 75 ame1...User0...u 0070: 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 serPassword1...p 0080: 61 73 73 ass [rw] searchResult: "cn=User,o=de,dc=gac" -> "cn=User,o=de,dc=gac" >>> dnPrettyNormal: <cn=User,o=de,dc=gac> => ldap_bv2dn(cn=User,o=de,dc=gac,0) <= ldap_bv2dn(cn=User,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=User,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=User,o=de,dc=gac>, <cn=user,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920add end=0x8920b46 len=105 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 0c 04 02 63 6e 31 06 04 04 55 73 65 72 30 0c 0...cn1...User0. 0030: 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 04 09 ..sn1...User0... 0040: 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 73 65 givenName1...Use 0050: 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 r0...userPasswor 0060: 64 31 06 04 04 70 61 73 73 d1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920aec end=0x8920b46 len=90 0000: 00 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f ....inetOrgPerso 0010: 6e 30 0c 04 02 63 6e 31 06 04 04 55 73 65 72 30 n0...cn1...User0 0020: 0c 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 04 ...sn1...User0.. 0030: 09 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 73 .givenName1...Us 0040: 65 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f er0...userPasswo 0050: 72 64 31 06 04 04 70 61 73 73 rd1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920afd end=0x8920b46 len=73 0000: 30 0c 04 02 63 6e 31 06 04 04 55 73 65 72 30 0c 0...cn1...User0. 0010: 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 04 09 ..sn1...User0... 0020: 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 73 65 givenName1...Use 0030: 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 r0...userPasswor 0040: 64 31 06 04 04 70 61 73 73 d1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b03 end=0x8920b46 len=67 0000: 00 06 04 04 55 73 65 72 30 0c 04 02 73 6e 31 06 ....User0...sn1. 0010: 04 04 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e ..User0...givenN 0020: 61 6d 65 31 06 04 04 55 73 65 72 30 16 04 0c 75 ame1...User0...u 0030: 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 serPassword1...p 0040: 61 73 73 ass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b0b end=0x8920b46 len=59 0000: 30 0c 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 0...sn1...User0. 0010: 04 09 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 ..givenName1...U 0020: 73 65 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 ser0...userPassw 0030: 6f 72 64 31 06 04 04 70 61 73 73 ord1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b11 end=0x8920b46 len=53 0000: 00 06 04 04 55 73 65 72 30 13 04 09 67 69 76 65 ....User0...give 0010: 6e 4e 61 6d 65 31 06 04 04 55 73 65 72 30 16 04 nName1...User0.. 0020: 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 .userPassword1.. 0030: 04 70 61 73 73 .pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b19 end=0x8920b46 len=45 0000: 30 13 04 09 67 69 76 65 6e 4e 61 6d 65 31 06 04 0...givenName1.. 0010: 04 55 73 65 72 30 16 04 0c 75 73 65 72 50 61 73 .User0...userPas 0020: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b26 end=0x8920b46 len=32 0000: 00 06 04 04 55 73 65 72 30 16 04 0c 75 73 65 72 ....User0...user 0010: 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 73 Password1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b2e end=0x8920b46 len=24 0000: 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 0...userPassword 0010: 31 06 04 04 70 61 73 73 1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b3e end=0x8920b46 len=8 0000: 00 06 04 04 70 61 73 73 ....pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b46 end=0x8920b46 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b46 len=131 0000: 64 81 80 04 13 63 6e 3d 55 73 65 72 2c 6f 3d 64 d....cn=User,o=d 0010: 65 2c 64 63 3d 67 61 63 00 69 30 1e 04 0b 6f 62 e,dc=gac.i0...ob 0020: 6a 65 63 74 43 6c 61 73 73 00 0f 04 0d 69 6e 65 jectClass....ine 0030: 74 4f 72 67 50 65 72 73 6f 6e 30 0c 04 02 63 6e tOrgPerson0...cn 0040: 00 06 04 04 55 73 65 72 30 0c 04 02 73 6e 00 06 ....User0...sn.. 0050: 04 04 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e ..User0...givenN 0060: 61 6d 65 00 06 04 04 55 73 65 72 30 16 04 0c 75 ame....User0...u 0070: 73 65 72 50 61 73 73 77 6f 72 64 00 06 04 04 70 serPassword....p 0080: 61 73 73 ass => send_search_entry: conn 3 dn="cn=User,o=de,dc=gac" => access_allowed: read access to "cn=User,o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr entry => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User,o=de,dc=gac" "objectClass" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr objectClass => slap_access_allowed: result not in cache (objectClass) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "objectClass" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User,o=de,dc=gac" "cn" requested => dn: [1] => acl_get: [3] attr cn => slap_access_allowed: result not in cache (cn) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "cn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User,o=de,dc=gac" "sn" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr sn => slap_access_allowed: result not in cache (sn) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "sn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= check a_set_pat: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: pattern: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: expanded: [cn=contacts,cn=user,o=de,dc=gac]/member >>> dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> => ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac,0) <= ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 <<< dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> <= check a_dn_pat: * <= acl_mask: [3] applying auth(=xd) (stop) <= acl_mask: [3] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute sn, value #0 not allowed => access_allowed: read access to "cn=User,o=de,dc=gac" "givenName" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr givenName => slap_access_allowed: result not in cache (givenName) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "givenName" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= check a_set_pat: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: pattern: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: expanded: [cn=contacts,cn=user,o=de,dc=gac]/member >>> dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> => ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac,0) <= ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 <<< dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> <= check a_dn_pat: * <= acl_mask: [3] applying auth(=xd) (stop) <= acl_mask: [3] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute givenName, value #0 not allowed => access_allowed: read access to "cn=User,o=de,dc=gac" "userPassword" requested => dn: [1] => acl_get: [2] attr userPassword => slap_access_allowed: result not in cache (userPassword) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "userPassword" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: cn=datadmin,dc=gac <= check a_dn_pat: * <= acl_mask: [2] applying auth(=xd) (stop) <= acl_mask: [2] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute userPassword, value #0 not allowed ber_flush2: 76 bytes to sd 11 0000: 30 4a 02 01 03 64 45 04 13 63 6e 3d 55 73 65 72 0J...dE..cn=User 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 2e 30 1e ,o=de,dc=gac0.0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0c .inetOrgPerson0. 0040: 04 02 63 6e 31 06 04 04 55 73 65 72 ..cn1...User sasl_write: want=96, written=96 0000: 00 00 00 5c 83 c6 63 35 c7 67 8b fa d8 28 bd db ...\..c5.g...(.. 0010: 48 09 37 6e ca 1c 8e b7 c6 09 d3 e9 21 3c 86 a2 H.7n........!<.. 0020: 2f bd 2d 46 68 ae b7 54 5d 29 47 56 09 b0 47 43 /.-Fh..T])GV..GC 0030: 6c f5 e3 f3 6e 4c 2f 54 9f 5a 7d ac 0d 54 6d 1d l...nL/T.Z}..Tm. 0040: bb e1 46 c4 26 1f 30 7e 8c 45 16 e0 66 91 3d 9c ..F.&.0~.E..f.=. 0050: 44 c3 e3 1e a5 bf 62 93 ee 46 00 01 00 00 00 00 D.....b..F...... ldap_write: want=76, written=76 0000: 30 4a 02 01 03 64 45 04 13 63 6e 3d 55 73 65 72 0J...dE..cn=User 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 2e 30 1e ,o=de,dc=gac0.0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0c .inetOrgPerson0. 0040: 04 02 63 6e 31 06 04 04 55 73 65 72 ..cn1...User conn=3 op=2 ENTRY dn="cn=user,o=de,dc=gac" <= send_search_entry: conn 3 exit. ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 9d .... sasl_read: want=157, got=157 0000: a4 f4 34 99 30 66 35 e2 21 a3 ee 0d e3 2e 5c fd ..4.0f5.!.....\. 0010: 63 81 96 e0 1e 06 e3 11 8c 51 3c 76 6a 3d 32 bd c........Q<vj=2. 0020: 84 4d 6a fe 8c 53 fd 9c c9 b5 29 51 ea 7c c7 24 .Mj..S....)Q.|.$ 0030: 4d ca fe 7d 91 47 5e 95 6b 39 d5 c3 2b 47 ab 5b M..}.G^.k9..+G.[ 0040: f6 c7 b4 af 75 ca 6c 6a fb fc 84 78 c2 d4 25 4b ....u.lj...x..%K 0050: 32 ea ea 5c 2f 79 61 5d 72 69 2a 3f 72 1f f6 07 2..\/ya]ri*?r... 0060: 80 22 8b b9 4f c6 94 58 b2 a1 cd 2c c7 cc bc 30 ."..O..X...,...0 0070: 86 73 90 62 35 93 c2 b4 60 b2 cf 2a 7d 8f db e6 .s.b5...`..*}... 0080: 01 f9 88 e7 a5 81 a3 d0 6d 93 24 08 a2 27 68 f1 ........m.$..'h. 0090: b6 f8 d4 84 73 92 17 00 01 00 00 00 03 ....s........ ldap_read: want=8, got=8 0000: 30 81 8a 02 01 03 64 81 0.....d. ldap_read: want=133, got=133 0000: 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d 64 65 ...cn=User2,o=de 0010: 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f 62 6a ,dc=gac0l0...obj 0020: 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 74 ectClass1...inet 0030: 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 6e 31 OrgPerson0...cn1 0040: 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 07 ...User20...sn1. 0050: 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 6e ..User20...given 0060: 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 04 Name1...User20.. 0070: 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 .userPassword1.. 0080: 04 70 61 73 73 .pass ber_get_next: tag 0x30 len 138 contents: ber_dump: buf=0x8920ac0 ptr=0x8920ac0 end=0x8920b4a len=138 0000: 02 01 03 64 81 84 04 14 63 6e 3d 55 73 65 72 32 ...d....cn=User2 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e ,o=de,dc=gac0l0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d .inetOrgPerson0. 0040: 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d 04 ..cn1...User20.. 0050: 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 09 .sn1...User20... 0060: 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 givenName1...Use 0070: 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f r20...userPasswo 0080: 72 64 31 06 04 04 70 61 73 73 rd1...pass read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b4a len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f de,dc=gac0l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e bjectClass1...in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 31 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n1...User20...sn 0050: 31 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 1...User20...giv 0060: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0080: 06 04 04 70 61 73 73 ...pass [rw] searchResult: "cn=User2,o=de,dc=gac" -> "cn=User2,o=de,dc=gac" >>> dnPrettyNormal: <cn=User2,o=de,dc=gac> => ldap_bv2dn(cn=User2,o=de,dc=gac,0) <= ldap_bv2dn(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=User2,o=de,dc=gac>, <cn=user2,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ade end=0x8920b4a len=108 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0030: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0040: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0050: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0060: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920aed end=0x8920b4a len=93 0000: 00 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f ....inetOrgPerso 0010: 6e 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 n0...cn1...User2 0020: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0030: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0040: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0050: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920afe end=0x8920b4a len=76 0000: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0010: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0020: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0030: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0040: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b04 end=0x8920b4a len=70 0000: 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 ....User20...sn1 0010: 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 ...User20...give 0020: 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 nName1...User20. 0030: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 ..userPassword1. 0040: 04 04 70 61 73 73 ..pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b0d end=0x8920b4a len=61 0000: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0010: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0020: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0030: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b13 end=0x8920b4a len=55 0000: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0010: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0020: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0030: 06 04 04 70 61 73 73 ...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b1c end=0x8920b4a len=46 0000: 30 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 0...givenName1.. 0010: 05 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 .User20...userPa 0020: 73 73 77 6f 72 64 31 06 04 04 70 61 73 73 ssword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b29 end=0x8920b4a len=33 0000: 00 07 04 05 55 73 65 72 32 30 16 04 0c 75 73 65 ....User20...use 0010: 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 rPassword1...pas 0020: 73 s ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b32 end=0x8920b4a len=24 0000: 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 0...userPassword 0010: 31 06 04 04 70 61 73 73 1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b42 end=0x8920b4a len=8 0000: 00 06 04 04 70 61 73 73 ....pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b4a end=0x8920b4a len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b4a len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 00 6c 30 1e 04 0b 6f de,dc=gac.l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 00 0f 04 0d 69 6e bjectClass....in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n....User20...sn 0050: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0060: 65 6e 4e 61 6d 65 00 07 04 05 55 73 65 72 32 30 enName....User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 00 ...userPassword. 0080: 06 04 04 70 61 73 73 ...pass => send_search_entry: conn 3 dn="cn=User2,o=de,dc=gac" => access_allowed: read access to "cn=User2,o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr entry => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "objectClass" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr objectClass => slap_access_allowed: result not in cache (objectClass) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "objectClass" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "cn" requested => dn: [1] => acl_get: [3] attr cn => slap_access_allowed: result not in cache (cn) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "cn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "sn" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr sn => slap_access_allowed: result not in cache (sn) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "sn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "givenName" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr givenName => slap_access_allowed: result not in cache (givenName) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "givenName" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "userPassword" requested => dn: [1] => acl_get: [2] attr userPassword => slap_access_allowed: result not in cache (userPassword) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "userPassword" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: cn=datadmin,dc=gac <= check a_dn_pat: * <= acl_mask: [2] applying auth(=xd) (stop) <= acl_mask: [2] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute userPassword, value #0 not allowed ber_flush2: 115 bytes to sd 11 0000: 30 71 02 01 03 64 6c 04 14 63 6e 3d 55 73 65 72 0q...dl..cn=User 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 54 30 2,o=de,dc=gac0T0 0020: 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f ...objectClass1. 0030: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 ..inetOrgPerson0 0040: 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d ...cn1...User20. 0050: 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 ..sn1...User20.. 0060: 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 .givenName1...Us 0070: 65 72 32 er2 sasl_write: want=135, written=135 0000: 00 00 00 83 4a 39 19 4f 93 38 d0 77 d0 bb 08 7f ....J9.O.8.w.... 0010: 49 18 1c 59 d7 a5 a3 ca b2 dd 90 83 5f fe 1d 0f I..Y........_... 0020: bc 35 66 33 a0 7b d3 01 02 70 3a 19 8e af 7c 7d .5f3.{...p:...|} 0030: 8b 79 7e 27 8e 4d f5 61 65 36 6a df ee 0a 8e 62 .y~'.M.ae6j....b 0040: 18 6e e7 75 1d 22 b7 98 3d 63 0a 29 e5 63 6f e5 .n.u."..=c.).co. 0050: 77 97 ef 02 65 d2 3e 7d da 21 24 d8 42 d5 86 39 w...e.>}.!$.B..9 0060: dc f6 79 f3 b5 bd 42 c3 90 f1 8d c8 da bc 68 99 ..y...B.......h. 0070: b0 88 7c 1f cf b6 93 18 8d f4 af 65 e5 57 98 8b ..|........e.W.. 0080: 13 00 01 00 00 00 01 ....... ldap_write: want=115, written=115 0000: 30 71 02 01 03 64 6c 04 14 63 6e 3d 55 73 65 72 0q...dl..cn=User 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 54 30 2,o=de,dc=gac0T0 0020: 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f ...objectClass1. 0030: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 ..inetOrgPerson0 0040: 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d ...cn1...User20. 0050: 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 ..sn1...User20.. 0060: 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 .givenName1...Us 0070: 65 72 32 er2 conn=3 op=2 ENTRY dn="cn=user2,o=de,dc=gac" <= send_search_entry: conn 3 exit. ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 8d .... sasl_read: want=141, got=141 0000: f4 db 84 c1 97 c3 cb 7b cd b0 23 ed 24 6b 4e 4d .......{..#.$kNM 0010: 61 83 7b 94 17 4e f6 e3 df 53 aa bb e6 f4 b2 b1 a.{..N...S...... 0020: 0d d6 7e 75 33 9a ed 9d 87 af c4 f8 66 66 de 7e ..~u3.......ff.~ 0030: c8 e8 58 c7 9e c2 eb 0c 74 53 eb b2 56 8c 20 90 ..X.....tS..V. . 0040: dd 3d cb 16 f8 bd db a0 6d 3a 3e cf f5 f2 05 4d .=......m:>....M 0050: 61 cc 11 9f 3c 83 57 cd 08 95 2c 1e 0d 8e 05 74 a...<.W...,....t 0060: 02 90 00 e8 ec db 36 ac 17 01 dd 2a 78 c4 72 57 ......6....*x.rW 0070: 7b 30 4b a5 90 93 e3 c8 74 20 4f 2a 4a 86 24 89 {0K.....t O*J.$. 0080: 45 a9 0b 19 28 52 96 00 01 00 00 00 04 E...(R....... ldap_read: want=8, got=8 0000: 30 7b 02 01 03 64 76 04 0{...dv. ldap_read: want=117, got=117 0000: 1f 63 6e 3d 63 6f 6e 74 61 63 74 73 2c 63 6e 3d .cn=contacts,cn= 0010: 75 73 65 72 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 user,o=de,dc=gac 0020: 30 53 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 0S0...objectClas 0030: 73 31 0e 04 0c 67 72 6f 75 70 4f 66 4e 61 6d 65 s1...groupOfName 0040: 73 30 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 s0...cn1...conta 0050: 63 74 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 cts0 ..member1.. 0060: 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 .cn=user2,o=de,d 0070: 63 3d 67 61 63 c=gac ber_get_next: tag 0x30 len 123 contents: ber_dump: buf=0x8920ac0 ptr=0x8920ac0 end=0x8920b3b len=123 0000: 02 01 03 64 76 04 1f 63 6e 3d 63 6f 6e 74 61 63 ...dv..cn=contac 0010: 74 73 2c 63 6e 3d 75 73 65 72 2c 6f 3d 64 65 2c ts,cn=user,o=de, 0020: 64 63 3d 67 61 63 30 53 30 1d 04 0b 6f 62 6a 65 dc=gac0S0...obje 0030: 63 74 43 6c 61 73 73 31 0e 04 0c 67 72 6f 75 70 ctClass1...group 0040: 4f 66 4e 61 6d 65 73 30 10 04 02 63 6e 31 0a 04 OfNames0...cn1.. 0050: 08 63 6f 6e 74 61 63 74 73 30 20 04 06 6d 65 6d .contacts0 ..mem 0060: 62 65 72 31 16 04 14 63 6e 3d 75 73 65 72 32 2c ber1...cn=user2, 0070: 6f 3d 64 65 2c 64 63 3d 67 61 63 o=de,dc=gac read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b3b len=120 0000: 64 76 04 1f 63 6e 3d 63 6f 6e 74 61 63 74 73 2c dv..cn=contacts, 0010: 63 6e 3d 75 73 65 72 2c 6f 3d 64 65 2c 64 63 3d cn=user,o=de,dc= 0020: 67 61 63 30 53 30 1d 04 0b 6f 62 6a 65 63 74 43 gac0S0...objectC 0030: 6c 61 73 73 31 0e 04 0c 67 72 6f 75 70 4f 66 4e lass1...groupOfN 0040: 61 6d 65 73 30 10 04 02 63 6e 31 0a 04 08 63 6f ames0...cn1...co 0050: 6e 74 61 63 74 73 30 20 04 06 6d 65 6d 62 65 72 ntacts0 ..member 0060: 31 16 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 1...cn=user2,o=d 0070: 65 2c 64 63 3d 67 61 63 e,dc=gac [rw] searchResult: "cn=contacts,cn=user,o=de,dc=gac" -> "cn=contacts,cn=user,o=de,dc=gac" >>> dnPrettyNormal: <cn=contacts,cn=user,o=de,dc=gac> => ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac,0) <= ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=contacts,cn=user,o=de,dc=gac>, <cn=contacts,cn=user,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ae8 end=0x8920b3b len=83 0000: 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0e 04 0c 67 72 6f 75 70 4f 66 4e 61 6d 65 73 30 ...groupOfNames0 0020: 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 63 74 ...cn1...contact 0030: 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 63 s0 ..member1...c 0040: 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 3d n=user2,o=de,dc= 0050: 67 61 63 gac ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920af7 end=0x8920b3b len=68 0000: 00 0e 04 0c 67 72 6f 75 70 4f 66 4e 61 6d 65 73 ....groupOfNames 0010: 30 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 63 0...cn1...contac 0020: 74 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 ts0 ..member1... 0030: 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 cn=user2,o=de,dc 0040: 3d 67 61 63 =gac ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b07 end=0x8920b3b len=52 0000: 30 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 63 0...cn1...contac 0010: 74 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 ts0 ..member1... 0020: 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 cn=user2,o=de,dc 0030: 3d 67 61 63 =gac ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b0d end=0x8920b3b len=46 0000: 00 0a 04 08 63 6f 6e 74 61 63 74 73 30 20 04 06 ....contacts0 .. 0010: 6d 65 6d 62 65 72 31 16 04 14 63 6e 3d 75 73 65 member1...cn=use 0020: 72 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 r2,o=de,dc=gac ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b19 end=0x8920b3b len=34 0000: 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 63 6e 0 ..member1...cn 0010: 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 3d 67 =user2,o=de,dc=g 0020: 61 63 ac ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b23 end=0x8920b3b len=24 0000: 00 16 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 ....cn=user2,o=d 0010: 65 2c 64 63 3d 67 61 63 e,dc=gac [rw] searchAttrDN: "cn=user2,o=de,dc=gac" -> "cn=user2,o=de,dc=gac" >>> dnPretty: <cn=user2,o=de,dc=gac> => ldap_bv2dn(cn=user2,o=de,dc=gac,0) <= ldap_bv2dn(cn=user2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnPretty: <cn=user2,o=de,dc=gac> >>> dnNormalize: <cn=user2,o=de,dc=gac> => ldap_bv2dn(cn=user2,o=de,dc=gac,0) <= ldap_bv2dn(cn=user2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnNormalize: <cn=user2,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b3b end=0x8920b3b len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b3b len=120 0000: 64 76 04 1f 63 6e 3d 63 6f 6e 74 61 63 74 73 2c dv..cn=contacts, 0010: 63 6e 3d 75 73 65 72 2c 6f 3d 64 65 2c 64 63 3d cn=user,o=de,dc= 0020: 67 61 63 00 53 30 1d 04 0b 6f 62 6a 65 63 74 43 gac.S0...objectC 0030: 6c 61 73 73 00 0e 04 0c 67 72 6f 75 70 4f 66 4e lass....groupOfN 0040: 61 6d 65 73 30 10 04 02 63 6e 00 0a 04 08 63 6f ames0...cn....co 0050: 6e 74 61 63 74 73 30 20 04 06 6d 65 6d 62 65 72 ntacts0 ..member 0060: 00 16 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 ....cn=user2,o=d 0070: 65 2c 64 63 3d 67 61 63 e,dc=gac => send_search_entry: conn 3 dn="cn=contacts,cn=user,o=de,dc=gac" => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr entry => match[0]: 12 31 cn=user,o=de,dc=gac => match[1]: 15 19 user => match[2]: 22 24 de => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "objectClass" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr objectClass => match[0]: 12 31 cn=user,o=de,dc=gac => match[1]: 15 19 user => match[2]: 22 24 de => slap_access_allowed: result not in cache (objectClass) => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "objectClass" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "cn" requested => dn: [1] => acl_get: [3] attr cn => slap_access_allowed: result not in cache (cn) => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "cn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "member" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr member => match[0]: 12 31 cn=user,o=de,dc=gac => match[1]: 15 19 user => match[2]: 22 24 de => slap_access_allowed: result not in cache (member) => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "member" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) ber_flush2: 125 bytes to sd 11 0000: 30 7b 02 01 03 64 76 04 1f 63 6e 3d 63 6f 6e 74 0{...dv..cn=cont 0010: 61 63 74 73 2c 63 6e 3d 75 73 65 72 2c 6f 3d 64 acts,cn=user,o=d 0020: 65 2c 64 63 3d 67 61 63 30 53 30 1d 04 0b 6f 62 e,dc=gac0S0...ob 0030: 6a 65 63 74 43 6c 61 73 73 31 0e 04 0c 67 72 6f jectClass1...gro 0040: 75 70 4f 66 4e 61 6d 65 73 30 10 04 02 63 6e 31 upOfNames0...cn1 0050: 0a 04 08 63 6f 6e 74 61 63 74 73 30 20 04 06 6d ...contacts0 ..m 0060: 65 6d 62 65 72 31 16 04 14 63 6e 3d 75 73 65 72 ember1...cn=user 0070: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 2,o=de,dc=gac sasl_write: want=145, written=145 0000: 00 00 00 8d ee 90 f3 ed 59 ee b5 ec 5f ae 3e aa ........Y..._.>. 0010: de 12 bf a5 11 0c 1d 9c 66 04 f6 0e ed e0 31 f2 ........f.....1. 0020: 69 e7 93 6a 77 87 e6 25 8b ba 32 92 e1 6a f0 ec i..jw..%..2..j.. 0030: 6a 64 5c 9e be c0 f2 0e 5e 12 9d 68 0f c2 4e 06 jd\.....^..h..N. 0040: fd 22 ee 71 ee 9f 28 85 92 75 87 72 a8 29 23 39 .".q..(..u.r.)#9 0050: 73 93 ed 45 f3 97 48 64 fe 8d 5d a0 a3 22 62 9f s..E..Hd..].."b. 0060: 21 25 e0 3b 09 1c c3 83 94 8b 42 7d 2a 20 51 3c !%.;......B}* Q< 0070: 69 11 74 cd 5e d5 e3 24 22 d5 5d 3a b1 79 df cb i.t.^..$".]:.y.. 0080: 1b cb 37 c4 09 ef ac 8c 34 78 02 00 01 00 00 00 ..7.....4x...... 0090: 02 . ldap_write: want=125, written=125 0000: 30 7b 02 01 03 64 76 04 1f 63 6e 3d 63 6f 6e 74 0{...dv..cn=cont 0010: 61 63 74 73 2c 63 6e 3d 75 73 65 72 2c 6f 3d 64 acts,cn=user,o=d 0020: 65 2c 64 63 3d 67 61 63 30 53 30 1d 04 0b 6f 62 e,dc=gac0S0...ob 0030: 6a 65 63 74 43 6c 61 73 73 31 0e 04 0c 67 72 6f jectClass1...gro 0040: 75 70 4f 66 4e 61 6d 65 73 30 10 04 02 63 6e 31 upOfNames0...cn1 0050: 0a 04 08 63 6f 6e 74 61 63 74 73 30 20 04 06 6d ...contacts0 ..m 0060: 65 6d 62 65 72 31 16 04 14 63 6e 3d 75 73 65 72 ember1...cn=user 0070: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 2,o=de,dc=gac conn=3 op=2 ENTRY dn="cn=contacts,cn=user,o=de,dc=gac" <= send_search_entry: conn 3 exit. ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 1e .... sasl_read: want=30, got=30 0000: e6 89 1d 0c cb fc a4 1b d5 c0 5e cb 22 a0 24 0f ..........^.".$. 0010: e8 02 b2 bf d3 3e 8c a9 00 01 00 00 00 05 .....>........ ldap_read: want=8, got=8 0000: 30 0c 02 01 03 65 07 0a 0....e.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x8920b50 ptr=0x8920b50 end=0x8920b5c len=12 0000: 02 01 03 65 07 0a 01 00 04 00 04 00 ...e........ read1msg: ld 0x88f5380 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x8920b50 ptr=0x8920b53 end=0x8920b5c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ read1msg: ld 0x88f5380 0 new referrals read1msg: mark request completed, ld 0x88f5380 msgid 3 request done: ld 0x88f5380 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x8920b50 ptr=0x8920b53 end=0x8920b5c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ ber_scanf fmt (}) ber: ber_dump: buf=0x8920b50 ptr=0x8920b5c end=0x8920b5c len=0 conn=3 op=2 meta_back_search[0] match="" err=0. ldap_msgfree send_ldap_result: conn=3 op=2 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=3 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ sasl_write: want=34, written=34 0000: 00 00 00 1e e8 3c 38 df 4b 1c ec fb 55 92 5c 6f .....<8.K...U.\o 0010: 44 b1 7f d4 f6 72 9f 5c 9b ff e3 48 00 01 00 00 D....r.\...H.... 0020: 00 03 .. ldap_write: want=14, written=14 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ conn=3 op=2 SEARCH RESULT tag=101 err=0 nentries=3 text= daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ber_get_next sasl_read: want=4, got=0 ldap_read: want=8, got=0 ber_get_next on fd 11 failed errno=0 (Success) connection_read(11): input error=-2 id=3, closing. connection_closing: readying conn=3 sd=11 for close connection_close: conn=3 sd=11 =>meta_back_conn_destroy: fetching conn=3 DN="cn=user2,o=de,dc=gac" =>meta_back_conn_destroy: destroying conn 3 refcnt=0 flags=0x00000100 ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 13 0000: 30 05 02 01 04 42 00 0....B. sasl_write: want=27, written=27 0000: 00 00 00 17 f0 4f 68 14 67 7c 34 5e 9f 47 43 50 .....Oh.g|4^.GCP 0010: 42 3e 0f 96 ca 00 01 00 00 00 01 B>......... ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. ldap_free_connection: actually freed daemon: removing 11 conn=3 fd=11 closed (connection lost) 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 Target-Log daemon: activity on: slap_listener_activate(8): >>> slap_listener(ldap:///) daemon: listen=8, new connection on 11 daemon: added 11r (active) listener=(nil) conn=3 fd=11 ACCEPT from IP=192.168.112.12:42372 (IP=0.0.0.0:389) daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL 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: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ber_get_next ldap_read: want=8, got=8 0000: 30 18 02 01 01 60 13 02 0....`.. ldap_read: want=18, got=18 0000: 01 03 04 00 a3 0c 04 0a 44 49 47 45 53 54 2d 4d ........DIGEST-M 0010: 44 35 D5 ber_get_next: tag 0x30 len 24 contents: ber_dump: buf=0x88ede60 ptr=0x88ede60 end=0x88ede78 len=24 0000: 02 01 01 60 13 02 01 03 04 00 a3 0c 04 0a 44 49 ...`..........DI 0010: 47 45 53 54 2d 4d 44 35 GEST-MD5 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=3 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x88ede60 ptr=0x88ede63 end=0x88ede78 len=21 0000: 60 13 02 01 03 04 00 a3 0c 04 0a 44 49 47 45 53 `..........DIGES 0010: 54 2d 4d 44 35 T-MD5 ber_scanf fmt ({m) ber: ber_dump: buf=0x88ede60 ptr=0x88ede6a end=0x88ede78 len=14 0000: 00 0c 04 0a 44 49 47 45 53 54 2d 4d 44 35 ....DIGEST-MD5 ber_scanf fmt (}}) ber: ber_dump: buf=0x88ede60 ptr=0x88ede78 end=0x88ede78 len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> conn=3 op=0 BIND dn="" method=163 do_bind: dn () SASL mech DIGEST-MD5 ==> sasl_bind: dn="" mech=DIGEST-MD5 datalen=0 SASL [conn=3] Debug: DIGEST-MD5 server step 1 send_ldap_sasl: err=14 len=181 send_ldap_response: msgid=1 tag=97 err=14 ber_flush2: 228 bytes to sd 11 0000: 30 81 e1 02 01 01 61 81 db 0a 01 0e 04 00 04 1c 0.....a......... 0010: 53 41 53 4c 28 30 29 3a 20 73 75 63 63 65 73 73 SASL(0): success 0020: 66 75 6c 20 72 65 73 75 6c 74 3a 20 87 81 b5 6e ful result: ...n 0030: 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a 7a 43 4b once="RGB4/njzCK 0040: 65 42 59 38 62 36 35 69 77 48 70 47 77 64 6e 37 eBY8b65iwHpGwdn7 0050: 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a 70 5a 4d dK14UwoZjboIzpZM 0060: 45 3d 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e E=",realm="node. 0070: 67 61 63 22 2c 71 6f 70 3d 22 61 75 74 68 2c 61 gac",qop="auth,a 0080: 75 74 68 2d 69 6e 74 2c 61 75 74 68 2d 63 6f 6e uth-int,auth-con 0090: 66 22 2c 63 69 70 68 65 72 3d 22 72 63 34 2d 34 f",cipher="rc4-4 00a0: 30 2c 72 63 34 2d 35 36 2c 72 63 34 2c 64 65 73 0,rc4-56,rc4,des 00b0: 2c 33 64 65 73 22 2c 6d 61 78 62 75 66 3d 36 35 ,3des",maxbuf=65 00c0: 35 33 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 536,charset=utf- 00d0: 38 2c 61 6c 67 6f 72 69 74 68 6d 3d 6d 64 35 2d 8,algorithm=md5- 00e0: 73 65 73 73 sess ldap_write: want=228, written=228 0000: 30 81 e1 02 01 01 61 81 db 0a 01 0e 04 00 04 1c 0.....a......... 0010: 53 41 53 4c 28 30 29 3a 20 73 75 63 63 65 73 73 SASL(0): success 0020: 66 75 6c 20 72 65 73 75 6c 74 3a 20 87 81 b5 6e ful result: ...n 0030: 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a 7a 43 4b once="RGB4/njzCK 0040: 65 42 59 38 62 36 35 69 77 48 70 47 77 64 6e 37 eBY8b65iwHpGwdn7 0050: 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a 70 5a 4d dK14UwoZjboIzpZM 0060: 45 3d 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e E=",realm="node. 0070: 67 61 63 22 2c 71 6f 70 3d 22 61 75 74 68 2c 61 gac",qop="auth,a 0080: 75 74 68 2d 69 6e 74 2c 61 75 74 68 2d 63 6f 6e uth-int,auth-con 0090: 66 22 2c 63 69 70 68 65 72 3d 22 72 63 34 2d 34 f",cipher="rc4-4 00a0: 30 2c 72 63 34 2d 35 36 2c 72 63 34 2c 64 65 73 0,rc4-56,rc4,des 00b0: 2c 33 64 65 73 22 2c 6d 61 78 62 75 66 3d 36 35 ,3des",maxbuf=65 00c0: 35 33 36 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 536,charset=utf- 00d0: 38 2c 61 6c 67 6f 72 69 74 68 6d 3d 6d 64 35 2d 8,algorithm=md5- daemon: activity on 1 descriptor 00e0: 73 65 73 73 sess conn=3 op=0 RESULT tag=97 err=14 text=SASL(0): successful result: <== slap_sasl_bind: rc=14 daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ber_get_next ldap_read: want=8, got=8 0000: 30 82 01 29 02 01 02 60 0..)...` ldap_read: want=293, got=293 0000: 82 01 22 02 01 03 04 00 a3 82 01 19 04 0a 44 49 .."...........DI 0010: 47 45 53 54 2d 4d 44 35 04 82 01 09 75 73 65 72 GEST-MD5....user 0020: 6e 61 6d 65 3d 22 75 73 65 72 32 40 64 65 22 2c name="user2@de", 0030: 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 realm="node.gac" 0040: 2c 6e 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a 7a ,nonce="RGB4/njz 0050: 43 4b 65 42 59 38 62 36 35 69 77 48 70 47 77 64 CKeBY8b65iwHpGwd 0060: 6e 37 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a 70 n7dK14UwoZjboIzp 0070: 5a 4d 45 3d 22 2c 63 6e 6f 6e 63 65 3d 22 7a 32 ZME=",cnonce="z2 0080: 69 6c 2f 6c 32 61 39 77 72 47 73 7a 2b 6b 32 2b il/l2a9wrGsz+k2+ 0090: 59 67 6d 56 46 39 55 4d 72 5a 55 6a 59 6a 70 54 YgmVF9UMrZUjYjpT 00a0: 62 54 56 5a 6f 68 7a 45 67 3d 22 2c 6e 63 3d 30 bTVZohzEg=",nc=0 00b0: 30 30 30 30 30 30 31 2c 71 6f 70 3d 61 75 74 68 0000001,qop=auth 00c0: 2d 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 34 -conf,cipher=rc4 00d0: 2c 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 35 ,maxbuf=16777215 00e0: 2c 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 61 ,digest-uri="lda 00f0: 70 2f 6e 6f 64 65 2e 67 61 63 22 2c 72 65 73 70 p/node.gac",resp 0100: 6f 6e 73 65 3d 38 33 35 62 65 33 64 32 62 65 66 onse=835be3d2bef 0110: 30 31 32 34 35 62 66 66 61 33 35 66 30 64 39 39 01245bffa35f0d99 0120: 64 66 32 62 34 df2b4 ber_get_next: tag 0x30 len 297 contents: ber_dump: buf=0x89233e8 ptr=0x89233e8 end=0x8923511 len=297 0000: 02 01 02 60 82 01 22 02 01 03 04 00 a3 82 01 19 ...`.."......... 0010: 04 0a 44 49 47 45 53 54 2d 4d 44 35 04 82 01 09 ..DIGEST-MD5.... 0020: 75 73 65 72 6e 61 6d 65 3d 22 75 73 65 72 32 40 username="user2@ 0030: 64 65 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e de",realm="node. 0040: 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 52 47 42 34 gac",nonce="RGB4 0050: 2f 6e 6a 7a 43 4b 65 42 59 38 62 36 35 69 77 48 /njzCKeBY8b65iwH 0060: 70 47 77 64 6e 37 64 4b 31 34 55 77 6f 5a 6a 62 pGwdn7dK14UwoZjb 0070: 6f 49 7a 70 5a 4d 45 3d 22 2c 63 6e 6f 6e 63 65 oIzpZME=",cnonce 0080: 3d 22 7a 32 69 6c 2f 6c 32 61 39 77 72 47 73 7a ="z2il/l2a9wrGsz 0090: 2b 6b 32 2b 59 67 6d 56 46 39 55 4d 72 5a 55 6a +k2+YgmVF9UMrZUj 00a0: 59 6a 70 54 62 54 56 5a 6f 68 7a 45 67 3d 22 2c YjpTbTVZohzEg=", 00b0: 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f 70 3d nc=00000001,qop= 00c0: 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 65 72 auth-conf,cipher 00d0: 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 37 37 =rc4,maxbuf=1677 00e0: 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 69 3d 7215,digest-uri= 00f0: 22 6c 64 61 70 2f 6e 6f 64 65 2e 67 61 63 22 2c "ldap/node.gac", 0100: 72 65 73 70 6f 6e 73 65 3d 38 33 35 62 65 33 64 response=835be3d 0110: 32 62 65 66 30 31 32 34 35 62 66 66 61 33 35 66 2bef01245bffa35f 0120: 30 64 39 39 64 66 32 62 34 0d99df2b4 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable conn=3 op=1 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x89233e8 ptr=0x89233eb end=0x8923511 len=294 daemon: activity on 1 descriptor 0000: 60 82 01 22 02 01 03 04 00 a3 82 01 19 04 0a 44 `.."...........D 0010: 49 47 45 53 54 2d 4d 44 35 04 82 01 09 75 73 65 IGEST-MD5....use 0020: 72 6e 61 6d 65 3d 22 75 73 65 72 32 40 64 65 22 rname="user2@de" 0030: 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 ,realm="node.gac 0040: 22 2c 6e 6f 6e 63 65 3d 22 52 47 42 34 2f 6e 6a ",nonce="RGB4/nj 0050: 7a 43 4b 65 42 59 38 62 36 35 69 77 48 70 47 77 zCKeBY8b65iwHpGw 0060: 64 6e 37 64 4b 31 34 55 77 6f 5a 6a 62 6f 49 7a dn7dK14UwoZjboIz 0070: 70 5a 4d 45 3d 22 2c 63 6e 6f 6e 63 65 3d 22 7a pZME=",cnonce="z 0080: 32 69 6c 2f 6c 32 61 39 77 72 47 73 7a 2b 6b 32 2il/l2a9wrGsz+k2 0090: 2b 59 67 6d 56 46 39 55 4d 72 5a 55 6a 59 6a 70 +YgmVF9UMrZUjYjp 00a0: 54 62 54 56 5a 6f 68 7a 45 67 3d 22 2c 6e 63 3d TbTVZohzEg=",nc= 00b0: 30 30 30 30 30 30 30 31 2c 71 6f 70 3d 61 75 74 00000001,qop=aut 00c0: 68 2d 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 h-conf,cipher=rc 00d0: 34 2c 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 4,maxbuf=1677721 00e0: 35 2c 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 5,digest-uri="ld 00f0: 61 70 2f 6e 6f 64 65 2e 67 61 63 22 2c 72 65 73 ap/node.gac",res 0100: 70 6f 6e 73 65 3d 38 33 35 62 65 33 64 32 62 65 ponse=835be3d2be 0110: 66 30 31 32 34 35 62 66 66 61 33 35 66 30 64 39 f01245bffa35f0d9 0120: 39 64 66 32 62 34 9df2b4 ber_scanf fmt ({m) ber: ber_dump: buf=0x89233e8 ptr=0x89233f4 end=0x8923511 len=285 0000: 00 82 01 19 04 0a 44 49 47 45 53 54 2d 4d 44 35 ......DIGEST-MD5 0010: 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 75 73 ....username="us 0020: 65 72 32 40 64 65 22 2c 72 65 61 6c 6d 3d 22 6e er2@de",realm="n 0030: 6f 64 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 ode.gac",nonce=" 0040: 52 47 42 34 2f 6e 6a 7a 43 4b 65 42 59 38 62 36 RGB4/njzCKeBY8b6 0050: 35 69 77 48 70 47 77 64 6e 37 64 4b 31 34 55 77 5iwHpGwdn7dK14Uw 0060: 6f 5a 6a 62 6f 49 7a 70 5a 4d 45 3d 22 2c 63 6e oZjboIzpZME=",cn 0070: 6f 6e 63 65 3d 22 7a 32 69 6c 2f 6c 32 61 39 77 once="z2il/l2a9w 0080: 72 47 73 7a 2b 6b 32 2b 59 67 6d 56 46 39 55 4d rGsz+k2+YgmVF9UM 0090: 72 5a 55 6a 59 6a 70 54 62 54 56 5a 6f 68 7a 45 rZUjYjpTbTVZohzE 00a0: 67 3d 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c g=",nc=00000001, 00b0: 71 6f 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 qop=auth-conf,ci 00c0: 70 68 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d pher=rc4,maxbuf= 00d0: 31 36 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 16777215,digest- 00e0: 75 72 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2e 67 uri="ldap/node.g 00f0: 61 63 22 2c 72 65 73 70 6f 6e 73 65 3d 38 33 35 ac",response=835 0100: 62 65 33 64 32 62 65 66 30 31 32 34 35 62 66 66 be3d2bef01245bff 0110: 61 33 35 66 30 64 39 39 64 66 32 62 34 a35f0d99df2b4 ber_scanf fmt (m) ber: ber_dump: buf=0x89233e8 ptr=0x8923404 end=0x8923511 len=269 0000: 00 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 75 73 ....username="us 0010: 65 72 32 40 64 65 22 2c 72 65 61 6c 6d 3d 22 6e er2@de",realm="n 0020: 6f 64 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 ode.gac",nonce=" 0030: 52 47 42 34 2f 6e 6a 7a 43 4b 65 42 59 38 62 36 RGB4/njzCKeBY8b6 0040: 35 69 77 48 70 47 77 64 6e 37 64 4b 31 34 55 77 5iwHpGwdn7dK14Uw 0050: 6f 5a 6a 62 6f 49 7a 70 5a 4d 45 3d 22 2c 63 6e oZjboIzpZME=",cn 0060: 6f 6e 63 65 3d 22 7a 32 69 6c 2f 6c 32 61 39 77 once="z2il/l2a9w 0070: 72 47 73 7a 2b 6b 32 2b 59 67 6d 56 46 39 55 4d rGsz+k2+YgmVF9UM 0080: 72 5a 55 6a 59 6a 70 54 62 54 56 5a 6f 68 7a 45 rZUjYjpTbTVZohzE 0090: 67 3d 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c g=",nc=00000001, 00a0: 71 6f 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 qop=auth-conf,ci 00b0: 70 68 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d pher=rc4,maxbuf= 00c0: 31 36 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 16777215,digest- 00d0: 75 72 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2e 67 uri="ldap/node.g 00e0: 61 63 22 2c 72 65 73 70 6f 6e 73 65 3d 38 33 35 ac",response=835 00f0: 62 65 33 64 32 62 65 66 30 31 32 34 35 62 66 66 be3d2bef01245bff 0100: 61 33 35 66 30 64 39 39 64 66 32 62 34 a35f0d99df2b4 ber_scanf fmt (}}) ber: ber_dump: buf=0x89233e8 ptr=0x8923511 end=0x8923511 len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> conn=3 op=1 BIND dn="" method=163 do_bind: dn () SASL mech DIGEST-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=265 SASL [conn=3] Debug: DIGEST-MD5 server step 2 SASL Canonicalize [conn=3]: authcid="user2@de" slap_sasl_getdn: conn 3 id=user2@de [len=8] => ldap_dn2bv(16) <= ldap_dn2bv(uid=user2@de,cn=DIGEST-MD5,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=user2@de,cn=DIGEST-MD5,cn=auth >>> dnNormalize: <uid=user2@de,cn=DIGEST-MD5,cn=auth> => ldap_bv2dn(uid=user2@de,cn=DIGEST-MD5,cn=auth,0) <= ldap_bv2dn(uid=user2@de,cn=DIGEST-MD5,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=user2@de,cn=digest-md5,cn=auth)=0 <<< dnNormalize: <uid=user2@de,cn=digest-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=user2@de,cn=digest-md5,cn=auth to a DN ==> rewrite_context_apply [depth=1] string='uid=user2@de,cn=digest-md5,cn=auth' ==> rewrite_rule_apply rule='uid=datadmin,cn=digest-md5,cn=auth' string='uid=user2@de,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_rule_apply rule='uid=([^,@]*)@([^,]*),cn=digest-md5,cn=auth' string='uid=user2@de,cn=digest-md5,cn=auth' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'cn=user2,o=de,dc=gac'} [rw] authid: "uid=user2@de,cn=digest-md5,cn=auth" -> "cn=user2,o=de,dc=gac" slap_parseURI: parsing cn=user2,o=de,dc=gac ldap_url_parse_ext(cn=user2,o=de,dc=gac) >>> dnNormalize: <cn=user2,o=de,dc=gac> => ldap_bv2dn(cn=user2,o=de,dc=gac,0) <= ldap_bv2dn(cn=user2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnNormalize: <cn=user2,o=de,dc=gac> <==slap_sasl2dn: Converted SASL name to cn=user2,o=de,dc=gac slap_sasl_getdn: dn:id converted to cn=user2,o=de,dc=gac SASL Canonicalize [conn=3]: slapAuthcDN="cn=user2,o=de,dc=gac" conn=3 op=1: meta_back_getconn[0] conn=3 op=1 meta_back_getconn: candidates=1 conn=-1 fetched conn=3 op=1 >>> meta_back_search_start[0] conn=3 op=1 >>> meta_search_dobind_init[0] conn=3 op=1 <<< meta_search_dobind_init[0]=1 [rw] searchBase: "cn=user2,o=de,dc=gac" -> "cn=user2,o=de,dc=gac" [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" ldap_search_ext put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x8924c28 ptr=0x8924c28 end=0x8924c63 len=59 0000: 30 39 02 01 05 63 34 04 14 63 6e 3d 75 73 65 72 09...c4..cn=user 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 0a 01 00 2,o=de,dc=gac... 0020: 0a 01 00 02 01 01 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 30 00 jectClass0. ber_scanf fmt ({) ber: ber_dump: buf=0x8924c28 ptr=0x8924c2d end=0x8924c63 len=54 0000: 63 34 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 c4..cn=user2,o=d 0010: 65 2c 64 63 3d 67 61 63 0a 01 00 0a 01 00 02 01 e,dc=gac........ 0020: 01 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 43 .........objectC 0030: 6c 61 73 73 30 00 lass0. ber_flush2: 59 bytes to sd 12 0000: 30 39 02 01 05 63 34 04 14 63 6e 3d 75 73 65 72 09...c4..cn=user 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 0a 01 00 2,o=de,dc=gac... 0020: 0a 01 00 02 01 01 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 30 00 jectClass0. ldap_write: want=59, written=59 0000: 30 39 02 01 05 63 34 04 14 63 6e 3d 75 73 65 72 09...c4..cn=user 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 0a 01 00 2,o=de,dc=gac... 0020: 0a 01 00 02 01 01 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0030: 6a 65 63 74 43 6c 61 73 73 30 00 jectClass0. conn=3 op=1 <<< meta_back_search_start[0]=1 conn=3 op=1 meta_back_search: ncandidates=1 cnd="*" ldap_result ld 0x8900620 msgid 5 wait4msg ld 0x8900620 msgid 5 (timeout 0 usec) wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: Empty ld 0x8900620 response count 0 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 NULL ldap_int_select daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL ldap_result ld 0x8900620 msgid 5 wait4msg ld 0x8900620 msgid 5 (timeout 100000 usec) wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: Empty ld 0x8900620 response count 0 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 NULL ldap_int_select read1msg: ld 0x8900620 msgid 5 all 2 ber_get_next ldap_read: want=8, got=8 0000: 30 81 8a 02 01 05 64 81 0.....d. ldap_read: want=133, got=133 0000: 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d 64 65 ...cn=User2,o=de 0010: 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f 62 6a ,dc=gac0l0...obj 0020: 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 74 ectClass1...inet 0030: 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 6e 31 OrgPerson0...cn1 0040: 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 07 ...User20...sn1. 0050: 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 6e ..User20...given 0060: 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 04 Name1...User20.. 0070: 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 .userPassword1.. 0080: 04 70 61 73 73 .pass ber_get_next: tag 0x30 len 138 contents: ber_dump: buf=0x89000f8 ptr=0x89000f8 end=0x8900182 len=138 0000: 02 01 05 64 81 84 04 14 63 6e 3d 55 73 65 72 32 ...d....cn=User2 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e ,o=de,dc=gac0l0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d .inetOrgPerson0. 0040: 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d 04 ..cn1...User20.. 0050: 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 09 .sn1...User20... 0060: 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 givenName1...Use 0070: 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f r20...userPasswo 0080: 72 64 31 06 04 04 70 61 73 73 rd1...pass read1msg: ld 0x8900620 msgid 5 message type search-entry wait4msg ld 0x8900620 0 s 94885 us to go wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: * msgid 5, type 100 ld 0x8900620 response count 1 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 msgid 5, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x89000f8 ptr=0x89000fb end=0x8900182 len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f de,dc=gac0l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e bjectClass1...in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 31 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n1...User20...sn 0050: 31 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 1...User20...giv 0060: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0080: 06 04 04 70 61 73 73 ...pass [rw] searchResult: "cn=User2,o=de,dc=gac" -> "cn=User2,o=de,dc=gac" >>> dnPrettyNormal: <cn=User2,o=de,dc=gac> => ldap_bv2dn(cn=User2,o=de,dc=gac,0) <= ldap_bv2dn(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=User2,o=de,dc=gac>, <cn=user2,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900116 end=0x8900182 len=108 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0030: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0040: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0050: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0060: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x8900125 end=0x8900182 len=93 0000: 00 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f ....inetOrgPerso 0010: 6e 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 n0...cn1...User2 0020: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0030: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0040: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0050: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900136 end=0x8900182 len=76 0000: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0010: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0020: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0030: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0040: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x890013c end=0x8900182 len=70 0000: 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 ....User20...sn1 0010: 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 ...User20...give 0020: 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 nName1...User20. 0030: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 ..userPassword1. 0040: 04 04 70 61 73 73 ..pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900145 end=0x8900182 len=61 0000: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0010: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0020: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0030: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x890014b end=0x8900182 len=55 0000: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0010: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0020: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0030: 06 04 04 70 61 73 73 ...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900154 end=0x8900182 len=46 0000: 30 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 0...givenName1.. 0010: 05 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 .User20...userPa 0020: 73 73 77 6f 72 64 31 06 04 04 70 61 73 73 ssword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x8900161 end=0x8900182 len=33 0000: 00 07 04 05 55 73 65 72 32 30 16 04 0c 75 73 65 ....User20...use 0010: 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 rPassword1...pas 0020: 73 s ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x890016a end=0x8900182 len=24 0000: 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 0...userPassword 0010: 31 06 04 04 70 61 73 73 1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x89000f8 ptr=0x890017a end=0x8900182 len=8 0000: 00 06 04 04 70 61 73 73 ....pass ber_scanf fmt ({m) ber: ber_dump: buf=0x89000f8 ptr=0x8900182 end=0x8900182 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x89000f8 ptr=0x89000fb end=0x8900182 len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 00 6c 30 1e 04 0b 6f de,dc=gac.l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 00 0f 04 0d 69 6e bjectClass....in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n....User20...sn 0050: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0060: 65 6e 4e 61 6d 65 00 07 04 05 55 73 65 72 32 30 enName....User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 00 ...userPassword. 0080: 06 04 04 70 61 73 73 ...pass => access_allowed: auth access to "cn=User2,o=de,dc=gac" "userPassword" requested => dn: [1] => acl_get: [2] attr userPassword => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "userPassword" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: cn=datadmin,dc=gac <= check a_dn_pat: * <= acl_mask: [2] applying auth(=xd) (stop) <= acl_mask: [2] mask: auth(=xd) => slap_access_allowed: auth access granted by auth(=xd) => access_allowed: auth access granted by auth(=xd) slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined ldap_msgfree ldap_result ld 0x8900620 msgid 5 wait4msg ld 0x8900620 msgid 5 (timeout 0 usec) wait4msg continue ld 0x8900620 msgid 5 all 2 ** ld 0x8900620 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:23 2009 ** ld 0x8900620 Outstanding Requests: * msgid 5, origid 5, status InProgress outstanding referrals 0, parent count 0 ld 0x8900620 request count 1 (abandoned 0) ** ld 0x8900620 Response Queue: Empty ld 0x8900620 response count 0 ldap_chkResponseList ld 0x8900620 msgid 5 all 2 ldap_chkResponseList returns ld 0x8900620 NULL ldap_int_select read1msg: ld 0x8900620 msgid 5 all 2 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 05 65 07 0a 0....e.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x88ecb80 ptr=0x88ecb80 end=0x88ecb8c len=12 0000: 02 01 05 65 07 0a 01 00 04 00 04 00 ...e........ read1msg: ld 0x8900620 msgid 5 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x88ecb80 ptr=0x88ecb83 end=0x88ecb8c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ read1msg: ld 0x8900620 0 new referrals read1msg: mark request completed, ld 0x8900620 msgid 5 request done: ld 0x8900620 msgid 5 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 5, msgid 5) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x88ecb80 ptr=0x88ecb83 end=0x88ecb8c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ ber_scanf fmt (}) ber: ber_dump: buf=0x88ecb80 ptr=0x88ecb8c end=0x88ecb8c len=0 conn=3 op=1 meta_back_search[0] match="" err=0. ldap_msgfree send_ldap_result: conn=3 op=1 p=3 send_ldap_result: err=0 matched="" text="" SASL Canonicalize [conn=3]: authzid="user2@de" SASL proxy authorize [conn=3]: authcid="user2@de" authzid="user2@de" conn=3 op=1 BIND authcid="user2@de" authzid="user2@de" SASL Authorize [conn=3]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=40 conn=3 op=1 BIND dn="cn=user2,o=de,dc=gac" mech=DIGEST-MD5 sasl_ssf=128 ssf=128 do_bind: SASL/DIGEST-MD5 bind: dn="cn=user2,o=de,dc=gac" sasl_ssf=128 send_ldap_response: msgid=2 tag=97 err=0 ber_flush2: 56 bytes to sd 11 0000: 30 36 02 01 02 61 31 0a 01 00 04 00 04 00 87 28 06...a1........( 0010: 72 73 70 61 75 74 68 3d 36 34 64 32 34 61 33 66 rspauth=64d24a3f 0020: 35 36 32 65 64 62 62 64 35 66 39 61 33 61 62 62 562edbbd5f9a3abb 0030: 36 34 35 39 34 62 37 61 64594b7a ldap_write: want=56, written=56 0000: 30 36 02 01 02 61 31 0a 01 00 04 00 04 00 87 28 06...a1........( 0010: 72 73 70 61 75 74 68 3d 36 34 64 32 34 61 33 66 rspauth=64d24a3f 0020: 35 36 32 65 64 62 62 64 35 66 39 61 33 61 62 62 562edbbd5f9a3abb 0030: 36 34 35 39 34 62 37 61 64594b7a conn=3 op=1 RESULT tag=97 err=0 text= <== slap_sasl_bind: rc=0 daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ldap_pvt_sasl_install ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 3d ...= sasl_read: want=61, got=61 0000: 61 16 8b 42 1b 22 4d 2a 76 d5 8a 4c ae c0 47 ea a..B."M*v..L..G. 0010: 15 10 7e 7f a7 72 20 20 d9 cc d5 f6 47 ca e4 01 ..~..r ....G... 0020: 9f 09 d0 1e 86 e0 a2 7e 23 a4 fd 64 2d 1b 7e b7 .......~#..d-.~. 0030: 7a 9b f5 35 56 1b dd 00 01 00 00 00 00 z..5V........ ldap_read: want=8, got=8 0000: 30 2b 02 01 03 63 26 04 0+...c&. ldap_read: want=37, got=37 0000: 06 64 63 3d 67 61 63 0a 01 02 0a 01 00 02 01 00 .dc=gac......... 0010: 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c ........objectcl 0020: 61 73 73 30 00 ass0. ber_get_next: tag 0x30 len 43 contents: ber_dump: buf=0x8923fa0 ptr=0x8923fa0 end=0x8923fcb len=43 0000: 02 01 03 63 26 04 06 64 63 3d 67 61 63 0a 01 02 ...c&..dc=gac... 0010: 0a 01 00 02 01 00 02 01 00 01 01 00 87 0b 6f 62 ..............ob 0020: 6a 65 63 74 63 6c 61 73 73 30 00 jectclass0. ber_get_next sasl_read: want=4 error=Resource temporarily unavailable ldap_read: want=8 error=Resource temporarily unavailable conn=3 op=2 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=0x8923fa0 ptr=0x8923fa3 end=0x8923fcb len=40 0000: 63 26 04 06 64 63 3d 67 61 63 0a 01 02 0a 01 00 c&..dc=gac...... 0010: 02 01 00 02 01 00 01 01 00 87 0b 6f 62 6a 65 63 ...........objec 0020: 74 63 6c 61 73 73 30 00 tclass0. >>> dnPrettyNormal: <dc=gac> => ldap_bv2dn(dc=gac,0) <= ldap_bv2dn(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 <<< dnPrettyNormal: <dc=gac>, <dc=gac> SRCH "dc=gac" 2 0 0 0 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=0x8923fa0 ptr=0x8923fbc end=0x8923fcb len=15 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 00 ..objectclass0. end get_filter 0 filter: (objectClass=*) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x8923fa0 ptr=0x8923fc9 end=0x8923fcb len=2 0000: 00 00 .. attrs: conn=3 op=2 SRCH base="dc=gac" scope=2 deref=0 filter="(objectClass=*)" ==> limits_get: conn=3 op=2 dn="cn=user2,o=de,dc=gac" ldap_create ldap_url_parse_ext(ldap://192.168.112.11) conn=3 op=2: meta_back_getconn[0] conn=3 op=2 meta_back_getconn: candidates=1 conn=3 inserted conn=3 op=2 >>> meta_back_search_start[0] conn=3 op=2 >>> meta_search_dobind_init[0] ldap_sasl_interactive_bind_s: user selected: digest-md5 ldap_int_sasl_bind: digest-md5 ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.112.11:389 ldap_new_socket: 13 ldap_prepare_socket: 13 ldap_connect_to_host: Trying 192.168.112.11:389 ldap_pvt_connect: fd: 13 tm: -1 async: 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 ldap_int_sasl_open: host=node-2.local ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x8920818 ptr=0x8920818 end=0x8920957 len=319 0000: 30 82 01 3b 02 01 01 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 78 77 e.gac",nonce="xw 0060: 4b 72 6a 59 52 4a 65 48 72 65 41 49 66 46 37 65 KrjYRJeHreAIfF7e 0070: 55 61 33 2b 4c 64 31 39 78 78 74 4b 76 61 34 38 Ua3+Ld19xxtKva48 0080: 6e 39 4c 39 38 46 56 71 41 3d 22 2c 63 6e 6f 6e n9L98FVqA=",cnon 0090: 63 65 3d 22 43 33 59 47 59 47 72 34 76 56 41 4f ce="C3YGYGr4vVAO 00a0: 61 71 63 48 59 48 47 44 76 4e 44 77 4a 54 30 46 aqcHYHGDvNDwJT0F 00b0: 6f 59 47 77 51 75 42 52 49 68 58 4f 73 5a 41 3d oYGwQuBRIhXOsZA= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 32 2c 71 6f ",nc=00000002,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 31 ocal",response=1 0120: 39 34 63 34 63 64 36 32 33 30 36 66 30 38 61 32 94c4cd62306f08a2 0130: 61 38 30 64 36 31 32 65 32 61 65 36 63 37 38 a80d612e2ae6c78 ber_scanf fmt ({i) ber: ber_dump: buf=0x8920818 ptr=0x892081f end=0x8920957 len=312 0000: 60 82 01 34 02 01 03 04 12 63 6e 3d 64 61 74 61 `..4.....cn=data 0010: 64 6d 69 6e 2c 64 63 3d 67 61 63 a3 82 01 19 04 dmin,dc=gac..... 0020: 0a 44 49 47 45 53 54 2d 4d 44 35 04 82 01 09 75 .DIGEST-MD5....u 0030: 73 65 72 6e 61 6d 65 3d 22 72 6f 6f 74 22 2c 72 sername="root",r 0040: 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c ealm="node.gac", 0050: 6e 6f 6e 63 65 3d 22 78 77 4b 72 6a 59 52 4a 65 nonce="xwKrjYRJe 0060: 48 72 65 41 49 66 46 37 65 55 61 33 2b 4c 64 31 HreAIfF7eUa3+Ld1 0070: 39 78 78 74 4b 76 61 34 38 6e 39 4c 39 38 46 56 9xxtKva48n9L98FV 0080: 71 41 3d 22 2c 63 6e 6f 6e 63 65 3d 22 43 33 59 qA=",cnonce="C3Y 0090: 47 59 47 72 34 76 56 41 4f 61 71 63 48 59 48 47 GYGr4vVAOaqcHYHG 00a0: 44 76 4e 44 77 4a 54 30 46 6f 59 47 77 51 75 42 DvNDwJT0FoYGwQuB 00b0: 52 49 68 58 4f 73 5a 41 3d 22 2c 6e 63 3d 30 30 RIhXOsZA=",nc=00 00c0: 30 30 30 30 30 32 2c 71 6f 70 3d 61 75 74 68 2d 000002,qop=auth- 00d0: 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 34 2c conf,cipher=rc4, 00e0: 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 35 2c maxbuf=16777215, 00f0: 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 61 70 digest-uri="ldap 0100: 2f 6e 6f 64 65 2d 32 2e 6c 6f 63 61 6c 22 2c 72 /node-2.local",r 0110: 65 73 70 6f 6e 73 65 3d 31 39 34 63 34 63 64 36 esponse=194c4cd6 0120: 32 33 30 36 66 30 38 61 32 61 38 30 64 36 31 32 2306f08a2a80d612 0130: 65 32 61 65 36 63 37 38 e2ae6c78 ber_flush2: 319 bytes to sd 13 0000: 30 82 01 3b 02 01 01 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 78 77 e.gac",nonce="xw 0060: 4b 72 6a 59 52 4a 65 48 72 65 41 49 66 46 37 65 KrjYRJeHreAIfF7e 0070: 55 61 33 2b 4c 64 31 39 78 78 74 4b 76 61 34 38 Ua3+Ld19xxtKva48 0080: 6e 39 4c 39 38 46 56 71 41 3d 22 2c 63 6e 6f 6e n9L98FVqA=",cnon 0090: 63 65 3d 22 43 33 59 47 59 47 72 34 76 56 41 4f ce="C3YGYGr4vVAO 00a0: 61 71 63 48 59 48 47 44 76 4e 44 77 4a 54 30 46 aqcHYHGDvNDwJT0F 00b0: 6f 59 47 77 51 75 42 52 49 68 58 4f 73 5a 41 3d oYGwQuBRIhXOsZA= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 32 2c 71 6f ",nc=00000002,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 31 ocal",response=1 0120: 39 34 63 34 63 64 36 32 33 30 36 66 30 38 61 32 94c4cd62306f08a2 0130: 61 38 30 64 36 31 32 65 32 61 65 36 63 37 38 a80d612e2ae6c78 ldap_write: want=319, written=319 0000: 30 82 01 3b 02 01 01 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 78 77 e.gac",nonce="xw 0060: 4b 72 6a 59 52 4a 65 48 72 65 41 49 66 46 37 65 KrjYRJeHreAIfF7e 0070: 55 61 33 2b 4c 64 31 39 78 78 74 4b 76 61 34 38 Ua3+Ld19xxtKva48 0080: 6e 39 4c 39 38 46 56 71 41 3d 22 2c 63 6e 6f 6e n9L98FVqA=",cnon 0090: 63 65 3d 22 43 33 59 47 59 47 72 34 76 56 41 4f ce="C3YGYGr4vVAO 00a0: 61 71 63 48 59 48 47 44 76 4e 44 77 4a 54 30 46 aqcHYHGDvNDwJT0F 00b0: 6f 59 47 77 51 75 42 52 49 68 58 4f 73 5a 41 3d oYGwQuBRIhXOsZA= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 32 2c 71 6f ",nc=00000002,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 31 ocal",response=1 0120: 39 34 63 34 63 64 36 32 33 30 36 66 30 38 61 32 94c4cd62306f08a2 0130: 61 38 30 64 36 31 32 65 32 61 65 36 63 37 38 a80d612e2ae6c78 ldap_result ld 0x88f5380 msgid 1 wait4msg ld 0x88f5380 msgid 1 (infinite timeout) wait4msg continue ld 0x88f5380 msgid 1 all 1 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 1 all 1 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 81 e1 02 01 01 61 81 0.....a. ldap_read: want=220, got=220 0000: db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 29 3a ........SASL(0): 0010: 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 73 75 successful resu 0020: 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 49 6a lt: ...nonce="Ij 0030: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0040: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0050: 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 61 6c aHFtRDLCA=",real 0060: 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 6f 70 m="node.gac",qop 0070: 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e 74 2c ="auth,auth-int, 0080: 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 68 65 auth-conf",ciphe 0090: 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d 35 36 r="rc4-40,rc4-56 00a0: 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 2c 6d ,rc4,des,3des",m 00b0: 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 61 72 axbuf=65536,char 00c0: 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f 72 69 set=utf-8,algori 00d0: 74 68 6d 3d 6d 64 35 2d 73 65 73 73 thm=md5-sess ber_get_next: tag 0x30 len 225 contents: ber_dump: buf=0x89242a8 ptr=0x89242a8 end=0x8924389 len=225 0000: 02 01 01 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 ...a.........SAS 0010: 4c 28 30 29 3a 20 73 75 63 63 65 73 73 66 75 6c L(0): successful 0020: 20 72 65 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 result: ...nonc 0030: 65 3d 22 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a e="Ijq+Ki4kJzVIz 0040: 74 6c 33 47 51 36 78 37 51 79 6e 77 73 4f 52 6a tl3GQ6x7QynwsORj 0050: 6f 64 47 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 odGzTaHFtRDLCA=" 0060: 2c 72 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 ,realm="node.gac 0070: 22 2c 71 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 ",qop="auth,auth 0080: 2d 69 6e 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c -int,auth-conf", 0090: 63 69 70 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 cipher="rc4-40,r 00a0: 63 34 2d 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 c4-56,rc4,des,3d 00b0: 65 73 22 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 es",maxbuf=65536 00c0: 2c 63 68 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 ,charset=utf-8,a 00d0: 6c 67 6f 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 lgorithm=md5-ses 00e0: 73 s read1msg: ld 0x88f5380 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x8924389 len=222 0000: 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 a.........SASL(0 0010: 29 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 ): successful re 0020: 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 sult: ...nonce=" 0030: 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 Ijq+Ki4kJzVIztl3 0040: 47 51 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 GQ6x7QynwsORjodG 0050: 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 zTaHFtRDLCA=",re 0060: 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 alm="node.gac",q 0070: 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e op="auth,auth-in 0080: 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 t,auth-conf",cip 0090: 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d her="rc4-40,rc4- 00a0: 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 56,rc4,des,3des" 00b0: 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 ,maxbuf=65536,ch 00c0: 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f arset=utf-8,algo 00d0: 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 73 rithm=md5-sess read1msg: ld 0x88f5380 0 new referrals read1msg: mark request completed, ld 0x88f5380 msgid 1 request done: ld 0x88f5380 msgid 1 res_errno: 14, res_error: <SASL(0): successful result: >, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x8924389 len=222 0000: 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 a.........SASL(0 0010: 29 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 ): successful re 0020: 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 sult: ...nonce=" 0030: 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 Ijq+Ki4kJzVIztl3 0040: 47 51 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 GQ6x7QynwsORjodG 0050: 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 zTaHFtRDLCA=",re 0060: 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 alm="node.gac",q 0070: 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e op="auth,auth-in 0080: 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 t,auth-conf",cip 0090: 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d her="rc4-40,rc4- 00a0: 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 56,rc4,des,3des" 00b0: 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 ,maxbuf=65536,ch 00c0: 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f arset=utf-8,algo 00d0: 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 73 rithm=md5-sess ber_scanf fmt (O) ber: ber_dump: buf=0x89242a8 ptr=0x89242d1 end=0x8924389 len=184 0000: 87 81 b5 6e 6f 6e 63 65 3d 22 49 6a 71 2b 4b 69 ...nonce="Ijq+Ki 0010: 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 36 78 37 51 4kJzVIztl3GQ6x7Q 0020: 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 61 48 46 74 ynwsORjodGzTaHFt 0030: 52 44 4c 43 41 3d 22 2c 72 65 61 6c 6d 3d 22 6e RDLCA=",realm="n 0040: 6f 64 65 2e 67 61 63 22 2c 71 6f 70 3d 22 61 75 ode.gac",qop="au 0050: 74 68 2c 61 75 74 68 2d 69 6e 74 2c 61 75 74 68 th,auth-int,auth 0060: 2d 63 6f 6e 66 22 2c 63 69 70 68 65 72 3d 22 72 -conf",cipher="r 0070: 63 34 2d 34 30 2c 72 63 34 2d 35 36 2c 72 63 34 c4-40,rc4-56,rc4 0080: 2c 64 65 73 2c 33 64 65 73 22 2c 6d 61 78 62 75 ,des,3des",maxbu 0090: 66 3d 36 35 35 33 36 2c 63 68 61 72 73 65 74 3d f=65536,charset= 00a0: 75 74 66 2d 38 2c 61 6c 67 6f 72 69 74 68 6d 3d utf-8,algorithm= 00b0: 6d 64 35 2d 73 65 73 73 md5-sess ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x8924389 len=222 0000: 61 81 db 0a 01 0e 04 00 04 1c 53 41 53 4c 28 30 a.........SASL(0 0010: 29 3a 20 73 75 63 63 65 73 73 66 75 6c 20 72 65 ): successful re 0020: 73 75 6c 74 3a 20 87 81 b5 6e 6f 6e 63 65 3d 22 sult: ...nonce=" 0030: 49 6a 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 Ijq+Ki4kJzVIztl3 0040: 47 51 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 GQ6x7QynwsORjodG 0050: 7a 54 61 48 46 74 52 44 4c 43 41 3d 22 2c 72 65 zTaHFtRDLCA=",re 0060: 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c 71 alm="node.gac",q 0070: 6f 70 3d 22 61 75 74 68 2c 61 75 74 68 2d 69 6e op="auth,auth-in 0080: 74 2c 61 75 74 68 2d 63 6f 6e 66 22 2c 63 69 70 t,auth-conf",cip 0090: 68 65 72 3d 22 72 63 34 2d 34 30 2c 72 63 34 2d her="rc4-40,rc4- 00a0: 35 36 2c 72 63 34 2c 64 65 73 2c 33 64 65 73 22 56,rc4,des,3des" 00b0: 2c 6d 61 78 62 75 66 3d 36 35 35 33 36 2c 63 68 ,maxbuf=65536,ch 00c0: 61 72 73 65 74 3d 75 74 66 2d 38 2c 61 6c 67 6f arset=utf-8,algo 00d0: 72 69 74 68 6d 3d 6d 64 35 2d 73 65 73 73 rithm=md5-sess ber_scanf fmt (x) ber: ber_dump: buf=0x89242a8 ptr=0x89242d1 end=0x8924389 len=184 0000: 87 81 b5 6e 6f 6e 63 65 3d 22 49 6a 71 2b 4b 69 ...nonce="Ijq+Ki 0010: 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 36 78 37 51 4kJzVIztl3GQ6x7Q 0020: 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 61 48 46 74 ynwsORjodGzTaHFt 0030: 52 44 4c 43 41 3d 22 2c 72 65 61 6c 6d 3d 22 6e RDLCA=",realm="n 0040: 6f 64 65 2e 67 61 63 22 2c 71 6f 70 3d 22 61 75 ode.gac",qop="au 0050: 74 68 2c 61 75 74 68 2d 69 6e 74 2c 61 75 74 68 th,auth-int,auth 0060: 2d 63 6f 6e 66 22 2c 63 69 70 68 65 72 3d 22 72 -conf",cipher="r 0070: 63 34 2d 34 30 2c 72 63 34 2d 35 36 2c 72 63 34 c4-40,rc4-56,rc4 0080: 2c 64 65 73 2c 33 64 65 73 22 2c 6d 61 78 62 75 ,des,3des",maxbu 0090: 66 3d 36 35 35 33 36 2c 63 68 61 72 73 65 74 3d f=65536,charset= 00a0: 75 74 66 2d 38 2c 61 6c 67 6f 72 69 74 68 6d 3d utf-8,algorithm= 00b0: 6d 64 35 2d 73 65 73 73 md5-sess ber_scanf fmt (}) ber: ber_dump: buf=0x89242a8 ptr=0x8924389 end=0x8924389 len=0 ldap_msgfree sasl_client_step: 1 ldap_sasl_bind_s ldap_sasl_bind ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x89304a0 ptr=0x89304a0 end=0x89305df len=319 0000: 30 82 01 3b 02 01 02 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 49 6a e.gac",nonce="Ij 0060: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0070: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0080: 61 48 46 74 52 44 4c 43 41 3d 22 2c 63 6e 6f 6e aHFtRDLCA=",cnon 0090: 63 65 3d 22 50 50 39 72 32 38 6e 37 2b 55 6f 41 ce="PP9r28n7+UoA 00a0: 49 35 76 48 61 50 63 58 45 6a 6d 4b 68 73 34 37 I5vHaPcXEjmKhs47 00b0: 6d 79 2f 75 6d 57 70 65 61 52 4f 48 79 45 30 3d my/umWpeaROHyE0= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f ",nc=00000001,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 34 ocal",response=4 0120: 31 38 35 35 38 30 32 63 36 38 63 62 32 38 61 66 1855802c68cb28af 0130: 35 34 31 31 63 66 32 37 66 66 31 38 31 65 36 5411cf27ff181e6 ber_scanf fmt ({i) ber: ber_dump: buf=0x89304a0 ptr=0x89304a7 end=0x89305df len=312 0000: 60 82 01 34 02 01 03 04 12 63 6e 3d 64 61 74 61 `..4.....cn=data 0010: 64 6d 69 6e 2c 64 63 3d 67 61 63 a3 82 01 19 04 dmin,dc=gac..... 0020: 0a 44 49 47 45 53 54 2d 4d 44 35 04 82 01 09 75 .DIGEST-MD5....u 0030: 73 65 72 6e 61 6d 65 3d 22 72 6f 6f 74 22 2c 72 sername="root",r 0040: 65 61 6c 6d 3d 22 6e 6f 64 65 2e 67 61 63 22 2c ealm="node.gac", 0050: 6e 6f 6e 63 65 3d 22 49 6a 71 2b 4b 69 34 6b 4a nonce="Ijq+Ki4kJ 0060: 7a 56 49 7a 74 6c 33 47 51 36 78 37 51 79 6e 77 zVIztl3GQ6x7Qynw 0070: 73 4f 52 6a 6f 64 47 7a 54 61 48 46 74 52 44 4c sORjodGzTaHFtRDL 0080: 43 41 3d 22 2c 63 6e 6f 6e 63 65 3d 22 50 50 39 CA=",cnonce="PP9 0090: 72 32 38 6e 37 2b 55 6f 41 49 35 76 48 61 50 63 r28n7+UoAI5vHaPc 00a0: 58 45 6a 6d 4b 68 73 34 37 6d 79 2f 75 6d 57 70 XEjmKhs47my/umWp 00b0: 65 61 52 4f 48 79 45 30 3d 22 2c 6e 63 3d 30 30 eaROHyE0=",nc=00 00c0: 30 30 30 30 30 31 2c 71 6f 70 3d 61 75 74 68 2d 000001,qop=auth- 00d0: 63 6f 6e 66 2c 63 69 70 68 65 72 3d 72 63 34 2c conf,cipher=rc4, 00e0: 6d 61 78 62 75 66 3d 31 36 37 37 37 32 31 35 2c maxbuf=16777215, 00f0: 64 69 67 65 73 74 2d 75 72 69 3d 22 6c 64 61 70 digest-uri="ldap 0100: 2f 6e 6f 64 65 2d 32 2e 6c 6f 63 61 6c 22 2c 72 /node-2.local",r 0110: 65 73 70 6f 6e 73 65 3d 34 31 38 35 35 38 30 32 esponse=41855802 0120: 63 36 38 63 62 32 38 61 66 35 34 31 31 63 66 32 c68cb28af5411cf2 0130: 37 66 66 31 38 31 65 36 7ff181e6 ber_flush2: 319 bytes to sd 13 0000: 30 82 01 3b 02 01 02 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 49 6a e.gac",nonce="Ij 0060: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0070: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0080: 61 48 46 74 52 44 4c 43 41 3d 22 2c 63 6e 6f 6e aHFtRDLCA=",cnon 0090: 63 65 3d 22 50 50 39 72 32 38 6e 37 2b 55 6f 41 ce="PP9r28n7+UoA 00a0: 49 35 76 48 61 50 63 58 45 6a 6d 4b 68 73 34 37 I5vHaPcXEjmKhs47 00b0: 6d 79 2f 75 6d 57 70 65 61 52 4f 48 79 45 30 3d my/umWpeaROHyE0= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f ",nc=00000001,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 34 ocal",response=4 0120: 31 38 35 35 38 30 32 63 36 38 63 62 32 38 61 66 1855802c68cb28af 0130: 35 34 31 31 63 66 32 37 66 66 31 38 31 65 36 5411cf27ff181e6 ldap_write: want=319, written=319 0000: 30 82 01 3b 02 01 02 60 82 01 34 02 01 03 04 12 0..;...`..4..... 0010: 63 6e 3d 64 61 74 61 64 6d 69 6e 2c 64 63 3d 67 cn=datadmin,dc=g 0020: 61 63 a3 82 01 19 04 0a 44 49 47 45 53 54 2d 4d ac......DIGEST-M 0030: 44 35 04 82 01 09 75 73 65 72 6e 61 6d 65 3d 22 D5....username=" 0040: 72 6f 6f 74 22 2c 72 65 61 6c 6d 3d 22 6e 6f 64 root",realm="nod 0050: 65 2e 67 61 63 22 2c 6e 6f 6e 63 65 3d 22 49 6a e.gac",nonce="Ij 0060: 71 2b 4b 69 34 6b 4a 7a 56 49 7a 74 6c 33 47 51 q+Ki4kJzVIztl3GQ 0070: 36 78 37 51 79 6e 77 73 4f 52 6a 6f 64 47 7a 54 6x7QynwsORjodGzT 0080: 61 48 46 74 52 44 4c 43 41 3d 22 2c 63 6e 6f 6e aHFtRDLCA=",cnon 0090: 63 65 3d 22 50 50 39 72 32 38 6e 37 2b 55 6f 41 ce="PP9r28n7+UoA 00a0: 49 35 76 48 61 50 63 58 45 6a 6d 4b 68 73 34 37 I5vHaPcXEjmKhs47 00b0: 6d 79 2f 75 6d 57 70 65 61 52 4f 48 79 45 30 3d my/umWpeaROHyE0= 00c0: 22 2c 6e 63 3d 30 30 30 30 30 30 30 31 2c 71 6f ",nc=00000001,qo 00d0: 70 3d 61 75 74 68 2d 63 6f 6e 66 2c 63 69 70 68 p=auth-conf,ciph 00e0: 65 72 3d 72 63 34 2c 6d 61 78 62 75 66 3d 31 36 er=rc4,maxbuf=16 00f0: 37 37 37 32 31 35 2c 64 69 67 65 73 74 2d 75 72 777215,digest-ur 0100: 69 3d 22 6c 64 61 70 2f 6e 6f 64 65 2d 32 2e 6c i="ldap/node-2.l 0110: 6f 63 61 6c 22 2c 72 65 73 70 6f 6e 73 65 3d 34 ocal",response=4 0120: 31 38 35 35 38 30 32 63 36 38 63 62 32 38 61 66 1855802c68cb28af 0130: 35 34 31 31 63 66 32 37 66 66 31 38 31 65 36 5411cf27ff181e6 ldap_result ld 0x88f5380 msgid 2 wait4msg ld 0x88f5380 msgid 2 (infinite timeout) wait4msg continue ld 0x88f5380 msgid 2 all 1 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 2 all 1 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 2 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 36 02 01 02 61 31 0a 06...a1. ldap_read: want=48, got=48 0000: 01 00 04 00 04 00 87 28 72 73 70 61 75 74 68 3d .......(rspauth= 0010: 35 36 65 64 61 37 65 64 32 65 62 38 63 38 39 32 56eda7ed2eb8c892 0020: 66 30 34 62 32 30 34 65 65 34 64 30 35 35 34 37 f04b204ee4d05547 ber_get_next: tag 0x30 len 54 contents: ber_dump: buf=0x89242a8 ptr=0x89242a8 end=0x89242de len=54 0000: 02 01 02 61 31 0a 01 00 04 00 04 00 87 28 72 73 ...a1........(rs 0010: 70 61 75 74 68 3d 35 36 65 64 61 37 65 64 32 65 pauth=56eda7ed2e 0020: 62 38 63 38 39 32 66 30 34 62 32 30 34 65 65 34 b8c892f04b204ee4 0030: 64 30 35 35 34 37 d05547 read1msg: ld 0x88f5380 msgid 2 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x89242de len=51 0000: 61 31 0a 01 00 04 00 04 00 87 28 72 73 70 61 75 a1........(rspau 0010: 74 68 3d 35 36 65 64 61 37 65 64 32 65 62 38 63 th=56eda7ed2eb8c 0020: 38 39 32 66 30 34 62 32 30 34 65 65 34 64 30 35 892f04b204ee4d05 0030: 35 34 37 547 read1msg: ld 0x88f5380 0 new referrals read1msg: mark request completed, ld 0x88f5380 msgid 2 request done: ld 0x88f5380 msgid 2 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_sasl_bind_result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x89242de len=51 0000: 61 31 0a 01 00 04 00 04 00 87 28 72 73 70 61 75 a1........(rspau 0010: 74 68 3d 35 36 65 64 61 37 65 64 32 65 62 38 63 th=56eda7ed2eb8c 0020: 38 39 32 66 30 34 62 32 30 34 65 65 34 64 30 35 892f04b204ee4d05 0030: 35 34 37 547 ber_scanf fmt (O) ber: ber_dump: buf=0x89242a8 ptr=0x89242b4 end=0x89242de len=42 0000: 87 28 72 73 70 61 75 74 68 3d 35 36 65 64 61 37 .(rspauth=56eda7 0010: 65 64 32 65 62 38 63 38 39 32 66 30 34 62 32 30 ed2eb8c892f04b20 0020: 34 65 65 34 64 30 35 35 34 37 4ee4d05547 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x89242a8 ptr=0x89242ab end=0x89242de len=51 0000: 61 31 0a 01 00 04 00 04 00 87 28 72 73 70 61 75 a1........(rspau 0010: 74 68 3d 35 36 65 64 61 37 65 64 32 65 62 38 63 th=56eda7ed2eb8c 0020: 38 39 32 66 30 34 62 32 30 34 65 65 34 64 30 35 892f04b204ee4d05 0030: 35 34 37 547 ber_scanf fmt (x) ber: ber_dump: buf=0x89242a8 ptr=0x89242b4 end=0x89242de len=42 0000: 87 28 72 73 70 61 75 74 68 3d 35 36 65 64 61 37 .(rspauth=56eda7 0010: 65 64 32 65 62 38 63 38 39 32 66 30 34 62 32 30 ed2eb8c892f04b20 0020: 34 65 65 34 64 30 35 35 34 37 4ee4d05547 ber_scanf fmt (}) ber: ber_dump: buf=0x89242a8 ptr=0x89242de end=0x89242de len=0 ldap_msgfree sasl_client_step: 0 ldap_pvt_sasl_install conn=3 op=2 <<< meta_search_dobind_init[0]=1 [rw] searchBase: "dc=gac" -> "dc=gac" [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" ldap_search_ext put_filter: "(objectClass=*)" put_filter: simple put_simple_filter: "objectClass=*" ldap_build_search_req ATTRS: * ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x89314e8 ptr=0x89314e8 end=0x8931517 len=47 0000: 30 2d 02 01 03 63 28 04 06 64 63 3d 67 61 63 0a 0-...c(..dc=gac. 0010: 01 02 0a 01 00 02 02 01 f4 02 02 0e 10 01 01 00 ................ 0020: 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 00 ..objectClass0. ber_scanf fmt ({) ber: ber_dump: buf=0x89314e8 ptr=0x89314ed end=0x8931517 len=42 0000: 63 28 04 06 64 63 3d 67 61 63 0a 01 02 0a 01 00 c(..dc=gac...... 0010: 02 02 01 f4 02 02 0e 10 01 01 00 87 0b 6f 62 6a .............obj 0020: 65 63 74 43 6c 61 73 73 30 00 ectClass0. ber_flush2: 47 bytes to sd 13 0000: 30 2d 02 01 03 63 28 04 06 64 63 3d 67 61 63 0a 0-...c(..dc=gac. 0010: 01 02 0a 01 00 02 02 01 f4 02 02 0e 10 01 01 00 ................ 0020: 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 00 ..objectClass0. sasl_write: want=67, written=67 0000: 00 00 00 3f 30 03 26 1a c6 d2 e0 d3 73 5a 16 f7 ...?0.&.....sZ.. 0010: 14 f8 04 b2 0a e8 79 e3 0c ea ec 99 c6 24 ff 09 ......y......$.. 0020: f5 56 8e 48 69 83 39 95 bf ed 32 b7 0d 1e 8c fe .V.Hi.9...2..... 0030: 43 f2 f3 cb 20 cb e7 88 87 0a ce 3e ea 00 01 00 C... ......>.... 0040: 00 00 00 ... ldap_write: want=47, written=47 0000: 30 2d 02 01 03 63 28 04 06 64 63 3d 67 61 63 0a 0-...c(..dc=gac. 0010: 01 02 0a 01 00 02 02 01 f4 02 02 0e 10 01 01 00 ................ 0020: 87 0b 6f 62 6a 65 63 74 43 6c 61 73 73 30 00 ..objectClass0. conn=3 op=2 <<< meta_back_search_start[0]=1 conn=3 op=2 meta_back_search: ncandidates=1 cnd="*" ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 37 ...7 sasl_read: want=55, got=55 0000: 13 01 fe 47 77 d4 71 21 9b 42 1d 85 74 36 e7 ce ...Gw.q!.B..t6.. 0010: b3 66 a5 15 94 42 5e 09 19 23 d2 a4 c3 43 e8 4f .f...B^..#...C.O 0020: bd f5 12 ac c9 8d 4d 5c fc 3e 52 cc c6 45 60 8a ......M\.>R..E`. 0030: 1d 00 01 00 00 00 00 ....... ldap_read: want=8, got=8 0000: 30 25 02 01 03 64 20 04 0%...d . ldap_read: want=31, got=31 0000: 06 64 63 3d 67 61 63 30 16 30 14 04 0b 6f 62 6a .dc=gac0.0...obj 0010: 65 63 74 43 6c 61 73 73 31 05 04 03 74 6f 70 ectClass1...top ber_get_next: tag 0x30 len 37 contents: ber_dump: buf=0x89246f0 ptr=0x89246f0 end=0x8924715 len=37 0000: 02 01 03 64 20 04 06 64 63 3d 67 61 63 30 16 30 ...d ..dc=gac0.0 0010: 14 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 05 ...objectClass1. 0020: 04 03 74 6f 70 ..top read1msg: ld 0x88f5380 msgid 3 message type search-entry wait4msg ld 0x88f5380 0 s 97635 us to go wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x89246f0 ptr=0x89246f3 end=0x8924715 len=34 0000: 64 20 04 06 64 63 3d 67 61 63 30 16 30 14 04 0b d ..dc=gac0.0... 0010: 6f 62 6a 65 63 74 43 6c 61 73 73 31 05 04 03 74 objectClass1...t 0020: 6f 70 op [rw] searchResult: "dc=gac" -> "dc=gac" >>> dnPrettyNormal: <dc=gac> => ldap_bv2dn(dc=gac,0) <= ldap_bv2dn(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=gac)=0 <<< dnPrettyNormal: <dc=gac>, <dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x89246f0 ptr=0x89246ff end=0x8924715 len=22 0000: 30 14 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 05 04 03 74 6f 70 ...top ber_scanf fmt ([W]) ber: ber_dump: buf=0x89246f0 ptr=0x892470e end=0x8924715 len=7 0000: 00 05 04 03 74 6f 70 ....top ber_scanf fmt ({m) ber: ber_dump: buf=0x89246f0 ptr=0x8924715 end=0x8924715 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x89246f0 ptr=0x89246f3 end=0x8924715 len=34 0000: 64 20 04 06 64 63 3d 67 61 63 00 16 30 14 04 0b d ..dc=gac..0... 0010: 6f 62 6a 65 63 74 43 6c 61 73 73 00 05 04 03 74 objectClass....t 0020: 6f 70 op => send_search_entry: conn 3 dn="dc=gac" => access_allowed: read access to "dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [6] cn=contacts,cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dn: [7] dc=gac => acl_get: [7] matched => acl_get: [7] attr entry => acl_mask: access to entry "dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying search(=scxd) (stop) <= acl_mask: [1] mask: search(=scxd) => slap_access_allowed: read access denied by search(=scxd) => access_allowed: no more rules send_search_entry: conn 3 access to entry (dc=gac) not allowed ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 6a ...j sasl_read: want=106, got=106 0000: 52 3b c0 02 7c b2 5c d6 b8 c1 1a 03 48 02 c5 29 R;..|.\.....H..) 0010: 6c 8c 11 4d 62 3c 58 0d 55 6c 8d 93 43 4f 52 1c l..Mb<X.Ul..COR. 0020: 57 f2 80 ae 0b 13 6c 9b 20 7f c6 68 59 ab 3d e4 W.....l. ..hY.=. 0030: f0 f9 5e 0d 46 45 56 14 a1 f3 47 6e 0a 69 81 7f ..^.FEV...Gn.i.. 0040: 48 97 8a 50 84 c0 cb 7c e2 71 23 36 0b 27 8a 81 H..P...|.q#6.'.. 0050: 57 be 29 39 a1 3d 95 f1 15 8c 21 c2 f9 85 59 76 W.)9.=....!...Yv 0060: 2e da 89 1a 00 01 00 00 00 01 .......... ldap_read: want=8, got=8 0000: 30 58 02 01 03 64 53 04 0X...dS. ldap_read: want=82, got=82 0000: 0b 6f 3d 64 65 2c 64 63 3d 67 61 63 30 44 30 1d .o=de,dc=gac0D0. 0010: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0e 04 ..objectClass1.. 0020: 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 30 09 04 .organization0.. 0030: 01 6f 31 04 04 02 64 65 30 18 04 0b 64 65 73 63 .o1...de0...desc 0040: 72 69 70 74 69 6f 6e 31 09 04 07 64 65 2e 67 61 ription1...de.ga 0050: 63 2e c. ber_get_next: tag 0x30 len 88 contents: ber_dump: buf=0x89209d0 ptr=0x89209d0 end=0x8920a28 len=88 0000: 02 01 03 64 53 04 0b 6f 3d 64 65 2c 64 63 3d 67 ...dS..o=de,dc=g 0010: 61 63 30 44 30 1d 04 0b 6f 62 6a 65 63 74 43 6c ac0D0...objectCl 0020: 61 73 73 31 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 ass1...organizat 0030: 69 6f 6e 30 09 04 01 6f 31 04 04 02 64 65 30 18 ion0...o1...de0. 0040: 04 0b 64 65 73 63 72 69 70 74 69 6f 6e 31 09 04 ..description1.. 0050: 07 64 65 2e 67 61 63 2e .de.gac. read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x89209d0 ptr=0x89209d3 end=0x8920a28 len=85 0000: 64 53 04 0b 6f 3d 64 65 2c 64 63 3d 67 61 63 30 dS..o=de,dc=gac0 0010: 44 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 D0...objectClass 0020: 31 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 1...organization 0030: 30 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 0...o1...de0...d 0040: 65 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 escription1...de 0050: 2e 67 61 63 2e .gac. [rw] searchResult: "o=de,dc=gac" -> "o=de,dc=gac" >>> dnPrettyNormal: <o=de,dc=gac> => ldap_bv2dn(o=de,dc=gac,0) <= ldap_bv2dn(o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(o=de,dc=gac)=0 <<< dnPrettyNormal: <o=de,dc=gac>, <o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x89209e4 end=0x8920a28 len=68 0000: 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 30 ...organization0 0020: 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 65 ...o1...de0...de 0030: 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 2e scription1...de. 0040: 67 61 63 2e gac. ber_scanf fmt ([W]) ber: ber_dump: buf=0x89209d0 ptr=0x89209f3 end=0x8920a28 len=53 0000: 00 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e ....organization 0010: 30 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 0...o1...de0...d 0020: 65 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 escription1...de 0030: 2e 67 61 63 2e .gac. ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x8920a03 end=0x8920a28 len=37 0000: 30 09 04 01 6f 31 04 04 02 64 65 30 18 04 0b 64 0...o1...de0...d 0010: 65 73 63 72 69 70 74 69 6f 6e 31 09 04 07 64 65 escription1...de 0020: 2e 67 61 63 2e .gac. ber_scanf fmt ([W]) ber: ber_dump: buf=0x89209d0 ptr=0x8920a08 end=0x8920a28 len=32 0000: 00 04 04 02 64 65 30 18 04 0b 64 65 73 63 72 69 ....de0...descri 0010: 70 74 69 6f 6e 31 09 04 07 64 65 2e 67 61 63 2e ption1...de.gac. ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x8920a0e end=0x8920a28 len=26 0000: 30 18 04 0b 64 65 73 63 72 69 70 74 69 6f 6e 31 0...description1 0010: 09 04 07 64 65 2e 67 61 63 2e ...de.gac. ber_scanf fmt ([W]) ber: ber_dump: buf=0x89209d0 ptr=0x8920a1d end=0x8920a28 len=11 0000: 00 09 04 07 64 65 2e 67 61 63 2e ....de.gac. ber_scanf fmt ({m) ber: ber_dump: buf=0x89209d0 ptr=0x8920a28 end=0x8920a28 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x89209d0 ptr=0x89209d3 end=0x8920a28 len=85 0000: 64 53 04 0b 6f 3d 64 65 2c 64 63 3d 67 61 63 00 dS..o=de,dc=gac. 0010: 44 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 D0...objectClass 0020: 00 0e 04 0c 6f 72 67 61 6e 69 7a 61 74 69 6f 6e ....organization 0030: 30 09 04 01 6f 00 04 04 02 64 65 30 18 04 0b 64 0...o....de0...d 0040: 65 73 63 72 69 70 74 69 6f 6e 00 09 04 07 64 65 escription....de 0050: 2e 67 61 63 2e .gac. => send_search_entry: conn 3 dn="o=de,dc=gac" => access_allowed: read access to "o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dnpat: [6] cn=contacts,cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => dn: [7] dc=gac => acl_get: [7] matched => acl_get: [7] attr entry => acl_mask: access to entry "o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying search(=scxd) (stop) <= acl_mask: [1] mask: search(=scxd) => slap_access_allowed: read access denied by search(=scxd) => access_allowed: no more rules send_search_entry: conn 3 access to entry (o=de,dc=gac) not allowed ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 99 .... sasl_read: want=153, got=153 0000: b1 6f c7 5b a9 ac c5 68 79 16 5a f6 1f dd 67 98 .o.[...hy.Z...g. 0010: da d3 ce ae b5 2f 65 1d df 64 48 63 f7 e6 34 72 ...../e..dHc..4r 0020: 99 f1 a8 48 e3 60 b5 e7 2b 95 e0 5e 26 f3 ac cc ...H.`..+..^&... 0030: f6 f5 e8 af 29 68 f5 42 6b 14 69 25 46 28 92 0f ....)h.Bk.i%F(.. 0040: 71 b4 5b 67 f8 2d ae 29 a3 07 05 a4 19 2e 25 f5 q.[g.-.)......%. 0050: ff 99 9d 27 f7 37 b0 88 2b fd 81 a3 d8 ef 3d d8 ...'.7..+.....=. 0060: 69 36 0b 0e 92 a0 5b ba 67 ee 3d 07 72 77 9e 28 i6....[.g.=.rw.( 0070: 80 56 1f e2 fc b1 11 70 8f 74 d8 b6 ad 2c 92 d0 .V.....p.t...,.. 0080: 9a 75 96 aa e9 50 57 82 6c 56 aa 89 db 86 fd 95 .u...PW.lV...... 0090: b9 9e cd 00 01 00 00 00 02 ......... ldap_read: want=8, got=8 0000: 30 81 86 02 01 03 64 81 0.....d. ldap_read: want=129, got=129 0000: 80 04 13 63 6e 3d 55 73 65 72 2c 6f 3d 64 65 2c ...cn=User,o=de, 0010: 64 63 3d 67 61 63 30 69 30 1e 04 0b 6f 62 6a 65 dc=gac0i0...obje 0020: 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 74 4f ctClass1...inetO 0030: 72 67 50 65 72 73 6f 6e 30 0c 04 02 63 6e 31 06 rgPerson0...cn1. 0040: 04 04 55 73 65 72 30 0c 04 02 73 6e 31 06 04 04 ..User0...sn1... 0050: 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e 61 6d User0...givenNam 0060: 65 31 06 04 04 55 73 65 72 30 16 04 0c 75 73 65 e1...User0...use 0070: 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 rPassword1...pas 0080: 73 s ber_get_next: tag 0x30 len 134 contents: ber_dump: buf=0x8920ac0 ptr=0x8920ac0 end=0x8920b46 len=134 0000: 02 01 03 64 81 80 04 13 63 6e 3d 55 73 65 72 2c ...d....cn=User, 0010: 6f 3d 64 65 2c 64 63 3d 67 61 63 30 69 30 1e 04 o=de,dc=gac0i0.. 0020: 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d .objectClass1... 0030: 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0c 04 inetOrgPerson0.. 0040: 02 63 6e 31 06 04 04 55 73 65 72 30 0c 04 02 73 .cn1...User0...s 0050: 6e 31 06 04 04 55 73 65 72 30 13 04 09 67 69 76 n1...User0...giv 0060: 65 6e 4e 61 6d 65 31 06 04 04 55 73 65 72 30 16 enName1...User0. 0070: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 ..userPassword1. 0080: 04 04 70 61 73 73 ..pass read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b46 len=131 0000: 64 81 80 04 13 63 6e 3d 55 73 65 72 2c 6f 3d 64 d....cn=User,o=d 0010: 65 2c 64 63 3d 67 61 63 30 69 30 1e 04 0b 6f 62 e,dc=gac0i0...ob 0020: 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 jectClass1...ine 0030: 74 4f 72 67 50 65 72 73 6f 6e 30 0c 04 02 63 6e tOrgPerson0...cn 0040: 31 06 04 04 55 73 65 72 30 0c 04 02 73 6e 31 06 1...User0...sn1. 0050: 04 04 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e ..User0...givenN 0060: 61 6d 65 31 06 04 04 55 73 65 72 30 16 04 0c 75 ame1...User0...u 0070: 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 serPassword1...p 0080: 61 73 73 ass [rw] searchResult: "cn=User,o=de,dc=gac" -> "cn=User,o=de,dc=gac" >>> dnPrettyNormal: <cn=User,o=de,dc=gac> => ldap_bv2dn(cn=User,o=de,dc=gac,0) <= ldap_bv2dn(cn=User,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=User,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=User,o=de,dc=gac>, <cn=user,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920add end=0x8920b46 len=105 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 0c 04 02 63 6e 31 06 04 04 55 73 65 72 30 0c 0...cn1...User0. 0030: 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 04 09 ..sn1...User0... 0040: 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 73 65 givenName1...Use 0050: 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 r0...userPasswor 0060: 64 31 06 04 04 70 61 73 73 d1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920aec end=0x8920b46 len=90 0000: 00 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f ....inetOrgPerso 0010: 6e 30 0c 04 02 63 6e 31 06 04 04 55 73 65 72 30 n0...cn1...User0 0020: 0c 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 04 ...sn1...User0.. 0030: 09 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 73 .givenName1...Us 0040: 65 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f er0...userPasswo 0050: 72 64 31 06 04 04 70 61 73 73 rd1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920afd end=0x8920b46 len=73 0000: 30 0c 04 02 63 6e 31 06 04 04 55 73 65 72 30 0c 0...cn1...User0. 0010: 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 04 09 ..sn1...User0... 0020: 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 73 65 givenName1...Use 0030: 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 r0...userPasswor 0040: 64 31 06 04 04 70 61 73 73 d1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b03 end=0x8920b46 len=67 0000: 00 06 04 04 55 73 65 72 30 0c 04 02 73 6e 31 06 ....User0...sn1. 0010: 04 04 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e ..User0...givenN 0020: 61 6d 65 31 06 04 04 55 73 65 72 30 16 04 0c 75 ame1...User0...u 0030: 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 serPassword1...p 0040: 61 73 73 ass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b0b end=0x8920b46 len=59 0000: 30 0c 04 02 73 6e 31 06 04 04 55 73 65 72 30 13 0...sn1...User0. 0010: 04 09 67 69 76 65 6e 4e 61 6d 65 31 06 04 04 55 ..givenName1...U 0020: 73 65 72 30 16 04 0c 75 73 65 72 50 61 73 73 77 ser0...userPassw 0030: 6f 72 64 31 06 04 04 70 61 73 73 ord1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b11 end=0x8920b46 len=53 0000: 00 06 04 04 55 73 65 72 30 13 04 09 67 69 76 65 ....User0...give 0010: 6e 4e 61 6d 65 31 06 04 04 55 73 65 72 30 16 04 nName1...User0.. 0020: 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 .userPassword1.. 0030: 04 70 61 73 73 .pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b19 end=0x8920b46 len=45 0000: 30 13 04 09 67 69 76 65 6e 4e 61 6d 65 31 06 04 0...givenName1.. 0010: 04 55 73 65 72 30 16 04 0c 75 73 65 72 50 61 73 .User0...userPas 0020: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b26 end=0x8920b46 len=32 0000: 00 06 04 04 55 73 65 72 30 16 04 0c 75 73 65 72 ....User0...user 0010: 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 73 Password1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b2e end=0x8920b46 len=24 0000: 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 0...userPassword 0010: 31 06 04 04 70 61 73 73 1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b3e end=0x8920b46 len=8 0000: 00 06 04 04 70 61 73 73 ....pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b46 end=0x8920b46 len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b46 len=131 0000: 64 81 80 04 13 63 6e 3d 55 73 65 72 2c 6f 3d 64 d....cn=User,o=d 0010: 65 2c 64 63 3d 67 61 63 00 69 30 1e 04 0b 6f 62 e,dc=gac.i0...ob 0020: 6a 65 63 74 43 6c 61 73 73 00 0f 04 0d 69 6e 65 jectClass....ine 0030: 74 4f 72 67 50 65 72 73 6f 6e 30 0c 04 02 63 6e tOrgPerson0...cn 0040: 00 06 04 04 55 73 65 72 30 0c 04 02 73 6e 00 06 ....User0...sn.. 0050: 04 04 55 73 65 72 30 13 04 09 67 69 76 65 6e 4e ..User0...givenN 0060: 61 6d 65 00 06 04 04 55 73 65 72 30 16 04 0c 75 ame....User0...u 0070: 73 65 72 50 61 73 73 77 6f 72 64 00 06 04 04 70 serPassword....p 0080: 61 73 73 ass => send_search_entry: conn 3 dn="cn=User,o=de,dc=gac" => access_allowed: read access to "cn=User,o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr entry => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User,o=de,dc=gac" "objectClass" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr objectClass => slap_access_allowed: result not in cache (objectClass) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "objectClass" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User,o=de,dc=gac" "cn" requested => dn: [1] => acl_get: [3] attr cn => slap_access_allowed: result not in cache (cn) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "cn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User,o=de,dc=gac" "sn" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr sn => slap_access_allowed: result not in cache (sn) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "sn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= check a_set_pat: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: pattern: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: expanded: [cn=contacts,cn=user,o=de,dc=gac]/member >>> dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> => ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac,0) <= ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 <<< dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> <= check a_dn_pat: * <= acl_mask: [3] applying auth(=xd) (stop) <= acl_mask: [3] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute sn, value #0 not allowed => access_allowed: read access to "cn=User,o=de,dc=gac" "givenName" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr givenName => slap_access_allowed: result not in cache (givenName) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "givenName" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= check a_set_pat: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: pattern: [cn=contacts,cn=$1,o=$2,dc=gac]/member => acl_string_expand: expanded: [cn=contacts,cn=user,o=de,dc=gac]/member >>> dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> => ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac,0) <= ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 <<< dnNormalize: <cn=contacts,cn=user,o=de,dc=gac> <= check a_dn_pat: * <= acl_mask: [3] applying auth(=xd) (stop) <= acl_mask: [3] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute givenName, value #0 not allowed => access_allowed: read access to "cn=User,o=de,dc=gac" "userPassword" requested => dn: [1] => acl_get: [2] attr userPassword => slap_access_allowed: result not in cache (userPassword) => acl_mask: access to entry "cn=User,o=de,dc=gac", attr "userPassword" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: cn=datadmin,dc=gac <= check a_dn_pat: * <= acl_mask: [2] applying auth(=xd) (stop) <= acl_mask: [2] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute userPassword, value #0 not allowed ber_flush2: 76 bytes to sd 11 0000: 30 4a 02 01 03 64 45 04 13 63 6e 3d 55 73 65 72 0J...dE..cn=User 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 2e 30 1e ,o=de,dc=gac0.0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0c .inetOrgPerson0. 0040: 04 02 63 6e 31 06 04 04 55 73 65 72 ..cn1...User sasl_write: want=96, written=96 0000: 00 00 00 5c 83 c6 63 35 c7 67 8b fa d8 28 bd db ...\..c5.g...(.. 0010: 48 09 37 6e ca 1c 8e b7 c6 09 d3 e9 21 3c 86 a2 H.7n........!<.. 0020: 2f bd 2d 46 68 ae b7 54 5d 29 47 56 09 b0 47 43 /.-Fh..T])GV..GC 0030: 6c f5 e3 f3 6e 4c 2f 54 9f 5a 7d ac 0d 54 6d 1d l...nL/T.Z}..Tm. 0040: bb e1 46 c4 26 1f 30 7e 8c 45 16 e0 66 91 3d 9c ..F.&.0~.E..f.=. 0050: 44 c3 e3 1e a5 bf 62 93 ee 46 00 01 00 00 00 00 D.....b..F...... ldap_write: want=76, written=76 0000: 30 4a 02 01 03 64 45 04 13 63 6e 3d 55 73 65 72 0J...dE..cn=User 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 2e 30 1e ,o=de,dc=gac0.0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0c .inetOrgPerson0. 0040: 04 02 63 6e 31 06 04 04 55 73 65 72 ..cn1...User conn=3 op=2 ENTRY dn="cn=user,o=de,dc=gac" <= send_search_entry: conn 3 exit. ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 9d .... sasl_read: want=157, got=157 0000: a4 f4 34 99 30 66 35 e2 21 a3 ee 0d e3 2e 5c fd ..4.0f5.!.....\. 0010: 63 81 96 e0 1e 06 e3 11 8c 51 3c 76 6a 3d 32 bd c........Q<vj=2. 0020: 84 4d 6a fe 8c 53 fd 9c c9 b5 29 51 ea 7c c7 24 .Mj..S....)Q.|.$ 0030: 4d ca fe 7d 91 47 5e 95 6b 39 d5 c3 2b 47 ab 5b M..}.G^.k9..+G.[ 0040: f6 c7 b4 af 75 ca 6c 6a fb fc 84 78 c2 d4 25 4b ....u.lj...x..%K 0050: 32 ea ea 5c 2f 79 61 5d 72 69 2a 3f 72 1f f6 07 2..\/ya]ri*?r... 0060: 80 22 8b b9 4f c6 94 58 b2 a1 cd 2c c7 cc bc 30 ."..O..X...,...0 0070: 86 73 90 62 35 93 c2 b4 60 b2 cf 2a 7d 8f db e6 .s.b5...`..*}... 0080: 01 f9 88 e7 a5 81 a3 d0 6d 93 24 08 a2 27 68 f1 ........m.$..'h. 0090: b6 f8 d4 84 73 92 17 00 01 00 00 00 03 ....s........ ldap_read: want=8, got=8 0000: 30 81 8a 02 01 03 64 81 0.....d. ldap_read: want=133, got=133 0000: 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d 64 65 ...cn=User2,o=de 0010: 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f 62 6a ,dc=gac0l0...obj 0020: 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e 65 74 ectClass1...inet 0030: 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 6e 31 OrgPerson0...cn1 0040: 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 07 ...User20...sn1. 0050: 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 6e ..User20...given 0060: 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 04 Name1...User20.. 0070: 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 04 .userPassword1.. 0080: 04 70 61 73 73 .pass ber_get_next: tag 0x30 len 138 contents: ber_dump: buf=0x8920ac0 ptr=0x8920ac0 end=0x8920b4a len=138 0000: 02 01 03 64 81 84 04 14 63 6e 3d 55 73 65 72 32 ...d....cn=User2 0010: 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e ,o=de,dc=gac0l0. 0020: 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 ..objectClass1.. 0030: 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d .inetOrgPerson0. 0040: 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d 04 ..cn1...User20.. 0050: 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 09 .sn1...User20... 0060: 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 givenName1...Use 0070: 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f r20...userPasswo 0080: 72 64 31 06 04 04 70 61 73 73 rd1...pass read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b4a len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 30 6c 30 1e 04 0b 6f de,dc=gac0l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 31 0f 04 0d 69 6e bjectClass1...in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 31 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n1...User20...sn 0050: 31 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 1...User20...giv 0060: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0080: 06 04 04 70 61 73 73 ...pass [rw] searchResult: "cn=User2,o=de,dc=gac" -> "cn=User2,o=de,dc=gac" >>> dnPrettyNormal: <cn=User2,o=de,dc=gac> => ldap_bv2dn(cn=User2,o=de,dc=gac,0) <= ldap_bv2dn(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=User2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=User2,o=de,dc=gac>, <cn=user2,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ade end=0x8920b4a len=108 0000: 30 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e ...inetOrgPerson 0020: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0030: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0040: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0050: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0060: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920aed end=0x8920b4a len=93 0000: 00 0f 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f ....inetOrgPerso 0010: 6e 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 n0...cn1...User2 0020: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0030: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0040: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0050: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920afe end=0x8920b4a len=76 0000: 30 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0...cn1...User20 0010: 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 ...sn1...User20. 0020: 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 ..givenName1...U 0030: 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 73 ser20...userPass 0040: 77 6f 72 64 31 06 04 04 70 61 73 73 word1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b04 end=0x8920b4a len=70 0000: 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e 31 ....User20...sn1 0010: 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 65 ...User20...give 0020: 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 16 nName1...User20. 0030: 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 06 ..userPassword1. 0040: 04 04 70 61 73 73 ..pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b0d end=0x8920b4a len=61 0000: 30 0d 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 0...sn1...User20 0010: 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 ...givenName1... 0020: 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 73 User20...userPas 0030: 73 77 6f 72 64 31 06 04 04 70 61 73 73 sword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b13 end=0x8920b4a len=55 0000: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0010: 65 6e 4e 61 6d 65 31 07 04 05 55 73 65 72 32 30 enName1...User20 0020: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 31 ...userPassword1 0030: 06 04 04 70 61 73 73 ...pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b1c end=0x8920b4a len=46 0000: 30 14 04 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 0...givenName1.. 0010: 05 55 73 65 72 32 30 16 04 0c 75 73 65 72 50 61 .User20...userPa 0020: 73 73 77 6f 72 64 31 06 04 04 70 61 73 73 ssword1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b29 end=0x8920b4a len=33 0000: 00 07 04 05 55 73 65 72 32 30 16 04 0c 75 73 65 ....User20...use 0010: 72 50 61 73 73 77 6f 72 64 31 06 04 04 70 61 73 rPassword1...pas 0020: 73 s ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b32 end=0x8920b4a len=24 0000: 30 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 0...userPassword 0010: 31 06 04 04 70 61 73 73 1...pass ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b42 end=0x8920b4a len=8 0000: 00 06 04 04 70 61 73 73 ....pass ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b4a end=0x8920b4a len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b4a len=135 0000: 64 81 84 04 14 63 6e 3d 55 73 65 72 32 2c 6f 3d d....cn=User2,o= 0010: 64 65 2c 64 63 3d 67 61 63 00 6c 30 1e 04 0b 6f de,dc=gac.l0...o 0020: 62 6a 65 63 74 43 6c 61 73 73 00 0f 04 0d 69 6e bjectClass....in 0030: 65 74 4f 72 67 50 65 72 73 6f 6e 30 0d 04 02 63 etOrgPerson0...c 0040: 6e 00 07 04 05 55 73 65 72 32 30 0d 04 02 73 6e n....User20...sn 0050: 00 07 04 05 55 73 65 72 32 30 14 04 09 67 69 76 ....User20...giv 0060: 65 6e 4e 61 6d 65 00 07 04 05 55 73 65 72 32 30 enName....User20 0070: 16 04 0c 75 73 65 72 50 61 73 73 77 6f 72 64 00 ...userPassword. 0080: 06 04 04 70 61 73 73 ...pass => send_search_entry: conn 3 dn="cn=User2,o=de,dc=gac" => access_allowed: read access to "cn=User2,o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr entry => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "objectClass" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr objectClass => slap_access_allowed: result not in cache (objectClass) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "objectClass" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "cn" requested => dn: [1] => acl_get: [3] attr cn => slap_access_allowed: result not in cache (cn) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "cn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "sn" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr sn => slap_access_allowed: result not in cache (sn) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "sn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "givenName" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => acl_get: [4] attr givenName => slap_access_allowed: result not in cache (givenName) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "givenName" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: self <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=User2,o=de,dc=gac" "userPassword" requested => dn: [1] => acl_get: [2] attr userPassword => slap_access_allowed: result not in cache (userPassword) => acl_mask: access to entry "cn=User2,o=de,dc=gac", attr "userPassword" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: cn=datadmin,dc=gac <= check a_dn_pat: * <= acl_mask: [2] applying auth(=xd) (stop) <= acl_mask: [2] mask: auth(=xd) => slap_access_allowed: read access denied by auth(=xd) => access_allowed: no more rules send_search_entry: conn 3 access to attribute userPassword, value #0 not allowed ber_flush2: 115 bytes to sd 11 0000: 30 71 02 01 03 64 6c 04 14 63 6e 3d 55 73 65 72 0q...dl..cn=User 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 54 30 2,o=de,dc=gac0T0 0020: 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f ...objectClass1. 0030: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 ..inetOrgPerson0 0040: 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d ...cn1...User20. 0050: 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 ..sn1...User20.. 0060: 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 .givenName1...Us 0070: 65 72 32 er2 sasl_write: want=135, written=135 0000: 00 00 00 83 4a 39 19 4f 93 38 d0 77 d0 bb 08 7f ....J9.O.8.w.... 0010: 49 18 1c 59 d7 a5 a3 ca b2 dd 90 83 5f fe 1d 0f I..Y........_... 0020: bc 35 66 33 a0 7b d3 01 02 70 3a 19 8e af 7c 7d .5f3.{...p:...|} 0030: 8b 79 7e 27 8e 4d f5 61 65 36 6a df ee 0a 8e 62 .y~'.M.ae6j....b 0040: 18 6e e7 75 1d 22 b7 98 3d 63 0a 29 e5 63 6f e5 .n.u."..=c.).co. 0050: 77 97 ef 02 65 d2 3e 7d da 21 24 d8 42 d5 86 39 w...e.>}.!$.B..9 0060: dc f6 79 f3 b5 bd 42 c3 90 f1 8d c8 da bc 68 99 ..y...B.......h. 0070: b0 88 7c 1f cf b6 93 18 8d f4 af 65 e5 57 98 8b ..|........e.W.. 0080: 13 00 01 00 00 00 01 ....... ldap_write: want=115, written=115 0000: 30 71 02 01 03 64 6c 04 14 63 6e 3d 55 73 65 72 0q...dl..cn=User 0010: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 30 54 30 2,o=de,dc=gac0T0 0020: 1e 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0f ...objectClass1. 0030: 04 0d 69 6e 65 74 4f 72 67 50 65 72 73 6f 6e 30 ..inetOrgPerson0 0040: 0d 04 02 63 6e 31 07 04 05 55 73 65 72 32 30 0d ...cn1...User20. 0050: 04 02 73 6e 31 07 04 05 55 73 65 72 32 30 14 04 ..sn1...User20.. 0060: 09 67 69 76 65 6e 4e 61 6d 65 31 07 04 05 55 73 .givenName1...Us 0070: 65 72 32 er2 conn=3 op=2 ENTRY dn="cn=user2,o=de,dc=gac" <= send_search_entry: conn 3 exit. ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 8d .... sasl_read: want=141, got=141 0000: f4 db 84 c1 97 c3 cb 7b cd b0 23 ed 24 6b 4e 4d .......{..#.$kNM 0010: 61 83 7b 94 17 4e f6 e3 df 53 aa bb e6 f4 b2 b1 a.{..N...S...... 0020: 0d d6 7e 75 33 9a ed 9d 87 af c4 f8 66 66 de 7e ..~u3.......ff.~ 0030: c8 e8 58 c7 9e c2 eb 0c 74 53 eb b2 56 8c 20 90 ..X.....tS..V. . 0040: dd 3d cb 16 f8 bd db a0 6d 3a 3e cf f5 f2 05 4d .=......m:>....M 0050: 61 cc 11 9f 3c 83 57 cd 08 95 2c 1e 0d 8e 05 74 a...<.W...,....t 0060: 02 90 00 e8 ec db 36 ac 17 01 dd 2a 78 c4 72 57 ......6....*x.rW 0070: 7b 30 4b a5 90 93 e3 c8 74 20 4f 2a 4a 86 24 89 {0K.....t O*J.$. 0080: 45 a9 0b 19 28 52 96 00 01 00 00 00 04 E...(R....... ldap_read: want=8, got=8 0000: 30 7b 02 01 03 64 76 04 0{...dv. ldap_read: want=117, got=117 0000: 1f 63 6e 3d 63 6f 6e 74 61 63 74 73 2c 63 6e 3d .cn=contacts,cn= 0010: 75 73 65 72 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 user,o=de,dc=gac 0020: 30 53 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 0S0...objectClas 0030: 73 31 0e 04 0c 67 72 6f 75 70 4f 66 4e 61 6d 65 s1...groupOfName 0040: 73 30 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 s0...cn1...conta 0050: 63 74 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 cts0 ..member1.. 0060: 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 .cn=user2,o=de,d 0070: 63 3d 67 61 63 c=gac ber_get_next: tag 0x30 len 123 contents: ber_dump: buf=0x8920ac0 ptr=0x8920ac0 end=0x8920b3b len=123 0000: 02 01 03 64 76 04 1f 63 6e 3d 63 6f 6e 74 61 63 ...dv..cn=contac 0010: 74 73 2c 63 6e 3d 75 73 65 72 2c 6f 3d 64 65 2c ts,cn=user,o=de, 0020: 64 63 3d 67 61 63 30 53 30 1d 04 0b 6f 62 6a 65 dc=gac0S0...obje 0030: 63 74 43 6c 61 73 73 31 0e 04 0c 67 72 6f 75 70 ctClass1...group 0040: 4f 66 4e 61 6d 65 73 30 10 04 02 63 6e 31 0a 04 OfNames0...cn1.. 0050: 08 63 6f 6e 74 61 63 74 73 30 20 04 06 6d 65 6d .contacts0 ..mem 0060: 62 65 72 31 16 04 14 63 6e 3d 75 73 65 72 32 2c ber1...cn=user2, 0070: 6f 3d 64 65 2c 64 63 3d 67 61 63 o=de,dc=gac read1msg: ld 0x88f5380 msgid 3 message type search-entry ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 100000 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: * msgid 3, type 100 ld 0x88f5380 response count 1 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 msgid 3, type 0x64 ber_scanf fmt ({m{) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b3b len=120 0000: 64 76 04 1f 63 6e 3d 63 6f 6e 74 61 63 74 73 2c dv..cn=contacts, 0010: 63 6e 3d 75 73 65 72 2c 6f 3d 64 65 2c 64 63 3d cn=user,o=de,dc= 0020: 67 61 63 30 53 30 1d 04 0b 6f 62 6a 65 63 74 43 gac0S0...objectC 0030: 6c 61 73 73 31 0e 04 0c 67 72 6f 75 70 4f 66 4e lass1...groupOfN 0040: 61 6d 65 73 30 10 04 02 63 6e 31 0a 04 08 63 6f ames0...cn1...co 0050: 6e 74 61 63 74 73 30 20 04 06 6d 65 6d 62 65 72 ntacts0 ..member 0060: 31 16 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 1...cn=user2,o=d 0070: 65 2c 64 63 3d 67 61 63 e,dc=gac [rw] searchResult: "cn=contacts,cn=user,o=de,dc=gac" -> "cn=contacts,cn=user,o=de,dc=gac" >>> dnPrettyNormal: <cn=contacts,cn=user,o=de,dc=gac> => ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac,0) <= ldap_bv2dn(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=contacts,cn=user,o=de,dc=gac)=0 <<< dnPrettyNormal: <cn=contacts,cn=user,o=de,dc=gac>, <cn=contacts,cn=user,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ae8 end=0x8920b3b len=83 0000: 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 31 0...objectClass1 0010: 0e 04 0c 67 72 6f 75 70 4f 66 4e 61 6d 65 73 30 ...groupOfNames0 0020: 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 63 74 ...cn1...contact 0030: 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 63 s0 ..member1...c 0040: 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 3d n=user2,o=de,dc= 0050: 67 61 63 gac ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920af7 end=0x8920b3b len=68 0000: 00 0e 04 0c 67 72 6f 75 70 4f 66 4e 61 6d 65 73 ....groupOfNames 0010: 30 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 63 0...cn1...contac 0020: 74 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 ts0 ..member1... 0030: 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 cn=user2,o=de,dc 0040: 3d 67 61 63 =gac ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b07 end=0x8920b3b len=52 0000: 30 10 04 02 63 6e 31 0a 04 08 63 6f 6e 74 61 63 0...cn1...contac 0010: 74 73 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 ts0 ..member1... 0020: 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 cn=user2,o=de,dc 0030: 3d 67 61 63 =gac ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b0d end=0x8920b3b len=46 0000: 00 0a 04 08 63 6f 6e 74 61 63 74 73 30 20 04 06 ....contacts0 .. 0010: 6d 65 6d 62 65 72 31 16 04 14 63 6e 3d 75 73 65 member1...cn=use 0020: 72 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 r2,o=de,dc=gac ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b19 end=0x8920b3b len=34 0000: 30 20 04 06 6d 65 6d 62 65 72 31 16 04 14 63 6e 0 ..member1...cn 0010: 3d 75 73 65 72 32 2c 6f 3d 64 65 2c 64 63 3d 67 =user2,o=de,dc=g 0020: 61 63 ac ber_scanf fmt ([W]) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b23 end=0x8920b3b len=24 0000: 00 16 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 ....cn=user2,o=d 0010: 65 2c 64 63 3d 67 61 63 e,dc=gac [rw] searchAttrDN: "cn=user2,o=de,dc=gac" -> "cn=user2,o=de,dc=gac" >>> dnPretty: <cn=user2,o=de,dc=gac> => ldap_bv2dn(cn=user2,o=de,dc=gac,0) <= ldap_bv2dn(cn=user2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnPretty: <cn=user2,o=de,dc=gac> >>> dnNormalize: <cn=user2,o=de,dc=gac> => ldap_bv2dn(cn=user2,o=de,dc=gac,0) <= ldap_bv2dn(cn=user2,o=de,dc=gac)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=user2,o=de,dc=gac)=0 <<< dnNormalize: <cn=user2,o=de,dc=gac> ber_scanf fmt ({m) ber: ber_dump: buf=0x8920ac0 ptr=0x8920b3b end=0x8920b3b len=0 ber_scanf fmt ({xx) ber: ber_dump: buf=0x8920ac0 ptr=0x8920ac3 end=0x8920b3b len=120 0000: 64 76 04 1f 63 6e 3d 63 6f 6e 74 61 63 74 73 2c dv..cn=contacts, 0010: 63 6e 3d 75 73 65 72 2c 6f 3d 64 65 2c 64 63 3d cn=user,o=de,dc= 0020: 67 61 63 00 53 30 1d 04 0b 6f 62 6a 65 63 74 43 gac.S0...objectC 0030: 6c 61 73 73 00 0e 04 0c 67 72 6f 75 70 4f 66 4e lass....groupOfN 0040: 61 6d 65 73 30 10 04 02 63 6e 00 0a 04 08 63 6f ames0...cn....co 0050: 6e 74 61 63 74 73 30 20 04 06 6d 65 6d 62 65 72 ntacts0 ..member 0060: 00 16 04 14 63 6e 3d 75 73 65 72 32 2c 6f 3d 64 ....cn=user2,o=d 0070: 65 2c 64 63 3d 67 61 63 e,dc=gac => send_search_entry: conn 3 dn="cn=contacts,cn=user,o=de,dc=gac" => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "entry" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr entry => match[0]: 12 31 cn=user,o=de,dc=gac => match[1]: 15 19 user => match[2]: 22 24 de => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "entry" requested => acl_mask: to all values by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "objectClass" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr objectClass => match[0]: 12 31 cn=user,o=de,dc=gac => match[1]: 15 19 user => match[2]: 22 24 de => slap_access_allowed: result not in cache (objectClass) => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "objectClass" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "cn" requested => dn: [1] => acl_get: [3] attr cn => slap_access_allowed: result not in cache (cn) => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "cn" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) => access_allowed: read access to "cn=contacts,cn=user,o=de,dc=gac" "member" requested => dn: [1] => dnpat: [4] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [4] matched => dnpat: [5] cn=([^,]*),o=([^,]*),dc=gac nsub: 2 => acl_get: [5] matched => acl_get: [5] attr member => match[0]: 12 31 cn=user,o=de,dc=gac => match[1]: 15 19 user => match[2]: 22 24 de => slap_access_allowed: result not in cache (member) => acl_mask: access to entry "cn=contacts,cn=user,o=de,dc=gac", attr "member" requested => acl_mask: to value by "cn=user2,o=de,dc=gac", (=0) <= check a_dn_pat: users <= acl_mask: [1] applying read(=rscxd) (stop) <= acl_mask: [1] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) ber_flush2: 125 bytes to sd 11 0000: 30 7b 02 01 03 64 76 04 1f 63 6e 3d 63 6f 6e 74 0{...dv..cn=cont 0010: 61 63 74 73 2c 63 6e 3d 75 73 65 72 2c 6f 3d 64 acts,cn=user,o=d 0020: 65 2c 64 63 3d 67 61 63 30 53 30 1d 04 0b 6f 62 e,dc=gac0S0...ob 0030: 6a 65 63 74 43 6c 61 73 73 31 0e 04 0c 67 72 6f jectClass1...gro 0040: 75 70 4f 66 4e 61 6d 65 73 30 10 04 02 63 6e 31 upOfNames0...cn1 0050: 0a 04 08 63 6f 6e 74 61 63 74 73 30 20 04 06 6d ...contacts0 ..m 0060: 65 6d 62 65 72 31 16 04 14 63 6e 3d 75 73 65 72 ember1...cn=user 0070: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 2,o=de,dc=gac sasl_write: want=145, written=145 0000: 00 00 00 8d ee 90 f3 ed 59 ee b5 ec 5f ae 3e aa ........Y..._.>. 0010: de 12 bf a5 11 0c 1d 9c 66 04 f6 0e ed e0 31 f2 ........f.....1. 0020: 69 e7 93 6a 77 87 e6 25 8b ba 32 92 e1 6a f0 ec i..jw..%..2..j.. 0030: 6a 64 5c 9e be c0 f2 0e 5e 12 9d 68 0f c2 4e 06 jd\.....^..h..N. 0040: fd 22 ee 71 ee 9f 28 85 92 75 87 72 a8 29 23 39 .".q..(..u.r.)#9 0050: 73 93 ed 45 f3 97 48 64 fe 8d 5d a0 a3 22 62 9f s..E..Hd..].."b. 0060: 21 25 e0 3b 09 1c c3 83 94 8b 42 7d 2a 20 51 3c !%.;......B}* Q< 0070: 69 11 74 cd 5e d5 e3 24 22 d5 5d 3a b1 79 df cb i.t.^..$".]:.y.. 0080: 1b cb 37 c4 09 ef ac 8c 34 78 02 00 01 00 00 00 ..7.....4x...... 0090: 02 . ldap_write: want=125, written=125 0000: 30 7b 02 01 03 64 76 04 1f 63 6e 3d 63 6f 6e 74 0{...dv..cn=cont 0010: 61 63 74 73 2c 63 6e 3d 75 73 65 72 2c 6f 3d 64 acts,cn=user,o=d 0020: 65 2c 64 63 3d 67 61 63 30 53 30 1d 04 0b 6f 62 e,dc=gac0S0...ob 0030: 6a 65 63 74 43 6c 61 73 73 31 0e 04 0c 67 72 6f jectClass1...gro 0040: 75 70 4f 66 4e 61 6d 65 73 30 10 04 02 63 6e 31 upOfNames0...cn1 0050: 0a 04 08 63 6f 6e 74 61 63 74 73 30 20 04 06 6d ...contacts0 ..m 0060: 65 6d 62 65 72 31 16 04 14 63 6e 3d 75 73 65 72 ember1...cn=user 0070: 32 2c 6f 3d 64 65 2c 64 63 3d 67 61 63 2,o=de,dc=gac conn=3 op=2 ENTRY dn="cn=contacts,cn=user,o=de,dc=gac" <= send_search_entry: conn 3 exit. ldap_msgfree ldap_result ld 0x88f5380 msgid 3 wait4msg ld 0x88f5380 msgid 3 (timeout 0 usec) wait4msg continue ld 0x88f5380 msgid 3 all 2 ** ld 0x88f5380 Connections: * host: 192.168.112.11 port: 389 (default) refcnt: 2 status: Connected last used: Thu May 14 10:19:33 2009 ** ld 0x88f5380 Outstanding Requests: * msgid 3, origid 3, status InProgress outstanding referrals 0, parent count 0 ld 0x88f5380 request count 1 (abandoned 0) ** ld 0x88f5380 Response Queue: Empty ld 0x88f5380 response count 0 ldap_chkResponseList ld 0x88f5380 msgid 3 all 2 ldap_chkResponseList returns ld 0x88f5380 NULL ldap_int_select read1msg: ld 0x88f5380 msgid 3 all 2 ber_get_next sasl_read: want=4, got=4 0000: 00 00 00 1e .... sasl_read: want=30, got=30 0000: e6 89 1d 0c cb fc a4 1b d5 c0 5e cb 22 a0 24 0f ..........^.".$. 0010: e8 02 b2 bf d3 3e 8c a9 00 01 00 00 00 05 .....>........ ldap_read: want=8, got=8 0000: 30 0c 02 01 03 65 07 0a 0....e.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x8920b50 ptr=0x8920b50 end=0x8920b5c len=12 0000: 02 01 03 65 07 0a 01 00 04 00 04 00 ...e........ read1msg: ld 0x88f5380 msgid 3 message type search-result ber_scanf fmt ({eAA) ber: ber_dump: buf=0x8920b50 ptr=0x8920b53 end=0x8920b5c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ read1msg: ld 0x88f5380 0 new referrals read1msg: mark request completed, ld 0x88f5380 msgid 3 request done: ld 0x88f5380 msgid 3 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 3, msgid 3) ldap_free_connection 0 1 ldap_free_connection: refcnt 1 ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x8920b50 ptr=0x8920b53 end=0x8920b5c len=9 0000: 65 07 0a 01 00 04 00 04 00 e........ ber_scanf fmt (}) ber: ber_dump: buf=0x8920b50 ptr=0x8920b5c end=0x8920b5c len=0 conn=3 op=2 meta_back_search[0] match="" err=0. ldap_msgfree send_ldap_result: conn=3 op=2 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=3 tag=101 err=0 ber_flush2: 14 bytes to sd 11 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ sasl_write: want=34, written=34 0000: 00 00 00 1e e8 3c 38 df 4b 1c ec fb 55 92 5c 6f .....<8.K...U.\o 0010: 44 b1 7f d4 f6 72 9f 5c 9b ff e3 48 00 01 00 00 D....r.\...H.... 0020: 00 03 .. ldap_write: want=14, written=14 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00 0....e........ conn=3 op=2 SEARCH RESULT tag=101 err=0 nentries=3 text= daemon: activity on 1 descriptor daemon: activity on: 11r daemon: read active on 11 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(11) connection_get(11): got connid=3 connection_read(11): checking for input on id=3 ber_get_next sasl_read: want=4, got=0 ldap_read: want=8, got=0 ber_get_next on fd 11 failed errno=0 (Success) connection_read(11): input error=-2 id=3, closing. connection_closing: readying conn=3 sd=11 for close connection_close: conn=3 sd=11 =>meta_back_conn_destroy: fetching conn=3 DN="cn=user2,o=de,dc=gac" =>meta_back_conn_destroy: destroying conn 3 refcnt=0 flags=0x00000100 ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 13 0000: 30 05 02 01 04 42 00 0....B. sasl_write: want=27, written=27 0000: 00 00 00 17 f0 4f 68 14 67 7c 34 5e 9f 47 43 50 .....Oh.g|4^.GCP 0010: 42 3e 0f 96 ca 00 01 00 00 00 01 B>......... ldap_write: want=7, written=7 0000: 30 05 02 01 04 42 00 0....B. ldap_free_connection: actually freed daemon: removing 11 conn=3 fd=11 closed (connection lost) 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

2 1

Re: (ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by michael＠stroeder.com 14 May '09

14 May '09

I cannot reproduce it all the time.

1 0

Re: (ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by michael＠stroeder.com 14 May '09

14 May '09

See tests/testrun/ here: http://www.stroeder.com/temp/openldap/its6126_test054-syncreplication-paral…

1 0

(ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by michael＠stroeder.com 14 May '09

14 May '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.105.68) >>>>> Starting test054-syncreplication-parallel-load ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Waiting 10 seconds to let the system catch up Using ldapmodify to modify producer directory... Using ldappasswd to change some passwords... Waiting 7 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Trying to change some passwords on the consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ >>>>> ./scripts/test054-syncreplication-parallel-load failed (exit 1) make[2]: *** [hdb-yes] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

1 0

(ITS#6125) back-sql support via Windows API ODBC
by slapd＠hannebauer.name 14 May '09

14 May '09

Full_Name: Christoph Hannebauer Version: 2.4.16 OS: Windows/cygwin URL: www.hannebauer.name/openldap-sql/configure.in.patch Submission from: (NULL) (77.189.227.183) I wasn't able to build slapd with back-sql in cygwin, because libodbc32 is not detected by configure. The console prints the error configure: error: could not locate suitable ODBC library and config.log contains: configure:31357: mgcc -o conftest.exe -g -O2 -I/usr/local/mingw/include -L/usr/local/mingw/lib conftest.c -lodbc32 >&5 /cygdrive/c/Users/CHANNE~1/AppData/Local/Temp/ccy74wDp.o: In function `main': /cygdrive/d/TestProgs/openldap-2.4.16/conftest.c:81: undefined reference to `_SQLDriverConnect' This means there is a library libodbc32, but it doesn't define SQLDriverConnect as a _cdecl function. When the current configure script searches for an ODBC library, it only checks whether one of the libraries iodbc, odbc, or odbc32 has SQLDriverConnect defined as _cdecl, which is not the case if odbc32 provides its functions as _stdcall. All Windows API functions are mangled as _stdcall functions, so I assume this error occurs on most MSYS and cygwin systems. With the attached patch, configure uses windows.h and sqlext.h to compile SQLDriverConnect and then tries to link it with -lodbc32 if no other ODBC library can be linked. This way, SQLDriverConnect is compiled the way sqlext.h defines it, which is _stdcall in case of cygwin. I have tested the patch in my environment: slapd with back-sql builds successfully. Glueck & Kanja Consulting AG (www.glueckkanja.com) hereby places the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#6118) Misleading LDAP URL example in man-page slapo-constraint.5
by michael＠stroeder.com 14 May '09

14 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.105.68) HI! I'd consider this example in the man-page of slapo-constraint to be problematic because the constrained attribute type is the same like the attribute type used for the valid values. constraint_attribute title uri ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog) Off course this would work if dc=catalog,dc=example,dc=com would be in a separate database but this is rather unlikely in common setups. So I'd recommend to make this clear. Ciao, Michael.

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by hyc＠symas.com 14 May '09

14 May '09

Luca Scamoni wrote: > Howard Chu ha scritto: >> >> In frame 1 print *ap >> > p *ap > $1 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags > = 0, a_next = 0x54149adc} Your frame 1 is pretty much impossible - you have oldattrs == newattrs, but in frame 2 the attr list was replaced by a duplicate (using attrs_dup, modify.c:94). Perhaps you've got a compiler bug. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by luca.scamoni＠sys-net.it 14 May '09

14 May '09

Howard Chu ha scritto: > > In frame 1 print *ap > p *ap $1 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags = 0, a_next = 0x54149adc} Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. Gruppo Partners Associates via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by hyc＠symas.com 14 May '09

14 May '09

luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Master segfaulted in hdb_index_mask. For some reason desc is NULL. > Backtrace: In frame 1 print *ap > #0 0x00de2d92 in hdb_index_mask (be=0x236ec90, desc=0x0, atname=0x236e958) at > index.c:47 > at = (AttributeType *) 0x99f5f48 > ai = (AttrInfo *) 0x0 > #1 0x00dd8ca5 in bdb_modify_idxflags (op=0x9c16a28, desc=0x9af4078, > got_delete=1, newattrs=0x5414fdac, oldattrs=0x5414fdac) at modify.c:54 > ap = (Attribute *) 0x5414fdac > ix2 = {bv_len = 0, bv_val = 0x2370104 ""} > ix_at = {bv_len = 25, bv_val = 0x99f5998 "certificateRevocationList"} > ai = (AttrInfo *) 0x9ab07c0 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by luca.scamoni＠sys-net.it 14 May '09

14 May '09

Last lines in log file May 14 07:50:25 quercia01 slapd[29850]: conn=57 op=68 MOD dn="cn=CRL7,ou=Regione Lombardia Certification Authority Cittadini,o=Regione Lombardia,c=IT,dc=a,dc =prod,dc=actalis" May 14 07:50:25 quercia01 slapd[29850]: conn=57 op=68 MOD attr=certificateRevocationList;binary May 14 07:50:25 quercia01 slapd[29850]: slap_queue_csn: queing 0x236e980 20090514055025.683019Z#000000#000#000000 Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. Gruppo Partners Associates via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6117) Segfault in hdb_index_mask
by luca＠OpenLDAP.org 14 May '09

14 May '09

Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Master segfaulted in hdb_index_mask. For some reason desc is NULL. Backtrace: #0 0x00de2d92 in hdb_index_mask (be=0x236ec90, desc=0x0, atname=0x236e958) at index.c:47 at = (AttributeType *) 0x99f5f48 ai = (AttrInfo *) 0x0 #1 0x00dd8ca5 in bdb_modify_idxflags (op=0x9c16a28, desc=0x9af4078, got_delete=1, newattrs=0x5414fdac, oldattrs=0x5414fdac) at modify.c:54 ap = (Attribute *) 0x5414fdac ix2 = {bv_len = 0, bv_val = 0x2370104 ""} ix_at = {bv_len = 25, bv_val = 0x99f5998 "certificateRevocationList"} ai = (AttrInfo *) 0x9ab07c0 #2 0x00dd98dc in hdb_modify_internal (op=0x9c16a28, tid=0x9ec6628, modlist=0xa3189f0, e=0x236eaa0, text=0x2370104, textbuf=0x236eb00 "ôÏ#", textlen=256) at modify.c:245 rc = 0 err = 0 mod = (Modification *) 0xa3189f0 ml = (Modifications *) 0xa3189f0 save_attrs = (Attribute *) 0x5414fdac ap = (Attribute *) 0x0 glue_attr_delete = 0 got_delete = 1 __PRETTY_FUNCTION__ = "hdb_modify_internal" #3 0x00ddab1a in hdb_modify (op=0x9c16a28, rs=0x23700f0) at modify.c:590 bdb = (struct bdb_info *) 0x9aaf888 e = (Entry *) 0x545d316c ei = (EntryInfo *) 0x9eb8828 manageDSAit = 0 textbuf = "ôÏ#\000@è#\000ðÿÿÿ(ë6\002á\226\027\000@è#\000\020\000\000\000\024Íy\000ð\0007\002\220ì6\002Hë6\002\026wy\000\020\000\000\000@è#\000ðÿÿÿ`\2352\n`\2352\n\024Íy\000hë6\002|wy\000\020\000\000\000\000\000\000\000\220ì6\002\000\000\000\000$\000\000\000@ç\026\b\006\000\000\000üþ\024Tl1]T\000\000\000\000xÓ5\n\000\000\000\000DjÁ\txÓ5\n\001\000\000\000\001\000\000\000D\2352\n\000\000\000\000\230\n«\t\230\t«\t\224y'\000\220ì6\002(ì6\002\232#'\000(jÁ\tÔt¿S\001\000\000\000Ñä\021\bL\000\000\000\000\200\000\000"... textlen = 256 ltid = (DB_TXN *) 0xa430420 lt2 = (DB_TXN *) 0x9ec6628 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x9aaf888}, boi_txn = 0xa430420, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\0', boi_flag = 0 '\0'} dummy = {e_id = 0, e_name = {bv_len = 130, bv_val = 0x0}, e_nname = {bv_len = 130, bv_val = 0x0}, e_attrs = 0x5414fdac, e_ocflags = 65792, e_bv = { bv_len = 0, bv_val = 0x0}, e_private = 0x0} lock = {off = 148504, ndx = 108, gen = 438195, mode = DB_LOCK_READ} num_retries = 0 preread_ctrl = (LDAPControl **) 0x0 postread_ctrl = (LDAPControl **) 0x0 ctrls = {0x0, 0xffffff40, 0x763c2298, 0x1, 0x0, 0x1} num_ctrls = 0 rc = 37153432 #4 0x080fffe2 in overlay_op_walk (op=0x9c16a28, rs=0x23700f0, which=op_modify, oi=0x9ab0898, on=0x0) at ../../../servers/slapd/backover.c:669 func = (BI_op_bind **) 0xf5fb8c rc = 32768 #5 0x081001a7 in over_op_func (op=0x9c16a28, rs=0x23700f0, which=op_modify) at ../../../servers/slapd/backover.c:721 oi = (slap_overinfo *) 0x9ab0898 on = (slap_overinst *) 0x9ab0998 be = (BackendDB *) 0x9aaf788 db = {bd_info = 0xf5fb60, bd_self = 0x9aaf788, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\001", '\0' <repeats 15 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9aaf5b8, be_nsuffix = 0x9ab0680, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 34, bv_val = 0x9ab0718 "cn=Manager,dc=a,dc=prod,dc=actalis"}, be_rootndn = {bv_len = 34, bv_val = 0x9ab0758 "cn=manager,dc=a,dc=prod,dc=actalis"}, be_rootpw = {bv_len = 6, bv_val = 0x9ab0548 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9af2488, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xf5f940, be_private = 0x9aaf888, be_next = {stqe_next = 0x9ab0b98}} cb = {sc_next = 0x0, sc_response = 0x80ff283 <over_back_response>, sc_cleanup = 0, sc_private = 0x9ab0898} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x0810027d in over_op_modify (op=0x9c16a28, rs=0x23700f0) at ../../../servers/slapd/backover.c:755 No locals. #7 0x08098538 in fe_op_modify (op=0x9c16a28, rs=0x23700f0) at ../../../servers/slapd/modify.c:301 update = 0 repl_user = 0 op_be = (BackendDB *) 0x9aaf788 bd = (BackendDB *) 0x8176380 textbuf = "ôÏ#\000@è#\000\230\030Ç\t(î6\002:v\027\000@è#\000\230\030Ç\tôÏ#\000šî6\002\230\030Ç\t\004ï6\002\004\236\035\000\230\030Ç\t\230\030Ç\t[\000\000\000\000@\000\000 Ó#\000\000\000\000\000\a\000\000\000\006vy\000xî6\002ÿÿÿÿÿÿÿÿ\v\000\000\000\025\000\000\000\230\030Ç\t\000\000\000\000!±\vJ", '\0' <repeats 16 times>, "µ0h%\000\000\000\000Èî6\002\027ä\t\bøÅ\233\t\220\233\000\n\031\000\000\000\2250h%\000\000\000\000\000\000\000\000\001\000\000\000ý\026<\000\004s¿S\220iÁ\táä\a\000\b@`%\a\000\000\000@ç\026\b\030ï6\002\\\214"... textlen = 256 #8 0x08097f67 in do_modify (op=0x9c16a28, rs=0x23700f0) at ../../../servers/slapd/modify.c:175 dn = {bv_len = 111, bv_val = 0x25683012 "cn=CRL7,ou=Regione Lombardia Certification Authority Cittadini,o=Regione Lombardia,c=IT,dc=a,dc=prod,dc=actalis"} textbuf = "8îTG\000\000\000\002\000\000\000\000³æ:\001ÿ\017\000\000@ç\026\b@è#\000\000\000\000\000\000\000\000\000\016\000\000\000@è#\000\000\000\000\000\000\000\000\000Tè#\000\200\000\000\000\000\000\000\000\031\000\000\000Xè#\000\006\000\000\0000\000\000\000ôÏ#\000 Ê#\000\000\000\000\000øÿ6\002ôÏ#\000\001\000\000\000@è#\000\030\0007\002V\224\027\000@è#\000,\000\000\000ÿÿÿÿðÀ\001\000\024Íy\000(\0007\002Ë\231y\000\030óÊ\tS£Ã\t\b\000\000\000Ìwy\000ÿÿÿÿ\024Íy\000\000\000\000\000\001\000\000\000\020\0027\002\000kÁ\t\230\0007\002fg\016\b\020\0027\002Õf\016\b"... textlen = 256 tmp = (Modifications *) 0x0 #9 0x08079867 in connection_operation (ctx=0x2370210, arg_v=0x9c16a28) at ../../../servers/slapd/connection.c:1115 rc = 80 op = (Operation *) 0x9c16a28 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = (Connection *) 0xb7f7a274 memctx = (void *) 0x9c16990 memctx_null = (void *) 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x08079d99 in connection_read_thread (ctx=0x2370210, argv=0x27) at ../../../servers/slapd/connection.c:1241 rc = 0 cri = {op = 0x9c16a28, func = 0, arg = 0x0, ctx = 0x2370210, nullop = 0} s = 39 #11 0x003ad389 in ldap_int_thread_pool_wrapper (xpool=0x99dfab0) at ../../../libraries/libldap_r/tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x99dfab0 task = (ldap_int_thread_task_t *) 0x52502480 work_list = (ldap_int_tpool_plist_t *) 0x99dfb30 ctx = {ltu_id = 37161888, ltu_key = {{ltk_key = 0x80793bb, ltk_data = 0x9c168a0, ltk_free = 0x80791ab <conn_counter_destroy>}, { ltk_key = 0x80e66d5, ltk_data = 0x9c16990, ltk_free = 0x80e64e8 <slap_sl_mem_destroy>}, {ltk_key = 0x8092ceb, ltk_data = 0x0, ltk_free = 0x8092c48 <slap_op_q_destroy>}, {ltk_key = 0x9af2498, ltk_data = 0x9c12970, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0x9af5a80, ltk_data = 0x9c31dd0, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0xde0b96, ltk_data = 0x44e44008, ltk_free = 0xde0b6b <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 580 hash = 5761604 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x008ad3cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #13 0x001ddc3e in clone () from /lib/tls/libc.so.6 No symbol table info available. any further info available upon request

1 0

Re: (ITS#6116) BDB 4.8 support
by hyc＠symas.com 13 May '09

13 May '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.131.62.113) > > > Oracle has kindly provided Howard and I access to the early BDB 4.8 code. > Filing this ITS so that we can track modifications to support new features in > BDB 4.8, such as the bulk add/delete capabilities. > After a quick read-thru of the Changes in 4.8, I'm a bit skeptical that we'll be able to use the bulk add/delete feature. It simply allows multiple key/value pairs to be written in one request and in general, since we only operate on individual entries, we seldom operate on more than one k/v pair at a time. The main exception is when generating a substring index. But in that case, we generate pairs in arbitrary (hashed) order, and BDB expects them in sorted order. We could try modifying slapadd to accumulate multiple entries in memory and then add them all at once, but that would only help the adds to the id2entry DB. For the dn2id and all the other index DBs, we again cannot guarantee that inserts will occur in any particular order. As such it seems like we'll be creating quite a bit of complexity, batching up id2entry writes but not batching up the other writes. On a separate front, we should probably look into adding support for partitioned databases. I think that has the potential to be pretty useful, although we'll have to continue to train admins to stop RAIDing all of their disks in order to see any benefit from this. It looks like most of the other changes in 4.8 are internal/transparent, so no action is required of us to take advantage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6116) BDB 4.8 support
by quanah＠OpenLDAP.org 13 May '09

13 May '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.131.62.113) Oracle has kindly provided Howard and I access to the early BDB 4.8 code. Filing this ITS so that we can track modifications to support new features in BDB 4.8, such as the bulk add/delete capabilities.

1 0

Re: (ITS#6112) LDAP Configuration
by quanah＠zimbra.com 13 May '09

13 May '09

--On May 13, 2009 9:41:04 AM +0000 vinodkharatmol(a)gmail.com wrote: > Full_Name: Vinod Kharatmol > Version: 2.3.27-5 > OS: Linux RHEL 4 Update 2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.199.133.19) > > > Hello, > > I have Installed RHEL 5 on VMware separately as Server and Client. > The LDAP Sever and Client Successfully configured. > I am able to start LDAP Server successfully using command: # service ldap > start. > I have created a ldapuser on Server. > But when I am trying to login as a ldapuser on client using # su ldapuser > then we are facing error as, su:ldapuser does not exist. > > I am totally stuck here. Nothing in this report shows any bug in the OpenLDAP software. If you are having problems with the ldap package provided by RHEL, I suggest you contact RedHat support. If you have general usage questions about OpenLDAP, you should address those to the appropriate list (most likely openldap-software(a)openldap.org). This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6115) gdi32.lib required by OpenSSL+Windows
by slapd＠hannebauer.name 13 May '09

13 May '09

Full_Name: Christoph Hannebauer Version: 2.4.16 OS: Windows/cygwin URL: http://www.hannebauer.name/openldap-openssl/configure.in.patch Submission from: (NULL) (139.18.40.169) I tried to use OpenSSL 0.9.8k for TLS in my cygwin (target MinGW) OpenLDAP build. The configure script does not detect OpenSSL (however, it doesn't break, instead it finishes without TLS support), because the static library cannot be linked. The config.log file contains error messages like /usr/local/mingw/lib/libcrypto.a(rand_win.o):rand_win.c:(.text+0xa0c): undefined reference to `_CreateDCA@16' The missing functions are part of the library gdi32.lib. The OpenSSL readme file INSTALL.W32 says, that Windows program using OpenSSL should link gdi32.lib (and user32.lib, ..., but on my machine, gdi32.lib seems to be sufficient). Therefore I have created the attached patch file to configure.in (1.697), which adds gdi32.lib to LIBS, if it is required for OpenSSL. I have tested the patched configure file on my machine, the build works without problems. Glück & Kanja Consulting AG (www.glueckkanja.com) hereby places the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs