On 03/27/2018 11:02 AM, Markus Kuhn wrote: > For example, the above SPN works in kvno (krb5-1.13.2, Ubuntu 16.04) > only after I remove the port number (whereas both SPNs are registered > in our Active Directory KDC): > > $ kvno MSSQLSvc/db0.ad.cl.cam.ac.uk:1433@ > kvno: Server not found in Kerberos database while getting credentials for > MSSQLSvc/db0.ad.cl.cam.ac.uk:1433@ > > $ kvno MSSQLSvc/db0.ad.cl.cam.ac.uk@ > MSSQLSvc/db0.ad.cl.cam.ac.uk@: kvno = 2
In this usage the principal name is specified on the command line (albeit with an empty realm, which has the special meaning of starting with the local realm and possibly accepting a referral). So kvno and the library make no assumption that db0.ad.cl.cam.ac.uk (with or without the port) is a hostname; they just pass the principal name off to the KDC as-is. I don't have any theories as to why the first command isn't working. You could try using "KRB5_TRACE=/dev/stdout kinit ..." to gain more insight, or perhaps using Wireshark to verify that the correct request is sent to the KDC. > I could not find any mention of port numbers on service principal names > in MIT Kerberos related documentation or RFC 4120, but Microsoft seems > to consider this an essential feature, at least in its ODBC driver > for SQLServer. In release 1.13 we added support for port numbers in the hostname part of a service-name-to-principal mapping operation (sometimes called "sn2princ"), by removing the port number before canonicalizing the hostname and then adding it back in afterwards. But that's irrelevant to the kvno invocations described above. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
