openldap-devel March 2008

openldap-devel@openldap.org

17 participants
21 discussions

Re: commit: openldap-guide/admin access-control.sdf set-following-references.png set-memberUid.png set-recursivegroup.png Makefile aspell.en.pws master.sdf slapdconf2.sdf slapdconfig.sdf
by Pierangelo Masarati 14 Mar '08

14 Mar '08

ghenry(a)OpenLDAP.org wrote: > access-control.sdf NONE -> 1.1 I see an error here: > <access directive> ::= access to <what> > [by <who> [<access>] [<control>] ]+ > <what> ::= * | > [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>] If no [.<basic-style>] is given, the default is <DN>; this rule should look like > [dn[.<scope-style>]=<DN> | dn.regex=<regex>] and basic style be changed/removed accordingly. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 2

Re: commit: ldap/servers/slapd backend.c operation.c proto-slap.h
by Howard Chu 13 Mar '08

13 Mar '08

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > backend.c 1.394 -> 1.395 > operation.c 1.85 -> 1.86 > proto-slap.h 1.751 -> 1.752 > > Log Message: > ITS#5419 introduce OpExtra / op->o_extra to supersede op->o_private This code should probably use <ldap_queue.h> instead of the current approach. > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/backend.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/operation.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/proto-slap.h > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: commit: ldap/servers/slapd config.h
by Hallvard B Furuseth 12 Mar '08

12 Mar '08

> config.h 1.49 -> 1.50 > const strings This change needs "const char*" or "LDAP_CONST char*", I'm not sure which, in 1st arg to register_at() and register_oc(). -- Hallvard

1 0

Completed SASL canonicalization option patch
by Joel Johnson 11 Mar '08

11 Mar '08

Here is the completed version of the patch (against 2.4.8) I initially brought up a week or so ago. It makes the hostname canonicalization step for SASL optional, both via ldap.conf and commandline arguments for the client tools. I submit it for consideration into the mainline code, as I believe it would provide a great benefit to a number of users such as myself. I present the completed version after some of the comments on the initial snapshot. The majority of comments were, frankly, what I had expected - "fix the DNS, that's the real problem." I argue that such an approach is somewhat narrow. While undoubtedly a best practice, it is not always feasible. I'll share my thoughts and comments on some of the previous responses. I hope to get some good feedback and reconsideration of the knee-jerk reactions. SASL authentication is not strictly dependent on hostname canonicalization in any form. There are, however, certain common implementation schemes that do require a canonical hostname determination in order to function properly. This unfortunately seems to have led to an implicit edict that all DNS configurations must be perfectly compliant in order for OpenLDAP to be able to use SASL authentication. The emphasis is always to 'fix your DNS, then we'll talk', rather than relaxing the overly strict requirement of the canonicalization step - overly strict because it is *not* required from SASL itself, only from OpenLDAP's usage of SASL. There exist broken DNS setups for which a user/admin may not be in a position to remedy the errors. Sorry Howard, saying "just use static /etc/hosts files" or "run your own local authoritative DNS server" are not very viable options. On my home server I have a dynamic IP. When I get a new IP, the machine updates its own /etc/hosts file, and while it would be possible to push the value to others, there are synchronization issues, not the least of which is that the other machines are more than likely not powered on when the update occurs. Running my own DNS server works great when within that netwok, but what about the cases where I'm at work/school/friend/in-laws/wherever and would like to connect? Or when I give access to external users? They certainly aren't going to be using my DNS server as a first line source. Anyway, why should I need any of that additional overhead when alternative, perfectly viable solutions exist. What benefit does the hostname canonicalization procedure provide? In a nutshell, it is simply a method of determining the identity of the entity with whom I'm communicating. When done using DNS it certainly has known security issues, but aside from direct attacks is generally quite reliable if properly configured. I believe that this is why it's not atypical to say "fix your DNS" if something isn't working properly. But why must this be the only option? There are at least two other cases to consider: 1) there are cases where we may not really care one iota about server authentication, and 2) there are options other than DNS for providing, at the very least, the same level of confidence in the identity of the peer. As for the first case, it's not one I'm involved in nor all too familiar with, but it certainly doesn't stretch the imagination to think of a case where the data returned is self-validating or requires no validation. With regard to the second case, alternative host identification, I'm currently using TLS for this, requiring a minimal level of validation. Yes, you can shoot yourself in the foot on this too (no self-signed certs, minimally a cert signed by a self-signed "CA"), but it certainly provides an option where there otherwise might not be one (as in my case). RFC 4752 (SASL GSSAPI), Section 5 states: "When constructing the input_name_string, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service." I mentioned a similar quote from a less SASL-specific (more Kerberos-specific) RFC before. The emphasis of this statement is to not use improper directory services to perform canonicalization. However, this does *not* imply that canonicalization must be performed, rather it states that *if* the client decides to use it, then a trusted naming service should be used to perform it. RFC 4422 (SASL) makes this explicit and confirms that the canonicalization is at most optional for a client, directly stating that "there is no requirement that the authorization identity string be canonical" (Section 5). Having said all of that, it is also noteworthy to note that canonicalization will often be enforced server-side simply based on the authentication configuration. In the specific case of using Kerberos, if the service principal uses the canonical hostname, the client better be getting a ticket using the canonical hostname as well. As a wrap-up, DNS has issues - some technical and some non-technical. I'm not in anyway suggesting that a proper setup should not be pursued, if such an option is available. But the fact of the matter is that it is not always possible. In such situations, the OpenLDAP software should not overtly preclude the user from using it (or indirectly require large workarounds) to the greatest extent in any situation, even if the configuration of a certain system is not idyllic. A few (or more) thoughts for consideration - Thanks, Joel Johnson

