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@gmail.com 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/htm... 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@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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

Thanks! This is very interesting!

I was able to use the above settings and this solved my password expiration problem with ldap and IPA.

e.g. [domain/LDAP] id_provider = ldap auth_provider = krb5 chpass_provider = krb5 ldap_schema = IPA krb5_realm = EXAMPLE.NET krb5_server = ipa-1b.ec2.example.net, ipa-1.example.net 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 ldap_user_ssh_public_key = ipaSshPubKey

It is unclear if I need all the above settings since its a mix of ldap and krb5?

Without a keytab validation is not possible, that's not ideal.

So the above does seem to work, but other than its not a full Kerberos setup, what is "not ideal" about the setup?

I am still looking at the sudo options now.

Thanks so much for the suggestions! Very helpful!

On Thu, Aug 28, 2014 at 5:06 PM, Simo Sorce simo@redhat.com wrote:

On Thu, 2014-08-28 at 22:28 +0200, Lukas Slebodnik wrote:

...

...

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

Without a keytab validation is not possible, that's not ideal.

Simo.

-- Simo Sorce * Red Hat, Inc * New York

---

sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

On Fri, 2014-08-29 at 09:00 +0100, John Hodrien wrote:

On Thu, 28 Aug 2014, Simo Sorce wrote:

...

...

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.

Depending on your reason for not joining a machine to the domain, you're free to share a single kerberos lookup credential via a keytab between multiple machines, will still gives you the ability to validate.

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

Simo.

On Fri, 2014-08-29 at 14:54 +0100, John Hodrien wrote:

On Fri, 29 Aug 2014, Simo Sorce wrote:

...

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

If I give you a null/unused.hostname@DOMAIN credential in a keytab, what can you fool?

If you use the same keytab on multiple machines and one machine is compromised (and the keytab stolen) then I can impersonate a fake KDC against the other machines using the same keytab for validation.

That's all.

Simo.