i didnt pick up on the fact that this was auth stuff, and not indexes
(indices?) or other data. LDAP is a hierarchical database, where the
relationship between data is forced into a superior/subordinate
structure. if you ask enough people, they will say that LDAP is not an
authentication platform, but a database. i tend to agree, and have put
Kerberos and LDAP together as my AuthN/Z suite. Kerberos is truly an
AuthN protocol, and when i can point something at it i do. i store my
Kerberos data in LDAP, and run n-way multi-primary replication. MIT
Kerberos does not have an event based replication means, only
time/schedule based. LDAP has an event based replication mechanism, so
when data changes all the nodes in the cluster get an immediate
replicated update. OpenLDAP can also proxy AuthN events to Kerberos
with a few specific configurations set, and the password field being set
to a specific string, {SASL}user@domain. this way something that talks
LDAP, can point to LDAP for AuthN, and be proxied to back Kerberos. to
me, this maintains the ever important "single source of the truth" for
credentials.
I run LDAP behind a HAProxy VIP too, for load balancing purposes and
transparent failover, so apps see less impact when failures occur. load
balancing allows me to scale out (handle more requests in a given unit
of time), and be fault tolerant. take a box out of the mix for updates,
reboots, maintenance, whatever and not interrupt processing. i load
balance nearly every stateful protocol, whenever possible. i anycast
most stateless protocols, too, as a means of load sharing. by having
more than one instance available to do the same work, you greatly reduce
the "hair on fire" calls in the middle of the night, or at least shorten
the Mean Time to Recovery.
On 2/23/23 12:55 AM, Nikolai Lusan wrote:
On Wed, 2023-02-22 at 11:08 +0000, Marc wrote:
> I don't even get what the advatages are of doing this with sql. If you
> use local replicated ldap and use local credential caching then your
> master ldap can go down without issues, even the local caching handle
> some local slapd issues.
Going to have to +1 this. LDAP also does multi-master replication, which
can make failover easier via DNS (like with a round robin for
ldap.mydomain), or multiple LDAP dictionaries for dovecot. The [big]
problem with OSS Postgres is that it only does master/slave replication,
with no plans to add multi-master replication to the code base (there is
Percona and 2ndQuadrant, but for small outfits, and individual there is
a price barrier there). Personally I love PGSQL as a DB, but for SSO I
use LDAP - because that's what it's designed for (i.e. read more than
written).
> I guess the local caching is also faster. Afaik were databases not
> designed for this purpose and a better fit is ldap.
This is totally true. RDBMS were not designed with this kind of use in
mind, LDAP was - it is, after all, a directory service. So unless your
auth stuff is part of some larger DB "thing" the directory type
solutions are not suitable for (how many table joins, or other extensive
SQL actions are taking place on that DB) then LDAP is the better way to
go, and extending LDAP with custom schemas is simple - just grab an IANA
number for you, or your organisation, so that you don't trample on any
other schema out there. I have a custom schema that I use for
postfix/dovecot - it's simple, quick, and efficient without the DB
overhead ... and I get the multi-master replication in OpenLDAP.
