Pripojeni pres SSPI do MSSQL 2000

snazim se svoji aplikaci pripojit pres ADO komponentu v Delphi z meho domaciho PC pres VPN do MSSQL v AD domene. Pouzivam connection string zhruba v tehle podobe :

Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=jmeno_db;Data Source=nazev_serveru

Kdyz jsem tu aplikaci zacal psat, tak to fungovalo (tj. nemam zaznam z wiresharku, ale zrejme se domluvili na predani username/password k dane domene) - ted mi to vyhazuje hlasku "Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.".

Kdyz vyhodim z toho pripojovaciho retezce integrated security a dam tam username/password (sa) uzivatele nad tou DB, tak to normalne funguje (pres VPN).

Kdyz pouziju verzi s integrated security primo na tom serveru, tak to taky funguje - z toho usuzuju, ze to neni problem toho, ze by muj domenovy ucet nemel prava nad tou DB.

Na serveru funguje i ta verze, kde specifikuji primo username/password. Zkousel jsem i poslat pres VPN muj username/password a odpoved byla, ze me nemuze prilogovat.

Nevim kde bych mel hledat pricinu - na MSSQL serveru to jde jak s SSPI, tak bez, pres VPN to jde jen s urcitym userem. S SSPI to slo, ale uz nejde - viz hlaska. Muj uzivatel je Domain Admin.

Zkousel jsem i sdileni pres VPN, kde se me to zepta na username/heslo a pripoji mi to vzdaleny disk normalne a nepomohlo to.

Hledal bych problém v tom, že tvoje aplikace nesprávně předává username - proto máš v té hlášce (null).
Ten komp, ze kterého to pouštíš, je v doméně? Pod jakým userem aplikaci spouštíš? Doménovým nebo lokálním?

2Marty - no prave, ze kdyz tam dam integrated security, tak to delam proto, abcy tam zadne username davat nemusel. Verze, kde do conenction stringu username davam - ta chodi.

Na domacim desktopu to poustim po lokalnim userem. Moje predstava byla takova, ze s integrated security se predaji username/password prislusejici k te domene, pokud je OS zna a kdyz ne - tak vyskoci dialog k zadani. Jeste jsem zkousel koukat na spojeni wiresharkem a prijde challenge packet s nazvem serveru a domeny, na ktery moje WInXP odpovidaji s lokalnim uzivatelskym jmenem.

Nakonec jsem si ten program pustil na ntb ve stejny siti (domaci), ale s Win2k4. Ve wiresharku je videt, ze si pres VPN rozhranni pokeca s tim serverem a pres pipe na SQL se domluvi o protokolu predani jmena a hesla do domeny.
Nejdriv neslo ani to, ale pak jsem se prihlasil na share domenovym jmenem a heslem a i ten muj program zacal fungovat. - Nicmene - neni urceny pro praci pres VPN a primo v te domene chodi i s SSPI.

Jenom nevim, proc kdyz se pripojuju z domaciho desktopu VPN k te domene (vlastne na server, kde bezi i ten SQL) - proc se ten program (ocividne pres TCP a ne pres pipe) nespoji s tim MSSQL serverem - i kdyz to predtim delal....

Citace:

---

Původně odeslal Lukas L.

2Marty - no prave, ze kdyz tam dam integrated security, tak to delam proto, abcy tam zadne username davat nemusel. Verze, kde do conenction stringu username davam - ta chodi.

---

Jo tak jsem to ani nemyslel, spíš jsem to směřoval tak, že nějaké nastavení kolem SSPI je špatně, případně že tvůj komp nějak špatně reaguje. Aplikace je evidentně v pořádku, když jinde funguje, tak bych hledal problém v tvém kompu. Nejsem programátor, nikdy jsem něco takovýho neprogramoval, ale AFAIK jak autentikace na MSSQL funguje, ... tak je to pěkná magie občas.

no prave - na MSSQL mam mixed mod, prava k DB mam (snad i) v poradku (hlavne, kdyz se stejnym loginem primo v domene to jde ok). Jen se mi nedari se SSPI napojit pres VPN z winxp - ale nevim proc - jestli to dela najeka politika (posilat/neposilat LM/NTLM/NTLM2,vyzadovat sifrovani atd atd - i kdyz nevim jestli to neni jen pro SMB, na druhou stranu to muze mit vliv i pripojeni pres pipe) - na ntbku jsem si s tim (GPO a registry netlogonu) nehral (porovnal jsem to a ty registry minimalne mam nastaveny stejne). Na desktopu mam WinXP uz jara 2004 - takze muzou byt v zajimavem stavu (reinstal planuju az na pripadne nove PC). Nebo mozna nejaka .DLL MSSQL klienta... nevim...