openldap-devel

openldap-devel@openldap.org

1416 discussions

liblber, sockbuf drivers
by Howard Chu 23 Dec '07

23 Dec '07

One of the things that often concerned me is that we have socket calls and references to errno in liblber, which is built as non-threaded code, but "errno" changes on many platforms in a threaded process. I was thinking that we should move the actual network I/O drivers out of liblber and into libldap, so that they'll be compiled correctly (with libldap_r) for their actual runtime environment. Not that I can point to any specific platform where this has been a problem. Just thinking out loud. -- -- 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

ldap_ntlm_bind patch from Evolution
by Russ Allbery 21 Dec '07

21 Dec '07

The Debian packaging of OpenLDAP has been carrying around the attached patch for many years now, and I'd really like to make it go away. Adding new functions to the exposed ABI of a library is really not kosher. However, it looks like Evolution really does use this patch for its Exchange addressbook feature, it falls back on doing simple binds with passwords without it, and it is apparently still a recommended patch. I'm attaching the patch as shipped with the evolution-exchange package, although the code that actually uses it is now in evolution-data-server. What should we do with this? Is what Evolution wants to do just broken? Obsolete in some way? Is there some other API that they could now use? I'm happy to file bugs against the corresponding Debian packages so that we can get rid of this patch, but I don't know what to tell them and don't even entirely understand what they're trying to accomplish. === begin quote of patch from evolution-exchange === (Note that this patch is not useful on its own... it just adds some hooks to work with the LDAP authentication process at a lower level than the API otherwise allows. The code that calls these hooks and actually drives the NTLM authentication process is in lib/e2k-global-catalog.c, and the code that actually implements the NTLM algorithms is in xntlm/.) This is a patch against OpenLDAP 2.2.6. Apply with -p0 --- include/ldap.h.orig 2004-01-01 13:16:28.000000000 -0500 +++ include/ldap.h 2004-07-14 11:58:49.000000000 -0400 @@ -1753,5 +1753,26 @@ LDAPControl **cctrls )); +/* + * hacks for NTLM + */ +#define LDAP_AUTH_NTLM_REQUEST ((ber_tag_t) 0x8aU) +#define LDAP_AUTH_NTLM_RESPONSE ((ber_tag_t) 0x8bU) +LDAP_F( int ) +ldap_ntlm_bind LDAP_P(( + LDAP *ld, + LDAP_CONST char *dn, + ber_tag_t tag, + struct berval *cred, + LDAPControl **sctrls, + LDAPControl **cctrls, + int *msgidp )); +LDAP_F( int ) +ldap_parse_ntlm_bind_result LDAP_P(( + LDAP *ld, + LDAPMessage *res, + struct berval *challenge)); + + LDAP_END_DECL #endif /* _LDAP_H */ --- libraries/libldap/Makefile.in.orig 2004-01-01 13:16:29.000000000 -0500 +++ libraries/libldap/Makefile.in 2004-07-14 13:37:23.000000000 -0400 @@ -20,7 +20,7 @@ SRCS = bind.c open.c result.c error.c compare.c search.c \ controls.c messages.c references.c extended.c cyrus.c \ modify.c add.c modrdn.c delete.c abandon.c \ - sasl.c sbind.c kbind.c unbind.c cancel.c \ + sasl.c ntlm.c sbind.c kbind.c unbind.c cancel.c \ filter.c free.c sort.c passwd.c whoami.c \ getdn.c getentry.c getattr.c getvalues.c addentry.c \ request.c os-ip.c url.c sortctrl.c vlvctrl.c \ @@ -29,7 +29,7 @@ OBJS = bind.lo open.lo result.lo error.lo compare.lo search.lo \ controls.lo messages.lo references.lo extended.lo cyrus.lo \ modify.lo add.lo modrdn.lo delete.lo abandon.lo \ - sasl.lo sbind.lo kbind.lo unbind.lo cancel.lo \ + sasl.lo ntlm.lo sbind.lo kbind.lo unbind.lo cancel.lo \ filter.lo free.lo sort.lo passwd.lo whoami.lo \ getdn.lo getentry.lo getattr.lo getvalues.lo addentry.lo \ request.lo os-ip.lo url.lo sortctrl.lo vlvctrl.lo \ --- /dev/null 2004-06-30 15:04:37.000000000 -0400 +++ libraries/libldap/ntlm.c 2004-07-14 13:44:18.000000000 -0400 @@ -0,0 +1,137 @@ +/* $OpenLDAP: pkg/ldap/libraries/libldap/ntlm.c,v 1.1.4.10 2002/01/04 20:38:21 kurt Exp $ */ +/* + * Copyright 1998-2002 The OpenLDAP Foundation, All Rights Reserved. + * COPYING RESTRICTIONS APPLY, see COPYRIGHT file + */ + +/* Mostly copied from sasl.c */ + +#include "portable.h" + +#include <stdlib.h> +#include <stdio.h> + +#include <ac/socket.h> +#include <ac/string.h> +#include <ac/time.h> +#include <ac/errno.h> + +#include "ldap-int.h" + +int +ldap_ntlm_bind( + LDAP *ld, + LDAP_CONST char *dn, + ber_tag_t tag, + struct berval *cred, + LDAPControl **sctrls, + LDAPControl **cctrls, + int *msgidp ) +{ + BerElement *ber; + int rc; + ber_int_t id; + + Debug( LDAP_DEBUG_TRACE, "ldap_ntlm_bind\n", 0, 0, 0 ); + + assert( ld != NULL ); + assert( LDAP_VALID( ld ) ); + assert( msgidp != NULL ); + + if( msgidp == NULL ) { + ld->ld_errno = LDAP_PARAM_ERROR; + return ld->ld_errno; + } + + /* create a message to send */ + if ( (ber = ldap_alloc_ber_with_options( ld )) == NULL ) { + ld->ld_errno = LDAP_NO_MEMORY; + return ld->ld_errno; + } + + assert( LBER_VALID( ber ) ); + + LDAP_NEXT_MSGID( ld, id ); + rc = ber_printf( ber, "{it{istON}" /*}*/, + id, LDAP_REQ_BIND, + ld->ld_version, dn, tag, + cred ); + + /* Put Server Controls */ + if( ldap_int_put_controls( ld, sctrls, ber ) != LDAP_SUCCESS ) { + ber_free( ber, 1 ); + return ld->ld_errno; + } + + if ( ber_printf( ber, /*{*/ "N}" ) == -1 ) { + ld->ld_errno = LDAP_ENCODING_ERROR; + ber_free( ber, 1 ); + return ld->ld_errno; + } + + /* send the message */ + *msgidp = ldap_send_initial_request( ld, LDAP_REQ_BIND, dn, ber, id ); + + if(*msgidp < 0) + return ld->ld_errno; + + return LDAP_SUCCESS; +} + +int +ldap_parse_ntlm_bind_result( + LDAP *ld, + LDAPMessage *res, + struct berval *challenge) +{ + ber_int_t errcode; + ber_tag_t tag; + BerElement *ber; + ber_len_t len; + + Debug( LDAP_DEBUG_TRACE, "ldap_parse_ntlm_bind_result\n", 0, 0, 0 ); + + assert( ld != NULL ); + assert( LDAP_VALID( ld ) ); + assert( res != NULL ); + + if ( ld == NULL || res == NULL ) { + return LDAP_PARAM_ERROR; + } + + if( res->lm_msgtype != LDAP_RES_BIND ) { + ld->ld_errno = LDAP_PARAM_ERROR; + return ld->ld_errno; + } + + if ( ld->ld_error ) { + LDAP_FREE( ld->ld_error ); + ld->ld_error = NULL; + } + if ( ld->ld_matched ) { + LDAP_FREE( ld->ld_matched ); + ld->ld_matched = NULL; + } + + /* parse results */ + + ber = ber_dup( res->lm_ber ); + + if( ber == NULL ) { + ld->ld_errno = LDAP_NO_MEMORY; + return ld->ld_errno; + } + + tag = ber_scanf( ber, "{ioa" /*}*/, + &errcode, challenge, &ld->ld_error ); + ber_free( ber, 0 ); + + if( tag == LBER_ERROR ) { + ld->ld_errno = LDAP_DECODING_ERROR; + return ld->ld_errno; + } + + ld->ld_errno = errcode; + + return( ld->ld_errno ); +} -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

