openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

(ITS#6769) Slapd fails to start when olcDbURI attribute is used
by jwinius＠umrk.nl 03 Jan '11

03 Jan '11

Full_Name: Jaap Winius Version: 2.4.23-7 OS: Debian squeeze URL: Submission from: (NULL) (2001:888:10:d5f::2) When attempting configuring slapd as a consumer with proxy authorization, it refuses to start up after the olcDbURI attribute is added to the olcDatabase=ldap entry: ===BEGIN====================== slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}hdb,cn=config: slapcat: bad configuration file! ===END======================== This situation occurs with both the SIMPLE and SASL-GSSAPI bind configurations that I've tested. The solution is to apply this patch: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch For background, see also this thread: http://www.openldap.org/lists/openldap-technical/201011/msg00124.html As you can see, the issue has been known for some time, but I don't know if a bug report has been submitted for it yet, so I thought this would do no harm.

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 03 Jan '11

03 Jan '11

--On Thursday, September 30, 2010 11:31 AM +0000 hyc(a)symas.com wrote: Using the latest patch for this issue from HEAD, the issue is no longer present. Using 14 searches (7 full db/7 paged results with a filter), the size of the slapd process is persistent across multiple runs, rather than growing substantially with each iteration of searches. This is using the same system and same database when the problem was originally filed. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6664) Server control forwarding in back_meta and back_ldap
by masarati＠aero.polimi.it 03 Jan '11

03 Jan '11

> back_meta and back_ldap should forward server controls that clients use in > their > queries to the corresponding external LDAP servers. > > For example, the inhability to send controls to external servers currently > causes that RFC2696 paged results control cannot be used, so it is > impossible to > retrieve more results for a query than the page size configured in the > external > server, which often is not a big number. I've patched back-meta in HEAD: if you add the "client-pr" directive, it will perform the client-side of RFC 2696 paged results (either always, with the specified page size, or in response to unsolicited paged results response). This will be totally transparent to the actual client, so the client no longer needs to perform paged results itself. Please test and report. Thanks, p.

1 0

(ITS#6768) NULL OldDN in modrdn operation kill slapd server
by sergeyfd＠gmail.com 03 Jan '11

03 Jan '11

Full_Name: Serge Dubrouski Version: 2.4.23 OS: RedHat ES 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.30.65.103) I ound that ldp.exe tool that comes with Windows is able to successfully kill OpenLDAP 2.4.23 slapd server when one tries to modify DN and submits an empty old DN. No binding is necessary so even anonymous user can easily run a DOS attach against OpenLDAP. Log files in openldap show this: Dec 29 15:19:32 ottawa slapd[11818]: conn=1000 op=2 do_modrdn Dec 29 15:19:32 ottawa slapd[11818]: do_modrdn: dn () newrdn (C=US) newsuperior () Dec 29 15:19:32 ottawa slapd[11818]: >>> dnPrettyNormal: <> Dec 29 15:19:32 ottawa slapd[11818]: <<< dnPrettyNormal: <>, <> Dec 29 15:19:32 ottawa slapd[11818]: >>> dnPrettyNormal: <C=US> Dec 29 15:19:32 ottawa slapd[11818]: <<< dnPrettyNormal: <c=US>, <c=us> Dec 29 15:19:32 ottawa slapd[11818]: conn=1000 op=2 MODRDN dn=""

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by raphael.ouazana＠linagora.com 03 Jan '11

03 Jan '11

Le Sam 1 janvier 2011 19:37, masarati(a)aero.polimi.it a écrit : >> raphael.ouazana(a)linagora.com wrote: >> >>> When using memberOf overlay, a MODRDN request on a member does not >>> update >>> correctly the matching group, even if the memberof-refint option is set >>> to >>> true. >>> >>> In my little understanding, memberof_value_modify calls >>> op->o_bd->be_modify >>> which calls back the overlay code, and finally never reach the backend. >> >> Guess what, modrdn is the only operation test052 does not check :( >> WOrking at it. Thanks, p. > > Fixed in HEAD; please test and report. Please note that test052 and the > corresponding expected output data have been modified to check modrdn. Thank you very much. Tested r1.33->r1.34, and this works fine, great! Regards, Raphaël Ouazana.

1 0

Re: (ITS#6684)
by norbert＠pueschel.net 03 Jan '11

03 Jan '11

Am 30.12.10 18:28, schrieb Howard Chu: > norbert(a)pueschel.net wrote: >> Updated TAR-file with (hopefully) sufficient copyright notice... >> >> http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar > > Your code does a string compare againset "memberOf" to detect those > filter references. > 1) it should simply be comparing the AttributeDescription pointers > 2) since the "memberof" attribute is actually configurable in the > memberof overlay, there's no guarantee that this is the correct > attribute to be looking for. It should also be configurable in your > patch. > You are right, of course. The problem is, I do not understand enough of internal structures to find the correct pointer... I would need to detect the memberof-overlay and find the correct string or pointer to compare to. I will gladly do so if you can give me some hints where to look. > You're using strcasecmp, but your inputs are already normalized > values. You should just use ber_bvcmp. > Right, see above. > Replying to the original: > >> 1) Using non-DN-valued URIs for autogroup does not work correctly, even >> with the latest version from HEAD. Especially changing group member is >> not tracked. > > I don't see why this should ever work or be supported. LDAP groups > list DNs. > Wrong. If you really think so, why did you accept Raphael Ouazana's patch, which is all about making this case work? Also see below. >> 2) Using the memberOf-overlay for constructing autogroups does not work > > I don't see any reason why this should work. The memberof overlay is > not used to construct groups, it is only used to report on group > memberships that have already been defined. Well, consider the following construction (which I am using in our ldap directory and which is the reason I started work on the autogroup overlay): dn: cn=admins,ou=access,dc=networker-gmbh,dc=de objectClass: groupOfNames cn: admins member: uid=xxxxx,ou=people,dc=networker-gmbh,dc=de member: uid=yyyyyy,ou=people,dc=networker-gmbh,dc=de dn: cn=admins(a)networker-gmbh.de,ou=aliases,dc=networker-gmbh,dc=de objectClass: nisMailAlias objectClass: labeledURIObject cn: admins(a)networker-gmbh.de labeledURI: ldap:///ou=people,dc=networker-gmbh,dc=de?mail?one?(&(objectClass=inetOrgPerson)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) dn: cn=admins,ou=groups,dc=networker-gmbh,dc=de objectClass: posixGroup objectClass: labeledURIObject cn: admins gidNumber: 10100 labeledURI: ldap:///ou=people,dc=networker-gmbh,dc=de?uid?one?(&(objectClass=posixAccount)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) Additionally, consider this relevant excerpt from slapd.conf: overlay dynlist dynlist-attrset groupOfNames labeledURI member dynlist-attrset nisMailAlias labeledURI rfc822MailMember:mail overlay autogroup autogroup-attrset posixGroup labeledURI memberUid As you can see, I use memberOf the construct mail aliases and posix group memberships from a groupOfNames master-list. For the mail aliases, dyngroup is sufficient, but the posix groups also need reverse lookups, which is why I'm using the autogroup overlay for this. Also, I cannot use a dn-valued list for the posix groups, as the Solaris NSS-libraries require the uid attribute to not contain a full dn.

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 03 Jan '11

03 Jan '11

