From: kerberos-boun...@mit.edu <kerberos-boun...@mit.edu> on behalf of Robbie Harwood <rharw...@redhat.com>
Sent: Thursday, January 10, 2019 2:18 PM To: Grant Taylor; kerberos@mit.edu Subject: Re: Kerberos n00b question. Grant Taylor <gtay...@tnetconsulting.net> writes: >> You don't have to recreate them, but yes, it's a good idea to set >> +requires_preauth. Setting -allow_svr will I believe block the use >> of U2U and make kvno on user principals no longer work, but this may >> be acceptable to you > > I need to do some more reading on what user-to-user and kvno are to know > if I care about them. kvno is a number associated with each principal that keeps track of how many times it's been rekeyed (password change and the like). It's useful for debugging to be able to access this information, but you can also get it out of kadmin. In this case, the thing that won't work is the 'kvno' program, which obtains and displays the kvno of a principal by fetching a ticket with that principal as the service, and then looking at the kvno in the resulting ticket. Naturally, that won't work for things which you've flagged not to be usable as services. U2U, on the other hand, will work just fine. It doesn't require allow_svr on either user, because it works by using the session key from a TGT belonging to the target user, rather than by using that user's long-term key from the kdb. > The little bit of reading that I just did on key version number (kvno) > sounds unrelated to servers / services (what I think of with allow_svr). > I need to do more reading. The kvno(1) tool works by acquiring a service ticket to the given principal. So for instance, asking `kvno rharw...@fedoraproject.org` acquires for rharw...@fedoraproject.org and then inspects the kvno on the result. Yes, exactly this. Of course, in a small installation where you're also the Kerberos admin, you can just use kadmin to examine a principal and find out its kvno. > On the surface, I think I'd like to keep kvno functional. > > Would -allow_svr have any impact on protocol translation? (I think > that's the term.) I.e. when a non-Kerberos aware client logs into IMAPS > with username & password and the daemon translates / gateways / bridges > into Kerberos on the client's behalf? (I saw something about that in > one of the first three videos I mentioned in a previous message.) I don't believe so (but I haven't actually checked). No, that use case will work just fine. But you should avoid it when you can, since one of Kerberos's main advantages is that you don't ever have to give application servers your password (or anything they could use to impersonate you). -- Jeff ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
