Re: [kitten] Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation...

[[e-mail] (Martin Rex)]

Stefan Metzmacher wrote:
> 
>>> I guess the proposed credential option is necessary, in that case.
>>>
>> 
>> I think in this case ignoring the flag should probably be conditional
>> to whether a PAC is present.
> 
> We should enforce a PAC always to be present, as we don't support
> trusted domains with LSA_TRUST_TYPE_MIT anyway.

I haven't really followed the discussion here, but Microsoft PACs are
a royal PITA, wasting huge amounts of network bandwidth, creating
bad latency on authentication, causing spurious authentication failures
during high-load situations and completely breaking certain rfc4559
HTTP Negotiate scenarios when users are assigned to lots of groups
in Microsoft AD.  Bottlenecks in LSA PAC verifications are extremely
annoying, such as using Outlook&Exchange with 50k+ Users and
at least once an hour an Outlook Password logon prompt pops up because
one of the crazy many rfc4559 Kerberos authentications failed between
Outlook and Exchange.  (Hitting cancel on the popup and toggling
offline/online in the Outlook window status bar retries Kerberos
authentication and typically succeeds...


Simply disabling PACs on the service account for service tickets
solves all of the hard and annoying problems, by enabling the bit
UF_NO_AUTH_DATA_REQUIRED (0x02000000) in the UserAccountControl
property of the service account.

Without setting this bit to omit the crazy PACs, common problems with
heavy (mindless) Group membership usage are this:

   https://blogs.technet.microsoft.com/shanecothran/2010/07/16/maxtokensize-and-kerberos-token-bloat/


Reasons why the myriads of PAC verfications occasionally fail:

   https://blogs.technet.microsoft.com/instan/2011/11/14/the-return-of-pac-mania-aka-some-reasons-why-pac-verification-can-fail/

and btw. huge kerberos tickets can also make rfc4559 fail because of
the excessive size of the HTTP header field to carry the AP_REQ with the
kerberos ticket.

Whenever authorization isn't actually managed through PACs,
i.e. pretty much 100% of the time when the backend is a database
and access through rfc4559 HTTP Negotiate, omitting PACs from Kerberos
tickets comes close to a universal panacea for a huge amount of
"occasional" failures.


-Martin