I have the same code base used on 2 different sites hosted on the same server (IIS 7.5).
For some reason, when I check the Identity.AuthenticationType property on the code behind of an http handler I see NTLM for 1 site and Negotiate for the other. This is causing some problems and I need both of them to use NTLM.
Could you help me to figure out why this difference? So far I see both IIS sites are configured on the same way but of course there is at least 1 difference that I couldn't detect.
Thanks!
EDIT
I've used this link that provides instructions to remove "Negotiate" provider from IIS. It didn't work for me. I executed
appcmd.exe set config "Contoso" -section:system.webServer/security/authentication/windowsAuthentication /-"providers.[value='Negotiate']" /commit:apphost
Maybe I did something wrong, but it didn't help. I still see "Negotiate" as AuthenticationType
The problem I have is that I'm setting on web.config impersonation credentials but it's not using them. Instead of using credentials I provide, it uses the anonymous user.
And something weird is that windowsAuthentication is disabled. I thought "Negotiate" was only used by windowsAuthentication.
Negotiate will choose either Ntlm or Kerberos authentication internally.
If the site says Ntlm only Ntlm authentication would be choosen.
Please check both the site and make the authentication has same.
Windows Authentication will need to be enabled and Anonymous Authentication disabled to get the logged in user (I am assuming here that you are on authenticating on a domain and don't want to fall back to an anonymous user if the user doesn't have authorised credentials using windows auth).
In IIS7.5, to see the providers being used, click on Authentication, right-click on Windows Authentication and select providers. You will have a list of enabled providers, the order is important. Try making sure they are both the same (in your case have NTLM at the top of the list).
Sorry for the late response!
First thing to check is if there is a difference between the authentication types that are enabled for each site.
By default only anonymous is enabled.
If your version of Internet Information Server (IIS) is 7.0 take a look in the <%SystemDrive%>/Windows/System32/inetsrv/config/ApplicationHost.config file for a section like this:
<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="false">
<providers>
<add value="Negotiate" />
<add value="NTLM" />
</providers>
</windowsAuthentication>
</authentication>
</security>
</system.webServer>
The documentation for Windows Authentication Providers may provide more detail.
The Remove NEGOTIATE from WindowsAuthentication in IIS question provides instructions for removing Negotiate which I found helpful when I was trying to re-enable Negotiate.
Related
I'm using Forms Authentication in my current ASP.NET Web Application (not MVC) and my IIS 6 server is configured with the following options:
in the [directory security tab] -> [Authentication Methods] I have:
the anonymous access Enabled
Integrated windows authentication Enabled
Do the above options prevent Forms Authentication from working properly? In other words, what is the proper IIS 6 configuration for Forms Authentication?
EDIT
I just made test with the two options above enabled and the Forms Authentication session expired and redirected me to the login page, but all the answers so far advise that [Integrated windows authentication] should be off!
Here is a check list for using ASP.NET Forms Authentication on IIS6
Configure IIS:
In IIS, Site Properties -> Directory Security -> Authentication and Access Control
Enable Anonymous Access
Disable all Authenticated access methods
Configure Forms Authentication:
Configure Forms Authentication in your site's web.config:
<authentication mode="Forms">
<forms name="MySite"
path="/"
loginUrl="~/logon.aspx"
protection="All"
timeout="30"
slidingExpiration="true" />
</authentication>
Your name and loginUrl may vary. The slidigExpiration attribute is used to keep extending the forms authentication cookie lifetime rather than just kicking the user off of the site after the timeout has expired. The timeout value is in minutes.
Configure Session Timeout:
You need to configure your session state timeout to be longer than your Forms Authentication ticket expiry. If you don't do this then an idle session can time out the session but leave the user logged in. Code that expects Session values to be present will throw exceptions because they are gone even though they are still authenticated. The timeout value is also in minutes.
<sessionState mode="InProc" timeout="40" />
Because forms authentication does not rely on IIS authentication, you should configure anonymous access for your application in IIS if you intend to use forms authentication in your ASP.NET application.
See here http://msdn.microsoft.com/en-us/library/ff647070.aspx for more information.
The anonymous access should be enabled, I don't think integrated windows authentication makes a difference but if you're not going to need it then it's best to turn it off. The important thing to remember is to make sure it's turned on in web.config:
<authentication mode="Forms" />
Here's a basic tutorial that might be useful:
Overview of Forms Authentication
Anonymous access -> checked
All other option on the security tab -> unchecked
Note, forms authentication is done by .NET - not by IIS. Also, Windows Authentication MUST be off as well.
Rather technical explanaitions by MS.
I have a WCF service I want to use to access a SQL db (via Linq2SQL at the moment), but the trusted security in a live IIS environment doesn't seem to use the right credentials - I've tried to follow the related posts here, but can't seem to quite get it. I'd be really grateful if someone could spot my mistake ...
in the Endpoint config, I've set it up to use BasicHttpBinding, with the following configuration
<basicHttpBinding>
<binding name="authHttpBinding">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows"/>
</security>
</binding>
</basicHttpBinding>
I've set the system.web settings to:
<authentication mode="Windows" />
<identity impersonate="true" />
on the IIS server, I've added a new AppPool, set the Identity to ApplicationPoolIdentity and ManagedPipeLine to Integrated. On the actual web application, set to my new AppPool, I've set Windows Authentication to "Enabled", and tried ASP.Net Impersonation on both enabled and disabled
When I try calling the WCF service, it runs, but when it makes an actual call to a stored proc via Linq2SQL (to a database on a remote server using Trusted Security), I get the following error:
Login failed for user 'domain\ machinename$' - the machine name with a dollar sign at the end
which looks to me a lot like I've failed to delegate the correct identity (I can access the actual database fine through Management Studio.
Accessing your db shouldn't have anything to do with your WCF security settings. I would remove security settings from your binding config and also the impersonation setting in the system.web. You shouldn't need either of these.
Check your connection string settings in your config and make sure that if you are using Windows integrated security to access your db that you have the correct permissions on your database. IIS will attempt to connect to your database using the identity configured in the apppool so you need to make sure that account has access. If you have a named user, then make sure your credentials are set correctly. ConnectionStrings.com has various examples of how to set this correctly.
HTH.
Steve
Yes it is possible. In this case, you need to make sure your security setting is set to Windows (which is the default) and make sure your services are primed for impersonation. You can do this programmatically or declaratively.
You need to instruct WCF to allow impersonation for the service/method you want by setting the appropriate ImpersonationOption attribute to either required or allowed.
[OperationBehavior(Impersonation=ImpersonationOption.Allowed)]
Because you are accessing resources across the network, you need top make sure the impersonation level is set to delegate, not impersonate, unless the resources you're accessing are local. This is set at the client endpoint behaviour level.
<clientCredentials>
<windows allowedImpersonationLevel="[Impersonation or Delegate]"/>
</clientCredentials>
Environment is IIS 7 integrated pipeline, ASP.NET 4.0. I have a .aspx page configured without anonymous authentication and with windows authentication:
<location path="auth/windows">
<system.webServer>
<security>
<authentication>
<anonymousAuthentication enabled="false" />
<windowsAuthentication enabled="true" />
</authentication>
</security>
</system.webServer>
</location>
When I request the page, a normal Windows auth (NTLM/Negotiate) challenge response happens, and ultimately the page is returned.
I have an HttpModule in which I handle the PostAuthorize event. As expected, this event is only raised once the challenge-response authentication has succeeded and access to the page has been authorized.
However, the Request.IsAuthenticated property is false; and HttpContext.Current.User.Identity reflects an unauthenticated user (.Name returns the empty string). Interestingly, Request.ServerVariables["LOGON_USER"] does return the value of the authenticated Windows user.
I'd have thought that once the user was authenticated (and authorized, for that matter), the request would reflect being authenticated; and the User / Identity for the request would have been properly set.
Any thoughts on why this is not the case?
Thanks,
Donnie
It turns out that the native handling of Windows authentication works when you have Forms authentication enabled in Web.config. But the managed part of Windows authentication - associating the authenticated Windows user with an IIdentity-derived object representing that user - only happens if Windows authentication is enabled in Web.config. Looks like I'll have to rely on the Request.ServerVariables["LOGON_USER"] value.
windows Authentication is enabled in IIS and authentication mode set to windows in my web.config file.
<authentication mode="Windows">
</authentication>
My site is asking for credentials and it's working fine. but when check using
HttpContext.User.Identity.Name
is empty string
Or
HttpContext.User.Identity.IsAuthenticated is false;
I used Request.ServerVariables["LOGON_USER"].Tostring(); to get logged in user credentials.
It worked for me, Thanks for Posting soccerdad.
What settings do I need to accomplish the following?
IIS6 Server sits on Domain1
Users access from Domain2, eg Domain2\User
I want
WindowsIdentity ident = WindowsIdentity.GetCurrent();
to return Domain2\User not Domain1\IUSR_SERVER
Current Settings
I have the authentication in IIS configured as "Integrated Windows Authentication" checked, the rest clear, this works fine when on the same server as the IIS server.
In web.config:
<authentication mode="Windows"/>
<identity impersonate="true"/>
Cross domain these settings prompts for a login.
The two domains need to have a trust relationship created (if they are part of the same forest that should already exist), then there may be a need to configure some delegation (talking AD stuff here not .NET).
The authentication between client and server must use negotiate and kerberos, which in turn means clocks need to be with in 5 minutes of each other, again this shouldn't be a problem when both domains belong to the same forest.
How can an application, running on a production server, access the login username of the machine that a user is accessing an application from? For example, I am currently logged into my machine on the INTRA corporate intranet. My username will be INTRA\Username.
I have added specific usernames to a database and wish to check this intranet username against the database to restrict access to an application and leverage the username across the application.
Currently, I am using the following code to access the username:
Private username As String = Thread.CurrentPrincipal.Identity.Name
This is working great on localhost, but when authenticating against the database on a development server, I'm getting the following error:
Login failed for user 'NT
AUTHORITY\ANONYMOUS LOGON'.
Is this an incorrect approach? Is this even possible, or is it too much of a security issue? This application will be an internal intranet application running in an IE shop. Relevant pieces of web.config that already exist include:
<identity impersonate="true"/>
<authentication mode="Windows"/>
<authorization>
<deny users="?"/>
</authorization>
<connectionStrings>
<add name="CONNSTR" connectionString="Initial Catalog=DATANAME;Data Source=servername;Integrated Security=True;" providerName="System.Data.SqlClient"/>
</connectionStrings>
When setting up your web application on the server, you need to go into the Document Security section (the name of it changes depending on what version of IIS your server is running, but it's something like that), turn off anonymous authentication, and turn on Windows authentication. That tells the server to request windows login authentication from the browser. (Perhaps someone who knows web.config files better than I [which is nearly anyone] can edit this to point to the relevant bit; I don't think it's impersonate but if I knew, I'd say. I've so far only done this via the UI.)
in your example, you are locating the username that your webserver is running under. What you are after is the username of the user accessing the page.
Try something like this:
How To: Use Windows Authentication in ASP.NET 2.0
If setting the directory security to Windows Authentication is not working, change it to Basic Authentication. You'll also need to specify the domain name to authenticate against. This was the only way we could get the security to propagate through from the IIS layer to the DB. Unfortunately this causes the username and password to be sent through clear text. Its not the best solution, but since things were on the Intranet, it worked while we work on updating our login procedure.