I have written a WCF Service and need to host it, I can either host in IIS or Self-Host and I would like to use Windows Authentication by setting the bindings in the web.config file below:
<bindings>
<netHttpBinding>
<binding>
<security mode="Transport">
<transport clientCredentialType="Windows" />
</security>
</binding>
</netHttpBinding>
</bindings>
I am trying to understand what IIS is doing in terms of authentication and passing it on to the web application, specifically:
If I host in IIS, do I need to enable Windows Authentication for the
service site in IIS administration settings?
If so, why can the service not perform Windows Authentication simply
from the config file just like self host - why does IIS need to get involved? Self host
doesn't need anything other than the web.config file.
Is there a way in IIS for the application (ASP MVC, WCF etc) to
handle authentication types (Forms, Windows Authentication, Basic)
without enabling them (reason being if the site is not configured
correctly it could be a security risk, if the code handles
authentication then the security intent becomes explicit)?
If I host in IIS, do I need to enable Windows Authentication for the service site in IIS administration settings?
Yes.
If so, why can the service not perform Windows Authentication simply from the config file just like self host - why does IIS need to get involved? Self host doesn't need anything other than the web.config file.
Because Windows Authentication is a feature. When it is installed, you can enable or disable this feature for particular site or service. Note, that Windows Authentication is not supported Home or Starter editions of Windows Vista® and Windows® 7.
IIS WCF host implementation is completely different from SelfHost implementation. And Windows Authentication feature is required to get things like setting security context identity (ServiceSecurityContext.Current.WindowsIdentity) or impersonating the caller (http://msdn.microsoft.com/en-us/library/ms788971(v=vs.110).aspx) to work on IIS WCF host.
Is there a way in IIS for the application (ASP MVC, WCF etc) to handle authentication types (Forms, Windows Authentication, Basic) without enabling them (reason being if the site is not configured correctly it could be a security risk, if the code handles authentication then the security intent becomes explicit)?
You must install feature before using it. There is no security risk because it just wouldn't work. For instance, if you configure your site or a service to use windows authentication, anonymous users won't get access to this site or service.
Check out this.
This gives all the details, follow this and i am sure you will get what you want.
Related
I'm currently working on an intranet portal for my company, it will remain internal, only users with accounts on our domain will have access to it. At the moment, I use forms authentication method, and authenticate users against the Active Directory domain with System.DirectoryServices. I also interrogate the AD with System.DirectoryServices.AccountManagement to manage access rights depending on the Active Directory groups the user belongs to and I store some data in user sessions and everything works fine.
I've been asked to study whether Single Sign-On could be implemented in our context, all our users work in RDS without exceptions, so they always are in an authenticated session and the higher-ups would prefer not having to sign in at all. As far as rewritting the code to authentify and authorize users as explained here and here
I'm not too concerned.
I tried everything on a blank ASP.Net MVC5 project, to which I added an ADO.Net model with integrated security. My dev SQL Server is hosted on a remote server (not the dev desktop), the same server also hosts the dev IIS server. In production, both services will be on separate servers. This worked fine as long as I was debugging localy on my desktop, but once I published to the IIS server, I hit the first snag and couldn't get out of it.
When I changed settings in the IIS app to disable anonymous and enable windows authentication, IIS automatically changed <authentication mode="Forms" /> to <authentication mode="Windows" /> in the web.config file (as suggested here), but I couldn't make it work with Integrated Security=True or Integrated Security=SSPI, I get an error page saying [SqlException (0x80131904): Login failed for user 'DOMAIN\MACHINE$'.].
The connection string reads like: <add name="ASPNetProjectEntities" connectionString="metadata=res://*/Models.ModelASPNetProject.csdl|res://*/Models.ModelASPNetProject.ssdl|res://*/Models.ModelASPNetProject.msl;provider=System.Data.SqlClient;provider connection string="data source=MACHINE;initial catalog=DATABASE;persist security info=True;Integrated Security=SSPI;MultipleActiveResultSets=True;App=EntityFramework"" providerName="System.Data.EntityClient" />
I tried to add the machine account DOMAIN\MACHINE$ to SQL logins and grant it rights to the database, but no dice. I tried to authorize delegation in the server AD account and activate identity impersonation, but that didn't work either. I can only make it work on the remote IIS server if I put a SQL user/pass in the connection string.
So I'm at loss what could be missing here to make it work with Integrated Security. Or will I have to put SQL credentials in the connection string and encrypt it on IIS?
You're confusing Integrated Security with the authentication mechanism of your website. If you use Integrated Security, the connection used from your web app to SQL Server will use the account that the application pool your web app is running as is using. To use Integrated Security, have a service account created in AD, set your app pool to run as that account, and grant the necessary permissions to that service account in SQL Server.
Note that whether you're using forms auth or integrated security isn't relevant to how the web app connects to SQL Server, unless you're using impersonation, which you should never use.
I have written WebApplication using the latest ASP.Net Core. We are successfully hosting the application using the HttpPlatformHandler and IIS 8.5 using Anonymous Authentication. We are required to use Kerberos Authentication and required to use Kerberos Constrained Delegation.
Our Operations Administrator has setup all the required SPN's. We are using a service account, and all SPN's appear to be registered correctly. We have a number of other applications (SSRS SharePoint etc) with similar setup's
In IIS I have completed the following steps:
Created a New AppPool that is "No Managed Code" and "Integrated Pipeline"
We are using the service account under "Identity"
Created a New Web Application
Windows Authentication "Enabled" With Negotiate as the Primary provder
Anonymous Authentication "Disabled"
system.webServer/security/authentication/windowsAuthentication "useAppPoolCredentials = True" and "useKernelMode = False"
System.WebServer Security Authentication Windows Authentication Screen Capture
I have also ensured that under the HttpPlatform config forwardWindowsAuth token s set to True
HttpPlatform IIS Screen Capture
When I perform an HttpGet from the WebApi, My application throws an authentication error that the "service account" cannot login to the server.
This seemed very strange, so I am now running a fiddler trace and found that before the authentication page is rendered I get 3 401 errors.
The next following results show that the WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply.
I was experiencing the exact same behavior - IIS settings & web.config changes were making no difference.
In my case, I just needed to restart the server, funny enough. Check to see if NTLM is working first, if so then this might be your issue (I'm guessing this is SPN related - I had not restarted the server after the SPNs were created).
All,
I am using the ASP.Net MVC 4 application.
I have enabled Windows Authentication.
Till now it is working fine.
Now I enhanced the application to connect to TFS via its API.
For this, I need to use the windows authentication credentials.
I have tried using
ICredentialsProvider credential = new UICredentialsProvider();
TfsTeamProjectCollection teamProjectCollection = new TfsTeamProjectCollection(collectionUri, credential);
This works great in the development environment. But when I host the application in IIS 8.5, it is not working at all under "Application Pool Identity" and "Network Service" account.
I tried with Local System and specific user in identity of application pool, it is working.
But I need this to work based on the windows credential (Active directory).
Can anyone suggest a solution?
You can deploy your web application on the TFS App Tier and configuring its app pool to run as the same identity as the TFS web services, and enable ASP.NET impersonation. Check this case: ASP.NET MVC3 Windows Authentication Pass Through to TFS
You are likely hitting a Kerberos double hope issue.
You have two options to resolve it:
Host your mvc web app on the same server as tfs
Configure Active Directory to allow your servers identity to delegate the logged in user credentials to another service.
#1 is easy but #2 will require a bunch of work for your Active Directory domain administrators.
https://support.microsoft.com/en-us/kb/810572
You will need:
At least one Service Principal Name (SPN) configured for your server's account (either a dedicated domain\svc_myaccout or the domain\servername$ account for Network Service).
The account you use needs to be enabled to allow delegation in AD
The server that hosts your application needs to be enabled for delegation
This is not 101 and in my experience, having done this a bunch in enterprise and small business, that most Domain Administrators don't know how Kerberos delegation works, or how to configure it.
You will need to learn how and make explicit requests that they can action. Like "run 'setspn myapp.mydomain.com domain\myserviceaccount'".
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>
We are developing an intranet web application on .NET 2.0 platform.
The application is using Integrated Windows Authentication for Single Sign On. The users are authorized to use diffent modules according to the Active Directory Groups they are in.
Up to the point where authentication and authorization is accomplished everything works fine. But the problem starts when application tries to connect to the database on MSSQL Server.
According to the security policies of our customer, no database user or password data should be kept in connection strings or in registry even if encrypted. So we are forced to use Integrated Security=SSPI in the connection string.
The Application Pool on IIS is configured by them with the Identity User who has access to the database.
When we deactivate Windows Integrated Authentication, we connect to the db with the Application Pool's Identity User. But when Integrated Authentication is on, the application is trying to connect to the database with logon user credentials.
We tried every combination of Integrated Authentication, with or without impersonation, to solve the problem.
Is there any way to solve this conflict?
Normally the way you are doing it should work. Do you have Kerberos with delegation enabled?
Maybe this helps:
How to: Access SQL Server Using Windows Integrated Security
http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx
Edit: if both SQL and IIS are on the same machine you need to turn off impersonate:
<authentication mode="Windows" />
<identity impersonate="false" />