In my environment, kadmin/admin has Maximum ticket life: 0 days 03:00:00. Whilst the admin user of root/admin has Maximum ticket life: 0 days 00:01:00
It looks like the two has not related to what i experience (6 minutes) On Tue, Mar 26, 2019 at 3:47 PM Jeffrey Hutzelman <jh...@cmu.edu> wrote: > The max_life setting in kdc.conf is only a global maximum lifetime for any > ticket the KDC issues. The actual lifetime of issued tickets is also > affected by the client request, the maximum ticket lifetime settings on > both the client and service principals in the database, and (for TGS > requests), the expiration time of the existing TGT. > > > Examine the database entries for both kadmin/admin and your admin user. > > ------------------------------ > *From:* Yegui Cai <caiye...@gmail.com> > *Sent:* Tuesday, March 26, 2019 1:17 PM > *To:* Jeffrey Hutzelman > *Cc:* John Devitofranceschi; Greg Hudson; kerberos@mit.edu > *Subject:* Re: Admin session expiry > > 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