[SSSD-users] Re: Kerberos ticket renewal with AD

[Andy Airey]

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&gt; 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&gt; 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&gt; 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&gt;
>  > > > > > 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:[e-mail]]
>  > > > > > > Sent: Tuesday, December 01, 2015 2:08 PM
>  > > > > > > To: End-user discussions about the System Security
> Services
>  Daemon
>  > > <
>  > > > > > > sssd-users(a)lists.fedorahosted.org&gt;
>  > > > > > > 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&gt;
>  > > > > > > 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/[e-mail]
>  > > > > > > > > sted.org
>  > > > > > > > >
>  > > > > > >
>  > > > > > > > _______________________________________________
>  > > > > > > > sssd-users mailing list
>  > > > > > > > sssd-users(a)lists.fedorahosted.org
>  > > > > > > >
>  > > > >
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>  > > > > > > > ed.org
>  > > > > > > _______________________________________________
>  > > > > > > sssd-users mailing list
>  > > > > > > sssd-users(a)lists.fedorahosted.org
>  > > > > > >
>  > > > > > >
>  > > > >
>  > >
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>  > > > > > > -----
>  > > > > > >
>  > > > > > > 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/[e-mail]
>  > > > > > >
>  > > > >
>  > > > > > _______________________________________________
>  > > > > > sssd-users mailing list
>  > > > > > sssd-users(a)lists.fedorahosted.org
>  > > > > >
>  > > > >
>  > >
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>  > > > > _______________________________________________
>  > > > > sssd-users mailing list
>  > > > > sssd-users(a)lists.fedorahosted.org
>  > > > >
>  > > > >
>  > >
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>  > > > >
>  > >
>  > > > _______________________________________________
>  > > > sssd-users mailing list
>  > > > sssd-users(a)lists.fedorahosted.org
>  > > >
>  > >
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>  > > _______________________________________________
>  > > sssd-users mailing list
>  > > sssd-users(a)lists.fedorahosted.org
>  > >
>  > >
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>  > >
>
>  > _______________________________________________
>  > sssd-users mailing list
>  > sssd-users(a)lists.fedorahosted.org
>  >
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>
>  https://lists.fedorahosted.org/admin/lists/[e-mail]
>