[Samba] [PATCH] Re: S4-Winbind dumping core on password
smk_va
smk_va at yahoo.com
Thu Sep 4 11:47:28 MDT 2014
The workaround to this seems to be,
chmod 640 /etc/krb5.keytab
This suggests the failure is due to a permissions-check issue, not an access issue, as /etc/krb5.keytab has group root, and the only member of the group root is the user root, per defaults.
(As an aside, winbindd code appears not to be fully working with linux kernel KEYRING caches, as discussed below; I've added a comment to BZ 10132.)
The following bugs,
https://bugzilla.samba.org/show_bug.cgi?id=6833
https://bugzilla.samba.org/show_bug.cgi?id=10490
appear to identify the same issue as here. However, the patch offered in the latter BZ appears incomplete. On plain-text login, with the patch applied and kerberos method = system keytab, winbindd_dual_pam_auth gives,
winbindd_dual_pam_auth_kerberos failed: NT_STATUS_INTERNAL_ERROR
and falls back to samlogon.
The workaround involving setting the ccache type to KEYRING appears to be bogus -- winbind appears not to recognize KEYRING caches as yet, so this setting forces pam_winbind to fail kerberos auth and fallback to samlogon. Changing the ccache type to KEYRING in /etc/security/pam_winbind.conf in an otherwise working configuration results in:
[2014/09/04 12:07:22.628028, 10, pid=8781, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_pam.c:1113(winbindd_dual_pam_auth_kerberos)
winbindd_dual_pam_auth_kerberos
[2014/09/04 12:07:22.628109, 10, pid=8781, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_pam.c:531(generate_krb5_ccache)
using ccache: KEYRING:persistent:<UID>
[2014/09/04 12:07:22.628210, 10, pid=8781, effective(<UID>, 0), real(<UID>, 0), class=winbind] ../source3/winbindd/winbindd_pam.c:642(winbindd_raw_kerberos_login)
winbindd_raw_kerberos_login: uid is <UID>
[2014/09/04 12:07:22.628468, 3, pid=8781, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_pam.c:729(winbindd_raw_kerberos_login)
winbindd_raw_kerberos_login: could not destroy krb5 credential cache: Unknown credential cache type
[2014/09/04 12:07:22.628528, 3, pid=8781, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_pam.c:735(winbindd_raw_kerberos_login)
winbindd_raw_kerberos_login: could not remove ccache for user <DOMAIN>\<username>
[2014/09/04 12:07:22.628573, 10, pid=8781, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_pam.c:1683(winbindd_dual_pam_auth)
winbindd_dual_pam_auth_kerberos failed: NT_STATUS_UNSUCCESSFUL
[2014/09/04 12:07:22.628619, 3, pid=8781, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_pam.c:1712(winbindd_dual_pam_auth)
falling back to samlogon
On Tuesday, August 5, 2014 9:42 PM, smk_va <smk_va at yahoo.com> wrote:
I applied the patch against sernet-samba-4.1.10 and the symptoms still appear to be the same (please see below output from running "valgrind --trace-children=yes winbindd". However, I took your point about kerberos method configuration and ran some tests with samba 3.6 and 4.1. Following are our findings, and the issue seems to boil down to plaintext authentication not working with kerberos method = system keytab. I would appreciate feedback on our findings below, particularly whether failing password logins with kerberos method = system keytab are a bug or a feature (seems a bug, but my understanding of Kerberos internals is, err, limited).
1.) With kerberos method = secrets (the default), logging in with a domain account using ssh works fine for passwordless logins (gssapi-with-mic) as well as for password-based authentication. Winbind log shows:
winbindd/winbindd_pam.c:1806(winbindd_dual_pam_auth)
Plain-text authentication for user MYDOMAIN\myusername returned NT_STATUS_OK (PAM: 0)
2.) With kerberos method = system keytab, passwordless logins with domain accounts (ssh/gssapi) work fine. Password-based logins fail under samba 3.6 with:
winbindd/winbindd_pam.c:1621(winbindd_dual_pam_auth)
winbindd_dual_pam_auth_kerberos failed: NT_STATUS_LOGON_FAILURE
winbindd/winbindd_pam.c:1806(winbindd_dual_pam_auth)
Plain-text authentication for user MYDOMAIN\myusername returned NT_STATUS_LOGON_FAILURE (PAM: 7)
However, with samba 4.1, and kerberos method = system keytab, password-based login fails and winbind issues a PANIC and stack-trace.
3.) Finally, with kerberos method = secrets and keytab, winbind authentication seems to have changed between 3.6 and 4.1 (and likely, 4.0). Whereas samba-3.6 winbind successfully authenticates plain-text passwords just as when kerberos method = secrets only; samba-4.1 winbind fails just as when kerberos method = system keytab is configured.
My issue arose because of the change in behavior between samba-3.6 and samba-4 in (3.) above. Configuring kerberos method = secrets only (the default) seems to take care of my issue as far as I can tell (we do not need special accounts/SPNs for running samba/cifs). However, it would be nice to have a cleaner setup (no samba PANICs), and to understand the plaintext authentication issue when kerberos method = system keytab.
Thanks for the help,
Murthy
==27847==
==27847== HEAP SUMMARY:
==27847== in use at exit: 24,713 bytes in 197 blocks
==27847== total heap usage: 20,941 allocs, 20,744 frees, 4,264,250 bytes allocated
==27847==
==27847== LEAK SUMMARY:
==27847== definitely lost: 26 bytes in 2 blocks
==27847== indirectly lost: 0 bytes in 0 blocks
==27847== possibly lost: 21,339 bytes in 128 blocks
==27847== still reachable: 3,348 bytes in 67 blocks
==27847== suppressed: 0 bytes in 0 blocks
==27847== Rerun with --leak-check=full to see details of leaked memory
==27847==
==27847== For counts of detected and suppressed errors, rerun with: -v
==27847== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
==27848==
==27848== HEAP SUMMARY:
==27848== in use at exit: 51,366 bytes in 305 blocks
==27848== total heap usage: 4,261 allocs, 3,956 frees, 2,631,685 bytes allocated
==27848==
==27848== LEAK SUMMARY:
==27848== definitely lost: 26 bytes in 2 blocks
==27848== indirectly lost: 0 bytes in 0 blocks
==27848== possibly lost: 46,744 bytes in 219 blocks
==27848== still reachable: 4,596 bytes in 84 blocks
==27848== suppressed: 0 bytes in 0 blocks
==27848== Rerun with --leak-check=full to see details of leaked memory
==27848==
==27848== For counts of detected and suppressed errors, rerun with: -v
==27848== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)
==27896== Invalid read of size 8
==27896== at 0x778DAAE: krb5_storage_free (store.c:273)
==27896== by 0x777934C: fkt_end_seq_get (keytab_file.c:520)
==27896== by 0x777805D: krb5_kt_end_seq_get (keytab.c:795)
==27896== by 0x942AF89: fill_mem_keytab_from_system_keytab (gse_krb5.c:478)
==27896== by 0x942B097: gse_krb5_get_server_keytab (gse_krb5.c:589)
==27896== by 0x942CC63: gensec_gse_server_start (gse.c:345)
==27896== by 0x83FF414: gensec_start_mech (gensec_start.c:663)
==27896== by 0x8400823: gensec_start_mech_by_oid (gensec_start.c:761)
==27896== by 0x1325D2: kerberos_return_pac (authdata.c:255)
==27896== by 0x145D3B: winbindd_dual_pam_auth (winbindd_pam.c:645)
==27896== by 0x15ABD9: child_handler (winbindd_dual.c:459)
==27896== by 0x58BBA7B: epoll_event_loop_once (tevent_epoll.c:736)
==27896== Address 0x28 is not stack'd, malloc'd or (recently) free'd
==27896==
==27896==
==27896== HEAP SUMMARY:
==27896== in use at exit: 100,438 bytes in 582 blocks
==27896== total heap usage: 107,032 allocs, 106,450 frees, 38,620,131 bytes allocated
==27896==
==27896== LEAK SUMMARY:
==27896== definitely lost: 2,495 bytes in 3 blocks
==27896== indirectly lost: 0 bytes in 0 blocks
==27896== possibly lost: 62,241 bytes in 290 blocks
==27896== still reachable: 35,702 bytes in 289 blocks
==27896== suppressed: 0 bytes in 0 blocks
==27896== Rerun with --leak-check=full to see details of leaked memory
==27896==
==27896== For counts of detected and suppressed errors, rerun with: -v
==27896== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 48 from 9)
On Friday, August 1, 2014 11:12 AM, smk_va <smk_va at yahoo.com> wrote:
Andrew, thanks, I'll try the patch and get back to you shortly.
I'll note that, yes, smb.conf has:
kerberos method = secrets and keytab
However, I think I have a working system keytab in /etc/krb5.keytab, as I get a valid ticket with:
kinit -k `hostname -s | tr a-z A-Z`$
(used for mounting cifs shares with the machine account's credentials).
So I'm wondering if this really is the issue, but let's see what we learn from a patched samba4.
Thanks,
Murthy
On Friday, August 1, 2014 12:12 AM, Andrew Bartlett <abartlet at samba.org> wrote:
On Tue, 2014-07-29 at 12:04 -0700, smk_va wrote:
> I'm still having the issue that password authentication to a domain account appears to cause sernet-samba-winbind to dump core. I've attached output from reproducing the error with "valgrind --trace-children=yes winbindd", but this time with the debuginfo package installed (which appears to give more informtaion). Help getting samba-4.1 working in our AD environment would be much appreciated.
Try this patch.
I suspect this is happening because you are using 'kerberos method = system' or
similar but have no system keytab.
Andrew Bartlett
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
More information about the samba
mailing list