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 -- [email protected]
> > To unsubscribe send an email to [email protected]
> > 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/[email protected]
> >
>
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
