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




[bcoates@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: 

(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>]

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Reply via email to