openldap-technical

openldap-technical@openldap.org

9 participants
9942 discussions

SASL EXTERNAL auth issues
by Penza Kenneth at MITA 23 Feb '16

23 Feb '16

Hi, I am using RHEL7 and openldap from LTB project(to test out SSHA password hashing). Currently I am having issues to configure SASL EXTERNAL auth. Maybe I am missing something, any pointers would be appreciated. [root@oldp4-dk-vm ~]# /usr/local/openldap/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.44 (Feb 15 2016 11:14:35) $ clement@centos7.unix.example.com:/home/clement/build/BUILD/openldap-2.4.44/servers/slapd [root@oldp4-dk-vm ~]# After adding the ldapi:/// listener to the startup script, I verified its working using lsof. [root@oldp4-dk-vm ~]# lsof | grep ldap | grep -e '$unix\|LISTEN$' slapd 7988 ldap 3u unix 0xffff880077fc23c0 0t0 603136 socket slapd 7988 ldap 7u IPv4 603140 0t0 TCP *:ldap (LISTEN) slapd 7988 ldap 8u IPv6 603141 0t0 TCP *:ldap (LISTEN) slapd 7988 ldap 9u IPv4 603144 0t0 TCP *:ldaps (LISTEN) slapd 7988 ldap 10u IPv6 603145 0t0 TCP *:ldaps (LISTEN) slapd 7988 ldap 11u unix 0xffff880077fc2000 0t0 603146 /usr/local/openldap/var/run/ldapi slapd 7988 7989 ldap 3u unix 0xffff880077fc23c0 0t0 603136 socket slapd 7988 7989 ldap 7u IPv4 603140 0t0 TCP *:ldap (LISTEN) slapd 7988 7989 ldap 8u IPv6 603141 0t0 TCP *:ldap (LISTEN) slapd 7988 7989 ldap 9u IPv4 603144 0t0 TCP *:ldaps (LISTEN) slapd 7988 7989 ldap 10u IPv6 603145 0t0 TCP *:ldaps (LISTEN) slapd 7988 7989 ldap 11u unix 0xffff880077fc2000 0t0 603146 /usr/local/openldap/var/run/ldapi slapd 7988 7991 ldap 3u unix 0xffff880077fc23c0 0t0 603136 socket slapd 7988 7991 ldap 7u IPv4 603140 0t0 TCP *:ldap (LISTEN) slapd 7988 7991 ldap 8u IPv6 603141 0t0 TCP *:ldap (LISTEN) slapd 7988 7991 ldap 9u IPv4 603144 0t0 TCP *:ldaps (LISTEN) slapd 7988 7991 ldap 10u IPv6 603145 0t0 TCP *:ldaps (LISTEN) slapd 7988 7991 ldap 11u unix 0xffff880077fc2000 0t0 603146 /usr/local/openldap/var/run/ldapi [root@oldp4-dk-vm ~]# Checking for supported sasl methods: [root@oldp4-dk-vm ~]# ldapsearch -x -H ldapi:/// -b "" -LLL -s base supportedSASLMechanisms dn: supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: LOGIN supportedSASLMechanisms: PLAIN [root@oldp4-dk-vm ~]# Attempting to bind using sasl [root@oldp4-dk-vm ~]# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b dn -vv -d 5 ldap_url_parse_ext(ldapi:///) ldap_initialize( ldapi:///??base ) ldap_create ldap_url_parse_ext(ldapi:///??base) ldap_sasl_interactive_bind: user selected: EXTERNAL ldap_int_sasl_bind: EXTERNAL ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_path ldap_new_socket: 3 ldap_connect_to_path: Trying /usr/local/openldap/var/run/ldapi ldap_connect_timeout: fd: 3 tm: -1 async: 0 ldap_ndelay_on: 3 ldap_ndelay_off: 3 ldap_msgfree ldap_err2string ldap_sasl_interactive_bind_s: Local error (-2) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed [root@oldp4-dk-vm ~]# Configuration: [root@oldp4-dk-vm ~]# cat config.ldif dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /usr/local/openldap/etc/openldap/slapd.conf.bak olcConfigDir: /usr/local/openldap/etc/openldap/slapd.d olcAllows: bind_v2 olcArgsFile: /usr/local/openldap/var/run/slapd.args olcAttributeOptions: x-hidden lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /usr/local/openldap/var/run/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSaslSecProps: noplain,noanonymous olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificateFile: /usr/local/openldap/etc/openldap/certs/ca-chain.cert.pem olcTLSCertificateFile: /usr/local/openldap/etc/openldap/certs/server.pem olcTLSCertificateKeyFile: /usr/local/openldap/etc/openldap/certs/server.key.pem olcTLSVerifyClient: never olcToolThreads: 1 olcWriteTimeout: 0 structuralObjectClass: olcGlobal dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/openldap/etc/openldap/schema/core.ldif include: file:///usr/local/openldap/etc/openldap/schema/cosine.ldif include: file:///usr/local/openldap/etc/openldap/schema/inetorgperson.ldif include: file:///usr/local/openldap/etc/openldap/schema/nis.ldif ## We serve small clients that do not handle referrals, ## so handle remote lookups on their behalf. #dn: olcDatabase=ldap,cn=config #objectClass: olcDatabaseConfig #objectClass: olcLdapConfig #olcDatabase: ldap #olcSuffix: "" #olcDbUri: ldap://ldap.some-server.com/ dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: TRUE olcAccess: to attrs=name;x-hidden by * =cs olcAccess: to attrs=userPassword by * auth olcAccess: to * by * read olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none olcAddContentAcl: TRUE olcRootPW: {SSHA}dWIRB+xNhhBABixGgVrRKv7/J93NrgW7 olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=manager,dc=myds,dc=example,dc=com" read by * none olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=manager,dc=myds,dc=example,dc=com" write by * none olcAccess: {1} to dn.base="" by * read olcAccess: {2} to * by self write by dn="cn=manager,dc=myds,dc=example,dc=com" write by * read olcAddContentAcl: FALSE olcDatabase: {2}hdb olcDbCacheFree: 1 olcDbCacheSize: 1000 olcDbCheckpoint: 512 15 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 3000 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbDirectory: /usr/local/openldap/var/openldap-data olcDbDirtyRead: FALSE olcDbDNcacheSize: 0 olcDbIDLcacheSize: 3000 olcDbIndex: cn,sn,mail pres,eq,approx,sub olcDbIndex: objectClass eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: FALSE olcDbSearchStack: 16 olcDbShmKey: 0 olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=manager,dc=myds,dc=example,dc=com olcRootPW: {SSHA}dWIRB+xNhhBABixGgVrRKv7/J93NrgW7 olcSuffix: dc=myds,dc=example,dc=com structuralObjectClass: olcHdbConfig [root@oldp4-dk-vm ~]# Regards Kenneth

