Hello, Thanks in advance for any assistance. This is a long post - apologizes. I have a bit of an odd setup with IPA ipa-server-3.0.0-37.el6.x86_64 and sssd-1.9.2-129.el6_5.4.x86_64 CentOS 6.5. My goal is to get sudo work using IPA as a source. I setup the IPA server as normal. Since we are using this in a cloud environment (ec2) with hosts that may come and go quickly, we decided not to connect clients using the ipa-client code. Instead we have user auth working with SSSD as an LDAP provider. ( I know this complicates all things IPA). e.g: sssd.conf /etc/sssd/sssd.conf [domain/LDAP] enumerate = true cache_credentials = True debug_level = 8 id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_schema = IPA ldap_uri = ldaps://ipa-1b.ec2.example.net, ldaps://ipa-1.example.net ldap_user_search_base = dc=example,dc=net ldap_id_use_start_tls = true tls_reqcert = demand ldap_tls_cacert = /etc/ipa/ca.crt # Setting to correctly query public SSH keys from IPA server ldap_user_ssh_public_key = ipaSshPubKey [sssd] services = nss, pam, ssh config_file_version = 2 domains = LDAP So far this is working fine, with a minor issue around password expiration (a known issue). NOTE: The IPA server does not keep a list of hosts since we are not using the ipa-client / kerberos setup. At this point I am trying to get IPA working as a sudo provider. After reading through: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/... and https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf I attempted to get sssd to use IPA as a sudo provider, I added the following to sssd.conf: [domain/LDAP] sudo_provider = ldap ldap_sudo_search_base = ou=sudoers,dc=example,dc=net [sssd] services = nss, pam, ssh, sudo and /etc/nsswitch.conf sudoers: files sss The setup did not resolve any rules, and I saw this in the logs: (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_sudo_init] (0x2000): Initializing sudo LDAP back end (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [ldap_get_sudo_options] (0x0400): Search base not set, trying to discover it later connecting to the LDAP server. (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [common_parse_search_base] (0x0100): Search base added: [SUDO][ou=sudoers,dc=example,dc=net][SUBTREE][] (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_object_class has value sudoRole (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_name has value cn (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_command has value sudoCommand (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_host has value sudoHost (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_user has value sudoUser (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_option has value sudoOption (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_runasuser has value sudoRunAsUser (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_runasgroup has value sudoRunAsGroup (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_notbefore has value sudoNotBefore (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_notafter has value sudoNotAfter (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_order has value sudoOrder (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): Option ldap_sudorule_entry_usn has no value (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_sudo_get_ip_addresses] (0x2000): Found IP address: 10.0.1.105 in network 10.0.1.0/24 (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_sudo_get_ip_addresses] (0x2000): Found IP address: fe80::5054:ff:fe7b:abae in network fe80::/64 (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_sudo_get_hostnames_send] (0x2000): Found fqdn: lreed-sssd02.example.net (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_sudo_get_hostnames_send] (0x2000): Found hostname: lreed-sssd02 (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1409237202 (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [ou=sudoers,dc=example,dc=net] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=lreed-sssd02.example.net)(sudoHost=lreed-sssd02)(sudoHost=10.0.1.105)(sudoHost=10.0.1.0/24)(sudoHost=fe80::5054:ff:fe7b:abae)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))][ou=sudoers,dc=example,dc=net]. (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with base [ou=sudoers,dc=example,dc=net] (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sysdb_sudo_purge_byfilter] (0x0400): No rules matched (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_load_sudoers_done] (0x0400): Sudoers is successfuly stored in cache (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_full_refresh_done] (0x0400): Successful full refresh of sudo rules (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1409258802 (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] [sdap_sudo_schedule_refresh] (0x0400): Smart refresh scheduled at: 1409238102 It seems “ Received 0 rules” means that IPA is note sending the full LDAP entries with sudo rules. I confirmed this by doing an ldap search using an authenticated user and could see them. I have since setup sudo-ldap.conf with an authenticated user. This seems to be working, however it seems a bit kludgy (I admit my entire setup is kludgy). Question #1 is that since this is going through sudo-ldap, sssd is not caching any of these rules. Is there a way to make sssd call sudo-ldap instead of setting it in nsswitch.conf: sudoers: files ldap vs sudoers: files sss ? It does not look like it but I may have something wrong. Question #2 is around hostname and sudo rules. Since we don’t have the hostnames in IPA by default, I can’t easily (AFAIK) add them to sudo rules. I can do rules for “ANY HOST” or I can add “external hosts” With file based sudo rules it is possible to use “wildcard” characters” for example with hostname to do “*-dev” and control rules thusly. The IPA web GUI does not seem to allow such rules. If I have to add each hostname this will become a possible show stopper. Thanks very much for any ideas on these problems. _______________________________________________ sssd-users mailing list sssd-users(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Thanks Rowland, that's interesting. Did you make that change on the AD side?

