Colors of Noise

Entries tagged "single-sign-on".

Kerberos authentication on the Librem 5
25th October 2022

The Librem 5 features a built-in smartcard reader. While most people use it for gpg I wanted to see if it can be used as an authenticator for services like email (SMTP, IMAP), access to web pages (HTTPS), calendars, etc without either having to retype a password often or having to store it on the device itself: single sign on for all my frequently used services.

Librem 5's smart card reader

For that one can leverage a feature called PKINIT of Kerberos (a network authentication protocol meant to allow secure communication over a non-secure network) which uses public key cryptography for initial user authentication (instead of a password). If the key material is saved on the smart card even a lost device can hardly be abused as the smart card is protected by a PIN and will lock itself after three incorrect tries (and you can easily revoke the certificate server side too).

On the service side one can use SASL/GSSAPI to make services like exim, postfix, dovecot, cyrus imapd, apache, nginx or prosodi use Kerberos to authenticate users and there's many more (like CalDAV servers, etc). The most prominent missing bit for me is currently the Synapse matrix server not supporting GSSAPI yet.

I won't go into the details of setting up the Kerberos server (KDC) or PKINIT itself or how to configure services as this is already done elsewhwere (1, 2) but rather focus on the Librem 5 and smart card side.

So for the following let's assume you have a Kerberos realm called MS20.NIX set up and your KDC has the DNS name kdc.ms20.nix, and your Kerberos principal (your user in the Kerberos database) is called foo@MS20.NIX. You also have an smtp and imap servers called smtp.ms20.nix and imap.ms20.nix set up to autenticate users via Kerberos. Finally we call the CA that signs all your certificates ca.pem (were're following the naming from 2).

What follows looks as if lots of things need to be done on the command line. I'll show a simplification at the very end but wanted those bits written down for reference/debugging. Note that this post is not meant as an exhaustive introduction but more like a quick summary of commands. I'm happy if someone grabs it and adds more details.

Kerberos Setup on the Librem 5

Let's first install the Kerberos client side packages on the phone and test that:

$ sudo apt install heimdal-clienets

The krb5-config package will ask for your Kerberos realm, KDC etc. With that in place you should be able to test if you can get a Kerberos ticket via

$ kinit

and entering your password.

If that worked the klist output will look something like:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: foo@MS20.NIX

Issued                Expires               Principal
Oct 24 12:55:13 2022  Oct 25 12:55:13 2022  krbtgt/MS20.NIX@MS20.NIX

Now that basic authentication worked We're ready to switch to certificates stored them on the smart card. Let's drop the credentials first:

$ kdestroy

Smartcard Setup

I have used an OpenPGP card smartcard and inserted that into the Librem 5. In my case it was salvaged from a Librem Key. As PKINIT uses OpenSC the OpenSC wiki was very helpful as it has details on how to get key material onto that particular card.

The software to use the Librem 5's smart card reader is enabled by default as part of the librem5-base package. You just need to add opensc to the mix:

$ sudo apt install opensc

With that you should already be able to see the card:

$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             L5 built-in SmartCard Reader 00 01 00 00
1    Yes             L5 built-in SmartCard Reader 00 01 00 01

As there's only a single reader and the second entry can confuse opensc let's ignore that one:

