Is there any reason I wouldn't want +requires_preauth on any user
accounts? It looks like it doubles the number of connections to the KDC
to get the tgt, but besides that additional load, is there any downside
to doing it?
Thanks,
Chris
On Tue, 2011-07-19 at 13:46 -0400, Chris Hecker wrote:
Is there any reason I wouldn't want +requires_preauth on any user
accounts? It looks like it doubles the number of connections to the KDC
to get the tgt, but besides that additional load, is there any downside
to doing it?
Short
On Tue, Jul 19, 2011 at 12:39 PM, Greg Hudson ghud...@mit.edu wrote:
The best practice is to set +requires-preauth (and probably
-allow_tgs_req) on principals with password-derived keys and leave it
unset on principals with random keys.
I thought the best practice would be to set
On Tue, Jul 19, 2011 at 2:01 PM, Ken Dreyer ktdre...@ktdreyer.com wrote:
On Tue, Jul 19, 2011 at 12:39 PM, Greg Hudson ghud...@mit.edu wrote:
The best practice is to set +requires-preauth (and probably
-allow_tgs_req) on principals with password-derived keys and leave it
unset on principals
On Tue, 2011-07-19 at 15:01 -0400, Ken Dreyer wrote:
I thought the best practice would be to set requires-preauth on
every principal? I don't want to give someone the ability to offline
attack any of my principals...
If I can successfully offline attack a random key, I'll just make a TGS
On Jul 14, 2011, at 9:40 AM, Greg Hudson wrote:
On Wed, 2011-07-13 at 15:33 -0400, Benjamin Coddington wrote:
Anyway, calling gss_accept_sec_context this way allows svcgssd to
create a context for any requested service name -- but the problem we
found is that svcgssd opens the kerberos replay
Ken Dreyer ktdre...@ktdreyer.com writes:
On Tue, Jul 19, 2011 at 12:39 PM, Greg Hudson ghud...@mit.edu wrote:
The best practice is to set +requires-preauth (and probably
-allow_tgs_req) on principals with password-derived keys and leave it
unset on principals with random keys.
I thought the
On Tue, 2011-07-19 at 16:21 -0400, Benjamin Coddington wrote:
gss_acquire_cred
gss_accept_sec_context
gss_export_lucid_sec_context
gss_delete_sec_context
I found that before we got to gss_delete_sec_context(), we had already
tried to clean up the context in
