openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

Phantom certificates?
by Andrew D. Arenson 12 May '14

12 May '14

I am trying to understand how a ldap server's certificate is being verified in the absence of the appropriate CA certificates. I have openldap 2.4.23-34 installed. If I set TLS_CACERTDIR to a dummy directory (like /home/aarenson), ldapsearch tells me, as expected, that the server's certificate is not verified. If I set TLS_CACERTDIR to a directory where I have placed the file with my CA certificates, ldapsearch tells me, again as expected, that the server's certificate _IS_ verified. The situation that is surprising me, though, is that if I set TLS_CACERTDIR to /etc/openldap/certs, which has the cert8.db file, but as far as I can tell has no actuall certificates in that database, ldap search tells me, surprisingly, that the server's certificate _IS_ verified. How is openldap verifying my server's certificate? When I look in /etc/openldap/certs for certificates, I find none: =========================================================================== = [root@in-rtls-dev02 certs]# pwd /etc/openldap/certs [root@in-rtls-dev02 certs]# ls cert8.db key3.db less password secmod.db [root@in-rtls-dev02 certs]# certutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI = =========================================================================== I have put a file with the appropriate chain of signing certificates in /etc/pki/tls/certs as incommon_chain_2013.pem: =========================================================================== = [root@in-rtls-dev02 certs]# pwd /etc/pki/tls/certs [root@in-rtls-dev02 certs]# ls 3641f99d.0 Makefile incommon-ie.pem make-dummy-cert 9de8458f.0 ca-bundle.crt incommon_chain_2013.pem renew-dummy-cert 9ef5f911.0 ca-bundle.trust.crt iu-bl-inter-ie.pem = =========================================================================== Here's the system ldap configuration I'm using: =========================================================================== = [root@in-rtls-dev02 openldap]# pwd /etc/openldap [root@in-rtls-dev02 openldap]# cat ldap.conf # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never #TLS_REQCERT allow TLS_REQCERT demand #TLS_CACERTDIR /etc/openldap/certs #TLS_CACERTDIR /etc/pki/tls/certs TLS_CACERTDIR /home/aarenson = =========================================================================== Here is the user ldap configuration I'm using. It is all commented out: =========================================================================== = [in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> cat .ldaprc # Instruct client to try requesting a server's cert. #TLS_REQCERT allow #TLS_REQCERT demand # Define location of CA Cert #TLS_CACERTDIR /etc/openldap/certs #TLS_CACERTDIR /etc/pki/tls/certs #TLS_CACERTDIR /home/aarenson = =========================================================================== Here are the three invocations of ldapsearch: =========================================================================== = [in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> ldapsearch -d 9 -D "aarenson(a)ads.iu.edu" -w "<PASSWORD>" -H ldaps://ads.iu.edu:636 -b "ou=Accounts,dc=ads,dc=iu,dc=edu" -s sub "(sAMAccountName=aarenson)" ... TLS: certificate [CN=InCommon Server CA,OU=InCommon,O=Internet2,C=US] is not valid - error -8179:Peer's Certificate issuer is not recognized.. ... [in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> LDAPTLS_CACERTDIR=/etc/pki/tls/certs LDAPTLS_REQCERT=demand ldapsearch -d 9 -D "aarenson(a)ads.iu.edu" -w "<PASSWORD" -H ldaps://ads.iu.edu:636 -b "ou=Accounts,dc=ads,dc=iu,dc=edu" -s sub "(sAMAccountName=aarenson)" ... distinguishedName: CN=aarenson,OU=Accounts,DC=ads,DC=iu,DC=edu ... [in-rtls-dev02.uits.iupui.edu:/home/aarenson] bash> LDAPTLS_CACERTDIR=/etc/openldap/certs LDAPTLS_REQCERT=demand ldapsearch -d 9 -D "aarenson(a)ads.iu.edu" -w "<PASSWORD>" -H ldaps://ads.iu.edu:636 -b "ou=Accounts,dc=ads,dc=iu,dc=edu" -s sub "(sAMAccountName=aarenson)" ... distinguishedName: CN=aarenson,OU=Accounts,DC=ads,DC=iu,DC=edu ... = =========================================================================== Andy -- Andrew D. Arenson | aarenson (@) iu.edu Advanced Biomedical IT Core, Research Technologies, UITS | W (317) 278-1208 RT is a PTI Cyberinfrastructure & Service Center | C (317) 679-4669 Indiana University Purdue University Indianapolis | F (317) 278-1852

2 5

common name
by Jignesh 12 May '14

12 May '14

I have confusion on on common name. In Open ldap it is a combination of first name and last name and other side it is unique. So it is forces us to use something else then combination of first name and last name. Now tools like php openldap, apache directory shows the LDPA user in left navigation by common name. So if we map common name to something else then we will have problem to view the list in these tools. Is it possible to change the setting for above tools so that they can reflect based on first name and last name instead of common name? -Jignesh

2 1

LMDB concurrent operation and MDB_NOSYNC
by Kristian Amlie 12 May '14

12 May '14

Hi, Does using MDB_NOSYNC when opening the MDB environment in any way affect LMDB's ability to do concurrent database access? Regards Kristian Amlie CFEngine

2 4

Multiple userPasswords entries & resetting one value
by Michael 11 May '14

11 May '14

I have a user with a SSHA userPassword value as well as a SASL userPassword entry. The SASL entry will never change but I'd like to be able to reset and age the SSHA entry only. Is this aging of only one value possible with ppolicy and is it possible to handle manual resets with ldappasswd and/or utilizing an LDIF file? -Mike

2 2

evaluation of set-clauses in <WHO>
by Michael Ströder 10 May '14

10 May '14

HI! Still trying to optimize a bunch of set-based ACLs I wonder whether the (possibly heavy-weight) set-clauses in the <WHO> part are evaluated only in case of an actually matching <WHAT> part. Any hint is appreciated. Ciao, Michael.

2 2

LDAP account status
by Julien Courtès 09 May '14

09 May '14

Hi, I want to disable an account without deleting informations about it. This account is linked with some services such as Owncloud, ftp authentification, samba, linux auth and ssh auth. Does it exists a way to disable the account for all the services? I know that I can disable the account for samba with sambaAcctFlags but I don't know an easy way for other services. I thinked to create a new field called "AccountStatus" and filter on each service accounts which have AccountStatus=active like that /(&(objectClass=inetOrgPerson)(AccountStatus=active)) /Is it a good way to do it or no? Thanks Julien Courtès

4 5

memberOf overlay issues
by Brendan Kearney 08 May '14

08 May '14

Fedora 20, slapd 2.4.39 i am trying to add the memberOf overlay onto a database. the module is loading fine, but the instantiation of the overlay causes some errors. it seems that an OID syntax is throwing things for a loop. below is the output from "slaptest -d any". What could i be doing wrong? 53682a3b ldif_read_file: read entry file without checksum: "/etc/openldap/slapd.d/cn=config/olcDatabase={2}mdb/olcOverlay={2}memberof.ldif" 53682a3b => str2entry: "dn: olcOverlay={2}memberof objectClass: olcOverlayConfig objectClass: olcMemberOfConfig objectClass: top olcOverlay: {2}memberof structuralObjectClass: olcMemberOfConfig entryUUID: 881fa376-67df-1033-8b16-e73c76eb0f15 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20140504135544Z entryCSN: 20140504135544.638618Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20140504135544Z " 53682a3b >>> dnPrettyNormal: <olcOverlay={2}memberof> 53682a3b <<< dnPrettyNormal: <olcOverlay={2}memberof>, <olcOverlay={2}memberof> 53682a3b str2entry: invalid value for attributeType objectClass #1 (syntax 1.3.6.1.4.1.1466.115.121.1.38) 53682a3b send_ldap_result: conn=-1 op=0 p=0 53682a3b send_ldap_result: err=80 matched="" text="internal error (cannot parse some entry file)" slaptest: bad configuration file!

1 1

Re: Phantom certificates?
by Andrew D. Arenson 07 May '14

07 May '14

On Wed, May 07, 2014 at 09:42:33AM +0200, Hallvard Breien Furuseth wrote: > On 05/06/2014 05:26 PM, Andrew D. Arenson wrote: > >(...) if I set > >TLS_CACERTDIR to /etc/openldap/certs, which has the cert8.db file, but > >as far as I can tell has no actuall certificates in that database, ldap > >search tells me, surprisingly, that the server's certificate _IS_ verified. > > > > How is openldap verifying my server's certificate? > > Maybe this is a variant of ITS#5582: Setting TLS_CACERT to any > certificate.pem file also tells OpenSSL to check the system's > standard installed certs. OpenLDAP should have a separate > option for that, or the opposite - an option not to do that. Thanks. I didn't find an option for turning on/off the use of a system's standard installed certs. Are you saying that you think something like that _does_ exist, or that you simply think it should? I tried moving my certs directory out of the default location of /etc/pki/tls, but was still unable able to generate a failure to verify the certificate when TLS_CACERTDIR was set to /etc/openldap/certs. Andy -- Andrew D. Arenson | aarenson (@) iu.edu Advanced Biomedical IT Core, Research Technologies, UITS | W (317) 278-1208 RT is a PTI Cyberinfrastructure & Service Center | C (317) 679-4669 Indiana University Purdue University Indianapolis | F (317) 278-1852

2 1

Re: LMDB integrity with MDB_NOSYNC on various filesystems
by Howard Chu 06 May '14

06 May '14

Dimitrios Apostolou wrote: > Hello, > > I'm reading in LMDB docs that MDB_NOSYNC will not allow database > corruption under certain conditions: > >> However, if the filesystem preserves write order and the MDB_WRITEMAP >> flag is not used, transactions exhibit ACI (atomicity, consistency, >> isolation) properties and only lose D (durability). I.e. database >> integrity is maintained, but a system crash may undo the final >> transactions > > > Do we know if these conditions are valid for modern filesystems like ext3, > ext4, XFS and how this is affected by various mount options (e.g. ordered, > writeback etc)? Read up on the specific filesystems you're interested in. These things change too frequently for us to track, and it's your responsibility to know what you're deploying. -- -- 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

deploying password policy module
by Paul B. Henson 06 May '14

06 May '14

We are planning to deploy the password policy module to satisfy our security groups requirement for account lockouts (a.k.a., intentionally provided DoS attack vectors <sigh>). I had a couple of questions regarding the deployment I was hoping someone might be kind enough to answer. Does the password policy module need to be loaded on all of the servers simultaneously, even if there are no password policies defined? We typically stage configuration changes, pulling servers out of the load balancer, updating them, testing them, and then putting them back, such that at no time is service unavailable. The password policy module extends the schema though, and I don't want a server with it loaded potentially trying to replicate unknown attributes to one without it loaded. It's not clear whether simply loading the module would potentially cause this, or if password policy attributes would only be replicated if the module was actually configured with a default policy or if a user had a specifically defined policy. So, would it be safe to stage the initial configuration change loading the module as long as no policies are in place or used (until all of the servers have been updated), or is it required to shut down all of the servers simultaneously to make the change? We are only planning to avail of account lockouts, not any of the other functionality of the module. As such, unless I misunderstand, the following policy should enable lockouts but not apply any of the other restrictions: dn: cn=default,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy pwdAttribute: userPassword pwdLockout: TRUE pwdLockoutDuration: 1800 pwdMaxFailure: 100 pwdFailureCountInterval: 300 This would be the default policy. We also have some number of service accounts which we would not want subject to lockouts, if I understand correctly, configuring those accounts with an explicit password policy pwdPolicySubentry like this: dn: cn=serviceaccount,ou=policies,dc=example,dc=com cn: default objectClass: pwdPolicy pwdAttribute: userPassword Should leave them with no restrictions? Finally, there is a requirement for the helpdesk to be able to manually unlock a locked out account. For an account that is currently locked out, would deleting the pwdAccountLockedTime and pwdFailureTime attributes reset it to a normal state? Thanks much.

3 15

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical