Pre-authentication is a security measure for user accounts because user's keys entropy is generally much lower as they are password derived and brute force attacks are much simpler. For services and hosts though, keys are completely random, so there is no need to use preauthentication, by dropping the requirement for those principals we can half the load on AS requests.
May make sense to add an option to ipa-getkeytab to set/clear pre-auth when a key is fetched, (set automatically if a password is used).
Related to #233 and #3859
3.4 development was shifted for one month, moving tickets to reflect reality better.
This bug is more important than previously thought.
Basically the problem is that the 'requires_preauth' flag in the MIT KDC is overloaded and means 2 different things on the client princ vs server princ of a AS_REQ or TGS_REQ. On the client princ it means that in order to perform an AS Request (to acquire a tgt or directly a ticket) you need preauthentication. At the same time if it is present on a server principal it means that a AS request or a TGS request will be denied if the client did not do preauthentication.
The problem is that if you need to turn preauth off for an application princiapl due to old software or whatever then side effects arise, including not beaing able to enforce that a client still need to do preauth to be able to get a ticket for said principal, but also that said application will be denied access to any other service that has the required_preauth flag on.
Because we do have it on by default for all principals it means that if someone really has a problem with preauth then he would have to go and manually change a ton of principals to let things work.
Replying to [comment:4 simo]:
This bug is more important than previously thought. Basically the problem is that the 'requires_preauth' flag in the MIT KDC is overloaded and means 2 different things on the client princ vs server princ of a AS_REQ or TGS_REQ. On the client princ it means that in order to perform an AS Request (to acquire a tgt or directly a ticket) you need preauthentication. At the same time if it is present on a server principal it means that a AS request or a TGS request will be denied if the client did not do preauthentication. The problem is that if you need to turn preauth off for an application princiapl due to old software or whatever then side effects arise, including not beaing able to enforce that a client still need to do preauth to be able to get a ticket for said principal, but also that said application will be denied access to any other service that has the required_preauth flag on. Because we do have it on by default for all principals it means that if someone really has a problem with preauth then he would have to go and manually change a ton of principals to let things work.
I am re-reading this comment and it seems that I am missing something. What are the conditions under which the preauth is actually undesirable and how frequent are those conditions? It seems that it might not be a big of a deal.
Simo, can you please help assess the priority of the ticket? Is it indeed a requirement for 3.4 or can it be pushed out?
Adjusting time plan - 3.4 development was postponed as we focused on 3.3.x testing and stabilization.
We reviewed this ticket together with Dmitri and Simo and decided to postpone it as we do not have enough resources to finish it within 4.0 time frame.
Simo, any chance you would be able to fix this one during FreeIPA 4.2 time frame, you are the best candidate :-)
From triage:
Is a stretch for 4.3.
Not a blocker for 4.3 release.
master:
ipa-4-3:
Metadata Update from @simo: - Issue assigned to simo - Issue set to the milestone: FreeIPA 4.3.1
Log in to comment on this ticket.