openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

(ITS#6771) Feature request: support for RFC 3829 authzid control
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A simple module that implements RFC 3829 server-side is committed in contrib/slapd-modules/authzid; it only works for single-step bind. Extension to multi-step bind may not be trivial. p.

1 0

(ITS#6770) Proxy authorization fails with SASL-GSSAPI
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) Proxy authorization works with SIMPLE binds, as well as with SASL binds using various other mechanisms, but not with SASL and GSSAPI. In that case it may only work initially, but eventually the problem is that, for no apparent reason, the consumer instead attempts to use a SIMPLE bind to authenticate itself to the provider. Naturally, this fails. For detailed background and debugging info, see this thread: http://www.openldap.org/lists/openldap-technical/201101/msg00002.html

1 0

(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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs