Re: slapd.conf for proxy to AD
by Del
Just to elaborate on some of my own points below:
> Like a lot of people I guess, I'm having trouble configuring slapd to
> work as a proxy server in front of Microsoft's Active Directory. AD in
> this case is configured to refuse to allow anonymous searches but I want
> to allow anonymous searches on the proxy. Therefore the configuration
> I'm hoping for is:
>
> * Anonymous binds to slapd get translated into an authenticated bind to AD.
> * Authenticated binds to slapd have their credentials (DN and password)
> passed through to AD.
According to man slapd-ldap, which says:
idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>]
[credentials=<simple password>] [saslmech=<SASL mech>]
[secprops=<properties>] [realm=<realm>] [authcId=<authentication
ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}]
[mode=<mode>] [flags=<flags>] [starttls=no|yes|critical]
[tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>]
[tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand]
[tls_ciphersuite=<ciphers>] [tls_protocol_min=<version>]
[tls_crlcheck=none|peer|all]
Allows to define the parameters of the authentication method
that is internally used by the proxy to authorize connections
that are authenticated by other databases. The identity defined
by this directive, according to the properties associated to the
authentication method, is supposed to have auth access on the
target server to attributes used on the proxy for authentication
and authorization, and to be allowed to authorize the users.
This requires to have proxyAuthz privileges on a wide set of
DNs, e.g. authzTo=dn.subtree:"", and the remote server to have
authz-policy set to to or both. See slapd.conf(5) for details
on these statements and for remarks and drawbacks about their
usage. The supported bindmethods are
So it seems that this is the parameter I want.
none|simple|sasl
where none is the default, i.e. no identity assertion is
performed.
I think I need "simple" here because I want OpenLDAP to do a simple bind (non-SASL) to AD.
...
The supported modes are:
<mode> := {legacy|anonymous|none|self}
If <mode> is not present, and authzId is given, the proxy always
authorizes that identity. <authorization ID> can be
u:<user>
[dn:]<DN>
The former is supposed to be expanded by the remote server
according to the authz rules; see slapd.conf(5) for details. In
the latter case, whether or not the dn: prefix is present, the
string must pass DN validation and normalization.
The default mode is legacy, which implies that the proxy will
either perform a simple bind as the authcDN or a SASL bind as
the authcID and assert the client’s identity when it is not
anonymous. Direct binds are always proxied. The other modes
imply that the proxy will always either perform a simple bind as
the authcDN or a SASL bind as the authcID, unless restricted by
idassert-authzFrom rules (see below), in which case the
operation will fail; eventually, it will assert some other
identity according to <mode>.
It seems to me that I want mode=legacy according to this. I want it to perform a simple bind
as some ID (VALID-BIND-DN below) when the client is anonymous, but assert the client's identity
when it is not anonymous.
I have to say that the language of the manual here is far from clear. It doesn't actually
define what is meant by "authcDN" for example, I'm only assuming that that means the "<simple
DN>" given as the argument to the binddn option of this parameter. Also it could skip the
double negatives.
However it doesn't appear to work. Any ideas?
> Here's what I have so far, based on the documentation. I'm using
> slapd.conf rather than the new conf.d directory based config, and I'm
> currently running openldap 2.4.19:
>
> --
> database ldap
> chase-referrals no
> suffix "MY-AD-SUFFIX-HERE"
> uri "ldaps://MY-AD-SERVER-HERE/"
> cancel abandon
>
> acl-bind bindmethod=simple binddn="VALID-BIND-DN"
> credentials="VALID-PASSWORD"
>
> idassert-bind bindmethod=simple binddn="VALID-BIND-DN
> credentials="VALID-PASSWORD" mode=legacy flags=non-prescriptive
>
> idassert-authzFrom "dn.regex:.*"
>
> access to * by * read
> --
>
> You can assume I've used valid bind DNs, suffixes, server names and
> passwords in the places where I've resorted to capitals above. I've
> tested these binds from the command line directly against the AD server
> and they all work.
>
> I have tested the above on OpenLDAP 2.3, it works for anonymous binds if
> and only if a successful authenticated bind is done first. The same was
> reported in this post:
>
> http://www.openldap.org/lists/openldap-technical/200907/msg00043.html
>
> In OpenLDAP 2.4 it fails to recognise the idassert-bind completely, all
> attempts at anonymous bind seem to fail. A similar problem was reported
> while upgrading to 2.3.11 to 2.3.27, here:
>
> http://www.openldap.org/lists/openldap-software/200701/msg00055.html
>
> Am I using the correct configuration directives to achieve what I want,
> and if not what should I be using?
>
> Thanx,
>
--
Del
14 years, 4 months
ACL doesn't work on my Centos 6
by Dong Xi
Hi,
Just set up openldap on my CentOS 6.5. Looks like very easy to set up. And
it is working. However, I found ACL doesn't work as expected. I am trying
to disable read access to anonymous, and give userPassword write access to
self and binduser. But it doesn't work: anonymous can still read whole ldap
entries, and no one except cn=Manager,dc=domain,dc=com can change
userPassword. I even change following section to access to * by * none to
lock down ldap, but still anonymous can read all.
===
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by dn.exact="cn=binduser,dc=domain,dc=com" write
by users read
by anonymous auth
access to *
by users read
by anonymous auth
===
to
===
access to * by * none
===
Here is the complete slapd.conf. Look like only default ACL works, whatever
ACL policy I am trying to apply. Please help.
slapd.conf
====
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
include /etc/openldap/schema/collective.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules
# - modulepath is architecture dependent value (32/64-bit system)
# - back_sql.la overlay requires openldap-server-sql package
# - dyngroup.la and dynlist.la cannot be used at the same time
# modulepath /usr/lib/openldap
# modulepath /usr/lib64/openldap
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload back_sql.la
# moduleload chain.la
# moduleload collect.la
# moduleload constraint.la
# moduleload dds.la
# moduleload deref.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload memberof.la
# moduleload pbind.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload seqmod.la
# moduleload smbk5pwd.la
# moduleload sssvlv.la
# moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by running
# /usr/libexec/openldap/generate-server-cert.sh. Your client software may
balk
# at self-signed certificates, however.
#TLSCACertificatePath /etc/openldap/certs
#TLSCertificateFile "\"OpenLDAP Server\""
#TLSCertificateKeyFile /etc/openldap/certs/password
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
#access to dn.base="" by * read
#access to dn.base="cn=Subschema" by * read
#access to *
# by self write
# by users read
# by anonymous auth
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by dn.exact="cn=binduser,dc=domain,dc=com" write
by users read
by anonymous auth
access to *
by users read
by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
# enable on-the-fly configuration (cn=config)
database config
access to *
by * none
# enable server status monitoring (cn=monitor)
database monitor
access to *
by * none
#######################################################################
# database definitions
#######################################################################
database bdb
suffix "dc=domain,dc=com"
checkpoint 1024 15
rootdn "cn=Manager,dc=domain,dc=com"
rootpw {SSHA}f3F8TAj9BihNSUtVdMyqrvlcIoawHDgb
loglevel 256
sizelimit unlimited
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
#rootpw {SSHA}f3F8TAj9BihNSUtVdMyqrvlcIoawHDgb
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
10 years, 11 months
Re: slapd-meta
by Fr3ddie
On 04/03/2016 20:33, Quanah Gibson-Mount wrote:
>
>> Then I modified the ldif file in order to create the meta-DB and its
>> sub-DBs
>> containing the URIs of the target servers (if I correctly understood):
>>
>> version: 1
>>
>> dn: olcDatabase={3}meta,cn=config
>> objectClass: olcDatabaseConfig
>> objectClass: olcMetaConfig
>> olcDatabase: {3}meta
>> olcSuffix: dc=loc1,dc=root
>> olcSuffix: dc=loc2,dc=root
>> olcSuffix: dc=loc3,dc=root
>
> I've never used meta backend, but the above doesn't look valid to me
> (multiple suffixes). The man page shows a single suffix, with URI
> directives for additional representations of the DB.
>
> [OMISSIS]
> The slapd-meta test suit shows an additional parameter, mode=self,
> being set. That may or may not help. ;)
Hello,
I performed further testing but I have no good news :(
about the multiple "olcSuffix" I'm inserting into the
"olcDatabase={3}meta" (I don't know where I'm supposed to put
multiple entries of the olcSuffix except the olcDatabase since it is an
attribute of olcDatabaseConfig objectclass),
I configured the meta backend with just one DB suffix and just one
target, in order to keep it easy and avoid,
as much as possible, my configuration mistakes. I believe this is the
configuration I would have been supposed to
do in order to properly configure the slapd-/ldap/ backend (?).
Moreover, although I tried both "mode=self", "mode=none" and
"authzID="dn:cn=admin,dc=loc1,dc=root""
(and "flags=non-prescriptive" too, while without the "authzID" of
course), the result is the same.
Logs from the slapd-meta equipped server report (I'm simply trying to
directly access the admin dn):
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SRCH
base="cn=admin,dc=loc1,dc=root" scope=0 deref=0 filter="(objectClass=*)"
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SRCH
attr=hasSubordinates objectClass
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11
meta_search_dobind_init[0] mc=0x7175f3e8: non-empty dn with empty cred;
binding anonymously
Mar 4 19:50:59 server01 slapd[28946]: conn=1160 op=11 SEARCH RESULT
tag=101 err=0 nentries=0 text=
and from the target server:
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 ACCEPT from
IP=10.0.x.55:51909 (IP=10.0.y.85:389)
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=0 BIND
dn="cn=admin,dc=loc1,dc=root" method=128
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=0 RESULT tag=97
err=53 text=unauthenticated bind (DN with no password) disallowed
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 op=1 UNBIND
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 closed
Mar 4 19:50:59 server-tgt slapd[31090]: conn=1728 fd=59 closed
thus the target server refuses unauthenticated bind and closes the
connection (as it is configured to do so).
Moreover, if I try to put double quotes around the "binddn" directive it
seems that slapd-meta doesn't recognize at all
the dn I'm trying to use to bind to the target, and the target server's
log reports:
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 fd=58 ACCEPT from
IP=10.0.x.55:49353 (IP=10.0.y.85:389)
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=0 BIND dn="" method=128
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=0 RESULT tag=97
err=0 text=
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=1 SEARCH RESULT
tag=101 err=123 nentries=0 text=anonymous proxied authorization not allowed
Mar 4 19:31:58 server-tgt slapd[31090]: conn=1094 op=1 do_search:
get_ctrls failed
Just to be complete, this is (one of) the configurations I'm trying:
dn: olcMetaSub={0}uri
objectClass: olcConfig
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
olcDbURI: "ldap://server01.loc1.root/dc=loc1,dc=root"
olcDbIDAssertBind: mode=self bindmethod=simple
binddn=cn=admin,dc=loc1,dc=root credentials=xxxxxxx starttls=no
authzID="dn:cn=admin,dc=loc1,dc=root"
while the rest of the configuration stayed the same as the one from my
first mail.
At this point I'm really stuck and the only thing I can think of it is
the presence of a bug somewhere into slapd-meta,
since the behaviour doesn't reflect the configuration on, somehow
simple, parameters.
Is there anybody having the same issues?
Is it still my fault on configuration?
I really don't know where to put my hands on...
Thanks for support
--
Fr3ddie
/fr3ddie(a)fr3ddie.it <mailto:fr3ddie@fr3ddie.it>/
A computer is like an air conditioner:
it stops working when you open Windows
9 years, 3 months
Re: Syncrepl over TLS for mirrormode
by Daniel Qian
Yes I wasn't aware of subjectAltName and I am still not sure if nss_ldap
in the OS honors that but I will test it out. Thanks Chris for answering
back.
On 11-08-27 4:23 PM, Chris Jacobs wrote:
> Apologies for taking a while (and top posting - blackberry).
>
> 1)I setup the mirror-mode servers behind a VIP (named ldapmaster1 &
> 2). VIP hosted on an F5 BigIP - which doesn't load balance StartTLS -
> which was fine by us - all 389 connections are insecure and all 686
> (?) are secure.
> 2) I created a cert via a CA trusted on all my client machines with:
> 2.A) Subject: ldap-vip.[domain]
> 2.B) subjectAltName(s): ldapmaster1.[domain], ldapmaster2.[domain],
> ldap-vip.[domain]
>
> (Subject included in alt name list as some clients - like firefox -
> ignore the subject if alt names exist - dumb IMNSHO.)
>
> Then the servers use the same cert to sync w/ each other as the
> clients use to connect to the VIP (or if needed, directly to the
> ldapmaster servers).
>
> The subjectAltName part of a cert is the 'tricky' part I think you're
> missing knowledge of.
>
> A wildcard cert works too, but then it'd be valid for any host
> *.[domain]. Not the most secure setup.
>
> - chris
>
> Chris Jacobs, Systems Administrator, Technology Services Group
> Apollo Group | Apollo Marketing and Product Development | Aptimus, Inc.
> 2001 6th Ave | Suite 3200 | Seattle, WA 98121
> direct 206.839.8245 | cell 206.601.3256 | fax 206.839.8106
> email chris.jacobs(a)apollogrp.edu
>
> ------------------------------------------------------------------------
> *From*: Daniel Qian <daniel(a)up247solution.com>
> *To*: Chris Jacobs
> *Cc*: 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org>
> *Sent*: Fri Aug 26 13:35:10 2011
> *Subject*: Re: Syncrepl over TLS for mirrormode
>
> Still not sure how you did it. Are you saying you set the same
> certificate in slapd and played with DNS to make it look like only one
> server(URL) to everyone?
>
> Thanks,
> Daniel
>
> On 11-08-26 4:03 PM, Chris Jacobs wrote:
>> What I did:
>> * setup servers behind VIP
>> * obtain cert with primary name of vip DNS w/ secondary names of the
>> servers.
>>
>> That way, the servers can sync/tryst each other via the same cert
>> used by clients.
>>
>> Note: some clients (lookin at you Firefox) won't use the primary name
>> if subjectaltname exists - so include primary name in the alt names JIC.
>>
>> - chris
>>
>> Chris Jacobs, Systems Administrator, Technology Services Group
>> Apollo Group | Apollo Marketing and Product Development� |�
>> Aptimus, Inc.
>> 2001 6th Ave� |� Suite 3200� |� Seattle, WA 98121
>> direct 206.839.8245� |� cell 206.601.3256� |� fax 206.839.8106
>> email chris.jacobs(a)apollogrp.edu
>>
>> ------------------------------------------------------------------------
>> *From*: openldap-technical-bounces(a)OpenLDAP.org
>> <openldap-technical-bounces(a)OpenLDAP.org>
>> *To*: openldap-technical(a)openldap.org <openldap-technical(a)openldap.org>
>> *Sent*: Fri Aug 26 12:49:04 2011
>> *Subject*: Syncrepl over TLS for mirrormode
>>
>> From the openldap website the two nodes have to use different URLs
>> like below:
>>
>> syncrepl rid=001
>> provider=ldap://ldap-sid2.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>> and
>> syncrepl rid=001
>> provider=ldap://ldap-sid1.example.com
>> bindmethod=simple
>> binddn="cn=mirrormode,dc=example,dc=com"
>> credentials=mirrormode
>> searchbase="dc=example,dc=com"
>> schemachecking=on
>> type=refreshAndPersist
>> retry="60 +"
>>
>> I can set two different certificates so that TLS is fine for sync
>> between the two nodes. However we will have regular Ldap client
>> access these two nodes behind a loadbalancer over TLS too. Obviously
>> the client can't connect with ldap-sid2.example.com, nor with
>> ldap-sid1.example.com. So what is the solution to this scenario?
>> Setup a pool of consumers with same hostname?
>>
>> Thanks,
>> Daniel
>>
>> ------------------------------------------------------------------------
>> This message is private and confidential. If you have received it in
>> error, please notify the sender and remove it from your system.
>>
>
>
> ------------------------------------------------------------------------
> This message is private and confidential. If you have received it in
> error, please notify the sender and remove it from your system.
>
13 years, 10 months
Re: fedora and openldap
by Judith Flo Gaya
Hello,
After doing all you suggest with the pki keys I'm stuck in the very same
place, the system is able to do ldapsearch but all user auth is not
working, I do this in order to configure the auth in the clients
# authconfig --disablecachecreds --enableldaps --enableldapauth
--ldapserver=ldaps://server.fdqn --ldapbasedn=dc=linux,dc=imppc,dc=org
--disablefingerprint --disablewinbind --disablewins --disablesssd
--disablesssdauth --disablenis --enablecache --enablelocauthorize
--disablemd5 --passalgo=sha512 --updateall
The pam.d files look ok:
# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_ldap.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok
try_first_pass use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session required pam_unix.so
session optional pam_ldap.so
This is the message in ldap server when I do id <ldap_user>
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 ACCEPT from
IP=[::1]:36208 (IP=[::]:636)
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 TLS established
tls_ssf=256 ssf=256
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 STARTTLS
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=0 RESULT oid= err=1
text=TLS already started
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 op=1 UNBIND
Apr 14 18:54:34 curri0 slapd[2010]: conn=1019 fd=12 closed
Aparently is ok but the id is not known
Any ideas?
Thanks a lot!
j
On 04/14/2011 05:44 PM, Judith Flo Gaya wrote:
> Hello Aaron,
>
> On 04/13/2011 09:07 PM, Aaron Richton wrote:
>> On Wed, 13 Apr 2011, Judith Flo Gaya wrote:
>>
>>> I see, I also have those files that you mention... I created my own CA
>>> as lots of tutorials explain.. Then I transmitted it to the clients and
>>> used it in the ldap.conf file. Do you suggest me to send those to the
>>> server and use them instead of the ones I generated with openssl?
>>
>> Well, you'll need the CA on the client to match the CA that signed the
>> server's certificate. In other words...if you generated your own CA for
>> both the client and the server, trust issues would be completely
>> expected...
> I don't know if I understood you or I didn't make myself clear on that
> point. I created a CA in the server and the copied the file to the
> client, is that wrong?
>>
>>> What's your server?
>>
>> OpenLDAP software is on both sides of the equation; it's just that some
>> clients are NSS, some clients are OpenSSL, some clients are GnuTLS, while
>> ALL servers are OpenSSL.
> I was talking about the operating system, for some reason I think that
> having red hat (with openldap compiled using openssl) and clients with
> fedora (openldap compiled against moznss) created my problems.
> Now that you said that this is your case (I think) then it may be
> something related to... I don't know what.
>>
>>> Well my final problem were not ldapsearch but the user autenticacion.
>>> The ldapsaerch showed the whole ldap definitions but if I try to ssh
>>> with an ldap user to the machine, I get some TLS negotiation problem ;(
>>> That's when I was told that the problem may be caused by the
>>> implementation of the ldap client (with moznss support).
>>
>> Well, when troubleshooting, it's often easiest to look with a narrow
>> scope. Using OpenLDAP software, such as ldapsearch(1) and ldapwhoami(1),
>> will probably offer a better debugging platform than an ssh
>> implementation? One step at a time...
> Yes, I totally agree, that's why I setup my own openldap installation
> and only care about ldapsearch working, then when ldapsearch finally
> worked, then I start looking at the user auth part, changing passw,
> etc.. as this part wasn't working and it appear to be a moznss problem,
> I got stuck... until you arrived, I will try what you suggest about
> using the pki certs instead of the openssl ones..
>
> Thanks a lot for the suggestion, hope this finally fix the issue.
> j
--
Judith Flo Gaya
Systems Administrator IMPPC
e-mail: jflo(a)imppc.org
Tel (+34) 93 554-3079
Fax (+34) 93 465-1472
Institut de Medicina Predictiva i Personalitzada del Càncer
Crta Can Ruti, Camí de les Escoles s/n
08916 Badalona, Barcelona,
Spain
http://www.imppc.org
14 years, 2 months
Re: Authenticate to ldap using Kerberos
by Wouter van Marle
On Thu, 2010-09-09 at 23:02 -0500, Dan White wrote:
> On 09/09/10 20:05 -0700, Russ Allbery wrote:
> >Wouter van Marle <wouter(a)squirrel-systems.com> writes:
> >> At this moment, I can connect to my ldap server from Evolution,
> >> authenticated. I have to enter a username and a password in my evo
> >> settings, which one way or another is communicated to openldap, which
> >> then checks this un/pw combo and considers it valid to give the
> >> information.
> >
> >If you are using Kerberos, you should never have to enter your username
> >and password into anything that isn't kinit or your initial authentication
> >to your system. If you do, that something is broken and is not using
> >Kerberos properly. Period.
>
> So if the poster had stated that he wanted to perform PAM authentication
> for his simple binds, I don't think he'd be confronted with such a violent
> reaction. However, from the standpoint of slapd, that's exactly what he's
> wanting to do.
Which is indeed what I have now slowly found out. I'm not an expert in
openldap or security; in the end I just want it to work. And
unfortunately evolution doesn't support all possible protocols; which is
of course why other applications try to support as many as possible, to
at least and up with one match.
Now Evolution can talk to openldap, and can authenticate, which is why I
can't call it "broken". Maybe it could be done better, maybe there are
newer protocols. But it's not broken in the sense of "doesn't work".
On top of that as long as it's on my own LAN, not out over the Internet,
I'm not worried about using plain passwords over unencrypted
connections. If an attacker manages to start sniffing passwords off of
my LAN (which is physically inside my office; all wired) then I have
worse security issues to worry about.
> Performing simple binds have precisely the same negative security footprint
> regardless of where his passwords may be stored. I'm assuming Evolution
> supports ldaps or STARTTLS,
Evolution does support encryption using TLS and SSH connections (that is
how it's called in the settings). And if I understand everything well
then plain authentication using one of those protocols is still pretty
secure.
Wouter.
> which would go a long way in mitigating that
> risk. If it didn't support TLS, I'd think that'd be a much more urgent
> focus (GSSAPI only provides 56 bits of encryption).
>
> >> Now basically the problem is that ldap is using the wrong authentication
> >> type. Wrong as in not the one that I want it to use. It is using it's
> >> own, internal authentication - this I want to change to an external
> >> system. It seems I need something like you guys call 'pass-through
> >> authentication'. And what I learnt over the last year or so when I
> >> looked more into this and related matter, Linux provides sasl and pam as
> >> general authentication libs, designed exactly for this purpose. Sasl and
> >> pam even can talk to each other.
>
> At this point, I'd agree with the above.
>
> >No. This is not correct.
>
> >SASL is what you do when you implement Kerberos properly. Evolution is
> >not doing this. It's either implementing a broken version of SASL where
> >it only implements a single mechanism (PLAIN), or it's actually not doing
> >SASL at all (most likely). The problem is exactly that Evolution is not
> >properly implementing Kerberos SASL mechanisms.
>
> Would you agree that any application which does not support the full range
> of SASL mechanisms is broken? What about simple binds? Would you suggest
> that OpenLDAP remove all support for simple binds? If not, why not?
>
> >PAM is indeed a way to verify passwords, but it has nothing to do with
> >SASL except in the very limited special case that there is one SASL
> >mechanism that communicates a password to the server, and once the
> >password is on the server, you might want to use PAM to check it. PAM is
> >not a network protocol; PAM is a way of plugging together password
> >verification systems on a local system and was really designed for either
> >console login or remote authentication that requires a password (such as
> >ssh without any Kerberos support). If you have Kerbeors and yet you're
> >resorting to using it with network services like LDAP, that means your
> >client software (in this case Evolution) is crappy and broken.
>
> Most protocols have support for legacy (pre-SASL) authentication. IMAP has
> login, POP has user/pass, LDAP has simple binds. (SMTP being one exception
> to this).
>
> In an ideal world we could just do away with all software that only
> has support for legacy authentication, but that'd break a good chunk of the
> ISP services I help to maintain. I'm not really a big fan of that.
>
> >Sadly, lots of client software is crappy and broken, so this is not an
> >uncommon thing to have to do, but that doesn't make Evolution any less
> >broken.
>
14 years, 9 months
Re: Problem with N-Way multimaster replication after an node fail and restore
by David Tello
Hi Ulrich,
Thank for your aswer. About the serverIDs, i think that are well
configured. I enable all trace in the servers an restart all nodes. I got
the below outs:
Node1:
May 13 11:04:36 wbsvisionNode1 slapd[27787]: olcServerID: value #0:
SID=0x001 (listener=ldap://wbsvisionNode1)
Node2:
May 13 11:05:43 wbsvisionNode2 slapd[17862]: olcServerID: value #1:
SID=0x002 (listener=ldap://wbsvisionNode2)
Node3:
May 13 11:06:27 wbsvisionNode3 slapd[6980]: olcServerID: value #2:
SID=0x003 (listener=ldap://wbsvisionNode3)
I understand that this outputs are the corrects.
I made the changes that Quanah indicated to me and i had the same behavior.
I continue searching...
Regards,
David Tello
El lun., 13 may. 2019 a las 8:04, Ulrich Windl (<
Ulrich.Windl(a)rz.uni-regensburg.de>) escribió:
> >>> David Tello <david.tello.wbsgo(a)gmail.com> schrieb am 09.05.2019 um
> 10:21
> in
> Nachricht
> <CADC8=Wxww4kTHyRS3_j+93VXRzc45fDrVLJxFwFTRjcH8QD_gQ(a)mail.gmail.com>:
> > I have a problem with the N-Way replication multimaster. My enviroiment
> is
> > debian Stretch and slapd (2.4.47+dfsg-3~bpo9+1) from Stretch backports.
> >
> > I have configured a cluster with 3 nodes. I have configured to replicate
> > the config database and a normal data mdb database. I followed the
> > documentation and the cluster sync work correctly when all nodes are
> > started.
> >
> > If i made a change in any node, this change is replicated to the others.
> My
> > problem appears when i make a change whe one node is down. In this case,
> > the other two nodes repli correctly, and when the downed node start this
> > get all pending changes correctly. And in this point occurs the problem.
> > After the start of downed node, the changes mades in this node are not
> send
> > to the other two nodes. For other way, the changes mades in the other two
> > nodes (no shutdowned) are sended to all nodes correctly.
> >
> > I tried this config with a two nodes cluster and the behavior was the
> same,
> > after reboot slapd do not send more updates.
> >
> >
> > I have checked the olcServerId because i know that a mistake here can
> > produce similar problems. I really think that it is correct.
> >
> > The cmdlines of the proccess are:
> >
> > /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode1/ ldap://127.0.0.1/
> > ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> > /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode2/ ldap://127.0.0.1/
> > ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> > /usr/sbin/slapd -h ldapi:/// ldap://wbsvisionNode3/ ldap://127.0.0.1/
> > ldaps:/// -g openldap -u openldap -F /etc/ldap/slapd.d
> >
> >
> > The config database configuración is below:
> >
> > *DN: cn=config*
> > .....
> > olcServerID: 1 ldap://wbsvisionNode1/
> > olcServerID: 2 ldap://wbsvisionNode2/
> > olcServerID: 3 ldap://wbsvisionNode3/
>
> Are you sure your server IDs are assigned as intended? It is logged like
> "slapd[1493]: olcServerID: value " on start.
>
> >
> > *dn: olcDatabase={0}config,cn=config*
> > .......
> > olcMirrorMode: TRUE
> >
> > olcSyncUseSubentry: FALSE
> >
> > olcSyncrepl:
> >
> > {0}rid=001
> > provider=ldap://wbsvisionNode1
> > bindmethod=simple
> > binddn="cn=admin,cn=config"
> > credentials="TuoDqAG7UbCJx8H8gfMO"
> > starttls=no
> > tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> > tls_key=/etc/pki/private/wbsagnitio.local.es.key
> > tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> > tls_reqcert=never
> > searchbase="cn=config"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> > {1}rid=002
> > provider=ldap://wbsvisionNode2
> > bindmethod=simple
> > binddn="cn=admin,cn=config"
> > credentials="TuoDqAG7UbCJx8H8gfMO"
> > starttls=no
> > tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> > tls_key=/etc/pki/private/wbsagnitio.local.es.key
> > tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> > tls_reqcert=never
> > searchbase="cn=config"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> > {2}rid=003
> > provider=ldap://wbsvisionNode3
> > bindmethod=simple
> > binddn="cn=admin,cn=config"
> > credentials="TuoDqAG7UbCJx8H8gfMO"
> > starttls=no
> > tls_cert=/etc/pki/certs/wbsagnitio.local.es.pem
> > tls_key=/etc/pki/private/wbsagnitio.local.es.key
> > tls_cacert=/etc/pki/certs/wbsagnitio-ca.pem
> > tls_reqcert=never
> > searchbase="cn=config"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> > FALSE
> >
> > ------
> >
> > *dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config*
> > objectClass: olcSyncProvConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {0}syncprov
> > olcSpCheckpoint: 1000 1
> >
> >
> > The data database configuración is below:
> >
> >
> >
> > *dn: olcDatabase={1}mdb,cn=config*
> > objectClass: olcMdbConfig
> > objectClass: olcDatabaseConfig
> > olcDatabase: {1}mdb
> > ...
> > olcDbIndex: objectClass eq
> > olcDbIndex: entryCSN eq
> > ...
> > olcLastMod: TRUE
> >
> > olcSuffix: dc=local,dc=es
> > .........
> > olcMirrorMode: TRUE
> >
> > olcSyncrepl: {0}rid=004
> > provider=ldap://wbsvisionNode1
> > bindmethod=simple
> > binddn="cn=manager,dc=local,dc=es"
> > credentials="test"
> > starttls=no
> > searchbase="dc=local,dc=es"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> >
> > olcSyncrepl: {1}rid=005
> > provider=ldap://wbsvisionNode2
> > bindmethod=simple
> > binddn="cn=manager,dc=local,dc=es"
> > credentials="test"
> > starttls=no
> > searchbase="dc=local,dc=es"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> >
> > olcSyncrepl: {2}rid=006
> > provider=ldap://wbsvisionNode3
> > bindmethod=simple
> > binddn="cn=manager,dc=local,dc=es"
> > credentials="test"
> > starttls=no
> > searchbase="dc=local,dc=es"
> > scope=sub
> > type=refreshAndPersist
> > retry="5 5 300 +"
> >
> > olcSyncUseSubentry: FALSE
> >
> > dn: olcOverlay={0}dynlist,olcDatabase={1}mdb,cn=config
> > objectClass: olcDynamicList
> > objectClass: olcOverlayConfig
> > olcOverlay: {0}dynlist
> > olcDlAttrSet: {0}virtualGroup memberDnURL uniqueMember
> > olcDlAttrSet: {1}virtualGroup memberUidURL memberUid:uid
> > olcDlAttrSet: {2}virtualGroup memberSidURL sambaSIDList:sambaSID
> >
> > dn: olcOverlay={1}lastbind,olcDatabase={1}mdb,cn=config
> > objectClass: olcLastBindConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {1}lastbind
> > olcLastBindPrecision: 30
> >
> > dn: olcOverlay={2}unique,olcDatabase={1}mdb,cn=config
> > objectClass: olcUniqueConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {2}unique
> > olcUniqueAttribute: uid
> > olcUniqueAttribute: uidNumber
> > olcUniqueAttribute: employeeNumber
> > olcUniqueBase: dc=local,dc=es
> >
> > dn: olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config
> > objectClass: olcMemberOf
> > objectClass: olcOverlayConfig
> > olcOverlay: {3}memberof
> > olcMemberOfDangling: ignore
> > olcMemberOfGroupOC: groupOfUniqueNames
> > olcMemberOfMemberAD: uniqueMember
> > olcMemberOfMemberOfAD: memberOf
> > olcMemberOfRefInt: TRUE
> >
> > dn: olcOverlay={4}accesslog,olcDatabase={1}mdb,cn=config
> > objectClass: olcAccessLogConfig
> > objectClass: olcOverlayConfig
> > olcAccessLogDB: cn=accesslog
> > olcOverlay: {4}accesslog
> > olcAccessLogOld:
> (|(objectClass=wbsagnitioGroup)(objectClass=wbsagnitioAccou
> > nt))
> > olcAccessLogOldAttr: roles
> > olcAccessLogOldAttr: objectClass
> > olcAccessLogOps: writes
> > olcAccessLogOps: bind
> > olcAccessLogPurge: 7+00:00 1+00:00
> >
> > dn: olcOverlay={5}ppolicy,olcDatabase={1}mdb,cn=config
> > objectClass: olcPPolicyConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {5}ppolicy
> > olcPPolicyDefault:
> cn=0-default,ou=passwordpolicies,ou=configuration,dc=loca
> > l,dc=es
> > olcPPolicyForwardUpdates: FALSE
> > olcPPolicyHashCleartext: FALSE
> > olcPPolicyUseLockout: FALSE
> >
> > dn: olcOverlay={6}syncprov,olcDatabase={1}mdb,cn=config
> > objectClass: olcSyncProvConfig
> > objectClass: olcOverlayConfig
> > olcOverlay: {6}syncprov
> > olcSpCheckpoint: 1000 1
> >
> > Below i show the sync log of some operations to show the behavior of my
> > cluster:
> > TEST 1: 3 Nodes up. Update in node 1 (correct):Log Node1:
> >
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7e0108b40 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7e0100a90 20190507150322.383471Z#000000#001#000000
> > Log Node2:
> >
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid 23fff700
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f8008107700 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> > cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f80081057c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f8008105ea0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006
> > cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode2 slapd[1263]: do_syncrep2: rid=006 CSN too
> > old, ignoring 20190507150322.383471Z#000000#001#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> > Log Node3:
> >
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid adbb2700
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c1069e0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c1045c0 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> > cookie=rid=006,sid=003,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c104c90 20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> > cookie=rid=005,sid=002,csn=20190507150322.383471Z#000000#001#000000
> > May 7 17:03:22 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005 CSN too
> > old, ignoring 20190507150322.383471Z#000000#001#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> >
> >
> > TEST 2: 3 Nodes up. Update in node 2 (correct) (later this will be the
> down
> > node):Log Node1:
> >
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=005
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_message_to_entry:
> > rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid eaffd700
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > be_search (0)
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7d4105fa0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7d411fdd0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncrepl_entry: rid=005
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> > cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7d4121830 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006
> > cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode1 slapd[14058]: do_syncrep2: rid=006 CSN too
> > old, ignoring 20190507150531.748816Z#000000#002#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> >
> > Log Node2:
> >
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_queue_csn: queueing
> > 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f80081050e0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=003,
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: slap_graduate_commit_csn:
> > removing 0x7f8008106ed0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode2 slapd[1263]: syncprov_sendresp: to=001,
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> >
> > Log Node3:
> >
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=005
> > cookie=rid=005,sid=002,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> > rid=005 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid acbb0700
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > be_search (0)
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f4288109c60 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 002
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f4288107310 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=001,
> > cookie=rid=006,sid=003,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=005
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42881079f0 20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507150531.748816Z#000000#002#000000
> > May 7 17:05:31 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004 CSN too
> > old, ignoring 20190507150531.748816Z#000000#002#000000
> > (cn=Usuarios,ou=grupos,dc=local,dc=es)
> >
> >
> > TEST 3: 2 Nodes up. The node 2 is down. Update in node 1:Log Node1:
> >
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7dc126f40 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=002,
> > cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7dc125e50 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:16 wbsvisionNode1 slapd[14058]: syncprov_sendresp: to=003,
> > cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> > Log Node3:
> >
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: do_syncrep2: rid=004
> > cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) tid a6ffd700
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42a01261a0 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_matchops: skipping
> > original sid 001
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42a0124640 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncprov_sendresp: to=002,
> > cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
> > May 7 17:10:15 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f42a0124810 20190507151016.178467Z#000000#001#000000
> >
> >
> > TEST 4: 3 Nodes up. Logs of the sync produced by the Node2 start. The
> node2
> > resync correctly the change made in TEST3 (when this node was down).
> > Log Node1:
> >
> > May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_queue_csn: queueing
> > 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode1 slapd[14058]: slap_graduate_commit_csn:
> > removing 0x7fc7dc122780 20190507151352.582436Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode1 slapd[14058]: syncprov_search_response:
> >
>
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> > Log Node2:
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slapd starting
> > May 7 17:13:52 wbsvisionNode2 slapd[435]: Starting OpenLDAP: slapd.
> > May 7 17:13:52 wbsvisionNode2 systemd[1]: Started LSB: OpenLDAP
> standalone
> > server (Lightweight Directory Access Protocol).
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=001
> > LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=003
> > LDAP_RES_INTERMEDIATE - REFRESH_DELETE
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> > LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> > LDAP_RES_INTERMEDIATE - SYNC_ID_SET
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> > rid=004 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f6021700
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > be_search (0)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_message_to_entry:
> > rid=006 DN: cn=Usuarios,ou=grupos,dc=local,dc=es, UUID:
> > d6c282a0-00ff-1039-89ae-b1c1eec8fb13
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) tid f501f700
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: dn_callback : entries have
> > identical CSN cn=Usuarios,ou=grupos,dc=local,dc=es
> > 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> > be_search (0)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=006 entry
> > unchanged, ignored (cn=Usuarios,ou=grupos,dc=local,dc=es)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> > LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=006
> >
>
> cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> > ou=personas,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> > ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> > ou=dominios,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn
> ou=dns,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6b9eaaa-00ff-1039-8994-b1c1eec8fb13, dn
> > ou=forward,ou=dns,dc=local,dc=es
> > .................................
> >
> > Similar lines with other entries.
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=006
> > present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > ...............................
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: syncrepl_entry: rid=004
> > be_modify cn=Usuarios,ou=grupos,dc=local,dc=es (0)
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> > LDAP_RES_INTERMEDIATE - REFRESH_PRESENT
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: do_syncrep2: rid=004
> >
>
> cookie=rid=004,sid=001,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b883e0-00ff-1039-898f-b1c1eec8fb13, dn dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b88520-00ff-1039-8990-b1c1eec8fb13, dn
> > ou=personas,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b8e51a-00ff-1039-8991-b1c1eec8fb13, dn
> > ou=grupos,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b9494c-00ff-1039-8992-b1c1eec8fb13, dn
> > ou=dominios,dc=local,dc=es
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6b9b18e-00ff-1039-8993-b1c1eec8fb13, dn
> ou=dns,dc=local,dc=es
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: nonpresent_callback: rid=004
> > present UUID d6c282a0-00ff-1039-89ae-b1c1eec8fb13, dn
> > cn=Usuarios,ou=grupos,dc=local,dc=es
> > .............................
> >
> > Similar lines with other entries.
> >
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63d0121400 20190507151016.178467Z#000000#001#000000
> > May 7 17:13:52 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63d0123740 20190507151016.178467Z#000000#001#000000
> >
> > Log Node3:
> >
> > May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_queue_csn: queueing
> > 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode3 slapd[1100]: slap_graduate_commit_csn:
> > removing 0x7f428c103b00 20190507151352.329505Z#000000#003#000000
> > May 7 17:13:52 wbsvisionNode3 slapd[1100]: syncprov_search_response:
> >
>
> cookie=rid=006,sid=003,csn=20190507151016.178467Z#000000#001#000000;20190507
> > 150531.748816Z#000000#002#000000;20190507150013.014798Z#000000#003#000000
> >
> >
> > TEST 5: 3 Nodes up. Change is made in Node2 after resync and this is not
> > sended to the other nodes in the cluster.Log Node1:
> >
> > Empty.
> > Log Node2:
> >
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_queue_csn: queueing
> > 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63cc125120 20190507152835.873382Z#000000#002#000000
> > May 7 17:28:35 wbsvisionNode2 slapd[591]: slap_graduate_commit_csn:
> > removing 0x7f63cc121370 20190507152835.873382Z#000000#002#000000
> > Log Node3:
> >
> > Empty.
>
>
>
>
6 years, 1 month
Re: Syncrepl only partially working
by Dieter Klünter
Am Fri, 28 Oct 2016 21:50:30 -0600
schrieb Joshua Schaeffer <jschaeffer0922(a)gmail.com>:
> 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.
Note that there is a hard coded limit to 500 operations. If you have
more than 500 entries, syncrepl only recieves a limited set of entries.
Read slapd-config(5) on limits.
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
8 years, 8 months
Re: [EXT] Re: Replication issues with openldap 2.5 {resolved}
by Ulises Gonzalez Horta
Yeah, the error message was misleading here, error 49 is wrong password,
but I knew for sure the password was right.
Maybe a log entry as the one you suggested will help you fast pinpoint the
issue
Ulises Gonzalez Horta
Lead Linux Engineer
C: 786 450 2970/ 240 727 6267
E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com>
On Fri, Jan 3, 2025 at 4:44 AM Windl, Ulrich <u.windl(a)ukr.de> wrote:
> Hi!
>
>
>
> Makes me wonder: How much does a “no UserPassword – cannot authenticate”
> error message cost, and how much time will it save? 😉
>
>
>
> Kind regards,
>
> Ulrich
>
>
>
> *From:* Ulises Gonzalez Horta <ugonzalezhorta(a)breezeline.com>
> *Sent:* Thursday, January 2, 2025 6:57 PM
> *To:* Stefan Kania <stefan(a)kania-online.de>
> *Cc:* openldap-technical(a)openldap.org
> *Subject:* [EXT] Re: Replication issues with openldap 2.5 {resolved}
>
>
>
> Thank you very much to all that read this thread, but especially to those
> replied and provided any guidance, I/We fixed the issue, the problem was
> caused by this default ACL
>
>
>
> {0}to attrs=userPassword by self write by anonymous auth by * none
>
> It default "stop" was avoiding that my replication user read the
> userPassword attribute for other users, hence the attribute was not being
> replicated, and for some reason if that attribute is not present and you
> try to authenticate a user then slapd does not produce too many logs, it
> only returns error 49.
>
>
>
> Thank you all and happy new year
>
>
>
>
>
> *Ulises Gonzalez Horta*
>
> *Lead Linux Engineer*
>
> *C: 786 450 2970/ 240 727 6267*
>
> *E:* ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com>
>
>
>
>
>
>
>
> On Thu, Jan 2, 2025 at 11:59 AM Stefan Kania <stefan(a)kania-online.de>
> wrote:
>
> Did you test the access to the attribute with slapacl? "slapacl -D
> dn=search-user,ou=users... -b cn=object-to-check,ou=.... userPassword"
>
>
> Am 02.01.25 um 15:37 schrieb Ulises Gonzalez Horta:
> > Hi Shawn
> >
> > After closely inspecting both/all entries with slapcat on each of the
> > servers I confirmed that all the user entries are being replicated -
> > except- for the userPassword one.
> > So it looks like we found the issue.
> >
> > Question is how to fix it, why is it not replicating the userPassword
> > attribute?
> >
> > I have removed my filter entry from my olcSyncrepl, now it looks like
> this
> >
> > olcSyncrepl: {0}rid=100 provider=ldap://master:389 type=refr
> > eshOnly interval=00:00:05:00 retry="300 +"
> > searchbase="dc=metrocast,dc=net" t
> > imelimit=unlimited sizelimit=unlimited bindmethod=simple
> > binddn="cn=repl,ou=boxes,dc=metrocast,dc=net" credentials="aaa" starttls
> > =critical tls_cacertdir="/etc/ldap/certs"
> >
> > But still not replicating the userPassword attribute, any clue??
> >
> > Thanks in advance
> >
> >
> >
> > Ulises Gonzalez Horta
> >
> > Lead Linux Engineer
> >
> > C: 786 450 2970/ 240 727 6267
> >
> > E:ugonzalezhorta@breezeline.com <mailto:jsutherland1@breezeline.com>
> >
> >
> >
> > On Wed, Jan 1, 2025 at 12:52 PM Shawn McKinney <smckinney(a)symas.com
> > <mailto:smckinney@symas.com>> wrote:
> >
> >
> > > On Dec 31, 2024, at 9:08 AM, Ulises Gonzalez Horta
> > <ugonzalezhorta(a)breezeline.com
> > <mailto:ugonzalezhorta@breezeline.com>> wrote:
> > >
> > > Hi and happy new year.
> > >
> > > I was checking to see if a bad acl could be the cause here, after
> > enabling all logs including -1 level, I still did not get anything
> > useful on syslog.
> > >
> > > So I went this route
> > > I get my slave server, removed the config for oldSyncRepl and
> > olcUpdateref, stopped slapd, removed the database, and loaded a
> > backup, then started slapd, then attempted the queries and it
> > worked fine
> >
> > Hello,
> >
> > Have you tried slapcat on that entry on both instances, comparing
> > the results to ensure they match?
> >
> > Also, are password policies enabled?
> >
> > Your earlier question about which log level for ACL's:
> >
> > man slapd.conf
> >
> > …
> >
> > 128 (0x80 ACL) access control list processing
> >
> > —
> > Shawn
>
>
6 months
Segmentation Fault on ldap_chain_op
by Jeremy Diaz
Hi everyone,
I am currently looking into an issue with an environment that consists of 3 producers and 6 consumers all on OpenLdap 2.4.48. All the masters share an identical master config and all of the consumers share an identical consumer config. One consumer server in particular is crashing on a random time interval with no obvious reason. Each ldap server has sasl pass through auth setup and there is an additional slapd process on each server being used as a ldap meta to AD.
One server in particular, is crashing at seemingly random intervals. Upon initial inspection, we noticed that around the time of a crash, saslauthd logs would have an increase in failed write messages:
Dec 11 07:23:20 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out
Dec 11 07:23:30 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out
Dec 11 07:23:40 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out
Dec 11 07:23:56 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out
Dec 11 07:23:57 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out
Dec 11 07:23:57 {REDACTED} saslauthd[2719]: user ldap_search_st() failed: Timed out
Dec 11 07:24:05 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out
Dec 11 07:24:06 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out
Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write: Broken pipe
Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write: Broken pipe
Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write failure
Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write: Broken pipe
Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write: Broken pipe
Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write failure
Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write: Broken pipe
Initially we thought this meant that the crashes were caused by performance issues with AD, saslauthd or the ldap meta instance. We also ran slapd in full debugging mode to see if the logs have some kind of hints to the source of the issue.
The resulting slapd logs were normal. To obtain further information we obtained the following trace of the segfault using gdb:
starting
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
frames-invalid
[New Thread 0x7ffbf19be700 (LWP 22956)]
new-thread
[New Thread 0x7ffbf11bd700 (LWP 22957)]
new-thread
[New Thread 0x7ffbf09bc700 (LWP 22958)]
new-thread
[New Thread 0x7ffbebfff700 (LWP 22959)]
new-thread
[New Thread 0x7ffbeb7fe700 (LWP 22963)]
new-thread
[New Thread 0x7ffbe9cfb700 (LWP 22965)]
new-thread
[New Thread 0x7ffbd3fff700 (LWP 22966)]
new-thread
signal
Program received signal
signal-name
SIGSEGV
signal-name-end
,
signal-string
Segmentation fault
signal-string-end
.
[Switching to Thread 0x7ffbf09bc700 (LWP 22958)]
thread-changed
frame-begin 0 0x4e52e3
frame-function-name
ldap_chain_op
frame-args
(
arg-begin
op=op@entry
arg-name-end
=
arg-value *
0x7ffbe41f0870
arg-end
,
arg-begin
rs=rs@entry
arg-name-end
=
arg-value *
0x7ffbf09bbb20
arg-end
,
arg-begin
op_f
arg-name-end
=
arg-value *
0x4a845e <ldap_back_search>
arg-end
,
arg-begin
ref=ref@entry
arg-name-end
=
arg-value *
0x0
arg-end
,
arg-begin
depth=depth@entry
arg-name-end
=
arg-value -
0
arg-end
)
frame-source-begin
at
frame-source-file
chain.c
frame-source-file-end
:
frame-source-line
422
frame-source-end
source ${REDACTED DIR}/chain.c:422:11629:beg:0x4e52e3
frame-end
stopped
post-prompt
#0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422
#1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090
#2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237
#3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508
#4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583
#5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861
#6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558
#7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211
#11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251
#12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677
#13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402
#16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247
#20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158
#21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307
#23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbd3ffdc10 " aaf9: 04 3a 75 69 64 3d 53 49 41 53 47 52 50 2c 6f 75 .:uid=SIASGRP,ou \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbcd83df04 "0\203\n\036\273\004\funiqueMember1\203\n\036\250\004\071uid=wtso732,ou={REDACTED}“…, len=len@entry=663561) at bprint.c:202
#5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:276
#6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbcc122e20, inout=inout@entry=1) at bprint.c:247
#7 0x00000000005894c1 in ber_scanf (ber=0x7ffbcc122e20, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723
#8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbd3ffdf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbd3ffe320, msg=<optimized out>, op=0x7ffbd3ffe510, si=0xa3e9e0) at syncrepl.c:2658
#9 do_syncrep2 (op=op@entry=0x7ffbd3ffe510, si=si@entry=0xa3e9e0) at syncrepl.c:1043
#10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3e670) at syncrepl.c:1571
#11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbd3fff700) at pthread_create.c:307
#13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 0x00007ffff673e16d in write () at ../sysdeps/unix/syscall-template.S:81
#1 0x00007ffff66c91a3 in _IO_new_file_write (f=0x937c20, data=0x7ffff7ff8000, n=162) at fileops.c:1258
#2 0x00007ffff66ca9be in new_do_write (to_do=162, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., fp=0x937c20) at fileops.c:519
#3 _IO_new_do_write (fp=0x937c20, data=0x7ffff7ff8000 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n5e0a2340 >>> dnPretty: <uid={REDACTED}>\n.. \n5e0a2340 daemon: epoll: listen=19"..., to_do=162) at fileops.c:495
#4 0x00007ffff66c87f8 in _IO_new_file_sync (fp=0x937c20) at fileops.c:869
#5 0x00007ffff66bd5f3 in __GI__IO_fflush (fp=0x937c20) at iofflush.c:40
#6 0x000000000058c21a in lutil_debug (debug=<optimized out>, level=level@entry=1, fmt=fmt@entry=0x59c7a6 ">>> dnPretty: <%s>\n") at debug.c:81
#7 0x000000000044c792 in dnPretty (syntax=syntax@entry=0x8c4810, val=val@entry=0x7ffbe9cf9d00, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at dn.c:539
#8 0x000000000046c614 in nameUIDPretty (syntax=0x8c4810, val=0x7ffbd9845600, out=0x7ffbe9cf9de0, ctx=0x0) at schema_init.c:1350
#9 0x000000000045383d in ordered_value_pretty (ad=ad@entry=0xa40470, val=0x7ffbd9845600, out=out@entry=0x7ffbe9cf9de0, ctx=ctx@entry=0x0) at value.c:511
#10 0x000000000044f676 in slap_mods_check (op=op@entry=0x7ffbe9cfa510, ml=0x7ffbd992c410, text=text@entry=0x7ffbe9cf9f60, textbuf=textbuf@entry=0x7ffbe9cfa180 "H\034\032\330\373\177", textlen=textlen@entry=256, ctx=ctx@entry=0x0) at modify.c:575
#11 0x0000000000492e10 in syncrepl_message_to_entry (syncUUID=0x7ffbe9cf9f40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbe9cfa320, msg=<optimized out>, op=0x7ffbe9cfa510, si=0xa3fb20) at syncrepl.c:2715
#12 do_syncrep2 (op=op@entry=0x7ffbe9cfa510, si=si@entry=0xa3fb20) at syncrepl.c:1043
#13 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa40060) at syncrepl.c:1571
#14 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#15 0x00007ffff754cdd5 in start_thread (arg=0x7ffbe9cfb700) at pthread_create.c:307
#16 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbeb7fcc10 " 4530: 62 61 6c 2c 64 63 3d 61 65 70 2c 64 63 3d 63 6f bal,dc={REDACTED} \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbd576fee7 "0\027\004\002cn1\021\004\017CSC User Access0-\004\025structuralObjectClass1\024\004\022groupOfUniqueNames03\004\tentryUUID1&\004$13257271-b706-49bc-a2a9-a5f3e7f4a0dd0L\004\fcreatorsName1<\004:cn={REDACTED}”…, len=len@entry=61665) at bprint.c:202
#5 0x000000000058c053 in ber_dump (ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:276
#6 0x000000000058c0ab in ber_log_dump (errlvl=errlvl@entry=16, loglvl=<optimized out>, ber=ber@entry=0x7ffbd4319130, inout=inout@entry=1) at bprint.c:247
#7 0x00000000005894c1 in ber_scanf (ber=0x7ffbd4319130, fmt=fmt@entry=0x5b09b3 "{mW}") at decode.c:723
#8 0x0000000000492ba8 in syncrepl_message_to_entry (syncUUID=0x7ffbeb7fcf40, syncstate=<optimized out>, entry=<synthetic pointer>, modlist=0x7ffbeb7fd320, msg=<optimized out>, op=0x7ffbeb7fd510, si=0xa3f3b0) at syncrepl.c:2658
#9 do_syncrep2 (op=op@entry=0x7ffbeb7fd510, si=si@entry=0xa3f3b0) at syncrepl.c:1043
#10 0x00000000004976db in do_syncrepl (ctx=<optimized out>, arg=0xa3f8b0) at syncrepl.c:1571
#11 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#12 0x00007ffff754cdd5 in start_thread (arg=0x7ffbeb7fe700) at pthread_create.c:307
#13 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbebe6cf20 " b6c6: 03 0a 01 04 30 22 02 03 02 38 56 17 0d 31 38 30 ....0\"...8V..180 \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbe04282a0 "0\203UK\275\002\001\001d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202
#5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175
#6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe17f55b0, ber=ber@entry=0x7ffbebe6d0f0, freeit=freeit@entry=0) at io.c:240
#7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe41bd940, ber=ber@entry=0x7ffbebe6d0f0) at result.c:339
#8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe41bd940, rs=<optimized out>) at result.c:1430
#9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbebffeaa0) at search.c:1085
#10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#11 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#13 0x000000000043c33f in fe_op_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:402
#14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41bd940, rs=0x7ffbebffeaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#15 0x000000000049de86 in over_op_func (op=0x7ffbe41bd940, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#17 0x000000000043bef6 in do_search (op=0x7ffbe41bd940, rs=0x7ffbebffeaa0) at search.c:247
#18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbebffebd0, arg_v=arg_v@entry=0x7ffbe41bd940) at connection.c:1158
#19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbebffebd0, argv=<optimized out>) at connection.c:1294
#20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbebfff700) at pthread_create.c:307
#22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422
#1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090
#2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237
#3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508
#4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583
#5 0x0000000000448d1f in slap_send_ldap_result (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at result.c:861
#6 0x00000000004bd8c3 in mdb_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:558
#7 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#8 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#9 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#10 0x00000000004d1a02 in relay_back_op (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=which@entry=2) at op.c:211
#11 0x00000000004d1b07 in relay_back_op_search (op=<optimized out>, rs=<optimized out>) at op.c:251
#12 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0xa3af00, on=0x0) at backover.c:677
#13 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#14 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#15 0x000000000043c33f in fe_op_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:402
#16 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe41f0870, rs=0x7ffbf09bbb20, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#17 0x000000000049de86 in over_op_func (op=0x7ffbe41f0870, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#18 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#19 0x000000000043bef6 in do_search (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at search.c:247
#20 0x0000000000439bc4 in connection_operation (ctx=0x7ffbf09bbbd0, arg_v=0x7ffbe41f0870) at connection.c:1158
#21 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#22 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf09bc700) at pthread_create.c:307
#23 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1 0x00007ffff66bd6ac in _L_lock_39 () from /lib64/libc.so.6
#2 0x00007ffff66bd5b4 in __GI__IO_fflush (fp=0x937d00) at iofflush.c:39
#3 0x000000000058bbc6 in ber_error_print (data=0x7ffbf102af20 " e54c: 33 5a 30 0c 30 0a 06 03 55 1d 15 04 03 0a 01 04 3Z0.0...U....... \n") at bprint.c:87
#4 0x000000000058be41 in ber_bprint (data=0x7ffbe42cc110 "0\203UK\275\002\001\021d\203UK\265\004\062cn={REDACTED}0\203UK|0\203UKw\004 certificateRevocationList;binary1\203UKP\004\203UKK0\203UKF0\203UJ-\002\001\001\060\r\006\t*\206H\206\367\r\001\001\v\005", len=len@entry=5589954) at bprint.c:202
#5 0x000000000058bfb3 in ber_log_bprint (errlvl=errlvl@entry=16, loglvl=<optimized out>, data=<optimized out>, len=len@entry=5589954) at bprint.c:175
#6 0x000000000058b179 in ber_flush2 (sb=0x7ffbe422daa0, ber=ber@entry=0x7ffbf102b0f0, freeit=freeit@entry=0) at io.c:240
#7 0x0000000000447ee5 in send_ldap_ber (op=op@entry=0x7ffbe42197b0, ber=ber@entry=0x7ffbf102b0f0) at result.c:339
#8 0x000000000044b290 in slap_send_search_entry (op=0x7ffbe42197b0, rs=<optimized out>) at result.c:1430
#9 0x00000000004bf3b4 in mdb_search (op=<optimized out>, rs=0x7ffbf11bcaa0) at search.c:1085
#10 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0xa3eeb0, on=0x0) at backover.c:677
#11 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#12 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#13 0x000000000043c33f in fe_op_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:402
#14 0x000000000049dd58 in overlay_op_walk (op=op@entry=0x7ffbe42197b0, rs=0x7ffbf11bcaa0, which=op_search, oi=0x980e00, on=0x0) at backover.c:677
#15 0x000000000049de86 in over_op_func (op=0x7ffbe42197b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730
#16 0x000000000049dfab in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757
#17 0x000000000043bef6 in do_search (op=0x7ffbe42197b0, rs=0x7ffbf11bcaa0) at search.c:247
#18 0x0000000000439bc4 in connection_operation (ctx=ctx@entry=0x7ffbf11bcbd0, arg_v=arg_v@entry=0x7ffbe42197b0) at connection.c:1158
#19 0x000000000043a9cb in connection_read_thread (ctx=0x7ffbf11bcbd0, argv=<optimized out>) at connection.c:1294
#20 0x0000000000563cbf in ldap_int_thread_pool_wrapper (xpool=0x8e36a0) at tpool.c:696
#21 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf11bd700) at pthread_create.c:307
#22 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 0x00007ffff674d603 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81
#1 0x000000000043618b in slapd_daemon_task (ptr=<optimized out>) at daemon.c:2539
#2 0x00007ffff754cdd5 in start_thread (arg=0x7ffbf19be700) at pthread_create.c:307
#3 0x00007ffff674d02d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
#0 0x00007ffff754df47 in pthread_join (threadid=140720067045120, thread_return=thread_return@entry=0x0) at pthread_join.c:90
#1 0x00000000005642b8 in ldap_pvt_thread_join (thread=<optimized out>, thread_return=thread_return@entry=0x0) at thr_posix.c:197
#2 0x0000000000437766 in slapd_daemon () at daemon.c:2932
#3 0x0000000000420b84 in main (argc=<optimized out>, argv=0x7fffffffe408) at main.c:1017
The above trace seems to suggest the source of the segfault is coming from the ldap_chain_op function at chain.c:422. We use chain forwarding for ppolicy operations on the consumers.
This is the line:
for ( ; !BER_BVISNULL( ref ); ref++ ) {
BER_BVISNULL is not a function but a macro which is defined (lber_pvt.h:216) as follows:
#define BER_BVISNULL(bv) ((bv)->bv_val == NULL)
The above seems suggests that ref is set to null at the time of the check.
When I double checked my chain configs I noticed there was an entry that did not contain the olcDbURI attribute that I did not create. It seems that this particular entry was created by the cn=config conversion for the following slapd.conf configuration:
Overlay chain
chain-proxy-whoami yes
chain-uri {REDACTED URI 1}
Chain-cache-uri FALSE
Chain-max-depth 1
Chain-return-error TRUE
Chain-idassert-bind bindmethod=“simple”
binddn={REDACTED}
credentials={REDACTED}
Chain-protocol-version 3
chain-uri {REDACTED URI 2}
Chain-cache-uri FALSE
Chain-max-depth 1
Chain-return-error TRUE
Chain-idassert-bind bindmethod=“simple”
binddn={REDACTED}
credentials={REDACTED}
Chain-protocol-version 3
chain-uri {REDACTED URI 3}
Chain-cache-uri FALSE
Chain-max-depth 1
Chain-return-error TRUE
Chain-idassert-bind bindmethod=“simple”
binddn={REDACTED}
credentials={REDACTED}
Chain-protocol-version 3
After the conversion to cn=config:
dn: olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {1}chain
olcChainCacheURI: FALSE
olcChainMaxReferralDepth: 1
olcChainReturnError: TRUE
dn: olcDatabase={0}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: ldaps starttls=no
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn: olcDatabase={1}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: “{REDACTED URI 1}“
olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/
cacerts.cer" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn: olcDatabase={2}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {2}ldap
olcDbURI: “{REDACTED URI 2}“
olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/
cacerts.cer" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
dn: olcDatabase={3}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {3}ldap
olcDbURI: “{REDACTED URI 3}“
olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/
cacerts.cer" tls_reqcert=demand tls_crlcheck=none
olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm
ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: TRUE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
I am wondering if the following is causing the segfaults:
When setting up the configs during the slapd.d conversion, the slapd.conf -> cn=config converter added an extra unnecessary entry for the chain config (there are 4 ldap proxy entries instead of 3). This particular entry that was added does not have an olcDbURI value. Since the referral string is set by the olcDbURI attribute value the missing value results in NULL being set for ref.
However, I have not yet been able to manually trigger the segfault by invoking ppolicy.
I also found a red hat ticket that seemd to detail the same issue (see https://bugzilla.redhat.com/show_bug.cgi?id=1644654).
Any ideas on this? I can also obtain a trace of all the threads if needed.
Jeremy
--
Jeremy Diaz
Rex Consulting, Inc
5652 Florence Terrace, Oakland, CA 94611
email: jeremy.diaz(a)rexconsulting.net
web: [ http://www.rexconsulting.net/ | http://www.rexconsulting.net ]
phone, toll-free: +1 (888) 403-8996 EXT: 5
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons
or entities other than the intended recipient is prohibited.
Rex Consulting, Inc. has been a California Corporation since 2001.
5 years, 5 months