On Sun, Jan 02, 2011 at 07:40:25PM -0800, Howard Chu wrote: > >(1) Stick more or less with the current behaviour, and change the > >documentation to say that you'll get > > uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > >for foreign realms. > > > >However, the odd thing about the current behaviour is that setting > >olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into > >the auth DN, regardless of whether it's local or foreign. That's not very > >useful. > > Note that it's not the OpenLDAP code that's sticking this in there; > it's the Cyrus code that's returning this realm in the callback. IMO > our job is to faithfully return what the Cyrus library gave us. The Cyrus library is faithfully passing on the *default* user_realm that you originally passed to sasl_server_new() in servers/slapd/sasl.c (which is global_realm, a.k.a. olcSaslRealm) Then OpenLDAP is sticking it into the authDN, in slap_sasl_getdn() > >I think it would make more sense, if olcSaslRealm is present, to use it to > >*qualify* usernames which don't have a realm. > > That decision is made by the Cyrus library, not us. It does not mandate what you do with the user_realm. You are free to ignore it, use it to qualify usernames which have no realm, or whatever. The documentation for canon_user (in include/sasl.h) says: * If user_realm is non-empty and an * unqualified user name is supplied, then the canon_user facility is * expected to append "@" and user_realm to the user name. The canon_user * facility may treat other characters such as "%" as equivalent to "@". Here is _canonuser_internal from lib/canonusr.c in Cyrus SASL: static int _canonuser_internal(const sasl_utils_t *utils, const char *user, unsigned ulen, unsigned flags __attribute__((unused)), char *out_user, unsigned out_umax, unsigned *out_ulen) ... /* Need to append realm if necessary (see sasl.h) */ if(sconn && sconn->user_realm && !strchr(user, '@')) { u_apprealm = (unsigned) strlen(sconn->user_realm) + 1; } /* Now Copy */ memcpy(out_user, begin_u, MIN(ulen, out_umax)); if(sconn && u_apprealm) { if(ulen >= out_umax) return SASL_BUFOVER; out_user[ulen] = '@'; memcpy(&(out_user[ulen+1]), sconn->user_realm, MIN(u_apprealm-1, out_umax-ulen-1)); } out_user[MIN(ulen + u_apprealm,out_umax)] = '\0'; > >(2) Change the OpenLDAP behaviour so that it matches the documentation at > >http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > > >To do this, the canonicalize function would have to parse the username, > >splitting it on '@' to separate username from realm, so that you would get > > > > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > > > >If the username doesn't contain '@', but olcSaslRealm is set, then I suggest > >you insert that instead: > > > > uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth > > > >And if there's no '@' and no olcSaslRealm, then just leave it alone: > > > > uid=kurt,cn=gssapi,cn=auth > > This has been discussed at great length, read the -devel archives > from 9 or 10 years ago. The fact is that the SASL specification > doesn't reserve '@' as a special character and there is no guarantee > that this is actually a realm separator. There are plenty of > authentication mechanisms where '@' is an integral part of the > username. This suggestion simply won't fly. I suspect that's why canon_user was made pluggable in the first place; if you have your own idea of what constitutes a username with or without a realm then you code for it there. In Cyrus-SASL, plugins/gssapi.c has it hard-coded: if (strchr((char *) name_token.value, (int) '@') != NULL) { ... /* cut off string at '@' */ (strchr(name_without_realm.value,'@'))[0] = '\0'; I agree that non-Kerberos SASL mechanisms might have different username formats; and hence, without additional configuration, OpenLDAP cannot split arbitrary SASL usernames into uid=user,cn=realm. However the current behaviour of olcSaslRealm isn't useful either, since it just gives you uid=user[@realm],cn=olcSaslRealm. I think the most appropriate behaviour for olcSaslRealm would be for it to qualify usernames that don't contain '@' - and if your app doesn't use usernames with '@', then don't set olcSaslRealm. > I don't believe we have any freedom to make any code changes here; > feel free to suggest verbiage changes for the documentation. No problem. I propose the following to bring the docs in line with behaviour. --- sasl.sdf.orig 2011-01-03 09:45:55.754879001 +0000 +++ sasl.sdf 2011-01-03 10:07:34.808208000 +0000 @@ -135,25 +135,35 @@ For the purposes of authentication and authorization, {{slapd}}(8) associates an authentication request DN of the form: -> uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth +> uid=<primary[/instance][@realm]>,cn=gssapi,cn=auth + +The realm is omitted by Cyrus SASL if it's equal to the default realm of the +server in {{FILE:/etc/krb5.conf}}. Continuing our example, a user with the Kerberos principal {{EX:kurt@EXAMPLE.COM}} would have the associated DN: -> uid=kurt,cn=example.com,cn=gssapi,cn=auth +> uid=kurt,cn=gssapi,cn=auth and the principal {{EX:ursula/admin@FOREIGN.REALM}} would have the associated DN: -> uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth +> uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth -The authentication request DN can be used directly ACLs and +The authentication request DN can be used directly in ACLs and {{EX:groupOfNames}} "member" attributes, since it is of legitimate LDAP DN format. Or alternatively, the authentication DN could be mapped before use. See the section {{SECT:Mapping Authentication Identities}} for details. +If you configure olcSaslRealm then it is always inserted as an extra +component in the authorization DN, regardless of the realm of the client. +For example, if you set olcSaslRealm to {{EX:example.com}} then you will +get: + +> uid=kurt,cn=example.com,cn=gssapi,cn=auth +> uid=ursula/admin(a)foreign.realm,cn=example.com,cn=gssapi,cn=auth H3: KERBEROS_V4

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by hyc＠symas.com 02 Jan '11

