Bug 972357 - sssd-ad assumes the UPN is the same as the user's principal
sssd-ad assumes the UPN is the same as the user's principal
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
18
All Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-08 16:27 EDT by Colin.Simpson
Modified: 2013-09-25 19:35 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-25 19:35:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Colin.Simpson 2013-06-08 16:27:59 EDT
Description of problem:
When I attempt to login to my AD account configured(joined) with the SSSD AD connector it tries to use my AD UPN (User Principal Name) to kinit with. This (in our case) 

Version-Release number of selected component (if applicable):
sssd-1.9.4-8.fc18.x86_64

How reproducible:
Every time

Steps to Reproduce:
1. Unable to login


Additional info:
Debug (below) of SSSD shows the issue. My UPN is colin@CSL.CO.UK which doesn't exist as an AD domain (and isn't mine). So it cannot find DC's for this, so can't login. 

I saw some discussion of using enterprise name for AD as the one to use for kinit. I tried this manually 

kinit -E colin@CSL.CO.UK

This does work but makes an ugly TGT (klist output).

Default principal: csimpson\@CSL.CO.UK@IONGEO.COM

Is this correct? Other commercial AD connectors or winbind don't seem to need this (or produce such an output on klist), is the correct way that sssd is thinking or am I missing the point with SSSD Enterpise name proposals and isn't this issue.


