- openldap-bugs - openldap.org

Re: (ITS#7349) openldap not supporting CAMELLIA ciphers
by hyc＠symas.com 09 Aug '12

09 Aug '12

goodgoingswati(a)gmail.com wrote: > Full_Name: Swati > Version: 2.4.32 > OS: RHEL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.113.153.34) > > > openldap is not supporting CAMELLIA based ciphers(both RSA and DSA based) > I have configured SSL LDAP(LDAPS) and on checking SSL connection with LDAPS > server with CAMELLIA based cipher leads to failure in handshake: OpenLDAP doesn't implement any ciphers at all; the ciphers are provided by whichever TLS implementation you're using. Closing this ITS. > > openssl s_client -connect localhost:636 -showcerts -cipher > DHE-DSS-CAMELLIA256-SHA -state -CAfile /path_to_cert -cert /path_to_client_cert > -key /path_to_client_key > CONNECTED(00000003) > SSL_connect:before/connect initialization > SSL_connect:SSLv2/v3 write client hello A > SSL3 alert read:fatal:handshake failure > SSL_connect:error in SSLv2/v3 read server hello A > 47726707455072:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert > handshake failure:s23_clnt.c:741: > --- > no peer certificate available > --- > No client certificate CA names sent > --- > SSL handshake has read 7 bytes and written 102 bytes > --- > New, (NONE), Cipher is (NONE) > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > > Handshake is failing with all camellia ciphers. > > -- -- 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#7349) openldap not supporting CAMELLIA ciphers
by goodgoingswati＠gmail.com 09 Aug '12

09 Aug '12

Full_Name: Swati Version: 2.4.32 OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.113.153.34) openldap is not supporting CAMELLIA based ciphers(both RSA and DSA based) I have configured SSL LDAP(LDAPS) and on checking SSL connection with LDAPS server with CAMELLIA based cipher leads to failure in handshake: openssl s_client -connect localhost:636 -showcerts -cipher DHE-DSS-CAMELLIA256-SHA -state -CAfile /path_to_cert -cert /path_to_client_cert -key /path_to_client_key CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL3 alert read:fatal:handshake failure SSL_connect:error in SSLv2/v3 read server hello A 47726707455072:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:741: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 102 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE Handshake is failing with all camellia ciphers.

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 08 Aug '12

08 Aug '12

Applying the patch accessible here: ftp://ftp.openldap.org/incoming/Daniel-Pluta-120808.patch together with the acl set below obsoletes ITS#6900. In combination they enable the mode of operation we described in section VI, subsection G. of the previously linked paper. to dn.base="ou=groups,o=test" attrs=children by users write by * none to dn.one="ou=groups,o=test" attrs=owner by dnattr=owner write continue by dnattr=owner self-z by * none break to dn.one="ou=groups,o=test" attrs=entry,@groupOfNames by dnattr=owner write by * none The patch enables support to independently substract the privileges 'z' or 'a' from 'w', while 'a' or 'z' remain in the resulting bit mask. The other way around, adding 'a' or 'z' privs is also supported. Nevertheless, in the sense of the subject of this ITS the patch represents only a workaround. A clean solution (separating the 'a', 'z' and 'w' bitmasks) is of course preferable. LDIF test cases using ldapmodify command: ldapmodify -x -D "cn=000001,ou=persons,o=test" ... #create group entry (should fail) dn: cn=its7347-fail,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #create group entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test #add another owner (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: modify add: owner owner: cn=000002,ou=persons,o=test #delete the other owner (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: modify delete: owner owner: cn=000002,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete #restore the group (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete #again restore the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: add cn: its7347 objectClass: top objectClass: groupOfNames member: cn=000001,ou=persons,o=test owner: cn=000001,ou=persons,o=test owner: cn=000002,ou=persons,o=test #try to delete the owner (should fail) dn: cn=its7347-success,ou=groups,o=test changetype: modify delete: owner owner: cn=000001,ou=persons,o=test #delete the entry (should succeed) dn: cn=its7347-success,ou=groups,o=test changetype: delete

1 0

