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(a)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#w2...
>
>
> On 1 December 2015 at 18:15, Sumit Bose <sbose(a)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(a)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(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
> > > > _______________________________________________
> > > > 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
> > _______________________________________________
> > 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
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/admin/lists/sssd-users@lists.fedorahosted.org