Re: [Freeipa-users] Sudo Rules Help (SOLVED)
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 = 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,
Re: [Freeipa-users] Sudo Rules Help
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 = bindpw = scope = sub sudoers_base = ou=SUDOers,dc=,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://.:389 ldap_search_base =
[Freeipa-users] Sudo Rules Help
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 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 = bindpw = scope = sub sudoers_base = ou=SUDOers,dc=,dc=com tls_cacertfile = /etc/ipa/ca.crt tls_checkpeer = yes tls_reqcert = demand ssl = start_tls ldap_schema = rfc2307bis ldap_uri = _srv_,ldap://.:389 ldap_search_base = dc=,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=,dc=com ldap_sudo_search_base = ou=SUDOers,dc=,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 = [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://.:389 ldap_search_base = dc=,dc=com ldap_user_search_base = cn=users,cn=accounts,dc=,dc=com ldap_group_search_base = cn=groups,cn=accounts,dc=,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 = [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://.:389 base dc=,dc=com ldap_version 3 tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes ssl start_tls binddn bindpw timelimit 5 bind_timelimit 15 sudoers_base ou=SUDOers,dc=,dc=com Thank you Brande -- 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
