[ASP.NET - MSSQL] Windows Integrated Authentication

[Griffin]

Tweakers,

Ik zit met een probleem.

Situatie:
Ik heb een applicatie in ASP.NET. In de web.config staat nu een ConnectionString waarin de user/pass zichtbaar zijn. Verder worden de gebruikers ingelogd via de ActiveDirectory.
Verder gebruik ik de 'LOGON_USER' (Request.ServerVariables["LOGON_USER"]) in de databse om te kijken wie ingelogd is en welke rechten deze gebruiker heeft. (De rechten komen uit een eigen database waarin de AD-userid is opgeslagen)

Dit werkt allemaal perfect en mensen die geen toegang hebben, hebben ook echt geen toegang.

Wat is nu het probleem, tja de connectionstring. Mijn leidinggevende wil het liefst het volgende.
- Gebruikers blijven op de huidige manier inloggen
- Geen user/pass in de web.config als plain tekst
- 1 domain user welke toegang heeft tot de MSSQL. Deze gebruiker moet dan gekoppeld worden aan de applicatie dat IIS deze user gebruikt om connectie te krijgen met de database.

Mijn leidinggevende weet dat het kan alleen niet weet niet hoe (ik dus ook niet).

Nu ben ik op internet gaan zoeken en al verschillende sites gevonden, echter geen die precies richten op de aanwezige wensen.
zo heb ik deze bekeken alleen wordt hier gebruik gemaakt van basic authentication en moet elke user toegang hebben tot de DB ipv 1.
ook heb ik deze bekeken, echter hier gaan ze er vanuit dat de MSSQL en IIS op dezelfde server staan. Echter dit is niet het geval. IIS en MSSQL staan beide op andere fysieke servers.

Wat heb ik al geprobeerd
De heb momenteel de volgende settings:
in de web.config staat het volgende:

code:

<add name="Connection" connectionString="Data Source=DBSVR;Initial Catalog=DBNAME;Integrated Security=True;Trusted_Connection=yes;"/>

<authentication mode="Windows" />
<identity impersonate="true"/>

(namen zijn fictief)

Naar mijn weten moet er ook nog iets ingesteld worden in de application pool namelijk het volgende:
- Identity niet gekozen voor 'predefined' maar 'Configurable'. Hier staat de DomainUser welke ook rechten heeft op de database.

Dan nog de settings van de applicatie (welke on Default website hangt):
in het authentication scherm heb ik:
- Anonymous access UIT staan
- Integrated windows authentication AAN staan
- Digest authentication AAN staan
- Domain ingevuld bij Realm.

Het probleem is nu echter dat als ik de applicatie draai dat ik een inlogprompt krijg. Ik kan heir elke domain user invullen die ik wil alleen de prompt blijft terug komen.

Mijn interpretatie
- Impersonatie moet op True omdat IIS en MSSQL op aparte servers staan
- De authenticate settings van de applicatie staan zo goed omdat ik geen anonymous logins wil en de users moeten inloggen via hun ADuserid.
- De connectionstring goed is omdat ik aangeef dat ik gebruik wil maken van Integrated Security en dat het een trusted connection is.

Ik hoop dat mn (lange) verhaal duidelijk is en dat jullie kunnen helpen.

[Snake]

Je moet impersionating uitzetten van de client > IIS. En dan de IIS worker laten draaien onder je domain user. Die heeft daan weer toegang tot je SQL server.

En zelf kan je dan nog de users op je website authenticeren op jouw manier.

[Griffin]

@ snake:
Nu ben ik geen held op het server gebied maar het uizetten van impersonate snap ik nog, maar wat bedoel je met het laten draaien van de IIS worker on mijn domain user (die dus toegang heeft tot de DB).

Als ik dit doe moet ik dan nog wel alle settings van de application pool en de andere settings zoals in de TS staat zo laten staan?


Edit:
Nu heb ik even lokaal alles ingesteld op IIS7 (server is IIS6). En daar werkt het dus wel.
Nu is het zo dat ik dan in de web.config niets over

code:

<authentication mode="Windows" />
    <identity impersonate="true"/>

staan.

Ik heb gewoon via IIS7 bij Authentication alles ingesteld: (als volgens):
- Anonymous UIT
- Impersonation UIT
- Basic UIT
- Digest AAN op realm domain
- FORMS UIT
- Windows AAN

Nu alles overproberen te zetten naar IIS op de server

UPDATE:
Een of andere reden werkt het dus niet op onze testserver met IIS6. Ik krijg wederom de inlogprompt

[ Voor 47% gewijzigd door Griffin op 23-10-2009 15:04 ]

[Niemand_Anders]

Waarom gebruik je hiervoor impersonatie? Je zegt dat je nu in de connectie de username/password hebt staan.
Je kunt vrij eenvoudig de connectie string veranderen naam integrated security zoals je hebt gedaan. Vervolgens verander je nog niets op de database aan rechten en maak je vanaf de webserver verbinding met de database. Die connectie gaat fout maar dat maakt niet uit. Vervolgens kijk je in de logging van je database server welke user werd gebruikt om verbinding met de database te maken. De gebruiker moet je vervolgens voldoende rechten op de applicatie database gegeven.

Je kunt natuurlijk ook de domain user impersoneren en deze gebruiken in combinatie met integrated security. Alleen zet dan de rechten op domain groups en niet op de individuele groepen anders wordt management een nachtmerry. Je zou eventueel kunnen overwegen om voor de website speciaal een aantal groepen in AD aan te maken.

[Snake]

Je moet 1 user aanmaken op je DB die de rechten nodig heeft die jij nodig hebt.

Dus read, write, execute en delete.

Dan ga je in IIS bij je worker process waar je website onder draait. Die draai je dan onder je nieuw aangemaakte user.

Zorg dat die user toegang heeft tot de mappen waarin de website staat gehost.

Waarom? Omdat je zo maar 1 user toegang moet geven tot de SQL server, ipv alle users die op die website komen.

En de users die op de website zelf komen kan je authenticeren met een eigen authentication module.

[AtleX]

Wat is het probleem met de username & password in de Web.Config? Volgens mij ben je namelijk een probleem aan het oplossen dat geen probleem is. Om je ASP.net user alle rechten te geven op alle databases lijkt me wat minder handig namelijk. Dat betekent dat bij een lek ergens in je web-applicaties of server alle databases gecompromiteerd zijn.

[Griffin]

@niemand anders:
Impersonatie heb ik nu dus uitstaan en dat werkt correct op IIS7 op mijn huidige (work)machine terwijl de DB op een andere server staat.
Ik heb gekeken wat jij zegt met kijken welke user er standaard wordt gebruikt, alleen ik kom dus niet voorbij dat inlogpromt scherm. Dus kan dat ook niet checken.

@snake:
• De DB user heb ik ingesteld in de database
• Wat jij bedoeld met "Dan ga je in IIS bij je worker process waar je website onder draait. Die draai je dan onder je nieuw aangemaakte user." is mij nog niet helemaal duidelijk.
• de aangemaakte domain user heeft fullcontrol op de map waar de website in staat.

Ik snap waarom je dit doet, want zo wil ik het ook (maar 1 user die toegang heeft tot de Db en deze user wordt geregeld in het AD).

Momenteel heb ik het dus werkend als volgt:
- IIS draaid op mijn desktop machine en is Versie 7.
- MSSQL draaid op de standaard SQL server hier (2005)

Dan heb ik de volgende stappen gedaan.
- AD user aangemaakt
- AD User gekoppeld aan database
- Application pool aanmaken met Identity van de aangemaakt AD User
- Virutal directory aangemaakt en deze koppelen aan de application pool
- de volgende settings gebruikt:
\- Anonymous UIT
\- Impersonation UIT
\- Basic UIT
\- Digest AAN op realm domain
\- FORMS UIT
\- Windows AAN
- Daarna de virutal directory omgezet naar Application.

De bovenstaande stappen heb ik ook herhaald op de test server met IIS 6 echter de laatste stap lukt daar niet. De virtual directory omzetten naar application (terwijl deze onder default website hangt).

AtleX schreef op vrijdag 23 oktober 2009 @ 15:14:
Wat is het probleem met de username & password in de Web.Config? Volgens mij ben je namelijk een probleem aan het oplossen dat geen probleem is. Om je ASP.net user alle rechten te geven op alle databases lijkt me wat minder handig namelijk. Dat betekent dat bij een lek ergens in je web-applicaties of server alle databases gecompromiteerd zijn.

Mijn leidinggevende wil dit liever gewoon niet hebben omdat het toch gevoelige info is.
Verder kennen we niet onze ASP.net user toe aan alle db's maar voor deze ene applicatie wordt er 1 ADUser aagemaakt door mijn leidinggevende.
Hij is nu dus degene die de applicatie beheer en weet straks dus niemand (behalve hij) de wachtwoorden ervan. Want de applicatie komt straks ook op een productserver te draaien waar niet alle ontwikkelaars toegang tot hebben.

[ Voor 22% gewijzigd door Griffin op 23-10-2009 15:18 ]

[AtleX]

Griffin schreef op vrijdag 23 oktober 2009 @ 15:16:
[...]

Mijn leidinggevende wil dit liever gewoon niet hebben omdat het toch gevoelige info is.

Die niemand kan zien zonder toegang tot de server.

Verder kennen we niet onze ASP.net user toe aan alle db's maar voor deze ene applicatie wordt er 1 ADUser aagemaakt door mijn leidinggevende.

Maar dan loop je tegen het probleem aan dat je die user moet gaan impersonaten, waardoor je de user credentials van de ingelogde user kwijt bent. Anders moet je de ASP.net user, waar je applicatie onder draait, toegang geven tot de DB en dan kom je weer uit bij de eerder genoemde beveiligingsproblemen.

Hij is nu dus degene die de applicatie beheer en weet straks dus niemand (behalve hij) de wachtwoorden ervan.

En toen viel 'ie voor de bus...

Want de applicatie komt straks ook op een productserver te draaien waar niet alle ontwikkelaars toegang tot hebben.

Dat maakt toch niet uit? Zodra de applicatie geïnstalleerd wordt door de systeembeheerder of wie dat dan ook gaat doen zet 'ie de credentials in de Web.config goed.

[Griffin]

AtleX schreef op vrijdag 23 oktober 2009 @ 15:32:
[...]

Die niemand kan zien zonder toegang tot de server.

[...]

Maar dan loop je tegen het probleem aan dat je die user moet gaan impersonaten, waardoor je de user credentials van de ingelogde user kwijt bent. Anders moet je de ASP.net user, waar je applicatie onder draait, toegang geven tot de DB en dan kom je weer uit bij de eerder genoemde beveiligingsproblemen.

[...]
En toen viel 'ie voor de bus...

[...]

Dat maakt toch niet uit? Zodra de applicatie geïnstalleerd wordt door de systeembeheerder of wie dat dan ook gaat doen zet 'ie de credentials in de Web.config goed.

Viel ie maar even voor een bus, was ik er nu vanaf .
Ik snap jouw kant van het verhaal ook wel en ik zie het zo ook, maar als mn leidinggevende het in dit geval zo wil hebben dan doen we het maar zo .

Verder ga ik op de testserver maar even helemaal vanaf scratch beginnen met de opbouw van IIS en kijken waar het fout gaat.

[Verwijderd]

Volgens mij moet je gewoon een "application pool" aanmaken in IIS, die toewijzen aan jouw webapplication (virtualdir of aparte site). Je zet dan de user die DB access heeft als de credentials voor die specifieke application pool en klaar. Ik heb bij mijn asp.net apps nergens credentials in mijn web.config staan. Ik gebruik de "rolebased" security van SQL/ASP.NET met een remote DB server.

Grtz,
Thanis

[urk_forever]

Misschien is het encrypten van de connection string een makkelijkere oplossing?

Voorbeeld

[Griffin]

urk_forever schreef op vrijdag 23 oktober 2009 @ 16:03:
Misschien is het encrypten van de connection string een makkelijkere oplossing?

Voorbeeld

Die heb ik al uitgevoerd en werkt perfect, alleen leidinggevende weet dat dit kan dus wil hij het ook zo hebben .

Heb net IIS weer opnieuw opgebouwd op de testserver en krijg nu een "Service Unavailable". Volgens eventlog komt dit omdat de identity van de application pool invalid is. Ik heb (om goed te kunnen testen ) een nieuwe ADUser laten aanmaken en heb ik allemaal ingevuld.
Ach ik ga nog even door en dan is het weekend, is het nog niet opgelost dan is er maandag weer een dag.

Update:
Na net een extra test uit te voeren kom ik erachter dat:
- Lokaal op mijn pc het werkt
- Als andere computers via mijn IIS de site bezoeken werkt het ook
- Als je op de testserver inlogt en dan localhost gaat kijken bij de site werkt het ook
- Als je via een externe pc (dus niet de server) naar de site gaat werkt het dus niet.

Tot zo ver zijn we. Maandag maar eens naar firewalls en rechten kijken etc.

[ Voor 21% gewijzigd door Griffin op 23-10-2009 17:12 ]

[Griffin]

Update:
Na maandag en dinsdag verder te prutsen op een andere server (om uit te sluiten dat het aan de server ligt) zijn we bijna klaar. (eigenlijk werkt het al).
We hebben het vinkje bij 'Windows authentication' in de websitesettings in IIS uitgezet. Digest staat wel aan.

Het werkt nu vanaf buiten en vanaf binnen. Het enige is dat vanaf intern er ook gevraagd word om in te loggen. Voor nu werkt het iig maar we gaan nog wel even verder zoeken.

[Griffin]

Nogmaals een update maar dan met de oplossing (voor als iemand dit probleem ook heeft in de toekomst).

Na lang zoeken bleek het dus een bug te zijn die in de knowledgebase van microsoft staat:
MS Knowledge base - Article ID: 871179

Hieronder een toelichting hoe alle settings moeten staan.

---

Aller eerst natuurlijk uitvoeren wat wat in de knowledge base - Article ID: 871179 staat.

Active Directory:
Maak een user met normale gebruikers rechten. Deze gebruiker gaat connectie maken naar de database.

MSSQL:
Zorg ervoor dat de AD gebruiker toegang heeft tot de database en daar de CRUD uit kan voeren.

IIS:
Application Pool:

• Voeg een Appliction Pool toe met standaard settings.
• Open properties en ga naar tab "Identity"
• Kies optie "Configurable" en vul hier de AD User in die aangemaakt hebt.

Website:

• Nieuwe vrituele directory met de standaard settings en eigen namen
• Open properties van de site
• Kies de zojuist aangemaakte Application Pool
• Ga naar de tab "Directory Security" en klik de knop "Edit"
• Disable "Anonymous access"
• Enable verder ALLEEN "Integrated Windows Authentication"

Web.config:
In je web.config moet het volgende staan:

code:

<add name="[ConnStringName]" connectionString="Data Source=[Servername];Initial Catalog=[DbName];Integrated Security=True;Trusted_Connection=yes;" providerName="System.Data.SqlClient"/>

Verder:

code:

<authentication mode="Windows"/>

---

Dat is het en dan zou het moeten werken.

Iedereen iig bedankt voor de hulp in eerste instantie.