sssd-users September 2017

sssd-users@lists.fedorahosted.org

16 participants
23 discussions

Password Caching Issues with AD
by Sam Weston 08 Sep '17

08 Sep '17

We've been using SSSD with our AD domain (please forgive the domain name...) with the following config on Ubuntu 16.04 for a year or so, with no problems at all. Joined to the domain with realmd. [sssd] config_file_version = 2 reconnection_retries = 3 services = nss,pam domains = SMALLBUSINESS.LAN [nss] [pam] [domain/SMALLBUSINESS.LAN] access_provider = ad ad_domain = SMALLBUSINESS.LAN ad_gpo_access_control = permissive cache_credentials = True default_shell = /bin/bash fallback_homedir = /home/%u id_provider = ad krb5_realm = SMALLBUSINESS.LAN krb5_store_password_if_offline = True ldap_id_mapping = True realmd_tags = manages-system joined-with-samba However recently we've had a lot of problems with people being unable to login when not connected to the network. This is with the handful of Ubuntu 17.04 machines I've started to roll out (SSSD 1.15.2 rather than 1.13.4 on 16.04). After spending about a day reading up and trying every configuration under the sun, I've found that the password doesn't appear to be cached on the 17.04 machine. If I run "ldbsearch -H /var/lib/sss/db/cache_SMALLBUSINESS.LAN.ldb "(&(objectClass=user)(cachedPassword=*))" name gidNumber cachedPassword" on my machine I get no results, but I get results on the working 16.04 machine. I'm at my wits' end with this, so any suggestions you've got will be much appreciated! Many Thanks Sam -- *Laminar Data - Secure cloud-based platform for managing, sharing and monetizing aeronautical data* *Learn More <https://laminardata.aero>*

1 1

User Kerberos lifetime ticket.
by Mark London 04 Sep '17

04 Sep '17

Hi - Is it possible to have a Kerberos ticket constantly being renewed as long as a person is still logged in? We want to kerberize our nfs mount points, which hosts the users' home directories. It would, of course, cause a major problem, if the ticket actually expired while the user was still logged in. But maybe I'm not reading the documentation correctly. Thanks. - Mark Sent from my iPhone

6 9

Re: sssd-ad on centos 7
by Michal Židek 01 Sep '17

01 Sep '17

