Last post Oct 16, 2013 11:13 PM by windump
Jan 24, 2010 12:27 PM|muellech|LINK
I have a problem running my ASP.NET application that accesses our local AD on a W2k8 server. The error I get is
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
[DirectoryServicesCOMException (0x8007203b): A local error has occurred.] System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) +557 System.DirectoryServices.DirectoryEntry.Bind() +44 System.DirectoryServices.DirectoryEntry.get_AdsObject() +42 System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) +98 Visus.Clearing.Core.ClearingUserList.AddUsersFromDirectoryGroup(String directoryPath, String user, String password, String groupName) in D:\Programmcode\visusclearing\Visus.Clearing.Core\ClearingUserList.cs:47 Visus.Clearing.Web.AddReceivable.Page_Load(Object sender, EventArgs e) in D:\Programmcode\visusclearing\visus-clearing\AddReceivable.aspx.cs:35 System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +25 System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +42 System.Web.UI.Control.OnLoad(EventArgs e) +132 System.Web.UI.Control.LoadRecursive() +66 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +2428
The weird thing about the problem is that the same binary works perfectly on my development machine (which is XP) - accessing the same server. If I run it on the server itself, the above mentioned error occurs. What I try to do is the following:
SearchResultCollection results = search.FindAll();
The problem is independent from the credentials I use. Eventually, I want to use a special service account for that (which already works on the remote XP machine), but on the W2k8 server, even a domain admin account does not work. I assume that the problem
originates from permission issues in the IIS configuration, but honestly, I do not know where to look for that. The application is running as network account in the default application pool. It is configured for using Windows authentication for the website
user. Furthermore, I have set impersonate to true and <trust level="Full" originUrl="" /> in the web.config.
Do you have any hints what changed in W2k8, which makes the application fail?
Thanks in advance,
asp net 2.0
active Directory credentials
LDAP authentication AD
Jan 25, 2010 09:08 AM|qwe123kids|LINK
Try Giving the Amin Rights to IIS User
Jan 26, 2010 03:45 AM|SecMaker|LINK
There're two ways of doing this.
- Set <identity impersonate=false> in web.config and then set your webserver (i.e. $WEBSERVER) to have access rights to the domain on the domain controller.
- Set <identity impersonate=true> in web.config and then set "trust this computer for delegation" on the webserver in the "Active Directory - Users and Computers" on the domain controller, in this case the current user will do the action instead of the webserver
like the example above this one.
Jan 26, 2010 05:06 AM|muellech|LINK
Thank you for your suggestions. I tried that without success, so let me add some further information: I am currently working on a test server/domain. Therefore, the web server is running on the DC. As I understand - this is my first ASP.NET app that I actually
want to deploy to a server - IIS is running as local system account (inetinfo.exe, right?). Furthermore, setting impersonate=true will cause my app to run as the user that authenticated in the login form, i. e. all restrictions regarding permissions that apply
to the user will also apply to my application, is that correct? Having that information, you can hopefully answer these questions:
- I assume it is not a good idea running IIS on the DC, but for testing purposes, it is possible at all? Or am I trying to configure something that cannot work?
- My IIS was originally installed with the certificate authority, i. e. I did not really configure it, but just ran a default installation and the certsrv works. Should I use another account than the local system? If so, where would I change it (i. e. somewhere
else than in services.msc)?
- Is the relevant user for me to configure the user of the IIS process of the user of the application pool that I use for my app? I am using the DefaultAppPool with the network service account.
- Even if the configuration would work by giving the web server administrative privileges, I would not want to do that. So I hope that there is a "more official" solution which avoids that? I mean, it cannot be the solution intended by Microsoft to run all
stuff as admin?
Regarding your suggestions: I tried both, impersonate=true and false and this did not change anything. I would, btw., prefer impersonate=true for my application. As the test domain currently consists of two machines (redundant DCs), I also tried to connect
to AD on the other server (trust for delegation is set in both directions). The effect is the same.
What I do not understand is the following: Why can I access AD from a dev machine, which is not part of the domain and which connects via VPN to the subnet the AD server is in? And why can the IIS on the local machine not do that? I have btw. tried to do
the connection from a dev machine running Windows 7 and this does not work either. It only works from Windows XP. Could the problem be related to the OS settings rather than to the web server settings?
Jan 26, 2010 11:24 AM|SecMaker|LINK
Okay, try using this one:
// Your action to Active Directory.
You can successfully access the AD from your development machine because Visual Studio has it's own webserver with full trust to the domain controller, that why.
Jan 26, 2010 12:06 PM|muellech|LINK
That does it, thanks.
Just in case s.o. else is interested: In my case, HostingEnvironment.Impersonate only worked when not providing credentials for the DirectoryEntry ctor, i. e. just new DirectoryEntry(somePath).
Btw, the development machine "trick" does not work any more on Windows 7.
Jan 26, 2010 12:53 PM|SecMaker|LINK
What do you mean with "only worked when not providing credentials"?
Jan 27, 2010 02:49 AM|muellech|LINK
You can provide a user name and a password for DirectoryEntry in the ctor. If you do that, it does not work. If you leave it blank (ctor with only one parameter), it works.
Oct 16, 2013 11:13 PM|windump|LINK
I also had this issue and in a production enviroment. The error logged was, "A local error has occured".
This code was attempting to change password of AD users using a service account that had password change priviledge delegated in AD.
(the fact that we are using a delegated service account for this was a whole other solution we had to discover after realizing users with Force Change, or Expired Passwords are unable to change the password with their own user principal, oh well, kinda makes
In any case - the idea behind the fix described by muellech was similar, works in DEV, not in PROD - so I wrapped my AD Actions in the using() statement suggested by SecMaker
Unfortunately, this had no affect...
I was able to resolve the issue by changing the PROD service account username string from a DN format string to a "domain\username" string. Using this username format to establish the PrincipalContext with the delegated service account WORKED! I left the
using() in there... maybe they are doing something?
I do not know why username format matters? FUN STUFF!