Hvorfor falder SQL Server over en VPN stadig tilbage på NTLM?

Din forbindelse virker, login accepteres, og SQL Server bruger NTLM, mens alle forventede Kerberos. Det resultat er ikke en VPN-fejl, fordi en tunnel kun leverer en vej; skemaet blev bestemt af det navn, klienten bad om, den principal, der er registreret i kataloget, og den billet, klienten faktisk kunne skaffe. Tre betingelser skal være opfyldt på én gang, og sessionen selv fortæller, hvilken der gav efter. Læs det, før nogen redigerer et service principal name.

Sessionen navngiver det skema, du faktisk fik

Godkendelsesskemaet hører til en forbindelse og ikke til en server eller en tunnel, så kontrollen skal køre inde i den session, du bekymrer dig om. Kør forespørgslen nedenfor fra samme klient, værktøj og konto, som producerede rapporten, og noter målrettet navn og transport ved siden af resultatet.

SELECT session_id, auth_scheme, net_transport, client_net_address, login_name
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

En række fra et lokalt SSMS-vindue på databaseværten beskriver en helt anden forbindelse, og derfor skal forespørgslen køre fra klientsiden. Gem outputtet med et tidsstempel, fordi den næste person, der læser det, vil spørge, hvornår det blev taget. Når flere programmer deler et endepunkt, skal du tage en prøve fra hver, fordi en forskel i datakilde mellem to programmer ofte er hele historien.

Betingelse et: passer navnet til SPN'en?

Kerberos godkender en navngivet tjeneste, så klienten beder kataloget om en billet til en bestemt principal. For TCP-udbyderen er den dokumenterede form MSSQLSvc/ efterfulgt af det fuldt kvalificerede værtsnavn og, for en standardinstans, porten. En navngivet instans registrerer MSSQLSvc/db01.corp.example:SQLPROD, hvor suffikset er instansnavnet i stedet for et nummer. Når listeneren nås via et alias, en CNAME, der opløses et andet sted, eller en bar IP-adresse, ændres det ønskede navn, og en anmodning uden en matchende principal har ingen billet at returnere.

Det er derfor, et program virker på et netværk og falder tilbage på et andet: et DNS-svar, en aliaspost eller en hosts-post ændrede det navn, klienten brugte. Sammenlign det ønskede navn med det, kataloget indeholder, før du rører registreringen.

Betingelse to: er SPN'en på den rigtige konto?

En SPN skal tilhøre den konto, der kører SQL-tjenesten, ikke klientens konto og ikke ved et uheld et computerobjekt. SQL Server kan registrere sine egne SPN'er ved opstart, når dens tjenestekonto har tilladelse til at skrive dem, hvilket er praktisk og også forklarer, hvordan en dublet opstår efter en ændring af tjenestekontoen.

Spørg kataloget efter det navn, du forventer, og list derefter, hvad kontoen faktisk ejer. Hvilket objekt der har posten, betyder mere end hvorvidt navnet findes et sted i skoven. Uoverensstemmelse betyder, at login aldrig var problemet, og Microsofts SPN-vejledning dokumenterer formaterne og de tilfælde, hvor en domæneadministrator skal oprette posten.

setspn -Q MSSQLSvc/db01.corp.example:1433
setspn -L CORP\svc-sql01

At tilføje endnu en post er ikke et sikkert eksperiment. En dublet eller en konfliktende registrering kan ødelægge klienter, der virkede, så undersøg ejerskabet før ændringen, og tjek det igen bagefter.

Betingelse tre: kan klienten overhovedet få en billet?

En korrekt SPN er ubrugelig, hvis klienten ikke kan nå en domænecontroller eller ikke har en brugbar legitimationskontekst. Udvekslingen har brug for KDC og DNS gennem VPN'en, og en tunnel, der kun ruter SQL-porten, fejler netop på dette trin. Tilgængelighed skal testes fra samme maskine og samme konto, ikke fra firewallen foran dem.

Undersøg billetcachen på maskinen og under den konto, der kører programmet. En maskinbred liste fra et forhøjet vindue siger intet om en tjeneste, der kører som en anden bruger, og en tom cache for den bruger er et fund og ikke en ulejlighed.

klist
klist -li 0x3e7

Beslut derefter, hvad en tilbagefaldsvej må gøre. Hvis politikken kræver Kerberos, skal NTLM afvises udtrykkeligt, fordi et stille tilbagefald forvandler en konfigurationsfejl til en fungerende forbindelse, der overtræder kravet. Hvis NTLM forbliver acceptabelt for nogle programmer, så navngiv dem, og hold op med at behandle hver NTLM-session som en hændelse.

At ændre starteren er én variabel, ikke en rettelse

At starte SSMS under en anden legitimationsoplysning kan kurere en utilsigtet udgående identitet, hvilket er en reel problemklasse. Det beviser intet om målrettet navn, registreringen eller billetvejen, og det ændrer ikke, hvad serveren accepterede.

Hold sammenligningen kontrolleret: samme endepunkt, samme udbyder, en kendt eksekveringskontekst, derefter en frisk forbindelse, hvis skema du undersøger. Bekræft det accepterede login og dets databasetilladelser separat, fordi adgang og godkendelse fejler af forskellige grunde.

Når Kerberos er påkrævet, skal du notere, hvorfor den første vej faldt tilbage, anvende én rettelse og køre forespørgslen igen fra samme klient. En vellykket forespørgsel efter en ændring af starteren er bevis på adgang, og det er endnu ikke bevis for, at godkendelseskravet blev opfyldt.