hi guys
I've been having my IPA deployment trusting AD for a while now and it's been behaving pretty good I must say, except for one thing - kerberos, in some places at least.
What I've needed really, or mainly that trust for, was ssh with gssapi and that is what I'd like to ask about - interaction between IPA and AD when it comes to kerberos - my AD win-clients sometimes would have tickets and be able to ssh with gssapi, some other time it would not work and ssh would ask for passwords.
I cannot really spot any pattern there and I hope some expert could decipher this for me and help to understand what and why that happens.
many thanks, L.
On Thu, 2019-07-11 at 12:09 +0100, lejeczek via FreeIPA-users wrote:
hi guys
I've been having my IPA deployment trusting AD for a while now and it's been behaving pretty good I must say, except for one thing - kerberos, in some places at least.
What I've needed really, or mainly that trust for, was ssh with gssapi and that is what I'd like to ask about - interaction between IPA and AD when it comes to kerberos - my AD win-clients sometimes would have tickets and be able to ssh with gssapi, some other time it would not work and ssh would ask for passwords.
I cannot really spot any pattern there and I hope some expert could decipher this for me and help to understand what and why that happens.
many thanks, L.
Generally there are two main cases:
1) your IPA host lives in a domain that is actually owned by AD, AD will never return a cross-realm ticket and direct their clients to the IPA KDC for domains it owns, so the clients will get back an error when trying to obtain a ticket for those hosts and fall back to password authntication.
2) You are using a non-qualified hostname or an alias (CNAME) that is not registered in the IPA KDC as an alias for the host you want to reach. This causes the client to be unable to obtain a ticket for the target machine falling back to password authentication.
Additional DNS resolution failure may cause these issues too.
Simo.
On 11/07/2019 14:03, Simo Sorce wrote:
On Thu, 2019-07-11 at 12:09 +0100, lejeczek via FreeIPA-users wrote:
hi guys
I've been having my IPA deployment trusting AD for a while now and it's been behaving pretty good I must say, except for one thing - kerberos, in some places at least.
What I've needed really, or mainly that trust for, was ssh with gssapi and that is what I'd like to ask about - interaction between IPA and AD when it comes to kerberos - my AD win-clients sometimes would have tickets and be able to ssh with gssapi, some other time it would not work and ssh would ask for passwords.
I cannot really spot any pattern there and I hope some expert could decipher this for me and help to understand what and why that happens.
many thanks, L.
Generally there are two main cases:
- your IPA host lives in a domain that is actually owned by AD, AD
will never return a cross-realm ticket and direct their clients to the IPA KDC for domains it owns, so the clients will get back an error when trying to obtain a ticket for those hosts and fall back to password authntication.
- You are using a non-qualified hostname or an alias (CNAME) that is
not registered in the IPA KDC as an alias for the host you want to reach. This causes the client to be unable to obtain a ticket for the target machine falling back to password authentication.
Additional DNS resolution failure may cause these issues too.
Simo.
In my setup it's: ipa.ad.domain.local <= one way trust <- ad.domain.local
but hostnames not as depicted above, are FQDN.
And I had gssapi working, very fine without problems but after a couple of weeks and few reboots no gssapi anymore for putty. Nothing has changed that I'm aware of, dns lookups/digs still resolve usual stuff - is there anything kerberos-specific that I should dns-dig?
Only thing that changed was network configuration, slightly. Both IPA & AD nodes had ifaces which connected to two subnets, where each subnet was meant to be dedicated to one domain but still ifaces to both subnets existed on involved nodes. Now AD & IPA are on separate subnets and communicate via a gateway/router.
many thanks, L
On Fri, Jul 12, 2019 at 12:03:42PM +0100, lejeczek via FreeIPA-users wrote:
On 11/07/2019 14:03, Simo Sorce wrote:
On Thu, 2019-07-11 at 12:09 +0100, lejeczek via FreeIPA-users wrote:
hi guys
I've been having my IPA deployment trusting AD for a while now and it's been behaving pretty good I must say, except for one thing - kerberos, in some places at least.
What I've needed really, or mainly that trust for, was ssh with gssapi and that is what I'd like to ask about - interaction between IPA and AD when it comes to kerberos - my AD win-clients sometimes would have tickets and be able to ssh with gssapi, some other time it would not work and ssh would ask for passwords.
I cannot really spot any pattern there and I hope some expert could decipher this for me and help to understand what and why that happens.
many thanks, L.
Generally there are two main cases:
- your IPA host lives in a domain that is actually owned by AD, AD
will never return a cross-realm ticket and direct their clients to the IPA KDC for domains it owns, so the clients will get back an error when trying to obtain a ticket for those hosts and fall back to password authntication.
- You are using a non-qualified hostname or an alias (CNAME) that is
not registered in the IPA KDC as an alias for the host you want to reach. This causes the client to be unable to obtain a ticket for the target machine falling back to password authentication.
Additional DNS resolution failure may cause these issues too.
Simo.
In my setup it's: ipa.ad.domain.local <= one way trust <- ad.domain.local
but hostnames not as depicted above, are FQDN.
And I had gssapi working, very fine without problems but after a couple of weeks and few reboots no gssapi anymore for putty. Nothing has changed that I'm aware of, dns lookups/digs still resolve usual stuff - is there anything kerberos-specific that I should dns-dig?
Only thing that changed was network configuration, slightly. Both IPA & AD nodes had ifaces which connected to two subnets, where each subnet was meant to be dedicated to one domain but still ifaces to both subnets existed on involved nodes. Now AD & IPA are on separate subnets and communicate via a gateway/router.
Hi,
is there a firewall? If yes, are all relevant ports (LDAP, Kerberos, DNS, AD services like ports 137, 138, 139, 445, ...) open in both directions for UDP and TCP?
Please check with 'klist.exe' on the Windows client after trying to log in with putty and GSSAPI what tickets you got besides your TGT. If there a ticket for the IPA host? Is there a cross-realm ticket from the AD to the IPA realm?
bye, Sumit
many thanks, L
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
On 11/07/2019 14:03, Simo Sorce wrote:
On Thu, 2019-07-11 at 12:09 +0100, lejeczek via FreeIPA-users wrote:
hi guys
I've been having my IPA deployment trusting AD for a while now and it's been behaving pretty good I must say, except for one thing - kerberos, in some places at least.
What I've needed really, or mainly that trust for, was ssh with gssapi and that is what I'd like to ask about - interaction between IPA and AD when it comes to kerberos - my AD win-clients sometimes would have tickets and be able to ssh with gssapi, some other time it would not work and ssh would ask for passwords.
I cannot really spot any pattern there and I hope some expert could decipher this for me and help to understand what and why that happens.
many thanks, L.
Generally there are two main cases:
- your IPA host lives in a domain that is actually owned by AD, AD
will never return a cross-realm ticket and direct their clients to the IPA KDC for domains it owns, so the clients will get back an error when trying to obtain a ticket for those hosts and fall back to password authntication.
- You are using a non-qualified hostname or an alias (CNAME) that is
not registered in the IPA KDC as an alias for the host you want to reach. This causes the client to be unable to obtain a ticket for the target machine falling back to password authentication.
Additional DNS resolution failure may cause these issues too.
Simo.
In krb5_child.log
I see: .. PKINIT client has no configured identity; giving up
What is the actually message there, in English? More below:
I also see this and wonder, is that just a formatting of the log/report, for 'pawel' is the user there: "xx.PRIVATE.xx.xx.xpawel"
10.5.4.214 is AD controller.
...
Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [become_user] (0x0200): Already user [1013601116]. (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [k5c_setup] (0x2000): Running as [1013601116][1013601116]. (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [set_lifetime_options] (0x0100): No specific renewable lifetime requested. (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [set_lifetime_options] (0x0100): No specific lifetime requested. (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [main] (0x0400): Will perform offline auth (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [create_empty_ccache] (0x1000): Existing ccache still valid, reusing (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [k5c_send_data] (0x0200): Received error code 0 (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [pack_response_packet] (0x2000): response packet size: [53] (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [k5c_send_data] (0x4000): Response sent. (Fri Jul 12 12:19:45 2019) [[sssd[krb5_child[334378]]]] [main] (0x0400): krb5_child completed successfully (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [main] (0x0400): krb5_child started. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [unpack_buffer] (0x1000): total buffer size: [157] (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [unpack_buffer] (0x0100): cmd [249] uid [1013601116] gid [1013601116] validate [true] enterprise principal [false] offline [true] UPN [pawel@xx.PRIVATE.xx.xx.x] (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [unpack_buffer] (0x0100): ccname: [KEYRING:persistent:1013601116] old_ccname: [KEYRING:persistent:1013601116] keytab: [/etc/krb5.keytab] (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [become_user] (0x0200): Trying to become user [1013601116][1013601116]. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [main] (0x2000): Running as [1013601116][1013601116]. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [become_user] (0x0200): Trying to become user [1013601116][1013601116]. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [become_user] (0x0200): Already user [1013601116]. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [k5c_setup] (0x2000): Running as [1013601116][1013601116]. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [set_lifetime_options] (0x0100): No specific renewable lifetime requested. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [set_lifetime_options] (0x0100): No specific lifetime requested. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [main] (0x0400): Will perform pre-auth (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [tgt_req_child] (0x1000): Attempting to get a TGT (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [get_and_save_tgt] (0x0400): Attempting kinit for realm [xx.PRIVATE.xx.xx.x] (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443932: Getting initial credentials for pawel@xx.PRIVATE.xx.xx.x (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443934: Sending unauthenticated request (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443935: Sending request (191 bytes) to xx.PRIVATE.xx.xx.x (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443936: Initiating TCP connection to stream 10.5.4.214:88 (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443937: Sending TCP request to stream 10.5.4.214:88 (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443938: Received answer (212 bytes) from stream 10.5.4.214:88 (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443939: Terminating TCP connection to stream 10.5.4.214:88 (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443940: Response was from master KDC (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443941: Received error from KDC: -1765328359/Additional pre-authentication required (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443944: Preauthenticating using KDC method data (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443945: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2) (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443946: Selected etype info: etype aes256-cts, salt "xx.PRIVATE.xx.xx.xpawel", params "" (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443947: PKINIT client has no configured identity; giving up (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_krb5_responder] (0x4000): Got question [password]. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443948: PKINIT client has no configured identity; giving up (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443949: Preauth module pkinit (16) (real) returned: 22/Invalid argument (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443950: PKINIT client has no configured identity; giving up (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443951: Preauth module pkinit (14) (real) returned: 22/Invalid argument (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_krb5_prompter] (0x4000): sss_krb5_prompter name [(null)] banner [(null)] num_prompts [1] EINVAL. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_krb5_prompter] (0x4000): Prompt [0][Password for pawel@xx.PRIVATE.xx.xx.x]. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_krb5_prompter] (0x0020): Cannot handle password prompts. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [sss_child_krb5_trace_cb] (0x4000): [334735] 1562934058.443952: Preauth module encrypted_timestamp (2) (real) returned: -1765328254/Cannot read password (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [get_and_save_tgt] (0x0400): krb5_get_init_creds_password returned [-1765328174] during pre-auth. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [k5c_send_data] (0x0200): Received error code 0 (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [pack_response_packet] (0x2000): response packet size: [12] (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [k5c_send_data] (0x4000): Response sent. (Fri Jul 12 12:20:58 2019) [[sssd[krb5_child[334735]]]] [main] (0x0400): krb5_child completed successfully
freeipa-users@lists.fedorahosted.org
-
lejeczek -
Simo Sorce -
Sumit Bose