[.NET Remoting] Geen toegant tot DB met SSPI

[whoami]

Ik heb de volgende situatie:

Ik heb een server waar IIS 6 opstaat, en een SQL Server 2000 DB.
Ik heb een aantal .NET remoted objects op die server staan, die gehost zijn in IIS. Deze objecten maken connectie met de SQL Server DB.
Dit werkt allemaal fijn zolang ik 'SQL Authentication' gebruik om toegang te krijgen tot de DB (dit wil dus zeggen dat mijn connectionstring een username en pwd bevat van een SQL account).
Echter, ik wil dit nu wijzigen zodat ik 'integrated security' kan gebruiken. Hiervoor heb ik m'n connectionstring gewijzigd zodat integrated security (SSPI) gebruikt wordt.
Echter, hier krijg ik een 'internal server error' op. Ik ben er nog niet in geslaagd om een gedetailleerde foutmelding te verkrijgen (ook niet met customErrors="off" in m'n web.config).
Ik ben er echter vrijwel zeker van, dat het met die connectionstring te maken heeft.
De ASP.NET user heeft ook rechten op de DB, dus dat kan het ook niet zijn.
Wat ook vreemd is, is dat het bij mij lokaal wel werkt:
Lokaal heb ik IIS 5.1 draaien, SQL Server 2000, en met de remoted objects die ik locaal staan heb, kan ik de DB wel accessen via integrated security.

Iemand ideeën, tips ?

[whoami]

Op een andere server met IIS 5.1 lukt het ook niet.... Dus ik denk ook niet dat het aan IIS6 ligt.

[whoami]

Ik ben er uiteindelijk in geslaagd om een wat betere foutboodschap te krijgen.

Deze is:

"Member name 'System.Data.SqlClient.SqlError server' not found."

[Infinitive]

Ik neem aan dat de sqlserver wel in hetzelfde domain zit als de webserver?
Lekker veelzeggende foutmelding trouwens

[ Voor 24% gewijzigd door Infinitive op 11-05-2005 12:22 ]

[whoami]

De SQL Server zit in het zelfde domain ja.
De foutmelding is idd veelzeggen.

Volgende stap: ik heb iemand laten inloggen vanaf zijn laptop op mijn workstation (mijn workstation is dus 'server'), en dat werkt wel....

[Infinitive]

Wat als je nu eens in een console app probeert om connectie met de database te maken. Dat zou dan ook niet moeten lukken. Maar dan kan je in ieder geval een heleboel situaties uitsluiten?

Je kan sqlserver ook zo configureren dat alleen sql logins geaccepteerd worden, of alleen SSPI logins. Ik neem aan dat je daar al wel naar gekeken hebt, hoewel dat geen kwaad kan om te controleren natuurlijk.

Ik weet verder ook niet of hij nog bepaalde andere poorten voor SSPI logins gebruikt? Anders zou je ook nog naar firewalls en dergelijke kunnen kijken...

[ Voor 50% gewijzigd door Infinitive op 11-05-2005 12:34 ]

[whoami]

Ok, ik krijg nu volgende melding op IIS 6 server:

Login failed for user 'NT Authority\network service'

De ASPNET user heeft rechten op de DB, maar blijkbaar werkt IIS6 met een andere user ?

[ Voor 32% gewijzigd door whoami op 11-05-2005 13:15 ]

[whoami]

Ik heb het opgelost door de '<machinename>\IIS_WPG' user access te geven tot sql server en de bijhorende DB.
Ik wist niet dat IIS6 met die user werkte....

Nu maar eens kijken of ik dat niet beter dmv impersonation kan oplossen.

[victorv]

Een workerprocess (W3WP) is de 'afhandelaar' van een HTTP request en draait onder de account van de ApplicationPool van de website, normaal de NetworkService (een weinig gepriviligeerde account).
Onder dit account probeert jouw applicatie nu de database te benaderen en die heeft geen rechten op jouw DB server.
Een paar mogelijkheden:

• Wijzig het account waaronder de ApplicationPool van de website draait van NetworkService naar een account dat ook toegang heeft op de database (een domain account?).
• je kunt impersonation en Windows Integrated Authentication aanzetten in de web.config, zodat jouw ASP.NET applicatie (de remoting dingen) werken onder de account van de aanvragende user (werkt prima op een Intranet). Elke user account moet dan ook bekend zijn op de DB, anders is er geen toegang.
• Je kunt beter de DB connectie string zo laten als tie is, zodat je met slechts 1 DB account te maken hebt. De connectiestring kun je opslaan in je web.config en dan wel geencrypt via DAPI. Zoek maar eens op DAPI op msdn.microsoft.com, dan vind je een heel artikel over DAPI. Ik geloof dat Keith Brown er ook iets over geschreven heeft in zijn Security Wiki/Boek op http://pluralsight.com/wiki/default.aspx

[ Voor 9% gewijzigd door victorv op 11-05-2005 13:29 ]

[whoami]

Naar DAPI heb ik eerder deze week al eens gekeken, om m'n connection string te encrypten.

Waarom zeg je dat het beter is om via sql authentication te werken ipv met integrated security ?

[victorv]

Met SQL authentication heb je maar 1 account die database access nodig heeft (een common scenario). Account management is eenvoudig en iedereen heeft toegang tot dezelfde data.

Met Integrated Security moet elke account die toegang moet hebben tot de database ook access hebben tot de database. Account management is lastiger. Het kan natuurlijk zijn dat jouw applicatie vereist dat verschillende users tot verschillende data toegang heeft en dat je dat via de database toepast.

[whoami]

Sonii schreef op woensdag 11 mei 2005 @ 14:46:
Met SQL authentication heb je maar 1 account die database access nodig heeft (een common scenario). Account management is eenvoudig en iedereen heeft toegang tot dezelfde data.

Met Integrated Security moet elke account die toegang moet hebben tot de database ook access hebben tot de database. Account management is lastiger. Het kan natuurlijk zijn dat jouw applicatie vereist dat verschillende users tot verschillende data toegang heeft en dat je dat via de database toepast.

Met integrated security heb ik, in mijn geval, ook slechts 1 account nodig die DB access heeft.... Alle DB access gebeurt via de remote componenten, dus enkel de account waar m'n ASP.NET componenten onder draaien, heeft access nodig tot die DB.

[Gé Brander]

Sonii schreef op woensdag 11 mei 2005 @ 14:46:
Met SQL authentication heb je maar 1 account die database access nodig heeft (een common scenario). Account management is eenvoudig en iedereen heeft toegang tot dezelfde data.

Met Integrated Security moet elke account die toegang moet hebben tot de database ook access hebben tot de database. Account management is lastiger. Het kan natuurlijk zijn dat jouw applicatie vereist dat verschillende users tot verschillende data toegang heeft en dat je dat via de database toepast.

Dat is ook een non arugement, omdat als je integrated security gebruikt, je dat ook goed moet doen. D.w.z. gebruik dus AD groups waar de users die toegang moeten hebben lid van gemaakt kunnen worden. Op deze wijze hoef je maar 1 AD account (de group account) bekend te maken in de server en database. Net zoveel werk binnen de SQL Server als een SQL account.

B.t.w. De NT Authoroty\Network Service account heb je eigenlijk ook nodig binnen je SQL Server als je MSDTC gebruikt of een geclusterde omgeving hebt.

[ Voor 8% gewijzigd door Gé Brander op 11-05-2005 16:26 ]

[whoami]

Ik heb enkel de 'network account' toegang gegeven op sql server.

Ik zie niet in waarom ik beter SQL Server authentication gebruik ipv Windows authentication.
Windows auth. is imho veel veiliger, omdat je dan zowiezo al moet kunnen aanloggen bij windows.

Nu nog ff verder zoeken mbt application pools in IIS6 en we kunnen weer gaan.

[Gé Brander]

whoami schreef op woensdag 11 mei 2005 @ 23:29:
Ik zie niet in waarom ik beter SQL Server authentication gebruik ipv Windows authentication.
Windows auth. is imho veel veiliger, omdat je dan zowiezo al moet kunnen aanloggen bij windows.

Dat zie je dan ook helemaal goed.
Het is jammer dat er nog maar weinig bedrijven die hun applicatie voor SQL Server niet of niet goed geschikt hebben gemaakt voor Windows authentication. Security op velerlei vlakken is helaas nog steeds onderbelicht.

Ik denk dat dat voornamelijk komt doordat de gemiddelde ontwikkelaar geen idee heeft van beheer en de gemiddelde beheerder geen idee heeft van ontwikkeling.

Deze twee partners (want dat zijn ze toch echt) wat vaker naar elkaar zouden moeten luisteren, dan krijg je een veel beter product namelijk.

[Verwijderd]

Wat je moet doen is een windows gebruiker aanmaken die toegang heeft tot de MSSQL database.

voeg deze gebruiker in IIS

Zet in je web.config het volgende
<system.web>
<identity impersonate="true" />
</system.web>

dan zou het moeten werken

[whoami]

Ja, dat weet ik wel, en het werkt ook al.
Maar mijn initiele probleem had daar niet mee te maken; het had te maken met het feit dat IIS6 een andere gebruiker gebruikt dan IIS5.1.
Ik moest dus gewoon nog IIS_WPG toevoegen aan de DB.
Nu weet ik ook wel dat ik dat beter kan oplossen door mbhv impersonasitation te werken, en die user toegang te verschaffen tot de DB.