Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 [user1@example.com]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [user1@example.com]
(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 [user1@example.com]
(Thu Dec 19 18:02:07 2013) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [user1@example.com]
(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 [user1@example.com]
(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]
share|improve this question

1 Answer 1

up vote 1 down vote accepted

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?

share|improve this answer
    
Thanks for your reply but I've seen that post. –  HTTP500 Dec 18 '13 at 16:36
    
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. –  abbra Dec 19 '13 at 9:13
    
I am using CentOS/RHEL 6.5. –  HTTP500 Dec 19 '13 at 15:47
    
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. –  abbra Dec 19 '13 at 17:05
    
Yes, nisdomainname is set. Again it all works if I am using "sudoers: files ldap" in /etc/nsswitch.conf –  HTTP500 Dec 19 '13 at 17:36

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.