02 Jan '11

Brian Candler wrote: > Now, if my understanding of the user_realm parameter is correct, I think > there are two ways to make OpenLDAP's behaviour consistent with its > documentation. > > (1) Stick more or less with the current behaviour, and change the > documentation to say that you'll get > uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > for foreign realms. > > However, the odd thing about the current behaviour is that setting > olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into > the auth DN, regardless of whether it's local or foreign. That's not very > useful. Note that it's not the OpenLDAP code that's sticking this in there; it's the Cyrus code that's returning this realm in the callback. IMO our job is to faithfully return what the Cyrus library gave us. > I think it would make more sense, if olcSaslRealm is present, to use it to > *qualify* usernames which don't have a realm. That decision is made by the Cyrus library, not us. > uid=kurt,cn=gssapi,cn=auth > ---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth > > i.e. change the canonicalize function to append @user_realm if the username > doesn't contain '@'. > > This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of > stripping off the default realm. > > (2) Change the OpenLDAP behaviour so that it matches the documentation at > http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > To do this, the canonicalize function would have to parse the username, > splitting it on '@' to separate username from realm, so that you would get > > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > > If the username doesn't contain '@', but olcSaslRealm is set, then I suggest > you insert that instead: > > uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth > > And if there's no '@' and no olcSaslRealm, then just leave it alone: > > uid=kurt,cn=gssapi,cn=auth This has been discussed at great length, read the -devel archives from 9 or 10 years ago. The fact is that the SASL specification doesn't reserve '@' as a special character and there is no guarantee that this is actually a realm separator. There are plenty of authentication mechanisms where '@' is an integral part of the username. This suggestion simply won't fly. I don't believe we have any freedom to make any code changes here; feel free to suggest verbiage changes for the documentation. -- -- 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#6766) memberOf does not replicate specially crafted modifications
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando If a modification deletes and recreates a member, something like dn: cn=group changetype: modify delete: member member: cn=user - add: member member: cn=user - the operation succeeds on the provider, but only the delete is replicated. This occurs because the operation, within the memberOf overlay, results in two separate operations: dn: cn=user changetype: modify delete: memberOf memberOf: cn=group dn: cn=user changetype: modify add: memberOf memberOf: cn=group with the same CSN, although corresponding to different operations, so the consumer ignores the second (btw, the CSN is the same of the modification that affects the "cn=group" entry). There may be two solutions: recognize that both operations affect the same entry, and group them, or change the CSN. p.

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 02 Jan '11

02 Jan '11

