Files
heimdal/lib/krb5
Nicolas Williams a59bb7132f When building a princ name pick a sane def type
This is part of the fix to #173.  MSFT RODCs insist on the name type for
krbtgt principals be set to KRB5_NT_SRV_INST.

Commentary from Jeffrey Altman <jaltman@secure-endpoints.com>

As reported by David Mulder of Dell's Quest, Active Directory will
return a BAD_INTEGRITY error when a request for a krbtgt service
ticket is received with principal type NT-PRINCIPAL instead of NT-SRV-INST
as required by RFC 4120.

[Nico: RFC4120 does not require this.  See the description of the
       name-type field of PrincipalName on page 55.]

  ERROR: VAS_ERR_KRB5: Failed to obtain credentials.
  Client: SLED10-32$@F.QAS,
  Service: SLED10-32$@F.QAS, Server: ad2-f.f.qas
  Caused by: KRB5KRB_AP_ERR_BAD_INTEGRITY (-1765328353): Decrypt integrity check failed

Microsoft began enforcing principal type checking for RODCs in 2008R2.
Microsoft does state that ALL krgtgt/REALM tickets SHOULD be sent using
principal name type of KRB5_NT_SRV_INST instead of KRB5_NT_PRINCIPAL.

From Microsoft:

  "I believe we discovered the problem. There isn't a bug in Windows.
  There's been a code change to address another issue which puts in additional
  checks for Kerberos tickets. The problem is with the Unix clients when the
  client request a TGT. The Unix clients are using Name-type Principal
  [KRB_NT_PRINCIPAL (1)] instead of using Name-type Service and Instance
  [KRB_NT_SRV_INST (2)]...."

This change assigns the NT-SRV-INST principal type each time a krbtgt
service principal is created.  Unlike Microsoft, the Heimdal mostly does
not care about the name-type of any principals, with the exception of
referrals, where the name type is needed to decide how to find a
next-hop realm.
2016-11-14 21:29:47 -06:00
..
2011-05-21 11:57:31 -07:00
2013-07-18 14:58:54 +02:00
2013-10-04 18:58:31 -04:00
2013-04-29 22:54:11 -07:00
2015-03-24 11:49:58 -05:00
2014-12-01 15:41:12 -08:00
2016-04-19 13:40:46 -05:00
2016-04-16 16:58:08 -05:00
2012-01-10 22:54:50 +01:00
2012-07-02 11:33:18 -04:00
2016-06-09 01:13:15 -04:00
2011-03-12 19:29:00 -08:00
2014-06-09 23:36:23 +02:00
2015-03-24 11:49:58 -05:00
2011-07-24 16:02:22 -07:00
2014-04-25 02:42:17 +02:00
2011-05-21 11:57:31 -07:00
2014-04-25 02:42:17 +02:00
2011-05-21 11:57:31 -07:00
2013-10-15 11:52:37 +02:00
2011-05-21 11:57:31 -07:00
2011-05-21 11:57:31 -07:00
2014-04-25 02:42:17 +02:00
2005-10-08 15:39:42 +00:00
2007-07-15 20:49:46 +00:00
2009-05-04 06:17:40 +00:00
2015-04-13 16:59:20 -05:00
2014-03-24 23:07:49 -05:00
2011-05-21 11:57:31 -07:00
2013-09-12 13:32:22 -05:00
2014-02-04 23:20:11 -05:00
2016-02-26 01:04:31 -06:00
2016-02-26 01:04:31 -06:00
2016-02-26 01:04:31 -06:00
2016-02-26 01:04:31 -06:00
2016-04-19 13:40:46 -05:00
2015-04-19 15:04:16 -05:00
2016-02-26 00:55:30 -06:00
2016-02-26 00:55:30 -06:00
2012-05-28 13:14:55 +01:00
2011-05-21 11:57:31 -07:00
2016-02-29 19:13:09 -06:00
2011-05-21 11:57:31 -07:00
2010-09-18 14:45:33 -07:00
2011-05-21 11:57:31 -07:00
2013-09-12 12:14:40 -05:00
2011-05-21 11:57:31 -07:00
2009-05-04 06:17:40 +00:00
2014-04-29 11:04:21 -06:00
2009-05-04 06:17:40 +00:00
2011-05-21 11:57:31 -07:00
2009-05-04 06:17:40 +00:00
2011-05-21 11:57:31 -07:00
2009-05-04 06:17:40 +00:00
2011-05-21 11:57:31 -07:00
2009-05-04 06:17:40 +00:00
2016-04-15 10:27:07 -05:00
2009-05-04 06:17:40 +00:00
2010-05-30 13:37:07 -07:00
2009-05-04 06:17:40 +00:00
2016-02-26 01:04:31 -06:00
2011-05-21 11:57:31 -07:00
2016-02-26 01:04:31 -06:00