I've got IPA running on an EL7.1 box for the domain NWRA.COM. I established a trust with our active directory domain (AD.NWRA.COM). The trust seem to be working mostly correctly, I can auto-login with AD kerberos tickets for example.
However, password authentication for the AD users does not appear to be working:
$ su - orion@AD.NWRA.COM Password: su: Authentication failure
sssd log shows:
(Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user [orion@ad.nwra.com] found. (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_server_status] (0x1000): Status of server 'ipa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'europa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_server_status] (0x1000): Status of server 'europa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [be_resolve_server_process] (0x0200): Found address for server ipa.nwra.com: [X.X.X.X] TTL 86400 (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [17483] (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [17483] (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [child_sig_handler] (0x1000): Waiting for child [17483]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [child_sig_handler] (0x0100): child [17483] finished successfully. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][3][40]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741822][18]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741823][32]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): TGT times are [1427485903][1427485903][1427521903][1427572303]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][6][8]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [krb5_auth_done] (0x0020): UPN used in the request [Orion Poplawski@AD.NWRA.COM] and returned UPN [orion@AD.NWRA.COM] differ by more than just the case. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success] (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][ad.nwra.com] (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][ad.nwra.com]
The UPN message seems like an issue. Ideas?
ipa-server-4.1.0-18.sl7_1.3.x86_64 sssd-1.12.2-58.el7.x86_64
On 03/27/2015 02:01 PM, Orion Poplawski wrote:
I've got IPA running on an EL7.1 box for the domain NWRA.COM. I established a trust with our active directory domain (AD.NWRA.COM). The trust seem to be working mostly correctly, I can auto-login with AD kerberos tickets for example.
However, password authentication for the AD users does not appear to be working:
$ su - orion@AD.NWRA.COM Password: su: Authentication failure
sssd log shows:
(Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [krb5_auth_done] (0x0020): UPN used in the request [Orion Poplawski@AD.NWRA.COM] and returned UPN [orion@AD.NWRA.COM] differ by more than just the case.
The UPN message seems like an issue. Ideas?
ipa-server-4.1.0-18.sl7_1.3.x86_64 sssd-1.12.2-58.el7.x86_64
Possibly relevant commit:
$ git show 7c4845bd0efb1dcb44b5be52923c539316725693 commit 7c4845bd0efb1dcb44b5be52923c539316725693 Author: Sumit Bose sbose@redhat.com Date: Wed Oct 24 10:01:09 2012 +0200
krb5_auth: update with correct UPN if needed
The Active Directory KDC handles request case in-sensitive and it might not always to possible to guess the UPN with the correct case. We check if the returned principal has a different case then the one used in the request and updates the principal if needed. This will help using calls from the Kerberos client libraries later on which would otherwise fail because the principal is handled case sensitive by those libraries.
diff --git a/src/providers/krb5/krb5_auth.c b/src/providers/krb5/krb5_auth.c index c1f9f14..f2e00fa 100644 --- a/src/providers/krb5/krb5_auth.c +++ b/src/providers/krb5/krb5_auth.c @@ -782,6 +782,36 @@ static void krb5_child_done(struct tevent_req *subreq) } }
+ /* Check if the cases of our upn are correct and update it if needed. + * Fail if the upn differs by more than just the case. */ + if (res->correct_upn != NULL && + strcmp(kr->upn, res->correct_upn) != 0) { + if (strcasecmp(kr->upn, res->correct_upn) == 0) { + talloc_free(kr->upn); + kr->upn = talloc_strdup(kr, res->correct_upn); + if (kr->upn == NULL) { + DEBUG(SSSDBG_OP_FAILURE, ("talloc_strdup failed.\n")); + ret = ENOMEM; + goto done; + } + + ret = check_if_cached_upn_needs_update(state->sysdb, pd->user, + res->correct_upn); + if (ret != EOK) { + DEBUG(SSSDBG_OP_FAILURE, + ("check_if_cached_upn_needs_update failed.\n")); + goto done; + } + } else { + DEBUG(SSSDBG_CRIT_FAILURE, ("UPN used in the request [%s] and " \ + "returned UPN [%s] differ by more " \ + "than just the case.\n", + kr->upn, res->correct_upn)); + ret = EINVAL; + goto done; + } + } + /* If the child request failed, but did not return an offline error code, * return with the status */ if (res->msg_status != PAM_SUCCESS && diff --git a/src/providers/krb5/krb5_utils.c b/src/providers/krb5/krb5_utils.c index 9837616..6cfd48c 100644 --- a/src/providers/krb5/krb5_utils.c +++ b/src/providers/krb5/krb5_utils.c @@ -57,6 +57,105 @@ errno_t find_or_guess_upn(TALLOC_CTX *mem_ctx, struct ldb_message *msg, return EOK; }
+errno_t check_if_cached_upn_needs_update(struct sysdb_ctx *sysdb, + const char *user, + const char *upn) +{ + TALLOC_CTX *tmp_ctx; + int ret; + int sret; + const char *attrs[] = {SYSDB_UPN, NULL}; + struct sysdb_attrs *new_attrs; + struct ldb_result *res; + bool in_transaction = false; + const char *cached_upn; + + if (sysdb == NULL || user == NULL || upn == NULL) { + return EINVAL; + } + + tmp_ctx = talloc_new(NULL); + if (tmp_ctx == NULL) { + DEBUG(SSSDBG_OP_FAILURE, ("talloc_new failed.\n")); + return ENOMEM; + } + + ret = sysdb_get_user_attr(tmp_ctx, sysdb, user, attrs, &res); + if (ret != EOK) { + DEBUG(SSSDBG_OP_FAILURE, ("sysdb_get_user_attr failed.\n")); + goto done; + } + + if (res->count != 1) { + DEBUG(SSSDBG_OP_FAILURE, ("[%d] user objects for name [%s] found, " \ + "expected 1.\n", res->count, user)); + ret = EINVAL; + goto done; + } + + cached_upn = ldb_msg_find_attr_as_string(res->msgs[0], SYSDB_UPN, NULL); + + if (cached_upn != NULL && strcmp(cached_upn, upn) == 0) { + DEBUG(SSSDBG_TRACE_ALL, ("Cached UPN and new one match, " + "nothing to do.\n")); + ret = EOK; + goto done; + } + + DEBUG(SSSDBG_TRACE_LIBS, ("Replacing UPN [%s] with [%s] for user [%s].\n", + cached_upn, upn, user)); + + new_attrs = sysdb_new_attrs(tmp_ctx); + if (new_attrs == NULL) { + DEBUG(SSSDBG_OP_FAILURE, ("sysdb_new_attrs failed.\n")); + ret = ENOMEM; + goto done; + } + + ret = sysdb_attrs_add_string(new_attrs, SYSDB_UPN, upn); + if (ret != EOK) { + DEBUG(SSSDBG_OP_FAILURE, ("sysdb_attrs_add_string failed.\n")); + goto done; + } + + ret = sysdb_transaction_start(sysdb); + if (ret != EOK) { + DEBUG(SSSDBG_OP_FAILURE, + ("Error %d starting transaction (%s)\n", ret, strerror(ret))); + goto done; + } + in_transaction = true; + + ret = sysdb_set_entry_attr(sysdb, res->msgs[0]->dn, new_attrs, + SYSDB_MOD_REP); + if (ret != EOK) { + DEBUG(SSSDBG_OP_FAILURE, ("sysdb_set_entry_attr failed [%d][%s].\n", + ret, strerror(ret))); + goto done; + } + + ret = sysdb_transaction_commit(sysdb); + if (ret != EOK) { + DEBUG(SSSDBG_OP_FAILURE, ("Failed to commit transaction!\n")); + goto done; + } + in_transaction = false; + + ret = EOK; + +done: + if (in_transaction) { + sret = sysdb_transaction_cancel(sysdb); + if (sret != EOK) { + DEBUG(SSSDBG_CRIT_FAILURE, ("Failed to cancel transaction\n")); + } + } + + talloc_free(tmp_ctx); + + return ret; +} + char *expand_ccname_template(TALLOC_CTX *mem_ctx, struct krb5child_req *kr, const char *template, bool file_mode, bool case_sensitive, bool *private_path) diff --git a/src/providers/krb5/krb5_utils.h b/src/providers/krb5/krb5_utils.h index 2848545..25d8c6c 100644 --- a/src/providers/krb5/krb5_utils.h +++ b/src/providers/krb5/krb5_utils.h @@ -37,6 +37,10 @@ errno_t find_or_guess_upn(TALLOC_CTX *mem_ctx, struct ldb_message *msg, const char *domain_name, const char *user, const char *user_dom, char **_upn);
+errno_t check_if_cached_upn_needs_update(struct sysdb_ctx *sysdb, + const char *user, + const char *upn); + /* Operations on a credential cache */ typedef errno_t (*cc_be_create_fn)(const char *location, pcre *illegal_re, uid_t uid, gid_t gid, bool private_path);
On 03/27/2015 02:01 PM, Orion Poplawski wrote:
I've got IPA running on an EL7.1 box for the domain NWRA.COM. I established a trust with our active directory domain (AD.NWRA.COM). The trust seem to be working mostly correctly, I can auto-login with AD kerberos tickets for example.
However, password authentication for the AD users does not appear to be working:
$ su - orion@AD.NWRA.COM Password: su: Authentication failure
sssd log shows:
(Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [krb5_auth_done] (0x0020): UPN used in the request [Orion Poplawski@AD.NWRA.COM] and returned UPN [orion@AD.NWRA.COM] differ by more than just the case.
The UPN message seems like an issue. Ideas?
Indeed. This appears to be user error. Being the AD newbie that I am, I had no idea that our logon UPNs do appear to be currently using the full name, e.g. "Orion Poplawski@ad.nwra.com". Changing it to orion fixed it. I wonder how this came to be.
Sorry for the noise, perhaps it will help someone in the future...
On (27/03/15 14:01), Orion Poplawski wrote:
I've got IPA running on an EL7.1 box for the domain NWRA.COM. I established a trust with our active directory domain (AD.NWRA.COM). The trust seem to be working mostly correctly, I can auto-login with AD kerberos tickets for example.
However, password authentication for the AD users does not appear to be working:
$ su - orion@AD.NWRA.COM Password: su: Authentication failure
sssd log shows:
(Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user [orion@ad.nwra.com] found. (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_server_status] (0x1000): Status of server 'ipa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'europa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_server_status] (0x1000): Status of server 'europa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [be_resolve_server_process] (0x0200): Found address for server ipa.nwra.com: [X.X.X.X] TTL 86400 (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [17483] (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [17483] (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [child_sig_handler] (0x1000): Waiting for child [17483]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [child_sig_handler] (0x0100): child [17483] finished successfully. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][3][40]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741822][18]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741823][32]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): TGT times are [1427485903][1427485903][1427521903][1427572303]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][6][8]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [krb5_auth_done] (0x0020): UPN used in the request [Orion Poplawski@AD.NWRA.COM] and returned UPN [orion@AD.NWRA.COM] differ by more than just the case. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
I know that you fixed your problem, but pam error code 4 (System error) should not happend in sssd It means some serious problem.
It can be related to the pevious debug message "krb5_auth_recv request failed."
Could you provide domain log file and krb5_child.log with enabled verbose logging? (put debug_level = 0xfff0 into domain section.
LS
On Fri, Mar 27, 2015 at 10:09:43PM +0100, Lukas Slebodnik wrote:
On (27/03/15 14:01), Orion Poplawski wrote:
I've got IPA running on an EL7.1 box for the domain NWRA.COM. I established a trust with our active directory domain (AD.NWRA.COM). The trust seem to be working mostly correctly, I can auto-login with AD kerberos tickets for example.
However, password authentication for the AD users does not appear to be working:
$ su - orion@AD.NWRA.COM Password: su: Authentication failure
sssd log shows:
(Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user [orion@ad.nwra.com] found. (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_server_status] (0x1000): Status of server 'ipa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_port_status] (0x1000): Port status of port 0 for server 'europa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [get_server_status] (0x1000): Status of server 'europa.nwra.com' is 'working' (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [be_resolve_server_process] (0x0200): Found address for server ipa.nwra.com: [X.X.X.X] TTL 86400 (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [17483] (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [child_handler_setup] (0x2000): Signal handler set up for pid [17483] (Fri Mar 27 13:51:42 2015) [sssd[be[nwra.com]]] [write_pipe_handler] (0x0400): All data has been sent! (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [child_sig_handler] (0x1000): Waiting for child [17483]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [child_sig_handler] (0x0100): child [17483] finished successfully. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [read_pipe_handler] (0x0400): EOF received, client finished (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][3][40]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741822][18]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][-1073741823][32]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): TGT times are [1427485903][1427485903][1427521903][1427572303]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [parse_krb5_child_response] (0x1000): child response [0][6][8]. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [krb5_auth_done] (0x0020): UPN used in the request [Orion Poplawski@AD.NWRA.COM] and returned UPN [orion@AD.NWRA.COM] differ by more than just the case. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [ipa_auth_handler_done] (0x0040): krb5_auth_recv request failed. (Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
I know that you fixed your problem, but pam error code 4 (System error) should not happend in sssd It means some serious problem.
It can be related to the pevious debug message "krb5_auth_recv request failed."
Could you provide domain log file and krb5_child.log with enabled verbose logging? (put debug_level = 0xfff0 into domain section.
Yes, in addition, it would be nice to see the output of KRB5_TRACE=/dev/stderr kinit -E -C orion@ad.nwra.com
Also, the UPN attribute of your user is really "Orion Poplawski@AD.NWRA.COM" ?
On 03/30/2015 01:55 AM, Jakub Hrozek wrote:
On Fri, Mar 27, 2015 at 10:09:43PM +0100, Lukas Slebodnik wrote:
On (27/03/15 14:01), Orion Poplawski wrote:
(Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
I know that you fixed your problem, but pam error code 4 (System error) should not happend in sssd It means some serious problem.
It can be related to the pevious debug message "krb5_auth_recv request failed."
Could you provide domain log file and krb5_child.log with enabled verbose logging? (put debug_level = 0xfff0 into domain section.
Yes, in addition, it would be nice to see the output of KRB5_TRACE=/dev/stderr kinit -E -C orion@ad.nwra.com
Also, the UPN attribute of your user is really "Orion Poplawski@AD.NWRA.COM" ?
A mistake in an AD update set it to that. Obviously it should be orion@AD.NWRA.COM, and is fixed now. Do you still want the kinit trace for this configuration error?
On Wed, 1 Apr 2015, Orion Poplawski wrote:
A mistake in an AD update set it to that. Obviously it should be orion@AD.NWRA.COM, and is fixed now. Do you still want the kinit trace for this configuration error?
I still see this as a bug in the AD provider. userPrincipalName in AD does *not* reliably map to the name of the user Principal. It's an alias for the username you can use at login, but it doesn't relate to kerberos AFAIK.
With our ldap/krb5 config (that we've *still* not switched over to use the ad provider), we use:
ldap_user_principal = checkundefinedattribute
This was, it hits an undefined attribute, and simply defaults to the reliably correct value.
jh
On Wed, Apr 01, 2015 at 09:03:07AM +0100, John Hodrien wrote:
On Wed, 1 Apr 2015, Orion Poplawski wrote:
A mistake in an AD update set it to that. Obviously it should be orion@AD.NWRA.COM, and is fixed now. Do you still want the kinit trace for this configuration error?
I still see this as a bug in the AD provider.
I agree, I would expect the AD provider to handle this with canonicalization.
But I'm not sure the krb5 trace would be useful now if the UPN value has been re-set on the AD side..
userPrincipalName in AD does *not* reliably map to the name of the user Principal. It's an alias for the username you can use at login, but it doesn't relate to kerberos AFAIK.
With our ldap/krb5 config (that we've *still* not switched over to use the ad provider), we use:
ldap_user_principal = checkundefinedattribute
This was, it hits an undefined attribute, and simply defaults to the reliably correct value.
jh _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 03/30/2015 01:55 AM, Jakub Hrozek wrote:
On Fri, Mar 27, 2015 at 10:09:43PM +0100, Lukas Slebodnik wrote:
On (27/03/15 14:01), Orion Poplawski wrote:
(Fri Mar 27 13:51:43 2015) [sssd[be[nwra.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 4, <NULL>) [Success]
I know that you fixed your problem, but pam error code 4 (System error) should not happend in sssd It means some serious problem.
It can be related to the pevious debug message "krb5_auth_recv request failed."
Could you provide domain log file and krb5_child.log with enabled verbose logging? (put debug_level = 0xfff0 into domain section.
Yes, in addition, it would be nice to see the output of KRB5_TRACE=/dev/stderr kinit -E -C orion@ad.nwra.com
Also, the UPN attribute of your user is really "Orion Poplawski@AD.NWRA.COM" ?
I reset the UPN attribute back to this, so:
# KRB5_TRACE=/dev/stderr kinit -E -C orion@ad.nwra.com [14682] 1427923299.541804: Getting initial credentials for orion@ad.nwra.com@AD.NWRA.COM [14682] 1427923299.542508: Sending request (177 bytes) to AD.NWRA.COM [14682] 1427923299.544866: Resolving hostname XXXX.ad.nwra.com. [14682] 1427923299.546848: Sending initial UDP request to dgram X.X.X.X:88 [14682] 1427923299.595880: Received answer (181 bytes) from dgram X.X.X:88 [14682] 1427923299.597244: Response was not from master KDC [14682] 1427923299.597840: Received error from KDC: -1765328359/Additional pre-authentication required [14682] 1427923299.598759: Processing preauth types: 16, 15, 19, 2 [14682] 1427923299.599345: Selected etype info: etype aes256-cts, salt "NWRA.LOCALorion", params "" Password for orion@ad.nwra.com@AD.NWRA.COM: [14682] 1427923307.894606: AS key obtained for encrypted timestamp: aes256-cts/EB95 [14682] 1427923307.895120: Encrypted timestamp (for 1427923308.62326): plain 301AA011180F32303135303430313231323134385AA105020300F376, encrypted A0B0AD5BD340BBB7F2D4AC53F36AAF5BA7C3015EECCF8BA45AD9E7588402CCCEBD4AE88675FB49C17552BC867B0B7A2858A20B03E6538456 [14682] 1427923307.895352: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [14682] 1427923307.895803: Produced preauth for next request: 2 [14682] 1427923307.896316: Sending request (255 bytes) to AD.NWRA.COM [14682] 1427923307.898545: Resolving hostname XXXXX.ad.nwra.com. [14682] 1427923307.899718: Sending initial UDP request to dgram X.X.X.X:88 [14682] 1427923307.965212: Received answer (94 bytes) from dgram X.X.X.X:88 [14682] 1427923307.966477: Response was not from master KDC [14682] 1427923307.967176: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP [14682] 1427923307.967478: Request or response is too big for UDP; retrying with TCP [14682] 1427923307.968229: Sending request (255 bytes) to AD.NWRA.COM (tcp only) [14682] 1427923307.969800: Resolving hostname XXXXXX.ad.nwra.com. [14682] 1427923307.972228: Initiating TCP connection to stream X.X.X.X:88 [14682] 1427923308.15548: Sending TCP request to stream X.X.X.X:88 [14682] 1427923308.104200: Received answer (1503 bytes) from stream X.X.X.X:88 [14682] 1427923308.104497: Terminating TCP connection to stream X.X.X.X:88 [14682] 1427923308.106137: Response was not from master KDC [14682] 1427923308.106752: Processing preauth types: 19 [14682] 1427923308.107281: Selected etype info: etype aes256-cts, salt "NWRA.LOCALorion", params "" [14682] 1427923308.107819: Produced preauth for next request: (empty) [14682] 1427923308.108421: AS key determined by preauth: aes256-cts/EB95 [14682] 1427923308.109253: Decrypted AS reply; session key is: aes256-cts/300B [14682] 1427923308.109691: FAST negotiation: unavailable [14682] 1427923308.110190: Initializing KEYRING:persistent:0:0 with default princ orion@AD.NWRA.COM [14682] 1427923308.110709: Removing orion@AD.NWRA.COM -> krbtgt/AD.NWRA.COM@AD.NWRA.COM from KEYRING:persistent:0:0 [14682] 1427923308.111274: Storing orion@AD.NWRA.COM -> krbtgt/AD.NWRA.COM@AD.NWRA.COM in KEYRING:persistent:0:0 [14682] 1427923308.111718: Storing config in KEYRING:persistent:0:0 for krbtgt/AD.NWRA.COM@AD.NWRA.COM: pa_type: 2 [14682] 1427923308.111953: Removing orion@AD.NWRA.COM -> krb5_ccache_conf_data/pa_type/krbtgt/AD.NWRA.COM@AD.NWRA.COM@X-CACHECONF: from KEYRING:persistent:0:0 [14682] 1427923308.112255: Storing orion@AD.NWRA.COM -> krb5_ccache_conf_data/pa_type/krbtgt/AD.NWRA.COM@AD.NWRA.COM@X-CACHECONF: in KEYRING:persistent:0:0
So one interesting thing I see is mention of NWRA.LOCAL. This is what our AD domain used to be before we renamed it AD.NWRA.COM, so perhaps there are still some remnants in there.
Also, while the UPN was Orion Poplawski@AD.NWRA.COM, the "pre-2000" logon name was still "NWRA\orion".
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
John Hodrien -
Lukas Slebodnik -
Orion Poplawski