This is a real quick question, is it possible to allow Windows Authentication for an ASP.Net intranet site (on a test server) to authenticate against the production server user accounts? If so, how would I go about doing so.
If they are part of the same domain this is built in. If they are on separate domains, this would require a trust between the domains, and then this would be "built in" simply by prepending the domain name in front of the production user name. If they are on stand-alone machines, this gets very complicated with establishing trusts between the machines and allowing users from the "workgroup" enter. If your servers are managed by a server admin team (like most major companies), it's probable that there will be no trusts established between machines in a production domain and machines in a test domain. Many corporate security policies prohibit this interaction.
You would have to add something like this to web.config
<system.web>
...
<authentication mode="Windows"/>
...
</system.web>
and login as SYSTEM-NAME\username and password.
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.
Has anyone ever experienced the following situation in .net with forms authentication?
User logs into system.
User is allowed into the "default" page inside of the directory
controlled by forms authentication.
User attempts to click on another link also inside of the directory
controlled by forms authentication.
Application redirects them to the login page again as if they hadn't
already logged in.
It's an ASP.net 3.5 website application, running IIS7, hosted in a Server Farm with just 2 servers. Authentication is managed by cookies on the users system and server affinity is turned on...so "technically" they should arrive at one of the two servers and stay there.
Thanks for any help/insight.
If it's a server farm you're load balanced (I assume) so you have no idea what server you're going to end up on, when working in a farm with forms authentication you need to ensure that the encrypt / decrypt keys are the same or the cookie created on server A can not be read by server B. Here's an example of a machine key that can be added to the web config to ensure cookies can be read in the farm:
<machineKey decryption="AES" decryptionKey="3B9E54DB3BB7DC57FF7CFBD8570B7AA21CD71BF63C6A9B48,IsolateApps" validationKey="3A74D6A6BA4C0771232C24FEFF997337F8B9542C255F5EA8EF214918A320362528EDA984A5AA8D0C24FDF50A062718932293496572248668C30DC3FAE2BDA183,IsolateApps" />
code:
System.Security.Principal.WindowsImpersonationContext impersonationContext;
impersonationContext =
((System.Security.Principal.WindowsIdentity)User.Identity).Impersonate();
//access network resources.
impersonationContext.Undo();
web.config:
<authentication mode="Windows">
</authentication>
<identity impersonate="true"
userName="user"
password="password"></identity>
As clear from web.config file, the app runs in an impersonated mode. I need to impersonate temporarily on top of that to access a network resource. I do that as shown above.
This works fine on server if I browse to the website on the local IE installed on the server but when I access the app from my PC or any other PC, I get a access denied.
Btw, this is all within an enterprise domain environment. so IE in both cases is passing a valid authenticated token.
Any ideas what is going on. thanks.
You need to make sure the server will delegate the impersonated security contexts in your application to another server (the network resource you mentioned).
I'm pretty sure it works while you're logged onto your server because it is using the security context of you being logged in directly, and not the impersonated context that exists in the application.
I can't remember specifics on configuration but I do know it is referred to as delegation or "Kerberos Double Hop". "Constrained Delegation" is when you configure such that only one type of delegation is allowed. IE, your app is only allowed to delegate security contexts when talking to Active Directory (port xyz) on this other specific server - otherwise not.
See Understanding Kerberos Double Hop
See DelegConfig - it is helpful in configuring delegation.
Also see: TechNet Article
And: this other article
we have a system where they client wants integrated Windows authentication.
This is an ASP.NET 3.5 application, connecting to Sql Server 2005.
The web server is Server 2003 R2 SP2.
The db server is Server 2003 SP2 (not R2).
In the db server, I ran the following script
exec sp_grantlogin 'myDomain\myUserGroup'
USE myDbName
exec sp_grantdbaccess 'myDomain\myUserGroup'
I have 3 users in the Windows user group 'myDomain\myUserGroup' right now. All three users' accounts are marked as trusted for delegation. The web server account in ADs is marked trusted for delegation.
The web application is marked as using Windows authentication (all others turned off).
The web.config has the following lines:
<authentication mode="Windows" ></authentication>
<identity impersonate="true" />
<authorization>
<deny users="?"/>
</authorization>
Yet when i try to connect to the web application with a user which is in the user group, i get the error:
System.Data.SqlClient.SqlException:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
My connection string is being built from a Sql ConnectionStringBuilder constructed as such:
ConnectionStringBuilder.DataSource = "MYDBSERVER"
ConnectionStringBuilder.InitialCatalog = "MYDBCATALOG"
ConnectionStringBuilder.IntegratedSecurity = True
If i HARD CODE one of the allowed accounts to impersonate on the web.config <identity /> line it works. But if i take off the hard coded account and try to pass the identity from the client's machine. I get the error.
So it seems that i don't have something configured correctly for the multi-hop integrated login scenario, but i can't figure out what.
Thanks in advance!
The ASP machine has authenticated the user connecting to IIS via NTLM/Kerberos. The authentication is guaranteed by the domain controller that has asked the original user process (IE) to present a secret that guarantees his identity: his password he typed when he logged into the box. The authentication is actually not done by the processes involved, but by the Local Security Authority (LSA, aka. lsass.exe) on each machine involved. Because the LSA on the ASP machine knows that the authentication is OK, it will allow an impersonation of the remote user to access anything it has the rights to access under the control of the said LSA (in other words, everything on the local ASP machine).
As soon as the ASP process that impersonates the user makes another hop to a new machine, it has left the realm controlled by the LSA on the ASP machine. The LSA on the SQL machine has no reason to trust the LSA on the ASP machine. So it ask it to present a proof that it is who it claims it is (the impersonated user). The ASP machine unfortunately cannot present such a proof, since it does not has the user secret (its password).
The work around is something called 'constrained delegation'. Through constrained delegation the domain controller intervenes in the negotiation between the SQL's machine LSA and the ASP machine LSA and says 'the ASP machine is OK, I vouch for him'. So the SQL's machine LSA trust the authentication and authenticate the original, impersonated user.
The technical details how to set up constrained delegation are described in How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Note that this is true anytime a 'double hop' and impersonation is involved, no matter the type of resources involved (can be a SQL server, can be a file share, can be a new back end ASP service).
If you're using Windows authentication then Impersonation doesn't flow past the ASP.NET process itself. You have two options here - swap to Basic Authentication, where Identity flows or, if you're running on Win2003 or later, you can use Kerberos and some hackery to impersonate when you connect
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.