[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LDAP authentication + Configuring PAM
From: |
Ludovic Courtès |
Subject: |
Re: LDAP authentication + Configuring PAM |
Date: |
Fri, 23 Aug 2019 14:14:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) |
Heya!
Ricardo Wurmus <address@hidden> skribis:
> My findings so far:
>
> * NSCD *must* be extended with caches for “passwd” and “group”
> databases or else applications will make the lookup for user accounts
> directly and will not consult LDAP at all.
Nscd already has caches for those in our default configuration, doesn’t
it?
> * it’s a pity that “name-service-switch” is not a system service and has
> to be extended manually. … Or is this perhaps how we should treat PAM
> configuration as well?
We should turn ‘name-service-switch’ into an extensible service, IMO.
It just happens to predate the service type graph.
> But back to the problem of authenticating users via LDAP. With our
> default unix-pam-service “pam_unix.so” (which checks that a user account
> exists locally and checks its password) is required, so LDAP
> authentication will always fail.
>
> I extended the pam-root-service-type with a service that matches on all
> pam_unix.so modules and makes them use the “sufficient” keyword instead
> to overcome this.
So you’re extending ‘pam-root-service-type’ with a “transformation”
procedure, right?
> This is problematic when nslcd-service-type is involved because it
> extends pam-root-service-type to add entries for pam_ldap.so. Instead
> of using a string “pam_ldap.so” it uses a G-expression to compute the
> absolute file name of “pam_ldap.so”. When extending the service and
> matching on PAM entries, however, we don’t have a string of the
> absolute file name to match on — we have a G-expression that is really
> awkward to match against.
Could you match against a <file-append> record?
> I worked around this (by lowering the G-expression first), but it’s
> ugly. And even then I still have the problem that I can’t control the
> order of PAM entries at all.
Perhaps we could add a field in <pam-configuration> that would be
transformation procedure that takes the complete list of entries?
> Perhaps we should implement a different mechanism for specifying PAM
> entries for the system, perhaps similar to what the name-service-switch
> field does?
We could also allow users to specify
(service pam-root-service-type (pam-configuration …))
in their ‘services’ field. Would that help?
> I also recommend using “sufficient” as the default keyword for
> “pam_unix.so” and ending the stack with “required pam_deny.so”. This
> would make it easier to extend the stack without having to rewrite
> existing module entries.
Why not.
Tricky issues! NixOS has lots of hard-coded cases instead of a generic
way to extend PAM settings:
https://github.com/NixOS/nixpkgs/blob/release-19.03/nixos/modules/security/pam.nix#L304
>From what you wrote, it may be that PAM configuration is simply not
“composable”, in the sense that you cannot assemble bits without viewing
the global picture.
Thanks,
Ludo’.