Russ Allbery <[email protected]> writes: > Adam Megacz <[email protected]> writes: >> Russ Allbery <[email protected]> writes: > >>> Check the host/* principal on the system to which you were >>> authenticating. I bet that the REQUIRES_PRE_AUTH flag was set for it, >>> which means that only tickets that are pre-authenticated can >>> authenticate to that service principal. > >> Indeed, that was it! Russ saves the day again. > > The behavior caused by setting REQUIRES_PRE_AUTH on principals to which > one authenticates rather than principals one authenticates as always > strikes me as surprising, unexpected, and unintuitive.
We are open to suggestions about how to remedy this behavior. I think it stems from the KDB flag REQUIRES_PRE_AUTH being overloaded with two mostly unrelated meanings: (1) require preauthentication when the specified client obtains initial tickets; (2) require that any client's service ticket have the "preauthenticated" flag set when presented to a specified service. How many people have a security policy that requires behavior (2) above? If so, is it necessary to conflate that behavior with behavior (1)? >> Curious: I assume that the failure mode here is some variation on the >> sshd machine asking the KDC for a delegation and the KDC refusing. > > I believe it fails even if you're not doing delegation. I believe the KDC > refuses to issue you a service ticket for a principal with > REQUIRES_PRE_AUTH set if your TGT is not tagged as preauthenticated. But > I don't remember the details of the research that I did when I ran into > this. (We just cleared that flag from principals like host/* principals > and moved on with our lives; given that they're randomly generated keys, > hopefully brute force attacks are difficult anyway.) That matches my recollection, but I haven't examined the relevant code recently. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
