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

Rowland Penny repenny241155 at gmail.com
Thu Aug 28 20:21:23 UTC 2014


On 28/08/14 20:16, Lance Reed wrote:
> Thanks Rowland, that's interesting.
>
> Did you make that change on the AD side?
Yes, the sudoers OU in AD has an hidden attribute 'nTSecurityDescriptor' 
this sets who can access the OU and how. Never having used IPA (to me 
this is a very nice beer: Indian Pale Ale ;-) ) I 'think' that would the 
same as 'access to' in LDAP. I had to change how Domain Computers 
connected to the OU, in this case by adding the inheritance flag.


> I suppose I could open up an ACI on the IPA server.
Again haven't a clue what ACI means.

> Not sure that is the route I want to go down as I don't understand the
> details or potential risks.
If you do have the same problem as I did, you need to find out how to 
allow whoever sssd connects as, to read the contents of the OU.

Rowland
>
>
>
> 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
> _______________________________________________
> 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