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(a)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(a)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(a)IPA.DEVEL:
>
> $ klist
> Ticket cache: KEYRING:persistent:1000:1000 Default principal:
> admin(a)IPA.DEVEL
>
> Valid starting Expires Service principal
> 01.12.2015 14:03:41 01.12.2015 14:05:19 krbtgt/IPA.DEVEL(a)IPA.DEVEL
> renew until 01.12.2015 14:06:59
>
> $ kinit -R
>
> $ klist
> Ticket cache: KEYRING:persistent:1000:1000 Default principal:
> admin(a)IPA.DEVEL
>
> Valid starting Expires Service principal
> 01.12.2015 14:04:05 01.12.2015 14:05:43 krbtgt/IPA.DEVEL(a)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(a)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(a)lists.fedorahosted.org
> > >
> > >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedoraho
> > >
sted.org
> > >
>
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org
> >
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahost
> >
ed.org
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)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(a)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(a)lists.fedorahosted.org
>
>
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org
>
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org