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 sssd-users-leave@lists.
> fedorahosted.org
> > > _______________________________________________
> > > sssd-users mailing list -- [email protected]
> > > To unsubscribe send an email to sssd-users-leave@lists.
> fedorahosted.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 [email protected]
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>


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?
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to