Please change the dependency to support Heimdal GSSAPI module

apport information

That seems reasonable.

Any particular reason you prefer the Heimdal implementation, btw? I've never really noticed much difference for the PAM modules.

Well I guess your comment regarding similarity between the MIT and Heimdal GSSAPI module implementations is spot on. They seem to work identically. But for utils I prefer heimdal-clients over krb5-user. Of course there's nothing preventing one from using the MIT GSSAPI module and Heimdal clients, but somehow I just find it more convenient by going with the all-Heimdal client approach, I guess :) And since it's technically possible, why not facilitate that by the packages posing dependency on a GSSAPI module implementation.

Note from upstream: Heimdal support is spotty at best. We have some contributed patches that enable support for most features of Heimdal, but they are untested by upstream.

We strongly recommend using MIT kerberos with SSSD at this time. If you choose to switch to Heimdal, you will be required to maintain it yourself.

On Tue, Mar 27, 2012 at 12:57:38PM -0000, Stephen Gallagher wrote:
> Note from upstream: Heimdal support is spotty at best. We have some
> contributed patches that enable support for most features of Heimdal,
> but they are untested by upstream.
>
> We strongly recommend using MIT kerberos with SSSD at this time. If you
> choose to switch to Heimdal, you will be required to maintain it
> yourself.
What do you mean by "will be required to maintain it yourself"? Upstream doesn't
accept bug reports for the use of sssd against Heimdal?

(Note that this bug report is just about allowing both GSSAPI PAM
modules, not about the use of a specific KDC or userland)

Cheers,

Jelmer

Sorry, my previous comment was unclear.

There is no formal support for Heimdal in the upstream SSSD. We have accepted some submissions in the past that make it possible for the SSSD services to operate with the Heimdal client libraries, but they are known to function in a degraded mode (some advanced features are not available). We don't support it because the primary developers of SSSD are all using Fedora and RHEL systems which do not ship Heimdal (with the exception of an embedded version in Samba) because it is in conflict with MIT Kerberos (they share some well-known files).

What I meant about supporting it yourself is this: there is no upstream testing effort done on Heimdal and no readily-available infrastructure for us to test issues found with it. We'll accept patches to fix issues, but we don't make any guarantees about suitability of SSSD's use with Heimdal.

In short, if you want better-tested support, we strongly advise the use of MIT Kerberos where SSSD is concerned.

One side-effect of using the Heimdal GSSAPI library would be that I don't think it would have access to our Kerberos Locator plugin, so it isn't guaranteed to be contacting the same Kerberos server in a failover scenario as SSSD logins are.

Yes this change would not change the way sssd is built on Ubuntu or against which Kerberos implementation the binaries/libraries are linked against. It would just allow usage of the Heimdal GSSAPI module which is load at runtime if GSSAPI is enabled. With the way the dependecies are currently declared, it's impossible to have both sssd and libsasl2-modules-gssapi-heimdal package installed at the same time.

On a related note, I don't understand why this change was implemented in 1.8.1-1 at all..

* Move libsasl2-modules-gssapi to sssd Depends to make sure it gets
    installed, as it's needed in most cases.

You can use sssd just fine without Kerberos so I think this dependency should be Recommends. And by default, Ubuntu APT configuration pulls all Recommends dependencies also. Quoting http://www.debian.org/doc/debian-policy/ch-relationships.html :

Recommends

    This declares a strong, but not absolute, dependency.

    The Recommends field should list packages that would be found together with this one in all but unusual installations.

Or maybe even Suggests...

Suggests

    This is used to declare that one package may be more useful with one or more others. Using this field tells the packaging system and the user that the listed packages are related to this one and can perhaps enhance its usefulness, but that installing this one without them is perfectly reasonable.

Added the heimdal as an option, committed in git. Also lowered the dependency as Recommends.

This bug was fixed in the package sssd - 1.8.2-0ubuntu1

---------------
sssd (1.8.2-0ubuntu1) precise; urgency=low

  * Merge from Debian git, remaining changes:
    - control, rules: Drop libsemanage-dev from build-depends, it's not
      in main and will not be for precise. Configure --with-semanage=no.

sssd (1.8.2-1) UNRELEASED; urgency=low

  * New upstream bugfix release 1.8.2.
    - Several fixes to case-insensitive domain functions
    - Fix for GSSAPI binds when the keytab contains unrelated
      principals
    - Fixed several segfaults
    - Workarounds added for LDAP servers with unreadable RootDSE
    - SSH knownhostproxy will no longer enter an infinite loop
      preventing login
    - The provided SYSV init script now starts SSSD earlier at startup
      and stops it later during shutdown
    - Assorted minor fixes for issues discovered by static analysis
      tools
  * control: Move the dependency of libsasl2-modules-gssapi-mit to
    Recommends.
  * control: sssd works with Heimdal gssapi modules too, add
    libsasl2-modules-gssapi-mit as an option for the Recommends.
    (LP: #966146)
  * libpam-sss.pam-auth-update: Drop the dependency to 128, since pam_sss
    should always be below pam_unix. (LP: #957486)
  * sssd.postrm: Try to remove /etc/sssd only if it exists.
    (Closes: #666226)
 -- Timo Aaltonen <email address hidden> Wed, 11 Apr 2012 11:48:56 +0300