Admin session expiry

Yegui Cai caiyegui at gmail.com
Mon Mar 11 11:42:25 EDT 2019


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