openldap-technical May 2017

openldap-technical@openldap.org

45 participants
79 discussions

Using of Collective attributes in 2.4.42
by Andrew Podko 19 May '17

19 May '17

Hello! I rebuilt the OpenLdap with -DLDAP_COLLECTIVE_ATTRIBUTES Added in slapd.conf include collective.schema moduleload collect overlay collect collectinfo cn=coll,dc=exadel,dc=com c-PhysicalDeliveryOfficeName,c-TelephoneNumber # also i tried with collectinfo cn=coll,dc=exadel,dc=com PhysicalDeliveryOfficeName,TelephoneNumber I created element: dn: cn=coll,dc=exadel,dc=com objectClass: subentry objectClass: extensibleObject objectClass: collectiveAttributeSubentry objectClass: top structuralObjectClass: subentry c-PhysicalDeliveryOfficeName: Test office c-TelephoneNumber: +8888888888 cn: coll subtreeSpecification: {base "ou=Test Group"} But when I query with ldapsearch, I don't see what users from ou=Test Group,dc=example,dc=com have attributes PhysicalDeliveryOfficeName, TelephoneNumber I can not understand what else needs to be done to make it work. Could you tell me what I missed? I checked it on versions 2.4.42 and 2.4.44. -- With Best Wishes Andrew Podko System Administrator Exadel apodko(a)exadel.com <mailto:apodko@exadel.com> -- CONFIDENTIALITY NOTICE: This email and files attached to it are confidential. If you are not the intended recipient you are hereby notified that using, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error please notify the sender and delete this email.

1 0

Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates
by Dameon Wagner 18 May '17

18 May '17

On Thu, May 18 2017 at 20:17:16 +0900, Alexandre Rosenberg scribbled in "Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates": > Hello, > > I test and the issue only happen if 2 CA have the same DN. > I regenerated the new CA with a different DN and it's working. > > As I am mentioned I am not sure what the proper behavior of > OpenLDAP/OpenSSL should be in case 2 CA have the same DN. > > I am not sure I misunderstanding what TLSCACertificateFile is used > for. The main use it to let OpenLDAP though which CA if should trust > when validating certificate. That is clearly what is in the doc. > > Best, > > Alex Hi Alex, Glad you got it working. I think the proper behaviour would be to not have 2 CAs with the same DN, as the first-match-wins. As the DN is used to identify the issuer of the certificate you're attempting to authenticate, it would make little sense to have a naming collision. I realise the docs say that order doesn't matter, but that assumes that all included certificates would have clearly distinguished subject names (hence "DN"). Cheers. Dameon. -- ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <>< Dr. Dameon Wagner, Systems Development and Support IT Services, University of Oxford ><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><

1 0

knowing which schema(s) to use
by Prentice Bisbal 17 May '17

17 May '17

Over the past few days or weeks, I've asked a number of questions related to schemas as I move my LDAP directory to a newer OS and newer version of OpenLDAP. As has happened in the past, I have run into schema issues when importing the database (LDIF file) into the new directory with slapadd. This time I got the following errors: 1. Kerberos attributes in "new" kerberos schema start with 'krb' instead of 'krb5' 2. I got a schema structural error because user accounts have both objectclasses "account" and "krbPrincipal", which is not good. 3. We were using solaris.schema on the old system, which CentOS 6 doesn't provide, but it does provide duaconf.schema, which seemed be be similar if not identical to solaris.schema. Both of these are easy to fix - just use sed to change 'krb5' to 'krb', and then change 'krbPrincipal' to 'krbPrincipalAux', but is this really the best/safest way to make these changes. Also, what happens to apps that are looking for the 'krb5' instead of 'krb' and vice-versa? I think many system admins would say just copy the schemas from the old server to the new server and forget about it, but I don't think this is a good approach. After doing that several times, I imagine the newer applications on the newer OS versions will be looking for different objectclass or attribute names (like krb instead of krb5), and things will eventually break, anyway. So my questions are this: 1. How do the rest of you handle situations like this? 2. Who/what is the authoritative source for current schema definitions? Are they all defined in RFCs? In an earlier e-mail, regarding my kerberos schema issues, Michael Ströder wrote > You should use the current schema file shipped with your particular Kerberos installation. That's exactly what I'm trying to do, which led to the kerberos schema issues. And in the past there have been times when the current version of the OS didn't provide the same schemas as the old version, and I was left searching the Internet to find the modern equivalent of the schema from the old system. -- Prentice

