I'm trying to create a .net web page that uses UserPrinciple.Current to get details of the currently logged in user, and allow them to change their Active Directory password.
After a fair bit of head-bashing, I got it working (yay!). My only issue is that I want it working on our intranet site (http://intranet) but it only seems to work if I specify the fully qualified domain name (http://intranet.mydomain.co.uk).
Looking at this page (How to configure an ASP.NET application for a delegation scenario) the troubleshooting section at the bottom of the 'Summary' section seems to contain two conflicting pieces of advice:
3.For Kerberos to work correctly, you must use fully qualified domain names (FQDN) for all the communication.
5.If the Web server uses a fully qualified domain name, you must add the site is added to the list of intranet sites in Internet Explorer.
Note that item 5 starts with IF - suggesting that it doesn't HAVE to do so. But Item 3 states that a FQDN is necessary.
So the question is simple: can I set up delegation through IIS 7 without using a FQDN host name ?
You need both otherwise it won't work for a good reason and IE will fallback to NTLM. Jus a side-note, it is really pointless to write a webapp where a user can change his AD password. This should be done through the Windows change password dialog and not some third party tool.
Related
We are experiencing odd behavior with our web application. If I change the URL to uppercase, or parts of it, after authenticating with the app, I then have to re-authenticate. Here's an example:
https://host.domain.com/website/asp
If I copy and paste that URL into a new tab after authenticating it will automatically authenticate and bring me to the landing page. However if I paste this into a new tab, while another tab is already authenticated:
https://host.domain.com/webSITE/asp
I have to re-authenticate with the app. (or IIS, this I'm not sure about)
This poses a problem when objects are developed without case being a consideration and I would think this behavior wouldn't be desirable. I will be reaching out to the application vendor but I'm wondering if anyone has experienced such an issue with IIS 7.
Thanks,
Max
IIS is generally case insensitive. Where sensitivity comes into play is with integrating modules. Modules like rewrite can be case sensitive. You didn't specify, but is your IIS application using rewrite at all? Also, your vendor may have controllers that are doing case sensitivity checks. But my guess would be the actual browser to be the culprit. Browsers that base cookies on the URL path can make those cookies case-sensitive. See this link for more information on users that have reported the same problem.
I have been trying to implement a webDAV connection on an existing IIS ASP.NET web site. This issue surrounds permissions and connectivity when "Enable anonymous access" is unchecked and disabled.
I have tried every combination available. The server is w2k3 Web Edition, no AD, IIS6, so "Digest authentication for Windows domain servers" is not an option in the Authenticated Access section of Authentication Methods of the Virtual Directory I am sharing in the web site.
I have read about and tested the Registry Edit of the following key, \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlset\services\WebClient\Parameters\BasicAuthLevel
and change the value to 2
agianst each possible authentication method. It seems to disable connectivity more then helping.
I am trying to map a path to a virtual directory on the web server, a function of the webDAV protocol, works great if anonymous access is enabled, but obviously can not be for this project.
I would like to at least get the Windows Authentication to work and disbale Anonymous Access.
I have been testing this on both a development server and production server and the behavior is consistent. On a Win7 OS I can not get the Windows Authentication dialog box to appear.
A few tests on XP, the box appeared but would not authenticate, but this may have been related to other config issues.
I have also tested with Permissions to the Everyone group just to see if I can connect.
Any further suggestions would be appreciated.
UPDATE: I found this article that explains a portion of the problem and work around though not entirely fitting for the issue explained above.
http://support.microsoft.com/kb/943280/en-us
Try adding permissions for Network_services and the IIS User on that box. that has always gotten me over the permissions issues I have faced. You need to add these from within IIS as at least with IIS 7 it seems to over rule the permissions from windows explorer. Not sure if IIS 6 does the same but I just do it by default now.
UPDATE: I found this article that explains a portion of the problem and work around though not entirely fitting for the issue explained above. http://support.microsoft.com/kb/943280/en-us
I want to provide a means to open up Windows Explorer (or at least view the directory contents) via an internal webpage I've developed for our business. There are several machines which we share over the internal network. I've provided a text entry field for allow the user to enter the folder path they want to associate with a given row in a DB table and I can store that info off and create the file://///10.10.5.10/Recipes/Pie link to the Pie recipe folder on one of our shared machines.
The link renders correctly on the page and if I copy the link info and paste it into the address bar it will display a navigable page in FireFox or open Windows Explorer if using IE.
However, the link does nothing if you click on it directly on my page. I suspect this might have something to do with security and the brower, right? I've seen a SharePoint page in someone else's system that did work, but I'd guess that has to do with some differences between SharePoint and a webpage in a browser. The work-around of right-clicking the link and copy/pasting it into another tab will work and I might have to live with this, but I was wondering if anyone had any suggestions or ways to deal with this issue. Perhaps I'm just doing something wrong, but I'm pretty sure it's browser-security related.
It seems for me as a pure Internet Explorer setting issue.
First of all I would recommend you better use UNC or DNS names in the path to the server instead of the usage of IP addresses: use file://///myserver/Recipes/Pie or file://///myserver.mydomain.com/Recipes/Pie instead of file://///10.10.5.10/Recipes/Pie.
Second you should better include the file://///myserver, file://///myserver.mydomain.com or even file://///10.10.5.10/ to the "Local intranet" or at least to "Trusted sites" zone:
Then you should verify the setting of the Security Zone to which you map the url. Look at the "Miscellaneous" group for the "Display mixed contain":
If you would has "Prompt" setting you will see the warning:
at every attempt to open the link file://///myserver/Recipes/Pie
If you would has some problems I recommend you to reset the IE settings in "Advanced" tab:
Most likely it's a permission issue.
ASP.net runs under the ASP.net process account. Look for the ASPNET user and apply permissions to the folder for the user in question.
It definitely sounds like a security issue. Try one or both of the following:
Try using impersonation to impersonate a domain user with sufficient priveleges to access explorer on the client's machine
If this is a small intranet application, give the application full trust on the client
Here's a link to a class you can use for impersonation - see my answer:
Invoke or call C# console app from C# web service?
I am currently trying to migrate a legacy ASP application from Windows Server 2000 and IIS5 on to Windows Server 2008 and IIS7. The authentication for this application uses an ISAPI filter. Both the application and the ISAPI filter work in the new environment except for one problem. The application in question is set up to be the root application (as in you access it by going to http://hostname/application.asp). If I access it by the stated URL, it asks for my authentication details, the ISAPI filter gets passed the correct login details and then does its thing. Then I added a default document to IIS7 to point to application.asp. Now if I access the application by going to http://hostname, the ISAPI filter gets passed the wrong login details. The ISAPI filter implements this method:
DWORD CMyISAPIFilter::OnAuthentication(CHttpFilterContext* pCtxt, PHTTP_FILTER_AUTHENT pAuthent)
In it, the pAuthent object gets passed in by IIS when it calls the ISAPI filter and has the pszUser property which normally holds the value entered in the authentication dialog. In my case (when accessing the website by using the default document entry), the pszUser property holds the value of the Windows account that is running the application pool instead. Just to make things clear, the ISAPI filter gets passed the correct value if I type in the application.asp part.
I'm quite stumped at this problem and have no clue as to how to solve it. To make matters workse I can't really rebuild/modify the ISAPI filter and am quite the beginner when it comes to IIS administration.
I have also found that authentication works if IIS does not have the Default Document feature installed. Without this feature the default document does not work (naturally) but authentication does. It's only after I add the Default Document feature that authentication breaks.
Thanks for your help!
Sounds like the web site is configured to use integrated security on the root level. Make sure you remove the checkmark from the Integrated Windows Authentication checkbox in the Directory Security-Tab.
The Node "Web Sites" can be configured as well. So make sure you don't miss that one ;-)
EDIT: Damn i can't upload a picture. Would make it easier for you to find the setting.
I've been having trouble getting my ASP.NET application to automatically log users into the Intranet site I'm building. No matter the googling or the experimentation I applied, there is always a login box displayed by IE7.
I've got Windows authentication mode set in the Web.config, disabled anonymous access and configured the correct default domain in IIS, but it's still asking the user to log in and, more annoyingly, the user is required to provide the domain too (DOMAIN\auser), which is causing problems with non-technical visitors. Thank Zeus for password remembering functionality.
I'm not the network administrator so it's possible that something about Active Directory is set up incorrectly, or it could just be me missing something very simple. Please note that I don't want to impersonate the user, I just need to know that the IPrincipal.Name property matches that of a valid record in my user database, hence authenticating the user to my application.
To this end, it would be very useful to have a checklist of all configuration requirements for AD, ASP.NET and IIS to work together in this manner as a reference for debugging and hopefully reducing some user friction.
It sounds like you've covered all the server-side bases--maybe it's a client issue? I assume your users have integrated authentication enabled in IE7? (Tools -> Internet Options -> Advanced -> Security). This is enabled by default.
Also, is your site correctly recognized by IE7 as being in the Local Intranet zone? The IE7 default is to allow automatic logon only in that zone, so users would be prompted if IE thinks your site is on the internet. I believe using a hostname with a dot in it causes IE to place the site into the Internet zone.
Open Active Directory Users and Computers MMC snap in
Expand computers section from TreeView (left side)
Check if the computer is registered in your domain.
Also, you have to login with a domain account on that computer, otherwise that authentication box will be shown.
In IIS, enable annonymous access and allow the web.config to handle user authentication.