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