Some further details.  In conjunction with other fixes that are not directly relevant here, for November Patch Tuesday (9 Nov) it is anticipated that the MS PAC will be extended as part the info on this bug.

This should make it practical for MIT and Heimdal to parse the PAC and obtain the 'real cname', for presentation to the Kerberos accepting application.

Furthermore, changes are proposed such that non-admin users with the right to create computer accounts (by MachineAccountQuota or otherwise) will have to keep the trailing $ on those accounts, even if they can rename them.

The combination of features will allow unix applications to more safely accept tickets from AD servers, with less risk that they are confused into logging in as 'root' (it would see root$ at best).

Nothing in this will prevent this attack from AD users given the right to create other AD users (compared with computers), but the MachineAccountQuota feature 
will be less dangerous to Kerberos acceptors in AD after these changes, if the PAC is found.

https://www.netspi.com/blog/technical/network-penetration-testing/machineaccountquota-is-useful-sometimes/

However, there may not in the current design be a PAC, nor any indication that there should/would have been one.  A krb5.conf setting 'PAC expected' may be required.  However I've lobbied hard that unless UF_NO_AUTH_DATA_REQUIRED is set, that the PAC would always be sent.  

I'll know if this was successful for MS Windows in a week, but Samba is likely to do this.

My hope is that with this alignment of changes, we can patch MIT and Heimdal Krb5 to parse the PAC, change the cname and so protect our users as much as is possible within the name-based constraints we live under.

Looks good! The new buffer is simply there to avoid needing NDR support in libkrb5, right? Because given this is going to require Windows/Samba KDCs to be upgraded, I wonder whether that would also be a worthwhile fix (although, don't get me wrong, a solution that doesn't require NDR is definitely worthwhile).

Regarding the attachment, presumably you mean to say the offsets are rounded to 8 bytes, not the lengths?

We could also extend gss_get_name_attribute() (at least in MIT where the plumbing is there) to get urn:mspac:upn-dns-info:sid, returning a stringified SID, for non-Windows applications that wish to just authorise the initiator by SID. But given so few applications use naming extensions, perhaps a better option would be a flag in the acceptor credential to say that gss_accept_sec_context() should return SIDs in names (GSS_C_NT_SID) instead of Kerberos principals.

Anyway, on Heimdal, we could enhance krb5_rd_req_ctx() to rewrite ticket->client if check_pac is TRUE. But that would throw away the ticket client principal, effectively you couldn't call krb5_pac_verify() again. So perhaps it will be better to move the logic into libgssapi instead (noting that this will have to be duplicated if Samba uses its own GSS implementation).

Once the embargo is lifted I can discuss with the rest of the Heimdal team.

Ah, I see most of the Kerberos library changes were already discussed in #14557, which I had not read closely until now.