2 1

Re: commit: ldap/libraries/libldap_r tpool.c
by Hallvard B Furuseth 09 Mar '08

09 Mar '08

hyc(a)OpenLDAP.org writes: > tpool.c 1.95 -> 1.96 > ITS#5407 more checks for pool pausing Needs clarification in this comment, at least: "/* See if a pause was requested; wait for it if so." What if more than one thread is waiting to pause? pool_pausecheck() lets through at least one, but not necessarily all. Sufficient for forward progress? Also a thread may request a pause just as pool_pausecheck() returns. With so much common code I'd make this and pool_pause() wrappers around handle_pause(tpool, always_pause), returning !always_pause if it paused. -- Hallvard

2 1

Multiple system-wide ldap.conf files
by Hallvard B Furuseth 07 Mar '08

07 Mar '08

I'd like to add support for multiple system-wide ldap.conf files. Our site needs one which comes with the LDAP package, and one which the host admin can create to override. One way would be to add this to include/ldap_defaults.h: /* Array initializer for system-wide LDAP configuration files. * The contents of late files override earlier ones. * Update the FILES section of doc/man/man5/ldap.conf.5 to match. */ #define LDAP_CONF_FILELIST { LDAP_CONF_FILE } after the line #define LDAP_CONF_FILE LDAP_SYSCONFDIR LDAP_DIRSEP "ldap.conf" Another way: An ldap.conf directive "tryinclude <filename>" so the package's ldap.conf can include the host-specific ldap.conf. Also allows a user's ldap.conf to include some package's ldap.conf, if needed. And it allows include-loops, so there should be a "max include depth" limit. Opinions? -- Hallvard

2 2

[Fwd: [x500standard] NP on Password Policy approved]
by Gavin Henry 06 Mar '08

06 Mar '08

I'm going to look myself, but was wondering if anyone was keeping track of this versus the OpenLDAP Password policy stuff? ---------------------------- Original Message ---------------------------- Subject: [x500standard] NP on Password Policy approved From: "Erik Andersen" <era(a)x500.eu> Date: Thu, March 6, 2008 1:48 pm To: "Directory list" <x500standard(a)freelists.org> "SG17-Q2" <tsg17q2(a)itu.int> Cc: "Jooran Lee" <jooran(a)kisi.or.kr> -------------------------------------------------------------------------- Hi Folks, The New Work Item on Password Policy has passed the ballot, although with some difficulties, but thanks to UK and Japan, we finally got 5 members to agree to participate in the work. It is worth noticing that China and Korea have agreed to contribute. We certainly welcome contributions and participation by these countries. Thanks a lot to the SC6 secretariat for its flexibility in carrying this through. The current Working Document and the Summary of Voting may be found on http://www.x500standard.com/index.php?n=Extension.Ballots#pwd. We will progress the document at our April meeting (see http://www.x500standard.com/index.php?n=Docs.Meetings). Please make your contributions!! Erik Andersen Andersen's L-Service Mobile: +45 20 97 14 90 e-mail: <mailto:era@x500.eu> era(a)x500.eu <http://www.x500.eu/> http://www.x500.eu <http://www.x500standard.com/> http://www.x500standard.com/