I suppose I could open up an ACI on the IPA server.

Not sure that is the route I want to go down as I don't understand the details or potential risks.

At this point I think I can live with the sudo-ldap.conf needing a sudo user and password. Its the limited sudo rules for all or nothing hosts that is my biggest hurdle. Thanks! On Thu, Aug 28, 2014 at 11:29 AM, Rowland Penny <repenny241155(a)gmail.com&gt; wrote: > On 28/08/14 16:04, Lance Reed wrote: >> Hello, >> >> Thanks in advance for any assistance. >> This is a long post - apologizes. >> I have a bit of an odd setup with IPA ipa-server-3.0.0-37.el6.x86_64 >> and sssd-1.9.2-129.el6_5.4.x86_64 CentOS 6.5. >> My goal is to get sudo work using IPA as a source. >> >> I setup the IPA server as normal. >> Since we are using this in a cloud environment (ec2) with hosts that >> may come and go quickly, we decided not to connect clients using the >> ipa-client code. >> Instead we have user auth working with SSSD as an LDAP provider. ( I >> know this complicates all things IPA). >> >> e.g: sssd.conf >> /etc/sssd/sssd.conf >> [domain/LDAP] >> enumerate = true >> cache_credentials = True >> debug_level = 8 >> >> id_provider = ldap >> auth_provider = ldap >> chpass_provider = ldap >> ldap_schema = IPA >> ldap_uri = ldaps://ipa-1b.ec2.example.net, ldaps://ipa-1.example.net >> ldap_user_search_base = dc=example,dc=net >> ldap_id_use_start_tls = true >> tls_reqcert = demand >> ldap_tls_cacert = /etc/ipa/ca.crt >> >> # Setting to correctly query public SSH keys from IPA server >> ldap_user_ssh_public_key = ipaSshPubKey >> >> [sssd] >> services = nss, pam, ssh >> config_file_version = 2 >> domains = LDAP >> >> >> So far this is working fine, with a minor issue around password >> expiration (a known issue). >> NOTE: The IPA server does not keep a list of hosts since we are not >> using the ipa-client / kerberos setup. >> >> At this point I am trying to get IPA working as a sudo provider. >> >> After reading through: >> >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/... >> and >> https://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> >> I attempted to get sssd to use IPA as a sudo provider, >> >> I added the following to sssd.conf: >> [domain/LDAP] >> sudo_provider = ldap >> ldap_sudo_search_base = ou=sudoers,dc=example,dc=net >> >> [sssd] >> services = nss, pam, ssh, sudo >> >> >> and >> /etc/nsswitch.conf >> sudoers: files sss >> >> >> The setup did not resolve any rules, and I saw this in the logs: >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_sudo_init] (0x2000): >> Initializing sudo LDAP back end >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [ldap_get_sudo_options] >> (0x0400): Search base not set, trying to discover it later connecting >> to the LDAP server. >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [common_parse_search_base] >> (0x0100): Search base added: >> [SUDO][ou=sudoers,dc=example,dc=net][SUBTREE][] >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_object_class has value sudoRole >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_name has value cn >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_command has value sudoCommand >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_host has value sudoHost >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_user has value sudoUser >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_option has value sudoOption >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_runasuser has value sudoRunAsUser >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_runasgroup has value sudoRunAsGroup >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_notbefore has value sudoNotBefore >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_notafter has value sudoNotAfter >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_order has value sudoOrder >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] [sdap_get_map] (0x0400): >> Option ldap_sudorule_entry_usn has no value >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] >> [sdap_sudo_get_ip_addresses] (0x2000): Found IP address: 10.0.1.105 in >> network 10.0.1.0/24 >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] >> [sdap_sudo_get_ip_addresses] (0x2000): Found IP address: >> fe80::5054:ff:fe7b:abae in network fe80::/64 >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] >> [sdap_sudo_get_hostnames_send] (0x2000): Found fqdn: >> lreed-sssd02.example.net >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] >> [sdap_sudo_get_hostnames_send] (0x2000): Found hostname: lreed-sssd02 >> (Thu Aug 28 10:46:32 2014) [sssd[be[LDAP]]] >> [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: >> 1409237202 >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo >> rules >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection >> successful >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules >> with base [ou=sudoers,dc=example,dc=net] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with >> >> [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=lreed-sssd02.example.net)(sudoHost=lreed-sssd02)(sudoHost=10.0.1.105)(sudoHost=10.0.1.0/24)(sudoHost=fe80::5054:ff:fe7b:abae)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\\*)(sudoHost=*?*)(sudoHost=*\**)(sudoHost=*[*]*))))][ou=sudoers,dc=example,dc=net]. >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: >> [sudoRunAsUser] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: >> [sudoRunAsGroup] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: >> [sudoNotBefore] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_load_sudoers_process] (0x0400): Receiving sudo rules with >> base [ou=sudoers,dc=example,dc=net] >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_load_sudoers_done] (0x0400): Received 0 rules >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sysdb_sudo_purge_byfilter] (0x0400): No rules matched >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_load_sudoers_done] (0x0400): Sudoers is successfuly stored >> in cache >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_full_refresh_done] (0x0400): Successful full refresh of >> sudo rules >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: >> 1409258802 >> (Thu Aug 28 10:46:42 2014) [sssd[be[LDAP]]] >> [sdap_sudo_schedule_refresh] (0x0400): Smart refresh scheduled at: >> 1409238102 >> >> It seems “ Received 0 rules” means that IPA is note sending the full >> LDAP entries with sudo rules. >> I confirmed this by doing an ldap search using an authenticated user >> and could see them. >> >> I have since setup sudo-ldap.conf with an authenticated user. >> This seems to be working, however it seems a bit kludgy (I admit my >> entire setup is kludgy). >> >> Question #1 is that since this is going through sudo-ldap, sssd is not >> caching any of these rules. >> Is there a way to make sssd call sudo-ldap instead of setting it in >> nsswitch.conf: sudoers: files ldap vs sudoers: files sss ? >> It does not look like it but I may have something wrong. >> >> Question #2 is around hostname and sudo rules. >> >> Since we don’t have the hostnames in IPA by default, I can’t easily >> (AFAIK) add them to sudo rules. >> I can do rules for “ANY HOST” or I can add “external hosts” >> With file based sudo rules it is possible to use “wildcard” >> characters” for example with hostname to do “*-dev” and control rules >> thusly. >> The IPA web GUI does not seem to allow such rules. >> If I have to add each hostname this will become a possible show stopper. >> >> >> Thanks very much for any ideas on these problems. >> _______________________________________________ >> sssd-users mailing list >> sssd-users(a)lists.fedorahosted.org >> https://lists.fedorahosted.org/mailman/listinfo/sssd-users > Hi, this seems very similar to the problem I had with sssd, sudo and Samba4 > AD, sssd could read the ou but couldn't read any of the rules, turned out to > be a permissions problem on the ou. I set the dsacl on the ou to allow > inheritance and sssd and sudo burst into life. > > Rowland > _______________________________________________ > sssd-users mailing list > sssd-users(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users(a)lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

>So far this is working fine, with a minor issue around password >expiration (a known issue). >NOTE: The IPA server does not keep a list of hosts since we are not >using the ipa-client / kerberos setup. 1. you needn't register machine with ipa-client install (obtain keytab) if you want to use auth_provider krb5 and chpass_provider krb5 e.g. auth_provider = krb5 chpass_provider = krb5 krb5_realm = IPA.EXAMPLE.TEST krb5_server = ipa-host.ipa.example.test

> auth_provider = krb5 > chpass_provider = krb5 > krb5_realm = IPA.EXAMPLE.TEST > krb5_server = ipa-host.ipa.example.test Without a keytab validation is not possible, that's not ideal.

Although if one of the machines is compromised, now you can fool the others, still better than no validation at all.