2 4

ppolicy overlay and disk space exhaution
by Bruncko Michal 22 Feb '16

22 Feb '16

Hello list We use ppolicy overlay for enforcing password lifecycle. Recently we faced with following issue and now I am trying to do some countermeasures to minimize risk of issue reoccurring. We use openldap server for user authentication. Here we store objects of real users as well as system users (for daemons and so on). We use redundant setup with two openldap servers running in mirror mode (multi-master). - Few days ago I find out that I wasn't able to log into service which uses this LDAP as authentication backend. - I find out that BOTH openldap servers are down (simply process wasn't listening) - checked LDAP database partition (dedicated partition for storing both DB and LOG BDB transaction files) and it was exhausted on both servers - reason of this exhaustion was a couple of BDB log files created just within last few minutes before daemon went down - based on slapd logs it seems that one system user (used by Nagios) had expired password - for which I forgot to set no password expiration - and it seems that those failed authentication tries caused this transaction logs to exhaust partition, as because for each failed bind, new "pwdFailureTime" value was added into object which is basically normal ldap modify operation causing transaction log to involve. - and as because that system user was used by Nagios for various purposes and LDAP BIND rate was really high, it effectively behave like DoS to kill my ldap servers due partition space exhausting obviously I have fixed policy for that system user to keep password with unlimited expiration time. but anyway this DoS can be basically reproduced by any real user from outside to effectively kill those ldap servers. Redundancy with multiple servers does not provide any benefit as modifying pwdFailureTime is propagated over all cluster servers with same result to disk space. Also expanding partition will not help - it only extends service availability based on allocated space - and bdb log consuming was really huge - 15 log files (each with 10MB size) was created just within two minutes!! now the question: did anybody considered this "effect" of using "pwdFailureTime" attribute? If so, what can I do to avoid this behavior to occur? Or how you are facing with this potential kind of issues? On one side it is fine to see some failure attempt history. Also keeping pwdFailureTime limited to some max number of values will not help as the LDAP modify operation have to be done anyway. For me the only useful possibility is to NOT use this attribute pwdFailureTime at all, but how to do it? I haven't found any possibility to disable using this attribute. openldap-2.4.40/Centos6 many thanks for help michal

