here's my sssd.conf .... sudo eventually works, just after a long timeout
[sssd]
config_file_version = 2
services = nss, pam
domains = default
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
override_shell = /bin/bash
override_homedir = /mnt/nfs_home/%u/linux
[pam]
[domain/default]
debug_level = 8
id_provider = ad
auth_provider = ad
access_provider = ldap
chpass_provider = ad
ad_domain = edited
ldap_search_base = edited
ldap_idmap_default_domain = edited
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = edited
ldap_account_expire_policy = ad
ldap_access_order = expire
ldap_schema = ad
ldap_referrals = False
ldap_id_mapping = True
ldap_force_upper_case_realm = True
ldap_user_search_base = edited
ldap_idmap_default_domain_sid = edited
ldap_tls_reqcert = never
case_sensitive = False
krb5_lifetime = 10h
krb5_renewable_lifetime = 7d
krb5_renew_interval = 3600
ldap_account_expire_policy = ad
krb5_realm =
#these will go away with IDMU uid
ldap_idmap_range_size = 20000000
ldap_idmap_range_min = 0
ldap_idmap_range_max = 2000000000
min_id = 500
override_gid = 197250
On 12/19/2013 11:43 AM, Dmitri Pal wrote:
On 12/19/2013 11:20 AM, Chris Petty wrote:
> I am running:
> sssd.x86_64: 1.9.2-82.4.el6_4
>
> On scientific linux 6.4.
>
> I do not have sssd and sudo integration because sudo is not available in
> our AD/ldap provided by the university. I have added a couple
> usernames unto the local sudoers file. I also haven't set any of the
> sudo options in my sssd.conf
>
> I set to use local files only for sudo in nsswitch
> sudoers: files
>
> However, whenever i call sudo as a user authenticated through sssd, sssd
> reaches out and does tons ( at least 54 ) of ldap searches, which return
> empty because sudo does not exist in the ldap, then i can eventually
> enter my password and use sudo.
>
> Here's a section of my sssd log. When this returns that "ldap_result
> found nothing" i can enter my password to proceed with local sudo.
>
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_groups_next_base] (0x0400): Searching for groups with base
> [DC=dhe,DC=duke,DC=edu]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(objectSID=S-edited)(objectclass=group)(name=*))][DC=dhe,DC=duke,DC=edu].
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [name]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [member]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectGUID]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectSID]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [whenChanged]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 54
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: sh[0x21309c0], connected[1], ops[0x2563870],
> ldap[0x265b420]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: sh[0x21309c0], connected[1], ops[0x2563870],
> ldap[0x265b420]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: sh[0x21309c0], connected[1], ops[0x2563870],
> ldap[0x265b420]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: sh[0x21309c0], connected[1], ops[0x2563870],
> ldap[0x265b420]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: sh[0x21309c0], connected[1], ops[0x2563870],
> ldap[0x265b420]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: sh[0x21309c0], connected[1], ops[0x2563870],
> ldap[0x265b420]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]]
> [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no
> errmsg set
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_get_groups_process]
> (0x0400): Search for groups, returned 0 results.
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 0,0,Success
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: sh[0x21309c0], connected[1], ops[(nil)], ldap[0x265b420]
> (Thu Dec 19 11:12:22 2013) [sssd[be[default]]] [sdap_process_result]
> (0x2000): Trace: ldap_result found nothing!
>
>
> How can i prevent these queries and just use the local sudoers files as
> indicated in nsswitch?
>
> thank,
> -Chris
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
I do not think it searches for sudo information. On every login SSSD
refreshes data about user and groups to be able to serve most recent
information about a user.
The volume of the searches is probably related to the resolution of the
nexted groups and group membership which indicates to me that you are
using LDAP back end rather than and AD back end for AD communication.
sssd.conf would be helpful to prove this theory.
If it is try then there are two issues:
a) Many lookups - switch to AD back end for that
b) sudo is not working - does it or you are just concerned about the noise?