[Freeipa-users] Sudo Rules Help (SOLVED)

Wed Nov 18 15:35:07 UTC 2015

I was able to track down the issues with Cent 5 and the sudo rules. I do 
not fully understand why, but I assume it has to do with being able to 
determine the hostname from the fqdn. I ended up having to add the 
following line to the /etc/sysctl.conf file:

nkernel.domainname = <domain>

Our domain for freeipa is actually a subdomain so possibly this may have 
had something to do with needing this setting?
After adding that line and running a "sysctl -p" sudo was able to 
identify the servers hostname within the host groups assigned on the 
sudo rule. At this point everything related to sudo I was having issues 
with is sorted out.

Thanks for pointing me in the right direction to sort the problem out. 
It looks like in both instances it was just user error and overlooking a 
few details.

On 11/12/2015 04:57 PM, Branden Coates wrote:
> 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
>>>
>>>
>>
>

-- 
---------------------------------
Branden Coates
Ops Team

Liquid Web, Inc.
support at liquidweb.com
1-800-580-4985 Toll Free
1-517-322-0434 International
---------------------------------