Catching more principals in ads_keytab_verify_ticket()

[Michael Brown]

Greetings,

I'm encountering a problem with a WinXP workstation and Samba 3.0.11
server in a Kerberos realm with an MIT KDC.  Specifically, the WinXP
workstation is requesting and obtaining a service ticket for
cifs/name.REALM at REALM, which is not one of the combinations tried in
libads/kerberos_verify.c:ads_keytab_verify_ticket().  The list of
combinations attempted currently comprises:

  name$
  NAME$
  host/name at REALM
  host/NAME at REALM
  host/fqdn at REALM
  host/Fqdn at REALM
  HOST/name at REALM
  HOST/NAME at REALM
  HOST/fqdn at REALM
  HOST/Fqdn at REALM
  cifs/name at REALM
  cifs/NAME at REALM
  cifs/fqdn at REALM
  cifs/Fqdn at REALM
  CIFS/name at REALM
  CIFS/NAME at REALM
  CIFS/fqdn at REALM
  CIFS/Fqdn at REALM

Deleting the principal cifs/name.REALM from the KDC results in the WinXP 
workstation falling back to NTLM, which is not desirable since the KDC is 
the only password database.  Creating a keytab entry for cifs/name.REALM 
is easy, but Samba currently won't try to use it; it tries only the 
combinations listed above.


I'd like to propose a slightly different structure for 
ads_keytab_verify_ticket(), as follows:

  allowed_principal_formats[] = {
    name$
    host/name
    host/fqdn
    host/name.REALM
    cifs/name
    cifs/fqdn
    cifs/name.REALM
  }

  for each principal in keytab {
    for each format in allowed_principal_formats {
      if ( strcasecmp ( principal, format ) ) {
	if ( krb5_rd_req ( principal ) succeeds ) {
          auth_ok = True;
          break;
        }
      }
    }
  }

This would get as close to case-insensitivity to principal names as an MIT
KDC allows (i.e. the principal on the KDC still has to exactly match the
case that the workstations request, but the Samba server will then happily 
use the principal, regardless of case), and also allows for the case where 
the DNS domainname is not the same as the Kerberos realm name.

I'm happy to code this up and submit a patch.  Does anyone have any
comments, suggestions or reasons why this might be a really bad idea?

Michael