"Authentication failure" on Ubuntu 18.04...
by Robert Heller
I have a server running CentOS 6 on the bare metal, running the stock CentOS 6
OpenLDAP packages (openldap-2.4.40-16.el6.x86_64,
openldap-clients-2.4.40-16.el6.x86_64, openldap-2.4.40-16.el6.i686,
openldap-servers-2.4.40-16.el6.x86_64) [yes I know these are old, but they
*work* -- "If it ain't broke, don't fix it."]. There are two VMs running on
this server, one running Ubuntu 14.04 and the other Ubuntu 18.04. (These two
VMs are/will be servers for DRBL.) The Ubuntu 14.04 VM (and all of its
diskless clients) are perfectly happy to talk to the OpenLDAP server (slapd)
running on the CentOS 6 machine. The Ubuntu 18.04 VM is not. ldapsearch works
everywhere though, so it is NOT the server or the core ldap libraries on any
of the machines (partitularly the Ubuntu 18.04 VM). I can only assume that
there is something fishy with nslcd or the pam/ldap libraries or config on the
Ubuntu 18.04 VM. I have checked everything, but I am coming up empty. I am
thinking there might be some "trick" to getting LDAP Authentication to work
under Ubuntu 18.04 that I am missing.
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller(a)deepsoft.com -- Webhosting Services
4 years, 5 months
Question about OID / feedback on schema
by Mikael Bak
Hi list,
After a previous discussion on this list[1] I've decided to define an
object class and some attributes of my own to be able to turn users
on/off and to be able to have their subscriptions expire.
I got a lot of help from Michael Ströder, who pointed me in the right
direction. Thank you for that!
What I have so far looks like this:
#objectidentifier oszkSchema x-hu-OSZK
objectidentifier oszkSchema 1.3.6.1.4.1.4203.666
objectidentifier oszkAttrs oszkSchema:3
objectidentifier oszkOCs oszkSchema:4
attributetype ( oszkAttrs:1
NAME 'oszkAccountActive'
EQUALITY booleanMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
SINGLE-VALUE )
attributetype ( oszkAttrs:2
NAME 'oszkAccountExpire'
SINGLE-VALUE
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
objectclass ( oszkOCs:1 NAME 'oszkPerson'
DESC 'OSZK person'
SUP inetOrgPerson
MUST ( oszkAccountActive )
MAY ( oszkAccountExpire ) )
My question is what I can use for OID in the beginning of the file? I
tried to use a private name (beginning with "x-" as described here:
http://www.openldap.org/doc/admin24/schema.html
That did not work. Using the numeric OID above works, but I'm not sure
what numbers are safe to use. This schema is going to be local on one
server for the time being.
So my question is: Is there a way to know what OID's I can use for
private/local use only. I would like to avoid registering my
organization with IANA fo now.
I did not find that information in the above document. If I missed it
and it's there, then I appologize.
Secondly, if you find any errors or potential problems with my schema,
then please let me know. I'm an LDAP beginner.
TIA,
Mikael
[1] http://www.openldap.org/lists/openldap-technical/201904/msg00006.html
4 years, 6 months
idassert-authzFrom: Proper way to include only non-anonymous binds
by Patrik Lundin
Hello,
What is the proper way to make sure only non-anonymous binds are allowed
to utilize idassert-bind credentials?
Reading http://www.openldap.org/faq/data/cache/532.html the following is
stated:
===
Authorize only non-anonymous:
idassert-authzFrom "dn:*"
===
It also states:
===
The idassert-authzFrom mechanism controls whether a client's identity
can be asserted or not. The idassert-authzFrom mechanism basically
selects what identities can access the identity assertion feature, and
indeed should be considered as the set of values of the authzFrom
attribute associated to the administrative identity, with the essential
difference that, if not present, by default every identity is
authorized, including anonymous.
===
These excerpts makes me believe that the expected default behaviour is that a
missing idassert-authzFrom will allow anyone, even anonymous binds. That
a pattern of "*" is supposed to match non-anon binds is also stated in
the slapd.conf man page (https://linux.die.net/man/5/slapd.conf):
===
A pattern of * means any non-anonymous DN.
===
Then there is this contradictory message I found while looking through
the lists:
https://www.openldap.org/lists/openldap-technical/200809/msg00096.html
It states:
===
If you want idassert to work also for anonymous operations (not
recommended, as this defeats the security model of the remote server, by
letting it believe that the proxy authenticated users while it didn't),
you need to explicitly enable it using an idassert-authzFrom rule that
includes anonymous, like
idassert-authzFrom "dn.regex:.*"
===
This is more in line with my tests, where removing the
"idassert-authzFrom" all together stops an anonymous ldapsearch from
returning a result, while adding 'idassert-authzFrom "dn:*"' makes it
return results for the anon bind.
I realize there is a difference between the the line from the FAQ
("dn:*") and the line from the mailing list ("dn.regex:.*") but looking
at slap_idassert_authzfrom_parse():
https://github.com/openldap/openldap/blob/b06f5b0493937fc28f2cc86df1d7f46...
... it appears to me that "*", "dn:*" and "dn.regex:.*" are supposed to
be equivalent. I am using the meta backend, but I'm guessing they are
sharing code in this case.
The man page for slapd-meta does not state what the result of not
configuring a "idassert-authzFrom" is though it seems to yield the
results I want (that only properly authenticated connections can make
use of the idassert-bind credentials).
I'm guessing one way to make sure only authenticated clients can do
anything is to add "require authc" to the config, but it is hard to tell
how these things interact, and it would be nice to know what the
expected way to configure idassert-authzFrom is (even if it means
leaving it unset).
Regards,
Patrik Lundin
4 years, 6 months
Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias
Thank you very much Quanah for your response!
> Sort of. If you added the schema and then an object, the other masters
> should halt replication at that point until they have a matching schema.
That's interesting.
> Not really, no. It does depend on the version of OpenLDAP in use, as
> there
> were some bugs in older OpenLDAP versions that would allow the object to
> partially replicate or the object to just get skipped, which could cause
> headache. But those issues were fixed.
>
So then best practice with tree sync is add the schema to all masters
first, then an object. which would make sense.
> I would say that by doing cn=config replication, you've added a wide
> surface area for new issues to occur. I generally view cn=config
> replication as more of a beta feature. There are still ongoing issues
> being resolved and fixed for it (For example, ITS#8616 in the most recent
> 2.4.47 release)
Hmm... so would you recommend removing the replication of cn=config for
now? Individually adding the schema to each master is feasible for us.
Thank you again
-Dave
4 years, 6 months
Re: Help needed: "glued" object.
by Alex Hebra
Hi Quanah,
Thanks for your answer. Here are the details asked:
OpenLDAP version 2.4.46.
Mirror configuration on node A:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
# Global section
serverID 1
# database section
# syncrepl directive
syncrepl rid=001
provider=ldaps://02.host.com
bindmethod=simple
binddn="cn=root,dc=xxx"
credentials=xxx
searchbase="dc=xxx"
schemachecking=on
type=refreshAndPersist
retry="10 +"
tls_cacert=/usr/local/etc/openldap/cert/cert02.crt
mirrormode on
Mirror configuration on node B:
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
# Global section
serverID 2
# database section
# syncrepl directive
syncrepl rid=001
provider=ldaps://01.host.com
bindmethod=simple
binddn="cn=root,dc=xxx"
credentials=xxx
searchbase="dc=xxx"
schemachecking=on
type=refreshAndPersist
retry="10 +"
tls_cacert=/usr/local/etc/openldap/cert/cert01.crt
mirrormode on
Thank you very much.
On Tue, Apr 2, 2019 at 7:02 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote:
> --On Tuesday, April 02, 2019 4:59 PM -0300 Alex Hebra <hebraalex(a)gmail.com>
>
> wrote:
>
> >
> >
> > Hi there,
> >
> >
> > I have a very critical OpenLDAP environment running on mirror mode
> > configuration. Is has about 800.000 users.
>
> Hello,
>
> You failed to provide any information on the release of OpenLDAP you are
> using and did not provide any information on the replication mechanism in
> use. By the sound of it, you are using standard syncrepl, where this sort
> of problem is not uncommon, particularly with older versions of OpenLDAP.
> I would suggest you start by noting the version of OpenLDAP in use and
> providing information on the setup and configuration of the multimaster
> nodes.
>
> Regards,
> Quanah
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
4 years, 6 months
Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias
Ha!
Of course.
Thank you for support
Best Regards,
Dave
On Apr 3, 2019, 4:41 PM -0400, Quanah Gibson-Mount <quanah(a)symas.com>, wrote:
> --On Wednesday, April 03, 2019 5:27 PM -0400 Dave Macias <davama(a)gmail.com>
> wrote:
>
> > > To which I should add -- And is only being fixed for OpenLDAP 2.5 and
> > > later.
> >
> > ...2.5....any ETA on that? ;)
>
> "When it's ready"? ;)
>
> We've been reviewing our development process and are waiting on a writeup
> from a project member on a new approach going forward to be debated by the
> project team and then implemented as our process for 2.5 and future.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
4 years, 6 months
Re: Question: n-way multimaster syncrep cn=config and tree
by Dave Macias
Got it!
Very helpful! Thank you!
> >> Hmm... so would you recommend removing the replication of cn=config for
> >> now? Individually adding the schema to each master is feasible for us.
> >
> > If it's not required then yes, I personally would not use it at this
> > time. For example, ITS#8286, although it only discusses a single matching
> > rule, ended up touching numerous files, and it's directly related to
> > using cn=config and cn=config replication
> > (<
> https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h
> > =3add82a3bb30b94afd23ff5e2c00c59ca8a931d8>).
>
> To which I should add -- And is only being fixed for OpenLDAP 2.5 and
> later.
>
...2.5....any ETA on that? ;)
Best,
dave
4 years, 6 months
Re: Help needed: "glued" object.
by Alex Hebra
Hi Quanah,
Thank your very much. Your reply is quite clear. After that I made a
decision to migrate to delta-sync and to increase my session log (I have
800k users and 2.000.000 of entries). Please take a look on my new config
after these changes, and let me know if it's ok:
Node A:
# Accesslog database definitions
database mdb
suffix cn=accesslog
directory /var/db/openldap-data/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
#####
# primary db config
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 2000000
# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00
# Global section
serverID 1
# database section
# syncrepl directive
syncrepl rid=001
provider=ldaps://02.host.com
bindmethod=simple
binddn="cn=root,dc=xxx"
credentials=xxx
searchbase="dc=xxx"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="10 +"
syncdata=accesslog
tls_cacert=/usr/local/etc/openldap/cert/certServerID2.crt
mirrormode on
Node B:
# Accesslog database definitions
database mdb
suffix cn=accesslog
directory /var/db/openldap-data/accesslog
rootdn cn=accesslog
index default eq
index entryCSN,objectClass,reqEnd,reqResult,reqStart
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
#####
# primary db config
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 2000000
# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7 days
logpurge 07+00:00 01+00:00
# Global section
serverID 2
# database section
# syncrepl directive
syncrepl rid=001
provider=ldaps://01.host.com
bindmethod=simple
binddn="cn=root,dc=xxx"
credentials=xxx
searchbase="dc=xxx"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="10 +"
syncdata=accesslog
tls_cacert=/usr/local/etc/openldap/cert/certServerID1.crt
mirrormode on
After that I made a change on Node A and it replicated to node B, then I
made a change on node B and it replicated to A. So seems it's working. My
doubt is how can I make sure it's working with delta-sync mode?
Another question, changing to delta-sync can I use more than 2 nodes, for
instance, 3 servers receiving writing and replicating between them?
Thank you.
On Wed, Apr 3, 2019 at 1:09 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote:
> --On Wednesday, April 03, 2019 11:14 AM -0300 Alex Hebra
> <hebraalex(a)gmail.com> wrote:
>
> > Thanks for your answer. Here are the details asked:
> >
> >
> > OpenLDAP version 2.4.46.
> >
> > syncprov-sessionlog 100
> > syncprov-sessionlog 100
>
> Hi Alex,
>
> Your sessionlog value is way too small. It needs to be something a little
> larger than the entire size of your database (so > 800,000 in your case).
> I also see you're using standard syncrepl rather than delta-syncrepl.
>
> Generally, having a "glued" object on a server indicates that at some
> point, the server was in a REFRESH mode (either you populated the server
> using syncrepl instead of slapcat, or it had some reason to fall back to
> REFRESH at a later date).
>
> In the REFRESH mode, the server may get entries "out of order". In this
> case, a stub (glue) object is created to "hold" the place for tha entry
> until it gets fully replicated. Unfortunately, this doesn't always
> happen,
> and you end up being stuck with the glued object on the server.
>
> You may be able to force replication of the object onto the server where
> it's missing by doing a MOD op against the affected entry on the master
> where it exists. If one master is "complete" (I.e., no glued objects),
> you
> could also slapcat that master and import the database into the othe
> rmaster via slapadd to resolve the problem for now.
>
> Overally, I strongly advise using delta-syncrepl as it largely avoids
> these
> issues (as long as it never has to fall back to standard syncrepl REFRESH
> mode).
>
> I would note that there was a fix in OpenLDAP 2.4.47 specific to
> delta-syncrepl when ppolicy is in use, so if using delta-sync you likely
> want that fix.
>
> --Quanah
>
>
>
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
4 years, 6 months
Question: n-way multimaster syncrep cn=config and tree
by Dave Macias
Hello,
we recently adjusted our sync from n-way multimaster replication of the
tree (searchbase="dc=organization,dc=com") and now included our "cn=config"
replication.
Some concerns/questions I have:
Before with only tree replication, it was my understanding that one could
NOT add a new schema along with an object unless said schema already
existed in the other masters. yes?
Our process was to turn off the sync add the schema to each master then
normalize. Probably turning off the sync was unnecessary but just to be
safe. Regardless if a new object with new schemas was added then one could
ruin all the masters. Correct?
Ok, so now with cn=config synchronized as well. Does this issue, if an
issue, go away?
Also, if upgrading one masters openldap software, should the sync be off?
Recommendations?
Any input is much appreciated.
Thank you,
Dave
4 years, 6 months
