sshd fails to do GSSAPI authentication when use_fully_qualified_names is true. Can reliably reproduce. Will dig out more issues.
I guess this is expected, because the default auth_to_local mapping (strip realm part of the Kerberos principal and use what remains as user name) does not work in this case. You can do the following to help libkrb5 to get the mapping right: - use .k5login file in the user's home directory - add suitable auth_to_local rules to /etc/krb5.conf (please note that this is case-sensitive) - configure sssd_krb5_localauth_plugin in /etc/krb5.conf and let SSSD do the mapping (there is an issue in sshd which still requires that .k5login exits which reminds me to file a ticket for this) HTH bye, Sumit
sssd-1.12.1-2 Joined to an AD domain with 'realm join domain.com' sssd.conf: [sssd] domains = borg.lan config_file_version = 2 services = nss, pam [domain/borg.lan] ad_domain = borg.lan krb5_realm = BORG.LAN realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad sshd_config KerberosAuthentication yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes GSSAPIStrictAcceptorCheck no
... Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: KEX done [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: userauth-request for user Fry service ssh-connection method none [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: attempt 0 failures 0 [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: PAM: initializing for "Fry" Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: PAM: setting PAM_RHOST to "192.168.11.5" Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: PAM: setting PAM_TTY to "ssh" Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: userauth-request for user Fry service ssh-connection method gssapi-with-mic [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: attempt 1 failures 0 [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: Postponed gssapi-with-mic for Fry from 192.168.11.5 port 34559 ssh2 [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: Received some client credentials Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: Failed gssapi-with-mic for Fry from 192.168.11.5 port 34559 ssh2 Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: userauth-request for user Fry service ssh-connection method gssapi-with-mic [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: attempt 2 failures 1 [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: userauth-request for user Fry service ssh-connection method gssapi-with-mic [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: attempt 3 failures 1 [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: userauth-request for user Fry service ssh-connection method gssapi-with-mic [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: debug1: attempt 4 failures 1 [preauth] Sep 23 21:32:58 jalisco.borg.lan sshd[29182]: Connection closed by 192.168.11.5 [preauth] ...
As Sumit noted, work around is adding this to krb5.conf [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so enable_only = sssd }
Fix is to add this snippet by default to /var/lib/sss/pubconf/ Fix requires sssd-1.12.1 or later.
Stef, given that you changed the summary to enabling the localauth plugin by default (which is something we, the Fedora developers should do in F-21 anyway), do you still consider this bugzilla to be an SSSD bug? Or were you going to change the component to whoever is setting up krb5.conf ?
IMO, we should make the plugin loaded by default when installed, the same way the locator and pac plugins are loaded by default. Would that cause problems? Can we do that with the following krb5.conf snippet? [plugins] localauth = { module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so } Now the question is where to put that snippet. We should have some sort of /usr/share/krb5.d directory where we can put stuff like this. That directory would be included in the default krb5.conf.
(In reply to Stef Walter from comment #7) > IMO, we should make the plugin loaded by default when installed, the same > way the locator and pac plugins are loaded by default. Would that cause > problems? > Right, I think that's a good idea. To the best of my knowledge, the only known problem is what Sumit described wrt .k5login files earlier and I don't think that can cause problems, it's just something to fix in OpenSSH or document for the time being. > Can we do that with the following krb5.conf snippet? > > [plugins] > localauth = { > module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so > } > Sounds about right (although I haven't tested that yet). > Now the question is where to put that snippet. We should have some sort of > /usr/share/krb5.d directory where we can put stuff like this. That directory > would be included in the default krb5.conf. If the included file was to be purely static and installed by sssd, then yes. If the file was to be autogenerated (although I don't see why) then /var/ would be more appropriate. Roland, do you agree? If so, can you create a Fedora bugzilla to add this directory and the include file in krb5?
(In reply to Jakub Hrozek from comment #8) > (In reply to Stef Walter from comment #7) > > Now the question is where to put that snippet. We should have some sort of > > /usr/share/krb5.d directory where we can put stuff like this. That directory > > would be included in the default krb5.conf. > > If the included file was to be purely static and installed by sssd, then > yes. If the file was to be autogenerated (although I don't see why) then > /var/ would be more appropriate. Yes, static, installed by the same rpm that owns /usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so > Roland, do you agree? If so, can you create a Fedora bugzilla to add this > directory and the include file in krb5? Just to be clear, this would be an include *directory*. While we're at it, should we create /etc/krb5.d directory as well and includedir it and /usr/share/krb5.d in krb5.conf by default?
(In reply to Stef Walter from comment #9) > > Roland, do you agree? If so, can you create a Fedora bugzilla to add this > > directory and the include file in krb5? > > Just to be clear, this would be an include *directory*. > Sorry, typo. You're right of course. > While we're at it, should we create /etc/krb5.d directory as well and > includedir it and /usr/share/krb5.d in krb5.conf by default? I guess this is more of a question for Roland, but what would be purpose of /etc/krb5.d/ ? A place where the system admin can drop snippets (as opposed to factory-distributed snippets in /usr/share/krb5.d) ?
(In reply to Jakub Hrozek from comment #10) > (In reply to Stef Walter from comment #9) > > > Roland, do you agree? If so, can you create a Fedora bugzilla to add this > > > directory and the include file in krb5? > > > > Just to be clear, this would be an include *directory*. > > > > Sorry, typo. You're right of course. > > > While we're at it, should we create /etc/krb5.d directory as well and > > includedir it and /usr/share/krb5.d in krb5.conf by default? > > I guess this is more of a question for Roland, but what would be purpose of > /etc/krb5.d/ ? A place where the system admin can drop snippets (as opposed > to factory-distributed snippets in /usr/share/krb5.d) ? Yes, and for realmd ... when that becomes necessary. No concrete use case yet. Actually, I would like to avoid configuring kerberos from within realmd, and make the defaults work, along with the help that sssd gives with it's includedir. So I don't mind if we skip /etc/krb5.d for now. I only suggested it for completeness. But as a general rule programatically changing monolithic configuration files is a pain. We should migrate to snippet directories wherever programaticly built configuration files are necessary.
(In reply to Stef Walter from comment #11) > (In reply to Jakub Hrozek from comment #10) > > (In reply to Stef Walter from comment #9) > > > > Roland, do you agree? If so, can you create a Fedora bugzilla to add this > > > > directory and the include file in krb5? > > > > > > Just to be clear, this would be an include *directory*. > > > > > > > Sorry, typo. You're right of course. > > > > > While we're at it, should we create /etc/krb5.d directory as well and > > > includedir it and /usr/share/krb5.d in krb5.conf by default? > > > > I guess this is more of a question for Roland, but what would be purpose of > > /etc/krb5.d/ ? A place where the system admin can drop snippets (as opposed > > to factory-distributed snippets in /usr/share/krb5.d) ? > > Yes, and for realmd ... when that becomes necessary. No concrete use case > yet. > > Actually, I would like to avoid configuring kerberos from within realmd, and > make the defaults work, along with the help that sssd gives with it's > includedir. > > So I don't mind if we skip /etc/krb5.d for now. I only suggested it for > completeness. Erm... I like that idea... please file a separate bug for *both* /usr/share/krb5.d/ and /etc/krb5.d/ (BTW: Shouldn't this be /usr/share/krb5.conf.d/ and /etc/krb5.conf.d/) ... ... for example /usr/share/krb5.d/ could contain the factory defaults like these two ones: -- snip -- $ cat /usr/share/krb5.d/K0001rhel_factory_defaults_logging.conf [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log $ cat /usr/share/krb5.d/K0006rhel_factory_defaults_use_keyring.conf [libdefaults] default_ccache_name = KEYRING:persistent:%{uid} -- snip -- ... so please file the RFE and assign it to me...
(In reply to Roland Mainz from comment #12) > (In reply to Stef Walter from comment #11) > > (In reply to Jakub Hrozek from comment #10) > > > (In reply to Stef Walter from comment #9) > > > > > Roland, do you agree? If so, can you create a Fedora bugzilla to add this > > > > > directory and the include file in krb5? > > > > > > > > Just to be clear, this would be an include *directory*. > > > > > > > > > > Sorry, typo. You're right of course. > > > > > > > While we're at it, should we create /etc/krb5.d directory as well and > > > > includedir it and /usr/share/krb5.d in krb5.conf by default? > > > > > > I guess this is more of a question for Roland, but what would be purpose of > > > /etc/krb5.d/ ? A place where the system admin can drop snippets (as opposed > > > to factory-distributed snippets in /usr/share/krb5.d) ? > > > > Yes, and for realmd ... when that becomes necessary. No concrete use case > > yet. > > > > Actually, I would like to avoid configuring kerberos from within realmd, and > > make the defaults work, along with the help that sssd gives with it's > > includedir. > > > > So I don't mind if we skip /etc/krb5.d for now. I only suggested it for > > completeness. > > Erm... I like that idea... please file a separate bug for *both* > /usr/share/krb5.d/ and /etc/krb5.d/ (BTW: Shouldn't this be > /usr/share/krb5.conf.d/ and /etc/krb5.conf.d/) ... > Yep, that's a better name > ... for example /usr/share/krb5.d/ could contain the factory defaults like > these two ones: > -- snip -- > $ cat /usr/share/krb5.d/K0001rhel_factory_defaults_logging.conf > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > $ cat /usr/share/krb5.d/K0006rhel_factory_defaults_use_keyring.conf > [libdefaults] > default_ccache_name = KEYRING:persistent:%{uid} > -- snip -- > > ... so please file the RFE and assign it to me... Done: https://bugzilla.redhat.com/show_bug.cgi?id=1146370 The krb5 bugzilla now also blocks this one.
Upstream ticket: https://fedorahosted.org/sssd/ticket/2449
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
It was moved to fedora 22 because krb5 in fedora 21 does not have directory /etc/krb5.conf.d/
There is no plan to include /etc/krb5.conf.d/ by default on fedora 22. It's only possible to do it on fedora 23+.
Upstream has shipped the localauth plugin enabled for some time now, what is left there to work on with Fedora?
localauth plugin is stored to directory /var/lib/sss/pubconf/krb5.include.d/ by default with sssd. However, this directory is not included in krb5.conf by default. And Simo had some objections to store or write files into /etc/krb5.conf.d/ IIRC ipa-client-install ammend krb5.conf and include /var/lib/sss/pubconf/krb5.include.d/. But it would not work for AD provider .
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.