Redundant Database, Pgsql ?

[Brendan Kearney]

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 at 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.
>