[ASP.Net] OracleClient en andere tnsnames.ora locatie

[kross]

Hoi,

Ik heb een webapplicatie met ASP.Net en die maakt via de oracleclient gebruik van een Oracle database. Dit gaat allemaal goed zolang er maar een tnsnames.ora in de map: C:\Program Files\Oracle\ora81\network\ADMIN staat. Maar wij gebruiken één centrale tnsnames voor alle servers i.v.m. onderhoud. Daarom gebruiken we normaal de volgende registry edits:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0]
"TNS_ADMIN"="P:\\ORACLE"
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME1]
"TNS_ADMIN"="P:\\ORACLE"

Voor toad en andere oracle applicaties werkt dit, alleen niet voor de ASP.Net applicatie. De webapp schijnt deze instelling te negeren, deze geeft dan de melding: ORA-12154: TNS:servicenaam kon niet worden herleid (als ik de tnsnames.ora weer terug zet werkt het weer).

Nu heb ik in het volgende berichtje ook gelezen dat iemand hiernaar zoekt, maar heb verder nog geen antwoord gevonden:

http://groups.yahoo.com/group/AspNetOracle/message/60

Weet hier iemand een oplossing?

Groetjes,
kross

[sander_g]

De instellingen die je hier laat zien zeggen dat tnsnames.ora op een P: schijf te vinden zijn.
1) de P: schijf zal het ASPNET account niet zo maar herkennen. Dat deze mapping bestaat als je interactief inlogt op de webserver zegt niets over de beschikbaarheid van deze mapping onder een service-account.

2) als je dit zou veranderen in een UNC-pad (\\server1\data\oracle o.i.d.) dan zou het ASPNET account rechten op de share en het bijbehorende pad moeten krijgen.

[EfBe]

ASP.NET user mag geen registry entries lezen, dus die kan niet bij die namen en DUS kan hij geen tnsname ophalen om bij je server te komen. OF je asp.net applicatie onder een user draaien die wel registry entries mag lezen OF (en dat weet ik dus niet hoe dat zou moeten) de Oracle Client software zo configureren dat deze onder een aparte user draait en wel de registry settings kan lezen of dat deze via andere wegen kan achterhalen welke tnsname server hij moet benaderen voor de login.

[sander_g]

Of het ASPNET account registry entries mag lezen hangt er maar net vanaf hoe e.e.a. geconfigureerd is. Standaard is het ASPNET account lid van de users-groep. En deze groep heeft lees-rechten op de registry. Misschien niet alle, maar in ieder geval de HKEY_LOCAL_MACHINE.

Daar hoeft het dus niet aan de te liggen. Schrijfrechten is natuurlijk een ander verhaal.

Misschien dat het op Win2003 inmiddels weer anders is.

[EfBe]

flybyfibre schreef op 02 October 2003 @ 13:27:
Of het ASPNET account registry entries mag lezen hangt er maar net vanaf hoe e.e.a. geconfigureerd is. Standaard is het ASPNET account lid van de users-groep. En deze groep heeft lees-rechten op de registry. Misschien niet alle, maar in ieder geval de HKEY_LOCAL_MACHINE.

Nee, dit is onzin. ASPNET user mag geen registry keys lezen, period.

[sander_g]

Als het waar zou zijn dat het ASPNET account geen registry keys zou kunnen lezen, waarom geeft Microsoft dan een kb artikel uit waarin beschreven staat hoe je username/password credentials voor ASP.NET kunt opslaan en ophalen in de registry?
http://support.microsoft.com/default.aspx?scid=329290
http://msdn.microsoft.com...nnetsec/html/thcmch19.asp

Toegegeven, hier staat wel dat het ASPNET account readpermissies moet krijgen op de specifieke entries in de registry. Maar het is dus niet uitgesloten dat ASPNET de registry in mag.

Ook een program manager van MS bevestigt dit

http://msdn.microsoft.com/chats/vstudio/vstudio_030702.asp
Erik_MS
A: You're right, it's the process identity (the local ASPNET account). Generally, that account can read the registry but not write it.

Zo'n onzin is het dus niet.

[EfBe]

Dan geloof je het niet Het is JOUW systeem dat het niet doet. Er zijn zoveel vragen al gesteld omtrent zaken die men uit de registry wil lezen vanuit een ASP.NET page... Het is wellicht verstandig impersonation te gebruiken in je website of de ASPNET user leesrechten te geven op die keys. Start regedt32 maar en kijk maar welke rechten de aspnet user heeft. 0.0. Dit komt omdat die user niet inlogt.

[ Voor 4% gewijzigd door EfBe op 03-10-2003 09:52 ]

[sander_g]

EfBe:
De discussie begint op een welles/nietes te lijken en het lost de probleem van de vrager niet op. Ik heb je maar een mailtje gestuurd.

[Surehand]

Als je de environment variabele TNS_ADMIN de waarde p:\oracle geeft, overschrijft dat de entry in het register, of die nu wel of niet gelezen kan worden...

[EfBe]

Surehand schreef op 03 October 2003 @ 11:54:
Als je de environment variabele TNS_ADMIN de waarde p:\oracle geeft, overschrijft dat de entry in het register, of die nu wel of niet gelezen kan worden...

De ASPNET user heeft geen environment variables, hij logt nl. niet in als een interactive user (hij heeft ook geen user profile geladen, je kunt ook geen crypto providers creeeren onder ASPNET hierdoor bijvoorbeeld).

Veelal draait op een devbak de aspnet_wp.exe onder 'SYSTEM' en niet onder 'ASPNET'. Dit werkt dan fantastisch, maar wanneer de site wordt gedeployed op een standalone, dichtgetimmerde webserver werkt het ineens niet meer. Dit komt dan omdat aspnet_wp.exe niet meer onder system draait maar onder 'ASPNET', een user die geen rechten heeft op de registry.

Zie posting van Scott Guthrie, een van de 2 makers van ASP.NET: http://groups.google.com/...BnnBHA.2244%40tkmsftngp02

Helemaal onderaan staat:

A few other scenarios that will now require explict ACL permissions to be
set in ASP.NET RTM (but didn't in beta2):

-- Creating new EventLog categories dynamically

-- Creating new PerfMon categories dynamically

-- Sending email using the NT SMTPMail Service

-- Using WMI (System.Management)

-- Registering COM+ components (System.EnterpriseServices)

-- Reading the Registry or IIS Metabase

Mja, ik verzin het niet hoor. Het is ook heel logisch: als de ASPNET user de registry kan lezen kan een attacker essentiele info achterhalen en dat hoeft niet, want de ASPNET user heeft de registry niet nodig om een site te draaien.

[EfBe]

Voor wat het waard is: op mijn lokale Win2k server bak heeft de users group GEEN access op HKLM\Software (is domain controller). Alleen de authenticated users. En daar zit het hem nu net in: ASPNET logt niet in. Op mn online bak (win2k standalone webserver) is ASPNET lid van users en kan hij wel HKLM\software lezen dmv de users group.

Op mn winxp doos werkt het wel, daar is de HKLM\Software hive dus wel beschikbaar voor local user group.

Kennelijk is het dus per situatie verschillend wat de rechten zijn van ASPNET. Ik heb alleen HKLM\Software getest, wellicht zijn er veel meer keys die onder 'authenticated users' vallen en daar valt ASPNET nooit onder.

Conclusies:
- men spreekt elkaar tegen bij MS: de een roept ja de ander nee
- er zijn veel mensen op internet terug te vinden met problemen gerelateerd aan leesrechten van ASPNET op registry keys.
- ASPNET user logt NIET in, en valt dus nooit onder authenticated users. Check de rechten van de keys die nodig zijn voor Oracle Client (via regmon bv) en check of ASPNET leesrechten heeft op die keys.
- Soms draait een website vrolijk onder IUSR_systemname ipv ASPNET, deze user heeft minder rights (is lid van guests, niet van users).

[Surehand]

Om (eigenwijs wellicht) terug te komen op de oplossing die ik aangaf: kan de ASPNET user wel de System environment variabelen lezen?

Zo ja, dan kan de variabele daar toch worden gedefinieerd?

Zo nee, hoe kunnen dan 'standaard' variabelen (PATH e.d.) worden uitgelezen?

[sander_g]

Surehand schreef op 03 October 2003 @ 12:57:
Om (eigenwijs wellicht) terug te komen op de oplossing die ik aangaf: kan de ASPNET user wel de System environment variabelen lezen?

Zo ja, dan kan de variabele daar toch worden gedefinieerd?

Zo nee, hoe kunnen dan 'standaard' variabelen (PATH e.d.) worden uitgelezen?

Voor zover ik kan zien kan je inderdaad System environment variabelen uitlezen. De volgende C# regel toont mij op een ASP.NET Web Server keurig het pad:

code:

   Response.Write(System.Environment.GetEnvironmentVariable("PATH"));

En ja, dat is onder het ASPNET account. Het zal echter lastig zijn/worden om ASPNET user specifieke variabelen te zetten. De ASPNET user logt immers niet interactief in op een server.