Admin session expiry

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Admin session expiry

Yegui Cai
Hi all.

Is there a way to configure KDC so that the admin session will expire if it
keeps inactive for a period of time?

Thanks,
YC
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Greg Hudson
On 12/28/18 12:07 PM, Yegui Cai wrote:
> Is there a way to configure KDC so that the admin session will expire if it
> keeps inactive for a period of time?

There is not.  However, if more than 45 connections are active at one
time, kadmind will kick out the least recently used connection.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Yegui Cai
Thanks for the info.

On Wed, Jan 2, 2019 at 11:30 AM Greg Hudson <[hidden email]> wrote:

> On 12/28/18 12:07 PM, Yegui Cai wrote:
> > Is there a way to configure KDC so that the admin session will expire if
> it
> > keeps inactive for a period of time?
>
> There is not.  However, if more than 45 connections are active at one
> time, kadmind will kick out the least recently used connection.
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Yegui Cai
In reply to this post by Greg Hudson
Hi Greg.
Any plan to add the capability of expiring admin sessions into a future
release?
Thanks!
Yegui

On Wed, Jan 2, 2019 at 11:30 AM Greg Hudson <[hidden email]> wrote:

> On 12/28/18 12:07 PM, Yegui Cai wrote:
> > Is there a way to configure KDC so that the admin session will expire if
> it
> > keeps inactive for a period of time?
>
> There is not.  However, if more than 45 connections are active at one
> time, kadmind will kick out the least recently used connection.
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Greg Hudson
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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

John Devitofranceschi
On Jan 13, 2019, at 1:49 AM, Greg Hudson <[hidden email]> 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           [hidden email]
> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Jeffrey Hutzelman
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 <[hidden email]>
Sent: Sunday, January 13, 2019 10:34
To: Greg Hudson
Cc: [hidden email]
Subject: Re: Admin session expiry

On Jan 13, 2019, at 1:49 AM, Greg Hudson <[hidden email]> 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           [hidden email]
> 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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Yegui Cai
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 <[hidden email]> 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 <[hidden email]>
> Sent: Sunday, January 13, 2019 10:34
> To: Greg Hudson
> Cc: [hidden email]
> Subject: Re: Admin session expiry
>
> On Jan 13, 2019, at 1:49 AM, Greg Hudson <[hidden email]> 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           [hidden email]
> > 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           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Jeffrey Hutzelman
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 <[hidden email]>
Sent: Monday, March 11, 2019 11:42
To: Jeffrey Hutzelman
Cc: John Devitofranceschi; Greg Hudson; [hidden email]
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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>>
Sent: Sunday, January 13, 2019 10:34
To: Greg Hudson
Cc: [hidden email]<mailto:[hidden email]>
Subject: Re: Admin session expiry

On Jan 13, 2019, at 1:49 AM, Greg Hudson <[hidden email]<mailto:[hidden email]>> 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           [hidden email]<mailto:[hidden email]>
> 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           [hidden email]<mailto:[hidden email]>
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list           [hidden email]<mailto:[hidden email]>
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Yegui Cai
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 <[hidden email]> 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 <[hidden email]>
> *Sent:* Monday, March 11, 2019 11:42
> *To:* Jeffrey Hutzelman
> *Cc:* John Devitofranceschi; Greg Hudson; [hidden email]
> *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 <[hidden email]> 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 <[hidden email]>
>> Sent: Sunday, January 13, 2019 10:34
>> To: Greg Hudson
>> Cc: [hidden email]
>> Subject: Re: Admin session expiry
>>
>> On Jan 13, 2019, at 1:49 AM, Greg Hudson <[hidden email]> 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           [hidden email]
>> > 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           [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>> ________________________________________________
>> Kerberos mailing list           [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

Jeffrey Hutzelman
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 <[hidden email]>
Sent: Tuesday, March 26, 2019 1:17 PM
To: Jeffrey Hutzelman
Cc: John Devitofranceschi; Greg Hudson; [hidden email]
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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>>
Sent: Monday, March 11, 2019 11:42
To: Jeffrey Hutzelman
Cc: John Devitofranceschi; Greg Hudson; [hidden email]<mailto:[hidden email]>
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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>>
Sent: Sunday, January 13, 2019 10:34
To: Greg Hudson
Cc: [hidden email]<mailto:[hidden email]>
Subject: Re: Admin session expiry

On Jan 13, 2019, at 1:49 AM, Greg Hudson <[hidden email]<mailto:[hidden email]>> 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           [hidden email]<mailto:[hidden email]>
> 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           [hidden email]<mailto:[hidden email]>
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list           [hidden email]<mailto:[hidden email]>
https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Admin session expiry

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