Catching more principals in ads_keytab_verify_ticket()

[Jeremy Allison]

On Sat, Feb 26, 2005 at 02:53:31PM -0800, Doug VanLeuven wrote:
> Michael Brown wrote:
> 
> >On Sat, 26 Feb 2005, Michael Brown wrote:
> > 
> >
> >>My domain and realm are different, though it's only on a test network so
> >>this isn't a huge barrier.  The major problem for me is the case
> >>variability; the method I'm proposing to fix this problem just happens
> >>to also makes it easy to cope with realm != domain.
> >>
> >>I'm working on a patch at the moment.
> >>   
> >>
> ><>
> >Patch against current SVN attached. Compiles cleanly with no warnings,
> >works when I test it.
> 
> Hi Mike,
> Since that section of code went in, the noise level has gone to almost 
> zero.  There's no telling, really, which variations do the trick for all 
> environments.  When I mentioned I thought it wouldn't hurt to add a 
> variation to cover your discovery I had in mind something more like the 
> following.  This adds two entries to the keytab and the verify routines.
> 
> If I understood you correctly, you want this - name.REALM at REALM
>  27 cifs/gate.NT.LDXNET.COM at NT.LDXNET.COM (ArcFour with HMAC/md5)
>  27 cifs/gate.NT.LDXNET.COM at NT.LDXNET.COM (DES cbc mode with RSA-MD5)
>  27 host/gate.NT.LDXNET.COM at NT.LDXNET.COM (ArcFour with HMAC/md5)
>  27 host/gate.NT.LDXNET.COM at NT.LDXNET.COM (DES cbc mode with RSA-MD5)
> To add to these style entries - fqdn at REALM
>  27 host/gate.ldxnet.com at NT.LDXNET.COM (ArcFour with HMAC/md5)
>  27 host/gate.ldxnet.com at NT.LDXNET.COM (DES cbc mode with RSA-MD5)
>  27 cifs/gate.ldxnet.com at NT.LDXNET.COM (ArcFour with HMAC/md5)
>  27 cifs/gate.ldxnet.com at NT.LDXNET.COM (DES cbc mode with RSA-MD5)

Ok, this is why I *hate* the krb5 principal code. If you guys are
working on this, please also give me something that addresses bug
2414 here :

https://bugzilla.samba.org/show_bug.cgi?id=2414

"When joining an Active Directory when subdomains are being used, the servicePrincipalNames inserted 
in AD are incorrectly generated. 

.....

How to fix: basically, SPNs should be generated from FQDN, rather than HOSTNAME.ADREALM (or in 
addition to)."

I *hate* kerberos so much :-).

Jeremy.