Bug 972357 - sssd-ad assumes the UPN is the same as the user's principal
Summary: sssd-ad assumes the UPN is the same as the user's principal
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: sssd
Version: 18
Hardware: All
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Jakub Hrozek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-08 20:27 UTC by Colin.Simpson
Modified: 2013-09-25 23:35 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-09-25 23:35:36 UTC


Attachments (Terms of Use)

Description Colin.Simpson 2013-06-08 20:27:59 UTC
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 21:00:00 UTC
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 11:27:00 UTC
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 11:32:12 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1842

Comment 4 Colin.Simpson 2013-06-09 12:07:35 UTC
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 12:15:26 UTC
(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 13:02:20 UTC
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 09:54:21 UTC
(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 12:01:29 UTC
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 19:10:54 UTC
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 18:04:17 UTC
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-13 01:51:33 UTC
Just FYI, as you correctly identified this issue is resolved for me in F19.

Comment 12 Jakub Hrozek 2013-07-15 08:40:22 UTC
(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 20:35:51 UTC
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 08:29:02 UTC
Can you also paste the contents of /var/log/sssd/krb5_child.log during the offline attempt?

Comment 15 Jakub Hrozek 2013-09-25 23:35:36 UTC
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.