Am 25.06.2025 um 17:33 schrieb Peter J. Holzer:
On 2025-06-25 14:42:26 +0200, raphi wrote:
[snip]
That's not how the identiy principle works, at least not how it's implement
in our company. A user in ldap has a direct relation to one digital entity,
either a token from an application or certificate from a physical person
(maybe some AD shenanigans also). We don't have digital entities for teams,
that's what's missing. For it to work they (security) would need to allow to
weaken this principle and as you said, allow everyone who has a certain role
to manage the associated user in LDAP, like setting a new password.
That user shouldn't have a password, since nobody is authenticating as
that user. It also doesn't have to exist in LDAP. It's just a role in
the database.
hmm I don't follow, maybe I was doing it wrong? In my tests I configured
LDAP as described in the documentation:
https://www.postgresql.org/docs/current/auth-ldap.html
[quote]
Once the user has been found in this search, the server re-binds to the
directory as this user, using the password specified by the client, to
verify that the login is correct
[/quote]
And this worked as expected, when the user provided the password stored
in LDAP, they could login and couldn't when given a wrong (or empty)
password. Can you elaborate on what you mean?
[snip]
But do they? "Complexity" (scare quotes intentional) rules are easy to
circumvent and when people don't see the need for strong passwords, they
will do so. If they do see the need they will use strong passwords on
their own and the rules are somewhere between unnecessary and
counter-productive. Most guidelines also have stopped recommending
mandatory password rotations quite some time ago.
These features provide convenient boxes for auditors to tick off and
security for management who can claim that they did something.
Operational security? Not so much.
(just my personal opinion as someone who's been a sysadmin for over 20
years (although not recently))
Well, PCI still does. But checking auditors boxes is not the main reason
I am looking for a solution (because we don't have any PCI applications
on PG yet anyway) but our self service: An ansible playbook creates a
role for someone and sends the password by email to the user who wanted
the role created. This password ought to be temporary and should be
changed upon first connect. Without any checks we can't neither ensure
that the password will be changed nor that it won't be reused. We make
it clear that this should happen and most devs probably do the sensible
thing and set a new complex password but as you said, some people are
just lazy and there's no feasable way for us to verify this.
have fun
raphi (who also was once in an almost forgotten lifetime a solaris admin
for over 20 years ;))
