On Thu, Jan 31, 2019 at 04:27:02PM +0100, Jeremy Monnet wrote:
> Hello,
> 
> I never fixed issues I had last year
> https://lists.fedorahosted.org/archives/list/[email protected]/thread/5XUJLUVI5JZILZKDK5DRHK7PSQNIZZBD/
> but I did made a new test on a brand new ubuntu up to date, and the
> result is far better, though everything is not working.
> 
> As a reminder, I have an AD with a parent and a child domain, let's
> say example.com and child.example.com. For the new server I set up, I
> used system provided utilities
> realm join example.com -U '[email protected]'
> which pretty much generates
> 
> root@ubuntu:/var/log/sssd# cat /etc/sssd/sssd.conf
> [sssd]
> domains = example.com
> config_file_version = 2
> services = nss, pam
> [domain/example.com]
> ad_domain = example.com
> krb5_realm = EXAMPLE.COM
> realmd_tags = manages-system joined-with-adcli
> cache_credentials = True
> id_provider = ad
> krb5_store_password_if_offline = True
> default_shell = /bin/bash
> ldap_id_mapping = False
> use_fully_qualified_names = False
> fallback_homedir = /home/%u@%d
> debug_level=9
> access_provider = ad
> 
> Now, everything is OK with the main domain, AFAIK, I can login, sudo
> based on groups, etc. But for the child domain, most work, I can id a
> user@child (that resolves the user and the groups associated), I can
> "su - user@child" from root, BUT I can not login with that user@child.
> Sanitized logs follow :
> 
> sssd_example.com.log
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [get_server_status]
> (0x1000): Status of server '<ad>' is 'working'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [get_port_status]
> (0x1000): Port status of port 389 for server '<ad>' is 'working'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to
> 6 seconds
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [resolve_srv_send]
> (0x0200): The status of SRV lookup is resolved
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [get_server_status]
> (0x1000): Status of server '<ad>' is 'working'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [be_resolve_server_process] (0x1000): Saving the first resolved server
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [be_resolve_server_process] (0x0200): Found address for server <ad>:
> [IP] TTL 3600
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [ad_resolve_callback] (0x0100): Constructed uri 'ldap://<ad>'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://<ad>'
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [unique_filename_destructor] (0x2000): Unlinking
> [/var/lib/sss/pubconf/.krb5info_dummy_ivIwhy]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [unlink_dbg]
> (0x2000): File already removed:
> [/var/lib/sss/pubconf/.krb5info_dummy_ivIwhy]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [sss_domain_get_state] (0x1000): Domain child.example.com is Active
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [child_handler_setup] (0x2000): Setting up signal handler up for pid
> [30303]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [child_handler_setup] (0x2000): Signal handler set up for pid [30303]
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]]
> [write_pipe_handler] (0x0400): All data has been sent!
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [read_pipe_handler]
> (0x0400): EOF received, client finished
> (Thu Jan 31 16:05:24 2019) [sssd[be[example.com]]] [krb5_auth_done]
> (0x0040): The krb5_child process returned an error. Please inspect the
> krb5_child.log file or the journal for more information
> 
> 
> krb5_child.log
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393070: Sending
> TCP request to stream <IP>:88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393071:
> Received answer (317 bytes) from stream <IP>:88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393072:
> Terminating TCP connection to stream <IP>:88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393073:
> Response was from master KDC
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393074:
> Decoding FAST response
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393075: TGS
> request result: -1765328377/Server not found in Kerberos database
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393076:
> Requesting tickets for RestrictedKrbHost/[email protected], referrals
> off

It's hard to say from the trimmed log, but I assume this happens during
the TGT validation phase? If yes, then you could work around that
temporarily by setting:
    krb5_validate = false
in the domain section, but please read the sssd-krb5 manual page to see
what security implications this have

Does it work to request this principal from the command line?
    kinit [email protected]
    kvno RestrictedKrbHost/[email protected]

Is the principal really lower-case and shortname? I would have expected
either lower-case FQDN or an upper-case shortname..

What is in the file
/var/lib/sss/pubconf/krb5.include.d/domain_realm_$domain?

> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393077:
> Generated subkey for TGS request: rc4-hmac/1624
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393078: etypes
> requested in TGS request: aes256-cts, aes128-cts, aes256-sha2,
> aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393080:
> Encoding request body and padata into FAST request
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393081: Sending
> request (1719 bytes) to EXAMPLE.COM
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393082:
> Initiating TCP connection to stream <IP>:88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393083: Sending
> TCP request to stream <IP>:88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393084:
> Received answer (317 bytes) from stream <IP>:88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393085:
> Terminating TCP connection to stream <IP>:88
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393086:
> Response was from master KDC
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393087:
> Decoding FAST response
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393088: TGS
> request result: -1765328377/Server not found in Kerberos database
> (Thu Jan 31 16:05:24 2019) [[sssd[krb5_child[30303]]]]
> [sss_child_krb5_trace_cb] (0x4000): [30303] 1548947124.393089:
> Destroying ccache MEMORY:xwkvpg9
> 
> 
> Do you have any idea why the server is not found in the child domain ?
> Could that be because the wrong server principal may be used ?
> 
> Thanks for your help !
> 
> Jeremy
> _______________________________________________
> sssd-users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/[email protected]
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]

Reply via email to