Re: Problem getting monitor backend and syncrepl overlay to work
by Benjamin Griese
Hi david,
i'm not sure about that, by havn't figured out why the credentials have to
be in cleartext, but that was only possibility I got syncrepl working since
I tried it with SSHA or MD5 prefixes.
Did you tried that in cleartext?
just my two bucks and a half
benjamin
On Wed, Mar 10, 2010 at 10:01, DeMoNs(a)web.de <DeMoNs(a)web.de> wrote:
> Hi all,
>
> i have a problem getting openldap to run monitor backend AND syncrepl
> overlay.
> i'm running freebsd-7.2-release-p6 in combination with
> openldap-server-2.4.19 with sasl support compiled in.
>
> i use the following slapd config:
>
> include /usr/local/etc/openldap/schema/core.schema
> include /usr/local/etc/openldap/schema/cosine.schema
> include /usr/local/etc/openldap/schema/nis.schema
> include /usr/local/etc/openldap/schema/inetorgperson.schema
> include /usr/local/etc/openldap/schema/misc.schema
> include /usr/local/etc/openldap/schema/ldapns.schema
> include /usr/local/etc/openldap/schema/radius.schema
>
> pidfile /var/run/openldap/slapd.pid
> argsfile /var/run/openldap/slapd.args
> logfile /var/log/slapd.log
>
> password-hash {SSHA}
> modulepath /usr/local/libexec/openldap
> moduleload back_bdb
> moduleload back_monitor
>
> access to dn.base="" by * read
> access to dn.base="cn=Subschema" by * read
> access to *
> by ssf=128 dn="cn=admin,dc=example,dc=de" write
> by dn="cn=admin,dc=example,dc=de" peername.ip=127.0.0.1 write
> by ssf=96 dn="cn=nssadmin,dc=example,dc=de" read
> by dn="cn=nssadmin,dc=example,dc=de" peername.ip=127.0.0.1 read
> by anonymous auth
> by * none
> access to attrs=userPassword
> by self write
> by anonymous auth
> by * none
>
> database bdb
> suffix "dc=example,dc=de"
> rootdn "dc=example,dc=de"
> directory /var/db/openldap-data
> index objectClass,entryCSN,entryUUID eq
> index uid pres,eq,sub
> index memberUID eq
> index uidNumber,gidNumber eq
> index host eq
>
> database monitor
> rootdn "cn=monitoring,cn=Monitor"
> rootpw monitoring
>
> access to dn.subtree="cn=Monitor"
> by dn="cn=nssadmin,dc=example,dc=de"
> by * none
>
> syncrepl rid=041
> provider=ldap://ldap-master.example.de
> type=refreshOnly
> interval=00:00:35:00
> searchbase="dc=example,dc=de"
> schemachecking=off
> bindmethod=simple
> starttls=yes
> binddn="cn=syncuser,dc=example,dc=de"
> credentials="strongsecretpassword"
>
> TLSCertificateFile /usr/local/etc/openldap/ssl/ldap-crt.pem
> TLSCertificateKeyFile /usr/local/etc/openldap/ssl/ldap-key.pem
> TLSCACertificateFile /usr/local/etc/openldap/ssl/cacert.pem
>
> loglevel 256
>
> now, when i run slaptest i receive following error:
>
> /usr/local/etc/openldap/slapd.conf: line 59: database monitor does not
> support operations required for syncrepl
> slaptest: bad configuration file!
>
> Line 59 corresponds to the credentials option in the synrepl statement.
> i can't figure out whats wrong, so if anyone can point me in the right
> direction that would be really helpful.
>
> thanks in advance,
> david
>
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
14 years, 8 months
RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
For this testing call, we particularly need folks to test OpenLDAP with
startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with
the 1.1 series). There is currenly nothing in the test suite that covers
encrypted connections (Although it's on my todo list). To build against
OpenSSL 1.1 may also require cyrus-sasl HEAD out of the cyrus-sasl GIT
repository, depending on your build options as the current cyrus-sasl
release does not support the OpenSSL 1.1 series. It can be found at
<https://github.com/cyrusimap/cyrus-sasl>. If you build with GSSAPI and
use Heimdal, you will also need the Heimdal 7.1.0 or later release (as that
is where OpenSSL 1.1 support was added). It can be obtained from
<http://h5l.org/>.
Also new with this release is the ability to run "make its" in the tests/
directory. This will run a specific set of tests around past bugs to
ensure there are no regressions. While I've tested this with modular
openldap builds, it has not been tested with the modules and backends built
into slapd, so there could be some issues in that scenario.
Generally, get the code for RE24:
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…>
Configure & build.
Execute the test suite (via make test) after it is built. Optionally, cd
tests && make its run through the regression suite.
Thanks!
OpenLDAP 2.4.45 Engineering
Added slapd support for OpenSSL 1.1.0 series (ITS#8353, ITS#8533)
Fixed libldap handling of Diffie-Hellman parameters (ITS#7506)
Fixed libldap GnuTLS use after free (ITS#8385)
Fixed slapd sasl SEGV rebind in same session (ITS#8568)
Fixed slapd syncrepl filter handling (ITS#8413)
Fixed slapd syncrepl infinite looping mods with delta-sync MMR
(ITS#8432)
Fixed slapd callback struct so older modules without writewait
should function.
Custom modules may need to be updated for sc_writewait
callback (ITS#8435)
Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794)
Fixed slapd-meta uninitialized diagnostic message (ITS#8442)
Fixed slapo-accesslog to honor pauses during purge for cn=config
update (ITS#8423)
Fixed slapo-relay to correctly initialize sc_writewait (ITS#8428)
Build Environment
Added test065 for proxyauthz (ITS#8571)
Fix test008 to be portable (ITS#8414)
Fix its4336 regression test (ITS#8534)
Fix its4337 regression test (ITS#8535)
Fix regression tests to execute on all backends (ITS#8539)
Contrib
Added slapo-autogroup(5) man page (ITS#8569)
Added passwd missing conversion scripts for apr1 (ITS#6826)
Fixed contrib modules where the writewait callback was not
correctly initialized (ITS#8435)
Fixed smbk5pwd to build with newer OpenSSL releases
(ITS#8525)
Documentation
admin24 fixed tls_cipher_suite bindconf option (ITS#8099)
admin24 fixed typo cn=config to be slapd.d (ITS#8449)
Fixed slapd-config(5), slapd.conf(5) clarification on
interval keyword for refreshAndPersist (ITS#8538)
Fixed slapo-ppolicy(5) to clearly note rootdn requirement
(ITS#8565)
Fixed various minor grammar issues in the man pages
(ITS#8544)
LMDB 0.9.20 Release Engineering
Fix mdb_load with escaped plaintext (ITS#8558)
Fix mdb_cursor_last / mdb_put interaction (ITS#8557)
LMDB 0.9.19 Release (2016/12/28)
Fix mdb_env_cwalk cursor init (ITS#8424)
Fix robust mutexes on Solaris 10/11 (ITS#8339)
Tweak Win32 error message buffer
Fix MDB_GET_BOTH on non-dup record (ITS#8393)
Optimize mdb_drop
Fix xcursors after mdb_cursor_del (ITS#8406)
Fix MDB_NEXT_DUP after mdb_cursor_del (ITS#8412)
Fix mdb_cursor_put resetting C_EOF (ITS#8489)
Fix mdb_env_copyfd2 to return EPIPE on SIGPIPE (ITS#8504)
Fix mdb_env_copy with empty DB (ITS#8209)
Fix behaviors with fork (ITS#8505)
Fix mdb_dbi_open with mainDB cursors (ITS#8542)
Fix robust mutexes on kFreeBSD (ITS#8554)
Fix utf8_to_utf16 error checks (ITS#7992)
Fix F_NOCACHE on MacOS, error is non-fatal (ITS#7682)
Build
Make shared lib suffix overridable (ITS#8481)
Documentation
Cleanup doxygen nits
Note reserved vs actual mem/disk usage
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7 years, 9 months
RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Thursday, February 02, 2017 1:01 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
>> From: Quanah Gibson-Mount
>> Subject: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
>>
>> For this testing call, we particularly need folks to test OpenLDAP with
>> startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and
>> with the 1.1 series).
>
> Compiled successfully with Gentoo linux and openSSL 1.02j/cyrus-sasl
> 2.1.26, configured as:
>
> --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
> --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking
> --disable-silent-rules --libdir=/usr/lib64
> --libexecdir=/usr/lib64/openldap --disable-static --enable-ldap
> --enable-slapd --enable-bdb --enable-hdb --enable-dnssrv=mod
> --enable-ldap=mod --enable-mdb=mod --enable-meta=mod --enable-monitor=mod
> --enable-null=mod --enable-passwd=mod
> --enable-relay=mod --enable-shell=mod --enable-sock=mod --disable-perl
> --disable-sql --disable-crypt --disable-slp --disable-lmpasswd
> --enable-syslog --enable-aci --enable-cleartext --enable-modules
> --enable-rewrite --enable-rlookups --enable-slapi --enable-syncprov=yes
> --enable-overlays=mod --enable-ipv6 --with-cyrus-sasl --enable-spasswd
> --disable-wrappers --with-tls=openssl --enable-dynamic --enable-local
> --enable-proctitle --enable-shared
>
> make test completed successfully, is there any particular way to verify
> all the tests were okay? Does the make itself fail if any of the tests
> do, I did not see a summary at the end. make its was not as happy:
"make test" will do a single pass through the entire test suite, for each
backend. Unfortunately, that does not always catch issues. For example,
the issue Dieter reported against HEAD with test061 only happens to me
occassionaly. To help with that, there is the abilty to run the test suite
in a loop, for a given backend. Like:
quanah@ub16:~/openldap-2.4.45RC/tests$ ./run -l 500 -b mdb test061
Will run test061 500 times, using back-mdb as the backend. Instead of a
specific test, one can do "all" to run everything through a loop X times.
>>>>>> Starting its4326 ...
> running defines.sh
> Running slapadd to build slapd database...
> Starting slapd on TCP/IP port 9011...
> Using ldapsearch to check that slapd is running...
> Starting proxy slapd on TCP/IP port 9012...
> Using ldapsearch to check that proxy slapd is running...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> ldapsearch failed (255)!
> ./data/regressions/its4326/its4326: line 93: kill: (28780) - No such
> process
>>>>>> ./data/regressions/its4326/its4326 failed (exit 255)
Interesting... it may be worthwhile to look in the testrun directory and
see why slapd failed to launch. I'll see if I can reproduce it as well.
> I see the fix for ITS8432 is included in this release (yay); I was
> wondering if you've had any luck tracking down the underlying issue
> behind ITS8444? So far I still haven't seen any corruption or operational
> issues from it, but the rampant noise in the logs and errors being
> generated are quite disconcerting :). Plus they will potentially mask any
> errors that are actually indicative of a real problem.
I've not been able to reproduce it. There's a regression test I wrote for
it included in the RE24 source, but it's never really triggered for me.
Please feel free to look it over and see if I've missed anything obvious in
my reproduction attempts. :)
You can execute it directly with ./run -b mdb its8444
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
7 years, 9 months
Re: Security between server and client nodes.
by Raffael Sahli
On 11/30/2011 01:48 PM, Jayavant Patil wrote:
>
>
> >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> >>
> >>
> >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>
> <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>> wrote:
> >>
> >>
> >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>> wrote:
> >> >>Hi
> >>
> >> >>I think you mean SSL connection or the STARTTLS Layer...?
> >> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
> >> >Ok.
> >>
> >> >>And tree security:
> >> >>On my server, a client user can only see his own object:
> >> >Are you using simple authentication mechanism?
> >>
> >> >>Maybe create a rule like this:
> >> >>access to filter=(objectClass=
> >> >>simpleSecurityObject)
> >> >> by self read
> >> >> by * none
> >>
> >> >I am not getting what the ACL rule specifies. Any suggestions?
> >>
> >>
> >> I have two users ldap_6 and ldap_7. I want to restrict a user to
> >> see his own data only.
> >> In slapd.conf, I specified the rule as follows:
> >> access to *
> >> by self write
> >> by * none
> >>
> >> But ldap_6 can see the ldap_7 user entries (or vice versa) with
> >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> >>
> >> Any suggestions?
> >>
> >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >Yes, that's exactly the rule I wrote above.
>
> >access to filter=(objectClass=
> >simpleSecurityObject)
> > by self read
> > by * none
>
>
> >Maybe you have to change the objectClass to posixAccount, or both or
> >whatever....
>
> >access to
> >filter=(|(objectClass=simpleSecurityObject)(objectClass=posixAccount))
> > by self read
> > by * none
>
>
> >Just add this rule before the global rule "access to *"
>
>
> >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>
> >And if you search like this with bind "admin dn", you will see every
> >object....
> >You have to bind with user ldap_6 and not with root
> But anyway client user knows the admin dn and rootbindpassword. So,
> with this he will look into all directory information to which he is
> not supposed to do.
> e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
>
> So, how to avoid this?
>
Why client user knows the admin dn and pw????????
>
>
> --
>
> Thanks & Regards,
> Jayavant Ningoji Patil
> Engineer: System Software
> Computational Research Laboratories Ltd.
> Pune-411 004.
> Maharashtra, India.
> +91 9923536030.
>
--
Raffael Sahli
public(a)raffaelsahli.com
12 years, 11 months
Re: client server connection to LDAP/Kerberos
by Dan White
On 02/01/13 10:08 +1100, Asmaa Ahmed wrote:
>Hello,
>
>I recently added Kerberos authentication to my LDAP server, and I am trying
>to connect the other servers to it.
>I have a server running Davical shared calendar, and I hope to get it
>working with my LDAP server again after Kerberos integration.
>
>Here is my configuration which was working before the integration and my
>source is
>"http://wiki.davical.org/w/Configuration/LDAP#Kerberos_Authentication"
>
> $c->authenticate_hook['config'] = array(
> 'host' => 'ldap.domain.com', //host name of your LDAP Server
> 'port' => '389', //port
>// 'bindDN' => 'cn=admin,dc=domain,dc=com', //DN to bind request
>// to this server (if required)
>// 'passDN' => 'password', //Password of request bind
> 'baseDNUsers' => 'ou=People,dc=domain,dc=com', //where to look for
>valid user
> 'filterUsers' => 'objectClass=*', //filter which must validate a user
>according to RFC4515, i.e. surrounded by brackets
> 'protocolVersion' => 3, // important for simple auth (no sasl)
>// 'startTLS' => true, // securing your LDAP connection
> 'i_use_mode_kerberos' => "i_know_what_i_am_doing",
>
>My slapd error logs:
>Jan 31 23:40:00 ldap slapd[1059]: conn=1273 fd=43 ACCEPT from
>IP=203.28.247.193:56887 (IP=0.0.0.0:389)
>Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 BIND dn="" method=128
>Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 RESULT tag=97 err=0 text=
>Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH
>base="ou=People,dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"
>Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH attr=uid
>modifyTimestamp cn mail
>Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SEARCH RESULT tag=101
>err=32 nentries=0 text=
>Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=2 UNBIND
>
>My OLC configuration:
>root@ldap:/var/log# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config
>"(|(cn=config)(olcDatabase={1}hdb))"
>dn: cn=config
>objectClass: olcGlobal
>cn: config
>olcArgsFile: /var/run/slapd/slapd.args
>olcAuthzRegexp: {0}uid=([^,]+),cn=domain.com,cn=gssapi,cn=auth uid=$1
> ,ou=people,dc=domain,dc=com
>olcLogLevel: stats
>olcPidFile: /var/run/slapd/slapd.pid
>olcSaslRealm: DOMAIN.COM
>olcToolThreads: 1
>
>dn: olcDatabase={1}hdb,cn=config
>objectClass: olcDatabaseConfig
>objectClass: olcHdbConfig
>olcDatabase: {1}hdb
>olcDbDirectory: /var/lib/ldap
>olcSuffix: dc=domain,dc=com
>olcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by *
>no
> ne
>olcAccess: {1}to dn.subtree="ou=krb5,dc=domain,dc=com" by dn="c
> n=adm-srv,ou=krb5,domain,dc=com" write by dn="cn=kdc-srv,ou
> =krb5,domain,dc=com" read by * none
>olcAccess: {2}to attrs=loginShell,gecos by self write by users read by *
>none
>olcAccess: {3}to dn.base="" by * read
>olcAccess: {4}to * by users read by * none
>olcLastMod: TRUE
>olcRootDN: uid=admin,ou=people,domain,dc=com
>
>
>Any suggestion to fix the binding and get my search working again with
>kerberos authentication ?
>
>Thanks.
Can you reproduce this problem with ldapsearch and/or ldapwhoami (-Y
GSSAPI) on the server which is running davical?
--
Dan White
11 years, 9 months
Re: Syncrepl N-Way multimaster replication - Configuration issue on Rhel6
by coma
Hello Ulrich,
thank you very much for your prompt reply.
Sorry, it was a copy/paste error, i've added the port in the URI but it
made no difference whatever I do (test other port, test with default
port...), error "read_config: no serverID / URL match found." was always
present.
But today i've solved the issue by upgrading my servers and reboot them,
but for the moment i' don't understand what was exactly the cause, maybe a
conflict on name resolution, error messages in debug mode point in this
direction (getaddrinfo() failed even the host is existing and resolved by
DNS).
About my second issue, it was a stupid mistake from my part, slapd was
listening only on localhost due to an entry in /etc/hosts (i added my
server name as alias of 127.0.0.1).
Thanks you again,
Regards,
2014-11-28 8:42 GMT+01:00 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>:
> >>> coma <coma.inf(a)gmail.com> schrieb am 27.11.2014 um 17:18 in Nachricht
> <CABnSCoknUmvmY_eJPac9mDqsWcja57b8W_1gT09VFZv0=ncFpA(a)mail.gmail.com>:
> > Hello everybody,
> > i'm currently tring to configure N-Way multimaster replication, and
> > i'm facing two issues with olcServerId and slapd -h options.
> >
> > For information:
> > I'm running on Rhel6.6 with openldap 2.4.39-8.
> > I'm running slapd on non-standard ports (11389 for ldap and ldap with
> > TLS, and 11390 for ldaps)
> > I've tried on standard ports but same issues.
> > I've configured the replication following these two procedures:
> > https://access.redhat.com/solutions/273533
> >
> http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
> >
> > - First Issue details:
> >
> > When i'm adding olcServerID's on both servers, using following ldif:
> >
> > cat <<EOF | ldapmodify -Y EXTERNAL -H ldapi:///
> > dn: cn=config
> > changetype: modify
> > replace: olcServerID
> > olcServerID: 1 ldap://server1-test1.test.com
> > olcServerID: 2 ldap://server2-test1.test.com
> > EOF
>
> Why didn't you add the port to your URI? You should have known that with a
> non-default port at least your URI won't match your server's configuration.
> Same for ldap: vs ldaps: I guess.
>
> >
> > i'm no longer able to restart slapd. Error is: read_config: no
> > serverID / URL match found. Check slapd -h arguments.
> >
> > To resolve it, i've tried to add the URL of my servers in
> > correspondant /etc/sysconfig/ldapExample:
> >
> > SLAPD_LDAP=no
> > SLAPD_LDAPI=yes
> > SLAPD_LDAPS=no
> > SLAPD_URLS="ldap://server1-test1.test.com:11389
> > ldaps://server1-test1.test.com:11390"
> >
> > But issue "Error is: read_config: no serverID / URL match found." is
> > always present event after a server reboot and a full openldap
> > reinstallationn.
> >
> > - Second issue détails (replication disabled, serverID's removed):
> >
> > With /etc/sysconfig/ldap configured as:
> > SLAPD_LDAP=no
> > SLAPD_LDAPI=yes
> > SLAPD_LDAPS=no
> > SLAPD_URLS="ldap://:11389 ldaps://:11390"
> >
> > i'm able to connect on port 11389/11390 with clear, starttls and SSL
> > using a ldap browser or ldapsearch,
> >
> > But with /etc/sysconfig/ldap configured as:
> > SLAPD_LDAP=no
> > SLAPD_LDAPI=yes
> > SLAPD_LDAPS=no
> > SLAPD_URLS="ldap://server1-test1.test.com:11389
> > ldaps://server1-test1.test.com:11390"
> >
> > i'm not able to connect anymore.
>
> How do your certificates look like?
>
>
> Regards,
> Ulrich
>
> >
> > Can you please help me on this?
> >
> > Thanks in advance,
>
>
>
>
9 years, 11 months
Syncrepl only partially working
by Joshua Schaeffer
Greetings all,
I'm trying to figure out why Syncrepl is only syncing part of my provider's database when I use GSSAPI to connect. Both my provider and consumer are on 2.4.40. Here are all the steps I'm taking:
My provider is working fine, I've been using it for months now without any issues. I added this to the provider:
dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 10
structuralObjectClass: olcSyncProvConfig
entryUUID: b32ac160-29e6-1036-8d0a-07ef98fd592e
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20161019012544Z
olcSpSessionlog: 100
entryCSN: 20161024233803.817199Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161024233803Z
I also indexed entryCSN and entryUUID on the provider. I have olcAuthzRegexp setup on the provider as well.
olcAuthzRegexp: {0}"uid=admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=admin,dc=harmonywave,dc=com"
olcAuthzRegexp: {1}"uid=ldap/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
olcAuthzRegexp: {2}"uid=syncprov,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=syncprov,dc=harmonywave,dc=com" #not using this.
olcAuthzRegexp: {3}"uid=.*\/admin,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=admin,dc=harmonywave,dc=com"
olcAuthzRegexp: {4}"uid=host\/([^.]*).harmonywave.com,cn=harmonywave.com,cn=GSSAPI,cn=auth" "cn=$1+ipHostNumber=.*,ou=Hosts,dc=harmonywave,dc=com"
olcAuthzRegexp: {5}"uid=([^/]*),cn=harmonywave.com,cn=GSSAPI,cn=auth" "uid=$1,ou=End Users,ou=People,dc=harmonywave,dc=com"
On the consumer I have slapd installed. The first thing I did was change the olcSuffix on my database. I'm not sure if this is required or not.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=harmonywave,dc=com
-
replace: olcRootDN
olcRootDN: cn=admin,dc=harmonywave,dc=com
Then I'm adding my ldap keytab for the consumer.
kadmin: ktadd -k /etc/ldap/ldap.keytab ldap/consumer.harmonywave.com
consumer: ~# chown openldap:openldap /etc/ldap/ldap.keytab
consumer: ~# chmod 0640 /etc/ldap/ldap.keytab
I edited my /etc/default/slapd file and pointed the KRB5_KTNAME environment variable to the new keytab then restarted slapd. Next I installed kstart and created a ticket cache.
consumer: ~# k5start -U -f /etc/ldap/ldap.keytab -K 10 -l 24h -k /tmp/krb5cc_108 -o openldap -b
I can see the ldap service's keytab with klist.
consumer: ~# klist /tmp/krb5cc_108
Ticket cache: FILE:/tmp/krb5cc_108
Default principal: ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM
Valid starting Expires Service principal
10/28/2016 21:18:14 10/29/2016 07:18:14 krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM
renew until 10/29/2016 21:18:14
Then I add my olcSaslRealm
dn: cn=config
changetype: modify
add: olcSaslRealm
olcSaslRealm: HARMONYWAVE.COM
Here is what my database looks like right before I add olcSyncrepl:
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym
ous auth by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRootPW:: ...
olcDbCheckpoint: 512 30
olcDbMaxSize: 1073741824
structuralObjectClass: olcMdbConfig
entryUUID: 9a091324-2e84-1036-8b7a-73db8891632a
creatorsName: cn=admin,cn=config
createTimestamp: 20161024222607Z
olcSuffix: dc=harmonywave,dc=com
olcRootDN: cn=admin,dc=harmonywave,dc=com
olcDbIndex: cn,uid eq
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: member,memberUid eq
olcDbIndex: objectClass eq
olcDbIndex: uidNumber,gidNumber eq
entryCSN: 20161029033105.691204Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20161029033105Z
then I add olcSyncrepl to the consumer.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: {0}rid=000
provider=ldap://provider.harmonywave.com
type=RefreshAndPersist
retry="30 10 1800 +"
searchbase="dc=harmonywave,dc=com"
bindmethod=sasl
saslmech=GSSAPI
starttls=critical
tls_cacert=/etc/ssl/certs/ca.harmonywave.com.pem
tls_reqcert=demand
After that I slapcat on the consumer and I only see about 1/3 of my data from the provider. When I watch the log on the provider this is what I get:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 ACCEPT from IP=10.1.30.19:55992 (IP=0.0.0.0:389)
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 STARTTLS
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=0 RESULT oid= err=0 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 TLS established tls_ssf=128 ssf=128
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=krbtgt/HARMONYWAVE.COM(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43768 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/baneling.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43769 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(&(|(objectClass=krbPrincipalAux)(objectClass=krbPrincipal))(krbPrincipalName=ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM))"
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SRCH attr=krbprincipalname krbcanonicalname objectclass krbprincipalkey krbmaxrenewableage krbmaxticketlife krbticketflags krbprincipalexpiration krbticketpolicyreference krbUpEnabled krbpwdpolicyreference krbpasswordexpiration krbLastFailedAuth krbLoginFailedCount krbLastSuccessfulAuth krbLastPwdChange krbLastAdminUnlock krbExtraData krbObjectReferences krbAllowedToDelegateTo
Oct 28 21:39:02 baneling slapd[12540]: conn=1005 op=43770 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=1 RESULT tag=97 err=14 text=SASL(0): successful result:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=2 RESULT tag=97 err=14 text=SASL(0): successful result:
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND dn="" method=163
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND authcid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM" authzid="ldap/koprulu.harmonywave.com(a)HARMONYWAVE.COM"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 BIND dn="uid=ldap/koprulu.harmonywave.com,cn=harmonywave.com,cn=gssapi,cn=auth" mech=GSSAPI sasl_ssf=56 ssf=128
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=3 RESULT tag=97 err=0 text=
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH base="dc=harmonywave,dc=com" scope=2 deref=0 filter="(objectClass=*)"
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=4 SRCH attr=* +
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 op=5 UNBIND
Oct 28 21:39:02 baneling slapd[12540]: conn=4421 fd=36 closed
The only thing I really notice from this is near the end of the file. It when it searches the base with attributes "*+", but then immediately unbinds. I've seen people stating that authzid is required, but when I don't provide it I still get a partial sync, so I'm not sure about this. I've restored my consumer to a clean install of slapd and repeated the above steps with minor variations several times but the consumer always syncs the exact same amount of data and then seems to stop.
Any help to point me in the right direction would be appreciated.
Thanks,
Joshua Schaeffer
**
8 years
RE: Multi Master OpenLdap.
by arun.sasi1＠wipro.com
Thank you very much Eli for concidering my issue. Here is my scenario...
I couldn’t find any abnormality in log files and also I never seen any deletion logs in the server. Slapd will go for hang and some ID`s will get disappear same will be replicate to slaves too. Mainly Groups and Computer accounts
I can see some UNBIND and connection lost logs from one server and another multimaster server from
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138411 op=24 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SRCH base="sambaDomainName=EMB,sambaDomainName=emb,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaTrustedDomainPassword)(sambaDomainName=emb))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(|(displayName=test)(cn=test)))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (displayName) not indexed
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (cn) not indexed
Jul 11 04:07:53 gb0135embldap01 slapd[21335]: @(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $ ^Ibuildd@yellow:/build/buildd/openldap-2.4.15/debian/build/servers/slapd
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: slapd starting
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=0 fd=23 ACCEPT from IP=[::1]:57016 (IP=[::]:389)
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=1 fd=24 ACCEPT from IP=134.32.44.37:40763 (IP=0.0.0.0:389)
OLCDATABSE
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=emb,dc=slb,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by anonymous auth by self write
by * none
olcAccess: {1}to dn.base="" by * read
#Enable Local Admin to add users in the Group and also SunOne to add users to country groups
olcAccess: {2}to dn.subtree="ou=groups,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable Local Admin to add computers
olcAccess: {3}to dn.subtree="ou=Computers,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by * read
#Enable shell-admin to set up local user access
olcAccess: {4}to attrs=loginShell,homeDirectory
by set="user/uid & [cn=shell-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable write access to account sun-one-replication for sun ldap replication.
olcAccess: {5}to *
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub
structuralObjectClass: olcHdbConfig
entryUUID: f479600a-5f34-102f-8ddd-3ff046e70702
creatorsName: cn=admin,cn=config
createTimestamp: 20100928101442Z
olcRootDN: cn=admin,dc=emb,dc=slb,dc=com
olcSyncrepl: {0}rid=003 provider=ldap://gb0135embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcSyncrepl: {1}rid=004 provider=ldap://ae0042embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcMirrorMode: TRUE
entryCSN: 20100928191927.932499Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100928191927Z
Ldap Version
@(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $
Operating system
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
Thanks,
-Arun
-----Original Message-----
From: E.S. Rosenberg [mailto:esr@g.jct.ac.il]
Sent: Monday, July 11, 2011 12:58 PM
To: Arun Sasi V (WI01 - Manage IT)
Cc: openldap-technical(a)openldap.org
Subject: Re: Multi Master OpenLdap.
Have you tried raising the loglevel?
Are the schemas the same between the servers?
Is time in sync between the servers?
What versions are you dealing with?
You don't provide a lot of info and most of us are not clairvoyant....
Regards,
Eli
2011/7/11 <arun.sasi1(a)wipro.com>:
>
>
>
>
> Thanks,
>
> -Arun
>
>
>
> From: Arun Sasi V (WI01 - Manage IT)
> Sent: Wednesday, July 06, 2011 5:46 PM
> To: 'openldap-technical(a)openldap.org'
> Subject: Multi Master OpenLdap.
>
>
>
> Hello Team,
>
>
>
> I have configured Multi-master Mirror mode replica setup in our environment.
> We have 3 regions slave Ldap server which is read only and two location we
> have configured as mirror mode replica Ldap. My problem here is…
>
>
>
> Master Ldap is going hang some times and some ID`s are disappearing from the
> master server. I couldn’t find any logs over there for why ID`s are
> disappearing and also why Ldap is going hung state.
>
>
>
> Thanks & Regards,
>
> Arun Sasi V
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
13 years, 4 months
TLS negotiation failure
by aRaviNd
Hi All,
I am trying to debug an issue related to Chef-manage WebUI trying to
authenticate users using LDAP. Authentication was working fine but after
upgrading the LDAP server to the latest version of the OS we are getting
authentication failures below are the errors showing in the log
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14)
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14): got connid=1003
Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): checking for
input on id=1003
Jul 13 20:26:52 ldap.local slapd[18572]: op tag 0x77, time 1657744012
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 do_extended
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jul 13 20:26:52 ldap.local slapd[18572]: do_extended:
oid=1.3.6.1.4.1.1466.20037
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 STARTTLS
Jul 13 20:26:52 ldap.local slapd[18572]: send_ldap_extended: err=0 oid=
len=0
Jul 13 20:26:52 ldap.local slapd[18572]: send_ldap_response: msgid=0
tag=120 err=0
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 op=0 RESULT oid= err=0
text=
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on:
Jul 13 20:26:52 ldap.local slapd[18572]:
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=9
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=10
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=11
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on:
Jul 13 20:26:52 ldap.local slapd[18572]: 14r
Jul 13 20:26:52 ldap.local slapd[18572]:
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: read active on 14
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=9
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=10
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: epoll: listen=11
active_threads=0 tvp=NULL
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14)
Jul 13 20:26:52 ldap.local slapd[18572]: connection_get(14): got connid=1003
Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): checking for
input on id=1003
Jul 13 20:26:52 ldap.local slapd[18572]: connection_read(14): TLS accept
failure error=-1 id=1003, closing
Jul 13 20:26:52 ldap.local slapd[18572]: connection_closing: readying
conn=1003 sd=14 for close
Jul 13 20:26:52 ldap.local slapd[18572]: connection_close: conn=1003 sd=14
Jul 13 20:26:52 ldap.local slapd[18572]: =>ldap_back_conn_destroy: fetching
conn 1003
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: removing 14
Jul 13 20:26:52 ldap.local slapd[18572]: conn=1003 fd=14 closed (TLS
negotiation failure)
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on 1 descriptor
Jul 13 20:26:52 ldap.local slapd[18572]: daemon: activity on::
We are not seeing the error while connecting to OpenLDAP servers using
OpenSSL or LDAP client tools. How can we debug further to see why the
server was not able to complete TLS negotiation?
Package versions are
openldap-2.4.44-25.el7_9.x86_64
openssl-1.0.2k-25.el7_9.x86_64
kernel-3.10.0-1160.66.1.el7.x86_64
Regards,
Aravind M D
2 years, 4 months
2.5.7 - bind err=49 after a userPassword and pwdChangedTime update
by Dave Macias
Hello,
Happy Friday!
I have a script that defaults the password to the user's username and then
it sets the pwdChangedTime so far back that pwdMaxAge: 62208000 triggers.
In 2.5.7 before I change the pwdChangedTime i MUST do a simple bind with
dn/password before I can apply the new pwdChangedTime. I say in 2.5.7 bc in
2.4.59 i dont see this behavior.
So my flow goes as follows:
ldappasswd <newpass>
ldapmodify <newPwdChangedTime> (pwdChangedTime: 20191008133434Z)
ssh with new <newpass>
Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" method=128
Oct 8 09:17:06 localhost slapd[1380194]: conn=1199 op=2 RESULT tag=97
err=49 qtime=0.000026 etime=0.000262 text=
Flow i have to do so that bind works:
ldappasswd <newpass>
ldapsearch -D userdn -w <newpass> &/dev/null
ldapmodify <newPwdChangedTime> (pwdChangedTime: 20191008133434Z)
ssh with new <newpass>
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
Oct 8 09:29:11 localhost slapd[1380194]: fe_op_lastbind: old
pwdLastSuccess value=20211008132909Z 2s ago
Oct 8 09:29:11 localhost slapd[1380194]: ppolicy_bind: Entry
uid=davetest,ou=People,dc=domain,dc=net has an expired password: 0 grace
logins
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=2 RESULT tag=97
err=49 qtime=0.000016 etime=0.002915 text=
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 op=3 UNBIND
Oct 8 09:29:11 localhost slapd[1380194]: conn=1264 fd=15 closed
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 fd=15 ACCEPT from IP=
127.0.0.1:34044 (IP=0.0.0.0:389)
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 STARTTLS
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=0 RESULT oid= err=0
qtime=0.000029 etime=0.000113 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 fd=15 TLS established
tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SRCH base=""
scope=0 deref=0 filter="(objectClass=*)"
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SRCH attr=*
altServer namingContexts supportedControl supportedExtension
supportedFeatures supportedLDAPVersion supportedSASLMechanisms
domainControllerFunctionality defaultNamingContext lastUSN
highestCommittedUSN
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=1 SEARCH RESULT
tag=101 err=0 qtime=0.000016 etime=0.000228 nentries=1 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" method=128
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 BIND
dn="uid=davetest,ou=People,dc=domain,dc=net" mech=SIMPLE bind_ssf=0 ssf=256
Oct 8 09:29:14 localhost slapd[1380194]: fe_op_lastbind: old
pwdLastSuccess value=20211008132911Z 3s ago
Oct 8 09:29:14 localhost slapd[1380194]: ppolicy_bind: Entry
uid=davetest,ou=People,dc=domain,dc=net has an expired password: 0 grace
logins
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=2 RESULT tag=97
err=49 qtime=0.000016 etime=0.002904 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 EXT
oid=1.3.6.1.4.1.4203.1.11.1
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 PASSMOD
id="uid=davetest,ou=People,dc=domain,dc=net" old new
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=3 RESULT oid= err=0
qtime=0.000016 etime=0.002618 text=
Oct 8 09:29:14 localhost slapd[1380194]: conn=1265 op=4 UNBIND
Is this expected behavior?
Thank you,
Dave
3 years, 1 month