[Freeipa-users] Sudo Rules Help
Branden Coates
bcoates at liquidweb.com
Thu Nov 12 21:57:08 UTC 2015
Thank you for the welcome!
So in the process of pulling the output of the log files with the most
recent attempts on cent6 I sorted out the issues with cent6, though
cent5 is still problematic. I added debug_level = 6 to sudo and the
domain in the sssd.conf. Originally I only had this for sudo so I was
missing part of the puzzle. I also removed the lines as suggested from
the sssd.conf since they are un-necessary. I suspect that may have been
something that was a hold over from the migration process between an old
d389 system using ldap.conf and freeipa.
While I was cleansing the domain logs I could see all the ldap_
directives detected and the defaults if not defined in sssd.conf. Our
setup does not allow anonymous access so a bind user is required to pull
group info. I added the lines below knowing now that the binddn
directive is invalid:
ldap_default_bind_dn =
ldap_default_authtok =
to the sssd.conf for cent6, reloaded sssd and cleared its cache with
sss_cache -E and attempted to sudo and it worked!
After sorting that out I moved on to working with cent5, also adding the
two lines above to its sssd.conf. I can now see in the logs that it
finds the users groups and can match that up in the sudo rules but it is
not finding the host in the host groups to match on the sudo rules. I am
attaching the logs from cent5 to show the issue related here. The host I
am testing on is a member of the host group called "sysops". You can see
in the attached sudo_debug that it does find the sysops sudo rule, and
also sees the host group called sysops assigned to the sudo rule, but it
does not find the host within the group. Note that it prompts for a
password, however the sudo rule does have the option !authenticate on
the sysops sudo rule, so once it can find the host it should no longer
prompt for a password.
I appreciate your taking the time to give insight on this issue. I have
been fighting with this for a few weeks now.
On 11/12/2015 04:34 AM, Pavel Březina wrote:
> On 11/11/2015 03:24 PM, Branden Coates wrote:
>> I have a few issues with sudo rules(FreeIPA 4.1.4-4 on Fedora 22) that I
>> would greatly appreciate some help with. The core of the issue is that
>> sudo rules fail to work when using ldap instead of ipa when you assign
>> user groups and host groups to the sudo rule in place of explicitly
>> adding users and hosts to the sudo rule. The reason for needing to use
>> ldap over ipa is due to the organization requiring 2fa for all users via
>> OTP tokens. We have a mix of cent 5 to 7 systems, not all can be
>> immediately upgraded, so with cent 5 and 6 nodes ldap must be used
>> instead of ipa to support 2fa.
>> Explicitly assigning users and hosts to sudo rules is also unmanageable,
>> the organization has hundreds of employees and multiple thousands of
>> servers. Utilizing the host and user groups is a must.
>>
>> On cent 7 the default sssd.conf generated by FreeIPA works, 2fa works by
>> default and the sssd.conf is using the ipa directives as well to parse
>> user and host groups on sudo rules. Everything here works as expected.
>>
>> In cent 6 to allow 2fa to work the conf has to be updated to use ldap
>> instead of ipa. In the process this seems to break the ability to search
>> user and host groups on sudo rules. Users and hosts explicitly defined
>> for the sudo rules still work so the clients can see the rules, they
>> just do not seem to want to look within the groups that may be assigned
>> to the rules. I moved the original sssd.conf created by FreeIPA using
>> the ipa directives and sudo works as expected, but 2fa is not possible
>> like this.
>>
>> Cent 5 is entirely incapable of using the sudo rules with user and host
>> groups since sudo lacks sssd support in cent 5 and depends on
>> /etc/ldap.conf to work. However like cent 6, users and hosts explicitly
>> defined for the sudo rules still work, so I presume fixing the sudo
>> rules with cent 6 on ldap would fix them here as well.
>>
>> Can anyone else confirm this behavior, and if so can anyone suggest any
>> possible fixes or workarounds? I have attached the modified Cent6 and
>> Cent 5 configs for sssd and ldap inline below(first time mailing, if
>> inline is not ok please let me know what is preferable for future
>
> Hi,
> welcome to the list! I personally prefer receiving it as an
> attachment, since it is more convenient for me to organize and read.
>
>> reference). Currently testing using the following versions:
>> CentOS Linux release 7.1.1503 (Core)
>> CentOS release 6.7 (Final)
>> CentOS release 5.11 (Final)
>>
>> Cent 6 /etc/sssd/sssd.conf:
>>
>> #SSSD client configuration file.
>> [domain/domain]
>> id_provider = ldap
>> auth_provider = ldap
>> chpass_provider = ldap
>> autofs_provider = ldap
>> sudo_provider = ldap
>
>> binddn = <binddn>
>> bindpw = <bindpw>
>> scope = sub
>> sudoers_base = ou=SUDOers,dc=<domain>,dc=com
>> tls_cacertfile = /etc/ipa/ca.crt
>> tls_checkpeer = yes
>> tls_reqcert = demand
>> ssl = start_tls
>
> ^ these are not sssd options thus it should not be in sssd.conf
>
>>
>> ldap_schema = rfc2307bis
>> ldap_uri = _srv_,ldap://<server>.<domain>:389
>> ldap_search_base = dc=<domain>,dc=com
>> ldap_user_search_base = cn=users,cn=accounts,dc=<domain>,dc=com
>> ldap_group_search_base = cn=groups,cn=accounts,dc=<domain>,dc=com
>> ldap_sudo_search_base = ou=SUDOers,dc=<domain>,dc=com
>>
>> enumerate = True
>> cache_credentials = True
>>
>> ldap_tls_cacertdir = /etc/ipa/
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> ldap_tls_reqcert = demand
>> ldap_id_use_start_tls = True
>>
>> krb5_realm = <DOMAIN>
>
> I do not see anything wrong here at first sight. Can you send also
> sssd_sudo.log and sssd_$domain.log please?
>
>>
>> [sssd]
>> services = nss, sudo, pam, ssh, autofs
>> config_file_version = 2
>> domains = domain
>>
>> [nss]
>> homedir_substring = /home
>> filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd
>>
>> [pam]
>>
>> [sudo]
>>
>> [autofs]
>>
>> [ssh]
>>
>> [pac]
>>
>> [ifp]
>>
>>
>> Cent 5 /etc/sssd/sssd.conf:
>>
>> #SSSD client configuration file.
>> [domain/domain]
>> id_provider = ldap
>> auth_provider = ldap
>> chpass_provider = ldap
>> autofs_provider = ldap
>>
>> ldap_schema = rfc2307bis
>> ldap_uri = _srv_,ldap://<server>.<domain>:389
>> ldap_search_base = dc=<domain>,dc=com
>> ldap_user_search_base = cn=users,cn=accounts,dc=<domain>,dc=com
>> ldap_group_search_base = cn=groups,cn=accounts,dc=<domain>,dc=com
>>
>> enumerate = True
>> cache_credentials = True
>>
>> ldap_tls_cacertdir = /etc/ipa/
>> ldap_tls_cacert = /etc/ipa/ca.crt
>> ldap_tls_reqcert = demand
>> ldap_id_use_start_tls = True
>>
>> krb5_realm = <DOMAIN>
>>
>> [sssd]
>> services = nss, pam
>> config_file_version = 2
>> domains = domain
>>
>> [nss]
>> homedir_substring = /home
>> filter_users = root,named,avahi,haldaemon,dbus,radiusd,news,nscd
>>
>> [pam]
>>
>>
>> Cent 5 /etc/ldap.conf:
>>
>> #LDAP client configuration file.
>> uri ldap://<server>.<domain>:389
>> base dc=<domain>,dc=com
>> ldap_version 3
>>
>> tls_cacertfile /etc/ipa/ca.crt
>> tls_checkpeer yes
>> ssl start_tls
>>
>> binddn <binddn>
>> bindpw <bindpw>
>> timelimit 5
>> bind_timelimit 15
>>
>> sudoers_base ou=SUDOers,dc=<domain>,dc=com
>>
>>
>> Thank you
>> Brande
>>
>>
>
-------------- next part --------------
[bcoates at cent5test3 ~]$ sudo su -
LDAP Config Summary
===================
uri ldap://<server>.<domain>,:389
ldap_version 3
sudoers_base ou=SUDOers,dc=<domain>,dc=com
binddn <removed>
bindpw <removed>
bind_timelimit 15000
timelimit 5
ssl start_tls
tls_checkpeer (yes)
tls_cacertfile /etc/ipa/ca.crt
===================
sudo: ldap_initialize(ld, ldap://<server>.<domain>,:389)
sudo: ldap_set_option: debug -> 0
sudo: ldap_set_option: ldap_version -> 3
sudo: ldap_set_option: tls_checkpeer -> 1
sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt
sudo: ldap_set_option: timelimit -> 5
sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 15)
sudo: ldap_start_tls_s() ok
sudo: ldap_sasl_bind_s() ok
sudo: found:cn=defaults,ou=sudoers,dc=<domain>,dc=com
sudo: ldap sudoOption: 'env_keep+=SSH_AUTH_SOCK'
sudo: ldap sudoOption: 'requiretty'
sudo: ldap sudoOption: 'always_set_home'
sudo: ldap search '(|(sudoUser=bcoates)(sudoUser=%bcoates)(sudoUser=%default)(sudoUser=%supervisors)(sudoUser=%sysops)(sudoUser=ALL))'
sudo: found:cn=default,ou=sudoers,dc=<domain>,dc=com
sudo: ldap sudoHost '+backupservers' ... not
sudo: ldap sudoHost '+internalservers' ... not
sudo: found:cn=sysops,ou=sudoers,dc=<domain>,dc=com
sudo: ldap sudoHost '+guardianservers' ... not
sudo: ldap sudoHost '+idm-servers' ... not
sudo: ldap sudoHost '+radius-servers' ... not
sudo: ldap sudoHost '+sysops' ... not
sudo: found:cn=supervisors,ou=sudoers,dc=<domain>,dc=com
sudo: ldap sudoHost '+supervisorservers' ... not
sudo: ldap search 'sudoUser=+*'
sudo: user_matches=1
sudo: host_matches=0
sudo: sudo_ldap_lookup(0)=0x40
[sudo] password for bcoates:
-------------- next part --------------
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [be_get_account_info] (4): Got request for [3][1][name=bcoates]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(uid=bcoates)(objectclass=posixAccount))][cn=users,cn=accounts,dc=<domain>,dc=com].
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_save_user] (6): Storing info for user bcoates
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_initgr_rfc2307bis_send] (6): Looking up parent groups for user [uid=bcoates,cn=users,cn=accounts,dc=<domain>,dc=com]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=uid=bcoates,cn=users,cn=accounts,dc=<domain>,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=<domain>,dc=com].
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [rfc2307bis_nested_groups_step] (6): Processing group [default]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [rfc2307bis_nested_groups_step] (6): Looking up parent groups for group [cn=default,cn=groups,cn=accounts,dc=<domain>,dc=com]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=cn=default,cn=groups,cn=accounts,dc=<domain>,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=<domain>,dc=com].
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [rfc2307bis_nested_groups_step] (6): Processing group [supervisors]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [rfc2307bis_nested_groups_step] (6): Looking up parent groups for group [cn=supervisors,cn=groups,cn=accounts,dc=<domain>,dc=com]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=cn=supervisors,cn=groups,cn=accounts,dc=<domain>,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=<domain>,dc=com].
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [rfc2307bis_nested_groups_step] (6): Processing group [sysops]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [rfc2307bis_nested_groups_step] (6): Looking up parent groups for group [cn=sysops,cn=groups,cn=accounts,dc=<domain>,dc=com]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(member=cn=sysops,cn=groups,cn=accounts,dc=<domain>,dc=com)(objectclass=posixGroup)(cn=*))][cn=groups,cn=accounts,dc=<domain>,dc=com].
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [be_pam_handler] (4): Got request with the following data
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): command: PAM_AUTHENTICATE
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): domain: <domain>
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): user: bcoates
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): service: sudo
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): tty: /dev/pts/1
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): ruser:
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): rhost:
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): authtok type: 1
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): authtok size: 0
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): newauthtok type: 0
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): newauthtok size: 0
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): priv: 0
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [pam_print_data] (4): cli_pid: 21973
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [be_pam_handler_callback] (4): Backend returned: (0, 6, <NULL>) [Success]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [be_pam_handler_callback] (4): Sending result [6][<domain>]
(Thu Nov 12 16:37:31 2015) [sssd[be[<domain>]]] [be_pam_handler_callback] (4): Sent result [6][<domain>]
More information about the Freeipa-users
mailing list