3 4

TLSCACertificateFile directive and multiple CA certificates
by Alexandre Rosenberg 17 May '17

17 May '17

Hello, Using multiple CA certificates with the TLSCACertificateFile directive is not working in my setup. The man page (1) clearly states that multiple certificates can be appended to the file. Only the first CA in the file appear to be used. I confirmed this by changing the order of the certificate in the file. I am using self-signed CA Certificate which is used for validating the provider server certificate during replication. I see this behaviour in both the latest OpenLDAP release and an older release. In both case I am using OpenSSL. I just realized one important point abound my setup: Both CA certificate have the same DN. Other that that they are completely different certificate (different key, expiry date). Both CA certificate are valid (not expired). I will test tomorrow if appending another CA certificate with a different CN makes a difference. I am wondering if some people are successfully using multiples certificates with the TLSCACertificateFile directive. Thanks. Best, Alex (1) http://www.openldap.org/software/man.cgi?query=slapd.conf

3 3

invalid structural object class chain (account/krbPrincipal)
by Prentice Bisbal 16 May '17

16 May '17

So with you help, I managed to fix my initial issues of adding some additional schemas to my system. Now, when I try to add the directory data from my old LDAP servers with slapcat, I'm getting the following structural error: (line=168): (65) invalid structural object class chain (account/krbPrincipal) The relevant portions for the offending dn look like this: objectClass: top objectClass: account objectClass: posixAccount objectClass: shadowAccount objectClass: krbPrincipal structuralObjectClass: account I should point out that I recently inherited this LDAP directory, and now I'm upgrading the LDAP servers to new hardware and a new OS with a much new version of OpenLDAP. I've never seen the stucturalObjectClass attribute before. From my experience, when you get errors like this, it's because either the schemas have changed, or someone used the -c switch when adding new entries to the directory. Usually it's the latter. I have googled my error and found many discussions for 'invalid structural object chain' on this list, but none of them seem to apply to this case. Most problem seemed be caused by having multiple conflicting STRUCTURAL object classes in one entry, but that doesn't seem to be the case since krbPrincipal is not STRUCTURAL. It's also not AUXILIARY: objectclass ( 2.16.840.1.113719.1.301.6.9.1 NAME 'krbPrincipal' SUP top MUST ( krbPrincipalName ) MAY ( krbObjectReferences ) ) account is STRUCTURAL: objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST userid MAY ( description $ seeAlso $ localityName $ organizationName $ organizationalUnitName $ host ) ) but posixAccount and shadowAccount are AUXILIARY : objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction of an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) objectclass ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount' DESC 'Additional attributes for shadow passwords' SUP top AUXILIARY MUST uid MAY ( userPassword $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $ description ) ) Any ideas for how to fix this? Could I just remove the account objectClass? I'm not sure whether or not we're using any of it's attributes. -- Prentice

2 3

Help with assertion control
by Sudhindra M R 16 May '17

16 May '17

Hi I am facing problem sending Assertion Control with LDAP DelRequest message. I am getting this error: 591950a9 begin get_filter 591950a9 conn=1004 op=1 DISCONNECT tag=120 err=2 text=error decoding filter 591950a9 conn=1004 op=1 DISCONNECT tag=120 err=2 text=error decoding filter 591950a9 conn=1004 op=1 do_delete: get_ctrls failed My code snippet looks like below: std::string keyy = "(&(cn=Manager)(givenName=Sudhi))"; struct berval * berEncodedFilter = ber_bvstr(keyy.c_str()); LDAPControl* serverControl[2]; return_code = ldap_control_create(LDAP_CONTROL_ASSERT, 0, berEncodedFilter, 0, &(serverControl[0])); serverControl[1] = NULL; return_code = ldap_delete_ext(m_connection, dn.c_str(), serverControl, 0, &msgID); ber_bvfree(berEncodedFilter); ldap_control_free(serverControl[0]); Is there an issue in this code? Please help. Thanks Sudhi

2 1

2.4.44 reproducible segfault via ldap search operation
by Karsten Heymann 16 May '17

