similar to: KVNO in secrets.keytab for AD DC

Hi, you're right about kvno. kvno dc gives me: dc at DOMAIN.NET.PL: kvno = 1 I'm pretty sure I didn't change dc$ password nor keytab wasn't recreated (the file is from 2015). I've checked other DCs. It looks like two of them with CentOS 7 have kvno = 2, and one with CentOS 6 has also v 1. DCs on CentOS 7 are pretty new, with samba version 4.7.4 from the scratch. Main DC

Try verifying kvno from the client that gives the error message. That kvno = 2 for dc$ must've come from somewhere. You can also double check e.g. via ADUC ldap attributes of the dc$: lastpwdset and kvno. If  kvno is definately 1 that means that client connecting has some error, if it's 2, than it means that dc has outdated keytab. And if it's the former, than I really am not sure

what is the output of "kvno dc.domain.net.pl"? There seems to be mismatch kvno of the secrets keytab, and what is client expecting (kvno 2). Kvno increments by 1 for every password change. Was there by any chance password change for the dc$ account and keytab was not recreated? If You made some upgrades, maybe during process You for example rejoined the domain (that would set new

Hello everyone, I have a FreeNAS server (9.10 running samba 4.3.11-GIT-UNKNOWN) that's recently started emitting this error: gss_accept_sec_context failed with [ Miscellaneous failure (see text): Failed to find cifs/nas01 at EXAMPLE.COM(kvno 4) in keytab MEMORY:cifs_srv_keytab (arcfour-hmac-md5)] I've looked at bug 12262 [1], which is why I've cc'd Stefan Metzmacher. I don't

Rowland, it is not a problem of mount but of kerberso ticket: [2019/10/08 10:58:09.626059, 1] ../../auth/gensec/spnego.c:1218(gensec_spnego_server_negTokenInit_step) gensec_spnego_server_negTokenInit_step: gse_krb5: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_LOGON_FAILURE [2019/10/08 10:58:09.634532, 1] ../../source3/librpc/crypto/gse.c:660(gse_get_server_auth_token)

Hi Rowland, I refer again after a week, perhaps missing an important piece to the big picture: the error message appears ONLY when you access the share using the netbios alias: [Global] workgroup = WG1 realm = DOM.CORP netbios name = fs-a netbios aliases = oldsamba security = ADS if you access the \\fs-a\sharename is ok if you access \\oldsamba\sharename the logs report the

Thank you, Louis, for your reply. By simply asking me to provide outputs of the aforementioned files, I found the cause of my first problem (auth failing). It was my /etc/hosts file on dc1. All of them should look like this, and indeed DC2 and DC3's *did* look like this: # cat /etc/hosts > 127.0.0.1 ? ? ? localhost.samdom.mycompany.net ?localhost > 192.168.3.201

Hi All, This is my first post, and I'm new to Samba... I'm working on a Squid project running on RHEL5.3. Samba v 3.4.5-42 x86 and have run into a problem. I use Kerberos authentication on my Squid box. After configuring Squid I joined my RH to my AD domain and then used Samba to generate a Keytab and add an HTTP SPN to it: - export KRB5_KTNAME=FILE:/etc/squid/HTTP.keytab - net ads

?:-) best answer ever..? just using samba-tool.. i like that response :-)? ? ? So next time we should also do an check, and that can be can simply with samba-tool :-) Thanks for the reply Banda, most welkom. ? ? Greetz, ? Louis? ? ------------------------- ? Van: banda bassotti [mailto:bandabasotti at gmail.com] Verzonden: dinsdag 5 november 2019 17:10 Aan: L.P.H. van Belle CC: samba at

On 05/11/2019 12:17, banda bassotti via samba wrote: > Luis, ok I'v removed everything, step 1: > > KRB5_KTNAME=FILE:/etc/krb5.keytab2 net ads keytab CREATE -P I have said this once already, but, I will try again ;-) You are creating a keytab, which may or may not be called /etc/krb5.keytab2 > step2: > # KRB5_KTNAME=FILE:/etc/krb5.keytab2 net ads keytab ADD >

Yes, I am planning on upgrading the FreeNAS which will include a newer version of samba. However, I'm quite confident that this is not a duplicate of #12262. To be clear: I'm offering to leave my production system in a degraded state to help myself and the Samba developers understand exactly what's going on here, to determine if this is a new bug, or an existing one. I'm worried

On 27/12/2019 17:06, Jonathon Reinhart wrote: > On Wed, Dec 18, 2019 at 9:52 AM Rowland penny via samba > <samba at lists.samba.org <mailto:samba at lists.samba.org>> wrote: > > On 18/12/2019 14:34, Jonathon Reinhart wrote: > > On Wed, Dec 18, 2019 at 9:13 AM Rowland penny via samba > > <samba at lists.samba.org <mailto:samba at

Hai, I've re-read you thread, and there are a few things going-on.. I suggest you do the following.. Change these. /etc/krb5.conf [libdefaults] default_realm = DOM.CORP dns_lookup_kdc = true dns_lookup_realm = false forwardable = true proxiable = true kdc_timesync = 1 debug = false /etc/samba/smb.conf [Global] workgroup = WG1 realm = DOM.CORP # Netbios names in

Hai, > > Change this one. > > /etc/hosts > > 10.0.0.2 fs-a.dom.corp fs-a oldsamba # Old/wrong > > 10.0.0.2 fs-a.dom.corp fs-a oldsamba.dom.corp oldsamba # > new/correct > > Or > > 10.0.0.2 fs-a.dom.corp fs-a oldsamba.dom.corp # new/correct > No, none of them are correct No, Rowland, your really wrong here. ( i dont say that often.. ) :-p But i give

Luis, ok I'v removed everything, step 1: KRB5_KTNAME=FILE:/etc/krb5.keytab2 net ads keytab CREATE -P klist -ke /etc/krb5.keytab2|grep 7|sort 7 cifs/FS-A at DOM.CORP (aes128-cts-hmac-sha1-96) 7 cifs/FS-A at DOM.CORP (aes256-cts-hmac-sha1-96) 7 cifs/FS-A at DOM.CORP (arcfour-hmac) 7 cifs/FS-A at DOM.CORP (des-cbc-crc) 7 cifs/FS-A at DOM.CORP (des-cbc-md5) 7

hello, today the following problem occurred: [2019/10/08 09: 57: 23.568282, 1] ../../source3/librpc/crypto/gse.c:660(gse_get_server_auth_token) gss_accept_sec_context failed with [Miscellaneous failure (see text): Failed to find cifs/fs-share at dom.corp (kvno 109) in keytab MEMORY: cifs_srv_keytab (arcfour-hmac-md5)] in my smb.conf I have the lines: kerberos method = dedicated keytab

Hai, Nope.. To much again ;-) This is one step to much: step2: # KRB5_KTNAME=FILE:/etc/krb5.keytab2 net ads keytab ADD cifs/oldsamba.dom.corp at DOM.CORP # KRB5_KTNAME=FILE:/etc/krb5.keytab2 net ads keytab ADD cifs/oldsamba at DOM.CORP # KRB5_KTNAME=FILE:/etc/krb5.keytab2 net ads keytab ADD cifs/oldsamba$@DOM.CORP And why are you adding @REALM .. Do it exactly as shown below. Because

On Wed, Dec 18, 2019 at 9:52 AM Rowland penny via samba < samba at lists.samba.org> wrote: > On 18/12/2019 14:34, Jonathon Reinhart wrote: > > On Wed, Dec 18, 2019 at 9:13 AM Rowland penny via samba > > <samba at lists.samba.org <mailto:samba at lists.samba.org>> wrote: > > > > Problem is, and as I said, Samba 4.3.x is EOL as far as Samba is >

Hi, I suggest you post this to samba at list.samba.org that more for these questions. Try this setting in resolv.conf search domain.net.pl nameserver 10.1.10.11 # IP of DC itself. #nameserver # and extra nameserver that has access to the DC dns info. (a second dc maybe) nameserver 8.8.8.8 # IP of forwarder in SMB.conf as backup for internet access. # and max 3 nameservers in

Luis, my typos, I'v to mask the output sorry (compliance) # su - testuser $ smbclient --option='client min protocol=NT1' -U testuser //oldsamba/testuser -c 'ls' Unable to initialize messaging context Enter DOM\testuser's password: session setup failed: NT_STATUS_LOGON_FAILURE [2019/11/05 15:50:50.009481, 1] ../../source3/librpc/crypto/gse.c:660(gse_get_server_auth_token)