Tegyük fel, hogy van egy 9 gépes tesztrendszered. Tegyük fel, hogy nem Te installáltad fel, és tegyük fel, hogy véletlenül a hozzátartozó dokumentumban elcseréltek két web szervert (DMZ-ben lévő, belső hálón lévő).
1. Megpróbálsz az általad belső webszervernek hitt szerverről bejelentkezni az SQL-be, nem megy.
2. OK, rosszul konfigoltál valamit, létrehozol SQL usert, hisz az tuti. Azzal se megy. Később rájössz, hogy SQL usert létre lehet hozni olyan SQL szerveren is, ami _nem_ mixed mode (ez logikus), de egy szót se szól, hogy ezzel ide biztos nem fogsz belépni...
3. Nem baj, leesik, megpróbálsz domain userrel belépni a webszerverre, hogy az SQL-be domain userrel tudj menni. Nem megy. A local admin és a domain admin jelszava megegyezik. Remote Desktop progival megadod kézzel, egyértelműen a domaint és a usert, alul írja is. TOVÁBBRA SEM MEGY az sql-be belépés, miközben az sql gépen megy ugyan ezzel a userrel, tűzfal nincs bekapcsolva. Aztán több órás szopás után észre veszed, hogy a Remote Desktop SZÓ NÉLKÜL lecseréli a domaint, ha az adott domainbe nincs beléptetve a gép (itt van az elcserélt szervereknek közül a történethez), és a saját domainba lépteti be a saját admint SIKERESEN, nem pedig a domain admint!
Tehát:
1. SQL nem szól, hogy ne szenvedj az sql userrel, mert nem fog menni, még hint szintjén se, ha sima windows mode-ban van feltéve.
2. Remote Desktop szó nélkül domaint cserél, ha ismeretlen a domain számára, és ha a usernév+jelszó megtalálható a gépen BE is fog lépni sikeresen...
Feliratkozás:
Megjegyzések küldése (Atom)
Hasonló szopásokban nekem is volt részem, olyan gépről próbáltam meg belépni az adatbázis szerverre (esetemben oracle volt), amely DMZ-ben volt. Azóta első dolgom ha nem megy a login, hogy telnetelem a szerveren a portot amin figyelnie kellene.
VálaszTörléspl: telnet 192.168.1.118 1433
http://msdn.microsoft.com/en-us/library/ms378845.aspx