On Wed, Sep 17, 2014 at 09:56:47AM -0700, Michichael Folfsunè wrote:
Hello Everyone,
Sorry if this is the wrong place to send this.
This is totally the right place to ask. Sorry for the late reply.
Tried figuring out how to
add a bug on the launchpad or the main site, but couldn't find anywhere to
actually submit a *new* bug. I searched through the bug tracker and it
doesn't look like this has been reported, so here you go:
Linux Version: Oracle Enterprise Linux 6.4 and 6.5 (RHEL)
SSSD Version: sssd-1.9.2-129.el6_5.4.x86_64 (No higher versions available
in yum)
Problem:
When case_sensitive = False is set, groups are returned lower-case
regardless of what the case of the group is in the directory. However,
sudoers rules aren't being detected as applicable unless the case of the
sudo rule in LDAP matches the case of the group. With just %test_admin, we
get a "User is not allowed to run sudo" error. But if we add %TEST_Admin to
the rule, sudo operates as expected.
I see. Unfortunately our team's sudo expert is out of the office this
week and I'm not too intimate with the sudo codebase to answer the
question. Maybe Daniel, the sudo maintainer (CC-ed) can help us?
Dan, if, for a user whose canonical username is mixed case, but SSSD
(and thus getpwnam()) returns lowercase username and at the same time,
SSSD matches the sudoUser attribute in a case-insensitive way, would
then sudo match the rules? If not, is that a sensible sudo RFE?
Below is some sanitized data.
This is getent or id:
util: /home/michichael> getent -s sss group test_admin
test_admin:*:10004:michichael
util: /home/michichael> getent -s sss group TEST_Admin
test_admin:*:10004:michichael
util: /home/michichael> id
uid=10002(michichael) gid=10004(test_admin) groups=10004(test_admin)
context=system_u:system_r:unconfined_t:s0-s0:c0.c1023
The LDAP entries in question are:
dn: cn=TEST_Access,ou=sudoers,dc=domain,dc=local
sudouser: %test_admin
sudorunasuser: ALL
sudocommand: ALL
sudohost: ALL
objectclass: top
objectclass: sudoRole
cn: TEST_Access
dn: cn=test_admin,ou=security groups,dc=domain,dc=local
uniquemember: cn=michichael folfsune,ou=test_users,ou=people,dc=domain,dc=
local
orclsourceobjectdn: CN=TEST_Admin,OU=Security Groups,DC=DOMAIN,DC=LOCAL
orclsamaccountname: TEST_Admin
gidnumber: 10004
displayname: TEST_Admin
objectclass: orcladobject
objectclass: groupofuniquenames
objectclass: orcladgroup
objectclass: orclgroup
objectclass: top
objectclass: posixgroup
orclobjectguid: TJTtdC/I6UK6m3uwpo/UXA==
cn: TEST_Admin
description: TEST Administrators
And the SSSD Config is:
sudo cat /etc/sssd/sssd.conf
[sudo] password for michichael:
[domain/default]
ldap_schema = rfc2307bis
ldap_tls_cacertdir = /etc/oracle-certs/
ldap_tls_cacert = /etc/oracle-certs/InternalCA.pem
ldap_user_member_of = uniqueMember
ldap_group_object_class = posixGroup
ldap_group_name = cn
ldap_group_gid_number = gidNumber
ldap_group_member = uniqueMember
ldap_group_nesting_level = 6
ldap_default_bind_dn = cn=binduser,cn=Users,dc=domain,dc=local
ldap_default_authtok_type = password
ldap_default_authtok = bindpassword
ldap_id_use_start_tls = True
ldap_search_base = dc=domain,dc=local
ldap_group_search_base = dc=domain,dc=local
case_sensitive = False
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
sudo_provider = ldap
ldap_uri =
ldap://ldapserver.domain.local:389/,ldap://secondaryldap.domain.local:389/
ldap_sudo_search_base = ou=sudoers,dc=domain,dc=local
[sssd]
services = nss, pam, sudo
config_file_version = 2
domains = default
[nss]
[pam]
[sudo]
sudo_timed = true
[autofs]
[ssh]
[pac]
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel