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

Lance Reed reed.r.lance at gmail.com
Thu Aug 28 19:16:00 UTC 2014


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 at 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/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.
>> 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 at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users


More information about the sssd-users mailing list