Admin session expiry

Yegui Cai caiyegui at gmail.com
Tue Mar 26 15:53:09 EDT 2019


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 <jhutz at 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 <caiyegui at gmail.com>
> *Sent:* Tuesday, March 26, 2019 1:17 PM
> *To:* Jeffrey Hutzelman
> *Cc:* John Devitofranceschi; Greg Hudson; kerberos at 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 <jhutz at 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 <caiyegui at gmail.com>
>> *Sent:* Monday, March 11, 2019 11:42
>> *To:* Jeffrey Hutzelman
>> *Cc:* John Devitofranceschi; Greg Hudson; kerberos at 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 <jhutz at 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 <jdvf at optonline.net>
>>> Sent: Sunday, January 13, 2019 10:34
>>> To: Greg Hudson
>>> Cc: kerberos at mit.edu
>>> Subject: Re: Admin session expiry
>>>
>>> On Jan 13, 2019, at 1:49 AM, Greg Hudson <ghudson at 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 at 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 at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>> ________________________________________________
>>> Kerberos mailing list           Kerberos at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>


More information about the Kerberos mailing list