5:34 a.m.
On Thu, Oct 24, 2019 at 11:52:56AM +0200, Pavel Březina wrote:
On 10/23/19 11:31 PM, Erinn Looney-Triggs wrote:
> Folks I am in the process of working through this but I thought I would
> throw it out just in case there were other thoughts or I was chasing
> down the wrong lane.
>
> We have a requirement for sudo to use a different password than the user
> password where I work. Now in RHEL 7 we implemented this requirement by
> modifying the pam stack for sudo to use the pam_krb5 module like the
> following:
>
> auth required pam_env.so
> auth requisite pam_succeed_if.so uid >= 500 quiet
> auth sufficient pam_krb5.so try_first_pass no_user_check
> auth required pam_deny.so
> account sufficient pam_localuser.so
> account sufficient pam_succeed_if.so uid < 500 quiet
> account [default=bad success=ok user_unknown=ignore] pam_krb5.so
> account required pam_permit.so
> password requisite pam_cracklib.so try_first_pass retry=3 type=
> password sufficient pam_krb5.so try_first_pass use_authtok
> password required pam_deny.so
> session optional pam_keyinit.so revoke
> session required pam_limits.so
>
> Now pam_krb5 is configured to auth against a username/sudo principal in
> /etc/krb5.conf like the following (the mappings is the important part):
>
> [appdefaults]
> pam = {
> debug = false
> forwardable = true
> renew_lifetime = 24h
> ticket_lifetime = 24h
> krb4_convert = false
> mappings = ^(.*)$ $1/sudo
> }
>
> pam_krb5 has for better or worse gone the way of the dodo in RHEL 8 and
> so I am looking to implement something similar using sssd. Our systems
> are already joined to an AD, and it appears to me for the moment that
> the 'application domain' using pam_sss might be the right approach here.
> I understand that it is best tested with LDAP, but well, here we go. So
> thus far I have:
>
> [application/appdom]
> inherit_from = ad.example.com
>
> and the /etc/pam.d/sudo has the following inserted:
>
> auth sufficient pam_sss.so forward_pass domains=appdom
>
> Great it seems to work. Now I need to remap the name to username/sudo
> and auth it against kerb. I don't even know if this is possible at this
> point, but again I thought I would write it up and ask just in case
> someone knew.
No, this is AFAIK not possible at the moment, as you already found out.
Sumit, given the mapping only appends /sudo to the username, would it make
sense to open an RFE to support such thing?
Hi,
we already have krb5_map_user, but if there are many users it might be
cumbersome to add a mapping for each. So some pattern/regex based
approach might be a good extension.
However, I'd like to understand the setup here a bit better to see if
there might be an alternative solution as well.
Erinn, are the 'user/sudo' principals are handled by AD as well? If yes,
can you send an example of the LDAP object which is used for this? Since
you said this is about a different password I assume there must be a
separate object. This object should either have 'user/sudo' as
samAccountName or 'user/sudo@REALM' as userPrincipalName. With this is
should be possible to configure [application/appdom] so that the "right"
principal is used.
bye.
Sumit
>
> Thanks,
>
> -Erinn
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
>