[Dovecot] auth_default_realm, pam_krb5, gssapi

[Sergey Urushkin]

Hi,
Just writing here my note about auth_default_realm, pam_krb5 and gssapi.
It seems that 'pam' passdb and 'gssapi' auth_mechanism doesn't honor 
'auth_default_realm' setting, at least in several setups I deal with.
Here is a part of the config:
  passdb {
  args = max_requests=100 cache_key=%u%r dovecot
  driver = pam
  }
  auth_default_realm = REALM.COM
  auth_mechanisms = plain login apop gssapi
  auth_username_format = %Uu

The problem is that pam_krb5 strips default realm from username (by 
default), even if auth_default_realm is specified and even if user logs 
in as 'user1 at realm.com' (with domain part).
A part of auth.log:
  mail auth: pam_krb5(dovecot:auth): user USER1 authenticated as 
USER1 at REALM.COM

The same for GSSAPI auth, if specified authorization name doesn't 
contain domain part.
A part of mail.log:
  mail dovecot: imap-login: Login: user=<USER1>, method=GSSAPI, 
rip=172.16.0.1, lip=192.168.1.1, mpid=5828, TLS, 
session=<bpzvRmDwPACsFwCX>

For several reasons I do need username inside dovecot to contain domain 
part. So, I found a solution to this problem - modifying /etc/krb5.conf 
this way:
  [libdefaults]
  default_realm = REALM.COM
  [realms]
  REALM.COM = {
  auth_to_local = RULE:[1:$1@$0]
  }

This will add realm part to the local username despite using default 
realm.
Maybe it's better to put this example to the wiki?
Tested with ubuntu 12.04 and dovecot 2.2.10, mit kerberos 1.10, amd64.

Taking the opportunity, I'd like to ask, is there a way to make 
usernames case insensitive while using GSSAPI. The case:
klist shows:
      Principal: user1 at REALM.COM
username in thunderbird 'uSer1 at REALM.COM'. Dovecot gives me this message 
(I use auth_username_format=%Uu for pam_krb5 to be able to login with 
lowercase realm):
      dovecot: auth: 
gssapi(USER1 at REALM.COM,172.16.0.1,<IIgwMGbw3ACsFgA4>): User not 
authorized to log in as USER1 at REALM.COM

As I know kerberos usernames are case insensitive (user part), at least 
kinit and windows against AD works that way.
Seems that k5credentials passdb extra field will not help here too. Does 
anyone have an idea?

Thanks.

-- 
Best regards,
Sergey Urushkin