$ cat <<EOF > /etc/opensc/opensc.conf
app default {
    ignored_readers = "TTXS serial 00 01 00 01","L5 built-in SmartCard Reader 00 01 00 01"

Which should make the output look like

$ opensc-tool -l
# Detected readers (pcsc)
Nr.  Card  Features  Name
0    Yes             L5 built-in SmartCard Reader 00 01 00 00

With the reader up and running we can now store the certificate and private key on it. For simplicity we create these on the KDC and transfer them to the phone (a more realistic setup would create those locally and use a certificate signing request so the private key never leaves your hands):

On the KDC:

$ hxtool issue-certificate --ca-certificate=FILE:krbca.pem --generate-key=rsa --key-bits=2048 --type="pkinit-client" --pk-init-principal="foo@MS20.NIX" --subject="uid=foo,DC=ms20,DC=nix" --certificate="FILE:user.pem"

Then you'd copy the file to your phone and install certificate and private key on the smartcard like (this will delete any already existing keys on the card):

$ # Install needed packages
$ sudo apt install opensc wipe
$ # Delete old keys and install certificate and private key on smartcard
$ pkcs15-init --delete-objects privkey,pubkey,cert --id 1 --auth-id 3
$ pkcs15-init --delete-objects privkey,pubkey,cert --id 2 --auth-id 3
$ pkcs15-init --delete-objects privkey,pubkey,cert --id 3 --store-private-key user.pem  --store-certificate user.pem --id 3 --auth-id 3
$ # Wipe the file containing the private key
$ wipe user.pem

Afterward we can look at what's on the card

$ pkcs15-tool -D
Using reader with a card: L5 built-in SmartCard Reader 00 01 00 00
PKCS#15 Card [OpenPGP card]:
  Version        : 0
  Serial number  : <serial number>
  Manufacturer ID: ZeitControl
  Language       : de
  Flags          : PRN generation, EID compliant

PIN [User PIN]
  Object Flags   : [0x03], private, modifiable
  Auth ID        : 03
  ID             : 02
  Flags          : [0x13], case-sensitive, local, initialized
  Length         : min_len:6, max_len:64, stored_len:64
  Pad char       : 0x00
  Reference      : 2 (0x02)
  Type           : UTF-8
  Path           : 3f00
  Tries left     : 3

PIN [User PIN (sig)]
  Object Flags   : [0x03], private, modifiable
  Auth ID        : 03
  ID             : 01
  Flags          : [0x13], case-sensitive, local, initialized
  Length         : min_len:6, max_len:64, stored_len:64
  Pad char       : 0x00
  Reference      : 1 (0x01)
  Type           : UTF-8
  Path           : 3f00
  Tries left     : 3

PIN [Admin PIN]
  Object Flags   : [0x03], private, modifiable
  ID             : 03
  Flags          : [0x9B], case-sensitive, local, unblock-disabled, initialized, soPin
  Length         : min_len:8, max_len:64, stored_len:64
  Pad char       : 0x00
  Reference      : 3 (0x03)
  Type           : UTF-8
  Path           : 3f00
  Tries left     : 3

Private RSA Key [Authentication key]
  Object Flags   : [0x03], private, modifiable
  Usage          : [0x222], decrypt, unwrap, nonRepudiation
  Access Flags   : [0x1D], sensitive, alwaysSensitive, neverExtract, local
  Algo_refs      : 0
  ModLength      : 2048
  Key ref        : 2 (0x02)
  Native         : yes
  Auth ID        : 02
  ID             : 03
  MD:guid        : 135c302c-ddad-1a3c-f558-8beae7612f9f

Public RSA Key [Authentication key]
  Object Flags   : [0x02], modifiable
  Usage          : [0x51], encrypt, wrap, verify
  Access Flags   : [0x02], extract
  ModLength      : 2048
  Key ref        : 0 (0x00)
  Native         : no
  Path           : a401
  ID             : 03

X.509 Certificate [Cardholder certificate]
  Object Flags   : [0x00]
  Authority      : no
  Path           : 3f007f21
  ID             : 03
  Encoded serial : <serial>

The OpenPGP card's default admin PIN is 12345678 and the user pin 123456.


Now add

pkinit_anchors = FILE:/etc/ssl/certs/ca.pem

to your /etc/krb5.conf and place the ca.pem in /etc/ssl/certs. With that you should be able to use pkinit. The -C option tells kinit to use your smart card for the crypto:

$ kinit -C PKCS11:/usr/lib/aarch64-linux-gnu/pkcs11/ foo@MS20.NET
PIN code for L5 built-in SmartCard Reader 00 01 00 00:

After entering the pin and typing klist the output should be similar to the klist output above. If you connect to various Kerberized services in your realm (e.g. by sending mail) the list will grow without having to retype any PINs or passwords:

$ klist
Credentials cache: FILE:/tmp/krb5cc_1000
        Principal: foo@ms20.nix

  Issued                Expires               Principal
Oct 24 12:55:13 2022  Oct 25 12:55:13 2022  krbtgt/MS20.NIX@MS20.NIX
Oct 24 12:55:57 2022  Oct 25 12:55:13 2022  imap/imap.ms20.nix@
Oct 24 12:57:45 2022  Oct 25 12:55:13 2022  smtp/smtp.ms20.nix@
Oct 24 13:00:32 2022  Oct 25 12:55:13 2022  HTTP/http.ms20.nix@

Can we make this simpler?

The above is very command line heavy and thus hard to use on a phone. With krb5-auth-dialog things become easier to set up. There's no need to adjust /etc//krb5.conf or to copy any certificates. PKINIT via smartcard is being enabled by a single click and you can select your CA (KDC trust anchor) via UI too:

PKINIT setup PIN dialog

There's a graphical dialog to enter your PIN that can either be started via the menu or triggered via a simple DBus call:

 $ gdbus call -e -d org.gnome.KrbAuthDialog -o /org/gnome/KrbAuthDialog -m org.gnome.KrbAuthDialog.acquireTgt ''

and the good part is that it won't prompt you if you already have a valid ticket. So you can e.g. add this as a hook to your offlineimap config.

As far as I know there's no end user friendly tool to transfer the certificates to the smartcard yet but note that this doesn't even have to happen on the phone itself. You can provision those elsewhere and then add the card to the phone but it might make sense to add that functionality to either krb5-auth-dialog or seahorse.

I hope this post motivates people to try this out and to leverage Kerberos for authenticating to services via the Librem 5's built-in smartcard reader.


Tags: gnome, librem5, phosh, single-sign-on.
krb5-auth-dialog: Simple AFS plugin
9th July 2010

I've just added a simple afs plugin to krb5-auth-dialog. It just calls either aklog or afslog after acquiring or renewing your Kerberos ticket to get you into your AFS cell. To activate it use

gconftool-2 --set --list-type=string --type=list /apps/krb5-auth-dialog/plugins/enabled [afs]

and restart krb5-auth-dialog. A package with the above enabled has been uploaded to Debian. Thanks to the test account in the cell provided by Jörg Herzinger I could test this easily and I have to say that AFS looks like a cool thing.

Tags: debian, gnome, single-sign-on.
krb5-auth-dialog: DBUS signals and plugins
3rd May 2010

Krb5-auth-dialog now sends DBus signals when you acquire or renew your Kerberos ticket granting ticket and when the ticket expires. When using OpenAFS This can e.g. be used to trigger a call to aklog on ticket renewal. It's simple to catch the DBus signals from a Python script:

import dbus
bus = dbus.SessionBus()
bus.add_signal_receiver(tgt_renewed_handler, dbus_interface = "org.gnome.KrbAuthDialog", signal_name = "krb_tgt_renewed")
bus.add_signal_receiver(tgt_acquired_handler, dbus_interface = "org.gnome.KrbAuthDialog", signal_name = "krb_tgt_acquired")
bus.add_signal_receiver(tgt_expired_handler, dbus_interface = "org.gnome.KrbAuthDialog", signal_name = "krb_tgt_expired")

The tgt_*_handler will then be called when the signal is received. The shipped Python example allows to execute a script already: -q --acquired-action=aklog --renewed-action=aklog

Krb5-auth-dialog also got a plugin system so you could use a loadable module for these kind of things instead. It already ships a PAM plugin that can be used to run some typical actions like calling pam-afs-session or getting kx509 set up.

You need to tell krb5-auth-dialog which plugins to load via gconf. To load the dummy and PAM plugins use:

gconftool-2 --set --list-type=string --type=list /apps/krb5-auth-dialog/plugins/enabled [pam,dummy]

Since I'm not using AFS or kx509 myself I'd be interested to know if this works out as expected.

If you want to write your one plugins you can use the dummy plugin as a basis.

A package with the above enabled has been uploaded to Debian experimental.

Tags: debian, gnome, single-sign-on.
Negotiate support for libsoup
30th November 2009

I've finally added basic Negotiate (Kerberos) support to libsoup. Git is available here. Using:

git clone;a=summary
# for nautilus:
killall gvfsd
LD_LIBRARY_PATH=libsoup/.libs/ gvfsd
# epiphany:
LD_LIBRARY_PATH=libsoup/.libs/ epiphany
# totem:
LD_LIBRARY_PATH=libsoup/.libs/ totem

you can protect your music, files, whatever on a webserver using mod_auth_kerb and access them without storing a passwort just using your Kerberos ticket. Would be nice to get this merged #587145.

Tags: gnome, single-sign-on.
krb5-auth-dialog 0.13
29th September 2009

Besides quiet some bug fixes krb5-auth-dialog 0.13 now features a ticket dialog that lists your current tickets.

Tags: gnome, single-sign-on.
offlineimap and krb5-auth-dialog
15th June 2009

It turns out patching offlineimap to use it with krb5-auth-dialog's DBUS interface is not necessary. You can simply use:

import dbus
import sys

bus = dbus.SessionBus()
ka = bus.get_object('org.gnome.KrbAuthDialog',
ret = ka.acquireTgt("", dbus_interface='org.gnome.KrbAuthDialog')
if not ret:
    print >>sys.stderr, "Cannot acuire TGT, aborting."
    sys.exit (0)

as ~/.acquiretgt and add:


to ~/.offlineimaprc. This way on each offlineimap invocation it'll check for a valid TGT and invoke krb5-auth-dialog via DBus if none is found. Oh, and version 0.11 has also been released.

Tags: single-sign-on.
krb5-auth-dialog: preferences dialog
9th April 2009

krb5-auth-dialog now has a preferences dialog that (among other things) allows you to set ticket flags like renewable or forwardable. An updated Debian package has already been uploaded.

Tags: single-sign-on.
krb5-auth-dialog: dbus interface
1st March 2009

The simple DBus interface has finally landed in GNOME's SVN. This allows your application to acquire a Kerberos Ticket Granting Ticket via a simple DBus call to krb5-auth-dialog:

    dbus-send --print-reply --type=method_call \
           --dest=org.gnome.KrbAuthDialog \
           /org/gnome/KrbAuthDialog \
           org.gnome.KrbAuthDialog.acquireTgt \

If there's a valid TGT already available the call will simply return, otherwise it'll spawn the dialog to prompt for the password.

There are patches for offlineimap and virt-manager to use this interface and a new krb5-auth-dialog has already been uploaded to Debian's unstable distribution.

Tags: single-sign-on.
krb5-auth-dialog 0.8
15th January 2009

I finally merged the krb5-auth-dialog patches discussed here into it's gnome svn home and we released 0.8.

Only the DBus interface is still missing since I'd like to rework this first. Other things on the TODO list are a config dialog and a dialog to see all current tickets in the cache.

There are packages available for Debian and Fedora already.

Tags: single-sign-on.
Kerberos and SAP on Linux
15th January 2009

The details on howto add GSSAPI/Kerberos to your Linux SAP server are nicely explained here (German). The only annoyance is that one has to hand edit the sources for the SNC adaptor. Therefore I've pushed an already patched tree (as desribed in the above document) here:

git clone

To build the source simply do a:

cd sncadapt 

And to "install" the resulting shared object copy to the location you specified for snc/gssapi_lib, e.g.:

cp /usr/local/lib64/

The document also assumes you're using AD, so creating the principal for the server and extracting it's keytab takes several steps. If you're using e.g. Heimdal you can simply do a:

ktutil -k sapsrv.keytab get SAPService/

and copy the resulting file from your KDC to your server.

Tags: single-sign-on.
Enabling Kerberos in the SAP GUI for Java
10th January 2009

Enabling Kerberos in the sapgui for Java on Linux:

There's another nice description at

Tags: single-sign-on.
krb5-auth-dialog: new icon
18th October 2008

Since it should be obvious at a glance when the ticket is about to expire I added a third icon:

expiring ticket

It gets shown together with the first notification, which is tunable via the /apps/krb5-auth-dialog/prompt_minutes gconf key:

gconftool-2 --type=int --set /apps/krb5-auth-dialog/prompt_minutes 30

The code landed on the pkinit branch so the build instructions stay the same. I also added a gconf schema to ease configuration and fixed a possible segfault on startup.

Tags: single-sign-on.
krb5-auth-dialog pkinit support
19th September 2008

I finally got around to hack pkinit support into krb5-auth-dialog. It's available on the pkinit branch in git:

git clone
git-checkout --track  -b  pkinit origin/pkinit mkdir build && cd build
../ --enable-pkinit && make && make install

In order to build it, you need Heimdal 1.1 or newer. The freshly built krb5-auth-dialog will work as before until you set:

gconftool-2 --type=string --set /apps/krb5-auth-dialog/pk_userid "PKCS11:/usr/lib/opensc/"

This tells krb5-auth-dialog to look for the principal's public/private/certificate identifier on a smartcard that is handled via opensc (like kinit's "-C" option). From now on krb5-auth-dialog will ask for the smart cards' PIN instead of the principals password:

pin entry

Note: when using pkcs11 there's currently a bug in Heimdal that causes all applications to crash when you enter an incorrect PIN. The bugreport has a patch for Heimdal 1.2 to fix this attached.

Tags: single-sign-on.
PKINIT: Kerberos v5 with Smart Cards
22nd June 2008

Using Kerberos for single sign on is a nice thing but one feels uncomfortable that only a password grants access to all services. One can use smart cards and public key cryptography to achieve Two factor authenticaton which makes things considerably safer. In Kerberos terms this is called pkinit. To get there, several steps are necessary:

  1. Creating the PKI
  2. Setting up the KDC
  3. Setting up the user part
  4. Putting things on the smart card

The step below assume you already have a working Heimdal Kerberos setup in a realm named MS20.NIX and are using Debian.

Creating the PKI

If you don't already have certificates hxtool is the simplest thing to create them:

Create the Certificate Authority (CA):

$ hxtool issue-certificate --self-signed --issue-ca --generate-key=rsa --subject="CN=CA,DC=ms20,DC=nix" --lifetime=10years --certificate="FILE:ca.pem"

Create the KDCs certificate:

$ hxtool issue-certificate --ca-certificate=FILE:ca.pem --generate-key=rsa --type="pkinit-kdc" --pk-init-principal="krbtgt/MS20.NIX@MS20.NIX" --subject="uid=kdc,DC=ms20,DC=nix" --certificate="FILE:kdc.pem"

Create the Certificate for a User agx@MS20.NIX:

$ hxtool issue-certificate --ca-certificate=FILE:ca.pem --generate-key=rsa --type="pkinit-client" --pk-init-principal="agx@MS20.NIX" --subject="uid=agx,DC=ms20,DC=nix" --certificate="FILE:user.pem"

In the above setup, hxtool puts the certificate and the private key into one file, so extract the lines between:


from ca.pem, store it away in ca.key ant put it at a save location, remove these lines from ca.pem then. Don't put ca.key on the KDC - you only need it to create new certificates. The resulting ca.pem is the save to copy around.

Note: unfortunately hxtool is currently missing from the heimdal-clients Debian package. You can aplly the patch from #487119 and rebuild the package.

Setting up the KDC

You need to enable pkinit in /etc/heimdal-kdc/kdc.conf and tell the KDC where to find it's own identity (pkinit_identity) as well as the trust anchors (pkinit_anchors). For simplicity we use our new CA as the only trust anchor so only certificates signed by this ca are valid for the KDC:

enable-pkinit = yes
pkinit_identity = FILE:/etc/heimdal-kdc/pkinit/kdc.pem
pkinit_anchors = FILE:/etc/heimdal-kdc/pkinit/ca.pem
# don't allow proxy certificates
pkinit_allow_proxy_certificate = false
pkinit_win2k_require_binding = yes

Copy ca.pem and kdc.pem to the above locations. Make sure kdc.pem is only readable by root since it contains a private key.

Setting up the user part

The client needs to know about our CA too since it needs to identify the KDC. This is setup in /etc/krb5.conf:

pkinit_anchors = FILE:/etc/ssl/certs/ca.pem

Copy ca.pem to the above location. Also copy user.pem to ~ and split out the private key part into a separate file user.key (the steps are the same as explained for the CA above). You can the test your installation with:

 $ cd ~
 $ kinit -C FILE:user.pem,user.key agx@MS20.NIX
 $ klist

 Credentials cache: FILE:/tmp/krb5cc_0
    Principal: agx@MS20.NIX

   Issued           Expires          Principal
 Jun 20 14:52:27  Jun 21 00:52:27  krbtgt/MS20.NIX@MS20.NIX

Putting things onto the smart card:

First Install opensc and make sure your smart card is recognized:

 $ opensc-tool -n
 CardOS M4 

I used an empty Aladdin eToken Pro which I wiped completely before adding the keys:

 $ pkcs15-init -E
 $ pkcs15-init -C -p pkcs15+onepin
 $ pkcs15-init --store-private-key user.key --auth-id 01 
 $ pkcs15-init --store-certificate user.pem --auth-id 01 
 # Lets see if it worked:
 $ kinit -C PKCS11:/usr/lib/opensc/ agx@MS20.NIX

 Credentials cache: FILE:/tmp/krb5cc_0
    Principal: agx@MS20.NIX

   Issued           Expires          Principal
 Jun 20 14:52:27  Jun 21 00:52:27  krbtgt/MS20.NIX@MS20.NIX

That's it. The steps above are quiet terse but this should get you started. Libpam-krb5 has pkinit support so you can use this during logon.

Tags: single-sign-on.
Apple Calendarser with Name Service Switch directory backend
22nd June 2008

Apple's Calendarserver uses a file based XML backend by default. This has the disadvantage that new users must be added manually and groups can't be maintained dynamically - the calendarserver needs to be restarted.

Therefore we added a simple Name Service Switch based directory service to the Debian packages - it's best to use 1.2.dfsg-4 or newer. Using this, all users known to the system via getent passwd can have calendars and group calendars can be maintained as simple groups of users. Where your system gets it's user and group information from can be configured via /etc/nsswitch.conf e.g.:

 passwd: files ldap
 group:  files ldap

looks up users and groups in /etc/{passwd,groups} and using ldap via libnss-ldap. For more details use man nsswitch.conf. All of this can be configured dynamically without the need to restart calendarserver.

Calendarserver Configuration

To enable the NSS backend in calendarserver comment out the XML File Directory Service via <!-- ... --> in /etc/caldavd/caldavd.plist then add the NSS one. This example has all the parameters you can set:

<!-- NSS directory service -->
    <string>Your Realm</string>

    <!-- Don't treat user ids smaller than firstValidUid as calendarserver users -->
    <!-- Don't treat user ids larger than lastValidUid as calendarserver users -->

    <!-- Groups starting with this prefix are considered calendarserver groups -->

    <!-- Don't treat group ids smaller than firstValidGid as calendarserver groups -->
    <!-- Don't treat group ids larger than lastValidGid as calendarserver groups -->
    <!-- use username@mailDomain as calender user mail addresses -->

The firstValidUid and lastValidUid parameters allow you to specify which users have calendars. By default uids in the range [1000,65533] are being used. This way system users like lp, mail, news backup and nobody are excluded.

Shared calendars are represented by groups of users. The group name must start with groupPrefix to avoid collisions with system users - the default is caldavd-. The members of these groups are allowed to read/write the calendar. The firstValidGid, lastValidGid have the same meaning as the uid ones above but since you already specified a prefix you normally can simply omit them.

The mailDomain parameter can be used to specify a default mail domain. In the exmaple above a user foo ends up with mail address of - this information is used by some clients for free busy lists and invitations.

The values above - except for the realmName and mailDomain - are the defaults build into calendarserver, so if these suite your needs you can simply skip them:

<!-- NSS directory service -->


After changing this don't forget to restart calendarserver using /etc/init.d/calendarserver restart.

Adding users and groups

Using the configuration above all users in the range [firstValidUid,lastValidUid] readily have a calendar to access at:


Adding a new user is now as easy as adduser <newuser>. The calendar get's created once the user tries to access his calendar for the first time. To add a shared calendar at:


simply do a addgroup caldavd-test. Then simply add users to this group: adduser test <user>. To see which users can access this particular shared calendar you can use:

getent group caldav-test

and to see all shared calendars use:

getent group | grep ^caldavd-

To see which calendars a user can access look at the output of id.

Note that {add,del}{user,group} manipluate users and groups in /etc/passwd and /etc/group only. If you're using other name service switch backends like ldap or postgresql you can use the corresponding tools instead.


User authentication currently only works using Kerberos. This is the recommended form of authentication anyways. Let me know if you have problems setting this up.

Tags: groupware, single-sign-on.
Howto wipe an Aladdin eToken you forgot the PIN for
20th June 2008

Mostly since I always forgot how to do this (this solution requires MS Windows):

Once done pkcs15-init from opensc works as expected.

Tags: single-sign-on.
krb5-auth-dialog: experimental dbus interface
13th June 2008

When you don't have a valid TGT thunderbird/icedove (, and evolution (2.22.2) just fail if your SMTP/IMAP/Caldav server only allows for GSSAPI authentication. While thunderbird tells you to turn off secure authentication - brilliant idea, evolution just says "error while refereshing folder" in the status bar - quiet user friendly.

Therefore I added a simple dbus interface to krb5-auth-dialog so that these applications can ask it to acquire the TGT for them. Thanks to the dbus glib bindings the code an application that want's a ticket needs to use is as simple as:

#include "krb5-auth-dialog-dbus-client-glue.h"
proxy = dbus_g_proxy_new_for_name_owner (connection,
org_gnome_KrbAuthProvider_acquire_tgt(proxy, "me@EXAMPLE.COM", &success, &error);
if (success)
     printf("Acquired TGT for %s\n", principal);

Currently you can only request a TGT for a principal krbt-auth-dialog knows about (either your username in the default realm or the one you set via gconf) since we don't do principal switching within krb5-auth-dialog yet. But this should do the trick already for most usage cases. A full example application is in helpers/krb5-auth-helper.c. This can readily be used in shell scripts:

cat <<EOF >evo-krb5
#!/bin/sh -e
krb5-auth-helper me@EXAMPLE.COM && evolution

Since the dialog only pops up if you don't have a valid TGT already the password dialog will only get into your way when needed. It would be nicer if those applications would use this interface directly now that it's there.

As usual you can clone from:

git clone

Make sure you build the dbus branch: git checkout --track -b dbus origin/dbus mkdir build && cd build && ../ && make && sudo make install

Tags: single-sign-on.
another krb5-auth-dialog update
8th June 2008

Krb5-auth-dialog now uses the GtkSecureEntry widget taken entirely from GPG's Pinentry. This nice widget uses the memory methods from secmem (also in Pinentry) and removes potentially dangerous methods such as copy and paste. This should make typing your password into krb5-auth-dialog a lot safer. You can clone from:

git clone

Hopefully GtkSecureEntry gets split out of Pinentry so it can be easier used by others (#485056).

Tags: single-sign-on.
krb5-auth-dialog updates
6th June 2008

krb5-auth-dialog (a simple app that monitors Kerberos tickets) now has a tray icon. This allows you to refresh your TGT or destroy the ticket cache any time you want. It also gives visual feedback on the state of your ticket and uses libnotify to notify about expiry/refresh.

valid ticket ticket expired

It interfaces with gconf to store the default principal, the time of the first password prompt and the trayicon's visibility:

gconftool-2 --type=string --set /apps/krb5-auth-dialog/principal "principal@YOUR.REALM"
gconftool-2 --type=int --set /apps/krb5-auth-dialog/prompt_minutes 30
gconftool-2 --type=bool --set /apps/krb5-auth-dialog/show_trayicon false

So overall it behaves more or less like a regular gnome application now. You can use:

git clone

to get the current version. The code is based on krb5-auth-dialog from Gnome SVN. I hope to get the above changes integrated there soon.

Tags: single-sign-on.

RSS Feed