I've been doing some analysis of the Cyrus SASL code. When you say "we're using the parameters as documented by Cyrus", I presume the documentation you refer to is the comments within the source, in which case this all hinges on one line in include/sasl.h: * user_realm -- the user realm (may be NULL in case of client) (in the parameter list for the SASL_CB_CANON_USER callback). So what's meant by "the user realm"? When the callback is actually made (in lib/canonusr.c), the value passed is sconn->user_realm. This appears to be the value you get from sasl_getprop() with SASL_DEFUSERREALM. The user_realm value can be set in sasl_server_new (lib/server.c) and sasl_setprop (lib/common.c). There is a further description of realms in sasl/include.h: * IMPORTANT NOTE: server realms / username syntax * ... A single server may support multiple realms. If the * server knows the realm at connection creation time (e.g., a server * with multiple IP addresses tightly binds one address to a specific * realm) then that realm must be passed in the user_realm field of * the sasl_server_new call. If user_realm is non-empty and an * unqualified user name is supplied, then the canon_user facility is * expected to append "@" and user_realm to the user name. That is: it seems to me fairly clear that the purpose of user_realm is to provide a *default* realm which can be appended to the username when canonicalizing it. As a specific example, the code in _canonuser_internal() appends @<user_realm> if the username doesn't contain '@'. Furthermore, it's also clear from this that the username (SASL_USERNAME) is intended to include '@' and a realm; Cyrus is not designed to split it into a username part and a realm part. This matches what I see when using Cyrus SASL's standalone "sample-server" and "sample-client" programs, with GSSAPI and a client with a kerberos ticket from a different realm to the server: ... Negotiation complete Username: student(a)REALM3.WS.NSRC.ORG << sasl_getprop SASL_USERNAME Realm: (NULL) << sasl_getprop SASL_DEFUSERREALM SSF: 56 ... There's a full transcript of this example at http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2010-December/002177.html Next, looking at plugins/gssapi.c: AFAICS it doesn't make use of user_realm, but does ask GSSAPI if the name without realm is the same as the name with realm, and if so returns the name with the realm stripped off. /* If the id contains a realm get the identifier for the user without the realm and see if it's the same id (i.e. tmartin == tmartin(a)ANDREW.CMU.EDU. If this is the case we just want to return the id (i.e. just "tmartin" */ So, there is code in the GSSAPI plugin to *strip* the realm if it's the same as the default, but I don't think there's code to *separate* the username from the realm if the realm is foreign. Putting all this together: it seems to me that the "user_realm" you see is really just the configured default realm for the session; and that when you query SASL_USERNAME for a Kerberos client, you will see "username" if it's in the default realm, and "username(a)foreign.realm" for other realms. And this matches what I observe when testing this in OpenLDAP. As you suggested, I did bring this up on the cyrus-sasl mailing list (archive URL above), but no replies have been forthcoming so far. Now, if my understanding of the user_realm parameter is correct, I think there are two ways to make OpenLDAP's behaviour consistent with its documentation. (1) Stick more or less with the current behaviour, and change the documentation to say that you'll get uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth for foreign realms. However, the odd thing about the current behaviour is that setting olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into the auth DN, regardless of whether it's local or foreign. That's not very useful. I think it would make more sense, if olcSaslRealm is present, to use it to *qualify* usernames which don't have a realm. uid=kurt,cn=gssapi,cn=auth ---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth i.e. change the canonicalize function to append @user_realm if the username doesn't contain '@'. This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of stripping off the default realm. (2) Change the OpenLDAP behaviour so that it matches the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI To do this, the canonicalize function would have to parse the username, splitting it on '@' to separate username from realm, so that you would get uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth If the username doesn't contain '@', but olcSaslRealm is set, then I suggest you insert that instead: uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth And if there's no '@' and no olcSaslRealm, then just leave it alone: uid=kurt,cn=gssapi,cn=auth Regards, Brian.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2011