My LDAP PTSD is coming back…
I’ll make the following LDAP assumptions:
- LDAP directory is configured and available
- LDAP uri is configured and a lookup on system level is working and returns the correct POSIX uid/gid with LDAP query
- no POSIX conflicts on the client (no object in passwd has uid/uid 11004) I can assume this because the fail over is root
- LDAP search base is configured and returns expected POSIX values
And I’ll make the following postgres assumptions:
- pg_hba.conf is configured for LDAP server address, port, and search base
- postgres can instantiate and connect to its dbs using LDAP with ldap
Finally, I’ll assume that your nfsv4 mount is active and that POSIX operations work at Pam - level tests.
The line
group: files [SUCCESS=merge] sss [SUCCESS=merge] systemd
Seems weird to me; either you add success clause to both uid and gid, or none, but not one and not the other.
This would also hint that Pam has not been updated to use LDAP.
That’s where I’d start.
Side note: LDAP is by default unencrypted on the wire, so to complete this exercise, you may want to setup secrecy on the server. This is especially important for db creds.
We would need more info to help confirm, but watching ids traffic will show you lots of misconfigurations as well as actually suspicious traffic, so this might be a POS device doing stupid stuff.
Is suricata listening on an internal subnet interface? If you are listening on a public interface, your job sorting through the trash traffic will be difficult because determining source is nearly pointless and your external interface should not know anything about the internal subnet.