4

I have recently run into a problem with my AD integration on a number of debian boxes. I use SSSD and krb5 to allow PAM to synchronize and authenticate users against the Active Directory. This has been working for over a year, until the AD administrator changed the UPN of the AD users from username@COMPANY.DK to username@ABCCOMPANY.DK.

Now, the synchronization and username recognition still works, but the authentication suddenly fails, as it seems that the name sent to krb5 is "username@ABCCOMPANY.DK". This realm is not known to krb5 so it fails to authenticate the user.

Changing the krb5.conf file realm to ABCCOMPANY does not work, as the realm isn't actually changed.

I can use kinit mnn@COMPANY.DK without problems, it logs me in just fine. I cannot, however do kinit mnn@ABCCOMPANY.DK as it makes krb5 complain with the following message:

kinit: Cannot find KDC for realm "ABCCOMPANY.DK" while getting initial credentials

That makes sense i think. SSSD sends ABCCOMPANY.DK in the UPN along to krb5, but krb5 is not recognizing that realm because it does not exist.

So, the question is: How do i configure krb5 to recognize that the realm is not the same as the UPN? And a bonus question out of pure curiosity: Is this practice (Setting the UPN to something else than the realm name) an accepted way of doing things? It seems odd to me to have a domain component that doesn't actually match a domain.

