On Wed, Aug 16, 2017 at 9:11 AM, Lukas Slebodnik <[email protected]> wrote:
> On (15/08/17 22:16), Louis Garcia wrote: > >On Wed, Aug 2, 2017 at 2:43 PM, Louis Garcia <[email protected]> wrote: > > > >> On Wed, Aug 2, 2017 at 11:42 AM, Jakub Hrozek <[email protected]> > wrote: > >> > >>> On Wed, Aug 02, 2017 at 11:07:08AM -0400, Louis Garcia wrote: > >>> > On Wed, Aug 2, 2017 at 8:54 AM, Jakub Hrozek <[email protected]> > >>> wrote: > >>> > > >>> > > On Wed, Aug 02, 2017 at 02:43:35PM +0200, Jakub Hrozek wrote: > >>> > > > On Wed, Aug 02, 2017 at 09:46:43AM +0200, Lukas Slebodnik wrote: > >>> > > > > On (02/08/17 09:43), Jakub Hrozek wrote: > >>> > > > > >On Tue, Aug 01, 2017 at 04:46:32PM -0400, Louis Garcia wrote: > >>> > > > > >> In fedora 26 where should sssd.conf live? /etc/sssd/ or > >>> > > /etc/sssd/conf.d/ > >>> > > > > >> ?? > >>> > > > > > > >>> > > > > >Ah, in fedora-26, this setup might be a bit more problematic > >>> because > >>> > > > > >sssd by default serves files already. Can you try something > like > >>> this > >>> > > > > >please (untested): > >>> > > > > > > >>> > > > > IMHO it is not more problematic it's simpler :-) > >>> > > > > >>> > > > Yeah, but users who upgrade (or follow my old blog post) get > stuck. > >>> I > >>> > > > can update the blog post, not sure what else can we do about the > >>> > > > existing configurations except for hardcoding id_provider=proxy > and > >>> > > > proxy_lib_name=files. > >>> > > > >>> > > sorry, I meant "hardcoding a check if the user is already running > >>> > > id_provider=proxy with lib_name=files and disabling the implicit > >>> domain, > >>> > > then". Because the user is already running pretty much the same > >>> > > configuration as the files provider, but because the implicit files > >>> are > >>> > > always configured before the explicit domains, this kind of > explicit > >>> > > domain is never reached.. > >>> > > > >>> > > > > >>> > > > > > >>> > > > > >[sssd] > >>> > > > > >services = nss, pam > >>> > > > > ># this was missing in your original config > >>> > > > > >domains = kerberos > >>> > > > > > > >>> > > > > >[nss] > >>> > > > > >filter_groups = root > >>> > > > > >filter_users = root > >>> > > > > > > >>> > > > > >[pam] > >>> > > > > >offline_credentials_expiration = 2 > >>> > > > > >offline_failed_login_attempts = 3 > >>> > > > > >offline_failed_login_delay = 5 > >>> > > > > > > >>> > > > > >[domain/kerberos] > >>> > > > > ># files provider instead of proxy > >>> > > > > >id_provider = files > >>> > > > > > > >>> > > > > >auth_provider = krb5 > >>> > > > > >chpass_provider = krb5 > >>> > > > > >krb5_realm = MONTCLAIRE.LOCAL > >>> > > > > >krb5_server = panther.montclaire.local > >>> > > > > > > >>> > > > > >cache_credentials = True > >>> > > > > >krb5_store_password_if_offline = True > >>> > > > > > >>> > > > > If that configuration does not help then please follow our > >>> > > troubleshooting wiki > >>> > > > > https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html > >>> > > #troubleshooting-authentication-password-change-and-access-control > >>> > > > > > >>> > > > > LS > >>> > > > > _______________________________________________ > >>> > > > > sssd-users mailing list -- [email protected] > >>> > > > > To unsubscribe send an email to [email protected] > >>> > > osted.org > >>> > > > _______________________________________________ > >>> > > > sssd-users mailing list -- [email protected] > >>> > > > To unsubscribe send an email to [email protected] > >>> osted.org > >>> > > _______________________________________________ > >>> > > sssd-users mailing list -- [email protected] > >>> > > To unsubscribe send an email to [email protected] > >>> osted.org > >>> > > > >>> > > >>> > > >>> > Ok I'm still not logged on to my realm but I got new logs. Not sure > if > >>> this > >>> > list accepts attachments but sssd_kerberos.log is quite long. > >>> > >>> It does, but it might be better to gzip the logs so that you don't get > >>> over the attachment limit so easily. > >>> > >>> > In that log i see user: louisgtwo@kerberos which is not right. > >>> > >>> This is just the internal name that sssd uses, not the principal. This > >>> can be ignored. > >>> > >>> > I login to > >>> > my realm as [email protected] > >>> > >>> Well, according to the logs, sssd didn't even receive the > >>> PAM_AUTHENTICATE request. I wonder how exactly is your PAM stack set up > >>> like? > >>> > >>> Also, there are some messages that I wouldn't expect (requests > returning > >>> EINVAL in the file provider, those requests should be just returned > from > >>> the cache..). However, this shouldn't abort the authentication if it > >>> even got to SSSD. > >>> > >>> So, could you please attach also /etc/pam.d/* and also add debug_level > >>> to the nss and pam sections so that we see the PAM stack but also the > >>> requests that triggered the EINVAL return codes? > >>> > >>> Thank you. > >>> > >>> > >>> > > >>> > sssd.conf: > >>> > [sssd] > >>> > services = nss, pam > >>> > domains = kerberos > >>> > > >>> > [nss] > >>> > filter_groups = root > >>> > filter_users = root > >>> > > >>> > [pam] > >>> > offline_credentials_expiration = 2 > >>> > offline_failed_login_attempts = 3 > >>> > offline_failed_login_delay = 5 > >>> > > >>> > [domain/kerberos] > >>> > id_provider = files > >>> > debug_level = 5 > >>> > > >>> > auth_provider = krb5 > >>> > chpass_provider = krb5 > >>> > krb5_realm = MONTCLAIRE.LOCAL > >>> > krb5_server = panther.montclaire.local > >>> > > >>> > cache_credentials = True > >>> > krb5_store_password_if_offline = True > >>> > >>> > >>> > _______________________________________________ > >>> > sssd-users mailing list -- [email protected] > >>> > To unsubscribe send an email to sssd-users-leave@lists. > fedorahosted.org > >>> _______________________________________________ > >>> sssd-users mailing list -- [email protected] > >>> To unsubscribe send an email to sssd-users-leave@lists. > fedorahosted.org > >>> > >> > >> > >> Is this the correct command for fedora 26? > >> #authconfig --enablesssd --enablesssdauth --enablekrb5 --update > >> > >> > >> do I add debug_level or debug_level = 5 to the nss and pam sections of > >> sssd.conf? > >> > >> > >I seem to have not gotten your last email buy this is what I have now. I > am > >still not able to login to my realm and get a ticket. > >log file attached. > > > >[sssd] > > domains = files > > services = nss, pam > > > >[domain/files] > >id_provider = files > >auth_provider = krb5 > > > >krb5_server = panther.montclaire.local > >krb5_realm = MONTCLAIRE.LOCAL > > > >debug_level = 5 > > Hmm, I tested similar configuration and it works for me. > > Could you increase debug_level from 5-> 9 and > also increase ldebug_level in pam section > """ > [pam] > debug_level = 9 > """ > > Then try to reproduce one more time and provide sanitized sssd log files > + related part of journald (equivalent to /var/log/secure with enabled > rsyslog) > > It would be good also provide list of running sssd processed > pgrep -af sssd > > LS > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > #cat /etc/sssd/sssd.conf [sssd] domains = files services = nss, pam [pam] debug_level = 9 [domain/files] id_provider = files auth_provider = krb5 krb5_server = panther.montclaire.local krb5_realm = MONTCLAIRE.LOCAL debug_level = 9 #pgrep -af sssd 670 /usr/sbin/sssd -i -f 678 /usr/libexec/sssd/sssd_be --domain files --uid 0 --gid 0 --debug-to-files 725 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files 726 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files I will try "enable_files_domain = false" next.
sssd_files.log.gz
Description: GNU Zip compressed data
sssd_pam.log.gz
Description: GNU Zip compressed data
system-auth
Description: Binary data
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
