Bug 1380436 - sudo: ignore case on case insensitive domains
Summary: sudo: ignore case on case insensitive domains
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Amith
Marc Muehlfeld
URL:
Whiteboard:
Depends On:
Blocks: 1382395 1392946
TreeView+ depends on / blocked
 
Reported: 2016-09-29 15:00 UTC by Jakub Hrozek
Modified: 2019-05-02 13:21 UTC (History)
14 users (show)

Fixed In Version: sssd-1.15.0-1.el7
Doc Type: Known Issue
Doc Text:
SSSD only applies values in `sudoUser` attributes from AD in lower case Previously, when the System Security Services Daemon (SSSD) fetched "sudo" rules from Active Directory (AD), the `sudoUser` attribute must have match the exact case of the `samAccountName` attribute of the user the rule was assigned to. Due to a regression in Red Hat Enterprise Linux 7.3, the `sudoUser` attribute now only matches lower case values. To work around this problem, rename `sudoUser` attribute values to lower case. With the workaround, "sudo" rules are applied correctly.
Clone Of:
: 1382395 1392946 (view as bug list)
Environment:
Last Closed: 2017-08-01 09:00:03 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:2294 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description Jakub Hrozek 2016-09-29 15:00:54 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/3203

Sudo responder search rules only with user name which may fail on case insensitive domains. We should also search by alias on such configuration.

Comment 5 Jakub Hrozek 2016-11-01 10:33:21 UTC
Steps to reproduce:
 - prepare an AD server
 - extend its schema to contain the sudoers attributes
 - prepare an AD user or a group on the AD server side
 - add a sudo rule that allows the user to run a command. In the sudo rule, try adding the user or a group name in different cases. Especially the exact case should be tested (because that's what used to work in 1.13) and the lowercase should be tested (because that's what admins might intuitively use since the AD domain is case-insensitive).
 - without the patch in 7.2, only the exact case would work. In 7.3.0, without the patch, only the lower case would work
 - with the patch, all cases should work.

Comment 9 Jakub Hrozek 2016-11-08 11:27:29 UTC
master:
f4a1046bb88d7a0ab3617e49ae94bfa849d10645
23637e2fd2b1fe42bdd2335893a11ac8016f56bc
sssd-1-14:
143b1dcbbe865a139616a22b139e19bd772e46f0
88239b7f17f599aefa88a8a31c2d0ea44b766c87

Comment 12 Jakub Hrozek 2016-11-23 10:29:16 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/3241

Comment 13 Jakub Hrozek 2016-11-23 10:36:51 UTC
Additional patches:
    master: 7e23edbaa7a6bbd0b461d5792535896b6a77928b
    sssd-1-14: 54f176066dafafdc12f6e0dd112ff6339308aa7c

Comment 15 Amith 2017-05-18 10:34:27 UTC
Verified the bug on SSSD Version: sssd-1.15.2-29.el7.x86_64

Steps followed during verification:
1. Add sudo rules in AD, allowing users to run commands. Also, assign the sudoUser attribute values in Upper case and lower case. For example:

dn: CN=rule1,OU=Sudoers,DC=sssdad,DC=com
objectClass: top
objectClass: sudoRole
cn: rule1

.
.
sudoUser: sudo_aduser1
sudoHost: ALL
sudoCommand: /usr/bin/less

dn: CN=rule2,OU=Sudoers,DC=sssdad,DC=com
objectClass: top
objectClass: sudoRole
.
.
sudoUser: SUDO_ADUSER2
sudoHost: ALL
sudoCommand: /usr/bin/more

dn: CN=rule3,OU=Sudoers,DC=sssdad,DC=com
objectClass: top
objectClass: sudoRole

.
.
sudoUser: sudo_aduser3@SSSDAD.COM
sudoHost: ALL
sudoCommand: /usr/bin/less

2. Setup sssd client and execute sudo cmds as users in exact case names, lower case names and upper case names.

Sample sssd.conf:

[sssd]
domains = sssdad.com
config_file_version = 2
services = nss, pam, sudo

[domain/sssdad.com]
ad_domain = sssdad.com
krb5_realm = SSSDAD.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
#use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
sudo_provider = ad

[pam]


[root@mudflap sssd]# sudo -l -U sudo_aduser1
Matching Defaults entries for sudo_aduser1 on mudflap:
    !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", 
.....
User sudo_aduser1 may run the following commands on mudflap:
    (root) /usr/bin/less

[root@mudflap sssd]# sudo -l -U SUDO_ADUSER1
Matching Defaults entries for sudo_aduser1 on mudflap:
    !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", 
......
User sudo_aduser1 may run the following commands on mudflap:
    (root) /usr/bin/less

[root@mudflap sssd]# sudo -l -U sudo_aduser2
Matching Defaults entries for sudo_aduser2 on mudflap:
    !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", 
..............
User sudo_aduser2 may run the following commands on mudflap:
    (root) /usr/bin/more

[root@mudflap sssd]# sudo -l -U sudo_aduser3@SSSDAD.COM
Matching Defaults entries for sudo_aduser3 on mudflap:
    !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", 
........
User sudo_aduser3 may run the following commands on mudflap:
    (root) /usr/bin/less

[root@mudflap sssd]# sudo -l -U sudo_aduser3
Matching Defaults entries for sudo_aduser3 on mudflap:
    !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", 
...........
User sudo_aduser3 may run the following commands on mudflap:
    (root) /usr/bin/less

[root@mudflap sssd]# sudo -l -U SUDO_ADUSER3
Matching Defaults entries for sudo_aduser3 on mudflap:
    !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", 
..............
User sudo_aduser3 may run the following commands on mudflap:
    (root) /usr/bin/less


With the latest sssd build, issue seems to be resolved.

Comment 16 errata-xmlrpc 2017-08-01 09:00:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:2294


Note You need to log in before you can comment on or make changes to this bug.