I did some experiments with admin session expiration. The sessions expires within around 6 minutes no matter what is set in max_life in kdc.conf. My guess is it is some hard coded value in KDC source code determines the expiry.
On Mon, Mar 11, 2019 at 11:55 AM Jeffrey Hutzelman <jh...@cmu.edu> wrote: > 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> 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> >> Sent: Sunday, January 13, 2019 10:34 >> To: Greg Hudson >> Cc: kerberos@mit.edu >> Subject: Re: Admin session expiry >> >> On Jan 13, 2019, at 1:49 AM, Greg Hudson <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 >> > 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 >> https://mailman.mit.edu/mailman/listinfo/kerberos >> ________________________________________________ >> Kerberos mailing list Kerberos@mit.edu >> https://mailman.mit.edu/mailman/listinfo/kerberos >> > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