Re: (ITS#7348) enhancement: check_password contrib module
by Guillaume.Rousse＠inria.fr 07 Aug '12

07 Aug '12

Ceci est un message signC) cryptographiquement au format MIME. --------------ms000000000208070102090606 Content-Type: multipart/mixed; boundary="------------050908090805020607010105" This is a multi-part message in MIME format. --------------050908090805020607010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Here is the patch. --=20 Guillaume Rousse INRIA, Direction des syst=E8mes d'information Domaine de Voluceau Rocquencourt - BP 105 78153 Le Chesnay Tel: 01 39 63 58 31 --------------050908090805020607010105 Content-Type: text/x-patch; name="0001-ITS-7348-new-check_password-contrib-module.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0001-ITS-7348-new-check_password-contrib-module.patch" =46rom fa2f6730171ab5755f56ca66715b723df726026d Mon Sep 17 00:00:00 2001 From: Guillaume Rousse <guillomovitch(a)gmail.com> Date: Tue, 7 Aug 2012 17:39:21 +0200 Subject: [PATCH] ITS #7348: new check_password contrib module Signed-off-by: Guillaume Rousse <Guillame.Rousse(a)inria.fr> --- contrib/slapd-modules/README | 3 + contrib/slapd-modules/check-password/Makefile | 52 +++ contrib/slapd-modules/check-password/README | 146 +++++++++ .../slapd-modules/check-password/check_password.c | 356 +++++++++++++++= ++++++ 4 files changed, 557 insertions(+) create mode 100644 contrib/slapd-modules/check-password/Makefile create mode 100644 contrib/slapd-modules/check-password/README create mode 100644 contrib/slapd-modules/check-password/check_password.c= diff --git a/contrib/slapd-modules/README b/contrib/slapd-modules/README index db74379..d8005ff 100644 --- a/contrib/slapd-modules/README +++ b/contrib/slapd-modules/README @@ -20,6 +20,9 @@ allop (overlay) autogroup (overlay) Automated updates of group memberships. =20 +check_password (plugin) + External password quality check module for ppolicy + cloak (overlay) Hide specific attributes unless explicitely requested =20 diff --git a/contrib/slapd-modules/check-password/Makefile b/contrib/slap= d-modules/check-password/Makefile new file mode 100644 index 0000000..42dd18f --- /dev/null +++ b/contrib/slapd-modules/check-password/Makefile @@ -0,0 +1,52 @@ + +LDAP_SRC =3D ../../.. +LDAP_BUILD =3D ../../.. +LDAP_INC =3D -I$(LDAP_BUILD)/include -I$(LDAP_SRC)/include -I$(LDAP_SRC)= /servers/slapd +LDAP_LIB =3D $(LDAP_BUILD)/libraries/libldap_r/libldap_r.la \ + $(LDAP_BUILD)/libraries/liblber/liblber.la + +CRACKLIB_PATH =3D /usr/share/cracklib/pw_dict +CRACKLIB_INC =3D=20 +CRACKLIB_LIB =3D -lcrack + +CONFIG_PATH =3D /etc/openldap/check_password.conf + +LIBTOOL =3D $(LDAP_BUILD)/libtool +CC =3D gcc +OPT =3D -g -O2 -Wall +DEFS =3D -DHAVE_CRACKLIB -DCRACKLIB_DICTPATH=3D"\"$(CRACKLIB_PATH)\"" \ + -DCONFIG_FILE=3D"\"$(CONFIG_PATH)\"" -DDEBUG +INCS =3D $(LDAP_INC) $(CRACKLIB_INC) +LIBS =3D $(LDAP_LIB) $(CRACKLIB_LIB) + +PROGRAMS =3D check_password.la +LTVER =3D 0:0:0 + +prefix=3D/usr/local +exec_prefix=3D$(prefix) +ldap_subdir=3D/openldap + +libdir=3D$(exec_prefix)/lib +libexecdir=3D$(exec_prefix)/libexec +moduledir =3D $(libexecdir)$(ldap_subdir) + +.SUFFIXES: .c .o .lo + +.c.lo: + $(LIBTOOL) --mode=3Dcompile $(CC) $(OPT) $(DEFS) $(INCS) -c $< + +all: $(PROGRAMS) + +check_password.la: check_password.lo + $(LIBTOOL) --mode=3Dlink $(CC) $(OPT) -version-info $(LTVER) \ + -rpath $(moduledir) -module -o $@ $? $(LIBS) + +clean: + rm -rf *.o *.lo *.la .libs + +install: $(PROGRAMS) + mkdir -p $(DESTDIR)$(moduledir) + for p in $(PROGRAMS) ; do \ + $(LIBTOOL) --mode=3Dinstall cp $$p $(DESTDIR)$(moduledir) ; \ + done + diff --git a/contrib/slapd-modules/check-password/README b/contrib/slapd-= modules/check-password/README new file mode 100644 index 0000000..10191c2 --- /dev/null +++ b/contrib/slapd-modules/check-password/README @@ -0,0 +1,146 @@ + +check_password.c - OpenLDAP pwdChecker library + +2007-06-06 Michael Steinmann <msl(a)calivia.com> +2008-01-30 Pierre-Yves Bonnetain <py.bonnetain(a)ba-cst.com> +2009 Clement Oudot <clem.oudot(a)gmail.com> - LTB-project +2009 Jerome HUET - LTB-project + +check_password.c is an OpenLDAP pwdPolicyChecker module used to check th= e +strength and quality of user-provided passwords. + +This module is used as an extension of the OpenLDAP password policy cont= rols, +see slapo-ppolicy(5) section pwdCheckModule. + +check_password.c will run a number of checks on the passwords to ensure = minimum +strength and quality requirements are met. Passwords that do not meet th= ese +requirements are rejected. + + +Password checks +--------------- + - passwords shorter than 6 characters are rejected if cracklib is used = (because + cracklib WILL reject them). + + - syntactic checks controls how many different character classes are us= ed + (lower, upper, digit and punctuation characters). The minimum number = of + classes is defined in a configuration file. You can set the minimum f= or each + class. + + - passwords are checked against cracklib if cracklib is enabled at comp= ile + time. It can be disabled in configuration file. + +INSTALLATION +------------ +Use the provided Makefile to build the module. + +Compilation constants : + +CONFIG_FILE : Path to the configuration file.=20 + Defaults to /etc/openldap/check_password.conf + +DEBUG : If defined, check_password will syslog() its actions. + +Build dependencies +cracklib header files (link with -lcrack). The Makefile does not look fo= r +cracklib; you may need to provide the paths manually. + +Install into the slapd server module path. Change the installation +path to match with the OpenLDAP module path in the Makefile. + +The module may be defined with slapd.conf parameter "modulepath". + +USAGE +----- +To use this module you need to add objectClass pwdPolicyChecker with an = +attribute 'pwdCheckModule: check_password.so' to a password policy entry= =2E + +The module depends on a working cracklib installation including wordlist= files. +If the wordlist files are not readable, the cracklib check will be skipp= ed +silently. + +Note: pwdPolicyChecker modules are loaded on *every* password change ope= ration. + +Configuration +------------- +The configuration file (/etc/openldap/check_password.conf by default) co= ntains +parameters for the module. If the file is not found, parameters are give= n their +default value. + +The syntax of the file is : + +parameter value + +with spaces being delimiters. Parameter names ARE case sensitive (this m= ay +change in the future). + +Current parameters : + +- useCracklib: integer. Default value: 1. Set it to 0 to disable crackl= ib verification. + It has no effect if cracklib is not included at compile time. + +- minPoints: integer. Default value: 3. Minimum number of quality point= s a new + password must have to be accepted. One quality point is awarded for e= ach character + class used in the password. + +- minUpper: integer. Defaut value: 0. Minimum upper characters expected.= + +- minLower: integer. Defaut value: 0. Minimum lower characters expected.= + +- minDigit: integer. Defaut value: 0. Minimum digit characters expected.= + +- minPunct: integer. Defaut value: 0. Minimum punctuation characters exp= ected. + +Logs +---- +If a user password is rejected by an OpenLDAP pwdChecker module, the use= r will +*not* get a detailed error message, this is by design. + +Typical user message from ldappasswd(5): + Result: Constraint violation (19) + Additional info: Password fails quality checking policy + +A more detailed message is written to the server log. + +Server log: + check_password_quality: module error: (check_password.so) + Password for dn=3D".." does not pass required number of strength check= s (2 of 3) + + +Caveats +------- +Runtime errors with this module (such as cracklib configuration problems= ) may +bring down the slapd process. + +Use at your own risk. + + +TODO +---- +* use proper malloc function, see ITS#4998 + + +HISTORY +------- +* 2009-10-30 Clement OUDOT - LTB-project + Version 1.1 + - Apply patch from Jerome HUET for minUpper/minLower/minDigit/minPunc= t + +* 2009-02-05 Clement Oudot <clem.oudot(a)gmail.com> - LINAGORA Group + Version 1.0.3 + - Add useCracklib parameter in config file (with help of Pascal Pejac)= + - Prefix log messages with "check_password: " + - Log what character type is found for quality checking + +* 2008-01-31 Pierre-Yves Bonnetain <py.bonnetain(a)ba-cst.com> + Version 1.0.2 + - Several bug fixes. + - Add external config file + +* 2007-06-06 Michael Steinmann <msl(a)calivia.com> + Version 1.0.1 + - add dn to error messages + +* 2007-06-02 Michael Steinmann <msl(a)calivia.com> + Version 1.0 + diff --git a/contrib/slapd-modules/check-password/check_password.c b/cont= rib/slapd-modules/check-password/check_password.c new file mode 100644 index 0000000..da427e7 --- /dev/null +++ b/contrib/slapd-modules/check-password/check_password.c @@ -0,0 +1,356 @@ +/* + * check_password.c for OpenLDAP + * + * See LICENSE, README and INSTALL files + */ + +#include <string.h> +#include <ctype.h> +#include <portable.h> +#include <slap.h> + +#ifdef HAVE_CRACKLIB +#include "crack.h" +#endif + +#if defined(DEBUG) +#include <syslog.h> +#endif + +#ifndef CRACKLIB_DICTPATH +#define CRACKLIB_DICTPATH "/usr/share/cracklib/pw_dict" +#endif + +#ifndef CONFIG_FILE +#define CONFIG_FILE "/etc/openldap/check_password.conf" +#endif + +#define DEFAULT_QUALITY 3 +#define DEFAULT_CRACKLIB 1 +#define MEMORY_MARGIN 50 +#define MEM_INIT_SZ 64 +#define FILENAME_MAXLEN 512 + +#define PASSWORD_TOO_SHORT_SZ \ + "Password for dn=3D\"%s\" is too short (%d/6)" +#define PASSWORD_QUALITY_SZ \ + "Password for dn=3D\"%s\" does not pass required number of strength che= cks (%d of %d)" +#define BAD_PASSWORD_SZ \ + "Bad password for dn=3D\"%s\" because %s" + +typedef int (*validator) (char*); +static int read_config_file (char *); +static validator valid_word (char *); +static int set_quality (char *); +static int set_cracklib (char *); + +int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry); + +static int set_quality (char *value) +{ +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Setting quality to [%s]", value); +#endif + + /* No need to require more quality than we can check for. */ + if (!isdigit(*value) || (int) (value[0] - '0') > 4) return DEFAULT_QUAL= ITY; + return (int) (value[0] - '0'); + +} + +static int set_cracklib (char *value) +{ +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Setting cracklib usage to [%s]", va= lue); +#endif + + + return (int) (value[0] - '0'); + +} + +static int set_digit (char *value) +{ +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Setting parameter to [%s]", value);= +#endif + if (!isdigit(*value) || (int) (value[0] - '0') > 9) return 0; + return (int) (value[0] - '0'); +} + +static validator valid_word (char *word) +{ + struct { + char * parameter; + validator dealer; + } list[] =3D { { "minPoints", set_quality }, + { "useCracklib", set_cracklib }, + { "minUpper", set_digit }, + { "minLower", set_digit }, + { "minDigit", set_digit }, + { "minPunct", set_digit }, + { NULL, NULL } }; + int index =3D 0; + +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Validating parameter [%s]", word); +#endif + + while (list[index].parameter !=3D NULL) { + if (strlen(word) =3D=3D strlen(list[index].parameter) && + strcmp(list[index].parameter, word) =3D=3D 0) { +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Parameter accepted."); +#endif + return list[index].dealer; + } + index++; + } + +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Parameter rejected."); +#endif + + return NULL; +} + +static int read_config_file (char *keyWord) +{ + FILE * config; + char * line; + int returnValue =3D -1; + + if ((line =3D ber_memcalloc(260, sizeof(char))) =3D=3D NULL) { + return returnValue; + } + + if ( (config =3D fopen(CONFIG_FILE, "r")) =3D=3D NULL) { +#if defined(DEBUG) + syslog(LOG_ERR, "check_password: Opening file %s failed", CONFIG_FILE)= ; +#endif + + ber_memfree(line); + return returnValue; + } + + while (fgets(line, 256, config) !=3D NULL) { + char *start =3D line; + char *word, *value; + validator dealer; + +#if defined(DEBUG) + /* Debug traces to syslog. */ + syslog(LOG_NOTICE, "check_password: Got line |%s|", line); +#endif + + while (isspace(*start) && isascii(*start)) start++; + + if (! isascii(*start)) + continue; + + if ((word =3D strtok(start, " \t")) && (dealer =3D valid_word(word)) &= & (strcmp(keyWord,word)=3D=3D0)) { + if ((value =3D strtok(NULL, " \t")) =3D=3D NULL) + continue; + +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Word =3D %s, value =3D %s", word,= value); +#endif + + returnValue =3D (*dealer)(value); + } + } + + fclose(config); + ber_memfree(line); + return returnValue; +} + +static int realloc_error_message (char ** target, int curlen, int nextle= n) +{ + if (curlen < nextlen + MEMORY_MARGIN) { +#if defined(DEBUG) + syslog(LOG_WARNING, "check_password: Reallocating szErrStr from %d to = %d", + curlen, nextlen + MEMORY_MARGIN); +#endif + ber_memfree(*target); + curlen =3D nextlen + MEMORY_MARGIN; + *target =3D (char *) ber_memalloc(curlen); + } + + return curlen; +} + + int +check_password (char *pPasswd, char **ppErrStr, Entry *pEntry) +{ + + char *szErrStr =3D (char *) ber_memalloc(MEM_INIT_SZ); + int mem_len =3D MEM_INIT_SZ; + + int nLen; + int nLower =3D 0; + int nUpper =3D 0; + int nDigit =3D 0; + int nPunct =3D 0; + int minLower =3D 0; + int minUpper =3D 0; + int minDigit =3D 0; + int minPunct =3D 0; + int nQuality =3D 0; + int i; + + /* Set a sensible default to keep original behaviour. */ + int minQuality =3D DEFAULT_QUALITY; + int useCracklib =3D DEFAULT_CRACKLIB; + + /** bail out early as cracklib will reject passwords shorter + * than 6 characters + */ + + nLen =3D strlen (pPasswd); + if ( nLen < 6) { + mem_len =3D realloc_error_message(&szErrStr, mem_len, + strlen(PASSWORD_TOO_SHORT_SZ) + + strlen(pEntry->e_name.bv_val) + 1); + sprintf (szErrStr, PASSWORD_TOO_SHORT_SZ, pEntry->e_name.bv_val, nLen)= ; + goto fail; + } + + /* Read config file */ + minQuality =3D read_config_file("minPoints"); + + useCracklib =3D read_config_file("useCracklib"); + minUpper =3D read_config_file("minUpper"); + minLower =3D read_config_file("minLower"); + minDigit =3D read_config_file("minDigit"); + minPunct =3D read_config_file("minPunct"); + + /** The password must have at least minQuality strength points with one= + * point for the first occurrance of a lower, upper, digit and + * punctuation character + */ + + for ( i =3D 0; i < nLen; i++ ) { + + if ( nQuality >=3D minQuality ) break; + + if ( islower (pPasswd[i]) ) { + minLower--; + if ( !nLower && (minLower < 1)) { + nLower =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found lower character - quality = raise %d", nQuality); +#endif + } + continue; + } + + if ( isupper (pPasswd[i]) ) { + minUpper--; + if ( !nUpper && (minUpper < 1)) { + nUpper =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found upper character - quality = raise %d", nQuality); +#endif + } + continue; + } + + if ( isdigit (pPasswd[i]) ) { + minDigit--; + if ( !nDigit && (minDigit < 1)) { + nDigit =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found digit character - quality = raise %d", nQuality); +#endif + } + continue; + } + + if ( ispunct (pPasswd[i]) ) { + minPunct--; + if ( !nPunct && (minPunct < 1)) { + nPunct =3D 1; nQuality++; +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Found punctuation character - qu= ality raise %d", nQuality); +#endif + } + continue; + } + } + + if ( nQuality < minQuality ) { + mem_len =3D realloc_error_message(&szErrStr, mem_len, + strlen(PASSWORD_QUALITY_SZ) + + strlen(pEntry->e_name.bv_val) + 2); + sprintf (szErrStr, PASSWORD_QUALITY_SZ, pEntry->e_name.bv_val, + nQuality, minQuality); + goto fail; + } + +#ifdef HAVE_CRACKLIB + + /** Check password with cracklib */ + + if ( useCracklib > 0 ) { + int j =3D 0; + FILE* fp; + char filename[FILENAME_MAXLEN]; + char const* ext[] =3D { "hwm", "pwd", "pwi" }; + int nErr =3D 0; + + /** + * Silently fail when cracklib wordlist is not found + */ + + for ( j =3D 0; j < 3; j++ ) { + + snprintf (filename, FILENAME_MAXLEN - 1, "%s.%s", \ + CRACKLIB_DICTPATH, ext[j]); + + if (( fp =3D fopen ( filename, "r")) =3D=3D NULL ) { + + nErr =3D 1; + break; + + } else { + + fclose (fp); + + } + } + + char *r; + if ( nErr =3D=3D 0) { + + r =3D (char *) FascistCheck (pPasswd, CRACKLIB_DICTPATH); + if ( r !=3D NULL ) { + mem_len =3D realloc_error_message(&szErrStr, mem_len, + strlen(BAD_PASSWORD_SZ) + + strlen(pEntry->e_name.bv_val) + + strlen(r)); + sprintf (szErrStr, BAD_PASSWORD_SZ, pEntry->e_name.bv_val, r); + goto fail; + } + } + } + + else { +#if defined(DEBUG) + syslog(LOG_NOTICE, "check_password: Cracklib verification disabled by = configuration"); +#endif + } + +#endif + + *ppErrStr =3D strdup (""); + ber_memfree(szErrStr); + return (LDAP_SUCCESS); + +fail: + *ppErrStr =3D strdup (szErrStr); + ber_memfree(szErrStr); + return (EXIT_FAILURE); + +} + --=20 1.7.11.4 --------------050908090805020607010105-- --------------ms000000000208070102090606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Signature cryptographique S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN7jCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIElTCCA32gAwIBAgIQK7maWQuBMVtp KDwyDC57STANBgkqhkiG9w0BAQUFADA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5B MRswGQYDVQQDExJURVJFTkEgUGVyc29uYWwgQ0EwHhcNMTEwMTExMDAwMDAwWhcNMTQwMTEw MjM1OTU5WjBYMQswCQYDVQQGEwJGUjEOMAwGA1UEChMFSU5SSUExGTAXBgNVBAMTEEd1aWxs YXVtZSBST1VTU0UxHjAcBgkqhkiG9w0BCQIWD3JvdXNzZUBpbnJpYS5mcjCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANT2GRniP4zFepDfXQ9qHZCqmyGFsnxP1sAK5gRwh2xm 7EJgNSAlRVkmYdkrohltfjGJWvzmlIc8lgbzPSddeHhlc3SI8ZV3b9gWlyq3asH4oPJ3KuKh d8s2JLoll4pYRo+EqH/kLr8Tz3xfDEHtXNXiZ4QM6kniyLyk2QKc8UUsxd8f8gbiUW8yP2rB 9MgwbKYHn+EudkGbn+krQGbrBQRK83phYVGNnRy13mlu8Mb+9mmNCJq8cL6vhhIsGB4VRvhb k3pcZc2zFm9QJFziYLpdqINoh3vmSVHEVN0Oa3KecuXjiaboonCzXnxvdgLWQYAJNglpP7TV H4PTw+xXLZsCAwEAAaOCAXYwggFyMB8GA1UdIwQYMBaAFGNNQ1oZSD/ERsECur/uDuWCt2am MB0GA1UdDgQWBBRPxfiKCFknW2HnMSChZnApNelBwjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwGAYDVR0gBBEwDzANBgsr BgEEAbIxAQICHTA/BgNVHR8EODA2MDSgMqAwhi5odHRwOi8vY3JsLnRjcy50ZXJlbmEub3Jn L1RFUkVOQVBlcnNvbmFsQ0EuY3JsMHIGCCsGAQUFBwEBBGYwZDA6BggrBgEFBQcwAoYuaHR0 cDovL2NydC50Y3MudGVyZW5hLm9yZy9URVJFTkFQZXJzb25hbENBLmNydDAmBggrBgEFBQcw AYYaaHR0cDovL29jc3AudGNzLnRlcmVuYS5vcmcwJAYDVR0RBB0wG4EZR3VpbGxhdW1lLlJv dXNzZUBpbnJpYS5mcjANBgkqhkiG9w0BAQUFAAOCAQEAQi0EyaS/cO1avHkqFkOVhX5kuG3y kUlOIrzga2dnR2H7ylRILOTxBLweXL2DKJN+ZPJleLJSmdVcstq0GneSA7D1kJt0aPdMHqI6 8fMcppQer+N1V/9LYJWWRTV6RFrlSduzEU5tmdlG7QbYtvgNtvBliZL06AYPO54FDkHrhfnJ ldS55eeuAkwFrYkJP1Aa+zo/H2ytzVnIICtZMsZSa7Y2xo4j5Ykxd0HIsc48lmnkDnZ08+yf AOjJis2tc9eeBdcvQ/Pck+woIDeW9vnahCRcOOqCbmith0cqFvEm8cb1ajPIKmlUGBJi97Qh XJV8FZcuIK1Naelj/8MDbcd3ZzCCBMMwggOroAMCAQICEHP+V/rfuMUIgXtmuWvwLe8wDQYJ KoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2Fs dCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMY aHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDkwNTE4MDAwMDAwWhcNMjgxMjMxMjM1 OTU5WjA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEg UGVyc29uYWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIFdn1M2ojoZAN z7sFRMOrH0o1hRohhaBP+PBA4kpDm/5bsbC/tFfcdYBBS2Qa9ttPb4/QJUU1+erLSvr72tPt RYgRlDbkzKgN78U9N+0We+PClZ5YM38i+/j/7Oa+264KZSUih9pvhItG6ECGKD+/VgjiSumD ouki+y36tigfkcHDcftTwCtOpAyhbp1V7ezhJIc6COINHOTETdDLJ/qEZObRl51WJFuTuyku Q+JBaj3iSmX8ml9ahoe8h8d5gJaZUcaQD2SRmX0Q3awsAyrheGT+zj1O9CtQEUvRWNSbA/B/ 9TtTsFND+8UvxAQpGjqs11Xp0Q6V0Tsxf3hPriktAgMBAAGjggFNMIIBSTAfBgNVHSMEGDAW gBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQUY01DWhlIP8RGwQK6v+4O5YK3ZqYw DgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAwGAYDVR0gBBEwDzANBgsrBgEE AbIxAQICHTBYBgNVHR8EUTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBvBggrBgEFBQcB AQRjMGEwOAYIKwYBBQUHMAKGLGh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BQUFDbGll bnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1c3QuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQAGK6lTLxPcXDkWzIafXkx7cvvsjVWKXpoK/1NMdvQGPVDPV/Ciz6+Z jKr+oBl2PpkDMvp1gziKu2uapQwTstQbduaULmeYWeORbAKQmpzIYEtVq8qIWo0r5WmVAwfR 1A78JCIuWbFjpF/t2SNy5JzOOlxsH0+pAMkd/vp/RS22LoTdDyegWRhO1XYlRfSZJnnbb58j 90O7Kw8Eo4EmLLd7Nfk9d19AIeZ/HaWWWr3QyxY6bLthi4r9BDlECsss4cvOLhCYGtvgk+1J ZGQIIJ+3o1Dwot3KtMZ8DD3nXhXcJ4bkOjtSWherqQZTK50Jc2QcAcP9MNKHA2/kFQN6OV9o MYIDBzCCAwMCAQEwTzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQD ExJURVJFTkEgUGVyc29uYWwgQ0ECECu5mlkLgTFbaSg8Mgwue0kwCQYFKw4DAhoFAKCCAY0w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODA3MTU1NzI1 WjAjBgkqhkiG9w0BCQQxFgQUQ1jLCcKguMOiIFP7wDC8SLbfFfYwXgYJKwYBBAGCNxAEMVEw TzA7MQswCQYDVQQGEwJOTDEPMA0GA1UEChMGVEVSRU5BMRswGQYDVQQDExJURVJFTkEgUGVy c29uYWwgQ0ECECu5mlkLgTFbaSg8Mgwue0kwYAYLKoZIhvcNAQkQAgsxUaBPMDsxCzAJBgNV BAYTAk5MMQ8wDQYDVQQKEwZURVJFTkExGzAZBgNVBAMTElRFUkVOQSBQZXJzb25hbCBDQQIQ K7maWQuBMVtpKDwyDC57STBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBANISMWbCVg4clpyyoU7WyOoP ENBalFbEzAbA7iBn6edoAEV8jgj41VcGlNsevz8kQrb59GzkjOqMXsIwHTsGvjky738QcFPu uXyb8ZY+ExFOhgscUVlQ924+idn6xPMstKuM/cPKrknqdrRsS6igOTMVhKjI0s0MX2vsSA8/ FLd48o7B8XE5vWCXpJKExRgZvJdbzxrY3fSFugo3/jrCPz62mquY9u4U55nspkADfd6Ws86J tzVhlZzAM+CGmBvXETbPOJpP6HV2ORAXhxSX/x2Rn07Rm8kShMVUSeSpg2cH5MiyAXNFwfix kZDykKSrudGq7u+YrAC/Q6isV4ohEZMAAAAAAAA= --------------ms000000000208070102090606--