16 May '17

Hi, some hours ago I found a way to instantly kill our (production -sigh- ) slapd processed with a simple unauthenticated ldap search operation. We are running 2.4.40 (from debian wheezy-backports) in production but I was able to reproduce exactly the same behaviour with 2.4.44 (taken from debian jessie-backports). While I'm building a minimal testcase without internal information so I can provide it to the project (are there more bug submission guidelines than http://www.openldap.org/faq/data/cache/59.html ?), I wanted to ask how you want me to handle this in my eyes quite serious incident. Should I just post it to the mailing list or do you prefer a non-public transmission first so the bug does not get exploited in a denial of service use case before you had the chance to come up with a fix? I will also try to verify if the problem is still existing in the current git master or self compiled 2.4.44. Best regards, Karsten

2 2

Re: Client binding to a specific local address
by Quanah Gibson-Mount 15 May '17

15 May '17

Be sure and raise it for discussion on the -devel list before starting work. --Quanah > On May 15, 2017, at 7:13 PM, Daniel Le <daniel.le(a)exfo.com> wrote: > > I filed http://www.openldap.org/its/index.cgi?findid=8654 and will be working on it as well. > > Daniel > > -----Original Message----- > From: Michael Ströder [mailto:michael@stroeder.com] > Sent: Saturday, May 13, 2017 6:58 AM > To: Daniel Le <daniel.le(a)exfo.com> > Cc: openldap-technical(a)openldap.org > Subject: Re: Client binding to a specific local address > > Daniel Le wrote: >> Thanks Quanah and Michael. I much appreciate your help. >> >> I am new to this list. How do I submit an enhancement request? Or would you be willing >> to do it on behalf of the community? > > You can file a RFE request here: > http://www.openldap.org/its/ > > Ciao, Michael. >

1 0

Re: Client binding to a specific local address
by Quanah Gibson-Mount 15 May '17

15 May '17

--On Thursday, May 11, 2017 5:24 PM -0500 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Ah I see. No such option at this time that I am aware of. Yeah, looking at os-ip.c in libldap, we have no option to use bind(2), and purely use connect(2). I suppose this could be seen as an enhancement request. do{ osip_debug(ld, "attempting to connect: \n", 0, 0, 0); if ( connect(s, sin, addrlen) != AC_SOCKET_ERROR ) { --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

3 3

Transaction log files generated too frequently and DB_LOG_AUTOREMOVE setting does not remove old log files
by Joanne Yan Fu 13 May '17

13 May '17

I have a relatively small OpenLDAP DB (ldif backup file is less than 7M and total size of *bdb files is less than 20M), that handles mostly read requests and few write requests. The servers are configured to run in a cluster env using master-master replication. Recently, the servers ran out of space as the transaction log files accumulated. We deleted the old log files manually (as attemp on using "DB_ARCHIVE -d" failed) and were able to restart one of the servers, however noticed the transaction log files (with default size of 10M) were created too frequently ever since (can be 80 files a day). In peak hours, the 10M transaction log files was generated every min I am sure there were not so many write activities. Does anyone know what could cause the creation of the tranaction log files so frequently? In addition, I had set "set_flags DB_LOG_AUTOREMOVE" flag along with check point settings in one of the servers running in cluster, but the log files were not removed automatically. Am I supposed to set the configurations on each server in the cluster to make it working on any of the servers? Here are some settings and server information: - OpenLDAP: slapd 2.4.23 on linux - In slapd.conf: database bdb ... checkpoint 1024 15 - In DB_CONFIG #the cache size is a little too big, we will tune it down later. Hope this will not be an issue set_cachesize 0 268435456 1 set_lg_regionmax 262144 set_lg_bsize 2097152 set_flags DB_LOG_AUTOREMOVE - a sublist of log files: -rw------- 1 ldap ldap 10485760 May 11 14:50 log.0000000068 -rw------- 1 ldap ldap 10485760 May 11 14:52 log.0000000069 -rw------- 1 ldap ldap 10485760 May 11 14:53 log.0000000070 -rw------- 1 ldap ldap 10485760 May 11 14:54 log.0000000071 -rw------- 1 ldap ldap 10485760 May 11 14:55 log.0000000072 Thanks, Joanne

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2017