On Wed, Aug 16, 2017 at 10:03:54AM +0200, Lukas Slebodnik 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 [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? > >> > >> > >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 > > I can see just just open session for this domain > zgrep pam_print_data sssd_files.log.gz > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > command: SSS_PAM_OPEN_SESSION > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > domain: files > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): user: > gdm@files > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > service: systemd-user > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): tty: > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > ruser: > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > rhost: > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > authtok type: 0 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): priv: > 1 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > cli_pid: 907 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): logon > name: not set > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > command: SSS_PAM_OPEN_SESSION > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > domain: files > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): user: > gdm@files > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > service: gdm-launch-environment > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): tty: > /dev/tty1 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > ruser: > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > rhost: > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > authtok type: 0 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): priv: > 0 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > cli_pid: 895 > (Tue Aug 15 22:04:40 2017) [sssd[be[files]]] [pam_print_data] (0x0100): logon > name: not set > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > command: SSS_PAM_OPEN_SESSION > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > domain: files > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): user: > louisgtwo@files > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > service: systemd-user > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): tty: > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > ruser: > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > rhost: > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > authtok type: 0 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): priv: > 1 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > cli_pid: 1397 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): logon > name: not set > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > command: SSS_PAM_OPEN_SESSION > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > domain: files > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): user: > louisgtwo@files > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > service: gdm-password > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): tty: > /dev/tty2 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > ruser: > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > rhost: > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > authtok type: 0 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): priv: > 0 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): > cli_pid: 1389 > (Tue Aug 15 22:05:07 2017) [sssd[be[files]]] [pam_print_data] (0x0100): logon > name: not set > > > I assume you hit the same case as in > https://bugzilla.redhat.com/show_bug.cgi?id=1429843 > https://pagure.io/SSSD/sssd/issue/3341 > > We could confirm that based on sssd_pam.log. > Authentication try to hit 1st domain due to user match and failed because > authentication is not supported with implicit_files domain. > > I think that temporary workaround should be to disable implicit files domain > > Put "enable_files_domain = false" into "sssd" section in /etc/sssd/sssd.conf
If this helps, then we have a bug in SSSD, because the implicit domain should not be started if you add an explicit files domain. _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
