W2K.PL

Wednesday, April 9th, 2008...10:16 pm

SQL 2008 i Kerberos

Jump to Comments

W trakcie krótkiej wizyty na C2C (o której już pisałem wcześniej) udało mi się zajść na jedną z sesji technicznych prowadzoną przez Marcina Szeligę a dotyczącą zmian w zakresie bezpieczeństwa w SQL 2008.

W zasadzie to jak to w tematach SQLowych … coś rozumie, specjalistą nie jestem :), ożywiłem się gdzy Marcin doszedł do tematów związanych z uwierzytelnieniem i Kerberos. W zasadzie to były tylko dwa slajdy - ale w końcu coś na czym się znałem. Jedna z podstawowych zmian o jakich wspomniał Marcin to brak konieczności rejestrowania SPN przez SQL Server i możliwość określenia ich w łańcuchu połączenia (connection string). Slajd poniżej (mam nadzieję że nie łamię żadnych praw autorskich ):

 

Tutaj moje uszy trochę zastrzygły … z tego co wiem to SPN czasami się przydają. Upewniłem się po sesji u Marcina, że się nie przesłyszałem i powiedziałem że sprawdzę … no to sprawdzam.

Swoją drogą ciekawy jest sam problem, z którym kilka razy się spotkałem. Rejestracja SPN stanowi problem zarówno dla developerów \ wdrożeniowców (chyba najczęstsza rzecz, o której się zapomina przy instalacji aplikacji), jak i dla administratorów (co i gdzie zarejestrować). W szczególności gdy administrator usługi katalogowej nie wydelegował odpowiednich uprawnień do atrybutu servicePrincipalName.

W zasadzie trochę w tym co powiedział Marcin prawdy jest. Tylko trzeba to doprecyzować. Tak więc:

• Faktycznie jest tak, że SPN można podać jako atrybut w ramach connection string.
• Nie do końca jest tak, że nie trzeba rejestrować SPN w AD dla instancji SQL. SPN nadal są wymagane jeżeli korzystamy z uwierzytelnienia opartego na Kerberos i specyfikujemy usługę w oparciu o SPN lub po prostu łączymy się do usługi, czyli:
• jeżeli SPN jest określony w connection string to usługa sama z siebie nie będzie starała się takowego skonstruować w oparciu o FQDN hosta, tylko użyje tego który został podany. Uwaga więc dla konfiugrujących rozwiązanie - sprawdźcie dwa razy connection stringi w konfiugracji.
• jeżeli podajemy SPN w postaci MSSQLSVC/FQDN:<port|instancename>, lub nie podajemy go w ogóle to musi on być zarejestrowany w AD.
• Nie jest wymagana rejestracja SPN dla usługi SQL 2008, jeżeli w connection string określimy usługę w formacie;
• serviceacount@domain - czyli UPN konta serwisowego
• domain\serviceaccount - czyli po prostu logon name
• machine$@domain - czyli UPN maszyny, z tym że to pewnie zadziała tylko gdy SQL działa na jednym z kont systemowych maszyny
• host\FQDN - uwaga jak wyżej.

Czyli jeżeli jesteśmy w stanie wskazać od razu odpowiednie konto systemowe czy maszynę to unikamy wyszukania odpowiedniego konta w AD w oparciu o SPN i nie musimy takowych rejestrować. I to już mi pasuje do mojego stanu wiedzy :), i wszystko gra.

I taki to pożytek z mojej obecności na C2C 2008.

P.S. Paweł opublikował zapis rozmowy kuluarowej, którą toczyliśmy w trakcie jednej z sesji na swoim blogu - to tak w ramach rozrywki.