1 0

(ITS#7348) enhancement: check_password contrib module
by Guillaume.Rousse＠inria.fr 07 Aug '12

07 Aug '12

Full_Name: Guillaume Rousse Version: current git HEAD OS: URL: Submission from: (NULL) (128.93.30.10) The attached patch provides an external password checker module for ppolicy. It was originally created by Michael Steinmann <msl(a)calivia.com>, then maintained by Clement Oudot <clem.oudot(a)gmail.com> as part of the LTP project (http://ltb-project.org/wiki/documentation/openldap-ppolicy-check-password). Integrating it directly as an openldap official contrib module would help its usage, as it relies on private OpenLDAP APIs. See README file for detailed history and copyrights.

1 0

Re: (ITS#6900) dnattr acl statement: users can produce dangling entries
by daniel＠pluta.biz 07 Aug '12

07 Aug '12

This ITS can be closed. See ITS#7347 instead, currently located http://www.openldap.org/its/index.cgi/Incoming?id=7347;selectid=7347#follow…

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 07 Aug '12

07 Aug '12

I've uploaded a quick workaround to check the above acl, it can be downloaded from here: ftp://ftp.openldap.org/incoming/its7347.patch => Test result: It works for me. In the sense of the ITS title it's just a half-way workaround: It addresses only subtractive ACLs, additive ACLs are not addressed. A clean solution, separating the bitmasks is of course preferable. In my opinion ITS#6900 should be closed.

1 0

Re: (ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by Kurt＠OpenLDAP.org 06 Aug '12

06 Aug '12

On Aug 6, 2012, at 1:55 PM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) > > > The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 > paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, > Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very > useful in our opinion. > > We (Peter an me) have discussed the idea behind this enhancement together with > Howard during dinner the day before the LDAPCon2011 officially started. We > described the enhancement as some kind of > "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". > > Until today ITS#6900 contains a prototypical patch (very dirty hack), to > demonstrate the described enhancement's mode of operation. > > The good news: > Probably this hack isn't needed anymore in the future and thus ITS#6900 could be > closed, but just in case ... > > The bad news: > ... another (hopefully) less intrusive and generally useful patch, that seems to > be implementable without introducing new keywords can be realized instead: > > In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt > explained that the acl privilege levels "a" and "z" share one bit with the "w" > privilege's bit set. Thus currently neither "a" nor "z" can be independently > substracted from "w" in the way either "z" or "a" remains in the privilege set. > Subtracting "a" or "z" results in removing the complete "w" privilege (including > "a" and "z"). Looking back at the devel discussion about the introduction of a/z privs (April 2005), there seems to have been no consideration of subtractive access controls. That is, I think the we all just missed the a/z feature was not implemented in a manner which supported subtractive access controls. Or, more simply put, whoops. Using qualifiers was the mistake. Just should of replaced one bit with 2 bits, with some operations requesting one or the other or both bits. > In case the bit masks of the privileges "a", "z", and "w" can be separated > (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the > following acl set offers the above described mode of operation (out-of-the-box > without the need to apply the hack submitted with ITS#6900): > > {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none > {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue > by dnattr=modifiersName -z by * none > {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write > by * none > > I've not been able to test this acls yet (due to no available hack/patch). At > least in theory it should represent the mentioned enhancement's mode of > operation: > The owner attribute can be modified (add and delete) by any owner, but no owner > can remove himself from the owner attribute to either repudiate his personal > responsibility for an entry or to produce a dangling entry (an administrator > needs to clean up), in case it's the last owner. I'd have to think a bit harder whether the access controls above implement this properly, but I am sure {1} can be written using non-substractive ACLs. Off hand, probably requiring two to do it. > Herewith, the request for a more detailed description of a usecase where > substractive privileges are of general use should be answered. The general use case of additive and subtractive ACL is that it sometimes makes ACLs shorter. > Additionally I > also thought about the statement, that "good ACLs" are either static or > additive: I think I used the word "should", as in subtractive ACLs should be avoided. There are likely cases where their use can be well justified, just like default grant rules can sometimes be well justified. However, many security experts advise use of explicit grants (=) or additive (+) grants. I generally concur with this advice. > I have not been able to find a static or additive ACL solution to > implement the above described functionality in a similar elegant way (e.g. > without administratively maintained group patterns) > > Alternative 1: (elegant static/additive ACL) > There possibly exists a solution to express the above described mode of > operation already nowadays by using static and additive acls only, if so, I > appreciate any advice. > > Alternative 2: (coding the bitmask-separation) > I have no clue how(h)ard ;-) it is to implement (especially test) a successfull > separation of these bit masks. It was mentioned that the incremental processing > of privileges has been added later and the underlying design could be > suboptimal. Currently I don't know which pitfalls to be aware of (especially in > and around acl.c). Nevertheless and depending on the answer to alternative 1, > I'm interessted to give it a try, thus any thoughts and hints are very welcome, > too. The latter should be the preferred approach, IMO. The question I would have is wether an implementation of such would have any negative impact upon deployments. That's a real hard one to access, as deployments do some pretty crazy things. In short, it comes does to whether anyone does =w continue followed by -a or -z and expecting the outcome not to z or a respectively. -- Kurt > > Thanks a lot! >

1 0

(ITS#7347) Exclusive bit masks for: ACL_WADD, ACL_WDEL, and ACL_WRITE
by daniel＠pluta.biz 06 Aug '12

06 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff03:e455:e36f:5b06:b2f1) The "Enhancement for dnattr=... ACL" we've described within the LDAPcon2011 paper (http://www.daasi.de/ldapcon2011/downloads/plutahommelweinert-paper.pdf, Chapter VI, Section G., pdf page 7, left column bottom) seems to be still very useful in our opinion. We (Peter an me) have discussed the idea behind this enhancement together with Howard during dinner the day before the LDAPCon2011 officially started. We described the enhancement as some kind of "dnattr-based-administrator-less-2-way-handshake-entry-responsibility(-owner)-transition". Until today ITS#6900 contains a prototypical patch (very dirty hack), to demonstrate the described enhancement's mode of operation. The good news: Probably this hack isn't needed anymore in the future and thus ITS#6900 could be closed, but just in case ... The bad news: ... another (hopefully) less intrusive and generally useful patch, that seems to be implementable without introducing new keywords can be realized instead: In http://www.openldap.org/lists/openldap-technical/201208/msg00040.html Kurt explained that the acl privilege levels "a" and "z" share one bit with the "w" privilege's bit set. Thus currently neither "a" nor "z" can be independently substracted from "w" in the way either "z" or "a" remains in the privilege set. Subtracting "a" or "z" results in removing the complete "w" privilege (including "a" and "z"). In case the bit masks of the privileges "a", "z", and "w" can be separated (introducing exclusive masks for ACL_WADD, ACL_WDEL and ACL_WRITE), the following acl set offers the above described mode of operation (out-of-the-box without the need to apply the hack submitted with ITS#6900): {0}to dn.base="ou=groups,o=iacm" attrs=children by users write by * none {1}to dn.one="ou=groups,o=iacm" attrs=owner by dnattr=owner =dxcsraz continue by dnattr=modifiersName -z by * none {2}to dn.one="ou=groups,o=iacm" attrs=entry,@groupOfNames by dnattr=owner write by * none I've not been able to test this acls yet (due to no available hack/patch). At least in theory it should represent the mentioned enhancement's mode of operation: The owner attribute can be modified (add and delete) by any owner, but no owner can remove himself from the owner attribute to either repudiate his personal responsibility for an entry or to produce a dangling entry (an administrator needs to clean up), in case it's the last owner. Herewith, the request for a more detailed description of a usecase where substractive privileges are of general use should be answered. Additionally I also thought about the statement, that "good ACLs" are either static or additive: I have not been able to find a static or additive ACL solution to implement the above described functionality in a similar elegant way (e.g. without administratively maintained group patterns). Alternative 1: (elegant static/additive ACL) There possibly exists a solution to express the above described mode of operation already nowadays by using static and additive acls only, if so, I appreciate any advice. Alternative 2: (coding the bitmask-separation) I have no clue how(h)ard ;-) it is to implement (especially test) a successfull separation of these bit masks. It was mentioned that the incremental processing of privileges has been added later and the underlying design could be suboptimal. Currently I don't know which pitfalls to be aware of (especially in and around acl.c). Nevertheless and depending on the answer to alternative 1, I'm interessted to give it a try, thus any thoughts and hints are very welcome, too. Thanks a lot!

1 0

Re: (ITS#7346) ACL processing: additive privs (using control continue)
by hyc＠symas.com 05 Aug '12

05 Aug '12

daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: MASTER > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.167.55.212) > > > For further explainations please vistit this technical-posting: > > http://www.openldap.org/lists/openldap-technical/201208/msg00025.html > > Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given > below. As noted in the referenced email thread, this is working as designed. "continue" controls are only useful when a following clause matches the same subject and specifies incremental privileges. There are no following clauses that match the subject in this case, so the implicit "by * none" at the end of every ACL clause is applied. Closing this ITS. -- -- 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#7346) ACL processing: additive privs (using control continue)
by daniel＠pluta.biz 04 Aug '12

04 Aug '12

Full_Name: Daniel Pluta Version: MASTER OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.167.55.212) For further explainations please vistit this technical-posting: http://www.openldap.org/lists/openldap-technical/201208/msg00025.html Testbed containing slapd.conf, data, ldapsearch-queries and 128-logs are given below. Thanks a lot ------8<--------- slapd.conf --------8<--------- include /opt/openldap-HEAD/etc/openldap/schema/core.schema pidfile /opt/openldap-HEAD/var/run/slapd.pid argsfile /opt/openldap-HEAD/var/run/slapd.args access to * by self write by users read by anonymous auth database mdb suffix "o=test" rootdn "cn=Manager,o=test" rootpw secret directory /opt/openldap-HEAD/var/openldap-data/test index objectClass eq access to dn.subtree="o=test" attrs=sn by users =s continue by group/groupOfNames/member="cn=readers,ou=groups,o=test" +r ------8<--------- sample data --------8<--------- version: 1 dn: o=test objectClass: organization objectClass: top o: test dn: ou=groups,o=test objectClass: organizationalUnit objectClass: top ou: groups dn: ou=persons,o=test objectClass: organizationalUnit objectClass: top ou: persons dn: cn=PersonA,ou=persons,o=test objectClass: person objectClass: top cn: PersonA sn: PersonA userPassword:: UGVyc29uQQ== dn: cn=PersonB,ou=persons,o=test objectClass: person objectClass: top cn: PersonB sn: PersonB userPassword:: UGVyc29uQg== dn: cn=readers,ou=groups,o=test objectClass: groupOfNames objectClass: top cn: readers member: cn=PersonA,ou=persons,o=test ------8<---------Tests using ldapsearch--------8<--------- #Test 1 seem to work as intended: # bindDn "cn=PersonA,..." is member of group "cn=readers,..." # filter: sn=* # search succeeds (that's ok) # read succeeds (that's ok, too) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonA,ou=persons,o=test" -w PersonA -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # PersonA, persons, test dn: cn=PersonA,ou=persons,o=test sn: PersonA cn: PersonA # PersonB, persons, test dn: cn=PersonB,ou=persons,o=test cn: PersonB sn: PersonB # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 #slapd's log (level 128): 501be157 => access_allowed: result not in cache (userPassword) 501be157 => access_allowed: auth access to "cn=PersonA,ou=persons,o=test" "userPassword" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr userPassword 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "userPassword" requested 501be157 => acl_mask: to value by "", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= check a_dn_pat: anonymous 501be157 <= acl_mask: [3] applying auth(=xd) (stop) 501be157 <= acl_mask: [3] mask: auth(=xd) 501be157 => slap_access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: auth access granted by auth(=xd) 501be157 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access granted by read(=rscxd) 501be157 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonA,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= acl_mask: [1] applying write(=wrscxd) (stop) 501be157 <= acl_mask: [1] mask: write(=wrscxd) 501be157 => slap_access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: read access granted by write(=wrscxd) 501be157 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: search access granted by =rs 501be157 => access_allowed: search access granted by =rs 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "entry" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr entry 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "entry" requested 501be157 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (cn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "cn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [2] attr cn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "cn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: self 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [2] applying read(=rscxd) (stop) 501be157 <= acl_mask: [2] mask: read(=rscxd) 501be157 => slap_access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: read access granted by read(=rscxd) 501be157 => access_allowed: result not in cache (sn) 501be157 => access_allowed: read access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be157 => dn: [1] o=test 501be157 => acl_get: [1] matched 501be157 => acl_get: [1] attr sn 501be157 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be157 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 501be157 <= check a_dn_pat: users 501be157 <= acl_mask: [1] applying =s (continue) 501be157 <= acl_mask: [1] mask: =s 501be157 <= check a_group_pat: cn=readers,ou=groups,o=test 501be157 <= acl_mask: [2] applying +r (stop) 501be157 <= acl_mask: [2] mask: =rs 501be157 => slap_access_allowed: read access granted by =rs 501be157 => access_allowed: read access granted by =rs #Test 2 does not seem to work as intended (at least to me): # bindDn "cn=PersonB,..." not a member of group "cn=readers,..." # filter: sn=* # read fails (that's ok) # search fails (but why is the privilege "=s" reset?) deepee@test:~$ ldapsearch -x -H "ldap://localhost:1389/"; -D "cn=PersonB,ou=persons,o=test" -w PersonB -b "ou=persons,o=test" '(sn=*)' sn cn # extended LDIF # # LDAPv3 # base <ou=persons,o=test> with scope subtree # filter: (sn=*) # requesting: sn cn # # search result search: 2 result: 0 Success # numResponses: 1 #slapd's log (level 128): 501be196 => access_allowed: result not in cache (userPassword) 501be196 => access_allowed: auth access to "cn=PersonB,ou=persons,o=test" "userPassword" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr userPassword 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "userPassword" requested 501be196 => acl_mask: to value by "", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= check a_dn_pat: anonymous 501be196 <= acl_mask: [3] applying auth(=xd) (stop) 501be196 <= acl_mask: [3] mask: auth(=xd) 501be196 => slap_access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: auth access granted by auth(=xd) 501be196 => access_allowed: search access to "ou=persons,o=test" "entry" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [2] attr entry 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "entry" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: self 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [2] applying read(=rscxd) (stop) 501be196 <= acl_mask: [2] mask: read(=rscxd) 501be196 => slap_access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access granted by read(=rscxd) 501be196 => access_allowed: search access to "ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 => mdb_entry_get: found entry: "cn=readers,ou=groups,o=test" 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonA,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules 501be196 => access_allowed: search access to "cn=PersonB,ou=persons,o=test" "sn" requested 501be196 => dn: [1] o=test 501be196 => acl_get: [1] matched 501be196 => acl_get: [1] attr sn 501be196 => acl_mask: access to entry "cn=PersonB,ou=persons,o=test", attr "sn" requested 501be196 => acl_mask: to all values by "cn=personb,ou=persons,o=test", (=0) 501be196 <= check a_dn_pat: users 501be196 <= acl_mask: [1] applying =s (continue) 501be196 <= acl_mask: [1] mask: =s 501be196 <= check a_group_pat: cn=readers,ou=groups,o=test 501be196 <= acl_mask: no more <who> clauses, returning =0 (stop) 501be196 => slap_access_allowed: search access denied by =0 501be196 => access_allowed: no more rules

1 0

(ITS#7345) New Feature : Add Connection Information in Access Log Entries
by ldap＠htam.net 03 Aug '12

03 Aug '12

Full_Name: Mathieu MILLET Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/accesslog_addConnectionInformation.patch Submission from: (NULL) (82.67.21.31) Entries provided by the Access Log Overlay does not contain informations such as the IP Address of the client. This patch adds a simple attribute : reqConnInfo containing the content of o_conn->c_peer_name . Please review this patch because I'm not sure about what safety checks must be performed on these data before "merging" them. If this patch is accepted : I, Mathieu MILLET, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by hyc＠symas.com 02 Aug '12

02 Aug '12

Eric Clements wrote: > I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. If you have a working patch that behaves as you think it should, you're welcome to submit it. Unfortunately, the RFC is explicitly silent on how other identity formats are represented. I.e., it doesn't even specify that SASL identities (such as used in SASL Bind) are valid here. > Though your statement is true, many SASL methods do not use DNs either. I > do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. > > Thank you, > --------------------------- > Eric Clements > > On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > >> eclements(a)apple.com wrote: >>> Full_Name: Eric Clements >>> Version: 2.4.26 >>> OS: MacOS >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (17.193.15.131) >>> >>> >>> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >>> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. >> >> I'm not sure I understand why you've filed this ITS. The RFC doesn't specify >> that a server MUST support non-DN valued identities. It in fact says in Section 3: >> >> If the server does not recognize provided fields or does not support >> the combination of fields provided, it SHALL NOT change the user >> password. >> >> Clearly it is allowed for a server to reject identities if it doesn't >> recognize them. -- -- 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

Re: (ITS#7342) Password modify EXOP requires a DN
by eclements＠apple.com 02 Aug '12

02 Aug '12

I filed it in response to a posting I saw on AFP548 regarding OS X. Some users have patched OpenLDAP to work around the issue. Though your statement is true, many SASL methods do not use DNs either. I do not see why it is not allowed for passwordModify in the same way. If it behaves as designed then feel free to close. Thank you, --------------------------- Eric Clements On Aug 1, 2012, at 2:26 PM, Howard Chu <hyc(a)symas.com> wrote: > eclements(a)apple.com wrote: >> Full_Name: Eric Clements >> Version: 2.4.26 >> OS: MacOS >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (17.193.15.131) >> >> >> RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify >> request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. > > I'm not sure I understand why you've filed this ITS. The RFC doesn't specify > that a server MUST support non-DN valued identities. It in fact says in Section 3: > > If the server does not recognize provided fields or does not support > the combination of fields provided, it SHALL NOT change the user > password. > > Clearly it is allowed for a server to reject identities if it doesn't > recognize them. > > -- > -- 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

Re: (ITS#7344) [PATCH] Add initial testsuit for slapo-constraint
by hyc＠symas.com 02 Aug '12

02 Aug '12

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: linux-fedora17 > URL: ftp://ftp.openldap.org/incoming/jsynacek-20120802-testsuit-slapo-constraint… > Submission from: (NULL) (209.132.186.34) > > > This patch adds an initial testsuit for slapo-constraint. Thanks, added to master. > > The attached file is derived from OpenLDAP Software. All of the modifications > to > OpenLDAP Software represented in the following patch(es) were developed by Red > Hat. Red Hat has not assigned rights and/or interest in this work to any party. > I, Jan Synacek am authorized by Red Hat, my employer, to release this work > under > the following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > -- -- 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#7344) [PATCH] Add initial testsuit for slapo-constraint
by jsynacek＠redhat.com 02 Aug '12

02 Aug '12

Full_Name: Jan Synacek Version: master OS: linux-fedora17 URL: ftp://ftp.openldap.org/incoming/jsynacek-20120802-testsuit-slapo-constraint… Submission from: (NULL) (209.132.186.34) This patch adds an initial testsuit for slapo-constraint. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Synacek am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#7342) Password modify EXOP requires a DN
by hyc＠symas.com 01 Aug '12

01 Aug '12

eclements(a)apple.com wrote: > Full_Name: Eric Clements > Version: 2.4.26 > OS: MacOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (17.193.15.131) > > > RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify > request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN. I'm not sure I understand why you've filed this ITS. The RFC doesn't specify that a server MUST support non-DN valued identities. It in fact says in Section 3: If the server does not recognize provided fields or does not support the combination of fields provided, it SHALL NOT change the user password. Clearly it is allowed for a server to reject identities if it doesn't recognize them. -- -- 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#7343) dynlist overlay does not include attributes of an entry containing objectClass of the dynlist attrset
by openldap＠stormcloud9.net 01 Aug '12

01 Aug '12

Full_Name: Patrick Hemmer Version: 2.4.31 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (98.211.220.204) The issue is that if the entry being dynamically added to the parent entry has the objectClass slapo-dynlist is configured to use (to determine expansion), that entry is not dynamically added to the parent. For example: ---- dn: olcOverlay={4}dynlist,olcDatabase={3}hdb,cn=config objectClass: olcDynamicList objectClass: olcOverlayConfig olcOverlay: {4}dynlist olcDlAttrSet: {0}labeledURIObject labeledURI ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) dn: cn=child,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject member: uid=bar,dc=example,dc=com cn: child ---- In the above example, I would expect "member: uid=bar,dc=example,dc=com" to be added to cn=parent,dc=example,dc=com, but it isn't. Now the documentation clearly states recursion is not allowed, so if cn=child were to have a 'labeledURI', this labeledURI would not be expanded. But this is not what is being done here, cn=child has no labeledURI present. It also behaves perfectly fine if I pull the "objetClass: labeledURIObject" off cn=child. ldapsearch with objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent member: uid=foo,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ---- ldapsearch without objectClass labeledURIObject present on cn=child: ---- dn: cn=parent,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: labeledURIObject cn: parent cn: child member: uid=foo,dc=example,dc=com member: uid=bar,dc=example,dc=com labeledURI: ldap:///cn=child,dc=example,dc=com??base?(objectClass=*) ----

1 0

(ITS#7342) Password modify EXOP requires a DN
by eclements＠apple.com 31 Jul '12

31 Jul '12

Full_Name: Eric Clements Version: 2.4.26 OS: MacOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (17.193.15.131) RFC 3062 Section 2.1 (authored by OpenLDAP) states that a password modify request may or may not be an LDAP DN, yet OpenLDAP backend requires a DN.

1 0

Re: (ITS#7340) Regression in slapo-constraint
by jsynacek＠redhat.com 31 Jul '12

31 Jul '12

On 07/30/2012 08:38 PM, Michael Ströder wrote: > Jan Synacek wrote: >> On 07/27/2012 10:47 PM, michael(a)stroeder.com wrote: >>> It seems there's a regression in slapo-constraint possibly caused by a patch for >>> ITS#7168. >> >> This works for me: >> >> slapd.ldif: >> ... >> dn: olcOverlay=constraint,olcDatabase={1}bdb,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcConstraintConfig >> olcOverlay: constraint >> olcConstraintAttribute: mail count 3 >> olcConstraintAttribute: description count 2 >> ... > > From the excerpt above it seems you've only added a count constraint. > > Please use more features of slapo-constraint for testing, e.g. regex- or > URL-based constraints. > > The patch for ITS#7168 broke all my customer setups since I'm slapo-constraint > quite heavily. > > Ciao, Michael. > I'm having hard time reproducing this. Still works for me. Please provide a minimal setup and an example that fails, so I can fix the patch. Thank you. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

Re: (ITS#7340) Regression in slapo-constraint
by michael＠stroeder.com 30 Jul '12

30 Jul '12

This is a cryptographically signed message in MIME format. --------------ms010302040303070900010905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jan Synacek wrote: > On 07/27/2012 10:47 PM, michael(a)stroeder.com wrote: >> It seems there's a regression in slapo-constraint possibly caused by a= patch for >> ITS#7168. >=20 > This works for me: >=20 > slapd.ldif: > ... > dn: olcOverlay=3Dconstraint,olcDatabase=3D{1}bdb,cn=3Dconfig > objectClass: olcOverlayConfig > objectClass: olcConstraintConfig > olcOverlay: constraint > olcConstraintAttribute: mail count 3 > olcConstraintAttribute: description count 2 > ... =46rom the excerpt above it seems you've only added a count constraint. Please use more features of slapo-constraint for testing, e.g. regex- or URL-based constraints. The patch for ITS#7168 broke all my customer setups since I'm slapo-const= raint quite heavily. Ciao, Michael. --------------ms010302040303070900010905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/ kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB 1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0 Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1 c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/ BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3 LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2 KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4 B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt 5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z 5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1 3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV 0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9 ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNzMwMTgzODQyWjAjBgkq hkiG9w0BCQQxFgQUbkqitqiUB3AUptpJBP8IZf85VpcwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE ggEANow9ad7A3wr3HYgEMXZdssyB+upyWbuJ5LwbagTwOvHqIIJRTaKTIEvnUk09t4Jm5EIn Z0Nx7RX/HhOSbK94k1azYSpfabscyEubVv5tmmIJLJ6uwGIk9+9tMr7D0sXj8AKxc5qb96sc 1Aj3NidCu5dE/qJhdiMK84FTAjqMbouQ0v+DaTuw8BDIjcQL7XNxyu536WAOB/5BGOtfms8e SXH2bvNfYbw25+HdC8OTibBoMJrFXZExyT6lpqjgPcSrcixF1bK/Y9w8kxgqq7keFAw3rcuK 7vXpYMYKdazQFhr6Z4XlvH8AOeSdpDgyy9u3miaV/f5p1TBPyQyMAlq9SgAAAAAAAA== --------------ms010302040303070900010905--

1 0

Re: (ITS#7340) Regression in slapo-constraint
by jsynacek＠redhat.com 30 Jul '12

30 Jul '12

On 07/27/2012 10:47 PM, michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 8a0ce24c5abaf687a41696d988f6a1330128368d > OS: > URL: > Submission from: (NULL) (79.227.171.183) > > > It seems there's a regression in slapo-constraint possibly caused by a patch for > ITS#7168. > > If the client sends valid data which not violates a constraint > CONSTRAINT_VIOLATION is returned: > > delete: departmentNumber > departmentNumber: old_number > - > add: departmentNumber > departmentNumber: new_number > - > > It seems turning off only the constraint for departmentNumber does not help. > Turning off all constraints makes it work. > This works for me: slapd.ldif: ... dn: olcOverlay=constraint,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcConstraintConfig olcOverlay: constraint olcConstraintAttribute: mail count 3 olcConstraintAttribute: description count 2 ... root.ldif: dn: dc=my-domain,dc=com objectclass: dcObject objectclass: organization dc: my-domain o: My Domain corp. user.ldif: dn: cn=usr2,dc=my-domain,dc=com objectclass: inetOrgPerson objectclass: organizationalPerson cn: usr2 sn: usr2 mail: original(a)email.com description: desc1 description: desc2 test.ldif: dn: cn=usr2,dc=my-domain,dc=com changetype: modify delete: description description: desc1 - add: description description: desc1-mod < operation is successful > Am I misunderstanding something? If it still doesn't work for you, please, provide more information including your configuration and an example that fails. -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat

1 0

(ITS#7341) Ordered list error in overlays.sdf and "attr" in access-control.sdf
by ghenry＠OpenLDAP.org 30 Jul '12

30 Jul '12

Full_Name: Gavin Henry Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Small typos in access-control.sdf overlays.sdf.

1 0

Re: (ITS#7168) [PATCH] Fix count constraint when using multiple modifications
by quanah＠zimbra.com 27 Jul '12

27 Jul '12

--On Tuesday, June 19, 2012 5:19 AM +0000 jsynacek(a)redhat.com wrote: > On 06/07/2012 03:00 PM, Howard Chu wrote: >> jsynacek(a)redhat.com wrote: >>> Full_Name: Jan Synacek >>> Version: 2.4.29 >>> OS: Fedora 16 >>> URL: >>> http://jsynacek.fedorapeople.org/openldap/jsynacek-20120216-constraint- >>> count.patch Submission from: (NULL) (209.132.186.34) >>> This patch is broken. See ITS#7340 and discussion on -technical. --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

(ITS#7340) Regression in slapo-constraint
by michael＠stroeder.com 27 Jul '12

27 Jul '12

Full_Name: Version: RE24 8a0ce24c5abaf687a41696d988f6a1330128368d OS: URL: Submission from: (NULL) (79.227.171.183) It seems there's a regression in slapo-constraint possibly caused by a patch for ITS#7168. If the client sends valid data which not violates a constraint CONSTRAINT_VIOLATION is returned: delete: departmentNumber departmentNumber: old_number - add: departmentNumber departmentNumber: new_number - It seems turning off only the constraint for departmentNumber does not help. Turning off all constraints makes it work.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs