KRB5CCNAME variable broken in second concurrent login shell - bug?

[Joschi Brauchle]

We have a weird problem with the KRB5CCNAME environment variable that 
seems to be an SSSD bug.

Configuration:
------------ /etc/sssd/sssd.conf ------------
...
# Set CCache to Kerberos default
krb5_ccachedir = /run/user/%U
krb5_ccname_template = DIR:%d/krb5cc
...
------------ /etc/sssd/sssd.conf ------------

Now, user "ne96soh" logs in to the machine for the FIRST time and does a 
kerberized ldapsearch:
------------
ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
DIR:/run/user/3036404/krb5cc
ne96soh@tueilnt-student01:~$ klist
Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
...
ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
... <succeeds>
------------

but then logs into the machine a SECOND concurrent time (i.e. leaving 
first session open):
------------
ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
DIR::/run/user/3036404/krb5cc/tktZoweZq
ne96soh@tueilnt-student01:~$ klist
Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
...
ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
         additional info: SASL(-1): generic failure: GSSAPI Error: 
Unspecified GSS failure.  Minor code may provide more information (No 
Kerberos credentials available)
------------

For me, the format of 'DIR::/run/user/3036404/krb5cc/tktZoweZq' in the 
second login seems strange! Is this a valid format?

When I manuelly reset the KRB5CCNAME variable in the second login shell 
to its original value 'DIR:/run/user/3036404/krb5cc', then the 
ldapsearch using GSSAPI succeeds.

The reason of all this seems to be that SSSD reuses existing ccaches for 
already logged on users, but possibly mixes up formats there.
See
------------ /var/log/sssd_default.log ------------
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_auth_send] 
(0x4000): Ccache_file is [DIR::/run/user/3036404/krb5cc/tktZoweZq] and 
is  active and TGT is  valid.
...
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_find_ccache_step] 
(0x0080): Saved ccache DIR::/run/user/3036404/krb5cc/tktZoweZq if of 
different type than ccache in configuration file, reusing the old ccache
...
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]] 
[safe_remove_old_ccache_file] (0x0400): New and old ccache file are the 
same, no one will be deleted.
(Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_mod_ccname] 
(0x4000): Save ccname [DIR::/run/user/3036404/krb5cc/tktZoweZq] for user 
[ne96soh].
------------ /var/log/sssd_default.log ------------

Best regards,

[Lukas Slebodnik]

On (15/10/14 14:37), Joschi Brauchle wrote:
> We have a weird problem with the KRB5CCNAME environment variable that seems
> to be an SSSD bug.
>
> Configuration:
> ------------ /etc/sssd/sssd.conf ------------
> ...
> # Set CCache to Kerberos default
> krb5_ccachedir = /run/user/%U
> krb5_ccname_template = DIR:%d/krb5cc
> ...
> ------------ /etc/sssd/sssd.conf ------------
>
> Now, user "ne96soh" logs in to the machine for the FIRST time and does a
> kerberized ldapsearch:
>
> ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> DIR:/run/user/3036404/krb5cc
> ne96soh@tueilnt-student01:~$ klist
> Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> ...
> ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> ... <succeeds>
>
> but then logs into the machine a SECOND concurrent time (i.e. leaving first
> session open):
>
> ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> DIR::/run/user/3036404/krb5cc/tktZoweZq
> ne96soh@tueilnt-student01:~$ klist
> Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> ...

Which version of sssd do you use?
IIRC, We forced to store "DIR:/run/user/3036404/krb5cc/" into our internal
cache.

LS

BTW "DIR::/run/user/3036404/krb5cc/tktZoweZq" is valid ccache string. It means
you use just one ccache from colection.

This version "DIR:/run/user/3036404/krb5cc/" means that any ccache which is
stored in ccache collection (directory "/run/user/3036404/krb5cc/" can be used)
As first ccache would be used primary ccache.

With KRB5CCNAME="DIR:/run/user/3036404/krb5cc/" you can call "klist -l"
and you will see all ccaches stored in this directory.

[Joschi Brauchle]

