Tűzfalas kollégák vs. Sql kollégák

Sziasztok!



El szoktam mesélni Sql Admin tanfolyamon a kedvenc sztorimat, és most úgy döntöttem ide is leírom, legyen meg.

Van egy nagy cégünk, aminek neve Bőség és Jólét Bt.
Informatikai területen szolgáltatunk. Vannak tűzfalas kollégáink, akik őrzik a rendet, és megóvnak minket a sok syn flood-tól ami érkezik Kínából, és vannak az Sql admin kollegák, akiknek a munkaköre kimerül abban, hogy az óránkénti 10.000 dollárt termelő adatbázis ne hasaljon már el, legyen mindig elérhető 0-24, elég gyorsan lehessen belőle selectálgatni. Ja és ebből az adatbázisból van vagy 200 db...

Szóval semmi stressz...

Meg is vagyunk, mindenki végzi a dolgát. Aztán egyszer csak a cég elnyer egy pályázati pénzt, amiből vagány Blade szervereket és néhány SQL 2012 Enterprise Editiont vásárolunk.
Miután kész van az architekt munkafolyamat, jöhet egy adatbázis migrálás az új szerverre.

Megtörténik, majd érkeznek a telefonok, hogy itt sem megy a programunk, meg a másik megyében sem megy a programunk... Mindenki nézi, hogy vajon mi történhetett, minden beállítás jónak tűnik...

Aztán egyszer csak az architektes kollegának eszébe jut 1 (azaz egy) dolog,amiben különbséget fedezett fel,mégpedig hogy valamilyen okból kifolyólag  nem Default Instance-ot telepítettünk fel, hanem Named Instance-ot. Erre rögtön mondja is az egy DBA kolléga, hogy nincs azzal gond, hiszen a programok config fileja (ami az sql szerverhez való csatlakozás paramétereit tartalmazza) frissítve lett mindenhol. Ráadásul odafigyeltünk arra is, hogy ugyanmár fusson az a Browser Service, sőt, még a 1434-es portot ki is nyittattuk a tűzfalas srácokkal...

Akkor mégis hogy lehet az, hogy csak azokkal az adatbázisokkal van gond, amik az "új vason vannak", és a régi szerver Default Példányáról pedig minden tökéletesen megy?


Hát úgy lehet, hogy a tűzfalas kollégák azt csinálják, amit kell, engedélyeznek mindent, amit kérsz és minden más megy a levesbe (vagyis Default Drop)

És mi mit kértünk tőlük? Hogy a TCP 1433 a Database Engine miatt és a TCP 1434 a Browser Service miatt legyen nyitva, hogy a kliensek elérjék a nevesített példányt.

Mert a Browser Service TCP 1434-en küldi az infót a kliensnek hogy  a keresett sql szerver melyik porton hallgatózik...

Igen ám, de magát a Kliens kérését, (hogy küldje már el a Named Instance portját), hol várja a Browser Service?

UDP 1434

És mi mit kértünk a tűzfalas kollégáktól? TCP 1434.

Ezt kellett volna tudnia a Firewall csapatnak? Hát nem, miért kellene? Az Sql-es sem kell hogy tudja, hogy vajon az SSL az ISO/OSI Layer 3 és Layer 4 "között" dolgozik -e vagy sem...

Szóval az én szerény véleményem az, hogy egy DBA tudja azt, hogy igenis kell néha UDP forgalmat engedni 1434 porton az sql szerverek felé.

A Service Principal Name (SPN) és a Windows Authentication kapcsolata

Üdv újra Mindenkinek!

Eltelt egy kis idő az utolsó bejegyzésem óta... Az elmúlt pár hónapban jó sok élménnyel lettem gazdagabb, sok DBA-val volt szerencsém találkozni és tapasztalatot cserélni. Az így összegyűjtött puskaporomat szeretném eldurrogtatni, több szálon (le)vezetve azt. Fogok kezdeni egy külön securitys szálat, és az egyéb/szokásos szálon is haladok majd. Így remélhetőleg átláthatóbbak lesznek a bejegyzés címei is.

Kezdem is rögtön azzal, hogy hívtak egy Sql szerverhez, ahol a helyzet a következő volt:

Mixed authentikációs mód engedélyezve, vagyis használva van (lenne) mind a Windows login, mind az Sql típusú login is. Az esetek túlnyomó többségében Sql acc. van használva, és csak ritkán a win. A hozzáférés windows login esetén mindig local gépen történt. (A helyzet így hozta.)


A probléma akkor ütötte fel a fejét, amikor a DBA kolléga egy távoli eléréssel szerette volna megoldani az aznapi dolgát, és nem tudott bejelentkezni. (Itt a távoli elérés nem RDP kapcsolatot, hanem SSMS ---> Connect ---> távoli_szerver_neve próbálkozást jelentett)


A hibakeresés során a következők voltak átgondolva (A bagatell dolgokat előre írom)

