Re: Using more than one LDAP?

On Thu, Jan 7, 2021 at 10:40 AM Paul Förster <paul.foerster@gmail.com> wrote:
>
> Hi Magnus,
>
> > On 06. Jan, 2021, at 16:57, Magnus Hagander <magnus@hagander.net> wrote:
> >
> > Yes. But you have a really hacky environment :P
>
> actually not. We have an old LDAP which we want to retire this year. And we also have Windows AD, which offers LDAP.
Sothe idea is to switch the LDAP environments in PostgreSQL. The old LDAP uses aaa-u1, aaa-u2, etc. which are also
accountsin the database. But our Windows AD has bbb-u1, bbb-u2, etc. So just switching LDAPs doesn't work. I'd also
haveto rename all users. Though it's just a one-liner, it would mean that users have to use their new names from one
secondto the next. But we want a transition phase if that's possible. 
>
> > You could have a third LDAP instance that federates the other two.
> >
> > Another option could be to proxy it through something like FreeRADIUS.
> > I'm fairly certain it can also move on to a secondary server if the
> > first one reports login failure.
>
> I can't. I'm no sysadmin and have no rights on systems to install anything except the PostgreSQL software. Also, the
networkguys wouldn't be too happy. And then, there is a problem introducing new software, which is possible, but can
takemonths for us to get the necessary permissions. 

This would be the hacky part of the environment: )



> > I assume you're not using any of the standard packagings then, as I
> > believe they all come with support for GSSAPI. Yet another reason why
> > it's a good idea to use that :)
>
> no, we always compile from source and only what we need. I can build packages with GSSAPI compiled into it but it
doesrequire me do have a small service interruption if I install packages with the same PostgreSQL version number, a
situation,which I'd like to avoid, if possible. 

And this would be the second hacky part of the environment :)


> > And no, gssapi does not use certificates.
>
> that's good news as I'm not really happy about all that certificate stuff. ;-)
>
> > pg_ident only works for authentication methods where the username
> > comes from the other system, such as with Kerberos. It does not work
> > for LDAP, where the username is specified in PostgreSQL.
>
> I don' understand that. The doc says it should work for all external authentication services. Maybe I misread
something?...

The docs say "When using an external authentication system such as
Ident or GSSAPI, the name of the operating system user that initiated
the connection might not be the same as the database user (role) that
is to be used."

I think that's a bit of a left-over to when it was really just ident.
First of all it should probably say peer rather than ident, and it's
not actually operating systems that are relevant here.

So I can understand you getting ab it confused by that. but the
property that matter is where the username comes from. In GSSAPI, or
peer, or certificate, etc, the username is provided by the external
system, and the mapping is applied *after* that.

With LDAP authentication, the username is provided by the client, and
is then passed to the external system.

Mapping applies *after* the authentication, which inthe case of LDAP
would be too late to make any difference.

The references to "unix user" and "operating system users" are
probably a leftover from the old days and actually contribute to some
of the confusion I think.

--
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/