[SSSD-users] sssd and sudo ldap problems with IPA.

Lukas Slebodnik lslebodn at redhat.com
Thu Aug 28 20:28:18 UTC 2014


On (28/08/14 11: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.
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

>
>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/html-single/Identity_Management_Guide/#config-sudo-clients
>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.
Yes, rules are not cached.

>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.
You needn't  use sudo-ldap.

By default, it is not possible to receive sudo rules with anonymous bind.
But sssd can bind as any user. (the same thing you did with sudo-ldap)

# details are in manula page sssd-ldap
ldap_default_bind_dn = cn=Privileged user
ldap_default_authtok_type = password
ldap_default_authtok = secretpassword


It isn't secure to have password in cleartext, but you can use utility
sss_obfuscate from package sssd-tools to convert passwort into human-unreadable
format.

LS


More information about the sssd-users mailing list