It us understood that because Samba implements parts of S4U2Self and S4U2Proxy we need to follow Microsoft with the protocol changes made recently.
Because Samba doesn't implement "Protected Users", and only implements constrained delegation in terms of the service that can be delegated to, the remaining issue appears to be that UF_NOT_DELEGATED is not honoured.
UF_NOT_DELEGATED controls the forwardable flag in the ticket, which is used to work out if this particular user should not be open for constrained delegation.
Does anybody else have a different reading?
I think I understood the plan to be for Heimdal and MIT Kerberos to start to match Windows and issue a PAC for all S4U2Self tickets and to include a signature over the whole ticket (including flags) in that PAC.
That will, as with Windows, prevent modification of the forwardable flag, or anything else for that matter.
Can you write up the plan with a focus for particular things I can do to progress this, at least for Heimdal (as this is the production KDC for now in Samba).
In another place you said it was 'just a bunch of work' but I'm not clear exactly what remains to be done so I'm lost as to being able to assist.
I don't mind if that advice is either on the MR or this Samba bug.
> I think I understood the plan to be for Heimdal and MIT Kerberos to start to match Windows and issue a PAC for all S4U2Self tickets
For all tickets, unless turned off by realm configuration, request padata, or the server DB entry. There is no way to tell whether a ticket will be used as an S4U2Self evidence ticket, and that's where we need the signature.
(In reply to Andrew Bartlett from comment #1)
The main issue is that UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION flag (set via samba-tool on an account) has no real effect because it can be forged. That and the UF_NOT_DELEGATED you mentioned, as the both use the same mechanism, that is the forwardable flag.
How about a call to sync on this?
We don't seem to be trying to keep the fact that we are working on this very private for various good reasons, including in particular the need to land intrusive patches in the upstream projects.
Given all that should we just make this bug public?
(In reply to Andrew Bartlett from comment #5)
> Given all that should we just make this bug public?
This has been made public as a protocol defect, so yeah we should make this bug public IMO.
Thanks, I agree.
As the patches and tests for this are being developed in public and will be landed in master first, a private bug is not as useful. Removing embargo.
This bug was referenced in samba master: