Re: commit: ldap/servers/slapd config.h
by Hallvard B Furuseth
> 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
15 years
Completed SASL canonicalization option patch
by Joel Johnson
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
15 years
Re: commit: ldap/libraries/libldap_r tpool.c
by Hallvard B Furuseth
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
15 years
Multiple system-wide ldap.conf files
by Hallvard B Furuseth
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
15 years
[Fwd: [x500standard] NP on Password Policy approved]
by Gavin Henry
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/
15 years
test046-dds and slapd-dds.conf
by Gavin Henry
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.
15 years
Re: commit: ldap/include lber_pvt.h
by Hallvard B Furuseth
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
15 years
Make SASL hostname canonicalization optional (RFC on patch approach)
by Joel Johnson
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-confi...
[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"
15 years