4 10

"LDAP ease modify restrictions" support
by Radovan Semancik 22 Feb '16

22 Feb '16

Hi, I was wondering whether OpenLDAP supports "LDAP ease modify restrictions" control (1.2.840.113556.1.4.1413). I was not able to find any information or documentation except for some vague clue that it might have been supported in OpenLDAP 2.2/2.3 times. The control is definitely not present in root DSE of my stock OpenLDAP 2.4.41. So I was wondering if there is some module/overlay that is needed to enable support for that. Thanks -- Radovan Semancik Software Architect evolveum.com

4 16

how to add users to LDAP and test authentication?
by Mary Kao 22 Feb '16

22 Feb '16

Hello, Would appreciate being pointed to good documentation for adding users to LDAP directory and testing user authentication? Thank you!

5 8

Odd LDAP Behavior
by Borresen, John - 0444 - MITLL 22 Feb '16

22 Feb '16

Getting, for me, some strange LDAP errors/indicators. This is a OpenLDAP 2.4.40 on CentOS7. The sudoers rules are being "seen" but not implemented: # sudo -l -U jdoe Matching Defaults entries for jdoe on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User jdoe may run the following commands on this host: (root) /usr/sbin/tcpdump (root) ALL (ALL) ALL When user jdoe tries to run a sudo command: # sudo su - sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 0 sudo: ldap_set_option: tls_cacertfile -> /etc/openldap/CA/cacert.pem sudo: ldap_set_option: tls_cacert -> /etc/openldap/CA/cacert.pem sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 30) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: Looking for cn=defaults: cn=defaults sudo: no default options found in ou=sudoers,dc=example,dc=com sudo: ldap search '(|(sudoUser=jdoe)(sudoUser=#12345)(sudoUser=%Example)(sudoUser=%#12345)(sud oUser=%Admin)(sudoUser=%Group1)(sudoUser=%GROUP2)(sudoUser=%GROUP3)(sudo User=%GROUP4(sudoUser=ALL))' sudo: searching from base 'ou=sudoers,dc=example,dc=com' sudo: adding search result sudo: result now has 1 entries sudo: ldap search '(sudoUser=+*)' sudo: searching from base 'ou=sudoers,dc=example,dc=com' sudo: adding search result sudo: result now has 1 entries sudo: sorting remaining 1 entries sudo: searching LDAP for sudoers entries sudo: Command allowed sudo: LDAP entry: 0x7fdfb8bc2260 sudo: done with LDAP searches sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(0)=0x02 Sorry, try again. Sorry, try again. Sorry, try again. sudo: 3 incorrect password attempts Also seeing in the log files, that bdb_substring_candidates: (sudoHost) not indexed But, it is indexed: oldDbIndex sudoHost eq Thanks in advance for assistance. This is a new environment, that is mimicking another LDAP environment running 2.4.39 on CentOS 5.12 which is running flawlessly. John D. Borresen (Dave) Linux/Unix Systems Administrator MIT Lincoln Laboratory Email: <mailto:john.borresen@ll.mit.edu> john.borresen(a)ll.mit.edu

2 1

Invalid credentials
by Dave Beach 21 Feb '16

21 Feb '16

I'm trying to debug a new openldap install on Debian Jessie. Password has been set with slappasswd, no command line options. I get a {SSHA} hash returned - what am I putting in slapd.conf for the admin password: the hashed (as rootpw {SSHA} password) or unhashed (as rootpw password) password? Either returns ldap_bind: Invalid credentials (49) when I restart slapd and perform an ldapsearch. Rootdn has been correctly set in slapd.conf. What can I provide in terms of output or log info to help some kind soul help me?

5 16

Known uses of LMDB outside OpenLDAP
by Ethan Hamilton 21 Feb '16

21 Feb '16