(Mon Jan 23 13:12:59 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1].
(Mon Jan 23 13:12:59 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1].
(Mon Jan 23 13:12:59 2017) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'mnn' matched without domain, user is mnn
(Mon Jan 23 13:12:59 2017) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
(Mon Jan 23 13:12:59 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [mnn] from [<ALL>]
(Mon Jan 23 13:12:59 2017) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [mnn@company.dk]
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3].
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3].
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'mnn' matched without domain, user is mnn
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)]
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not set
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): user: mnn
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.112.155
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 8724
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [be_get_account_info] (0x0100): Got request for [3][1][name=mnn]
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No such attribute]
...
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [mnn@company.dk]
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data:
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: company.dk
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): user: mnn
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sshd
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: 172.16.112.155
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 8724
(Mon Jan 23 13:12:59 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [be_pam_handler] (0x0100): Got request with the following data
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): domain: company.dk
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): user: mnn
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): service: sshd
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): tty: ssh
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): ruser:
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): rhost: 172.16.112.155
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): authtok type: 1
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): newauthtok type: 0
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): priv: 1
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [pam_print_data] (0x0100): cli_pid: 8724
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [krb5_auth_send] (0x0100): Home directory for user [mnn] not known.
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [krb5_auth_send] (0x0200): Ignoring ccache attribute [FILE:/tmp/krb5cc_876027530_rTTlt3], because it doesn'texist.
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'KERBEROS'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_KERBEROS._udp.company.dk'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KERBEROS' as 'resolved'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'ad2.company.dk' in files
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [set_server_common_status] (0x0100): Marking server 'ad2.company.dk' as 'resolving name'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'ad2.company.dk' in files
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'ad2.company.dk' in DNS
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [set_server_common_status] (0x0100): Marking server 'ad2.company.dk' as 'name resolved'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [be_resolve_server_process] (0x0200): Found address for server ad2.company.dk: [xxx.xx.x.xx] TTL 3600
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'KPASSWD'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_KPASSWD._udp.company.dk'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'KPASSWD' as 'resolved'
(Mon Jan 23 13:12:59 2017) [sssd[be[company.dk]]] [be_resolve_server_process] (0x0200): Found address for server ad2.company.dk: [xxx.xx.x.xx] TTL 3600
(Mon Jan 23 13:13:00 2017) [sssd] [service_send_ping] (0x0100): Pinging company.dk
(Mon Jan 23 13:13:00 2017) [sssd] [service_send_ping] (0x0100): Pinging nss
(Mon Jan 23 13:13:00 2017) [sssd] [service_send_ping] (0x0100): Pinging pam
(Mon Jan 23 13:13:00 2017) [sssd] [ping_check] (0x0100): Service pam replied to ping
(Mon Jan 23 13:13:00 2017) [sssd] [ping_check] (0x0100): Service nss replied to ping
(Mon Jan 23 13:13:00 2017) [sssd[be[company.dk]]] [become_user] (0x0200): Trying to become user [876027530][876000513].
(Mon Jan 23 13:13:00 2017) [sssd] [ping_check] (0x0100): Service company.dk replied to ping
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [unpack_buffer] (0x0100): cmd [241] uid [876027530] gid [876000513] validate [false] enterprise principal [false] offline [false] UPN [mnn@ABCCOMPANY.DK]
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_876027530_XXXXXX] keytab: [/etc/krb5.keytab]
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [false]
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [k5c_setup] (0x0100): Not using FAST.
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [get_and_save_tgt] (0x0020): 981: [-1765328230][Cannot find KDC for realm "ABCCOMPANY.DK"]
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [map_krb5_error] (0x0020): 1043: [-1765328230][Cannot find KDC for realm "ABCCOMPANY.DK"]
(Mon Jan 23 13:13:00 2017) [[sssd[krb5_child[8727]]]] [k5c_send_data] (0x0200): Received error code 1432158209
(Mon Jan 23 13:13:00 2017) [sssd[be[company.dk]]] [child_sig_handler] (0x0100): child [8727] finished successfully.
(Mon Jan 23 13:13:00 2017) [sssd[be[company.dk]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
(Mon Jan 23 13:13:00 2017) [sssd[be[company.dk]]] [be_pam_handler_callback] (0x0100): Sending result [4][company.dk]
(Mon Jan 23 13:13:00 2017) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [4][company.dk]
(Mon Jan 23 13:13:00 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4].
(Mon Jan 23 13:13:00 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 29
(Mon Jan 23 13:13:00 2017) [sssd[be[company.dk]]] [be_pam_handler_callback] (0x0100): Sent result [4][company.dk]
(Mon Jan 23 13:13:02 2017) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
(Mon Jan 23 13:13:02 2017) [sssd[pam]] [client_recv] (0x0200): Client disconnected!
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit_signal] (0x0040): Monitor received Interrupt: terminating children
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit] (0x0040): Returned with: 0
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit] (0x0020): Terminating [pam][8719]
(Mon Jan 23 13:13:04 2017) [sssd[be[company.dk]]] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit] (0x0020): Child [pam] exited gracefully
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit] (0x0020): Terminating [nss][8718]
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit] (0x0020): Child [nss] exited gracefully
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit] (0x0020): Terminating [company.dk][8717]
(Mon Jan 23 13:13:04 2017) [sssd] [monitor_quit] (0x0020): Child [company.dk] terminated with a signal
1

Please check your sssd version. According this thread UPN lookup functional works since sssd-1.12.

P.S. But there related bug fixed in sssd-1.13.2, so try to update sssd to the latest available version.

UPD. According this post SSSD 1.10 and later has support for alternate Kerberos principal suffix (see "Support for enterprise logins" section). And this functionality is implemented in sssd-ad provider. Are you sure you are using SSSD ad provider, but not krb5?

  • I ran on debian stable, so the version was 1.8.4-2. I upgraded to 1.14.2-1 from testing, but the problem still persists. – Martin Nielsen Jan 25 '17 at 10:28
0

Check realm in, at least:

  • krb5.conf
  • smb.conf
  • sssd.conf

For reference, here's my script for AD preparation on Ubuntu:

https://github.com/bviktor/ubuntu-ad/blob/master/ad.sh

  • The realm did not change, so it is still set to COMPANY.DK everywhere, the UPN however, is ABCCOMPANY.DK. Changing the realm to ABCCOMPANY.DK in either config file makes the krb5 backend fail because it cannot find the realm (There is no realm called ABCCOMPANY.DK) – Martin Nielsen Jan 31 '17 at 8:34
  • Ah, sorry, was too quick to respond :) – bviktor Jan 31 '17 at 8:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.