On 10/15/2014 02:58 PM, Lukas Slebodnik wrote:
> On (15/10/14 14:37), Joschi Brauchle wrote:
> > We have a weird problem with the KRB5CCNAME environment variable that seems
> > to be an SSSD bug.
> >
> > Configuration:
> > ------------ /etc/sssd/sssd.conf ------------
> > ...
> > # Set CCache to Kerberos default
> > krb5_ccachedir = /run/user/%U
> > krb5_ccname_template = DIR:%d/krb5cc
> > ...
> > ------------ /etc/sssd/sssd.conf ------------
> >
> > Now, user "ne96soh" logs in to the machine for the FIRST time and does a
> > kerberized ldapsearch:
> >
> > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > DIR:/run/user/3036404/krb5cc
> > ne96soh@tueilnt-student01:~$ klist
> > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > ...
> > ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> > ... <succeeds>
> >
> > but then logs into the machine a SECOND concurrent time (i.e. leaving first
> > session open):
> >
> > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > DIR::/run/user/3036404/krb5cc/tktZoweZq
> > ne96soh@tueilnt-student01:~$ klist
> > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > ...
>
> Which version of sssd do you use?
> IIRC, We forced to store "DIR:/run/user/3036404/krb5cc/" into our internal
> cache.
>
> LS
>
> BTW "DIR::/run/user/3036404/krb5cc/tktZoweZq" is valid ccache string. It means
> you use just one ccache from colection.
>
> This version "DIR:/run/user/3036404/krb5cc/" means that any ccache which is
> stored in ccache collection (directory "/run/user/3036404/krb5cc/" can be used)
> As first ccache would be used primary ccache.
>
> With KRB5CCNAME="DIR:/run/user/3036404/krb5cc/" you can call "klist -l"
> and you will see all ccaches stored in this directory.

Sorry for not specifying the SSSD version.
It is 1.9.6 (fairly old, I know).

So if "DIR::/run/user/3036404/krb5cc/tktZoweZq" is a valid ccache file, 
why does the kerberized ldapsearch fail then?

I am guessing that ldapsearch just calls some other library (sasl?) to 
get the krb credentials. Hence, somewhere along the chain this 
"DIR::/run/user/3036404/krb5cc/tktZoweZq" is not accepted...

[Lukas Slebodnik]

On (15/10/14 17:00), Joschi Brauchle wrote:
> On 10/15/2014 02:58 PM, Lukas Slebodnik wrote:
> > On (15/10/14 14:37), Joschi Brauchle wrote:
> > > We have a weird problem with the KRB5CCNAME environment variable that seems
> > > to be an SSSD bug.
> > >
> > > Configuration:
> > > ------------ /etc/sssd/sssd.conf ------------
> > > ...
> > > # Set CCache to Kerberos default
> > > krb5_ccachedir = /run/user/%U
> > > krb5_ccname_template = DIR:%d/krb5cc
> > > ...
> > > ------------ /etc/sssd/sssd.conf ------------
> > >
> > > Now, user "ne96soh" logs in to the machine for the FIRST time and does a
> > > kerberized ldapsearch:
> > >
> > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > DIR:/run/user/3036404/krb5cc
> > > ne96soh@tueilnt-student01:~$ klist
> > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > ...
> > > ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> > > ... <succeeds>
> > >
> > > but then logs into the machine a SECOND concurrent time (i.e. leaving first
> > > session open):
> > >
> > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > ne96soh@tueilnt-student01:~$ klist
> > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > ...
> >
> > Which version of sssd do you use?
> > IIRC, We forced to store "DIR:/run/user/3036404/krb5cc/" into our internal
> > cache.
> >
> > LS
> >
> > BTW "DIR::/run/user/3036404/krb5cc/tktZoweZq" is valid ccache string. It means
> > you use just one ccache from colection.
> >
> > This version "DIR:/run/user/3036404/krb5cc/" means that any ccache which is
> > stored in ccache collection (directory "/run/user/3036404/krb5cc/" can be used)
> > As first ccache would be used primary ccache.
> >
> > With KRB5CCNAME="DIR:/run/user/3036404/krb5cc/" you can call "klist -l"
> > and you will see all ccaches stored in this directory.
>
> Sorry for not specifying the SSSD version.
> It is 1.9.6 (fairly old, I know).

old but should be stable :-)
> So if "DIR::/run/user/3036404/krb5cc/tktZoweZq" is a valid ccache file, why
> does the kerberized ldapsearch fail then?
>
> I am guessing that ldapsearch just calls some other library (sasl?) to get
> the krb credentials. Hence, somewhere along the chain this
> "DIR::/run/user/3036404/krb5cc/tktZoweZq" is not accepted...

Here is an upstream ticket
https://fedorahosted.org/sssd/ticket/2002

The patch was backported just to the branch sssd-1.10 and never into sssd-1.9
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=f65eb572cbc8796fefaad5...

If you want you can patch it yourself.

LS

[Jakub Hrozek]

On Wed, Oct 15, 2014 at 05:45:39PM +0200, Lukas Slebodnik wrote:
> On (15/10/14 17:00), Joschi Brauchle wrote:
> > On 10/15/2014 02:58 PM, Lukas Slebodnik wrote:
> > > On (15/10/14 14:37), Joschi Brauchle wrote:
> > > > We have a weird problem with the KRB5CCNAME environment variable that seems
> > > > to be an SSSD bug.
> > > >
> > > > Configuration:
> > > > ------------ /etc/sssd/sssd.conf ------------
> > > > ...
> > > > # Set CCache to Kerberos default
> > > > krb5_ccachedir = /run/user/%U
> > > > krb5_ccname_template = DIR:%d/krb5cc
> > > > ...
> > > > ------------ /etc/sssd/sssd.conf ------------
> > > >
> > > > Now, user "ne96soh" logs in to the machine for the FIRST time and does a
> > > > kerberized ldapsearch:
> > > >
> > > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > > DIR:/run/user/3036404/krb5cc
> > > > ne96soh@tueilnt-student01:~$ klist
> > > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > ...
> > > > ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> > > > ... <succeeds>
> > > >
> > > > but then logs into the machine a SECOND concurrent time (i.e. leaving first
> > > > session open):
> > > >
> > > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > > DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > ne96soh@tueilnt-student01:~$ klist
> > > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > ...
> > >
> > > Which version of sssd do you use?
> > > IIRC, We forced to store "DIR:/run/user/3036404/krb5cc/" into our internal
> > > cache.
> > >
> > > LS
> > >
> > > BTW "DIR::/run/user/3036404/krb5cc/tktZoweZq" is valid ccache string. It means
> > > you use just one ccache from colection.
> > >
> > > This version "DIR:/run/user/3036404/krb5cc/" means that any ccache which is
> > > stored in ccache collection (directory "/run/user/3036404/krb5cc/" can be used)
> > > As first ccache would be used primary ccache.
> > >
> > > With KRB5CCNAME="DIR:/run/user/3036404/krb5cc/" you can call "klist -l"
> > > and you will see all ccaches stored in this directory.
> >
> > Sorry for not specifying the SSSD version.
> > It is 1.9.6 (fairly old, I know).
>
> old but should be stable :-)
> > So if "DIR::/run/user/3036404/krb5cc/tktZoweZq" is a valid ccache file, why
> > does the kerberized ldapsearch fail then?
> >
> > I am guessing that ldapsearch just calls some other library (sasl?) to get
> > the krb credentials. Hence, somewhere along the chain this
> > "DIR::/run/user/3036404/krb5cc/tktZoweZq" is not accepted...
>
> Here is an upstream ticket
> https://fedorahosted.org/sssd/ticket/2002
>
> The patch was backported just to the branch sssd-1.10 and never into sssd-1.9
> https://git.fedorahosted.org/cgit/sssd.git/commit/?id=f65eb572cbc8796fefaad5...
>
> If you want you can patch it yourself.

Speaking of, our front pages still states the LTM release is 1.9.6.

While technically, this is true because we never announced that LTM from
now on is 1.11, it really doesn't reflect the reality either.

I suggest we should (after releasing the upcoming 1.12.x releases!) do a
1.9.7 with what's been commited to sssd-1-9 since 1.9.6, announce it's
the last 1.9 release and 1.11 is the new stable.

I also think that 1.11.7 is the first upstream release from sssd-1-11 that
could be compared to 1.9.6 quality-wise.

[Simo Sorce]

On Wed, 15 Oct 2014 18:16:46 +0200
Jakub Hrozek  wrote:
> Speaking of, our front pages still states the LTM release is 1.9.6.
>
> While technically, this is true because we never announced that LTM
> from now on is 1.11, it really doesn't reflect the reality either.
>
> I suggest we should (after releasing the upcoming 1.12.x releases!)
> do a 1.9.7 with what's been commited to sssd-1-9 since 1.9.6,
> announce it's the last 1.9 release and 1.11 is the new stable.
>
> I also think that 1.11.7 is the first upstream release from sssd-1-11
> that could be compared to 1.9.6 quality-wise.

+1

Simo.

[Joschi Brauchle]

On 10/15/2014 05:45 PM, Lukas Slebodnik wrote:
> On (15/10/14 17:00), Joschi Brauchle wrote:
> > On 10/15/2014 02:58 PM, Lukas Slebodnik wrote:
> > > On (15/10/14 14:37), Joschi Brauchle wrote:
> > > > We have a weird problem with the KRB5CCNAME environment variable that seems
> > > > to be an SSSD bug.
> > > >
> > > > Configuration:
> > > > ------------ /etc/sssd/sssd.conf ------------
> > > > ...
> > > > # Set CCache to Kerberos default
> > > > krb5_ccachedir = /run/user/%U
> > > > krb5_ccname_template = DIR:%d/krb5cc
> > > > ...
> > > > ------------ /etc/sssd/sssd.conf ------------
> > > >
> > > > Now, user "ne96soh" logs in to the machine for the FIRST time and does a
> > > > kerberized ldapsearch:
> > > >
> > > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > > DIR:/run/user/3036404/krb5cc
> > > > ne96soh@tueilnt-student01:~$ klist
> > > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > ...
> > > > ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> > > > ... <succeeds>
> > > >
> > > > but then logs into the machine a SECOND concurrent time (i.e. leaving first
> > > > session open):
> > > >
> > > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > > DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > ne96soh@tueilnt-student01:~$ klist
> > > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > ...
> > >
> > > Which version of sssd do you use?
> > > IIRC, We forced to store "DIR:/run/user/3036404/krb5cc/" into our internal
> > > cache.
> > >
> > > LS
> > >
> > > BTW "DIR::/run/user/3036404/krb5cc/tktZoweZq" is valid ccache string. It means
> > > you use just one ccache from colection.
> > >
> > > This version "DIR:/run/user/3036404/krb5cc/" means that any ccache which is
> > > stored in ccache collection (directory "/run/user/3036404/krb5cc/" can be used)
> > > As first ccache would be used primary ccache.
> > >
> > > With KRB5CCNAME="DIR:/run/user/3036404/krb5cc/" you can call "klist -l"
> > > and you will see all ccaches stored in this directory.
> >
> > Sorry for not specifying the SSSD version.
> > It is 1.9.6 (fairly old, I know).
>
> old but should be stable :-)
> > So if "DIR::/run/user/3036404/krb5cc/tktZoweZq" is a valid ccache file, why
> > does the kerberized ldapsearch fail then?
> >
> > I am guessing that ldapsearch just calls some other library (sasl?) to get
> > the krb credentials. Hence, somewhere along the chain this
> > "DIR::/run/user/3036404/krb5cc/tktZoweZq" is not accepted...
>
> Here is an upstream ticket
> https://fedorahosted.org/sssd/ticket/2002
>
> The patch was backported just to the branch sssd-1.10 and never into sssd-1.9
> https://git.fedorahosted.org/cgit/sssd.git/commit/?id=f65eb572cbc8796fefaad5...
>
> If you want you can patch it yourself.
>
> LS

