ldap_set_option() of LDAP_OPT_X_TLS_REQUIRE_CERT
by Todd Lyons
Hello, I'm a developer on the Exim MTA and I have some questions about
differing behavior I am seeing across different systems. I would like
some suggestions about the best way to handle each issue.
First, I have not gotten "a ton of complaints." One person contacted
me with the issues I am describing below. I do not know his server or
client versions, other than his workstation is Debian Squeeze. I'll
just refer to him as "the guy".
Second, my test server is running openldap 2.3.34, my workstation on
which I am running my test builds of Exim is using openldap 2.4.28
client libs.
Issues:
1. When multiple servers are specified, our ldap code just did an
unbind to all servers defined when it was finished. The guy contacted
me with the problem that the unbind call hangs when one of the ldap
servers was unavailable for whatever reason. On *my* system, the
blind unbind worked properly no matter if the bind succeeded.
I modified the ldap code so that it only unbinds if the original bind
succeeded. That seems the proper/correct way to handle it in all
cases, so this issue really is already solved. I'm just wondering if
there are any gotchas I might be missing by doing it this way.
2. A few months ago I helped (a different) someone troubleshoot a
really strange problem where setting the LDAP_OPT_X_TLS_REQUIRE_CERT
option in our code did not have any impact on his machine. Our code
set that option per connection. It turns out that, for him, setting
that option per connection did not affect the TLS require cert option
that the bind used. He found some comment somewhere advising that
NULL for the ldap handle sets the option globally in the ldap client.
We tried it and it solved the problem for him. I saw identical
behavior on my system (NULL worked, ldap handle did not) so we assumed
that the code had never really worked properly. I then changed our
ldap code to use NULL instead of the ldap handle when setting the TLS
require cert option.
The guy (with the current problem) runs a system that worked just fine
previously, but using the new code (NULL instead of ldap handle when
setting TLS require cert option) does not affect the TLS require
certificate setting when his bind is attempted. After much testing
and debugging, I had him merely change that one line back to using the
ldap handle in ldap_set_option() and it then worked properly for him.
So I have two systems (mine and his) which behave differently after
the ldap_set_option() on LDAP_OPT_X_TLS_REQUIRE_CERT. In a fit of
psychotic testing, I decided on my system to just blindly set it both
globally and per connection. It worked, and produced no errors. That
surprised me, I expected one or the other to complain.
My potential code looks like the following (apologize if Gmail wraps),
can you explain any pitfalls of doing it this way? Should the two be
#ifdef guarded by client lib version checks or something?
/* Use NULL ldap handle b/c is global in some client libs */
rc = ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option);
if (rc)
{
DEBUG(D_lookup)
debug_printf("Unable to set TLS require cert_option(%d) globally: %s\n",
cert_option, ldap_err2string(rc));
}
/* Use current ldap handle b/c is per-connection in others */
rc = ldap_set_option(ld, LDAP_OPT_X_TLS_REQUIRE_CERT, &cert_option);
if (rc)
{
DEBUG(D_lookup)
debug_printf("Unable to set TLS require cert_option(%d) on LDAP server "
"%s%s: %s\n",
cert_option, host, porttext, ldap_err2string(rc));
}
Any comments or suggestions are appreciated.
...Todd
--
The total budget at all receivers for solving senders' problems is $0.
If you want them to accept your mail and manage it the way you want,
send it the way the spec says to. --John Levine
9 years, 11 months
substring matching rule not working in extensible search filter
by David Coutadeur
Hi everybody,
I tryied this filter in a ldapsearch operation:
(&(objectClass=inetOrgPerson)(description:2.5.13.7:=*abcd))
but this results in a "Bad search filter (-7)".
However if I write this without the joker it works:
(&(objectClass=inetOrgPerson)(description:2.5.13.7:=abcd))
I don't see any restriction on matching rule extensible notation in RFC
4515 (http://tools.ietf.org/html/rfc4515). Is this syntax not
implemented in OpenLDAP, or did I make a mistake in my filter ?
Thank you in advance,
DC
9 years, 11 months
invalid value for attributeType objectClass
by limpteam＠gmail.com
Hello community!
Have a Centos 6.4 server with new openldap 2.4.23-32.el6_4.1 installled.
I'm new to ldap and just install it and configure for easy use.
I edit only than 2 files olcDatabase={0}config.ldif and
olcDatabase={2}bdb.ldif
It's starts, I worked with it, add some OU and CN via phpLdapAdmin and
tested it on Thunderbird.
But after I decide to restart slapd i got error:
PROXIED attributeDescription "DC" inserted.
str2entry: invalid value for attributeType objectClass #0 (syntax
1.3.6.1.4.1.1466.115.121.1.38)
slaptest: bad configuration file!
and didn't start.
it's problem with ppolicy and pwdAttribute? How can i solve this?
Thanks for answer!
P.S. Google can't help me or I just don't understand the whole theory.
9 years, 11 months
About LDAP PAM authentication
by Ernesto Manuel Suarez Ojeda
Hi,
I have 4 goals in configurating ldap pam authentication in my workstations Ubuntu 12.04 and 10.04:
1. Authenticate both ldap users and unix users.
2. Login using cached credentials when ldap server is down.
3. Warnings and dialog for password change when password expired or is about to expire.
4. Password length and complexity check.
We have an openldap server with an operational ppolicy.schema and we need a comprehensive explanation about configuring Ubuntu clients for achieve this goals. I have read some documents but I'm not satisfied.
Thanks,
Ernesto Suárez Ojeda
9 years, 11 months
Trouble with delta-syncrepl MMR: delta-sync lost sync on X, switching to REFRESH
by Patrick Lists
Hi,
I'm trying to create a 2-node delta-syncrepl Multi-Master setup with the
help of the Admin Guide, man pages and
tests/scripts/test063-delta-multimaster. I see the following problem
repeat on the "slave" master aka ldap02 which initially syncs with
ldap01 aka the "primary" master:
Oct 28 04:12:14 ldap02 slapd[9998]: do_syncrep2: rid=001 delta-sync lost
sync on (reqStart=20131028012214.000002Z,cn=accesslog), switching to REFRESH
I found ITS#7274 which mentions that some order should be changed
(syncprov before olcServerID) but I have no idea how that applies to my
setup. Being new to all this magic I came up empty. So here's my config.
Hopefully it isn't too messed up :) I would appreciate it if someone
could share a clue or 2 how to make this work. Comments on the config
not related to the problem are also most welcome.
OS: CentOS 6.4 x86_64 - clean install, all OpenLDAP dirs are empty
OpenLDAP version: RE24 git rev f9e417a from around 10/23/2013.
On the initial/"primary" master (note that the config is the same for
the "slave" up to the comment):
$ sudo /usr/local/sbin/slapadd -v -F $LDAP_ETC/slapd.d \
-l ./delta-syncrepl-MMR.ldif -n 0
$ cat ./delta-syncrepl-MMR.ldif
# global configuration settings
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/openldap-2.4/slapd-2.4.args
olcPidFile: /var/run/openldap-2.4/slapd-2.4.pid
olcLogFile: /var/log/openldap-2.4/slapd-2.4.log
olcLogLevel: conns stats stats2 sync
olcTLSCACertificateFile: /etc/pki/tls/certs/DS-CA.crt
olcTLSCertificateFile: /etc/pki/tls/certs/slapd.crt
olcTLSCertificateKeyFile: /etc/pki/tls/private/slapd.key.crt
olcTLSCipherSuite: TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!RC4:@STRENGTH
olcTLSVerifyClient: demand
olcLocalSSF: 256
olcSecurity: ssf=256
olcPasswordCryptSaltFormat: $6$%s
olcPasswordHash: {CRYPT}
olcServerID: 1 ldap://ldap01
olcServerID: 2 ldap://ldap02
# load modules
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/local/lib64/openldap-2.4
olcModuleload: {0}syncprov.la
olcModuleload: {1}accesslog.la
olcModuleLoad: {2}back_mdb.la
olcModuleLoad: {3}back_monitor.la
olcModuleLoad: {4}memberof.la
olcModuleLoad: {5}refint.la
olcModuleLoad: {6}ppolicy.la
# schema definitions
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# include the schemas
include: file:///etc/openldap-2.4/schema/core.ldif
include: file:///etc/openldap-2.4/schema/corba.ldif
include: file:///etc/openldap-2.4/schema/cosine.ldif
include: file:///etc/openldap-2.4/schema/duaconf.ldif
include: file:///etc/openldap-2.4/schema/dyngroup.ldif
include: file:///etc/openldap-2.4/schema/inetorgperson.ldif
include: file:///etc/openldap-2.4/schema/java.ldif
include: file:///etc/openldap-2.4/schema/misc.ldif
include: file:///etc/openldap-2.4/schema/nis.ldif
include: file:///etc/openldap-2.4/schema/openldap.ldif
include: file:///etc/openldap-2.4/schema/ppolicy.ldif
include: file:///etc/openldap-2.4/schema/collective.ldif
# global database parameters
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
# setup cn=config (password = 1234)
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: {CRYPT}$6$...
olcSyncrepl: {0}rid=001 provider=ldap://ldap01
binddn="cn=Manager,dc=test"
bindmethod=sasl saslmech=external
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcSyncrepl: {1}rid=002 provider=ldap://ldap02
binddn="cn=Manager,dc=test"
bindmethod=sasl saslmech=external
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcMirrorMode: TRUE
olcAccess: to *
by dn.exact="cn=Manager,dc=test" write
by * none
olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# add the syncprov overlay to the cn=config database
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
# setup monitoring
dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMonitorConfig
olcDatabase: monitor
olcAccess: to dn.subtree=cn=Monitor
by dn.exact="cn=config" write
by dn.exact="cn=Manager,dc=test" write
by * none
# setup Accesslog database definitions
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lib/ldap-2.4/accesslog
olcSuffix: cn=accesslog
olcAccess: {0}to dn.subtree="cn=accesslog"
by dn.exact="cn=Manager,dc=test" read
olcRootDN: cn=Manager,dc=test
olcDbIndex: objectClass,entryCSN,reqStart,reqEnd,reqResult,reqDN eq
olcDbMode: 0600
# max size in bytes - 1GB = 1073741824 bytes
olcDbMaxsize: 1073741824
# add the syncprov overlay to the cn=accesslog database
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
# up to here ^^^ is also the config for the "slave"
# main mdb database definition
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {3}mdb
olcSuffix: dc=test
olcDbDirectory: /var/lib/ldap-2.4/test
olcRootDN: cn=Manager,dc=test
olcRootPW: {CRYPT}$6$...
olcSyncrepl: {0}rid=003 provider=ldap://ldap01
binddn="cn=Manager,dc=test"
bindmethod=sasl saslmech=external
searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager_nopass.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcSyncrepl: {1}rid=004 provider=ldap://ldap02
binddn="cn=Manager,test"
bindmethod=sasl saslmech=external
searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcMirrorMode: TRUE
olcDbIndex: cn pres,eq,sub
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: memberUid pres,eq
olcDbIndex: objectClass pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: uid pres,eq
olcDbIndex: uidNumber pres,eq
olcDbIndex: entryCSN,entryUUID eq
olcDbMode: 0600
# max size in bytes - 1GB = 1073741824 bytes
olcDbMaxSize: 5368709120
olcAccess: to attrs=userPassword
by dn.exact="cn=Manager,dc=test" write
by self write
by anonymous auth
by * none
olcAccess: to *
by dn.exact="cn=Manager,dc=test" write
by self read
by * read
olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# add the syncprov overlay to the main mdb database
dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckPoint: 20 10
# add the accesslog overlay to the main mdb database
dn: olcOverlay={1}accesslog,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
olcAccessLogPurge: 01+00:00 04+00:00
# add memberof overlay to mdb database
dn: olcOverlay={2}memberof,olcDatabase={3}mdb,cn=config
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
# add refint overlay to mdb database
dn: olcOverlay={3}refint,olcDatabase={3}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: refint
olcRefintAttribute: member memberOf
olcRefintNothing: cn=Manager,dc=test
# add the ppolicy overlay to the main mdb database
dn: olcOverlay={4}ppolicy,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=test
olcPPolicyHashCleartext: TRUE
$ sudo /usr/local/bin/ldapadd -v -f ./test-data.ldif x -D
"cn=Manager,dc=test" -w $(cat ./ldap.secret) -d0 -ZZ
# Organization
dn: dc=test
objectClass: dcObject
objectClass: organization
dc: test
o: Test
description: Test LDAP Root
# add ppolicy ou
dn: ou=policies,dc=test
ou: policies
objectClass: top
objectClass: organizationalUnit
# add password policy
dn: cn=default,ou=policies,dc=test
cn: default
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
objectClass: person
objectClass: top
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdExpireWarning: 600
pwdFailureCountInterval: 30
pwdGraceAuthNLimit: 5
pwdInHistory: 5
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdMaxAge: 0
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 5
pwdMustChange: FALSE
pwdSafeModify: FALSE
pwdCheckModule: check_password.so
sn: dummy value
...
Thanks!
Regards,
Patrick
9 years, 11 months
Used port
by Muhammad Bashir Al-Noimi
Hello,
As I know OpenLDAP uses by default 389. How can I be sure what if my
server use it or not?
--
Best Regards
Muhammad Bashir Al-Noimi
9 years, 11 months
libpam-ldapd issue
by Muhammad Bashir Al-Noimi
Hello,
I installed OpenLDAP under Ubuntu 13.04 x64 by using the mentioned
steps in this article (
http://edin.no-ip.com/blog/hswong3i/ldap-single-sign-webmin-ubuntu-12-04-...
) the problem I've faced that my system cannot lookup Unix users in
the LDAP database because I couldn't configure libpam-ldapd to enable
Unix authentication, LDAP Authentication.
How can I fix this issue?
P.S.
I'm still a newbie with LDAP so forgive me for silly question.
I tried to use dpkg-reconfigure libpam-ldapd but it didn't ask me anything!
--
Best Regards
Muhammad Bashir Al-Noimi
9 years, 11 months
slapd deferring operation?
by Aleksander Dzierżanowski
Hi.
I’m trying to migrate small other vendor LDAP server to OpenLDAP.
I've created test environment with 3 multimaster OpenLDAP instances - version 2.4.36. Below is some strange behavior of slapd while I was adding few hunderd of accounts from ldif file using ‚ldapadd’ command from remote host.
[…]
conn=1015 op=440 ADD dn=„uid=XXX,ou=People,ou=developers,o=test"
conn=1015 op=440 RESULT tag=105 err=0 text=
connection_input: conn=1015 deferring operation: too many executing
conn=1015 op=441 ADD dn=„uid=YYY,ou=People,ou=developers,o=test"
conn=1015 op=441 RESULT tag=105 err=0 text=
[…]
My question is what does mean 'deferring operation’ - as you can see result is OK (err=0) so nothing was really deferred. Database is really small - few hundred entries, and server is not used at all by any other machine. I was using rootdn user which I suppose does not have any limits for search/add/mod operations?
Is it some configuration issue? I also observe the same ‚deferring’ info in log file when there is only a single host client connected to this LDAP server - RedHat/CentOS with configured sssd. They are not so often but appear regularly.
—
Olo
9 years, 11 months