Hi My name is Ethan Hamilton. I work as software engineer for TIBCO Software, http://www.tibco.com/ . As part of my current activities, I am evaluating embedded databases for use in a system of record scenario. LMDB is one of the several good databases that has picked our attention. There is lots of information available in the internet but we find lacking, especially when compared with the information available for other databases like RocksDB, is information about production uses outside OpenLDAP. Facebook makes a lot of information available about how they use RocksDB. They also have a lot of other companies presenting in their meetups on how they currently use (or plan to use) RocksDB. I am seeking information about uses of LMDB in system of record kind of situations, especially in large, replicated clusters where LMDB is used as the persistence layer to store mission critical data. Thank you in advance, Ethan

2 1

ssf settings for SASL and TLS
by Joshua Schaeffer 20 Feb '16

20 Feb '16

What is the proper way to setup SASL and TLS with different security strength factors? I've setup SASL on my OpenLDAP server so that it can connect to my Kerberos server using GSSAPI. I also have TLS setup for simple auth. My database config is below: root@baneling:~/ldif_files# slapcat -H "ldap:///olcDatabase={1}mdb,cn=config??base?" dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=harmonywave,dc=com olcAccess: {0}to attrs=userPassword,shadowLastChange,krbPrincipalKey by self write by anonymous auth by dn="cn=admin,dc=harmonywave,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=harmonywave,dc=com olcRootPW:: e1NTSEF9dUhDcE1jUUJoWlpuc0twRHBNQkVCUGtmTFA5SC9EYUU= olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq olcDbIndex: uidNumber,gidNumber eq olcDbIndex: member,memberUid eq olcDbIndex: sudoUser eq olcDbIndex: krbPrincipalName eq,pres,sub olcDbMaxSize: 1073741824 structuralObjectClass: olcMdbConfig entryUUID: caa04334-6857-1035-9fbb-dd6671002504 creatorsName: cn=admin,cn=config createTimestamp: 20160215174631Z olcSecurity: sasl=56 simple_bind=256 ssf=256 entryCSN: 20160218030327.503814Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20160218030327Z When I set the security to "olcSecurity: sasl=56 simple_bind=256" then I can bind with SASL or simple auth. However if I set ssf=256 (or really anything higher then 56), like in the above configuration, I get an error when trying to bind with SASL: root@baneling:~/ldif_files# ldapsearch -LLL -Y GSSAPI -H ldapi:/// -b dc=harmonywave,dc=com -s base SASL/GSSAPI authentication started SASL username: jschaeffer(a)HARMONYWAVE.COM SASL SSF: 56 SASL data security layer installed. Confidentiality required (13) Additional information: stronger confidentiality required If I set tls instead of ssf to any number (tls=1 or greater) then I get a slightly different error message when trying to bind with SASL: root@baneling:~/ldif_files# ldapsearch -LLL -Y GSSAPI -H ldapi:/// -b dc=harmonywave,dc=com -s base SASL/GSSAPI authentication started SASL username: jschaeffer(a)HARMONYWAVE.COM SASL SSF: 56 SASL data security layer installed. Confidentiality required (13) Additional information: TLS confidentiality required It looks like slapd has its own preference when parsing through olcSecurity. I'm really just trying to understand the preferred method for setting this up. Perhaps this isn't a real-world situation or perhaps I already answered my own question by setting just sasl and simple_bind. Thanks, Joshua

4 9

can find slapd.conf fine in /etc/openldap under Centos7
by MichaelLeung 20 Feb '16

20 Feb '16

hi all i am not so sure it is the correct place to issue my problem but i really need some help sine i upgrade to Centos7 and install openldap-2.4.4 on it, i would not find slapd.conf in /etc/openldap, the only related file i can find is slapd.ldif . though i still can start slapd services does openldap need slapd.conf any more ?

2 1

chain-uri with a blank?
by Marc Patermann 18 Feb '16

18 Feb '16

Hi, should chain-uri work with an URI with a blank the DIT path? like in: chain-uri "ldap://servername/ou=far bar,c=de" I'm getting a parsing error here with 2.4.43. Feb 17 18:35:01 slapd[1765]: /etc/openldap/slapd.conf: line 156 (chain-uri "ldap://servername/ou=foo bar,c=de") Feb 17 18:35:01 slapd[1765]: /etc/openldap/slapd.conf: line 156: unable to parse uri "(null)" in "uri <uri>" line: URL doesn't begin with "[c]ldap[si]://". Is this a bug? Marc

5 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical