T
tmsprowl
Greetings!
I was wondering if someone could help me with a problem I'm having.
My department is just one of many within my organization. My
organization has control over the network domain, but my department has
a couple of web servers of our own that are part of my organization's
domain. I am trying to read LDAP information on my organization's
domain controller from a web application on one of my department's
servers. I have been told that anyone in the domain can retrieve the
LDAP information and on our applications that require authentication,
this is true. It's the applications that do not require authentication
that pose a problem. I must impersonate an account within the domain
in order to retrieve the information. This works flawlessly on our
applications that are still using .NET 1.1 and reside on the other of
my department's servers, but seems to be failing under .NET 2.0 on this
particular server. I receive the following error:
Configuration Error
Description: An error occurred during the processing of a configuration
file required to service this request. Please review the specific error
details below and modify your configuration file appropriately.
Parser Error Message: Error reading configuration information from the
registry.
Source Error:
Line 41: <customErrors mode="Off"/>
Line 42:
Line 43: <identity impersonate="true"
Line 44:
userName="registry:HKLM\SOFTWARE\LibraryASPNetApps\Identity,userName"
Line 45:
password="registry:HKLM\SOFTWARE\LibraryASPNetApps\Identity,password"/>
I created the registry keys using aspnet_setreg following instructions
in Microsoft's KB Article 329290 using a valid user account on the
domain. The Identity key has the following permissions:
Administrators: F
<servername>\ASPNET: R
CREATOR OWNER: None, and I can't set them; after setting it, it just
defaults back to none.
SYSTEM: F
The ASP.NET worker process also has write permissions on the Temporary
ASP.NET Files folder (for version 2.0, as that's what the application
is written in) and read access on the application's directory.
On a whim of advice from another posting on the groups, I gave Everyone
read permission for the Identity registry key, but that availed
nothing. At one point, I restarted our server but all that seemed to
happen was that the Identity registry key had its permissions reset.
Both of our servers are running Windows 2000 with Service Pack 4 and
IIS 5.0. Both of our servers have .NET Framework 2.0 installed, even
though most of our applications on the first server are still using
..NET 1.1. Aside from .NET version differences and the servers the
applications are residing on, I can find no differences between the 2.0
application that's causing the problem and the 1.1 applications that do
not. Everything else is the same: the operating system, IIS, the
account being impersonated, the permissions on the folders and registry
keys. Both servers have the most recent critical updates installed.
Would anyone here happen to know the cause of this problem or perhaps
the solution to it? My guess is that there is something exceptionally
simple that I'm overlooking.
Thank you.
I was wondering if someone could help me with a problem I'm having.
My department is just one of many within my organization. My
organization has control over the network domain, but my department has
a couple of web servers of our own that are part of my organization's
domain. I am trying to read LDAP information on my organization's
domain controller from a web application on one of my department's
servers. I have been told that anyone in the domain can retrieve the
LDAP information and on our applications that require authentication,
this is true. It's the applications that do not require authentication
that pose a problem. I must impersonate an account within the domain
in order to retrieve the information. This works flawlessly on our
applications that are still using .NET 1.1 and reside on the other of
my department's servers, but seems to be failing under .NET 2.0 on this
particular server. I receive the following error:
Configuration Error
Description: An error occurred during the processing of a configuration
file required to service this request. Please review the specific error
details below and modify your configuration file appropriately.
Parser Error Message: Error reading configuration information from the
registry.
Source Error:
Line 41: <customErrors mode="Off"/>
Line 42:
Line 43: <identity impersonate="true"
Line 44:
userName="registry:HKLM\SOFTWARE\LibraryASPNetApps\Identity,userName"
Line 45:
password="registry:HKLM\SOFTWARE\LibraryASPNetApps\Identity,password"/>
I created the registry keys using aspnet_setreg following instructions
in Microsoft's KB Article 329290 using a valid user account on the
domain. The Identity key has the following permissions:
Administrators: F
<servername>\ASPNET: R
CREATOR OWNER: None, and I can't set them; after setting it, it just
defaults back to none.
SYSTEM: F
The ASP.NET worker process also has write permissions on the Temporary
ASP.NET Files folder (for version 2.0, as that's what the application
is written in) and read access on the application's directory.
On a whim of advice from another posting on the groups, I gave Everyone
read permission for the Identity registry key, but that availed
nothing. At one point, I restarted our server but all that seemed to
happen was that the Identity registry key had its permissions reset.
Both of our servers are running Windows 2000 with Service Pack 4 and
IIS 5.0. Both of our servers have .NET Framework 2.0 installed, even
though most of our applications on the first server are still using
..NET 1.1. Aside from .NET version differences and the servers the
applications are residing on, I can find no differences between the 2.0
application that's causing the problem and the 1.1 applications that do
not. Everything else is the same: the operating system, IIS, the
account being impersonated, the permissions on the folders and registry
keys. Both servers have the most recent critical updates installed.
Would anyone here happen to know the cause of this problem or perhaps
the solution to it? My guess is that there is something exceptionally
simple that I'm overlooking.
Thank you.