I have ported the patch to 1.9.6. but still get the exact same behavior 
as described in the original email, unfortunately.

[Joschi Brauchle]

On 10/15/2014 06:31 PM, Joschi Brauchle wrote:
> On 10/15/2014 05:45 PM, Lukas Slebodnik wrote:
> > On (15/10/14 17:00), Joschi Brauchle wrote:
> > > On 10/15/2014 02:58 PM, Lukas Slebodnik wrote:
> > > > On (15/10/14 14:37), Joschi Brauchle wrote:
> > > > > We have a weird problem with the KRB5CCNAME environment variable
> > > > > that seems
> > > > > to be an SSSD bug.
> > > > >
> > > > > Configuration:
> > > > > ------------ /etc/sssd/sssd.conf ------------
> > > > > ...
> > > > > # Set CCache to Kerberos default
> > > > > krb5_ccachedir = /run/user/%U
> > > > > krb5_ccname_template = DIR:%d/krb5cc
> > > > > ...
> > > > > ------------ /etc/sssd/sssd.conf ------------
> > > > >
> > > > > Now, user "ne96soh" logs in to the machine for the FIRST time and
> > > > > does a
> > > > > kerberized ldapsearch:
> > > > >
> > > > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > > > DIR:/run/user/3036404/krb5cc
> > > > > ne96soh@tueilnt-student01:~$ klist
> > > > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > > ...
> > > > > ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> > > > > ... <succeeds>
> > > > >
> > > > > but then logs into the machine a SECOND concurrent time (i.e.
> > > > > leaving first
> > > > > session open):
> > > > >
> > > > > ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> > > > > DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > > ne96soh@tueilnt-student01:~$ klist
> > > > > Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> > > > > ...
> > > >
> > > > Which version of sssd do you use?
> > > > IIRC, We forced to store "DIR:/run/user/3036404/krb5cc/" into our
> > > > internal
> > > > cache.
> > > >
> > > > LS
> > > >
> > > > BTW "DIR::/run/user/3036404/krb5cc/tktZoweZq" is valid ccache
> > > > string. It means
> > > > you use just one ccache from colection.
> > > >
> > > > This version "DIR:/run/user/3036404/krb5cc/" means that any ccache
> > > > which is
> > > > stored in ccache collection (directory "/run/user/3036404/krb5cc/"
> > > > can be used)
> > > > As first ccache would be used primary ccache.
> > > >
> > > > With KRB5CCNAME="DIR:/run/user/3036404/krb5cc/" you can call "klist -l"
> > > > and you will see all ccaches stored in this directory.
> > >
> > > Sorry for not specifying the SSSD version.
> > > It is 1.9.6 (fairly old, I know).
> >
> > old but should be stable :-)
> > > So if "DIR::/run/user/3036404/krb5cc/tktZoweZq" is a valid ccache
> > > file, why
> > > does the kerberized ldapsearch fail then?
> > >
> > > I am guessing that ldapsearch just calls some other library (sasl?)
> > > to get
> > > the krb credentials. Hence, somewhere along the chain this
> > > "DIR::/run/user/3036404/krb5cc/tktZoweZq" is not accepted...
> >
> > Here is an upstream ticket
> > https://fedorahosted.org/sssd/ticket/2002
> >
> > The patch was backported just to the branch sssd-1.10 and never into
> > sssd-1.9
> > https://git.fedorahosted.org/cgit/sssd.git/commit/?id=f65eb572cbc8796fefaad5...
> >
> > If you want you can patch it yourself.
> >
> > LS
>
> I have ported the patch to 1.9.6. but still get the exact same behavior
> as described in the original email, unfortunately.

I have dug up
https://fedorahosted.org/sssd/ticket/1936
which exactly fits my problem description and contains patches to sssd
> 1.10:

d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
d673bd397f1ed8239b36a5134bcd29914b11ae72
fa3cdcff460d555f4a4905fb0a2d96be564fc599

Unfortunately the last one does not apply successful to sssd 1.9.6, 
which is where my clumsy efforts are reaching their time limitation.

