Proč SQL Server přes VPN stále padá zpět na NTLM?

Vaše připojení funguje, přihlášení je přijato a SQL Server používá NTLM, zatímco všichni očekávali Kerberos. Tento výsledek není závada VPN, protože tunel dodává jen cestu; schéma určilo jméno, které klient požadoval, principal zaregistrovaný v adresáři a lístek, který klient skutečně dokázal získat. Tři podmínky musí platit současně a relace sama říká, která ustoupila. Přečtěte si to, než někdo upraví hlavní název služby.

Relace pojmenuje schéma, které jste skutečně dostali

Schéma ověřování patří připojení, nikoli serveru nebo tunelu, takže kontrola musí běžet uvnitř relace, na které vám záleží. Spusťte dotaz níže ze stejného klienta, nástroje a účtu, které vytvořily zprávu, a poznamenejte cílové jméno a transport vedle výsledku.

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

Řádek z místního okna SSMS na hostiteli databáze popisuje zcela jiné připojení, a proto musí dotaz běžet ze strany klienta. Uložte výstup s časovým razítkem, protože další člověk, který jej přečte, se zeptá, kdy byl pořízen. Když několik aplikací sdílí jeden koncový bod, odeberte vzorek z každé, protože rozdíl ve zdroji dat mezi dvěma aplikacemi je často celý příběh.

První podmínka: odpovídá jméno SPN?

Kerberos ověřuje pojmenovanou službu, takže klient žádá adresář o lístek pro jeden konkrétní principal. Pro poskytovatele TCP je dokumentovaný tvar MSSQLSvc/ následovaný plně kvalifikovaným názvem hostitele a u výchozí instance port. Pojmenovaná instance registruje MSSQLSvc/db01.corp.example:SQLPROD, kde přípona je název instance místo čísla. Přístup k listeneru přes alias, CNAME, který se překládá jinam, nebo holou IP adresu mění požadované jméno a požadavek bez odpovídajícího principalu nemá lístek, který by vrátil.

Proto jedna aplikace funguje v jedné síti a v jiné padá zpět: odpověď DNS, záznam aliasu nebo položka hosts změnily jméno, které klient použil. Porovnejte požadované jméno s tím, co adresář obsahuje, než se dotknete registrace.

Druhá podmínka: je SPN na správném účtu?

SPN musí patřit účtu, který spouští službu SQL, ne účtu klienta a ne náhodou počítačovému objektu. SQL Server může při startu registrovat vlastní SPN, když má jeho servisní účet oprávnění je zapisovat, což je pohodlné a také vysvětluje, jak po změně servisního účtu vznikne duplikát.

Zeptejte se adresáře na jméno, které očekáváte, a poté vypište, co účet skutečně vlastní. Který objekt záznam drží, je důležitější než to, zda jméno někde v doménovém lese existuje. Neshoda znamená, že přihlášení nikdy nebylo problémem, a průvodce SPN od Microsoftu dokumentuje formáty i případy, kdy záznam musí vytvořit správce domény.

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

Přidání dalšího záznamu není bezpečný experiment. Duplikát nebo konfliktní registrace může rozbít klienty, kteří fungovali, proto před změnou zkontrolujte vlastnictví a poté je znovu ověřte.

Třetí podmínka: může klient vůbec získat lístek?

Správné SPN je k ničemu, pokud se klient nedostane na řadič domény nebo nemá použitelný kontext pověření. Výměna potřebuje KDC a DNS přes VPN a tunel, který směruje jen port SQL, selhává právě v tomto kroku. Dostupnost se musí testovat ze stejného počítače a stejného účtu, ne z firewallu před nimi.

Zkontrolujte mezipaměť lístků na počítači a pod účtem, který spouští aplikaci. Seznam pro celý počítač z okna se zvýšenými právy nic neříká o službě běžící jako jiný uživatel a prázdná mezipaměť pro tohoto uživatele je zjištění, ne nepříjemnost.

klist
klist -li 0x3e7

Potom rozhodněte, co smí záložní cesta udělat. Pokud zásada vyžaduje Kerberos, musí být NTLM výslovně odmítnuto, protože tiché selhání mění chybu konfigurace v fungující připojení, které požadavek porušuje. Pokud NTLM zůstává pro některé aplikace přijatelné, pojmenujte je a přestaňte každou relaci NTLM považovat za incident.

Změna spouštěče je jedna proměnná, ne oprava

Spuštění SSMS pod jiným pověřením může vyléčit nezamýšlenou odchozí identitu, což je skutečná třída problémů. Nic to nedokazuje o cílovém jménu, registraci nebo cestě lístku a nemění to, co server přijal.

Udržte srovnání pod kontrolou: stejný koncový bod, stejný poskytovatel, známý kontext spuštění, potom nové připojení, jehož schéma zkontrolujete. Potvrďte přijaté přihlášení a jeho databázová oprávnění odděleně, protože přístup a ověřování selhávají z různých důvodů.

Když je Kerberos povinný, poznamenejte, proč první cesta ustoupila, proveďte jednu opravu a spusťte dotaz znovu ze stejného klienta. Úspěšný dotaz po změně spouštěče je důkazem přístupu a zatím není důkazem, že požadavek na ověřování byl splněn.