I'm working on a solution for my employer that grabs the currently logged in user's name using a WindowsIdentity method, and compares that to an Active Directory LDAP query to get the "Title" property.  If the title property matches a list of permitted titles in the code-behind, it grants them access, otherwise it redirects them.  My question is, the whole thing works beautifully in VS2005 on a VM development server, but when I deploy it to an IIS 6.0 server (VM or not) it fails during the LDAP query, giving all sorts of error messages including "Domain not available", or "Operations Error".  My associate and I even installed ADAM and I tried using this method of authentication, but got the same results.  My web.config is set as follows:

<authentication mode="Windows"/>
<identity impersonate="true"/>
<anonymousIdentification enabled = "false"/>

We've even tried changing the IIS Directory Security on the virtual directory for the website, both with anonymous enabled and disabled, even changing the anonymous account to a service account that has AD admin access, and still no luck.  I'm thinking there's something I missed between IIS 6.0 and ASP.NET 2.0, because we have .Net 1.1 web-based solutions that work fine on these very same servers!
Any ideas or suggestions?  Is there an industry best-practice or standard for using Windows authentication on specific web forms of a website that I missed?

Hi,

Could you please please provide the error message with stack trace. Also I would suggest you to take netmon trace which will help you to dig deep and try turning off the caspol and see if that helps or not.

Thanks

Rudra Roy

I suspect you have issu with trusted for delegation. Windows 2003 introduce contrained delagation. By default a a server or an account is not allow to access network ressouce on behalf unless authorized. I stronly recommand that you delegate a service account and not the machine account. Are you using kerberos or NTLM? Are you using Web services? Why? Because:

"Client credentials do not flow implicitly. The Web service consumer must set the credentials and authentication details on the proxy. To flow the security context of the client's Windows security context (either from an impersonating thread token or process token) to a Web service you can set the Credentials property of the Web service proxy to CredentialCache. DefaultCredentials as shown below. " http://msdn2.microsoft.com/en-us/library/aa302390.aspx

suggestion have a look at the following article:

I tried some of the methods described above with no success.  I followed the steps in http://forums.asp.net/p/897609/971665.aspx#971665, and now it forces a login on EVERY intranet website, not just my project site.  I'm in the process of figuring out what I did to cause that one, hoping it's just our filter and not me...

Here's the error it gives when trying to hit AD to pull the LDAP query.  It fails on line 131 below:

Server Error in '/ptm' Application.
--------------------------------------------------------------------------------

The specified domain either does not exist or could not be contacted.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Runtime.InteropServices.COMException: The specified domain either does not exist or could not be contacted.

Source Error:

Line 129:        mySearcher.Filter = ("anr=" + userid);
Line 130:        mySearcher.PropertiesToLoad.Add("Title");
Line 131:        SearchResult result = mySearcher.FindOne();
Line 132:        DirectoryEntry de = result.GetDirectoryEntry();
Line 133:        membership = (string)de.Properties["Title"].Value;

Stack Trace:

[COMException (0x8007054b): The specified domain either does not exist or could not be contacted.
]
   System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail) +610
   System.DirectoryServices.DirectoryEntry.Bind() +36
   System.DirectoryServices.DirectoryEntry.get_AdsObject() +31
   System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne) +73
   System.DirectoryServices.DirectorySearcher.FindOne() +42
   _Default.GetUserMember(String userid) in c:\IT Development\ptm\table_management.aspx.cs:131
   _Default.Page_Load(Object sender, EventArgs e) in c:\IT Development\ptm\table_management.aspx.cs:50
   System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) +15
   System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) +34
   System.Web.UI.Control.OnLoad(EventArgs e) +99
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1061

This has to be something simple I'm doing wrong, it can't be this difficult for an already authenticated user to be granted access to a specific page in a website based on values associated with their AD account.

which scenario did do implement? did you delagate aspnet or use a domain account for your applicatin pool? Are you running with network service in the app pool? To see your security context, try the following code:

 WindowsIdentity id = WindowsIdentity.GetCurrent();
        Response.Write("<b>Windows Identity Check</b><br>");
        Response.Write("Name: " + id.Name + " type: " + id.AuthenticationType + "<br>");

Also enable auditing  in windows and look in the event viewer security log you will see who is logging in.

 Administrative tools/local security policy/Local Policies/audit policy/audit logon event for failure and success

Here's what I tried just this morning...

• Disabled anonymous access in IIS, and added <authentication mode="Windows"/> and <identity impersonate="true"/> to web.config.  --no good (When trying to view the page on the same server as IIS, it prompts you endlessly without granting access.  When trying to view the page outside of the IIS server, it throws a generic page error.)
• Added a service account that is known to have access to AD to the local IIS_WPG security group.  Changed Group Policy on the local server to include the account in the "Adjust memory quotas for a process", "logon as a service" and "Replace a process level token" groups.  Also added the aspnet and IIS_WPG groups with RWE access to the website directory.  --no good.  Throws the "Domain cannot be reached" error listed above.
• Added my personal credentials (as a test) to the DirectoryServices.DirectoryEntry call like this:  System.DirectoryServices.DirectoryEntry entry = new System.DirectoryServices.DirectoryEntry("LDAP://DC=<domain>,DC=<com>","<username>","<password>"); --no good, still says cannot be reached.

The security context shows <servername>\<anonymousUserAccountFromIIS>...type = "NTLM"

Windows Security log in Event Viewer shows NT AUTHORITY\SYSTEM passing through.  Now, when I set <anonymousIdentification enabled="false"/> in web.config, it went away, but reflected the current logged in user's account on the server, so when I was logged in other users would actually be impersonated as me.  If no one was logged on it would fail.

I think I found a solution.  It seems like I was "over-engineering" my authentication.  Here's what I did:

• Disabled anonymous authentication in IIS for the website
• Added the <authentication mode="Windows"/> and <identity impersonate="true"/> elements to web.config
• Added the following method to the code-behind for any page needing security:

Works like a champ.  Thanks to everyone for their feedback!  I learned quite a bit today about authentication, AD, NT logins, etc.  It's a good day when you can learn something new!