Could these patches be possibly backported to a new/final 1.9.7 version 
for me to test?

Best regards,
Joschi Brauchle

[Jakub Hrozek]

On Wed, Oct 15, 2014 at 11:41:47PM +0200, Joschi Brauchle wrote:
> d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
> d673bd397f1ed8239b36a5134bcd29914b11ae72
> fa3cdcff460d555f4a4905fb0a2d96be564fc599
>
> Unfortunately the last one does not apply successful to sssd 1.9.6, which is
> where my clumsy efforts are reaching their time limitation.
>
> Could these patches be possibly backported to a new/final 1.9.7 version for
> me to test?

Pavel, if you have some free time, could you try backporting these three
patches to sssd-1-9 ? I would like to wrap up 1.9.7, declare sssd-1-9
EOL and release 1.11.8 before the Christmas break..

[Lukas Slebodnik]

On (02/12/14 11:42), Jakub Hrozek wrote:
> On Wed, Oct 15, 2014 at 11:41:47PM +0200, Joschi Brauchle wrote:
> > d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
> > d673bd397f1ed8239b36a5134bcd29914b11ae72
> > fa3cdcff460d555f4a4905fb0a2d96be564fc599
> >
> > Unfortunately the last one does not apply successful to sssd 1.9.6, which is
> > where my clumsy efforts are reaching their time limitation.
> >
> > Could these patches be possibly backported to a new/final 1.9.7 version for
> > me to test?
>
> Pavel, if you have some free time, could you try backporting these three
> patches to sssd-1-9 ? I would like to wrap up 1.9.7, declare sssd-1-9
> EOL and release 1.11.8 before the Christmas break..

I sent rebased 3rd patch to Marcus a month ago. I forgot to add sssd-devel to
CC.

Attached is backported patch fa3cdcff460d555f4a4905fb0a2d96be564fc599 to 1-9
branch.
There should not be problem to cherry-pick 1st and 2nd patch.

LS

[Pavel Reichl]

On 12/02/2014 11:42 AM, Jakub Hrozek wrote:
> On Wed, Oct 15, 2014 at 11:41:47PM +0200, Joschi Brauchle wrote:
> > d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
> > d673bd397f1ed8239b36a5134bcd29914b11ae72
> > fa3cdcff460d555f4a4905fb0a2d96be564fc599
> >
> > Unfortunately the last one does not apply successful to sssd 1.9.6, which is
> > where my clumsy efforts are reaching their time limitation.
> >
> > Could these patches be possibly backported to a new/final 1.9.7 version for
> > me to test?
>
> Pavel, if you have some free time, could you try backporting these three
> patches to sssd-1-9 ? I would like to wrap up 1.9.7, declare sssd-1-9
> EOL and release 1.11.8 before the Christmas break..

Sure.

Joschi, can you test attached patches?

Thanks!

[Joschi Brauchle]

On 12/02/2014 12:30 PM, Pavel Reichl wrote:
> On 12/02/2014 11:42 AM, Jakub Hrozek wrote:
> > On Wed, Oct 15, 2014 at 11:41:47PM +0200, Joschi Brauchle wrote:
> > > d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
> > > d673bd397f1ed8239b36a5134bcd29914b11ae72
> > > fa3cdcff460d555f4a4905fb0a2d96be564fc599
> > >
> > > Unfortunately the last one does not apply successful to sssd 1.9.6,
> > > which is
> > > where my clumsy efforts are reaching their time limitation.
> > >
> > > Could these patches be possibly backported to a new/final 1.9.7
> > > version for
> > > me to test?
> >
> > Pavel, if you have some free time, could you try backporting these three
> > patches to sssd-1-9 ? I would like to wrap up 1.9.7, declare sssd-1-9
> > EOL and release 1.11.8 before the Christmas break..
>
> Sure.
>
> Joschi, can you test attached patches?
>
> Thanks!

I have quickly tested the proposed patches on one of the machines that 
was affected by the described bug and the problem has disappeared! The 
KRB functionality is working now on the first and any consecutive 
simultaneous logins.