2 2

test046-dds and slapd-dds.conf
by Gavin Henry 06 Mar '08

06 Mar '08

Hi All, I'm just finishing docs for slapo-dds and I noticed that anything less than 1 minute for dds-interval is flagged up as being maybe too small. 5 seconds in test046-dds is OK to correctly tests its functionality I presume? I'm sure it is but just wanted to check to see if this should also be mentioned in the man page. Thanks.

1 0

Re: commit: ldap/include lber_pvt.h
by Hallvard B Furuseth 05 Mar '08

05 Mar '08

hyc(a)OpenLDAP.org writes: > lber_pvt.h 1.39 -> 1.40 > Silence BER_BVC warning > > -#define BER_BVC(s) { STRLENOF(s), (s) } > +#define BER_BVC(s) { STRLENOF(s), (char *)(s) } Is this a "cast away const"? It also removes warnings about genuine type errors. If it's just for a few cases, how about adding a BER_BVCC macro which takes a const char[] instead? Or if it's for C++, that can use const_cast<char *>(s). -- Hallvard

2 4

Make SASL hostname canonicalization optional (RFC on patch approach)
by Joel Johnson 04 Mar '08

04 Mar '08

I've been having issues with SASL and having the hostname canonicalized in two places, once in OpenLDAP's SASL code, and again in the SASL provider (GSSAPI) library. I'm able to disable the SASL mechanism step, but it is mandatory in current OpenLDAP code. I found discussion from a few months ago surrounding the submittal of a patch to disable hostname canonicalization [1]. The issue appeared to be settled with discussion of a single use case where the URI references a CNAME which redirects to one of several machines in a cluster, in which case the canonicalization needs to be done to relate to the actual machine connected to. I agree that in such a situation, the canonicalization is required. I have one of many imaginable use cases, however, where the canonicalization is strictly must *not* occur in order for proper function. Two cases that I have personally, I'm sure there are others that are similiar: 1) As an ISP service provider I may have several DNS service names that happen to be on the same server, yet I want to maintain separate identities to make the services nearly transparent to migrate to dedicated hardware in the future if the need arises. Suppose that I have directory.example.com and imap.example.com on the same box, whose hostname is lucy.example.com. I would have three A records (or one A record and two CNAMES) for the same box, but since I can only have one PTR record, 2) On my home network I wish to use OpenLDAP, but my local server is on a DSL connection and I have no control over the DNS PTR records, and as such the records are effectively meaningless to the operation of my system. I do impose the requirement of mandatory TLS (via security ssf=128) which in and of itself provides stonger server authentication than name canonicalization via reverse DNS. A deficiency of the previously patch [1] appears to be that the option is not configurable, so I have created a related patch [2] (currently against 2.4.8, not quite HEAD) to add a runtime configuration option to select whether or not the name canonicalization should be performed. It defaults to true, the current behavior. The patch is still in progress, but has the functionality and provides an illustration of my approach. The following are known issues that will be addressed: 1) The actual hostname we successfully connected to should be used instead of blindly using ldo_defludp->lud_host 2) There is as of yet no implementation for the ldap_{set,get}_option cases for the new options. I have a stub in ldap_int_set_sasl_option, but haven't pulled in the LDAP_INT_GLOBAL_OPT reference to get access to the boolean values. 3) As a result of 2, there is not a commandline option specified. I propose that this would be a very valuable option, especially since there are cases where name canonicalization is infeasible if not impossible, as well as the fact that combined with TLS stronger server authentication is available. To use GSSAPI with SASL, it should also be noted that the more recent Kerberos RFCs have specifically required that reverse DNS *not* be used [3]. I'm looking for comments on the viability of such a patch being included in the base software, as well as comments on the patch itself. Thanks, Joel Johnson [1] http://www.openldap.org/lists/openldap-devel/200710/msg00088.html [2] http://www.lixil.net/~mrjoel/contrib/openldap/sasl-canonicalization-configu… [3] RFC 4120 - "Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names"

4 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel March 2008