(In reply to Luke Howard from comment #2)
Yes, I specifically petitioned for this to avoid needing an NDR parser, and was successful.

As long as the most important services use GSSAPI (SSH, mod_auth_kerb in Apache, NFS, etc) then I don't really mind where this is put.  I just lobbied to ensure it would be possible, the rest I'm handing over to you good folks, if that's OK.

Samba will be parsing the PAC regardless so is not impacted one way or the other, this is about saving the rest of Unix.

Regarding the SID, this is of course a much safer long-term-identifier.

What I think would be ideal would be for a patch to be made for mod_auth_kerb to return the SID in LDAP escaped format, so for example a Drupal install can be told to map that to a samAccountName in the LDAP plugin, without rewriting the stack.  So providing a way that could happen would be good.

I also thought of (for example) Keycloak, who should parse the SID and use that.

We can't open this up to the world (but perhaps AB can brief one Keycloak dev inside Red Hat), loose lips sink ships and all that, but we can prepare the groundwork for others and have infrastructure ready.

The 8-byte thing is for the bit-field (used to communicate the client's desire regarding a PAC internally in the TGT, hopefully not needed if we get our way), which is to be measured in the header in terms of 'known' bits, but is 8-byte chunks of bits-or-zeros, I'm told.

OK, I see Nico is on this so, I'll await his thoughts.

Not sure if I quite understand the 8-byte thing you're referring to, isn't Flags 4 bytes? It seems odd the lengths would be rounded up because then you don't know how long the field values are (unless they're NUL terminated or, the SID has its own embedded length). The offsets being aligned to 8 bytes would be less surprising although shouldn't be necessary for string values.

Sorry Luke, I was referring to a different buffer which I don't have here, which is a detail of the PAC.  I should have checked what I had in the attachment.

I actually don't really know what the comment means exactly, that is a copy&paste from the MS engineer and I agree it seems odd.  I hope is is offsets being rounded up, that would make more sense.

Thankfully a SID's length can be determined, but yes, this seems strange.  

I've asked for a sample PAC which will help a lot.

> Imagine in particular an account with userPrincipalName of root@SAMBA.EXAMPLE.COM.  This might cause unexpected behaviour in kerberos acceptors that are name-based (eg) ssh.

I take issue with this.

In my circles we refer to this behavior of ignoring the realm as "realm chopping", and yes, it's bad, but every username is affected, and root is not particularly special.  Just don't realm-chop.

There is nothing we can do in the krb5 libraries, short of changing '@' to something else, like '%', to prevent libraries and applications layered on top from realm chopping.  And replacing '@' would break just about everything.

This is not a new problem.  This is not a bug that should be embargoed.  It's not a bug.

It's not just about realm chopping, though, as the domain itself is also a valid UPN suffix. i.e. in a domain SAMBA.EXAMPLE.COM the user bar could have a UPN of foo@SAMBA.EXAMPLE.COM (correct me if I'm wrong, Andrew; I believe there are some some checks for uniqueness, to assert at user where sAMAccountName == foo does not exist).

The point of the PAC extension if simply to make the canonical principal name easily available in environments where the service does name-based authorisation and cannot be certain the client AS-REQ used the canonicalize flag.

I suppose we can separate the discussion into:

(a) does Heimdal want to support this? and;
(b) if so, do we implement it in libkrb5 or the krb5 GSS mechanism

Ditto for MIT, but that's really for Greg to decide.

