Ondrej Sevecek's Blog

Pokud váš SQL server běží pod doménovým (nedej bože lokálním) servisním uživatelským účtem (nebavíme se o managed service account ani o group managed service account), tak si buďte téměř jisti, že se, bez další konfigurace, do něho připojujete pomocí NTLM, místo abyste používali Kerberos. V předchozím článečku jsem popisoval, jak se za pomoci KLIST ověří, že se do něho přihlašujete pomocí Kerberos, tak tu si právě osvětlíme, jak toho dosáhnout, pokud to tak není.

Proč Kerberos?

Je to:

1. rychlejší, protože se nemuíste komplet ověřovat při každém TCP spojení vůči DC (ano, PAC validation tam pro servisní doménové účty bude)
2. bezpečnější, protože je to oproti NTLM vzájemně autentizované a není možné to spojení aktivně napadnout MITM a odposlouchávat
3. ještě bezpečnější, protože to za jistých podmínek může být šifrováno AES, namísto výchozího RC4 nebo DES
4. frajerské, protože jenom frajeři mají SQLko na Kerbáči :-)

Co to vyžaduje aby jel Kerberos?

Aby jel vůbec Kerberos, na servisním uživatelském účtu, pod kterým běží ona služba SQL serveru, musí být v Active Directory správně vyplněn atribut servicePrincipalName. Musí v něm být, obvykle dvě, SPN. Něco jako:

MSSQLSVC/dbserver.gopas.virtual:59595
MSSQLSVC/dbserver.gopas.virtual:DBINSTANCE

Číslo je číslo portu, na kterém to poslouchá. To druhé je jméno instance. Pokud se jedná o výchozí instanci (default instance), mělo by tam být něco takovéhohle:

MSSQLSVC/dbserver.gopas.virtual

Ani v jednom z obou případů nedoporučuji na tu hodnotu atributu servicePrincipalName sahat ručně. Čísla portů se mohou měnit. Taky když tu službu vypnete, nebo změníte její servisní účet, je dobře, aby se ta hodnota sama vyčistila. Nebudou pak nastávat kolize.

Pokud tam nic není, nebo je tam něco špatného, Kerberos nebude fungovat a jedete nejspíš přes NTLM.

Jak toho dosáhnu?

Optimálně bych povolil tomu servisnímu účtu, aby si sám sobě tyto hodnoty registroval při restartu služby SQL serverové instance. Je potřeba zjistit distiguishedName toho uživatelského účtu a potom použijete jednoduše DSACLS. Samozřejmě, pokud byste se obávali, že si ten servisní účet sám změní SPN na něco zlého, tak mu to nedovolujte a nastavte to ručně.

DSACLS "CN=sqlSvc,OU=SvcAccounts,DC=gopas,DC=virtual /G "Self:RPWP;servicePrincipalName""

Když potom restartujete SQL server službu, pokud se jí registrace SPN úspěšně povede, dozvíte se o tom díky následující události v Application logu (protokolu událostí):

Event Id: 26059
Event source: MSSQL$instance
Event type: Information
Message: The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) for the SQL Server service. 

I úspěšná odregistrace SPN při vypínání SQL server služby bude vypadat podobně:

Event Id: 26060
Event source: MSSQL$instance
Event type: Information
Message: The SQL Server Network Interface library successfully deregistered the Service Principal Name (SPN) for the SQL Server service.

Neúspěšná registrace SPN při vypínání SQL server služby bude vypadat opět podobně (i takto je to jenom Information, aby se správci neděsili, zřejmě):

Event Id: 26067
Event source: MSSQL$instance
Event type: Information
Message: The SQL Server Network Interface library could not registered the Service Principal Name (SPN) for the SQL Server service. Windows return code 0x2098, state 15. Failure to register a SPN might cause integrated authentication to use NTLM instead.

Jak to je s AES?

Aby Kerberos šifroval TGS tikety pro SQL server pomocí AES (a současně to i fungovalo) musí být splněno zhruba následující:

1. doména musí být alespoň na úrovni Windows 2008 (domain functional level - DFL)
2. klientem musí být alespoň Windows Vista, nebo Windows 2008 a novější (tedy Windows 7, Windows 8, Windows 2012 apod.)
3. SQL servery, které používají stejný doménový servisní uživatelský účet musí běžet alespoň na Windows 2008 a novějších
4. musí to opravdu ten Kerberos používat :-)
5. a pozor, teď důležitý! ten doménový servisní účet, pod kterým běží instance SQL služeb musí mít v atributu msDS-SupportedEncryptionTypes zapnutu podporu AES. A zde neplatí, jak by řekl Babica, pokud nemáte AES, dejte si tam nějakej jinej algoritmus.

Zase se jedná jen o případ servisních doménových uživatelských účtů. On SQL server samozřějmě může běžet i pod účtem svého serveru (clusteru), a do toho samozřejmě počítám i lokální servisní účty (NT SERVICE) nebo pod managed service account, nebo pod group managed service account. V takovém případě ale sám jeho počítač aktualizuje seznam algoritmů v atributu msDS-SupportedEncryptionTypes automaticky při každém startu.

Mrkněte se do libovolného účtu počítače s Windows 7 nebo Windows 2008 a novějšími.

Pozor! Do atributu msDS-SupportedEncryptionTypes dejte raději i ostatní algoritmy jako je RC4 a DES

Pokud to tam nedáte a necháte tam jenom AES, starší klienti typu XP a 2003 žádný tiket nedostanou a pojedou asi pomocí NTLM. Asi. Možná nepojedou vůbec. Takže bacha na ta AES zaškrtávátka na záložce uživatelských účtů Account. Tam to zapne výhradně AES a vypne RC4 a DES podporu natvrdo. Upravujte raději přímo atribut msDS-SupportedEncryptionTypes.

Tím že tam dáte i RC4 a DES nic nezkazíte. AES je vždycky preferovaný, pokud to jde. Řadiče domény (DC) od Windows 2008 R2 už stejně DES nedávají vůbec a RC4 tam tedy zbude jen kvůli kompatibilitě se staršími klienty.

Možná musíte změnit heslo

Je možné, že jste heslo toho služebního účtu ještě nezměnili od doby, kdy jste zvýšili DFL na úroveň 2008. Tak to máte smůlu. Dokud ho nezměníte, Active Directory si neuloží AES a SHA-1 encryptory a AES tikety to stejně dělat nebude. Na to by vám Hurvínek řekl: chá, chá!

Na puberťáky má ovšem Taťulda vžycky tip: Nemusíte tam dávat jiné heslo. Klidně ho vyresetujte na to stejné. Jenom je potřeba ho prostě znovu nastavit. Stačí na doméně. Nemusíte vůbec sahat na SQL server. Chá chá!