On 07/18/2014 11:53 AM, Rowland Penny wrote:
On 18/07/14 16:18, Jakub Hrozek wrote:
On Thu, Jul 10, 2014 at 11:20:10AM +0100, Rowland Penny wrote:
Any suggest to what I check next??
Sorry for the delayed reply.
Looks like an ACI problem to me, the first search binds as NETBOOK$@EXAMPLE.COM, the second as cn=Administrator,cn=Users,dc=example,dc=com _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
ER, could you please expand 'ACI' for me, I haven't a clue what you are talking about ;-)
Access Control Instructions in LDAP on the server side. In one case the account has privileges to get information and in other it does not. You need to change permission on the server for the SSSD account to have permission to do the search.
As for the part that I did understand, from what I have read, the first search is what sssd does and does not get any results, but by searching as the Administrator( and I suppose as any user) all the rules are found.
I have since tried again on a Linux Mint 17 (aka Ubuntu 14.04) laptop with the standard sssd packages and I still cannot get sudo to work, sssd seems to check for sudo rules but does not find any:
if I examine sssd_example.com.log, I find this:
[sdap_sudo_refresh_connect_done] (0x0400): SUDO LDAP connection successful [sdap_sudo_load_sudoers_next_base] (0x0400): Searching for sudo rules with base [ou=sudoers,dc=example,dc=com] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=sudoRole)(|(!(sudoHost=*))(sudoHost=ALL)(sudoHost=ThinkPad)(sudoHost=ThinkPad.example.com)(sudoHost=192.168.0.215)(sudoHost=192.168.0.0/24)(sudoHost=fe80::86a6:c8ff:fe3b:da7b)(sudoHost=fe80::/64)(sudoHost=+*)(|(sudoHost=*\*)(sudoHost=*?*)(sudoHost=***)(sudoHost=*[*]*))))][ou=sudoers,dc=example,dc=com].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoCommand] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoHost] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoUser] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOption] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsUser] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoRunAsGroup] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6 [sdap_id_op_connect_done] (0x4000): caching successful connection after 2 notifies [be_run_unconditional_online_cb] (0x4000): List of unconditional online callbacks is empty, nothing to do.
would you like the entire sssd logs for the domain ?
I would like to add that sssd works for users and groups, so it it connecting to AD, it just doesn't seem to want to find any sudo rules.
I also take it that sssd & sudo work like this:
sudo rules are put into AD, sssd searches AD and pulls any rules that are relevant to the client, sssd then stores these rules in a cache, when the sudo command is run it first reads the sudo files on the client and then (provided it is set in nssswitch.conf) it reads the cache.
Rowland _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users