Please assume there are two servers:
Server-A: Windows 2012, IIS8, ASP.NET 4.5
Server-B: Windows 2012, IIS8, ASP.NET 4.5, Active Directory
The two servers are owned and managed by different organisations, and Active Directory on Server-B has no remit nor involvement with Server-A.
Based on this, is it possible to use Windows Authentication on Server-A to authenticate a user accessing Server-B? I would assume not, but obviously aren't completely sure.
I have managed to write code on Server-B to read attributes (e.g. employeeID) for the currently authenticated user, but need to pass them to Server-A for processing (this might eventually act as a single-sign-on mechanism). Unless there are better ways of course which you might want to share??
I achieved this in the following manner. There may be better methods but this one is as secure as I can get it:
User logs into Server B via Active Directory
User access an 'authentication' page hosted on Server B
The page looks up their AD employeeID and encrypts it in a cookie
The user is transfer to the web app on Server A
Web app on Server A sees the encrypted cookie and decrypts it, checking that the previous page was located on the customers IP address
Web app logs the user in using the employeeID from the encrypted cookie
An interface has been created on Server B so that when a employeeID value gets updated, this change is mirrored onto Server A so that the employeeID values stay synchronised.
You can use Forms authentication and AD authorization provider.
http://msdn.microsoft.com/en-us/library/ff650308.aspx
Related
I have two servers, let's say they are APPSVR (ASP.NET) and DBSVR (SQL Server). Currently, the application running smoothly with database connection using SQL Server authentication with User Id and Password.
In the future, it must be changed with Windows Authentication Integrated Security=True. I have tried to change this but can't worked (DB connection failure).
We have domain controller also and both server in the same domain. I am not sure which one that must be configured in our environment (Domain/SQL Server/IIS Manager). What's the right procedure to do this?
Is your asp.net application already running with domain user authentication?
Do you need per user login for SQL server because you set up the
access right on domain user rather than create your own access right
system on your asp.net application?
Why i am asking you this? Because You need to consider the differences between web application and desktop application. In web application, the web server contact the sql server not the user pc.
So this complicate the setup if you want the web server to use the windows authentication to login to sql server then you need to set up the web server to somehow masquerade as the domain users. You also need to consider the scenario if user are accessing the web application from the internet.
I suggest using strong application only password for sql server connection using local user rather than domain Users. For access right you can simply create a new table to store domain user login id and their access right. This set up still allow login to web application using the domain Users but the database connection is not. The Advantage is you can minimize the access to simply few or even one user application only user you need to maintain in sql server rather than every domain Users that need to be registered on sql server if you use windows authentication.
If you still need the Windows Authentication set up than you can see the info here.
We recently had to change over to using Windows Auth instead of a SQL Account to access the DB from our ASP site. The trick is to have the application pool start up with the same domain account you use to access the SQL Server and then you can just change your connection string to use Integrated Security.
The process is shown here:
https://thycotic.force.com/support/s/article/Using-Windows-Authentication-to-access-SQL-Server-Secret-Server
We have a web application developed for use on the intranet of our client. There is no login page, hence there is no Forms authentication.
The application creates a number of records which have to be stored in the DB along with the name of the currrently logged in user. For this we have enabled windows authentication which works just fine in our development environment - and I assume, that when this is deployed on the envinronment of the client, it will work too.
The problem is, that when we host this on a test server, we need to give public IP access to the clients to check it out - and hence the virtual directory is configured to allow "anonymous access". This obviously causes a problem for us while storing the records since we are not able to capture the login name for the person who is creating/testing this application.
If we enable windows authentication for the test machine, then anyone who tries to access the app through the public IP gets a login window popup which we dont want.
Any ideas on how to capture the logged in user name for this scenario ?
Based on your design, user should log on a windows machine in your network the server is located. For that scenario, VPN would serve best and simulate real environment.
I'm currently implementing a cache mechanisem for our site.
I want to use the SQL Cache dependancy feature.
I am running the following command in management studio and it's not working.
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO "my_server_name\ASPNET"
The error I'm getting is:
Cannot find the user 'my_server_name\ASPNET', because it does not exist or you do not have permission.
I tried signing in with the admin of the specific database I'm setting the notification for, sa, and windows authentication with the machine administrator.
Also tried running management studio as administrator and still not joy.
Can someone please point me in the right direction.
Thank you!
First, it appears you are attempting to grant permissions to the account under which the site is running. In IIS 6 and IIS7 these are control by the account set on the Application Pool. That account used to be ASPNET but no longer by default. Instead, the default (starting with .NET 2.0 I believe) is NETWORK SERVICE. However, if you are using IIS 7, that has changed yet again. By default in IIS7 it uses something called the "ApplicationPoolIdentity" which is its own special credential created for each site. If SQL Server is on a different machine than the web server, you will run into another problem which is the credentials are all local to the machine.
My recommendation would be to do the following depending on your setup:
Both servers are on a domain and you want to use trusted connections:
Create a domain account and drop it into Domain Users.
On the web server, drop this account into the IIS_IUSRS group.
Go into the Application Pool for the site and change the account under which the site is running to this domain account. You will also want to ensure that this account has the proper NTFS permissions to the site files. If this site only writes to the database, you can given the account read-only access the folder(s) with the site files.
Ensure the connection string used by the site is formed to request a trusted connection. (See www.connectionstrings.com for the syntax)
On the database server execute your grant to this account:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO "domain name\MyIISAccount"
There may also be other Kerberos issues related to the fact that both servers on the domain and that might require creating a SPN (Service Principal Name).
Neither server is on a domain (i.e., both are member servers) and you want to use trusted connections:
Create a local account on both the web server and the database server with the same username and password. It is critical that they both have the same username and password. This technique involves using NTLM "pass-through" authentication which matches the hash created by the username and password to determine if the user is authenticated between the two desparate servers. On Windows 2008 R2, you may have to jump through a few local policy hoops to ensure that NTLM is enabled between the two servers.
Do steps #2 to #4 above with this account.
On the SQL Server, ensure that this local account has a Login and that this login maps to a User in the database. Then you would execute something like:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLServerMachineName\AccountUsedBySite'
You want to use SQL accounts instead of a trusted connection:
In this scenario, the connection string used by the site to connect to the database will include a username and password which map to a Login on the SQL Server database which maps to a User in the database (typically put in the db_owner role to make it dbo). This
Assuming the credentials are correct, you need only execute your grant against this user:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLUserAccountUsedBySite'
Both IIS and SQL Server are on the same machine and you want to use trusted connections
Create a local user account and drop it into the Users group.
Drop this account into the local IIS_IUSRS group.
Go into the Application Pool for the site and change the account under which the site is running to this local account. You will also want to ensure that this account has the proper NTFS permissions to the site files. If this site only writes to the database, you can given the account read-only access the folder(s) with the site files.
Ensure the connection string used by the site is formed to request a trusted connection. (See www.connectionstrings.com for the syntax)
In SQL Server, create a login for this account then create a user in the appropriate database for this account dropping it into the appropriate roles.
Now execute your grant to this account:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO 'SQLServerMachineName\MyIISAccount'
Try this:
GRANT SUBSCRIBE QUERY NOTIFICATIONS TO [my_server_name\ASPNET]
I have inherited a conventional three tier web app with ASP.net 2.0 for the UI, .Net web services (ASMX) in the middle tier and SQL Server 2005 for the DB. This is currently an intranet application with the only users being company employees. Currently the application uses Active Directory (AD) authentication.
At the login screen, the user is presented with username / password dialog. The middle tier makes a simple call to the AD to check the username / password. If ok, then a sessionId guid is generated and sent back to the UI. This sessionId is then passed on every subsequent call from the UI within the session. All methods in the middle tier first check the validity of the sessionID against a simple session table in SQL Server, before processing the request.
I now need to make the web services middle tier of the application available to a new UI that will be available to the public internet. I don't need to worry about authentication because that will be managed by the new UI. However, I don't want to leave the web services completely open without any security. I just want to be sure that the system calling the services has permission to do so. I don't want to burden the new UI with having to maintain the sessionIds currently used.
Any views on the best way to secure the services when being called from the new UI? I guess I could use x509 certificates but I've done this before so I'm not aware of any disadvantages (performance?) or how to go about the implementation.
The new UI has been developed used .Net 3.5. We can install .Net 3.5 on the middle tier so I guess we could benefit from using WCF?
I don't believe this is a problem that is suited for cryptography. It would be better to limit access to your web service using an IP restriction. If this data is being transfered over an insecure connection like the open internet, then you could use ssl to verify the client and server as well as keep the transmitted data safe. You could also use VPN which is probably the easiest to implement.
I am concerned with your session table. I believe this introduces a lag time for revoking user accounts. If this session doesn't have an expire time then it would make it impossible to revoke a user account. After a user has logged in how do you kick them off?
One solution is to have the ASMX web service query active directory for each request, if your AD server isn't under a heavy load then this should be fine. Keep in mind that AD is a very efferent database in its own right.
I have a fairly complex business application written in ASP.NET that is deployed on a hosted server. The site uses Forms Authentication, and there are about a dozen different roles defined. Employees and customers are both users of the application.
Now I have the requirement to develop a Windows Mobile client for the application that allows a very specialized set of tasks to be performed from a device, as opposed to a browser on a laptop. The client wants to increase productivity with this measure. Only employees will use this application.
I feel that it would make sense to re-use the security infrastructure that is already in place. The client does not need offline capability.
My thought is to deploy a set of web services to a folder of the existing site that only the new role "web service" has access to, and to use Forms Authentication (from a Windows Mobile 5/.Net 3.5 client).
I did see this question and I am aware of the limitations that Forms Authentication poses. Since security is not my primary motivator (I use SSL and can restrict access by IP address), but rather using existing user accounts and roles, my decision tree is somewhat different as well.
Can I do this, is it a good idea, and are there any code examples/references that you can point me to?
I ended up with a combination of things. First, forms authentication does not really work in this scenario, because of the redirects that you get when a users is not logged in or the credentials are incorrect.
Because I want to use the user accounts from the web app, I worked around this by just calling Membership.ValidateUser prior to processing each service call on the server.
A user is prompted for an id and password when logging on to the client. I store both values encrypted in the proxy class and pass them transparently with each call using a host header, so that the application does not have to bother with this once the user is logged in, i.e. the credentials were validated once by calling the Login() service method (which only calls Membership.ValidateUser).
I use the CryptoApi on both the server and the client side.
I understand that host headers are somewhat outdated for security applications, but since I use strong encryption AND SSL, it is perfectly adequate.