I've noticed that it is possible SQL Server 2005/2008 to authenticate replication accounts using certificates. Is it possible to authenticate .NET SqlConnection in the same manor?
Ideally, I'd like to do away with password authentication completely and have the aspnet user connect using a certificate stored against its account.
Is this possible, and if so, how can this be done?
The only way to authenticate a TDS protocol connection (ie. a user connection) is using Windows authentication (NTLM/Kerberos) or SQL Authentication (user/password). Is not possible to authenticate TDS connections using certificates. Only Database Mirroring and Service Broker connections can authenticate using certificates.
What you probably noticed is the HTTPS authentication between IIS and a client that occurs in Web Based Replication. That is indeed certificate based authentication, but occurs between the client and IIS and SQL Server is not involve din any way in it.
You can configure ASP.NET to use client side certificates, see this KB article.
But the ASP.NET server does not have access to your client's certificate. So the ASP.NET server cannot authenticate to SQL Server with a certificate.
Related
I am currently maintaining web applications available from a secure network. My users connect to the network within a VPN connection using L2TP/IPSec, to which they authenticate using their user id and password. When they access the web application, they also have to authenticate again with the same user id and password.
Since they have authenticated once to the VPN already, is it possible for the application to verify their authentication status and get their identity from the VPN?
Thank you!
It really depends on your VPN server and the capabilities of your web app. If your web app can access the VPN servers logs, current connections or API than yeah you might be able to set something up.
George
I'm trying to connect and getting an error like:
Login failed. The login cannot be used with Windows Authentication
I'm using mirrored local accounts on SQL Server and web server because I'm simply trying to use a trusted connection between machines not on the same domain. It seems like something that would be fairly common, but after days of trying to find an answer that applied to my situation, I do not recognize that any of the answers were applicable... that or the fact that I'm only a .NET developer and not a sysadmin or DBA means I have it and just don't know it.
Here's what I can say:
CMS web server: ASP.NET 4.0 web app running on Windows Server 2008, IIS7, on corporate DMZ
CMS database server: SQL Server 2008 R2 on a domain server
For various reasons that I won't go in to, encrypting the credentials is not sufficient.
The database port that the application needs to connect on is not the standard port and is set up to listen on a different port.
Setting up DB mirroring isn't an option and doesn't really address the requirements (in my way of thinking)
Also, FYI if this is helpful to know:
Content entry happens on internal web server which publishes content to same DB that is accessed by the DMZ web server.
Content server is set up to have the website run the app pool in integrated mode with a windows domain user that has been set as a service account using the -ga switch and given all the appropriate rights and everything runs perfect.
External web server, without domain access, using mirrored accounts (same username and password set up on the SQL Server machine and web machine).
Local account on the web server set as a service account using -ga switch and running as the app pool identity for my app.
On the SQL Server box, created local user with identical creds and given same permissions that the domain user identity has
Connecting to SQL Server via MGMT studio installed on web server with the SQL Server user creds works fine.
Now, if I put in the username in to the connection strings, everything is perfect. As soon as I put the trusted_connection=yes in the connection string like I did with the domain server connection strings, I get the trust error.
So if my connection string is like this, it works fine:
Server=myServerAddress;Database=myDataBase;Username=MyUser; Password=MyPassword;
If I change my connection string to either of these, it fails:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
or
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
I'm working with one of the client's network admins and he's not necessarily a DBA and doesn't have experience with configuring web apps. So it's possible that we're missing something and any advice or ideas would help. What am I missing?
If using SQL credentials are not an option, then you should use Active Directory and create a one-way trust (have DMZ server domain trust your internal domain), create a service account in your internal domain which your DMZ application can use, and grant that account access to the database. Then it will be able to generate SSPI context.
Here at work we just implemented an Apple Open Directory server. It stores everyone's usernames and passwords and implements LDAP and Kerberos. I've been tasked with configuring all of our ASP.Net web applications to authenticate with it--so users can use their Open Directory usernames and passwords to log into our ASP.Net applications.
I need something like mod_auth_kerb, except for IIS and ASP.Net--and I'd like to use forms-based authentication.
Is this possible?
IIS only supports kerberos for NTLM authentication as far as I know. I have never seen a secondary kerberos capable library or software. (true kerberos I mean) Now you could use the LDAP libraries in .Net to communicate between the servers in a kerberos fashion, but the connection between user client and asp.net server would still be an SSL plain/text connection.
I've also never seen it done, but it should be able to be done ... if the asp.net server had a trust relationship with the Apple Open Directory server with an LDAP connection made between the two, it might be possible to enable the NTLM authentication at the IIS level, and that would (in theory) extend the kerberos connectivity to the AOD through the trust. Again, I've never even contemplated it so I don't know what the pitfalls would be of attempting it.
I have successfully used DirectoryServices to connect to other Active Directories through the LDAP protocol, but I still have not found a way to embed the kerberos connectivity between client and authentication server without NTLM.
To use Kerberos authentication in IIS, your authentication type for the protected resource should be "Windows Authentication". This will make IIS use Negotiate (spnego) authentication. The server must be a member of a domain for Kerberos to work. I'd recommend using a Server 2008 or Server 2008 R2 machine for this if possible as it handles Kerberos authentication more gracefully.
I haven't gotten a chance to work with a Mac server for a while, but It's my understanding that Open Directory is capable of serving a Windows domain member. For authorization, you'll have to query the LDAP directory from ASP or use your own internal authorization mechanism.
Edit: This Microsoft KB article might be of some use to you: http://msdn.microsoft.com/en-us/library/aa480475.aspx
The environment setup has an ASP.NET webservice on IIS 6 connecting to a SQL Server over the network.
I am trying to understand, whether it's possible to secure the calls between IIS and SQL Server 2008. Is it possible? Is it something on the lines of SSL?
thanks for reading!
If you still want to after Pierreten's answer...
Yes, you can enable SSL Encryption for all SQL Server connections.
SQL Server SSL Encryption, server side, is described here. And in KB 316898 too
"Server side" requires only a server certificate and all connections are encrypted
"client side" requires client certs and is optional, and only for that client
Certain client libraries (notably MS JDBC) do not support server side s you may invalidate your host's monitoring (This has happened to me a time or 2)
a blog entry too
Assuming your SQL box is on the same network as your iis box hosting the service, and both are tucked away behind a firewall, there's no need for that extra security
If both machines are in the same domain, an efficient and easy to manage way to secure the link is by using IPsec.
Our website connects to a database correctly when running the website locally using the built-in web server. But, when we deploy the site to our server running IIS, we get a database connection error. The database server is different from our IIS server. Note that a trusted connection to a different database on the SAME server as IIS works fine.
What do we need to do to connect to a SQL database on a different server with a trusted connection?
When you're running a web site using Cassini, the account used by the web server process is your own account that you use to log on to your Windows machine. That account will be different on IIS.
Consider the security implications of opening the database up to a broader access than you may need with trusted connection. Perhaps you could use Windows authentication with a service account. That is, create an application-specific user in SQL Server with limited permissions. Then, you will get the benefits of connection pooling while avoiding passing credentials.
I'd check the user account that app domain in IIS is using to connect to SQL Server. The account in IIS may not have access to network resources as well which would explain the trouble reaching the other database server.
Sounds like you need to configure the database server to provide access to the database you're trying to connect to.
Assuming SQL Server, log into SQL Server Enterprise Manager and under Security -> Logins, open the properties for the applicable user (probably the Network Service or ASP.NET account of the web server) and go to the Database Access tab and ensure that the Permit checkbox is ticked for the database you are connecting to.