openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

How to correctly escape search filters
by Jeremiah Martell 27 Apr '10

27 Apr '10

I've been trying to research how to correctly escape search filters, and I can't find any single reliable source that makes sense. I look at RFC 2253 (http://www.ietf.org/rfc/rfc2253.txt) section 2.4, and this IBM webpage ( http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzah… ), and they both seem to suggest that you need to escape (for example) the '+' sign. But when I escape a search filter like this: (&(objectclass=person)(facsimileTelephoneNumber=+1234)) to this: (&(objectclass=person)(facsimileTelephoneNumber=\+1234)) it results in a bad filter. My hunch is that perhaps DNs, attribute names, and attribute values are all escaped different. Is there a simple explanation online on how to escape search filters? Thanks, - Jeremiah

2 1

Re: openldap 2.4.21 - back-ldap + pcache ... backend binding
by repudi8or repu 27 Apr '10

27 Apr '10

On Tue, Apr 27, 2010 at 3:43 PM, repudi8or repu <repudi8or(a)gmail.com> wrote: > Thanks for the response Masarati, > > I have setup with mode=self, but still the same error. > > Maybe im having a conceptual issue here. What i am trying to do is ensure > the backend functions prior to looking at the configuring the frontend > correctly. I am configuring the solaris openldap slapd with back-ldap and > pcache and am expecting to be able to simulate a fronted authentication > process using ldapsearch to the solaris openldap proxy. The backend ldap > service is AD @ backendldap.core.dir.mycompany.com. the proxy box i will > refer to as openldapproxy (openldapproxy.core.dir.mycompany.com)" > > my database ldap section now looks like this :- > backendldap.core.dir.mycompany.com" > > database ldap > uri "ldap://backendldap.core.dir.mycompany.com" > suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" > rootdn "dc=core,dc=dir,dc=mycompany,dc=com" > idassert-bind > bindmethod=simple binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" credentials="password" > mode=self > > i am testing by running ldapsearch on the openldapproxy host itself in the > following manner :- > # /usr/local/bin/ldapsearch -x -h localhost -b > ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com employeeID=12345678 > > the proxied bind goes out to the backend AD as i have shown in the below > discussion. The response returned is :- > # filter: employeeID=12345678 > # requesting: ALL > # > # search result > search: 2 > result: 48 Inappropriate authentication > # numResponses: 1 > > Running slapd in diag mode i see the following in the debug output :- > do_bind: v3 anonymous bind > connection_get(11) > connection_get(11): got connid=1014 > connection_read(11): checking for input on id=1014 > ber_get_next > ber_get_next: tag 0x30 len 105 contents: > op tag 0x63, time 1272346583 > ber_get_next > conn=1014 op=1 do_search > ber_scanf fmt ({miiiib) ber: > >>> dnPrettyNormal: > <ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com> > => ldap_bv2dn(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com,0) > <= ldap_bv2dn(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > => ldap_dn2bv(272) > <= ldap_dn2bv(ou=people,ou=eprofile,dc=core,dc=dir,dc=mycompany,dc=com)=0 > <<< dnPrettyNormal: > <ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com>, > <ou=people,ou=eprofile,dc=core,dc=dir,dc=mycompany,dc=com> > SRCH "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" 2 0 0 0 > 0 > ber_scanf fmt ({mm}) ber: > filter: (?=undefined) > ber_scanf fmt ({M}}) ber: > attrs: > ==> limits_get: conn=1014 op=1 self="[anonymous]" > this="ou=people,ou=eprofile,dc=core,dc=dir,dc=telstra,dc=com" > send_ldap_result: conn=1014 op=1 p=3 > send_ldap_result: err=48 matched="" text="" > send_ldap_response: msgid=2 tag=101 err=48 > Note the anonymous bind, I need this to be a simply authenticated bind > using the idassert binddn and credentials > Note the "self="[anonymous]"............... I was expecting that it should > have been self=[USERID_THAT_RAN_THE_LDAPSEARCH] > > Regards Rep > On Tue, Apr 27, 2010 at 1:55 PM, <masarati(a)aero.polimi.it> wrote: > >> > Hi Folks, >> > >> > I am having troubles configuring openladp to my requirements. >> > >> > I am setting up an openldap server running on solaris 10 x86 to use as >> > a ldap proxy authentication server. >> > >> > My issue is that i cant get it to send authenticated simple binds to the >> > backend ldap system. I am running wireshark and when i ldapsearch direct >> > to >> > the backend ldap i see a bind which looks like this :- >> > Lightweight-Directory-Access-Protocol >> > LDAPMessage bindRequest(1) >> > "cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" simple >> > messageID: 1 >> > protocolOp: bindRequest (0) >> > bindRequest >> > version: 3 >> > name: >> > cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com >> > authentication: simple (0) >> > simple: 384174656C73747261316732 >> > >> > However when i initiate an ldapsearch to my local solaris slapd and >> > capture >> > the proxied backldap bind to the backend ldap system it looks like this >> :- >> > Lightweight-Directory-Access-Protocol >> > LDAPMessage bindRequest(1) "<ROOT>" simple >> > messageID: 1 >> > protocolOp: bindRequest (0) >> > bindRequest >> > version: 3 >> > name: >> > authentication: simple (0) >> > simple: <MISSING> >> > >> > I am having trouble working out from the documentation if it should be >> > acl-bind or idassert-bind or some other option which influences the >> > backend >> > bind. I have tried both those to no avail. >> > Here is the "database ldap" section from my slapd.conf >> > >> > ####################################################################### >> > # ldap database definitions >> > ####################################################################### >> > database ldap >> > uri "ldap://backendldap.core.dir.mycompany.com" >> > suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" >> > rootdn "dc=core,dc=dir,dc=mycompany,dc=com" >> > acl-bind bindmethod=simple >> > binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> > credentials="password" >> > idassert-bind bindmethod=simple >> > binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> > credentials="password" >> >> The relevant directive is "idassert-bind", since you appear to be looking >> for an identity assertion. I hope what you posted was screwed up by the >> mailer: continuation lines must start with whitespace. What is missing >> above is the "mode=self" parameter to "idassert-bind". Try something like >> >> idassert-bind bindmethod=simple >> binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" >> credentials="password" >> mode=self >> >> p. >> >> > overlay pcache >> > proxycache bdb 400 1 50 1200 >> > directory /var/openldap-data >> > cachesize 10000 >> > index cn,sn,uid pres,eq,sub >> > index objectclass eq >> > >> > proxycachequeries 400 >> > proxyattrset 0 uid mail cn sn givenName >> > proxytemplate (uid=) 0 600 >> > proxytemplate (mail=) 0 600 >> > proxytemplate (&(uid=)(mail=)) 0 600 >> > >> > Any help would be greatly appreciated >> > >> > Regards Rep >> > >> >> >> >

2 1

openldap 2.4.21 - back-ldap + pcache ... backend binding
by repudi8or repu 27 Apr '10

27 Apr '10

Hi Folks, I am having troubles configuring openladp to my requirements. I am setting up an openldap server running on solaris 10 x86 to use as a ldap proxy authentication server. My issue is that i cant get it to send authenticated simple binds to the backend ldap system. I am running wireshark and when i ldapsearch direct to the backend ldap i see a bind which looks like this :- Lightweight-Directory-Access-Protocol LDAPMessage bindRequest(1) "cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" simple messageID: 1 protocolOp: bindRequest (0) bindRequest version: 3 name: cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com authentication: simple (0) simple: 384174656C73747261316732 However when i initiate an ldapsearch to my local solaris slapd and capture the proxied backldap bind to the backend ldap system it looks like this :- Lightweight-Directory-Access-Protocol LDAPMessage bindRequest(1) "<ROOT>" simple messageID: 1 protocolOp: bindRequest (0) bindRequest version: 3 name: authentication: simple (0) simple: <MISSING> I am having trouble working out from the documentation if it should be acl-bind or idassert-bind or some other option which influences the backend bind. I have tried both those to no avail. Here is the "database ldap" section from my slapd.conf ####################################################################### # ldap database definitions ####################################################################### database ldap uri "ldap://backendldap.core.dir.mycompany.com" suffix "ou=People,ou=eProfile,dc=core,dc=dir,dc=mycompany,dc=com" rootdn "dc=core,dc=dir,dc=mycompany,dc=com" acl-bind bindmethod=simple binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" credentials="password" idassert-bind bindmethod=simple binddn="cn=mybindid,cn=users,dc=core,dc=dir,dc=mycompany,dc=com" credentials="password" overlay pcache proxycache bdb 400 1 50 1200 directory /var/openldap-data cachesize 10000 index cn,sn,uid pres,eq,sub index objectclass eq proxycachequeries 400 proxyattrset 0 uid mail cn sn givenName proxytemplate (uid=) 0 600 proxytemplate (mail=) 0 600 proxytemplate (&(uid=)(mail=)) 0 600 Any help would be greatly appreciated Regards Rep

2 1

Schema-aware and OBSOLETE (was: (ITS#6151) Update cosine.schema to RFC 4524)
by Michael Ströder 26 Apr '10

26 Apr '10

Kurt, following-up on openldap-technical since this is off-topic in ITS#6151. Kurt Zeilenga wrote: > > On Apr 22, 2010, at 2:58 PM, Michael Ströder wrote: > >> Kurt Zeilenga wrote: >>> One additional note, I generally would advise that a schema-aware client >>> not alter it's update behavior of elements based upon whether said elements >>> are active or inactive (OBSOLETE) in the schema. >> >> I disagree especially for cases when new data is added. > > I think you're trying to make the client far smarter than it really ought > to be. This general statement is pretty blurry without speaking about certain use-cases. > If the clients configured to place say place element of data in attribute > x, it shouldn't try to put it elsewhere. It should fail. > While certainly one could design a client such as it could be configured > with fallbacks for attributes, and fallback for fallbacks, etc., this is an > unnecessarily complication IMO. Who said that my or any other client is doing anything like this in case of OBSOLETE schema elements? It would certainly be non-sense. The only thing I'm trying to achieve is to guide the user in the UI not to get frustrated by trial-and-error. > Also, note that were a client to attempt the above, it could still fail due > to an element being marked inactive between the time it read the schema and > the time it tried the DIT update. A client always have to implement proper error control even if the UI is guiding the user along the subschema information. >>> Instead, they should just >>> try the update and, if it fails, report it as they normally would. >> >> Modifying existing data I first have to think about... >> >>> Handling the inactive condition locally hides the error from the directory >>> administrator, who is likely relying on directory server logs to find >>> applications which using inactive schema. >> >> Hmm, that's not the case with a schema-aware client anyway which guides the >> user *not* to use OBSOLETE schema elements. > > I generally assume the user is not selecting which attribute to store some > piece of information into. I assume the client been programmed to collect > a piece of information and configured (or programmed) where to store it. With web2ldap it's a mix of both: One can pre-configure HTML templates per object class for input forms with which the web2ldap admin specifies the descriptive labels around an input field. With this you can hide which LDAP attribute the data is stored into. But the user can also switch to table and LDIF input fields (and back to tempating) when editing the data. In the template and table input forms I'd like to grey out input fields where the user's input would lead to a schema violation (OBSOLETE). E.g. it does not make sense to present OBSOLETE object classes in the object class select form when adding/modifying entries. It's similar to use slapo-allowed to only display editable input fields of attributes a user is allowed to write to. On the other hand web2ldap always trys to respect what's already present in the entries. The paradigm is to be minimal invasive: Don't change anything while modifying existing entries if the user did not explicitly change it. > The client you refer to is what I would call an application-neutral LDAP > directory administration tool. For such a tool, it might be reasonable to > warn the user (whose generally an "administrator" of some sort as opposed > to a "normal" user). Even such a tool can have customization. The categories are not that sharp... ;-) >> You're likely talking about >> detecting pre-configured applications with hard-coded use of OBSOLETE object >> classes and attribute types. >> Most times these are not schema-aware at all. > > Well, pre-configured applications may be schema-aware but maybe not as > fully as an LDAP directory administration tool might be. They might check > that the element they were configured to use is appropriate for that use by > examining its specification in the subschema. Yes, there are things like this in web2ldap too for certain use-cases (e.g. determining whether it works with MS AD while setting password attribute etc.). But I was especially interested in discussing what's appropriate in case of OBSOLETE schema descriptions. Ciao, Michael.

1 0

[Fwd: Support for ordering matching rules in extensible match filters?]
by deepee＠gmx.net 25 Apr '10

25 Apr '10

Hi, first of all, please excuse me if I've hit the wrong openldap mailinglist. My question below is related to section 4.1 of RFC4517 which says: Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion syntax of the matching rule is the same as the value syntax of the attribute. Could someone please explain to me why openldap currently doesn't support for example 'caseIgnoreOrderingMatch' (which is listed in section 4.2 of RFC4517) in extensible match filters? Of course I've seen the two SHOULDs above - I just don't understand the openldap related technical/design decision regarding the missing support and would be very happy if someone could please explain this to me. Another more common question but also related to my previous mail (below): could someone please also tell me the RFC(s) in which the evaluation of ordering matching rules (especially when used in extensible match filters) is specified? Thanks again! Betreff: Support for ordering matching rules in extensible match filters? Datum: Thu, 22 Apr 2010 11:18:35 +0200 Von: Daniel <deepee(a)gmx.net> An: openldap-technical(a)openldap.org Hi, why doesn't slapd support ordering matching rules in extensible match filters? Does the small code enhancement for slapd's generalizedTimeOrderingMatch() would make sense into the direction to support ordering matching in extensible filters (in this particular case)? Thanks a lot! static int generalizedTimeOrderingMatch( int *matchp, slap_mask_t flags, Syntax *syntax, MatchingRule *mr, struct berval *value, void *assertedValue ) { struct berval *asserted = (struct berval *) assertedValue; ber_len_t v_len = value->bv_len; ber_len_t av_len = asserted->bv_len; /* ignore trailing 'Z' when comparing */ int match = memcmp( value->bv_val, asserted->bv_val, (v_len < av_len ? v_len : av_len) - 1 ); Debug( LDAP_DEBUG_TRACE, "gTOM1: %s %s %d\n", value->bv_val, asserted->bv_val, match); if ( flags & SLAP_MR_EXT ) { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => SLAP_MR_EXT (%ld) [%d %d]\n", flags, 0, 0); if ( match == -1 ) match = 0; else if ( match == 0 ) match = 1; } else { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => ? (%ld) [%d %d]\n", flags, 0, 0); if ( match == 0 ) match = v_len - av_len; } Debug( LDAP_DEBUG_TRACE, "gTOM2: %s %s %d\n", value->bv_val, asserted->bv_val, match); *matchp = match; return LDAP_SUCCESS; }

2 2

N-Way Replication noob questions
by Siddhartha Jain 25 Apr '10

25 Apr '10

Hi, First, kudos to OpenLDAP team for the progress they have made with 2.4. I am returning to use OpenLDAP after nearly a decade and it is heartening to see all the new features even when going from 2.3 to 2.4 (As a side rant, it is painful to see Redhat/CentOS still ship 2.3.x. RedHat might do it to push their own DS over OpenLDAP but why CentOS)? 1. From the OpenLDAP guide, I see that replication is setup to replicate both - config and information trees. a. With each master having a unique "ServerID", does it mean that config replication won't overwrite certain attributes like ServerID? b. How are multiple "ServerID" values handled when the replication config is introduced? c. What about credentials used for rootDN of various databases? Do they get sync-ed too? 2. What is the best way to setup a new master with empty databases? Slapcat from an existing one and Slapdadd to the new one? Or, let replication take care of it? Network traffic issues aside, my point is how does timestamp matching work for non-existant objects (in the new master vs existing). Or, put differently, how is deletion vs new/empty database differentiated? Why wouldn't replication consider the non-existence of databases in the new master as all databases having been deleted? 3. From 18.2.2.3 of the Guide "Arguments against Multi-Master replication". 4. " If connectivity with a provider is lost because of a network partition, then "automatic failover" can just compound the problem" Care to expand on this, please? 5. " If a network is partitioned and multiple clients start writing to each of the "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single provider" How so? If all masters are sync-ed with NTP tighly, then shouldn't this issue take care of itself when a partitioned master(s) comes back online and reconnect. Thanks, - Siddhartha

2 1

ppolicy in back_ldap?
by Tyler Gates 23 Apr '10

23 Apr '10

Hey guys, I currently have a multi-master system setup with a back_ldap proxying frontend. We are using ppolicy and it is loaded fine and works on the two masters but I'm experiencing a little weirdness on the proxy side. It works fine but when I implemented password expirations the other day I keep seeing messages on the proxy like: ppolicy_bind: Setting warning for password expiry for .... = 0 seconds These entries should not be receiving any warning messages and I know my settings are correct because if I redirect to one of the masters the log output is what I expect. Also, if I run a perl script that uses password policy controls and look for time_before_expiration, the value is always 0 on the proxy while it is not even set if pwdExpireWarning is not met or a sane value if it is on the masters. After reading slapo-ppolicy it looks like maybe I should be setting olcPPolicyForwardUpdates to TRUE (?) and set a olcupdateRef in olcDatabase={1}ldap,cn=config to both masters but it spits at me every time I try it. It also says a chain overlay should be set as well but when I read slapo-chain its says: "It is useless in conjunction with the slapd-ldap and slapd-meta backends because they already exploit the libldap specific referral chase feature." If I remove ppolicy overlay I don't see any of the values. I need the proxy to be able to see these attributes (as in those making queries to it) and not hammer my logs with incorrect messages. Is it possible to make this work, am I doing some wrong? Thanks for any help, Tyler -- Tyler Gates Systems Administrator Castle Branch Inc. 910-815-3880 ext 7230 tjgates(a)castlebranch.com This e-mail message, including any attachments, may contain private, confidential, and privileged information for the restricted use of the intended recipient(s). If you are not the intended recipient(s), you may NOT use, disclose, copy, or disseminate this information. Please notify the sender by return e-mail of this misdirected correspondence and destroy all copies of the original message including all attachments. Your cooperation is appreciated.

2 8

Syncrepl TLS certificate verification - configurable
by Siddhartha Jain 22 Apr '10

22 Apr '10

Hi, I have setup replication between two primary servers to use TLS. The config says: {0}rid=101 provider=ldap://pldap01.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem {1}rid=102 provider=ldap://pldap02.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem Replication works alright but logs show these lines on pldap01: Apr 22 03:47:20 pldap01 slapd[3451]: conn=1089 fd=22 TLS established tls_ssf=256 ssf=256 Apr 22 03:47:20 pldap01 slapd[3451]: slap_client_connect: URI=ldap://pldap02.xyz.net Warning, ldap_start_tls failed (-11) And, this on pldap02: Apr 22 03:47:40 pldap02 slapd[2564]: conn=1096 fd=26 TLS established tls_ssf=256 ssf=256 Apr 22 03:47:51 pldap02 slapd[2564]: slap_client_connect: URI=ldap://pldap01.xyz.net Warning, ldap_start_tls failed (-11) To be fair, the certificates are self-signed and don't match the DN but I am assuming that "starttls=yes" forces TLS and the consumers cannot default to plaintext. Right? If yes, does this mean that in syncrepl, tls use is hardcoded to verify certificates and fall back to non-verified TLS session if verification fails? Or, is this configurable meaning can I enforce verification (preferable in production)? Thanks, - Siddhartha

2 1

RE: Implementing LDAP logging
by rahul.manchanda＠bt.com 22 Apr '10

22 Apr '10

Adding to the below I didn't compiled the LDAP with --enable-debug during configuration time. Is that the reason it is not logging to the logfile I mentioned in the ldap configuration? This is the way I am specifying the logging info in the slapd.conf: loglevel sync stats logfile /opt/software/openldap2.4.19/etc/openldap/logs/ldaplog-primary.log Please suggest. Regards Rahul Manchanda ------------------------------------------------------------------------ ---------------------------------- Andes , Selfcare Platform Build Team tel: (+91) (20) 66018100 extn: 6178; e-mail: rahul.manchanda(a)bt.com Address: Tech Mahindra, Sharada Center, Erandwana Pune-4 From: Manchanda,RK,Rahul,DKE C Sent: Wednesday, April 21, 2010 3:03 PM To: openldap-technical(a)openldap.org Cc: Manchanda,RK,Rahul,DKE C Subject: Implementing LDAP logging Hi All, Even on specifying the loglevel and logfile directives in the slapd.conf ldap related logs are not being written to the file. However separate auditlog file is getting created successfully and all the update/delete/modify/insert operations are getting recorded successfully over there. I need to get the ldap related log file created as well but that is something not happening. Also tried specifying the LOCAL4 feature in the syslog.conf and restarted the system logging service but no luck with that as well. I don't want to put the logging options in the ldap start up command line argument but want the log file created from configuration itself. Can someone please suggest on this and also is there a way to implement log rotation for the ldap log file through configuration itself then that will be really helpful. Many Thanks in advance. Regards Rahul Manchanda ------------------------------------------------------------------------ ---------------------------------- Andes , Selfcare Platform Build Team tel: (+91) (20) 66018100 extn: 6178; e-mail: rahul.manchanda(a)bt.com Address: Tech Mahindra, Sharada Center, Erandwana Pune-4

2 4

Support for ordering matching rules in extensible match filters?
by Daniel 22 Apr '10

22 Apr '10

Hi, why doesn't slapd support ordering matching rules in extensible match filters? Does the small code enhancement for slapd's generalizedTimeOrderingMatch() would make sense into the direction to support ordering matching in extensible filters (in this particular case)? Thanks a lot! Cheers Daniel static int generalizedTimeOrderingMatch( int *matchp, slap_mask_t flags, Syntax *syntax, MatchingRule *mr, struct berval *value, void *assertedValue ) { struct berval *asserted = (struct berval *) assertedValue; ber_len_t v_len = value->bv_len; ber_len_t av_len = asserted->bv_len; /* ignore trailing 'Z' when comparing */ int match = memcmp( value->bv_val, asserted->bv_val, (v_len < av_len ? v_len : av_len) - 1 ); Debug( LDAP_DEBUG_TRACE, "gTOM1: %s %s %d\n", value->bv_val, asserted->bv_val, match); if ( flags & SLAP_MR_EXT ) { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => SLAP_MR_EXT (%ld) [%d %d]\n", flags, 0, 0); if ( match == -1 ) match = 0; else if ( match == 0 ) match = 1; } else { Debug( LDAP_DEBUG_TRACE, "gTOM: MR => ? (%ld) [%d %d]\n", flags, 0, 0); if ( match == 0 ) match = v_len - av_len; } Debug( LDAP_DEBUG_TRACE, "gTOM2: %s %s %d\n", value->bv_val, asserted->bv_val, match); *matchp = match; return LDAP_SUCCESS; }

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical