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

[Stefan Metzmacher <[e-mail]>]

Hi Martin,

I don't think your comments apply to what I'm proposing. See the
inline comments below.

>> We should enforce a PAC always to be present, as we don't support
>> trusted domains with LSA_TRUST_TYPE_MIT anyway.

"We" is Samba in here. Services which don't use the PAC at all
are not enforced to use it in future.

> 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...

The PAC contains two signatures, one that's done with the services
long-term key (machine password) and one with the KDCs (krbtgt)
long-term key.

In Samba we're only rely on krb5_pac_verify(), which is an
offline verification that's possible with the same key
that's used to decrypt the ticket itself.

You're talking about "online" PAC verification that's
used to verify KDCs signature by asking a DC.

See
https://blogs.msdn.microsoft.com/openspecification/2009/04/24/understanding-microsoft-kerberos-pac-validation/
regarding SeTcbPrivilege.

The main difference is that code that runs as part of the OS
with SeTCBPrivilege only needs the offline verification.

And Samba is similar and only requires the offline verification.

> 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.

I'm not sure that it applies to all workloads, but it's quite possible
that http is typically different to SMB, LDAP or DCERPC.

metze