Further testing I think user1 may have been cached all along. I was not
clearing cache while sssd was stopped.
After stopping, clearing, starting - id user1 hangs. I then add ad_server
and debug_level to sssd.conf and restart it. I can now id user1 but I
believe it's coming from cache.
On Thu, Aug 31, 2017 at 9:28 AM, William Edsall <wedsall(a)gmail.com> wrote:
left realm, joined realm as user1, added debug_level and ad_server to
sssd.conf (it seems to hang when it runs into a dead ad_server), restarted
I ran an id on user1, it returned data. No data for user2.
I then cleared cache using: sss_cache -E, id'ed user1 again and data was
returned. Still no data for user2.
domains = example.com
default_domain_suffix = example.com
config_file_version = 2
services = nss, pam
debug_level = 9
ad_domain = example.com
ad_server = EXAMPLE.EXAMPLE.COM
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = ad
sssd_nss is ~700 of the following lines:
(Thu Aug 31 09:21:05 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The
Data Provider returned an error [org.freedesktop.sssd.Error.
On Thu, Aug 31, 2017 at 7:44 AM, Michal Židek <mzidek(a)redhat.com> wrote:
> On 08/30/2017 09:49 PM, William Edsall wrote:
>> Hello list,
>> I've configured sssd on Centos 7 with the very basics. I'm able to id
>> my own user account, which was used to join the domain (via realm), but
>> unable to id any other account.
>> Does anything make sense about this? I should mention this is a very
>> large (50,000+) corporate AD.
> please provide sssd domain and sssd_nss logs with debug_level = 9
> as well as your SSSD configuration file.
> For more details see:
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org