I’m having this problem as well. This is only happening on Ubuntu machines for me, the RedHat and CentOS machines don’t seem to have this issue. I was starting to think this might be a problem with Kerberos libraries or something, otherwise I can’t understand why it wouldn’t work only on Ubuntu.

 

I monitor when one of my servers loses contact with the AD by running a cron script every 10 minutes:

#!/bin/bash

 

HOST=`hostname`

TST=`kinit -k 'SERVERNAME $@AD.MYDOMAIN.COM' 2>&1`

if [ "$TST" != "" ]; then

    logger -p user.crit "SSSD AUTH ERROR: [$DATE] $TST on $HOST"

    DATE=`date`

    echo "[$DATE]" $TST>>/root/sssd-weirdness.txt

fi

 

I get back: [Wed Oct 28 15:50:01 CDT 2015] kinit: Preauthentication failed while getting initial credentials, right at 7 days after the last time I manually rejoined the server. Running ‘kinit –k’ is not working for me.

 

 

From: Andy Airey [mailto:airey.andy@gmail.com]
Sent: Tuesday, December 01, 2015 8:31 AM
To: End-user discussions about the System Security Services Daemon <sssd-users@lists.fedorahosted.org>
Subject: [SSSD-users]Re: Kerberos ticket renewal with AD

 

What I am experiencing is that I can use the machine for 7 days until the TGT in SSSD's ccache expires.

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