On (15/08/17 22:16), Louis Garcia wrote:
>On Wed, Aug 2, 2017 at 2:43 PM, Louis Garcia <louisgtwo(a)gmail.com> wrote:
>
>> On Wed, Aug 2, 2017 at 11:42 AM, Jakub Hrozek <jhrozek(a)redhat.com> 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
<jhrozek(a)redhat.com>
>>> 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 --
sssd-users(a)lists.fedorahosted.org
>>> > > > > To unsubscribe send an email to
sssd-users-leave(a)lists.fedorah
>>> > >
osted.org
>>> > > > _______________________________________________
>>> > > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>>> > > > To unsubscribe send an email to
sssd-users-leave(a)lists.fedorah
>>>
osted.org
>>> > > _______________________________________________
>>> > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>>> > > To unsubscribe send an email to sssd-users-leave(a)lists.fedorah
>>>
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 louisgtwo(a)MONTCLAIRE.LOCAL
>>>
>>> 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 -- sssd-users(a)lists.fedorahosted.org
>>> > To unsubscribe send an email to
sssd-users-leave(a)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
>>>
>>
>>
>> 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.