(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [krb5_auth_send] (0x0100): No ccache file for user [colin] found.
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [krb5_auth_send] (0x4000): Ccache_file is [not set] and is not active and TGT is not valid.
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [get_server_status] (0x1000): Status of server 'ukdc03.iongeo.lan' is 'working'
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [get_port_status] (0x1000): Port status of port 389 for server 'ukdc03.iongeo.lan' is 'working'
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 10 seconds
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [get_server_status] (0x1000): Status of server 'ukdc03.iongeo.lan' is 'working'
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [be_resolve_server_process] (0x1000): Saving the first resolved server
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [be_resolve_server_process] (0x0200): Found address for server ukdc03.iongeo.lan: [10.10.1.20] TTL 1200
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [krb5_find_ccache_step] (0x4000): Recreating  ccache file.
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [10533]
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [child_handler_setup] (0x2000): Signal handler set up for pid [10533]
(Fri Jun  7 20:00:18 2013) [sssd[be[IONGEO]]] [write_pipe_handler] (0x0400): All data has been sent!
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [main] (0x0400): krb5_child started.
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [unpack_buffer] (0x1000): total buffer size: [112]
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [unpack_buffer] (0x0100): cmd [241] uid [4000] gid [2000] validate [true] offline [false] UPN [colin@CSL.CO.UK]
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [unpack_buffer] (0x0100): ccname: [DIR:/run/user/4000/krb5cc] keytab: [/etc/krb5.keytab]
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [krb5_child_setup] (0x0400): Will perform online auth
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [krb5_child_setup] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [krb5_set_canonicalize] (0x0100): SSSD_KRB5_CANONICALIZE is set to [false]
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [krb5_child_setup] (0x0100): Not using FAST.
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [tgt_req_child] (0x1000): Attempting to get a TGT
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [CSL.CO.UK]
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [sss_child_krb5_trace_cb] (0x4000): [10533] 1370631618.602291: Getting initial credentials for colin@CSL.CO.UK

(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [sss_child_krb5_trace_cb] (0x4000): [10533] 1370631618.602450: Sending request (192 bytes) to CSL.CO.UK

(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [get_and_save_tgt] (0x0020): 977: [-1765328164][Cannot resolve servers for KDC in realm "CSL.CO.UK"]
(Fri Jun  7 20:00:18 2013) [[sssd[krb5_child[10533]]]] [kerr_handle_error] (0x0020): 1030: [-1765328164][Cannot resolve servers for KDC in realm "CSL.CO.UK"]
Comment 1 Colin.Simpson 2013-06-08 17:00:00 EDT
Sorry I typed that from memory the ugly principal I mentioned was:
 
Default principal: colin\@CSL.CO.UK@IONGEO.LAN
Comment 2 Jakub Hrozek 2013-06-09 07:27:00 EDT
Hi Colin,

The support for enterprise principal is coming in sssd-1.10 which is part of Fedora 19. In the current version that is included in Fedora 19 there is a couple of bugs related to the enterprise principal support, so I would recommend waiting for the next release (hopefully Monday).
Comment 3 Jakub Hrozek 2013-06-09 07:32:12 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1842
Comment 4 Colin.Simpson 2013-06-09 08:07:35 EDT
Is my issue addressed by the enterprise principal implementation? 
And will it generate these slightly odd looking default principals?
Comment 5 Jakub Hrozek 2013-06-09 08:15:26 EDT
(In reply to Colin Simpson from comment #4)
> Is my issue addressed by the enterprise principal implementation? 

Since you can kinit with the -E option then I think it would.

> And will it generate these slightly odd looking default principals?

We enable canonicalization by default then the principal should not look ugly :)

Can you try:
kinit -E -C colin@CSL.CO.UK

do you still get an ugly principal?
Comment 6 Colin.Simpson 2013-06-09 09:02:20 EDT
Yes that has cleaned up my principal. It now just says just colin@IONGEO.LAN

Will this make it to F18 or will 1.10 be F19 purely?
Comment 7 Jakub Hrozek 2013-06-10 05:54:21 EDT
(In reply to Colin Simpson from comment #6)
> Yes that has cleaned up my principal. It now just says just colin@IONGEO.LAN
> 
> Will this make it to F18 or will 1.10 be F19 purely?

Currently we are planning F19 only because there is a huge number of changes in 1.10 including different packaging. If 1.10 will ever be present in F-18 then it's going to be later when we are sure there are no regressions.

However, we could start with a private repo on repos.fedorapeople.org. Also, we already have a repository with nightly builds - http://jdennis.fedorapeople.org/ipa-devel/ But please note these are really nightly builds, so breakage happens from time to time. I would only recommend this repository for testing or development.
Comment 8 Fedora Update System 2013-06-12 08:01:29 EDT
sssd-1.10.0-8.fc19.beta2 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/sssd-1.10.0-8.fc19.beta2
Comment 9 Fedora Update System 2013-06-12 15:10:54 EDT
Package sssd-1.10.0-8.fc19.beta2:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.10.0-8.fc19.beta2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10683/sssd-1.10.0-8.fc19.beta2
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2013-06-13 14:04:17 EDT
Package sssd-1.10.0-10.fc19.beta2:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sssd-1.10.0-10.fc19.beta2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-10683/sssd-1.10.0-10.fc19.beta2
then log in and leave karma (feedback).
Comment 11 Colin.Simpson 2013-07-12 21:51:33 EDT
Just FYI, as you correctly identified this issue is resolved for me in F19.
Comment 12 Jakub Hrozek 2013-07-15 04:40:22 EDT
(In reply to Colin Simpson from comment #11)
> Just FYI, as you correctly identified this issue is resolved for me in F19.

Great, thank you for testing!
Comment 13 Colin.Simpson 2013-07-15 16:35:51 EDT
One thing I think I have found is that offline password caching doesn't seem to be working for me. Maybe I'm doing something wrong but the debug looks a bit like it's looking for the UPN name in created DIR cache.

This is F19 sssd-1.10.0-16

Debug:

Mon Jul 15 21:03:56 2013) [[sssd[krb5_child[23084]]]] [need_switch_to_principal] (0x0200): Comparing default principal [colin\@CSL.CO.UK@IOUK.IOROOT.TLD] and new principal [colin\@CSL.CO.UK@IOUK.IOROOT.TLD].
(Mon Jul 15 21:03:56 2013) [[sssd[krb5_child[23084]]]] [map_krb5_error] (0x0020): 1283: [0][Success]
(Mon Jul 15 21:03:56 2013) [[sssd[krb5_child[23084]]]] [pack_response_packet] (0x2000): response packet size: [49]
(Mon Jul 15 21:03:56 2013) [[sssd[krb5_child[23084]]]] [k5c_send_data] (0x4000): Response sent.
(Mon Jul 15 21:03:56 2013) [[sssd[krb5_child[23084]]]] [main] (0x0400): krb5_child completed successfully
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [child_sig_handler] (0x1000): Waiting for child [23084].
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [child_sig_handler] (0x0100): child [23084] finished successfully.
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [sss_child_handler] (0x2000): waitpid failed [10]: No child processes
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [read_pipe_handler] (0x0400): EOF received, client finished
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [parse_krb5_child_response] (0x1000): child response [0][3][37].
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [cc_dir_cache_for_princ] (0x0400): No principal for colin@CSL.CO.UK in DIR:/run/user/4000/krb5cc
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [krb5_auth_done] (0x0020): No ccache for colin@CSL.CO.UK in DIR:/run/user/4000/krb5cc?
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [check_wait_queue] (0x1000): Wait queue for user [colin] is empty.
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][iongeo.com]
(Mon Jul 15 21:03:56 2013) [sssd[be[iongeo.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][iongeo.com]
(Mon Jul 15 21:03:56 2013) [sssd[pam]] [sbus_remove_timeout] (0x4000): 0x7fce229194f0
(Mon Jul 15 21:03:56 2013) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 7FCE2290E410
(Mon Jul 15 21:03:56 2013) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching.
(Mon Jul 15 21:03:56 2013) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [4][iongeo.com]
(Mon Jul 15 21:03:56 2013) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4].
(Mon Jul 15 21:03:56 2013) [sssd[pam]] [pam_reply] (0x0100): blen: 77
Comment 14 Jakub Hrozek 2013-07-16 04:29:02 EDT
Can you also paste the contents of /var/log/sssd/krb5_child.log during the offline attempt?
Comment 15 Jakub Hrozek 2013-09-25 19:35:36 EDT
This bug was fixed a long time ago, closing.

Note You need to log in before you can comment on or make changes to this bug.