Intriguing OleDB problem

[suityou01]

I think eek is right.

You saw the bit about impersonating the logged in user right? This is the same user account that was used to install the Oracle client, and has successfully connected to the database using oledb from a console app.

If eek is right, he's not explaining how I am wrong. The argument was that the IUSR account needs tweaking, but if I am using impersonation then that argument falls by the wayside, Shirley?

[suityou01]

Impersonation does work but there's a bit to do in IIS to get it to ACTUALLY impersonate the user. In IIS7 there is now "ApplicationPoolIdentity", which will run the App pool in the context of the user that is being impersonated.

I am using a web.config to force the impersonation, but also in the App pool I need to set the property "LoadUserProfile" to true, otherwise it will run in the context of that user without loading the user profile and hence I assume cannot access the folders eek mentioned. (Even though I set C:\Oracle and subfolders to "Everyone Full Control".

Linky

IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. SQL Express is an example of an application that does this. However, a user profile has to be created to store temporary data in either the profile directory or in the registry hive. The user profile for the NETWORKSERVICE account was created by the system and was always available. However, with the switch to unique Application Pool identities, no user profile is created by the system. Only the standard Application Pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new Application Pool.

However, if you want, you can configure IIS Application Pools to load the user profile by setting the "LoadUserProfile" attribute to "true".

[mudskipper]

Impersonation does work but there's a bit to do in IIS to get it to ACTUALLY impersonate the user. In IIS7 there is now "ApplicationPoolIdentity", which will run the App pool in the context of the user that is being impersonated.

I am using a web.config to force the impersonation, but also in the App pool I need to set the property "LoadUserProfile" to true, otherwise it will run in the context of that user without loading the user profile and hence I assume cannot access the folders eek mentioned. (Even though I set C:\Oracle and subfolders to "Everyone Full Control".

Linky

What eek said.

[suityou01]

What eek said.

I must have missed the bit where he suggested checking the properties on the application pool.

[Zippy]

So have you fixed it now? To be fair (and I read it the same way as eek) it wasn't clear you had changed the permissions in the first instance.

[eek]

I must have missed the bit where he suggested checking the properties on the application pool.

Because it was irrelevant to the immediate issue you were trying to solve. You need to sort out file permissions and access to oracle home before anything else.

Playing around with application pools was not part of your original request which was

Using the oledb provider from ODAC 10.2 to connect to an Oracle database.

In a web service (myFile.asmx) it won't connect. It just hangs on the Connection.Open(); line until it times out the web service.

However, lift the exact same code into a simple console app and it works like a charm from the same box.

for which the solution is and always well be sort out Oracles inability to set file permissions correctly.

At least I know* what to do the next time you have a problem.



*don't offer advice as it won't be appreciated. Its better to treat him with the bedwetting respect suity so rightfully deserves and laugh at his utter incompetence.

[d000hg]

OT slightly but a serious Q... SY, do you copy-paste questions onto CUK at the same time as asking on 'proper' sites like StackOverflow, or are you making the scary move to entrust your work performance to a collective who are as likely to deliberately sell you down the river as help you?!

[suityou01]

So have you fixed it now? To be fair (and I read it the same way as eek) it wasn't clear you had changed the permissions in the first instance.

Yes now fixed. Thanks to all for their help (you too eek )

After a brief search, evidence of the permissions change found in post #3.

Because it was irrelevant to the immediate issue you were trying to solve. You need to sort out file permissions and access to oracle home before anything else.

Playing around with application pools was not part of your original request which was



for which the solution is and always well be sort out Oracles inability to set file permissions correctly.

I don't see it as irrelevant. Clearly the issue was a permissions problem so you either

a) Change the file permissions on the Oracle home
b) Change the user context of the process to one that does have the necessary file permissions on the Oracle home.

In b) it's just all about making the mountain come to Mohamed I guess.

At least I know* what to do the next time you have a problem.



*don't offer advice as it won't be appreciated. Its better to treat him with the bedwetting respect suity so rightfully deserves and laugh at his utter incompetence.

Woah there cowboy, that's bedwetting speak and I have the monopoly on that around these parts. Well ok, MF and I have the monopoly.

OT slightly but a serious Q... SY, do you copy-paste questions onto CUK at the same time as asking on 'proper' sites like StackOverflow, or are you making the scary move to entrust your work performance to a collective who are as likely to deliberately sell you down the river as help you?!

I love you all equally Doogie, no need to seek attention.

[eek]

In b) it's just all about making the mountain come to Mohamed I guess.


Woah there cowboy, that's bedwetting speak and I have the monopoly on that around these parts. Well ok, MF and I have the monopoly.

Option Total Cluelessness (sorry I meant B) actually introduces a whole wad of security risks which is why you really, really, really shouldn't do it. There is a reason why the IUSR user has very minimal access rights my concern is that clientco will soon find out why.

[suityou01]

Option Total Cluelessness (sorry I meant B) actually introduces a whole wad of security risks which is why you really, really, really shouldn't do it. There is a reason why the IUSR user has very minimal access rights my concern is that clientco will soon find out why.

It is not running in the context of IUSER, rather the context of the application pool. .Net has supported impersonation for years.

I'd read up on it if I were you.

HTH