##(see the SpecSpec for an explanation)

 * '''Launchpad Entry''': UbuntuSpec:server-karmic-kerberize-main-servers

== Summary ==

### This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples.

Software in Ubuntu that runs as a server should be audited for Kerberization.

== Release Note ==

### This section should include a paragraph describing the end-user impact of this change.  It is meant to be included in the release notes of the first release in which it is implemented.  (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.)

### It is mandatory.

Common services have been enabled to be easily integrated in a kerberos infrastructure.

== Rationale ==

### This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.

Kerberos is used in major corporate infrastructure to handle authentication. Microsoft Active Directory (and Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008), Apple Mac OSX use Kerberos as their default authentication methods.

Enabling kerberos for common services would facilitate Ubuntu Server integration in existing infrastructure.

== Use Cases ==

 * Miranda installs the mail server task and configures it to use the kerberos infrastructure to authenticate clients.
 * Neal deploys systems in the data center and can log into them via ssh using its kerberos ticket.
 * Olaf runs web applications related to the company intranet. He relies on Kerberos authentication to provide a single-sign-on environment to all employees.

== Design ==

### You can have subsections that better describe specific parts of the issue.

=== Default Kerberos implementation for client libraries ===

There are different implementations of Kerberos available in the repositories:
  * MIT:
   * [[http://packages.ubuntu.com/source/karmic/krb5|Package]] in main.
   * The client library is libkrb53.
  * Heimdal: 
   * [[http://packages.ubuntu.com/source/karmic/heimdal|Package]] in universe.
   * The client library package is libkrb5-22-heimdal.

The current preferred choice is MIT (ie is in main).

Should we switch to Heimdal instead for the client libraries ?

Keep MIT libraries:
  * Pros:
    * Most of the packages in Debian are compiled with MIT libraries.
    * The MIT library is installed by default (because most of the packages are compiled to use it).
  * Cons:
    *

Move Heimdal libs:
  * Pros:
    * in-memory credentials cache, heimdal-kcm, which is useful so users don't have to manually "kinit" periodically from the command line: '''NEEDS TO BE CHECKED'''. 
    * might also ease integration into an identity manager or gnome-keyring, or smartcard support: '''NEEDS TO BE CHECKED'''. 
    * having all-heimdal libraries and purging libkrb53 would allow use of the KCM functionality: '''NEEDS TO BE CHECKED'''. 
    * most of the packages can use Heimdal libs simply by recompiling: '''TO BE TESTED'''.
  * Cons:
    * increase deltas with Debian.
    * heimdal is linked against OpenSSL, which is GPL-incompatible.

The Debian guys have done a good job at allowing interoperability with the krb5-config package and both implementations using the same configs and can share ticket caches.

The runtime libraries for MIT Kerberos and Heimdal can be installed simultaneously and use symbol versioning, so it should be safe to mix the libraries on one system.

=== Authentication Libraries ===

==== SASL ====

There are multiple implementations of SASL libraries:

 * cyrus-sasl - in main.
   * libsasl2-modules-gssapi-mit - in universe.
   * libsasl2-modules-gssapi-heimdal - in universe.
 * dovecot - in main.

List of packages in main that depends on libsasl2-2:

|| Package Name|| Cyrus SASL support || Dovecot SASL ||
|| cyrus-sasl2 || ||
|| exim4 || Yes || [[http://wiki.dovecot.org/HowTo/EximAndDovecotSASL|Yes]] ||
|| kdepimlibs || Yes || ||
|| libnss-ldap || Yes || ||
|| libvirt || Yes || ||
|| mutt || Yes || ||
|| opal || Yes || ||
|| openldap || Yes || ||
|| php5 || Yes || ||
|| pidgin || Yes || ||
|| postfix || Yes || [[http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL|Yes]] ||
|| ptlib || Yes || ||
|| pwlib || Yes || ||
|| python-ldap || Yes || ||
|| subversion || Yes || ||


==== PAM ====
   * libpam-krb5 (MIT Kerberos) - in main.
   * libpam-heimdal - in universe.

=== Services ===

==== in main ====

|| Packages || Currently supported via || Default Service principals name ||
|| openssh || GSSAPI || host/fqdn@REALM ||
|| openldap || SASL || ldap/fqdn@REALM ||
|| samba (as a cifs server) || || cifs/fqdn@REALM host/fqdn@REALM ||
|| postfix || SASL || smtp/fqdn@REALM ||
|| exim4 || SASL || ||
|| dovecot || GSSAPI || imap/fqdn@REALM pop/fqdn@REALM ||
|| cupsys || GSSAPI || IPP/fqdn@REALM ||
|| postgresql || GSSAPI || postgres/fqdn@REALM ||
|| mysql || [[http://bugs.mysql.com/bug.php?id=6733|Not available]] ||
|| apache2 || via mod-auth-krb5|| HTTP/fqdn@REALM HTTP/short_fqdn@REALM ||
|| freeradius || freeradius-krb5 module ||
|| ipsec-tools (racoon) || GSSAPI ||
|| openvpn || ||
|| pptpd || ||
|| vsftpd || ||
|| virt-manager/libvirt || ||

== Implementation ==

### This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

==== Kerberos client libraries ====

Keep libkrb53 in main.

==== SASL ====

Keep Cyrus-Sasl in main. 

 * Move libsasl2-modules-gssapi-mit in main:
   * Write a MIR for it.

==== Services ====

===== setup-krb-service script =====

Provide a CLI to help in service principal creation so that admins don't have to figure out what are the default principal names. Each package that support kerberos will provide a list of service principal names that should be created.

{{{
   $ setup-krb-service package-name
}}}
   
   1. create the service principals (kadmin addprinc).
   1. copy them to the local machine (kadmin ktadd).
   1. configure the service to use kerberos:
      * check configuration (default configuration with krb enabled?)
      * make a test
   1. check if the PTR and A dns entries are set correctly.

Support the case where the user doesn't have necessary privileges.

===== Keytab files =====

As a policy services should look into /etc/krb5/keytab.d/package-name.keytab. Each file should be owned by root which has rw permissions, group owned by the group running the service with r permissions. No world permission. /etc/krb5.keytab is reserved for the host principal. 

Examples:
{{{
/etc/krb5/keytab.d/dovecot.keytab
/etc/krb5/keytab.d/postfix.keytab
/etc/krb5/keytab.d/openldap.keytab
}}}

Rationale: By default most services uses the default /etc/krb5.keytab. Since keytab files contains sensitive information access should be tightly controlled. For example the dovecot process should not have access to the cups service credentials.

===== Pkg integration =====
 * support for setup-krb-service in each package: 
   * provide a list of default principal names.
   * script to configure the service to use kerberos.
 * setup-krb-service during postinstall time: if the host is already kerberized, setup the service to run with kerberos enabled (ex: via debconf key?).

===== List of targeted packages/tasks =====
 * openssh task (openssh)
 * mail server task (postfix+dovecot)
 * print server task (cupsys)
 * samba (as a cifs server)
 * openldap

===== Document how to enable kerberos in the Ubuntu Server Guide =====

=== Migration ===

### Include:
###  * data migration, if any
###  * redirects from old URLs to new ones, if any
###  * how users will be pointed to the new way of doing things, if necessary.

Look into pam-krb5-migrate and may be move it into main.

=== Test Plan ===

### It's important that we are able to test new features, and demonstrate them to users.  Use this section to describe a short plan that anybody can follow that demonstrates the feature is working.  This can then be used during testing, and to show off after release.

The testing plan covers testing each application in a kerberos environment:
  1. an AD environment.
  2. an MIT environment.

### This need not be added or completed until the specification is nearing beta.

== Outstanding Issues ==

### This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

== Links and References ==
 * [[UbuntuDownUnder/BOFs/KerberizingUbuntu|KerberizingUbuntu]] spec from UbuntuDownUnder
 * KerberizingUbuntu

== BoF agenda and discussion ==

### Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

----
CategorySpec