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.
Thanks,
-Erinn
And it looks like this may not be possible if this page is correct: https://docs.pagure.org/SSSD.sssd/users/pam_krb5_migration.html
There is no regex support in user mappings, thus this may not work at all.
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?
Thanks,
-Erinn _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
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@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
So yes I saw krb5_map_user, problem is we have hundreds of these users and that list grows and shrinks dynamically as people come and go. I could do some really terrible hack to pull the data from wherever and stick it into krb5_map_user but that's just awful. Ultimately regex support here would solve everything.
I can't fully answer your second question yet, I am digging into it and I don't know this area of auth well enough. It appears for the moment that user/sudo is NOT a separate object. I know we don't have any other kerb other than the AD so perhaps we are injecting principles directly into the krb database in AD, which I realize is just backed into LDAP etc. etc.
I'll pass along more info when I have it.
Correction they are full AD objects. So any ideas for a workaround are welcome.
-Erinn
Well I attempted to get this to work and I couldn't find a way. I attempted to set up a separate domain and then modify the re_expression, however that just modifies what gets captured into SSSD, and there is now way I can find to make a substitution. After looking around for other options (short of modifying the code) I'm left with packaging pam_krb5 ourselves for RHEL 8 in order to distribute it to our internal systems. I'm certainly open to other ideas, but I can't see how to modify the username in a non static way.
I've opened a couple of bug reports, one against sssd itseld, one against RHEL 8: https://pagure.io/SSSD/sssd/issue/4109 https://bugzilla.redhat.com/show_bug.cgi?id=1767176
It'll be a matter of peoples opinion as to whether to fix these, I realize my employer is in a minority by using sudo in this manner.
Thanks, -Erinn
On Wed, Oct 30, 2019 at 08:36:35PM -0000, Erinn Looney-Triggs wrote:
Well I attempted to get this to work and I couldn't find a way. I attempted to set up a separate domain and then modify the re_expression, however that just modifies what gets captured into SSSD, and there is now way I can find to make a substitution. After
Hi,
sorry for the delay, I was hoping you will send examples of the plain user and sudo related AD object.
re_expression is indeed not the right place. Depending on how the AD objects look like and where they are stored you should modify the search bases or enhance the search filters. The issue in the SSSD side is that SSSD assumes that users are uniquely found only in one domain to make the pam_sss domains option work. I currently trying ot figure out if this behavior was added on purpose of if the assumption can be dropped to make using SSSD in you case more easy.
Nevertheless e.g. assuming that the plain AD users are stored in the cn=users,dc=domain OU and the sudo objects in cn=sudo,dc=domain you can just set the search bases accordingly for each domain
If the sudo objects are stored in a sub-OU of cn=users,dc=domain you have to change the search scope for cn=users,dc=domain as well so that the other objects are not found, e.g.
ldap_search_base = cn=users,dc=domain?one
If the objects only differ in some attributes you can add a filter to the search base as well, e.g.:
ldap_search_base = cn=users,dc=domain?subtree?(userPrincipalName=sudo*)
I hope this gives you some idea how to configure the two domains. But feel free to share a sanitized layout of the two object kinds so that I can help to find a suitable configuration.
bye, Sumit
looking around for other options (short of modifying the code) I'm left with packaging pam_krb5 ourselves for RHEL 8 in order to distribute it to our internal systems. I'm certainly open to other ideas, but I can't see how to modify the username in a non static way.
I've opened a couple of bug reports, one against sssd itseld, one against RHEL 8: https://pagure.io/SSSD/sssd/issue/4109 https://bugzilla.redhat.com/show_bug.cgi?id=1767176
It'll be a matter of peoples opinion as to whether to fix these, I realize my employer is in a minority by using sudo in this manner.
Thanks, -Erinn _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@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.fedorahosted.o...
sssd-users@lists.fedorahosted.org