Samba verbinding wordt afgebroken door verlopen Kerberos tic

[eager2learn]

In onze omgeving werken Samba-server met de parameters "workgroup = WORKGROUP" en "security = user" goed.
Maar bij een Samba-server met de parameters "workgroup = <DOMAIN-NAME>" en "security = ads" wordt de Samba verbinding na enkele uren afgebroken.
Ik vermoed dat dat komt door een verlopen Kerberos ticket.
Ik weet niet hoe ik dat verbreken van de Samba verbinding kan voorkomen.

Op een Windows-10 systeem is de X-schijf "mapped" aan de Samba-server.
Op dit windows-10 systeem heb onderstaande C-source gecompileerd met gcc.

code:

#include <windows.h>
#include <stdio.h>
#include <time.h>
#include <errno.h>

int main()
{
  FILE *fp;
  int ret_val1, ret_val2;

  fp = fopen("X:/0000/hans/ftest_file.txt", "w");

  do
  {
    time_t t = time(NULL);
    struct tm tm = *localtime(&t);
    printf("%2d %02d:%02d:%02d\n", tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
    ret_val1 = fprintf(fp, "%2d %02d:%02d:%02d\n", tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec);
    ret_val2 = fflush(fp);
    printf("fprintf ret_val = %d fflush ret_val = %d errno = %d\n", ret_val1, ret_val2, errno);
    Sleep(60000);
  } while(1);
  
  fclose(fp);

  return(0);
}

Dit programma schrijft ieder minuut de dag en tijd in een file op de Samba-server share.
De output op het Windows-10 systeem is:

code:

8  6:57:20
fprintf ret_val = 12 fflush ret_val = 0 errno = 0

Maar na enkele uren wordt dat:

code:

8  16:42:23
fprintf ret_val = 12 fflush ret_val = -1 errno = 22

De file op de Samba-server wordt dan ook niet meer verder gevuld.
Het commando "klist" op de Samba-server geeft de onderstaande output:

code:

Ticket cache: FILE:/tmp/krb5cc_0             
            Default principal: automation@<DOMAIN-NAME>

            Valid starting     Expires            Service principal
            09/02/22 11:59:59  10/02/22 11:59:59  krbtgt/<DOMAIN-NAME>.LOCAL@<DOMAIN-
                                                                                                                NAME>.LOCAL
                                renew until 25/02/22 11:59:59

Het verlengen van de kerberos Expire tijd met het commando hier onder lost het probleem niet op.

code:

kinit -V -k -t /etc/krb5.keytab automation@<DOMAIN-NAME>
       Using default cache: /tmp/krb5cc_0
       Using principal: automation@<DOMAIN-MAME>
       Using keytab: /etc/krb5.keytab
       Authenticated to Kerberos v5

Hoe kan ik een Samba verbinding maken in een domein zonder dat de verbinding na enkele uren wordt afgebroken?

[Voor 1% gewijzigd door eager2learn op 07-03-2022 16:56. Reden: Onjuiste parameter]

[thunder7]

wat staat er in smb.conf, met name omtrent de timeout opties?

[eager2learn]

Het 'Samba' commando "testparm -sv | grep -i time" geeft de onderstaande output.

afs token lifetime = 604800
ctdb locktime warn threshold = 0
ctdb timeout = 0
cups connection timeout = 30
deadtime = 0
debug hires timestamp = Yes
debug prefix timestamp = No
idmap cache time = 604800
idmap negative cache time = 120
ldap connection timeout = 2
ldap timeout = 15
lock spin time = 200
lpq cache time = 30
machine password timeout = 604800
name cache timeout = 660
oplock break wait time = 0
passwd chat timeout = 2
printcap cache time = 750
time server = No
timestamp logs = Yes
username map cache time = 0
winbind cache time = 300
winbind request timeout = 60
dfree cache time = 0
dos filetime resolution = No
dos filetimes = Yes
fake directory create times = No

Deze paramters zijn het zelfde als bij een SMBv2 waar bij het probleem van het afbreken van de verbinding niet optreed. Maar bij SMBv2 wordt geen kerberos gebruikt en bij SMBv3 wel.

De parameter "afs token lifetime" kende ik nog niet maar is wel interessant.
Ik heb de onderstaande beschrijving gevonden:

This "afs token lifetime" parameter controls the lifetime of tokens that the AFS fake-kaserver claims.
In reality these never expire but this lifetime controls when the afs client will forget the token.
Set this parameter to 0 to get NEVERDATE.

Default: afs token lifetime = 604800

Die (default) 604800 is in seconden. Dat is dus 10 dagen.
De verbinding wordt echter al na enkele uren afgebroken.

Ik ga nu een test draaien met die "afs token lifetime" op 0.

[Voor 4% gewijzigd door eager2learn op 14-02-2022 09:26. Reden: Verbetering]

[ripperke]

Kerberos tickets zijn by default 10 uur geldig, tussen 6h57 en 16h42 zit 9h45, zijn dit de exacte timestamps ? Moest dit het probleem zijn is dit meer te verwachten om 10:00:01.

De klist die je geeft komt van op de server, die heeft eigenlijk geen meerwaarde in je onderzoek naar je probleem. Ook die kinit geeft je een nieuw TGT maar heeft verder geen invloed op je Win 10 client(s) / probleem.

Je kijkt beter eens naar de output van klist op je Windows 10 client machine (gewoon klist ingeven in een cmd prompt) en zoek even de entry cifs/<server>. Die gaat je zeggen wanneer je Kerberos ticket exact vervalt.

[Thc_Nbl]

volgens mij hit je een bugje.
welk os en samba versie is dit, gezien er behoorlijk wat veranderd is in dat gebied.
Ik zag er vandaag nog een over voorbij komen. bugzilla.samba.org

[eager2learn]

Ik gebruik Windows 10 20H2 als client en Ubuntu 18 met Samba 4.7.6 als server.

Een test met Samba parameter "afs tiken lifetime" op "0" geeft het zelfde probleem.

Ik keek inderdaad naar Kerberos tickets op de Samba server en moet juist naar Kerberos tickets op de Windows client kijken.
C:\windows\system32\klist.exe geeft 17 tickets als output.
Daar moet ik mijn dus in gaan verdiepen.

[eager2learn]

Vanaf het Windows 10 systeem is een share mapped van de Samba server met als account
"automatuion@<DOMAIN-NAME>.

Op dat Windows 10 systeem geeft het commando klist onderstaande output met Kerberos ticket.
C:\windows\system32\klist
#6> Client: automation @ <DOMAIN-NAME>
Server: cifs/prod03 @ <DOMAIN-NAME>
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
Start Time: 2/19/2022 15:18:14 (local)
End Time: 2/20/2022 1:18:14 (local)
Renew Time: 2/27/2022 17:01:03 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: DC2017.<domain-name>

De "End Time: 2/20/2022 1:18:14" komt precies overeen met de tijd dat het C programma fwrite error 22
krijgt bij de flush dat de datum en tijd string naar de file op de Samba share schrijft.


20 01:17:35
fprintf ret_val = 12 fflush ret_val = 0 errno = 0
20 01:18:35
fprintf ret_val = 12 fflush ret_val = -1 errno = 22

De keberos ticket moet dus vernieuwd worden met een nieuwe "End time".

Op LInux kan dat met het commando "kinit".
Maar Windows heeft geen kinit.exe commando.

Maar hoe kan ik op Windows 10 die Kerberos ticket vernieuwen?

[ripperke]

Als je met user "automation" bent aangelogd zou Windows vanzelf je Kerberos ticket moeten vernieuwen want die heeft je wachtwoord gecached staan, maar dat lijkt niet te werken...

Of hoe heb je die network drive gemapt als user automation ? Ben je toch met een andere user aangelogd in Windows zelf?

Je zou als mogelijke workaround een alias kunnen maken in DNS naar je fileserver waardoor je geen Kerberos meer doet maar gaat fallbacken naar NTLM, je credentials worden dan opgeslagen in de Credential Manager als het goed gaat.

[eager2learn]

Door te experimenteren en relevante artikelen op internet te lezen bouw ik steeds meer kennis op over Kerberos tickets en de oorzaak van mijn probleem.
Ik heb geconstateerd dat de Kerberos ticket op Windows (inderdaad) automatisch wordt vernieuwd.
Mijn test programma fwite.exe heeft een bestand geopend op de Samba share en schrijft daar iedere minuut de dag nummer en tijd in. Vanaf het moment dat de Kerberos ticket "af loopt" (expired) en vernieuwd wordt is de geopende file op de Samba share blijkbaar gesloten, want een nieuwe schrijf en flush actie geeft error 22.

Het probleem is dus hoe een programma een file op de Samba share geopend kan houden als de kerberos ticket "afloopt" (expired) en vernieuwd wordt.

De tip over om de share met de zelfde account te mappen als waarmee ik in Windows inlogt ben, ga ik uitproberen.
Ook de tip over NTLM is interessant.
Maar de connectie tussen het Windows systeem en de Samba share moet wel secure blijven.
Een "Men in the middle" moet niet kunnen inbreken in die verbinding.

[Cyphax]

eager2learn schreef op dinsdag 22 februari 2022 @ 10:59:
Het probleem is dus hoe een programma een file op de Samba share geopend kan houden als de kerberos ticket "afloopt" (expired) en vernieuwd wordt.

Is dit programma je enige probleem? Want dan zou ik zeggen: je programma is het probleem (zo langdurig een file geopend houden is denk ik geen goed idee), pas het aan zodat het elke keer dat het dat bestand aan moet passen, even het bestand opent, aanpast, en dan weer sluit.

Of is er een hele specifieke reden dat je een file zo lang echt open wilt houden?
Je programma zou eigenlijk sowieso om moeten kunnen gaan met disconnects als het zo afhankelijk is van een netwerkresource...

[eager2learn]

Nee, mijn programma is maar een test.
Wij gebruiken een applicaties die wij inkopen en die applicatie verwerkt 7x24 binnen komende data.
Met die applicatie kan ik niet experimenteren in de productie omgeving.
Die applicatie werkt nu met SMB2 op een Samba server en SMB2 heeft dat probleem niet.
Om beveiliging 's reden wil ik overstappen naar SMB3.
Maar dan moet dit probleem wel eerst opgelost zijn.
Vanaf Windows met SMB3 naar een Windows SMB server treed dit probleem niet op.

[eager2learn]

Als extra test heb ik ook op een Windows 2016 server een map gemaakt van de Samba server.
Nadat mijn test programma gestopt is met errno 22 kan ik de share niet meer bereiken.

22 01:05:46
fprintf ret_val = 12 fflush ret_val = 0 errno = 0
22 01:06:46
fprintf ret_val = 12 fflush ret_val = -1 errno = 22

C:>X:
Invalid Signature.
C:>

[eager2learn]

Het probleem van die "Invalid Signature" treed wel op in:
Windows 10 Pro
Windows server 2012 R2 Standard
Windows Server 2016 Standard

Het probleem van die "Invalid Signature" treed niet op in:
Windows 10 Pro 20H2
Windows Server 2022 21H2