Hello everyone,
I cannot get kernel keyring caches to work with Ubuntu Trusty (when copying a fully working configuration from openSUSE 13.2).
Scenario: =========================== I am trying to use persistent kernel keyring ccaches with Ubuntu Trusty, which comes with - SSSD 1.11.x - MIT kerberos libs 1.12.x - Kernel 3.13.x
All these components should support kernel keyring ccaches. Is this correct?
In order to debug the problem, I updated SSSD to 1.12.5 and the kernel to 3.19. But still the problem persists, thus I'm asking for help here...
Setup: =========================== I enable persistent keyring ccaches like so in /etc/krb5.conf: -------------- [libdefaults] ... default_ccache_name = KEYRING:persistent:%{uid} --------------
Symptoms: ============================ First of all, none of the problems described next occur when using FILE ccaches (default setting).
I can log into the machine, but no ccache is created for my user, see -------------- Could not chdir to home directory /home/<user>: Permission denied /usr/bin/xauth: timeout in locking authority file /home/<user>/.Xauthority -bash: /home/<user>/.bash_profile: Permission denied $ echo $KRB5CCNAME KEYRING:persistent:3036404 $ klist klist: No credentials cache found while retrieving principal name --------------
Doing a manual kinit now does create the ccache successfully: -------------- $ klist klist: No credentials cache found while retrieving principal name $ kinit Password for username@REALM: $ klist Ticket cache: KEYRING:persistent:3036404:3036404 Default principal: username@REALM Valid starting Expires Service principal 11/07/2015 13:58:23 11/07/2015 23:58:23 krbtgt/REALM@REALM renew until 11/14/2015 13:58:21 -------------- But note the strange ccache name with twice the UID. This looks not right. I am expecting something like "KEYRING:persistent:3036404:krb_ccache_RANDOM" ...
Logs of SSSD 1.12.5 and using Kernel 3.19. on Trusty: ============================ - krb5_child.log: http://paste.opensuse.org/view/raw/eb52751d - strace of backend process: http://paste.opensuse.org/view/raw/85f09d65
I obfuscated parts of the logs, removing my username, realm, hostname and domainname.
The strace shows some interesting keyctl errors: ENOKEY (Required key not available)
Thanks for any suggestions on how to fix the problem! - J Brauchle
On (07/11/15 14:05), Joschi Brauchle wrote:
Hello everyone,
I cannot get kernel keyring caches to work with Ubuntu Trusty (when copying a fully working configuration from openSUSE 13.2).
Scenario:
I am trying to use persistent kernel keyring ccaches with Ubuntu Trusty, which comes with
- SSSD 1.11.x
- MIT kerberos libs 1.12.x
- Kernel 3.13.x
All these components should support kernel keyring ccaches. Is this correct?
In order to debug the problem, I updated SSSD to 1.12.5 and the kernel to 3.19. But still the problem persists, thus I'm asking for help here...
Setup:
I enable persistent keyring ccaches like so in /etc/krb5.conf:
[libdefaults] ... default_ccache_name = KEYRING:persistent:%{uid}
Symptoms:
First of all, none of the problems described next occur when using FILE ccaches (default setting).
I can log into the machine, but no ccache is created for my user, see
Could not chdir to home directory /home/<user>: Permission denied /usr/bin/xauth: timeout in locking authority file /home/<user>/.Xauthority -bash: /home/<user>/.bash_profile: Permission denied $ echo $KRB5CCNAME KEYRING:persistent:3036404 $ klist klist: No credentials cache found while retrieving principal name
Doing a manual kinit now does create the ccache successfully:
$ klist klist: No credentials cache found while retrieving principal name $ kinit Password for username@REALM: $ klist Ticket cache: KEYRING:persistent:3036404:3036404 Default principal: username@REALM Valid starting Expires Service principal 11/07/2015 13:58:23 11/07/2015 23:58:23 krbtgt/REALM@REALM renew until 11/14/2015 13:58:21
But note the strange ccache name with twice the UID. This looks not right. I am expecting something like "KEYRING:persistent:3036404:krb_ccache_RANDOM" ...
Logs of SSSD 1.12.5 and using Kernel 3.19. on Trusty:
- krb5_child.log: http://paste.opensuse.org/view/raw/eb52751d
- strace of backend process: http://paste.opensuse.org/view/raw/85f09d65
I obfuscated parts of the logs, removing my username, realm, hostname and domainname.
The strace shows some interesting keyctl errors: ENOKEY (Required key not available)
Thanks for any suggestions on how to fix the problem!
The issue might be related to UPN
(Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [unpack_buffer] (0x0100): cmd [241] uid [3036404] gid [3000000] validate [true] enterprise principal [true] offline [false] UPN [ne96soh@ADS.MWN.DE]
(Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [sss_get_ccache_name_for_principal] (0x2000): krb5_cc_cache_match failed: [-1765328243][Can't find client principal ne96soh@ADS.MWN.DE in cache collection] (Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [create_ccache] (0x4000): Initializing ccache of type [KEYRING] (Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the same, none will be deleted. (Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [k5c_send_data] (0x0200): Received error code 0 (Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [pack_response_packet] (0x2000): response packet size: [133] (Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [k5c_send_data] (0x4000): Response sent. (Sat Nov 7 13:28:14 2015) [[sssd[krb5_child[6150]]]] [main] (0x0400): krb5_child completed successfully
Could you also provide log files from domain section? The strace is not very useful to me.
LS
Please find the logs of the domain section here: http://pastebin.com/raw.php?i=WjU2TFNT
As mentioned, I can log in just fine when using FILE based caches.
Here is a tail of a DIFF of the krb5_child.log between a FILE and KEYRING login:
--- sssd.file/krb5_child.log 2015-11-09 17:38:50.499412249 +0100 +++ sssd.keyring/krb5_child.log 2015-11-09 17:38:36.827472075 +0100 @@ -2 +2 @@ -[[sssd[krb5_child]]] [unpack_buffer] (0x1000): total buffer size: [152] +[[sssd[krb5_child]]] [unpack_buffer] (0x1000): total buffer size: [147] @@ -4 +4 @@ -[[sssd[krb5_child]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_3036404_XXXXXX] old_ccname: [KEYRING:persistent:3036404] keytab: [/etc/krb5.keytab] +[[sssd[krb5_child]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:3036404] old_ccname: [KEYRING:persistent:3036404] keytab: [/etc/krb5.keytab] @@ -41 +41 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Encrypted timestamp (for 1447086864.253259): plain 301AA011180F32303135313130393136333432345AA105020303DD4B, encrypted 524172B321C1B579A7F4B653AD67E00D97616A3AECAB1BA35B89481ED0AF6ADECD9F16068FA9A32490FD8CFDE0EDFA82CFDC7B2CE3493C43 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Encrypted timestamp (for 1447086718.404997): plain 301AA011180F32303135313130393136333135385AA1050203062E05, encrypted A2D47A87494D3A06AFD635A758AE6AF519538AD992A71489B7EE71A40DAB8711C796DB654C3B62E0EBAA6F6DF4EC13F587F2AD34DB41F423 @@ -81 +81 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Decrypted AS reply; session key is: aes256-cts/FADF +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Decrypted AS reply; session key is: aes256-cts/0C47 @@ -85 +85 @@ -[[sssd[krb5_child]]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [689422421] +[[sssd[krb5_child]]] [sss_krb5_expire_callback_func] (0x2000): exp_time: [689422567] @@ -91 +91 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Initializing MEMORY:Pabonj3 with default princ myusername@MYREALM +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Initializing MEMORY:WWLjrPf with default princ myusername@MYREALM @@ -93 +93 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Removing myusername@MYREALM -> krbtgt/MYREALM@MYREALM from MEMORY:Pabonj3 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Removing myusername@MYREALM -> krbtgt/MYREALM@MYREALM from MEMORY:WWLjrPf @@ -95 +95 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Storing myusername@MYREALM -> krbtgt/MYREALM@MYREALM in MEMORY:Pabonj3 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Storing myusername@MYREALM -> krbtgt/MYREALM@MYREALM in MEMORY:WWLjrPf @@ -97 +97 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Getting credentials myusername@MYREALM -> myhostname$@MYREALM using ccache MEMORY:Pabonj3 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Getting credentials myusername@MYREALM -> myhostname$@MYREALM using ccache MEMORY:WWLjrPf @@ -99 +99 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Retrieving myusername@MYREALM -> myhostname$@MYREALM from MEMORY:Pabonj3 with result: -1765328243/Matching credential not found +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Retrieving myusername@MYREALM -> myhostname$@MYREALM from MEMORY:WWLjrPf with result: -1765328243/Matching credential not found @@ -101 +101 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Retrieving myusername@MYREALM -> krbtgt/MYREALM@MYREALM from MEMORY:Pabonj3 with result: 0/Success +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Retrieving myusername@MYREALM -> krbtgt/MYREALM@MYREALM from MEMORY:WWLjrPf with result: 0/Success @@ -107 +107 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Generated subkey for TGS request: aes256-cts/9793 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Generated subkey for TGS request: aes256-cts/6A8B @@ -137 +137 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): FAST reply key: aes256-cts/445A +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): FAST reply key: aes256-cts/FC6B @@ -139 +139 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): TGS reply is for myusername@MYREALM -> myhostname$@MYREALM with session key aes256-cts/4945 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): TGS reply is for myusername@MYREALM -> myhostname$@MYREALM with session key aes256-cts/4221 @@ -145 +145 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Removing myusername@MYREALM -> myhostname$@MYREALM from MEMORY:Pabonj3 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Removing myusername@MYREALM -> myhostname$@MYREALM from MEMORY:WWLjrPf @@ -147 +147 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Storing myusername@MYREALM -> myhostname$@MYREALM in MEMORY:Pabonj3 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Storing myusername@MYREALM -> myhostname$@MYREALM in MEMORY:WWLjrPf @@ -149 +149 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Creating authenticator for myusername@MYREALM -> myhostname$@MYREALM, seqnum 0, subkey (null), session key aes256-cts/4945 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Creating authenticator for myusername@MYREALM -> myhostname$@MYREALM, seqnum 0, subkey (null), session key aes256-cts/4221 @@ -155 +155 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): AP-REQ ticket: myusername@MYREALM -> myhostname$@MYREALM, session key aes256-cts/4945 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): AP-REQ ticket: myusername@MYREALM -> myhostname$@MYREALM, session key aes256-cts/4221 @@ -165 +165 @@ -[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Destroying ccache MEMORY:Pabonj3 +[[sssd[krb5_child]]] [sss_child_krb5_trace_cb] (0x4000): Destroying ccache MEMORY:WWLjrPf @@ -176 +176 @@ -[[sssd[krb5_child]]] [sss_get_ccache_name_for_principal] (0x4000): Location: [FILE:/tmp/krb5cc_3036404_XXXXXX] +[[sssd[krb5_child]]] [sss_get_ccache_name_for_principal] (0x4000): Location: [KEYRING:persistent:3036404] @@ -178,3 +178,2 @@ -[[sssd[krb5_child]]] [create_ccache] (0x4000): Initializing ccache of type [FILE] -[[sssd[krb5_child]]] [switch_creds] (0x0200): Switch user to [3036404][3000000]. -[[sssd[krb5_child]]] [switch_creds] (0x0200): Already user [3036404]. +[[sssd[krb5_child]]] [create_ccache] (0x4000): Initializing ccache of type [KEYRING] +[[sssd[krb5_child]]] [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the same, none will be deleted. @@ -182 +181 @@ -[[sssd[krb5_child]]] [pack_response_packet] (0x2000): response packet size: [138] +[[sssd[krb5_child]]] [pack_response_packet] (0x2000): response packet size: [133]
To me, this looks all completely okay. Still, I do not get a ccache in the KEYRING configuration.
On (09/11/15 17:54), Joschi Brauchle wrote:
Please find the logs of the domain section here: http://pastebin.com/raw.php?i=WjU2TFNT
I cannot see any problem with authentication. sh$ grep -E "be_pam|(pam_print_data.*(user|command))" pok.log [be_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: PAM_AUTHENTICATE [pam_print_data] (0x0100): user: ne96soh [pam_print_data] (0x0100): ruser: [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success] [be_pam_handler_callback] (0x0100): Sending result [0][ADS.MWN.DE] [be_pam_handler_callback] (0x0100): Sent result [0][ADS.MWN.DE]
[be_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: PAM_ACCT_MGMT [pam_print_data] (0x0100): user: ne96soh [pam_print_data] (0x0100): ruser: [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success] [be_pam_handler_callback] (0x0400): SELinux provider doesn't exist, not sending the request to it. [be_pam_handler_callback] (0x0100): Sending result [0][ADS.MWN.DE] [be_pam_handler_callback] (0x0100): Sent result [0][ADS.MWN.DE]
[be_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: PAM_SETCRED [pam_print_data] (0x0100): user: ne96soh [pam_print_data] (0x0100): ruser: [be_pam_handler] (0x0100): Sending result [0][ADS.MWN.DE]
[be_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: PAM_OPEN_SESSION [pam_print_data] (0x0100): user: ne96soh [pam_print_data] (0x0100): ruser: [be_pam_handler] (0x0100): Sending result [0][ADS.MWN.DE]
[be_pam_handler] (0x0100): Got request with the following data [pam_print_data] (0x0100): command: PAM_SETCRED [pam_print_data] (0x0100): user: ne96soh [pam_print_data] (0x0100): ruser: [be_pam_handler] (0x0100): Sending result [0][ADS.MWN.DE]
The user ne96soh was successfully authenticated. Did you attach log fiels with kernel keyring ccache?
LS
On 11/10/2015 10:54 AM, Lukas Slebodnik wrote:
On (09/11/15 17:54), Joschi Brauchle wrote:
Please find the logs of the domain section here: http://pastebin.com/raw.php?i=WjU2TFNT
...
The user ne96soh was successfully authenticated. Did you attach log fiels with kernel keyring ccache?
LS
Yes, the user is authenticated successfully! The problem is, that there exists no CCACHE after login, i.e., I get: ---------- $ klist klist: No credentials cache found while retrieving principal name ----------
I just changed the setup from KEYRING to DIR based cache collections and get a similar error: ---------- /etc/krb5.conf [libdefaults] ... default_ccache_name = DIR:/run/user/%{uid}/krb5cc ----------
Now after login I get ---------- $ klist klist: Credentials cache file '/run/user/3036404/krb5cc/tkt' not found $ ls -al /run/user/3036404/krb5cc -rw------- 1 myuser mygroup 4 Nov 10 11:06 /run/user/3036404/krb5cc/primary $ cat /run/user/3036404/krb5cc/primary tkt ----------
But again, a manual kinit is successful: ---------- $ kinit Password for myuser@MYREALM: $ klist Ticket cache: DIR::/run/user/3036404/krb5cc/tkt Default principal: myuser@MYREALM
Valid starting Expires Service principal 11/10/2015 11:08:40 11/10/2015 21:08:40 krbtgt/MYREALM@MYREALM renew until 11/17/2015 11:08:40 ----------
To me this somehow looks like something else (like SElinux oder AppArmor) getting in the way of any other ccache setup than FILE. Only that I uninstalled and disabled apparmor completely...
What else can this be?!?
On (10/11/15 11:10), Joschi Brauchle wrote:
On 11/10/2015 10:54 AM, Lukas Slebodnik wrote:
On (09/11/15 17:54), Joschi Brauchle wrote:
Please find the logs of the domain section here: http://pastebin.com/raw.php?i=WjU2TFNT
...
The user ne96soh was successfully authenticated. Did you attach log fiels with kernel keyring ccache?
LS
Yes, the user is authenticated successfully! The problem is, that there exists no CCACHE after login, i.e., I get:
$ klist klist: No credentials cache found while retrieving principal name
Could you tell us what is a value of env variable KRB5CCNAME after log-in?
Do you test with ssh or su or "su -"
Please also provide dump of sssd cache after authentication. There should be somethig about ccache as well.
ldbsearch -H /var/lib/sss/db/cache_*.com.ldb
e.g. ccacheFile: KEYRING:persistent:20728
LS
Hello Lukas,
I will provide more logs shortly. Just one quick question:
I updates to Ubuntu 15.10 (latest) and all problems persist if I dont use FILE based caches.
I then checked the installed packages in Ubuntu and to my surpise, I found a mixed setup with MIT kerberos and Heimdal Kerberos libraries. E.g. the openLDAP service and all Samba tools use heimdal, whereas the rest of the system uses MIT kerberos libs.
So, I am starting to believe that the problems I see are coming from this mixture of kerberos libs.
E.g., when I use DIR ccaches as default in /etc/krb5.conf and then remove the KRB5CCNAME variable in my session, all MIT-based kerberos tools still work (because they read the setup correctly from /etc/krb5.conf) while all Samba tools fail and use /tmp/ to check for FILE caches.
Is there anything known about Ubuntu and anything else then FILE based ccaches? E.g. I found: https://www.mail-archive.com/sssd-users@lists.fedorahosted.org/msg03317.html
-Joschi
On 11/10/2015 11:40 AM, Lukas Slebodnik wrote:
On (10/11/15 11:10), Joschi Brauchle wrote:
On 11/10/2015 10:54 AM, Lukas Slebodnik wrote:
On (09/11/15 17:54), Joschi Brauchle wrote:
Please find the logs of the domain section here: http://pastebin.com/raw.php?i=WjU2TFNT
...
The user ne96soh was successfully authenticated. Did you attach log fiels with kernel keyring ccache?
LS
Yes, the user is authenticated successfully! The problem is, that there exists no CCACHE after login, i.e., I get:
$ klist klist: No credentials cache found while retrieving principal name
Could you tell us what is a value of env variable KRB5CCNAME after log-in?
Do you test with ssh or su or "su -"
Please also provide dump of sssd cache after authentication. There should be somethig about ccache as well.
ldbsearch -H /var/lib/sss/db/cache_*.com.ldb
e.g. ccacheFile: KEYRING:persistent:20728
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, Nov 10, 2015 at 12:10:11PM +0100, Joschi Brauchle wrote:
Hello Lukas,
I will provide more logs shortly. Just one quick question:
I updates to Ubuntu 15.10 (latest) and all problems persist if I dont use FILE based caches.
I then checked the installed packages in Ubuntu and to my surpise, I found a mixed setup with MIT kerberos and Heimdal Kerberos libraries. E.g. the openLDAP service and all Samba tools use heimdal, whereas the rest of the system uses MIT kerberos libs.
That's expected.
Samba upstream only supports Heimdal at the moment. There is ongoing work to support MIT as well, driven by Andreas Schneider, but it's not finished yet.
At the same time, because Fedora only carries MIT and Fedora is more or less our reference architecture for SSSD, then SSSD only[*] supports Heimdal.
[*] There were some Heimdal patches in the past, but we accepted them more or less blindly as long as they looked OK and didn't break MIT builds. We never tested Heimdal ourselves.
So, I am starting to believe that the problems I see are coming from this mixture of kerberos libs.
E.g., when I use DIR ccaches as default in /etc/krb5.conf and then remove the KRB5CCNAME variable in my session, all MIT-based kerberos tools still work (because they read the setup correctly from /etc/krb5.conf) while all Samba tools fail and use /tmp/ to check for FILE caches.
Is there anything known about Ubuntu and anything else then FILE based ccaches? E.g. I found: https://www.mail-archive.com/sssd-users@lists.fedorahosted.org/msg03317.html
-Joschi
On 11/10/2015 11:40 AM, Lukas Slebodnik wrote:
On (10/11/15 11:10), Joschi Brauchle wrote:
On 11/10/2015 10:54 AM, Lukas Slebodnik wrote:
On (09/11/15 17:54), Joschi Brauchle wrote:
Please find the logs of the domain section here: http://pastebin.com/raw.php?i=WjU2TFNT
...
The user ne96soh was successfully authenticated. Did you attach log fiels with kernel keyring ccache?
LS
Yes, the user is authenticated successfully! The problem is, that there exists no CCACHE after login, i.e., I get:
$ klist klist: No credentials cache found while retrieving principal name
Could you tell us what is a value of env variable KRB5CCNAME after log-in?
Do you test with ssh or su or "su -"
Please also provide dump of sssd cache after authentication. There should be somethig about ccache as well.
ldbsearch -H /var/lib/sss/db/cache_*.com.ldb
e.g. ccacheFile: KEYRING:persistent:20728
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-- Dipl.-Ing. Joschi Brauchle, M.S.
Institute for Communications Engineering (LNT) Technische Universitaet Muenchen (TUM) 80290 Munich, Germany
Tel: +49 89 289-23474 Fax: +49 89 289-23490 E-mail: joschi.brauchle@tum.de Web: http://www.lnt.ei.tum.de/
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (10/11/15 12:10), Joschi Brauchle wrote:
Hello Lukas,
I will provide more logs shortly. Just one quick question:
I updates to Ubuntu 15.10 (latest) and all problems persist if I dont use FILE based caches.
I then checked the installed packages in Ubuntu and to my surpise, I found a mixed setup with MIT kerberos and Heimdal Kerberos libraries. E.g. the openLDAP service and all Samba tools use heimdal, whereas the rest of the system uses MIT kerberos libs.
So, I am starting to believe that the problems I see are coming from this mixture of kerberos libs.
E.g., when I use DIR ccaches as default in /etc/krb5.conf and then remove the KRB5CCNAME variable in my session, all MIT-based kerberos tools still work (because they read the setup correctly from /etc/krb5.conf) while all Samba tools fail and use /tmp/ to check for FILE caches.
It could explain a lot.
You might try to remove default_ccache_name from /etc/krb5.conf and still use KEYRING ccache.
You just need to set krb5_ccname tepmplate in domain section of sssd.
man sssd-krb5 -> krb5_ccname_template
BTW template default_ccache_name in krb5.conf and krb5_ccname_template in sssd.conf have different syntax.
I didn't test it but it might help
LS
On 10/11/15 06:10, Joschi Brauchle wrote:
I then checked the installed packages in Ubuntu and to my surpise, I found a mixed setup with MIT kerberos and Heimdal Kerberos libraries. E.g. the openLDAP service and all Samba tools use heimdal, whereas the rest of the system uses MIT kerberos libs.
This is completely broken, I am surprised to hear Ubuntu really does that. In particular SSSD links with samba libraries but is only ever tested with MIT Kerberos, and depends on it for the DIR/KEYRING feature (Heimdal does not implement those iirc).
So, I am starting to believe that the problems I see are coming from this mixture of kerberos libs.
In general you cannot mix code linked to the 2 libraries, bad things will happen, and you will have to resort to the minimum common denominator for both, on systems that want to use programs independently compiled against one or the other and used in the same session, which is FILE ccaches only.
Simo.
On 11/10/2015 11:40 AM, Lukas Slebodnik wrote:
Could you tell us what is a value of env variable KRB5CCNAME after log-in?
$ echo $KRB5CCNAME KEYRING:persistent:3036404
Do you test with ssh or su or "su -"
SSH tests fail each time. Local tests fail each time. (Both meaning that login succeeds, but no ccache available)
If I do a "su - <username>" then I obtain a ccache, see: ----------SSH login... $ klist klist: No credentials cache found while retrieving principal name $ su - myusername Password: X11 connection rejected because of wrong authentication. No directory, logging in with HOME=/ $ klist Ticket cache: KEYRING:persistent:3036404:krb_ccache_LgqDqsq Default principal: myusername@MYREALM
Valid starting Expires Service principal 11/10/2015 16:03:28 11/11/2015 02:03:28 krbtgt/MYREALM@MYREALM renew until 11/17/2015 16:03:28 $ echo $KRB5CCNAME KEYRING:persistent:3036404 ----------
Any followup SSH or local login succeeds as well.
If I do mixed SSH and local logins, they succeed at some point (at least thats what I believe)... That is really strange.
Some observations: - local and SSH login have a substantion PAM configuration, while - su is pretty simple. - Note that even when I successfully obtain a valid keyring ccache at some point, and kinit is happy... I have never ever been able to use these credentials with kerberized NFS3+4. I always get an "access denied" error with NFS3+4, see
---------- after su - myusername $ klist Ticket cache: KEYRING:persistent:3036404:krb_ccache_LgqDqsq Default principal: myusername@MYREALM
Valid starting Expires Service principal 11/10/2015 16:03:28 11/11/2015 02:03:28 krbtgt/MYREALM@MYREALM renew until 11/17/2015 16:03:28 $ cd /home/myusername # home is nfs4 + krb5 protected -su: cd: /home/myusername: Permission denied ----------
The only way to get login + NFS working so far is using FILE caches so far. In this case, after I 'cd' to my home, klist also shows an 'nfs/nfsserver.fqdn@MYREALM' ticket and all is well:
---------- after SSH login and FILE ccache in /etc/krb5.conf $ klist Ticket cache: FILE:/tmp/krb5cc_3036404_GZnyw8 Default principal: myusername@MYREALM
Valid starting Expires Service principal 11/10/2015 16:23:09 11/11/2015 02:23:09 krbtgt/MYREALM@MYREALM renew until 11/17/2015 16:23:09 11/10/2015 16:23:10 11/11/2015 02:23:09 nfs/nfsserver.fqdn@MYREALM renew until 11/17/2015 16:23:09 $ pwd /home/myusername ----------
Please also provide dump of sssd cache after authentication. There should be somethig about ccache as well.
ldbsearch -H /var/lib/sss/db/cache_*.ldb
Please see here: http://paste.opensuse.org/view/raw/46179025
I noticed that my userPrincipalName and canonicalUserPrincipalName differ... not sure if this matters.
On (10/11/15 16:25), Joschi Brauchle wrote:
On 11/10/2015 11:40 AM, Lukas Slebodnik wrote:
Could you tell us what is a value of env variable KRB5CCNAME after log-in?
$ echo $KRB5CCNAME KEYRING:persistent:3036404
Do you test with ssh or su or "su -"
SSH tests fail each time.
Does dump of sssd cache contain attribute "ccacheFile" after that login?
If yes you might try to use this ccache KRB5CCNAME=$(value from dump) klist
Local tests fail each time. (Both meaning that login succeeds, but no ccache available)
If I do a "su - <username>" then I obtain a ccache, see: ----------SSH login...
^^^ it says ssh but you did "su -"
$ klist klist: No credentials cache found while retrieving principal name $ su - myusername Password: X11 connection rejected because of wrong authentication. No directory, logging in with HOME=/ $ klist Ticket cache: KEYRING:persistent:3036404:krb_ccache_LgqDqsq Default principal: myusername@MYREALM
Valid starting Expires Service principal 11/10/2015 16:03:28 11/11/2015 02:03:28 krbtgt/MYREALM@MYREALM renew until 11/17/2015 16:03:28 $ echo $KRB5CCNAME KEYRING:persistent:3036404
That's good.
Any followup SSH or local login succeeds as well.
It might be explained by fact that user session is opened (loginctl) and was not closed. So the same KRB5CCNAME was ised.
If I do mixed SSH and local logins, they succeed at some point (at least thats what I believe)... That is really strange.
Some observations:
- local and SSH login have a substantion PAM configuration, while
- su is pretty simple.
It's expected and shoud not be used for such tests. "su -" uses different pam service /etc/pam.d/su-l which do full authentication
- Note that even when I successfully obtain a valid keyring ccache at some
point, and kinit is happy... I have never ever been able to use these credentials with kerberized NFS3+4. I always get an "access denied" error with NFS3+4, see
This is not related to sssd :-)
---------- after su - myusername $ klist Ticket cache: KEYRING:persistent:3036404:krb_ccache_LgqDqsq Default principal: myusername@MYREALM
Valid starting Expires Service principal 11/10/2015 16:03:28 11/11/2015 02:03:28 krbtgt/MYREALM@MYREALM renew until 11/17/2015 16:03:28 $ cd /home/myusername # home is nfs4 + krb5 protected
-su: cd: /home/myusername: Permission denied
The only way to get login + NFS working so far is using FILE caches so far. In this case, after I 'cd' to my home, klist also shows an 'nfs/nfsserver.fqdn@MYREALM' ticket and all is well:
---------- after SSH login and FILE ccache in /etc/krb5.conf $ klist Ticket cache: FILE:/tmp/krb5cc_3036404_GZnyw8 Default principal: myusername@MYREALM
Valid starting Expires Service principal 11/10/2015 16:23:09 11/11/2015 02:23:09 krbtgt/MYREALM@MYREALM renew until 11/17/2015 16:23:09 11/10/2015 16:23:10 11/11/2015 02:23:09 nfs/nfsserver.fqdn@MYREALM renew until 11/17/2015 16:23:09 $ pwd /home/myusername
Please also provide dump of sssd cache after authentication. There should be somethig about ccache as well.
ldbsearch -H /var/lib/sss/db/cache_*.ldb
Please see here: http://paste.opensuse.org/view/raw/46179025
I noticed that my userPrincipalName and canonicalUserPrincipalName differ... not sure if this matters.
You can test yourself so that you will not use UPN but user@domain ne96soh@ADS.MWN.DE
But we might try to solve why ssh does not work for first time. * please try with empty sssd cache. * destroy KEYring cache (or destroy user session with loginctl)
LS
sssd-users@lists.fedorahosted.org