No, kadmin is never authenticated by a password. It's a Kerberos-authenticated service and generally requires initial tickets, which means you can't use a tgt to get a ticket for it. Instead, in the usual case, the kadmin client will obtain an initial ticket for kadmin/admin, for which purpose it generally needs to prompt you for a password. The ticket it obtains is kept in memory and not ever written to a file where you can see it, but it does exist. And, like all tickets, it has a lifetime.
________________________________ From: Yegui Cai <caiye...@gmail.com> Sent: Monday, March 11, 2019 11:42 To: Jeffrey Hutzelman Cc: John Devitofranceschi; Greg Hudson; kerberos@mit.edu Subject: Re: Admin session expiry Hi Jeffrey. I did some experiments with kadmin. It looks like by default, remote admin sessions are authenticated with admin password. And in that case, the sessions will never expired because there is no tickets in the system. Does it mean I need to disable kadmin password authentication? if it is do-able? Thanks, Yegui On Sun, Jan 13, 2019 at 11:33 AM Jeffrey Hutzelman <jh...@cmu.edu<mailto:jh...@cmu.edu>> wrote: It's not necessary to disable the admin principal or expire the session to get this effect. The admin service is itself a Kerberos-authenticated service, and Kerberos tickets expire. Without valid tickets for the admin service, it is not possible to make a request, regardless of whether or not you happen to have a TCP connection open to the server. By setting the max ticket lifetime for admin principals and/or the kadmin/admin service principal, you can limit the time these tickets are valid, and this the time during which it is possible to make admin requests. -- Jeff ________________________________ From: John Devitofranceschi <j...@optonline.net<mailto:j...@optonline.net>> Sent: Sunday, January 13, 2019 10:34 To: Greg Hudson Cc: kerberos@mit.edu<mailto:kerberos@mit.edu> Subject: Re: Admin session expiry On Jan 13, 2019, at 1:49 AM, Greg Hudson <ghud...@mit.edu<mailto:ghud...@mit.edu>> wrote: > > On 1/11/19 11:08 AM, Yegui Cai wrote: >> Any plan to add the capability of expiring admin sessions into a future >> release? > > We can consider it, although it would come at a complexity cost in the > network code. Can you describe why that feature is important in your > deployment? > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu<mailto:Kerberos@mit.edu> > https://mailman.mit.edu/mailman/listinfo/kerberos Banks and other highly regulated environments have requirements to implement controls around the access of individuals to systems and data. This includes “just in time” access provisioning and time-bound access to sensitive systems. For a detailed example, see ch. 11.1 of the Monetary Authority of Singapore’s “Technology Risk Management Guidelines” (TRM Guidelines <http://www.mas.gov.sg/~/media/MAS/Regulations%20and%20Financial%20Stability/Regulatory%20and%20Supervisory%20Framework/Risk%20Management/TRM%20Guidelines%20%2021%20June%202013.pdf>) "The [Financial Institution] should only grant user access to IT systems and networks on a need-to-use basis and within the period when the access is required.” Now, these kinds of things are often vague and you can probably satisfy the requirements in a number of ways. You *could* whack the admin session at the network level OR you *could* expire the admin principal that was used to authenticate the session (in an out of band process that’s been set up to manage such access) and demonstrate that even with a connected admin session the expired principal renders the session useless. One of the key points for such controls is being able to provide evidence that the control is being met since it is not sufficient to do the right thing, you have to also be able to *prove* that you’re doing the right thing. This is another can of worms entirely. jd ________________________________________________ Kerberos mailing list Kerberos@mit.edu<mailto:Kerberos@mit.edu> https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu<mailto:Kerberos@mit.edu> https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