(In reply to Luke Howard from comment #11)
Correct, user foo@DOMAIN.COM can obtain a ticket, by specifying no-canonicalisation, of bar@DOMAIN.COM, and absent this extension (or reading the NDR-encoded portion of the PAC) the target server is none the wiser.

Talking with Alexander Bokovoy of FreeIPA/sssd and looking at example idmap configurations for NFSv4 it seems to me that mapping of the organisations primary domain into the unqualified/plan unix nsswitch namespace is quite common, allowing 'local' users to authenticate with AD credentials.

There is no uniqueness constraint in AD currently between userPrincipalName values and samAccountName values (this is something Samba intends to address), the only 'protection' comes from the name resolution order inside the KDC, meaning that some names have higher priority than others. 

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6435d3fb-8cf6-4df5-a156-1277690ed59c

Note however Samba implements a different ordering (UPN first).

My argument for this is that application developers and system administrators have chosen their security boundary based on the observed behaviour with canonicalised tickets, and don't expect UPNs, other aliases (per the link) or even enterprise principal names (yes really) in that returned client name.

As to the embargo, yes, there may be little new here and if so I'm sorry for troubling you, but I request you observe the embargo as there are broader issues I'm not at liberty to disclose.

Thanks,

Andrew Bartlett

I'm happy to write up a PR once the embargo is lifted, and then the rest of the Heimdal team can decide whether to approve it or not. :)

(In reply to Luke Howard from comment #13)
Thanks!

Adding Sumit for SSSD.

In FreeIPA case we default to unqualified names output in SSSD but there are actually three distinct things:
 - input format name
 - internal fully qualified name
 - output format name

For input SSSD accepts both unqualified and qualified names. One of configured domains can be set as a default domain for the unqualified names. Output format depends on ambiguity of the user/group name -- if they are from the same default domain, the name would be unqualified.

For configurations where nss_sss is used together with IDMAP sss module in Samba configuration, this should be more or less the same as nss_winbind and winbind. Detecting a state based on /etc/nssswitch.conf content is not really helpful.

I think Sumit had concern about Kerberos name mapping in .k5login and .k5users but I don't remember exactly what that was.

Mapping Kerberos principals to local names is orthogonal to this, no? This is completely configurable through the krb5_aname_to_localname() and krb5_userok() plugin mechanisms (in Heimdal, at least). (The mechanism-independent GSS-API equivalents are gss_localname() and gss_authorize_localname().)

Instead, as I understand it, this bug is about making the canonical Kerberos principal name – sAMAccountName@REALM – available to Kerberos services where the client did not request canonicalisation at the time of the AS-REQ.

(In reply to Luke Howard from comment #16)
I suppose it could be considered orthogonal, and yes, this is 'just' about making the canonical Kerberos principal name – sAMAccountName@REALM - the one that is obtained by the application.

I do however see that garbage-in-garbage-out applies to mapping Kerberos principals to local names, that situations that administrators had thought safe can be unsafe if the names can be varied with too much freedom. 

The biggest risk is a default or common mapping of AD names to names that were *not* provided by AD, such as well known privileged accounts like root, or (on eg many cloud hosts) "ubuntu".  Essentially I'm thinking about the consequence not just the policy need that tickets clearly represent who they were issued to.

It should be remembered that in AD computer creation privileges are broad - all domain users by default.  Combined with step two of 3.3.5.6.1 Client Principal Lookup https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/6435d3fb-8cf6-4df5-a156-1277690ed59c (cname of root, account of root$) an unprivileged user can create tickets with such an 'unexpected' name. 

I know the machine acccount quota this could be considered an AD-misfeature and should be disabled, but that isn't going to happen any time soon - things rely on it sadly, just as they do on the $-extension lookup steps listed above (we have Samba bugs to prove it).  

The counter-point would be that in AD everything is SID based and the creation of 'strange' names are of no consequence.  

In the middle I'm just trying to ensure that as few Unix devices are 0wned as is practical, now that I've got MS to give us a way to get the samAccountName practically.

Anyway, hopefully once this is all the appropriate level of protection can be added to the Kerberos libs, for the protection of the un-aware. 

Thanks,

Andrew Bartlett

Got it. Well, if we agree it is a problem, then the only solution ends up being the one you have proposed, because the service has no way of knowing whether the client name in the ticket is the canonical one or not.

(Technically not true, it can NDR decode the KERB_VALIDATION_INFO but as you've pointed out that would require Kerberos implementations to implement enough NDR to do it.)

>  - (for example) by default a kinit to an alias (a userPrincipalName for example) in AD will get a ticket with that UPN as the cname

Can an AD user get any alias they want?  If not, I think I don't care.

What am I missing?  Can I create any alias I want in AD that isn't taken?

If I understand Andrew right, one of the dangerous cases is because anyone can join machines to a domain, and if your machine is called ROOT, then you can acquire a ticket for that principal sans $ owing to the name lookup rules.

(In reply to nico from comment #20)
Yes.

The machineAccountQuota and the implicit lookup on <cname>$ is what scares me, because all unprivileged users and computers get those rights by default, so essentially they can create any un-taken name they want.

Sorry about the diversion via UPNs, the UPN is an issue, a user with the right to create users can select samAccountName and UPN arbitrarily, but machineAccountQuota is worse.

Sorry for any confusion, the tricky balance between discretion and disclosure.

FWIW when I google machineAccountQuota, this is the first thing that comes back:

https://www.netspi.com/blog/technical/network-penetration-testing/machineaccountquota-is-useful-sometimes/

So, it's not like this attack is unknown, it's just that no one has combined it with name-based authorisation.

I suspect if you're using name-based authorisation you should definitely disable MAQ.

Thankfully one of the things the Nov changes will come with is a requirement that those accounts (computer accounts created as non-admins) keep their $, which will avoid a lot of the games that researcher used.

I will be thanking the authors of that page, that page helped me a lot with thinking about ways to break our worlds.

Is there a schedule for this?

(In reply to nico from comment #26)
"11B" eg Patch Tuesday 9 November.

Created attachment 16811 [details]
Heimdal patch v0

This patch against Heimdal is completely untested, so it probably won't work. But, if someone wants to debug it, be my guest.

Created attachment 16818 [details]
Sample PAC from Microsoft to confirm parser is correct.  Please don't insert into public things.

This is a base64-encoded PAC with the additional changes in it.  Please keep confidential, we can build our own version later for testing with, but for now as we don't have a test Windows to work with this will need to do.

Created attachment 16819 [details]
Samba IDL for new HAS_SAM_NAME_AND_SID behaviour

Created attachment 16826 [details]
patch to add IDL and fill in HAS_SAM_NAME_AND_SID

This patch includes the change to our KDC to issue the PAC with the new info.

Created attachment 16831 [details]
Heimdal patch v1

More working patch, allows UPN to be absent, uses DNS domain name directly as realm as it appears to be already capitalised.

TODO: add support for GSS acceptors extracting the SID.

I'm sorry I'm responding so late but the last year has been quite challenging for me in multiple life areas.  

Andrew wrote in private e-mail "Microsoft is 50/50 on changing Kerberos behavior to always issue a PAC to a target service, regardless of the KERB-PA-PAC-REQUEST.  It would honour ADS_UF_NO_AUTH_DATA_REQUIRED (a flag in userAccountControl on the AD service account) only.   A Kerberos implementation could then rely on the PAC and get the samAccountName knowing that if the PAC was not present they were not in AD."

As the person that requested the addition of ADS_UF_NO_AUTH_DATA_REQUIRED, the motivation was to ensure that the size of the generated Kerberos ticket would be small enough to be transferred in a single UDP packet without fragmentation, and be small enough to be embedded in a web service cookie.   The primary use cases were for

 1. the AFS3 rxkad-k5 challenge-response protocol

 2. Stanford's webauth 

Since its introduction in Windows Server 2003 SP1, the ADS_UF_NO_AUTH_DATA_REQUIRED flag has become the recommended configuration for many non-Windows services that are unable to support large packet sizes.  

As the name of the flag implies, the point of the setting is that the application service does not rely upon the PAC for authorization data.  In other words, it doesn't require the group membership information.  The flag was never intended to indicate that the application service would break if AUTH_DATA were provided.

For OpenAFS and AuriStorFS and other filesystems such as NFS which leverage the client principal name, if the client principal name can be tampered with such that it is set to a name that might no longer be a current AD account but once was an AD account, such a client principal could be used to obtain authorization to data that the former AD account was authorized to access.

There is a broad assumption by many Kerberos admins that if they remove the ability to authenticate as a name that prevents access to data authorized for the name.   It is rarely the case that the AD admin is also the administrator of all of the non-Windows application that might have authorization rights embedded within it.   For example, the OpenAFS / AuriStorFS Protection service and the embedded ACLs within the filesystem namespace.   AuriStorFS provides the ability to disable an authentication name entry separate from deletion but OpenAFS does not.   In order to ensure that a name and assigned id are not reused, the authorization entry in the Protection service must remain.

For AuriStorFS, which supports combined identity authentication of both the user process and the machine from which the request is issued, the machine account identity (e.g. DESKTOP$@AD.DOMAIN) matters as well.  The ability of an untrusted entity to select their own names is particularly problematic for AuriStorFS when they are machine names because rights granted to users can be elevated when combined with a machine identity from an appropriate group of machines.

See https://www.auristor.com/documentation/man/linux/7/auristorfs_acls.html for use cases.

The underlying problem here isn't the presence or lack of a PAC or other AUTH_DATA field.   The issue is whether or not the machine accounts created by untrusted entities are permitted to select their own names.  

Heimdal master supports client principal aliases.  They have proven quite useful for realm renaming (jaltman@YOUR-FILE-SYSTEM.COM has an alias of jaltman@AURISTOR.COM and jaltman@AURISTOR.IO).  The alias permits a user to authenticate as any of the client principal names to obtain a ticket for the requested client principal name.   This is fine because the names are approved by the realm administrator.   

MachineAccountQuota is a mess.   The underlying problem is that the untrusted party can select names which do not need to go through any of the namespace management processes the organization might have in place.

For example, many sites that operate AD do so in parallel to MIT or Heimdal realms.   When this is the case, they often operate a namespace and password synchronization mechanism to ensure that a principal name is reserved in both realms even if the client principal is only permitted to be used in one of them.  A client principal that is restricted to one of the realms is created disabled in the other.  What MachineAccountQuota permits is for creation of a client principal name to bypass all of this and therefore it shouldn't be permitted to exist.

I do not believe that its possible to fix this mess by adding additional fields to the issued tickets.  Partly because I know how many filesystem deployments that exist in the world that would never be updated to look at PAC fields to identify a canonical name.   The only way to fix this is by preventing the creation and use of untrusted client principals.  

Microsoft should as part of any update disable MachineAccountQuota as a method of adding untrusted accounts without domain admin approval.  When MAQ is enabled, accounts should be created in a disabled state.  A workflow should be implemented to require domain admin approval of requested names before the account can be transitioned out of the disabled state.  The ability to add/change UPNs and samAccountName should be removed from the MAQ account creator.   All existing MAQ created accounts (which can be identified by the existence of the ms-DS-CreatorSID attribute) should be disabled until domain admins review and enable them.   This would permit account names to be manually synchronized with the organizations identity provisioning system.

Let me be clear, the problem here isn't that a user account can have multiple client principals as aliases or that a client principal alias is specified as the client principal name.  Nor is the problem that the issued service ticket fails to contain the "canonical client principal name" or fails to include a list of all of the client entity's aliases.   None of that is a security problem.  The security problem is the fact that the account was created by an untrusted entity and that the names that are being authenticated are themselves useless.

A Kerberos realm that authenticates trusted and untrusted names is worthless.  It is in my opinion stupid to try to patch over the problem by adding a new field that is supposed to signify that "this client principal is trusted".  This is especially unhelpful because the canonical name that it is suggested that services rely upon instead is itself untrusted.  So what if it has a $ appended to the end of the name.

Another attack vector I will mention here as I think about it related to the AFS3/AuriStorFS Protection services are that authentication as a group entity is permitted.  Therefore, the ability to force a group-name@REALM client principal ticket for a realm trusted by an AFS3/AuriStorFS cell would grant the client all of the rights of the group without authenticating as an individual user.

Many of the Athena schools rely upon this ability.   I suspect that they are unaware that when they migrated from MIT Kerberos to AD or added AD as a second synchronized source of name authentication that they opened a Pandora's box.

At the very least security@openafs.org needs to be notified of the problem.  However, so do all of the NAS vendors that support Kerberos authentication for NFS.  Anyone that maintains an authentication name to UID mapping database. 

You should also include Apple's security group.  IBM also has a Kerberos distribution that will require updates.  The Java GSS/Kerberos implementations from Oracle and IBM will also require the same changes being made to MIT and Heimdal.  Not that Apple's Kerberos is a fork of Heimdal and they no longer pull patches from Heimdal.  What about Debian, Ubuntu, SuSE, and other Linux distros?

Russ Allbery informs me that the maximum base64 encoded ticket size that could be supported by WebAuth is about 2K.

I agree that there should not be a kinit control to prevent t requesting a PAC and I am strongly in support of disabling that behavior in the KDCs.  However, I do not believe that inclusion of the new fields in the PAC address the root problem.

(In reply to Jeffrey Altman from comment #35)
Sadly I'm informed that while the extension to UPN_DNS_INFO will go ahead, it will still be possible for the client to request no-PAC via KERB-PA-PAC-REQUEST

Ideally all target services would use the PAC and embedded SID to find the user's stable identity and confirm this is an AD user, but in name-based systems the provided samAccountName would at least be canonical at the time the ticket was issued.

As was noted in other comments significant important applications set ADS_UF_NO_AUTH_DATA_REQUIRED, and these won't ever get the PAC.

It has been pointed out to me that bit 15 - canonicalize is set by Windows AD in tickets requested with that flag.  

I can't see that being set in Samba AD with Heimdal but we could fix that.  The presence of that flag would be of comfort to target services that the name is canonical. 

My initial recommendation is that the libkrb5 on target services require the PAC when they know they are in an AD domain, parse the PAC for the samAccountName, and if they don't get the PAC that they require that 'canonicalise' is set in the ticket.

I would also recommend that tooling which joins to AD write the required configuration out into krb5.conf when joining AD.

However such a pattern would break clients that use AD with the default krb5.conf (canonicalise disabled) and which target servers using ADS_UF_NO_AUTH_DATA_REQUIRED or which set no-PAC at kinit time with KERB-PA-PAC-REQUEST.

With possibly breaking protocol changes ruled out there are no good options here and this will take some time to resolve.  On the flip side, the challenges here have been the case since AD was implemented, only now we have some partial solutions.

> It has been pointed out to me that bit 15 - canonicalize is set by Windows AD in tickets requested with that flag.

Bit 15 in ticket flags is enc-pa-rep (RFC 6806 section 11), which has a different meaning.  I don't see a ticket flag for canonicalize.

(In reply to Greg Hudson from comment #37)
That's unfortunate, I was just passing on my notes.  Clearly I'll need to get some more testing done to understand what I was told. 

If so then sadly we may have no options other than requiring and parsing the PAC.

I think you’re confusing ticket flags and KDC-REQ options. The latter allows the client to request canon from the KDC. There is no canon ticket flag which would, if it existed, let the service know if canon was used. Maybe that would be useful but, well, it doesn’t exist, so yes services will need to use the PAC if they want the canonical name, or assert that all clients always set the canon flag as organizational policy.

The latter (policy) is not foolproof of course.

(In reply to Luke Howard from comment #40)
A KDC could require canonicalise of course, or canonicalise || PAC.  

But that's probably a 'next release' thing I think, at least by default.

We have confirmed with tests that no such bit exists (even if mis-named or mis-used), the canonicalize flag from the client doesn't change anything in the ticket, other than of course the name (as expected). 

MS has also confirmed this hope was misplaced.

So, services that wish not to be confused should require the PAC and use the information found within it.  

Perhaps new ticket flags of 'PAC was suppressed' and 'canonicalized' (only set if the name actually changed) could be allocated and advocated for, as a further fix and a way to make this fix practical.  

I understand the distaste for the situation where this is a config opt-in on the Kerberos acceptor, given the low uptake such an option would have.

On the Active Directory side, perhaps the DC could potentially be patched to refuse the issue tickets in some situations.

Once this is all out of embargo it will be easier to publicly prototype some ideas in Samba and then for impacted users to advocate to MS for a future release/fix.

See RFC6806, which defines the canonicalize(15) KDCOption but no associated ticket flag. Interestingly it also defines a AD-LOGIN-ALIAS authorisation data type containing all known principal aliases, but to my knowledge no one has implemented it. Arguably this would have been a more standards oriented solution than the new UPN DNS info. The first element in the SEQUENCE could contain the canonical name.

If MIT/Heimdal needs a server to test against to validate the mitigation here then WIP patches for Samba are available on bug 14834, please ask and I'll CC.

However if patches to allow administrators to address this are unlikely to be published with urgency, then I suggest waiting for a Microsoft release and testing that, in case we (Samba) got it wrong.

I don't have time or resources to test the patch unfortunately. When MS releases and you have a chance to test, could you please open a Heimdal PR with the patch and any changes?

This bug was referenced in samba v4-14-stable (Release samba-4.14.10):

df9bbb3e7304a6c8443f8955d5ec1ce458a34bce
1c440ea65759fe6a9b8db8fd567e4a0d6cd63d44
adea7022c7822f1494f696d49025e10add1f5a0e
6dda0f61bb906590316599c1065d0f2aa51e5beb
eac75fb3b601880f8692dfd4674c49b843cf7275

This bug was referenced in samba v4-13-stable (Release samba-4.13.14):

52a505512a2b7d077a4b458a77094c2d2ff72e5e
49ddf6166b304836886f2bd951782a144dc3d0e3
f4841ce8c11bdf2165aa3ead9c9589ad699cd03b
718aefaacf48d4cdd04e895bc69f5d6b4a028780
c59f5762ead77bcf9add3994a88a6d2b8e383869

This bug was referenced in samba v4-15-stable (Release samba-4.15.2):

e670327b5ee6124219e922dded83a805ab7a521f
f11063bc77df573d36ecab4751070dc96723c2f6
a98a756a689c8a60966aa4e56a90013fc29d9b80
596841810d79b5ce47301141ab979aad0cf165cf
3116befb038f33a9d26de4a17da0e24560c9e462

This bug was referenced in samba v4-15-test:

e670327b5ee6124219e922dded83a805ab7a521f
f11063bc77df573d36ecab4751070dc96723c2f6
a98a756a689c8a60966aa4e56a90013fc29d9b80
596841810d79b5ce47301141ab979aad0cf165cf
3116befb038f33a9d26de4a17da0e24560c9e462

This bug was referenced in samba v4-14-test:

df9bbb3e7304a6c8443f8955d5ec1ce458a34bce
1c440ea65759fe6a9b8db8fd567e4a0d6cd63d44
adea7022c7822f1494f696d49025e10add1f5a0e
6dda0f61bb906590316599c1065d0f2aa51e5beb
eac75fb3b601880f8692dfd4674c49b843cf7275

This bug was referenced in samba v4-13-test:

52a505512a2b7d077a4b458a77094c2d2ff72e5e
49ddf6166b304836886f2bd951782a144dc3d0e3
f4841ce8c11bdf2165aa3ead9c9589ad699cd03b
718aefaacf48d4cdd04e895bc69f5d6b4a028780
c59f5762ead77bcf9add3994a88a6d2b8e383869

This bug was referenced in samba master:

558f440f2060934d39bd1b6297e554f47fc44e8c
23dc0cbd53e16f0450204aa3a0eb971d1215bc5a
3f7b971d3762b6f3a1e934a99f1b25365f7b6a54
903ab1a02776504ba3b4eb59470cfb8bdf4f2a90
43983170fc8671f7c0f0a0a6e1f8a82d9dbc2b60

The patches addressing this issue have been pushed to master and security releases made.

Removing embargo.  To get mitigation into upstream products we need to be able to discuss this in public forums.

Can we consider the sample MS PAC public now the embargo has been lifted? I can't seem to access the original attachment but its original contents are public as part of the Heimdal patch attached to this bug.

If it is public, I'll file a Heimdal PR with the patch.

If not, can you provide me with some other sample test data?

Heimdal PR here:

https://github.com/heimdal/heimdal/pull/902

I don't think the sample MS PAC is supposed to be made public, as it contains account names and such. I'll upload an alternative PAC obtained from Windows to use as a sample.

It also appears to contain a bug (FlagsLength in PAC_ATTRIBUTES_INFO is 0x02 instead of 0x20). If you can provide me with a fresh PAC that is OK to make public, that'd be great, I'll update my Heimdal patch.

Created attachment 17062 [details]
Sample PAC obtained from a Windows DC

OK, I added a new sample PAC. I think that the FlagsLength field is supposed to be the number of flag bits that the DC supported, in case new ones are added in future, so a value of 0x02 is correct.

Ah, got it. I assumed it was rounded up to 4 bytes.

Thanks, I've updated the Heimdal PR, the other PAC should be gone now.

Not sure how to delete the patch I submitted into this bug, could you please do so for me?

I don't think I'm able to delete attachments, but I've hidden them for now.

Support merged to Heimdal master.

There is a new [libdefaults] option in krb5.conf, report_canonical_client_name (default disabled), which will have replace the ticket client with that from the UPN_DNS_INFO_EX (if present) when processing an AP-REQ.

This pull request also included support in the KDC for the UPN_DNS_INFO_EX and ATTRIBUTES_INFO buffer types. The windc PAC generation function was changed to pass PAC attribute flags indicating whether a PAC was explicitly or implicitly requested. Samba should update its backend appropriately.