Sorry, I accidentally did not reply to the list, so, for others, see the message below. Michal On 09/01/2017 04:15 PM, Michal Židek wrote: > Hi again! > > See comments inline... > > On 09/01/2017 03:33 PM, William Edsall wrote: >> Had a few communications with Michal but we're still stuck. >> >> One issue is that we have dozens of domain controllers globally. A >> standard dns lookup could give me a domain controller overseas which >> will be slow, or maybe even a domain controller that isn't responding. >> As such, I have been inserting ad_server = x into the sssd.conf to >> improve performance. > > The logs you sent privately to me last time where from an > attempt with manually set ad_server option? It would explain > why the kerberos authentication was broken for the SSSD host > if the server you specified was different then the one > from which you downloaded the keytab entries during realm join. > This is logical, because joining machine to a realm also > involves creating host entry in the AD. This change was > not synchronized with other DCs and thus you were not able > to authenticate against them. > >> >> I noticed that if I do not insert ad_server = x, I'm getting different >> results. My initial id request is very slow but seems to produce >> results. While searching, it seems to also be 'inserting' users into >> the users hash table - almost as if it's searching and inserting our >> entire user database? For example there are countless lines of the >> following: >> (Fri Sep 1 09:28:37 2017) [sssd[be[example.com >> <http://example.com>]]] [sdap_nested_group_hash_insert] (0x4000): >> Inserting [CN=user_name,OU=bla,OU=bla Users,DC=dow,DC=com] into hash >> table [users] >> > > This is OK. In order to get all your nested group IDs, SSSD has to go > through all the members of groups that you are member of. It will not > download all users, just information about the memberships and store > them in local database, but the group needs to be stored complete > (with all memberships). So what you see being stored is the info > about the memberships, not the actual user entry from AD. > >> As my initial id request returns, it seems to return several chunks of >> my group ids at once as if it's processing them individually and >> searching all users in that group (thus the above log entries). > > Sorry I do not understand from the sentence above, if ti returns > all the expected IDs or not, or what is the current problem that > you are facing. > >> >> Not sure if this helps or just muds up the issue but it's strange indeed. >> >> On Thu, Aug 31, 2017 at 10:47 AM, Michal Židek <mzidek(a)redhat.com >> <mailto:mzidek@redhat.com>> wrote: >> >> I have the important part of logs now :) >> >> Looking at the domain logs, this looks like a DNS or networking >> issue. >> Are you sure you can resolve the EXAMPLE.EXAMPLE.COM >> <http://EXAMPLE.EXAMPLE.COM> from the machine >> with SSSD? >> >> (Thu Aug 31 09:16:17 2017) [sssd[be[example.com >> <http://example.com>]]] [fo_resolve_service_done] (0x0020): Failed >> to resolve server 'EXAMPLE.EXAMPLE.COM >> <http://EXAMPLE.EXAMPLE.COM>': Domain name not found >> >> (Thu Aug 31 09:16:17 2017) [sssd[be[example.com >> <http://example.com>]]] [set_server_common_status] (0x0100): Marking >> server 'EXAMPLE.EXAMPLE.COM <http://EXAMPLE.EXAMPLE.COM>' as 'not >> working' >> >> (Thu Aug 31 09:16:17 2017) [sssd[be[example.com >> <http://example.com>]]] [be_resolve_server_process] (0x0080): >> Couldn't resolve server (EXAMPLE.EXAMPLE.COM >> <http://EXAMPLE.EXAMPLE.COM>), resolver returned [11]: Resource >> temporarily unavailable >> >> >> On 08/31/2017 04:38 PM, Michal Židek wrote: >> >> I forgot to say one think. You can sanitize the logs, but please >> sent the whole logs (not just parts) for the sssd_domain and >> sssd_nss logs (maybe you actually did this, but as I said, >> I do not see the mail with the attachment). >> >> Michal >> >> On 08/31/2017 04:31 PM, Michal Židek wrote: >> >> Hi, >> >> I do not see the email where you sent the logs as attachment. >> Maybe it is stuck in moderation (maybe the attachment was >> too big >> or something). I only noticed you sent something thanks to >> your >> last message. Can you please sent the logs directly to me? >> >> If the logs are too big, It will help if you stop sssd, >> delete the logs, start sssd again and redo the test. This >> will keep the logs shorter. >> >> Thanks, >> >> Michal >> >> On 08/31/2017 03:45 PM, William Edsall wrote: >> >> 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 <mailto:wedsall@gmail.com> >> <mailto:wedsall@gmail.com <mailto:wedsall@gmail.com>>> >> wrote: >> >> >> Steps: >> 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 nssd. >> >> 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. >> >> >> [sssd] >> domains = example.com <http://example.com> >> <http://example.com> >> default_domain_suffix = example.com >> <http://example.com> <http://example.com> >> config_file_version = 2 >> services = nss, pam >> >> >> [domain/example.com <http://example.com> >> <http://example.com>] >> debug_level = 9 >> ad_domain = example.com <http://example.com> >> <http://example.com> >> ad_server = EXAMPLE.EXAMPLE.COM >> <http://EXAMPLE.EXAMPLE.COM> <http://EXAMPLE.EXAMPLE.COM> >> krb5_realm = EXAMPLE.COM <http://EXAMPLE.COM> >> <http://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 >> >> >> Logs: >> 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.DataProvider.Offline] >> >> sssd_example.com.log (attached). >> >> On Thu, Aug 31, 2017 at 7:44 AM, Michal Židek >> <mzidek(a)redhat.com <mailto:mzidek@redhat.com> >> <mailto:mzidek@redhat.com >> <mailto:mzidek@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. >> >> Thanks >> William >> >> >> >> Hello, >> >> please provide sssd domain and sssd_nss logs >> with debug_level = 9 >> as well as your SSSD configuration file. >> >> For more details see: >> >> https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html >> >> <https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html> >> >> <https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html >> >> <https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html>> >> >> Michal >> _______________________________________________ >> sssd-users mailing list -- >> sssd-users(a)lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org> >> <mailto:sssd-users@lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org>> >> To unsubscribe send an email to >> sssd-users-leave(a)lists.fedorahosted.org >> <mailto:sssd-users-leave@lists.fedorahosted.org> >> <mailto:sssd-users-leave@lists.fedorahosted.org >> <mailto:sssd-users-leave@lists.fedorahosted.org>> >> >> >> >> >> >> _______________________________________________ >> sssd-users mailing list -- >> sssd-users(a)lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org> >> To unsubscribe send an email to >> sssd-users-leave(a)lists.fedorahosted.org >> <mailto:sssd-users-leave@lists.fedorahosted.org> >> >> _______________________________________________ >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org> >> To unsubscribe send an email to >> sssd-users-leave(a)lists.fedorahosted.org >> <mailto:sssd-users-leave@lists.fedorahosted.org> >> >> _______________________________________________ >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org> >> To unsubscribe send an email to >> sssd-users-leave(a)lists.fedorahosted.org >> <mailto:sssd-users-leave@lists.fedorahosted.org> >> >> _______________________________________________ >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org >> <mailto:sssd-users@lists.fedorahosted.org> >> To unsubscribe send an email to >> sssd-users-leave(a)lists.fedorahosted.org >> <mailto:sssd-users-leave@lists.fedorahosted.org> >> >> >> >> >> _______________________________________________ >> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org >> >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users September 2017