openldap-technical

openldap-technical@openldap.org

14 participants
9796 discussions

Re: LDIF?
by Quanah Gibson-Mount 24 Feb '16

24 Feb '16

--On Wednesday, February 24, 2016 12:50 AM +0100 Emmanuel Lécharny <elecharny(a)gmail.com> wrote: >> > No to mention there is a missing dc Attribute in the entry. Good point. It's unlikely the author meant to combine the two objectClasses. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

2 1

Re: Regarding lmdb
by Howard Chu 24 Feb '16

24 Feb '16

Hor Meng Yoong wrote: > Dear Howard > > Thank you for your great effort in creating lmdb. > > I am looking a solution that can sync multiple lmdb slaves to one lmdb master. > Changes from the each lmdb slave are also updated to other lmdb slaves via the > lmdb master. > > Any up-to-date, up-and-running lmdb slaves can vote among themsleves to become > he next master in the event that the master fails. To prevent islanding and > multiple masters, vote is only allowed if there are at least a minimum numbers > (configurable) of interconnected lmdb slaves. > > To improve efficiency, data protection, a master table inside the lmdb master > decides which lmdb slaves should be updated, such as frequency of update, > tables to be updated. Drastic database operation (e.g., table creation and > deletion) shall only be initiated from he master. > > Bases on current design architecture and future design plan, what is the best > way for this to be implemented. Replication is a non-goal for LMDB. In OpenLDAP we already have a multimaster replication protocol built on LDAP; we don't need replication in the database engine. Projects that aim to build replication as an LMDB feature are misguided. An embedded database engine's only job is to store and retrieve bytes using local storage. Nothing else. What you're talking about belongs at a higher abstraction layer and has nothing to do with the DB engine. Whatever system you are trying to design is orthogonal to the storage engine. I suggest you look into Dynomite using memcacheDB. http://techblog.netflix.com/2014/11/introducing-dynomite.html https://github.com/LMDB/memcachedb Note that any time you start dealing with network services, you immediately incur the need for authentication, authorization, and privacy controls. Please don't be like the rest of the NoSQL crowd and only realize this after the fact. You will need a proper network protocol, one that's designed to be efficient and secure. You'll also need a decent data model for serializing data over the wire. Most of what you'll need has already been invented and formalized in a spec - we call it LDAP. > Besr regards > Hor Meng > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

How to monitor and test write ldap?
by jupiter 24 Feb '16

24 Feb '16

Hi, I am setting a nagios scripts to monitor the LDAP server. While I can run ldapsearch to check and read data from LDAP, I also want to write dummy data to LDAP database to make sure both read / write are functional well. What is the proper way to run come command in nagios script to write dummy data to LDAP? Or if you have good solution to check write process? Thank you. Kind regards, - jupiter

2 1

LDIF?
by Mary Kao 23 Feb '16

23 Feb '16

Hello, I am trying to add an 'ou' entry to a directory (just a sample), and keep getting the following error. Would appreciate any pointers as to why this is happening: > ldapadd -x -D "cn=Manager,dc=my-domain,dc=com" -W -f users-example.ldif Enter LDAP Password: adding new entry "ou=RavenApps,dc=my-domain,dc=com" ldap_add: Invalid syntax (21) additional info: objectclass: value #1 invalid per syntax I have an LDIF file called "users-example.ldif" with the contents:dn: ou=RavenApps,dc=my-domain,dc=com objectclass: dcObject objectClass: organizationUnit ou: RavenApps Presently, in the directory I have: > ldapsearch -x -b 'dc=my-domain,dc=com' '(objectClass=*)' # extended LDIF # # LDAPv3 # base <dc=my-domain,dc=com> with scope subtree # filter: (objectClass=*) # requesting: ALL # # my-domain.com dn: dc=my-domain,dc=com objectClass: dcObject objectClass: organization o: Raven dc: my-domain # Manager, my-domain.com dn: cn=Manager,dc=my-domain,dc=com objectClass: organizationalRole cn: Manager # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Thank you!

3 2

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 23 Feb '16

23 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical