Re: LDAP authentication + Configuring PAM

[Ludovic Courtès]

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