Looking good so far!

Best regards,
Joschi Brauchle

[Jakub Hrozek]

On Tue, Dec 02, 2014 at 03:11:43PM +0100, Joschi Brauchle wrote:
> On 12/02/2014 12:30 PM, Pavel Reichl wrote:
> > On 12/02/2014 11:42 AM, Jakub Hrozek wrote:
> > > On Wed, Oct 15, 2014 at 11:41:47PM +0200, Joschi Brauchle wrote:
> > > > d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
> > > > d673bd397f1ed8239b36a5134bcd29914b11ae72
> > > > fa3cdcff460d555f4a4905fb0a2d96be564fc599
> > > >
> > > > Unfortunately the last one does not apply successful to sssd 1.9.6,
> > > > which is
> > > > where my clumsy efforts are reaching their time limitation.
> > > >
> > > > Could these patches be possibly backported to a new/final 1.9.7
> > > > version for
> > > > me to test?
> > >
> > > Pavel, if you have some free time, could you try backporting these three
> > > patches to sssd-1-9 ? I would like to wrap up 1.9.7, declare sssd-1-9
> > > EOL and release 1.11.8 before the Christmas break..
> >
> > Sure.
> >
> > Joschi, can you test attached patches?
> >
> > Thanks!
>
> I have quickly tested the proposed patches on one of the machines that was
> affected by the described bug and the problem has disappeared! The KRB
> functionality is working now on the first and any consecutive simultaneous
> logins.
>
> Looking good so far!

Thank you very much for testing and for the patience.

[Lukas Slebodnik]

On (02/12/14 15:11), Joschi Brauchle wrote:
> On 12/02/2014 12:30 PM, Pavel Reichl wrote:
> > On 12/02/2014 11:42 AM, Jakub Hrozek wrote:
> > > On Wed, Oct 15, 2014 at 11:41:47PM +0200, Joschi Brauchle wrote:
> > > > d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
> > > > d673bd397f1ed8239b36a5134bcd29914b11ae72
> > > > fa3cdcff460d555f4a4905fb0a2d96be564fc599
> > > >
> > > > Unfortunately the last one does not apply successful to sssd 1.9.6,
> > > > which is
> > > > where my clumsy efforts are reaching their time limitation.
> > > >
> > > > Could these patches be possibly backported to a new/final 1.9.7
> > > > version for
> > > > me to test?
> > >
> > > Pavel, if you have some free time, could you try backporting these three
> > > patches to sssd-1-9 ? I would like to wrap up 1.9.7, declare sssd-1-9
> > > EOL and release 1.11.8 before the Christmas break..
> >
> > Sure.
> >
> > Joschi, can you test attached patches?
> >
> > Thanks!
>
> I have quickly tested the proposed patches on one of the machines that was
> affected by the described bug and the problem has disappeared! The KRB
> functionality is working now on the first and any consecutive simultaneous
> logins.

If you need any other small patches in sssd-1-9 we can push them
(of course if backport will be easy).

LS

[Jakub Hrozek]

On Tue, Dec 02, 2014 at 03:11:43PM +0100, Joschi Brauchle wrote:
> On 12/02/2014 12:30 PM, Pavel Reichl wrote:
> > On 12/02/2014 11:42 AM, Jakub Hrozek wrote:
> > > On Wed, Oct 15, 2014 at 11:41:47PM +0200, Joschi Brauchle wrote:
> > > > d413dd5d7d4affeae9fe4dfd2de4b2296ecaffcc
> > > > d673bd397f1ed8239b36a5134bcd29914b11ae72
> > > > fa3cdcff460d555f4a4905fb0a2d96be564fc599
> > > >
> > > > Unfortunately the last one does not apply successful to sssd 1.9.6,
> > > > which is
> > > > where my clumsy efforts are reaching their time limitation.
> > > >
> > > > Could these patches be possibly backported to a new/final 1.9.7
> > > > version for
> > > > me to test?
> > >
> > > Pavel, if you have some free time, could you try backporting these three
> > > patches to sssd-1-9 ? I would like to wrap up 1.9.7, declare sssd-1-9
> > > EOL and release 1.11.8 before the Christmas break..
> >
> > Sure.
> >
> > Joschi, can you test attached patches?
> >
> > Thanks!
>
> I have quickly tested the proposed patches on one of the machines that was
> affected by the described bug and the problem has disappeared! The KRB
> functionality is working now on the first and any consecutive simultaneous
> logins.
>
> Looking good so far!

