George Diamantopoulos
2012-Mar-29 21:02 UTC
[Samba] Samba 4 KVNO mismatch - Failure to join AD domain (Windows & Freenas)
Hello all, I've run into the issue described here: http://lists.samba.org/archive/samba-technical/2010-September/073075.html To sum it up, I installed samba4 from git on a debian wheezy system. Initially, I was able to join Windows 7 clients to the AD controller. However, trying to get freenas 8 to join has been failing. In the end, trying to get it to work I changed administrator's password (via dsa.msc) which broke AD joining for windows clients too. KVNO in secrets.keytab file has always been "1". Could this mismatch be the cause of the failures? I rebooted all clients (to get rid of stale tickets) to no avail. The only way to fix this was to run the provision script again, but now samba is not very stable (I managed to join the AD domain, but upon login I get The security database on the server does not have a computer account for this workstation trust relationship). I really don't know where to start. Do you think using samba from debian SID would be wiser than building from git? Are there any other errors in the log I didn't spot? Is KVNO mismatch the reason joining fails, or are there more errors? Thanks. Kerberos: AS-REQ administrator at SYNDOM.SYNERGYPROJECT.GR from ipv4:172.17.172.41:13893 for krbtgt/SYNDOM.SYNERGYPROJECT.GR at SYNDOM.SYNERGYPROJECT.GR Kerberos: No preauth found, returning PREAUTH-REQUIRED -- administrator at SYNDOM.SYNERGYPROJECT.GR Kerberos: AS-REQ administrator at SYNDOM.SYNERGYPROJECT.GR from ipv4:172.17.172.41:44144 for krbtgt/SYNDOM.SYNERGYPROJECT.GR at SYNDOM.SYNERGYPROJECT.GR Kerberos: Client sent patypes: encrypted-timestamp Kerberos: Looking for PKINIT pa-data -- administrator at SYNDOM.SYNERGYPROJECT.GR Kerberos: Looking for ENC-TS pa-data -- administrator at SYNDOM.SYNERGYPROJECT.GR Kerberos: ENC-TS Pre-authentication succeeded -- administrator at SYNDOM.SYNERGYPROJECT.GR using arcfour-hmac-md5 Kerberos: AS-REQ authtime: 2012-03-29T23:45:08 starttime: unset endtime: 2012-03-30T09:45:07 renew till: unset Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, des3-cbc-md5, arcfour-hmac-md5, des-cbc-md5, des-cbc-md4, des-cbc-crc, using arcfour-hmac-md5/arcfour-hmac-md5 Kerberos: Requested flags: forwardable Kerberos: TGS-REQ administrator at SYNDOM.SYNERGYPROJECT.GR from ipv4:172.17.172.41:38698 for ldap/adpdc.syndom.synergyproject.gr at SYNDOM.SYNERGYPROJECT.GR Kerberos: TGS-REQ authtime: 2012-03-29T23:45:08 starttime: 2012-03-29T23:45:08 endtime: 2012-03-30T09:45:07 renew till: unset Terminating connection - 'kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[kdc_tcp_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] --- important bit ???? --- GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Failed to find ADPDC$@SYNDOM.SYNERGYPROJECT.GR(kvno 3) in keytab FILE:/usr/local/samba/private/secrets.keytab (arcfour-hmac-md5) SPNEGO(gssapi_krb5) NEG_TOKEN_INIT failed: NT_STATUS_LOGON_FAILURE SPNEGO login failed: NT_STATUS_LOGON_FAILURE ------------------------------- Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] ldb_wrap open of secrets.ldb auth_check_password_send: Checking password for unmapped user [SYNDOM]\[Administrator]@[(null)] auth_check_password_send: mapped user is: [SYNDOM]\[Administrator]@[(null)] Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] ldb_wrap open of secrets.ldb auth_check_password_send: Checking password for unmapped user [SYNDOM]\[Administrator]@[(null)] auth_check_password_send: mapped user is: [SYNDOM]\[Administrator]@[(null)] Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED] ldb_wrap open of secrets.ldb auth_check_password_send: Checking password for unmapped user [SYNDOM]\[Administrator]@[(null)] auth_check_password_send: mapped user is: [SYNDOM]\[Administrator]@[(null)] Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED' single_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]
Andrew Bartlett
2012-Apr-04 10:22 UTC
[Samba] Samba 4 KVNO mismatch - Failure to join AD domain (Windows & Freenas)
On Fri, 2012-03-30 at 00:02 +0300, George Diamantopoulos wrote:> Hello all, > > I've run into the issue described here: > http://lists.samba.org/archive/samba-technical/2010-September/073075.html > > To sum it up, I installed samba4 from git on a debian wheezy system. > Initially, I was able to join Windows 7 clients to the AD controller. > However, trying to get freenas 8 to join has been failing. In the end, > trying to get it to work I changed administrator's password (via > dsa.msc) which broke AD joining for windows clients too. KVNO in > secrets.keytab file has always been "1". Could this mismatch be the > cause of the failures? > > I rebooted all clients (to get rid of stale tickets) to no avail. The > only way to fix this was to run the provision script again, but now > samba is not very stable (I managed to join the AD domain, but upon > login I get The security database on the server does not have a > computer account for this workstation trust relationship). > > I really don't know where to start. Do you think using samba from > debian SID would be wiser than building from git? Are there any other > errors in the log I didn't spot? Is KVNO mismatch the reason joining > fails, or are there more errors?Samba is best installed from git. As to the KVNO mismatch, have you somehow installed a client with the same name as the server (ADPDC), or attempted to 'join' the server to itself? That can cause this kind of thing. Changing the administrator password won't be the issue, but if anything (a join, or reset with any tool) of the machine account password certainly could update sam.ldb but not the local secrets.ldb/secrets.keytab. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org