Using FreeIPA for centralized sudo - using SSSD for sudoers

Question

I have setup FreeIPA for centralized sudo and all is working well with the exception of being able to use SSSD for sudoers.

If I have in my client /etc/nsswitch.conf the following:

sudoers: files ldap

a sudo command works as desired when the FreeIPA server is available. However, I would like to use SSSD so that in the event that the FreeIPA server were unavailable that sudo would still work.

When I have in my client /etc/nsswitch.conf the following:

sudoers: files sss

And my /etc/sssd/sssd.conf the following:

[domain/example.com]

cache_credentials = True
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = host3.example.com
chpass_provider = ipa
ipa_server = _srv_, ipa.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
domains = example.com
ldap_sudo_search_base = ou=SUDOers,dc=example,dc=com
.
.
.
[snip]

And try to run sudo I'll get:

user1 is not allowed to run sudo on host3. This incident will be reported.

This is a different error than:

user1 is not in the sudoers file. This incident will be reported.

which leads me to believe that SSSD has actually retrieved something from FreeIPA but that what it got is wrong somehow. My one and only sudorule on the FreeIPA server is:

[root@ipa ~]# ipa sudorule-find
-------------------
1 Sudo Rule matched
-------------------
  Rule name: All
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  User Groups: admins
----------------------------
Number of entries returned 1
----------------------------

and the user that I'm issuing sudo with is in the admins group (again it works when ldap is specified in the nsswitch.conf).

What am I missing?

UPDATE 1:

Believe my sssd.conf was incorrect, have updated to include:

sudo_provider = ldap
ldap_uri = ldap://ipa.example.com
ldap_sudo_search_base = ou=SUDOers,dc=example,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/host3.example.com
ldap_sasl_realm = EXAMPLE.COM
krb5_server = ipa.example.com
[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
domains = example.com
.
.
.
[snip]

Get the same message though, i.e.:

user1 is not allowed to run sudo on host3. This incident will be reported.

UPDATE 2:

I turned on debug for SSSD, i.e. edited /etc/sssd/sssd.conf and added:

debug_level = 5

I then inspected the /var/log/sssd/sssd_example.com.log. In here I noticed that SSSD doesn't like CAPITALS in a value for ldap_sudo_search_base, i.e. when I had

ldap_sudo_search_base = ou=SUDOers,dc=example,dc=com

I noticed in the log that there wasn't an entry for ldap_sudo_search_base at all. When I changed to lowercase ou=sudoers I then saw the entry in the log, e.g.:

(Thu Dec 12 18:58:31 2013) [sssd[be[example.com]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][ou=sudoers,dc=example,dc=com][SUBTREE][]

I still get the same user1 is not allowed to run sudo on host3. so it still remains unresolved.

UPDATE 3

(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [accept_fd_handler] (0x0400): Client connected!
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Received client version [1].
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_cmd_get_version] (0x0200): Offered version [1].
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'user1' matched without domain, user is user1
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'user1' matched without domain, user is user1
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting default options for [user1] from [<ALL>]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [[email protected]]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [[email protected]]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving default options for [user1] from [example.com]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=user1)(sudoUser=#1219400005)(sudoUser=%apache)(sudoUser=%superadmins)(sudoUser=%user1)(sudoUser=+*))(&(dataExpireTimestamp<=1387476127)))]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [<default options>@example.com]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'user1' matched without domain, user is user1
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): name 'user1' matched without domain, user is user1
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [user1] from [<ALL>]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [[email protected]]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [[email protected]]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [user1] from [example.com]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=user1)(sudoUser=#1219400005)(sudoUser=%apache)(sudoUser=%superadmins)(sudoUser=%user1)(sudoUser=+*))(&(dataExpireTimestamp<=1387476127)))]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=user1)(sudoUser=#1219400005)(sudoUser=%apache)(sudoUser=%superadmins)(sudoUser=%user1)(sudoUser=+*)))]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [[email protected]]
(Thu Dec 19 18:02:11 2013) [sssd[sudo]] [client_recv] (0x0200): Client disconnected!
(Thu Dec 19 18:02:11 2013) [sssd[sudo]] [client_destructor] (0x2000): Terminated client [0x2095c60][18]

Solution

Make sure your configuration follows a simple setup described here: https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html

Ok, since I made that simple setup after verifying it works on RHEL 6.x and Fedora 18, I wish you had specified more details to help you.

Here is my working example with Fedora 19 (test sudo packages with RHEL 6.5 fixes forward ported):

[root@id ~]# nisdomainname 
example.com
[root@id ~]# sudo -U admin -l
Matching Defaults entries for admin on this host:
    requiretty, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR
    LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
    env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME
    LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
    secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User admin may run the following commands on this host:
    (root) /usr/bin/bash
[root@id ~]# LANG=en_US.utf8 ipa sudorule-show admins --all
  dn: ipaUniqueID=83814998-68c1-11e3-a7ad-001a4a418612,cn=sudorules,cn=sudo,dc=example,dc=com
  Rule name: admins
  Enabled: TRUE
  User Groups: admins
  Hosts: id.example.com
  Sudo Allow Commands: /usr/bin/bash
  RunAs External User: root
  ipauniqueid: 83814998-68c1-11e3-a7ad-001a4a418612
  objectclass: ipaassociation, ipasudorule
[root@id ~]# su - admin
[admin@id ~]$ sudo /usr/bin/bash
[sudo] password for admin: 
[root@id admin]# exit
[admin@id ~]$

Do you have nisdomainname defined?

Comments

[HTTP500]

Thanks for your reply but I've seen that post.

[abbra]

From your question I don't see what platform you are working with. Fedora 19 has unsolved bug in sudo package that prevents SSSD sudo integration working, RHEL 6 has this bug fixed.

[HTTP500]

I am using CentOS/RHEL 6.5.

[abbra]

I've updated my answer with the example output. One thing you need to make sure is set is nisdomainname -- this is sudo's requirement due to the way it handles netgroups.

[HTTP500]

Yes, nisdomainname is set. Again it all works if I am using "sudoers: files ldap" in /etc/nsswitch.conf

[abbra]

with sudoers: files ldap you are using completely different backend. Can you enable debug_level=9 in [sudo] section of sssd.conf and add debug sudo /var/log/sudo-debug all@debug to /etc/sudo.conf? These two will generate enough debug information to find out what exactly fails.

[HTTP500]

I've added UPDATE 3 with the sssd_sudo.log output at debug_level = 8 (cuts out some noise). The sudo-debug.log produced 1500 lines of output, can you narrow it down to what to look for? Anyway, it looks like SSSD can't find any rules (i.e. my All rule). But why?

[HTTP500]

It is working now. I was messing around a lot with different switches to ipa-client-install (after doing an uninstall) and got my sssd.conf mixed up with another host I was also testing on. I think - but can't say for sure - that when I first reported this it was using the correct ldap_sasl_authid host but perhaps it wasn't. Anyway, I learned a lot in debugging this, thanks for your help.

[abbra]

great. For others, Fedora 19 will need this update to sudo to have it working: sudo-1.8.6p7-2.fc19