On Tue, Dec 01, 2015 at 07:02:53PM +0100, Andy Airey wrote:
Sumit,
So you mean the ticket in /var/lib/sss/db/ccache_example.com
and after 7days you have to re-join the domain? In this case I guess there is some strict AD policy applied which requires that the keytab has to be renewed at least every 7days otherwise it becomes invalid and cannot be re-used anymore.
Indeed, that is the case. However, the default "Maximum lifetime for user ticket renewal" is 7d [1]. And there is no such policy that I am aware of (I manage AD too, it hurts sometimes).
As recommended in other emails as well I would try to run 'msktutil
auto-update' in a daily cron jobs. I would expect that you have to use the --auto-update-interval option as well because by default msktutil updates the keytab only ever 30d (which is the default for AD clients) and cannot read the current value expected by AD because this is buried in a GPO.
I will try out 'msktutil' and be sure to report back. Although I don't know of anything changing machine passwords (except AD itself?).
It might just expire it.
Please note that this is completely unrelated to the ticket renewable
feature.
Sorry for the misunderstanding. It wasn't crystal clear to me. Can you confirm the following; SSSD does ask for a reneweable ticket *and* can renew a current TGT or service principal ticket. However, it cannot request a *new* TGT. Correct?
yes, but this workflow is for users which try to log in to the system. During authentication SSSD (if configured for Kerberos authentication) tired to get a TGT for the user and if configured tries to renew the ticket as long as a process of the user is still running on the system and the TGT is still renewable. For a user SSSD cannot request a new TGT on its own because this requires the user password which in general is not kept by SSSD for security reasons. Btw, service tickets cannot be renewed but a fresh one will be requested as long as the TGT is valid.
But, this is different for the machine password. The machine password is generated randomly during the join and hashes of the password are stored in the host keytab, by default /etc/krb5.keytab. The content of the keytab file is as good as a password and should be handled with the same care as a plain text password. With the keytab you can get a fresh TGT, just call 'kinit -k'. SSSD uses the keytab to get a TGT to e.g. be able to connect to the AD LDAP service which by default only allows authenticated access. If the TGT becomes invalid SSSD will just use the keytab again to get a fresh TGT, no renewal is involved here. If now the machine password expires on the server side SSSD depends on external tools like msktutil to renew it.
HTH
bye, Sumit
Thanks for the replies, this has been really helpful so far.
Kind Regards,
Andy
[1] https://technet.microsoft.com/nl-be/library/cc738673%28v=ws.10%29.aspx#w2k3t...
On 1 December 2015 at 18:15, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 03:30:32PM +0100, Andy Airey wrote:
What I am experiencing is that I can use the machine for 7 days until the TGT in SSSD's ccache expires.
So you mean the ticket in /var/lib/sss/db/ccache_example.com and after 7days you have to re-join the domain? In this case I guess there is some strict AD policy applied which requires that the keytab has to be renewed at least every 7days otherwise it becomes invalid and cannot be re-used anymore.
As recommended in other emails as well I would try to run 'msktutil auto-update' in a daily cron jobs. I would expect that you have to use the --auto-update-interval option as well because by default msktutil updates the keytab only ever 30d (which is the default for AD clients) and cannot read the current value expected by AD because this is buried in a GPO.
Please note that this is completely unrelated to the ticket renewable feature.
HTH
bye, Sumit
With "use" I mean:
- LDAP lookups with SASL-GSSAPI binds for automount maps and sudoRoles
- login to the machine both with GSSAPI and password
When the ticket expires, the connection to AD is gone completely. My understanding was that, with the krb5_renew* settings, this would be resolved.
It seems like I'm getting this wrong, but is there a way to get a new TGT (with new renew until) through SSSD? Cron 'kinit -k' every week? Doesn't sound like the right way to do it.
On 1 December 2015 at 15:13, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 02:59:02PM +0100, Andy Airey wrote:
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the
domain
and
be able to login after said limit/renewable_lifetime.
What do you mean by "keep the machine joined to the domain". I thought you were talking of TGTs for user principals.
If you want to get a fresh TGT (including a fresh renew until) for the host itself you can just use the keytab by calling
kinit -k
Can you describe your use-case in more details?
Thank you.
bye, Sumit
On 1 December 2015 at 14:11, Ondrej Valousek <
Ondrej.Valousek@s3group.com>
wrote:
Yes - I would only add one thing - if you are unhappy with the 7
days
limit, you can change default KDC settings in the domain policy for
your AD
(which defaults to 7 days). I have changed it to 14 days for
example.
O.
-----Original Message----- From: Sumit Bose [mailto:sbose@redhat.com] Sent: Tuesday, December 01, 2015 2:08 PM To: End-user discussions about the System Security Services Daemon
<
sssd-users@lists.fedorahosted.org> Subject: [SSSD-users]Re: Kerberos ticket renewal with AD
On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote: > I agree on the lifetime of 7 days, that's fine. > > What I want to achieve is that I do not have to manually kinit
the
> machine again. > So that our users kan keep logging on, even after 7 days. > I thought SSSD would do this for me. I cannot log in to each
server
> everytime to make sure a new krbtgt is there ... > > As per the manpage of kinit: > > > *-R* > > > > requests renewal of the ticket-granting ticket. Note that an
expired
> > ticket cannot be renewed, even if the ticket is still within
its
> > renewable life. > > > If SSSD does a kinit -R, it should get a new krbtgt with a new > expiration date that's 7 days ahead, right?
no, there are 2 different time. One is the plain lifetime of the
ticket
the other is the renewable lifetime which relate to option -l and
-r of
kinit respectively.
$ kinit -l 100s -r 200s admin Password for admin@IPA.DEVEL:
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:03:41 01.12.2015 14:05:19
krbtgt/IPA.DEVEL@IPA.DEVEL
renew until 01.12.2015 14:06:59$ kinit -R
$ klist Ticket cache: KEYRING:persistent:1000:1000 Default principal: admin@IPA.DEVEL
Valid starting Expires Service principal 01.12.2015 14:04:05 01.12.2015 14:05:43
krbtgt/IPA.DEVEL@IPA.DEVEL
renew until 01.12.2015 14:06:59As you can see the Expires time changes after 'kinit -R' but not
the
'renew until' time.
HTH
bye, Sumit
> > > > On 1 December 2015 at 13:26, John Hodrien <
J.H.Hodrien@leeds.ac.uk>
wrote: > > > On Tue, 1 Dec 2015, Andy Airey wrote: > > > > Hi, > >> > >> If I read the manpage http://linux.die.net/man/5/sssd-krb5 > >> correctly, the setting krb5_renew_interval suggests that the
krbtgt
> >> gets renewed. > >> > >> I thought this meant that the ticket gets renewed (a new
krbtgt is
> >> generated) before the 7 days come to an end. > >> Now, 7 days after kinit, we cannot log on tp the machine
anymore
> >> with our > >> krb5 credentials. > >> > > > > It'll get renewed regularly, as the valid lifetime of your
ticket
> > will be more like 10/12 hours. Just do a kinit, then klist,
and
see
> > what it tells you. > > You can ask for a longer life ticket, but AFAIK AD defaults to
a
max
> > of 7 days. A long life ticket isn't particularly nice from a > > security point of view either. > > > > If there is another way, please enlighten me :). > >> > > > > SSSD can renew until it can't. In your original post you
showed:
> > > > "renew until 12/07/15 13:16:40" > > > > You can renew until that point, but you're not allowed to get a > > credential valid after that point, so without a password you
can
> > feed to the KDC, or additional privs for the machine, you're
done
aren't you? > > > > It's doing nothing more than a kinit -R as I understand it, and
it's
> > bound by the same limitations. > > > > > > jh > > _______________________________________________ > > sssd-users mailing list > > sssd-users@lists.fedorahosted.org > > > >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho
> > sted.org > >
> _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost
> ed.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the
intended
recipient(s). If you are not an intended recipient, you must not
use,
disclose, copy, distribute or retain this e-mail or any part
thereof.
If
you have received this e-mail in error, please notify the sender by
return
e-mail and delete all copies of this e-mail from your computer
system(s).
Please direct any additional queries to:
communications@s3group.com.
Thank You. Silicon and Software Systems Limited (S3 Group).
Registered
in
Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
Hello list,
Just want to report back that the 'msktutil --auto-update' cron-job seems to have done the trick for me!
Thanks for the awesome work and support, guys.
Andy
On 2 December 2015 at 11:44, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 07:02:53PM +0100, Andy Airey wrote:
Sumit,
So you mean the ticket in /var/lib/sss/db/ccache_example.com
and after 7days you have to re-join the domain? In this case I guess there is
some
strict AD policy applied which requires that the keytab has to be renewed at least every 7days otherwise it becomes invalid and cannot be re-used anymore.
Indeed, that is the case. However, the default "Maximum lifetime for user ticket renewal" is 7d
[1].
And there is no such policy that I am aware of (I manage AD too, it hurts sometimes).
As recommended in other emails as well I would try to run 'msktutil
auto-update' in a daily cron jobs. I would expect that you have to use the --auto-update-interval option as well because by default msktutil updates the keytab only ever 30d (which is the default for AD clients) and cannot read the current value expected by AD because this is buried in a GPO.
I will try out 'msktutil' and be sure to report back. Although I don't know of anything changing machine passwords (except AD itself?).
It might just expire it.
Please note that this is completely unrelated to the ticket renewable
feature.
Sorry for the misunderstanding. It wasn't crystal clear to me. Can you confirm the following; SSSD does ask for a reneweable ticket
*and*
can renew a current TGT or service principal ticket. However, it cannot request a *new* TGT. Correct?
yes, but this workflow is for users which try to log in to the system. During authentication SSSD (if configured for Kerberos authentication) tired to get a TGT for the user and if configured tries to renew the ticket as long as a process of the user is still running on the system and the TGT is still renewable. For a user SSSD cannot request a new TGT on its own because this requires the user password which in general is not kept by SSSD for security reasons. Btw, service tickets cannot be renewed but a fresh one will be requested as long as the TGT is valid.
But, this is different for the machine password. The machine password is generated randomly during the join and hashes of the password are stored in the host keytab, by default /etc/krb5.keytab. The content of the keytab file is as good as a password and should be handled with the same care as a plain text password. With the keytab you can get a fresh TGT, just call 'kinit -k'. SSSD uses the keytab to get a TGT to e.g. be able to connect to the AD LDAP service which by default only allows authenticated access. If the TGT becomes invalid SSSD will just use the keytab again to get a fresh TGT, no renewal is involved here. If now the machine password expires on the server side SSSD depends on external tools like msktutil to renew it.
HTH
bye, Sumit
Thanks for the replies, this has been really helpful so far.
Kind Regards,
Andy
[1]
https://technet.microsoft.com/nl-be/library/cc738673%28v=ws.10%29.aspx#w2k3t...
On 1 December 2015 at 18:15, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 03:30:32PM +0100, Andy Airey wrote:
What I am experiencing is that I can use the machine for 7 days
until the
TGT in SSSD's ccache expires.
So you mean the ticket in /var/lib/sss/db/ccache_example.com and after 7days you have to re-join the domain? In this case I guess there is
some
strict AD policy applied which requires that the keytab has to be renewed at least every 7days otherwise it becomes invalid and cannot be re-used anymore.
As recommended in other emails as well I would try to run 'msktutil auto-update' in a daily cron jobs. I would expect that you have to use the --auto-update-interval option as well because by default msktutil updates the keytab only ever 30d (which is the default for AD clients) and cannot read the current value expected by AD because this is buried in a GPO.
Please note that this is completely unrelated to the ticket renewable feature.
HTH
bye, Sumit
With "use" I mean:
- LDAP lookups with SASL-GSSAPI binds for automount maps and
sudoRoles
- login to the machine both with GSSAPI and password
When the ticket expires, the connection to AD is gone completely. My understanding was that, with the krb5_renew* settings, this would
be
resolved.
It seems like I'm getting this wrong, but is there a way to get a
new TGT
(with new renew until) through SSSD? Cron 'kinit -k' every week? Doesn't sound like the right way to do
it.
On 1 December 2015 at 15:13, Sumit Bose sbose@redhat.com wrote:
On Tue, Dec 01, 2015 at 02:59:02PM +0100, Andy Airey wrote:
I don't mind the limit as such. I'm just looking to see how I can keep the machine joined to the
domain
and
be able to login after said limit/renewable_lifetime.
What do you mean by "keep the machine joined to the domain". I
thought
you were talking of TGTs for user principals.
If you want to get a fresh TGT (including a fresh renew until) for
the
host itself you can just use the keytab by calling
kinit -k
Can you describe your use-case in more details?
Thank you.
bye, Sumit
On 1 December 2015 at 14:11, Ondrej Valousek <
Ondrej.Valousek@s3group.com>
wrote:
> Yes - I would only add one thing - if you are unhappy with the
7
days
> limit, you can change default KDC settings in the domain
policy for
your AD
> (which defaults to 7 days). I have changed it to 14 days for
example.
> O. > > -----Original Message----- > From: Sumit Bose [mailto:sbose@redhat.com] > Sent: Tuesday, December 01, 2015 2:08 PM > To: End-user discussions about the System Security Services
Daemon
<
> sssd-users@lists.fedorahosted.org> > Subject: [SSSD-users]Re: Kerberos ticket renewal with AD > > On Tue, Dec 01, 2015 at 01:42:26PM +0100, Andy Airey wrote: > > I agree on the lifetime of 7 days, that's fine. > > > > What I want to achieve is that I do not have to manually
kinit
the
> > machine again. > > So that our users kan keep logging on, even after 7 days. > > I thought SSSD would do this for me. I cannot log in to each
server
> > everytime to make sure a new krbtgt is there ... > > > > As per the manpage of kinit: > > > > > *-R* > > > > > > requests renewal of the ticket-granting ticket. Note that
an
expired
> > > ticket cannot be renewed, even if the ticket is still
within
its
> > > renewable life. > > > > > If SSSD does a kinit -R, it should get a new krbtgt with a
new
> > expiration date that's 7 days ahead, right? > > no, there are 2 different time. One is the plain lifetime of
the
ticket
> the other is the renewable lifetime which relate to option -l
and
-r of
> kinit respectively. > > $ kinit -l 100s -r 200s admin > Password for admin@IPA.DEVEL: > > $ klist > Ticket cache: KEYRING:persistent:1000:1000 Default principal: > admin@IPA.DEVEL > > Valid starting Expires Service principal > 01.12.2015 14:03:41 01.12.2015 14:05:19
krbtgt/IPA.DEVEL@IPA.DEVEL
> renew until 01.12.2015 14:06:59 > > $ kinit -R > > $ klist > Ticket cache: KEYRING:persistent:1000:1000 Default principal: > admin@IPA.DEVEL > > Valid starting Expires Service principal > 01.12.2015 14:04:05 01.12.2015 14:05:43
krbtgt/IPA.DEVEL@IPA.DEVEL
> renew until 01.12.2015 14:06:59 > > > As you can see the Expires time changes after 'kinit -R' but
not
the
> 'renew until' time. > > HTH > > bye, > Sumit > > > > > > > > > On 1 December 2015 at 13:26, John Hodrien <
J.H.Hodrien@leeds.ac.uk>
> wrote: > > > > > On Tue, 1 Dec 2015, Andy Airey wrote: > > > > > > Hi, > > >> > > >> If I read the manpage <
http://linux.die.net/man/5/sssd-krb5%3E
> > >> correctly, the setting krb5_renew_interval suggests that
the
krbtgt
> > >> gets renewed. > > >> > > >> I thought this meant that the ticket gets renewed (a new
krbtgt is
> > >> generated) before the 7 days come to an end. > > >> Now, 7 days after kinit, we cannot log on tp the machine
anymore
> > >> with our > > >> krb5 credentials. > > >> > > > > > > It'll get renewed regularly, as the valid lifetime of your
ticket
> > > will be more like 10/12 hours. Just do a kinit, then
klist,
and
see
> > > what it tells you. > > > You can ask for a longer life ticket, but AFAIK AD
defaults to
a
max
> > > of 7 days. A long life ticket isn't particularly nice
from a
> > > security point of view either. > > > > > > If there is another way, please enlighten me :). > > >> > > > > > > SSSD can renew until it can't. In your original post you
showed:
> > > > > > "renew until 12/07/15 13:16:40" > > > > > > You can renew until that point, but you're not allowed to
get a
> > > credential valid after that point, so without a password
you
can
> > > feed to the KDC, or additional privs for the machine,
you're
done
> aren't you? > > > > > > It's doing nothing more than a kinit -R as I understand
it, and
it's
> > > bound by the same limitations. > > > > > > > > > jh > > > _______________________________________________ > > > sssd-users mailing list > > > sssd-users@lists.fedorahosted.org > > > > > >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho
> > > sted.org > > > > > > _______________________________________________ > > sssd-users mailing list > > sssd-users@lists.fedorahosted.org > >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost
> > ed.org > _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org > >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
> ----- > > The information contained in this e-mail and in any
attachments is
> confidential and is designated solely for the attention of the
intended
> recipient(s). If you are not an intended recipient, you must
not
use,
> disclose, copy, distribute or retain this e-mail or any part
thereof.
If
> you have received this e-mail in error, please notify the
sender by
return
> e-mail and delete all copies of this e-mail from your computer
system(s).
> Please direct any additional queries to:
communications@s3group.com.
> Thank You. Silicon and Software Systems Limited (S3 Group).
Registered
in
> Ireland no. 378073. Registered Office: South County Business
Park,
> Leopardstown, Dublin 18. > _______________________________________________ > sssd-users mailing list > sssd-users@lists.fedorahosted.org > >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
>
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Andy Airey -
Sumit Bose