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
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