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
