On Tue, Aug 12, 2014 at 03:30:02PM +0300, Alexander Bokovoy wrote:
On Mon, 28 Jul 2014, Simo Sorce wrote:
>On Tue, 2014-07-22 at 14:55 +0200, Sumit Bose wrote:
>>Hi,
>>
>>these two patches implement the MIT Kerberos localauth plugin for SSSD.
>>Since it uses the new plugin style
>>(http://k5wiki.kerberos.org/wiki/Projects/Plugin_support_improvements)
>>it has to be activated explicitly. A section like
>>
>>[plugins]
>> localauth = {
>> module = sssd:/path/to/plugin/sssd_krb5_localauth_plugin.so
>> enable_only = sssd
>> }
>>
>>Should work. Please note that this example deactivates any other
>>mechanism, e.g. .k5login files. See krb5.conf man page of MIT Kerberos
>>1.12 how to active the mechanism as well.
>>
>>One of the main use cases for this plugin is an IPA environment with
>>trust to AD. Currently AD user who want to use SSO with IPA client needed
>>a .k5login file in their home directory containing their Kerberos
>>principal. Alternatively krb5.conf has to be edited but here the names
>>user at the login prompt has to follow a fixed format and are case
>>sensitive. If the localauth plugin is activated the mapping of Kerberos
>>principal and user name is done by SSSD.
>>
>>While I was testing the plugin with ssh I found that st least the Fedora
>>and RHEL versions of the sshd do not rely completely in the Kerberos
>>libraries here but do some checks on their own, especially they check
>>for the existence of the .k5login file in the default configuration.
>>This check can be disabled by setting KerberosUseKuserok to 'no' but
>>then sshd does not call krb5_userok() but the more restrictive
>>krb5_aname_to_localname() and does case sensitive checks on the related
>>names which won't help much in out case. As a result a .k5login file is
>>still needed when testing with ssh but it can be empty or contain random
>>content. I will investigate why OpenSSH is patched in this way on Fedora
>>and RHEL.
>
>The patches look good to me, quite simple and direct.
>It would be nice to avoid the sshd annoying restrictions in RHEL/Fedora
>indeed, and possibly elsewhere.
>
>
>Idea: Can we add a distributors.README file where we start listing all
>the common issues we find in packages and warn distributors to patches
>they may want to adopt in related packages that we asked Fedora/RHEL
>maintainers to add/backport ?
It is a good idea overall for both SSSD and FreeIPA to carry a list of
such dependencies/fixes. We get regularly questions about backports of a
newer code and answering them would be better with a structured list.
I don't object to the idea of the list, but as with any such list, how
do you maintain it and ensure it's not obsolete?