3 4

Re: commit: ldap/doc/man/man5 slapd-bdb.5
by Howard Chu 17 Dec '07

17 Dec '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/doc/man/man5 > > Modified Files: > slapd-bdb.5 1.38 -> 1.39 > > Log Message: > Support DB encryption When this topic was first raised, I thought it was pretty useless: http://www.openldap.org/lists/openldap-software/200202/msg00232.html And in general, it's not even a necessary feature: http://www.openldap.org/lists/openldap-devel/200211/msg00045.html But it seems to be a checklist feature these days. It may actually provide some value to sites that do regular backups of their raw DB files. It may actually be useful in some cases where you provide an encryption key on separate removable media (e.g. a USB flash drive). It might actually prevent a news article down the road on how some organization lost their 5 million record customer database and now all that unprotected data is now being exploited by criminals. I doubt it, of course. It exacts a performance penalty on every DB operation, so I don't think anyone will be able to use this long-term. For the off-site backup scenario, it makes more sense to just encrypt the backup images (tar format or whatever backup utility is used). That way you only spend cycles on encryption once, at backup time. Any site that's savvy enough to do automated backups can certainly figure out how to protect those backups with encryption. But the question comes up from time to time, why we don't offer this feature in the DB itself, and sometimes it's easier to just say "ok" than try to educate people. (In fact we did a custom build of OpenLDAP for a bank a few years ago, that requested this feature from us. They didn't even care about the key management, the key was just a 96 character string hardcoded into the back-bdb patch. The current patch in CVS is obviously a little better than that.) So anyway, if you're wondering, no, I still think it's a dumb solution. It's here as a marketing gimmick, for feature list checkboxes, not for any technical merit. -- -- 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/