- Biztos jó loginnal akarok bejelentkezni? (Ugyanabban a domainben ugyanazzal a loginnal bejelentkezve a munkaállomsára ezt szinte lehetetlen elrontani SSMS Win Auth. esetén)

- Nem lenne jó a jelszavam ? (De hiszen be se lett írva az SSMS-be, a munkaállomáson meg bent vagyok)

- Nem lenne benne a Windows loginom a Security/Logins ágban? 
- Vagy ha benne van a Logins ágban, akkor esetleg nincs Connect jogom?  (De csak távoli eléréssel nem megy, ha helyben próbálom, simán bejelentkezik)

- Hálózati probléma, ami kihat a távelérésre, de a local kísérletet engedi? (De az sql loginok gyönyörűen működnek, az összes.)


Feltételezésem szerint kb. ekkor kerültem én a képbe.

Nem volt semmi "bonyolítás" kategóriába tartozó körülmény pl. más tartományból érkező authentikációs kérések, megbízhatósági kérdések, szerver tanúsítvány megetetése a kliensek felé, stb. Így rögtön lecsaptam arra a kérdésre, hogy vajon mi lehet a különbség két connection között, ami ugyanabból a domainből jön, ugyanabból az alhálózatból, ugyanazzal az AD hitelesített Win loginnal... És malacom volt, mert rögtön elsőre meglett a tuti. (Még engem is meglepett hogy milyen gyorsan :-)    ) 

Local gépről bejelentkezés win loginnal, majd megnéztem a connection típusát, méghozzá így:

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

Az eredmény az lett, hogy: Net_Transport = Shared memory és auth_scheme=NTLM

Ezért az NTLM-ért szurkoltam, hogy lássam ! Ugyanis megvan a kiváltó oka a hibának.

És itt jön a képbe a Service Principal Name (SPN), ugyanis ha ez az SPN nincs sikeresen regisztrálva a tartományunkba, ezáltal a Key Distribution Center nem tud erről, akkor a Kerberos típusú hitelesítések nem fognak működni! Hogy még tovább árnyaljam: Ráadásul a Kerberos authentikáció előnyt élvez az NTLM-el szemben (mondjuk nagyon helyesen) ezért esélytelen volt, hogy a távoli elérés NTLM-el menjen végig.

Tehát ha helyben jók vagyunk, távolról pedig nem (és minden hálózati, routing ill. tűzfal probléma forrást kiszűrtünk) akkor nagy eséllyel "csak" annyi a gond, hogy a Kerberos megakad ott, ahol még az NTLM  még elmegy, ergo SPN regisztrálási problémánk van.

Ha idáig eljutottunk, akkor már a nehezén túl vagyunk, ugyanis ennek a beregisztrálása kézzel elég hamar megvan. ( Azért legyen jogunk regisztrálni a Az Active Directory Domain Services-be)

pl.:   setspn -A MSSQLvc/eles_sql_szerverem.cegnevem.hu:1433 loginnév

Minimális magyarázat :  Service név/FQDN:port az_a_login_neve_akivel_registrálom

Ez a Default Instance esetén jó lesz, de ha nevesített példány fut, akkor a port helyére az instance neve kerüljön!  (Nevesített példány esetén nem kell túl aggódni a port témakörét ugye, mert akkor minek találták volna ki a Browser Servicet :)    )


Megjegyzés: Bár az én esetemben nem volt beregisztrált SPN az Sql servicenek, attól még simán előfordulhat az, hogy nálad már lesz egy, de az neked nem lesz jó. Miért is?

Miért ne regisztráljunk be mellé egy működő SPN-t, és hagyjuk a régit úgy? Azért, mert a Kerberos alapvetően támogatja a "mutual" authentikálást, és a Kerberos v5 protocolt használó kliens nem fogja tudni megugrani azt, hogy duplikálva látja ugyanannak az Sql Servicenek az SPN-jét.(Na jó, van egy kivétel, ha nem beépített loginnal futtatod a Database Enginet, hanem Domain Accounttal, és annak meg van adva a jelszava is a Server Managerben ugye.)

A tiszta megoldás, ha egy db reg van, ezért ha törölni akarsz akkor a -A helyett használd nyugodtan a -D kapcsolót a setspn parancsnál.


Kettő darab gyors kiegészítés, mielőtt egy Windows Server Expert megjegyezné :) 

1.: Amennyiben az SPN regisztrálás nem sikerül, akkor egy ilyen bejelentkezési kísérletnél igazából a Windows security layer fog hisztizni, hogy nem tudta kideríteni az account + SPN párost.

2.: Nem mentünk bele abba, hogy vajon mehetne-e távolról az NTML a Kerberos helyett. Igazából fel sem merült bennük ez a fajta megoldás, engem meg nem is izgatott, mivel nem lett volna teljes megoldás. Az SPN-t nem gyógyítja meg.


Konklúzió:  Legyünk jóban a windows szerver admin kollégánkkal, mert egy hibás SPN regisztrációs kísérlet bekerül Warning formájában a Windows Server Application logjába... ;)



Bye.