Pushed to sssd-1-9:
 * ce2187657335d96c3dc995fcb6e170ca73560041
 * da1ee87ceffea21a4c6fa9b7f561144681f7968e
 * cd1e5f2ce4f9f19dfa6ca5a1e8980b11c8372e0b

[Sumit Bose]

On Wed, Oct 15, 2014 at 02:37:59PM +0200, Joschi Brauchle wrote:
> We have a weird problem with the KRB5CCNAME environment variable that seems
> to be an SSSD bug.
>
> Configuration:
> ------------ /etc/sssd/sssd.conf ------------
> ...
> # Set CCache to Kerberos default
> krb5_ccachedir = /run/user/%U
> krb5_ccname_template = DIR:%d/krb5cc
> ...
> ------------ /etc/sssd/sssd.conf ------------
>
> Now, user "ne96soh" logs in to the machine for the FIRST time and does a
> kerberized ldapsearch:
>
> ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> DIR:/run/user/3036404/krb5cc
> ne96soh@tueilnt-student01:~$ klist
> Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> ...
> ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> ... <succeeds>
>
> but then logs into the machine a SECOND concurrent time (i.e. leaving first
> session open):
>
> ne96soh@tueilnt-student01:~$ echo $KRB5CCNAME
> DIR::/run/user/3036404/krb5cc/tktZoweZq
> ne96soh@tueilnt-student01:~$ klist
> Ticket cache: DIR::/run/user/3036404/krb5cc/tktZoweZq
> ...
> ne96soh@tueilnt-student01:~$ ldapsearch ...<using GSSAPI>
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Local error (-2)
>         additional info: SASL(-1): generic failure: GSSAPI Error:
> Unspecified GSS failure.  Minor code may provide more information (No
> Kerberos credentials available)
>
> For me, the format of 'DIR::/run/user/3036404/krb5cc/tktZoweZq' in the
> second login seems strange! Is this a valid format?

Which version of SSSD are you using? iirc we fixed a similar issue some
time ago.

bye,
Sumit
> When I manuelly reset the KRB5CCNAME variable in the second login shell to
> its original value 'DIR:/run/user/3036404/krb5cc', then the ldapsearch using
> GSSAPI succeeds.
>
> The reason of all this seems to be that SSSD reuses existing ccaches for
> already logged on users, but possibly mixes up formats there.
> See
> ------------ /var/log/sssd_default.log ------------
> (Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_auth_send] (0x4000):
> Ccache_file is [DIR::/run/user/3036404/krb5cc/tktZoweZq] and is  active and
> TGT is  valid.
> ...
> (Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_find_ccache_step]
> (0x0080): Saved ccache DIR::/run/user/3036404/krb5cc/tktZoweZq if of
> different type than ccache in configuration file, reusing the old ccache
> ...
> (Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [safe_remove_old_ccache_file]
> (0x0400): New and old ccache file are the same, no one will be deleted.
> (Wed Oct 15 14:04:54 2014) [sssd[be[default]]] [krb5_mod_ccname] (0x4000):
> Save ccname [DIR::/run/user/3036404/krb5cc/tktZoweZq] for user [ne96soh].
> ------------ /var/log/sssd_default.log ------------
> Best regards,
>
> Dipl.-Ing. Joschi Brauchle, M.S.
>
> Institute for Communications Engineering (LNT)
> Technische Universitaet Muenchen (TUM)
> 80290 Munich, Germany
>
> Tel (work): [phone]
> Fax (work): [phone]
> E-mail: [e-mail]
> Web: http://www.lnt.ei.tum.de/
> sssd-devel mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel