SQL Server 2025 a pomalá SQL Autentikace

V případě použití SQL Serveru 2025 s SQL autentikací je zavádění modulů Varia přibližně třikrát pomalejší než při použití předchozích verzí SQL Serveru. Příčinou je změna mechanismu ověřování hesel používaného při SQL autentikaci.

SQL Server 2025 používá pro autentikaci založenou na hesle standardně nový algoritmus PBKDF2 (Password-Based Key Derivation Function 2) s hashovací funkcí SHA-512 a 100 000 iteracemi. Oproti předchozím verzím je tak výrazně zvýšena výpočetní náročnost procesu ověřování hesla. Tato změna sice zvyšuje bezpečnost uložených hesel vůči útokům hrubou silou, avšak současně prodlužuje dobu potřebnou k provedení každého přihlášení pomocí SQL autentikace.

Zpomalení se týká výhradně SQL autentikace, při použití Windows autentikace (SSPI/Kerberos) se tento mechanismus nepoužívá a k uvedenému zpomalení nedochází.

Při zavádění modulů dochází k připojování jednotlivých tabulek, přičemž každé připojení vytváří minimálně jedno nové databázové spojení vyžadující samostatnou autentikaci vůči SQL Serveru. V prostředích bez podpory connection poolingu (MS Access jej při připojování tabulek nevyužívá) se proces ověření hesla provádí opakovaně pro každé spojení. Zvýšená výpočetní náročnost algoritmu PBKDF2 se tak násobí počtem navazovaných připojení, což vede k celkovému prodloužení doby zavádění modulů.

Řešení:

Microsoft o daném chování ví (SQL Server 2025 known issues – PBKDF2 hashing algorithm can affect login performance), ale oficiální řešení kromě použití doménové autentikace nenabízí.

1) Použijte windows autentikaci (doporučené řešení)

  • V Active Directory vytvořte novou skupinu a přidejte do ní všechny doménové uživatele, kteří budou Vario používat.
  • Při použití windows autentikace v síti s Active Directory je nutné, aby byla služba SQL serveru spouštěna pod doménovým uživatelem, nebo pod účtem NetworkService. V opačném případě nebude SQL server schopen ověřit členy dané skupiny.

 

  • Otevřete Možnosti Varia, v sekci Uživatelé najděte přepínač Autentikace SQL serveru a zvolte možnost Doménová autentikace.

 

  • Potvrďte dialog zobrazený výše a z níže zobrazeného seznamu vyberte doménovou skupinu, kterou jste vytvořili.

 

  • Po klepnutí na tlačítko  OK  bude doménové skupině nastaveno oprávnění ke čtení a zápisu do databází Varia. Poté bude Vario ukončeno. Při dalším přihlášení se již bude používat Windows autentikace.

Postup pro stanice, které nejsou v Active directory:

  • Na těchto stanicích lze provozovat Vario buď pouze v jednouživatelském režimu, nebo ve víceuživatelském režimu při použití relací vzdálené plochy. Vzhledem k tomu, že stanice není v AD, nefunguje automatické dotazování na seznam skupin a nastavení windows autentikace se musí provést ručně.
  • Nejprve je nutno vytvořit lokální skupinu (například VarioUsers) a do ní přidat lokální uživatele, kteří budou Vario používat. Poté je potřeba do souboru Vario.ini ve složce datového profilu přidat sekci Security, pokud již neexistuje. Do této sekce je potřeba přidat hodnotu SQLServerDomainSecurity odstranit hodnotu SQLServerSharedUser. Hodnotu SQLServerDomainSecurity nastavte na 1.

Sekce pak bude vypadat takto:

[Security]
SQLServerDomainSecurity=1

 

Nakonec je nutno této skupině přiřadit oprávnění k SQL serveru. To provedete v management studiu pomocí jednoduchého skriptu:

DECLARE @GroupName SYSNAME
-- Zde zadejte název skupiny
set @GroupName = 'VarioUsers'

DECLARE @MachineName SYSNAME
SET @MachineName = CONVERT(sysname, SERVERPROPERTY('MachineName'))

DECLARE @LoginName NVARCHAR(300)
SET @LoginName = QUOTENAME(@MachineName + '\' + @GroupName)

EXEC('CREATE LOGIN ' + @LoginName + ' FROM WINDOWS WITH DEFAULT_LANGUAGE = Czech')

SET @LoginName = @MachineName + '\' + @GroupName
exec spav_dejpravarw_all_dbs @LoginName

2) Využijte trace flag 4671 (v současnosti se jedná o Microsoftem nedokumentované řešení)

  • Přidání trace flagu 4671 do spouštěcích parametrů služby SQL Serveru 2025 deaktivuje nový mechanismus iterovaného hashování hesel.

 

Na základě interních testů bylo zjištěno, že v SQL Serveru 2025 má trace flag 4671 odlišné chování než v SQL Serveru 2022. V testovaném buildu SQL Serveru 2025 přidání startup parametru -T4671 deaktivuje nový mechanismus iterovaného hashování hesel. Bez aktivního trace flagu je tento mechanismus ve výchozím nastavení zapnut. Toto chování se liší od SQL Serveru 2022 (build CU12 a vyšší), kde trace flag 4671 sloužil naopak k aktivaci iterovaného hashování hesel.

 

Pozorované chování

  • Bez použití -T4671 jsou doby otevření Varia při použití SQL autentikace výrazně delší.
  • Po aktivaci -T4671 (přidáním do spouštěcích parametrů služby SQL Server) se výkon přihlašování vrací na úroveň srovnatelnou s předchozími verzemi SQL Serveru.

 

Dopad na existující SQL loginy

  • Bylo ověřeno, že SQL loginy, jejichž hesla byla vytvořena nebo změněna v době, kdy byl aktivní nový režim hashování, se po přepnutí režimu nadále úspěšně autentikují. Autentikace neselže, avšak stále probíhá pomalejší ověřovací cestou. Změna hesla způsobí jeho nové zahashování podle aktuálně aktivního režimu a obnoví očekávaný výkon přihlašování.

 

Pomocí níže uvedeného příkazu lze zjistit, zda je trace flag 4671 aktivní nebo ne:

DBCC TRACESTATUS(4671)

 

  • aktivní trace flag 

 

  • neaktivní trace flag 

 

  • Pomocí následujícího dotazu lze nalézt loginy vytvořené při zapnutém iterativním hashování:

SELECT name, password_hash
FROM sys.sql_logins
WHERE name NOT LIKE '##MS%'

  • Pokud nabývá první byte hashe hesla hodnoty 0x03, jedná se o heslo vygenerované novým způsobem, a i po deaktivaci iterovaného hashování na úrovní SQL Serveru probíhá ověření novým, pomalým způsobem.

      

  • Pouze hesla, jejichž první byt hashe hesla nabývá hodnoty 0x02, se ověřují původním, rychlým způsobem.

      

 

  • Hesla dotčených loginů lze aktualizovat nejrychleji pomocí následujícího příkazu:

alter LOGIN [loginname] WITH PASSWORD = 'heslo'

Chování trace flagu 4671 je závislé na konkrétní verzi a buildu SQL Serveru. V současnosti se jedná o nedokumentované řešení a je možné, že v budoucnu Microsoft tuto možnost zakáže!

Před nasazením do produkčního prostředí doporučujeme provést výkonové testy a ověřit chování na konkrétní instalaci.

Použití trace flagu je nutné považovat za pokročilé konfigurační nastavení, které může mít bezpečnostní a provozní dopady.

 

Odkazované dokumenty