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#w2k3tr_kerb_tools_nwcz
>
>
> 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>
> > > > > > > >> 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