3 4

Re: commit: ldap/libraries/libldap url.c
by Hallvard B Furuseth 17 Dec '07

17 Dec '07

hyc(a)OpenLDAP.org writes: > url.c 1.104 -> 1.105 > Better fix to prev commit Actually the code was OK with not calling hex_escape_len() when there is a port number; it's only ldapi URLs which are escaped in desc2str(). Good call with IPv6 "[]" though. I guess it's time to walk through desc2str_len() and check that it matches desc2str(). -- Hallvard

1 0

Re: commit: ldap/libraries/libldap url.c
by Howard Chu 16 Dec '07

16 Dec '07

hallvard(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > url.c 1.103 -> 1.104 > > Log Message: > Declare enough buffer space for out-of-range URL port numbers It would have been better simply to never accept out-of-range port numbers. lud_port should have been an unsigned short instead of int. Or just test for the correct range on assignment and return an error as necessary. -- -- 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/

2 2

old bugs
by Howard Chu 15 Dec '07

15 Dec '07

ITS#4467 seems to have gone nowhere. Whether or not any patches have been committed for it isn't obvious because it hasn't been updated since it was submitted. There's no evidence that this ITS has any impact. Either it's been fixed, or it's not a problem. #4591 seems to have aged a bit too. Can we close these? -- -- 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/

2 2

RE23 testing
by Howard Chu 13 Dec '07

13 Dec '07

Now that 2.4.7 is released, please take a look at RE23. This should probably be the last 2.3 release. Thanks. -- -- 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/

2 1

New ACL Admin Guide Section
by Gavin Henry 13 Dec '07

13 Dec '07

Dear All, I'm going to pull the ACL stuff out of the config sections and have a dedicated chapter. Any objections? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

'countryName' in core.schema (was : (ITS#5236) core.ldif differs from core.schema)
by Michael Ströder 12 Dec '07

12 Dec '07

HI! following up on this because some older schema files reference 'countryName' (and worked with RE23). Howard Chu wrote: > I'm puzzled why RFC4519 drops the 'countryName' alias for this type > from the RFC2256 definition. Me too... How to deal with that (except changing the schema files of other vendors)? Ciao, Michael.

2 3

Issues with migration 2.3 to RE24 with slapcat/slapadd
by Michael Ströder 12 Dec '07

12 Dec '07

HI! When migrating data extracted from a 2.3.39 server via slapcat into a RE24 server I had two issues: 1. Option -q of slapadd resulted in a seg fault. 2. I had to remove the entryCSN attributes from the LDIF data. Probably this is somewhat related to the 2.3-2.4 replication issue. Ciao, Michael.

3 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel