Here's the desired setup:
Service with wsHttpBinding is on IIS 6 on Machine 1 behind the firewall.
Client is front end website on IIS 6 on Machine 2 on a DMZ.
We are currently able to authenticate the client using Windows authentication, but with impersonation
<identity impersonate="true" userName="OurCompany\Me" password="Blahblahblah" />
since the website would use the "ASPNET" as username, which is not in the domain.
We now want to move away from this method, because of safety issue; we don't want to expose this kind of info on the DMZ.
Is there any way to get authenticated properly without using
the impersonate on the client
config?
If we changed so that we use
certificate authentication, would it
affect service operations that
require impersonations (needed
impersonations for file access on
the network for example)?
thanks.
This has been resolved now, and I think it'd be constructive to share the solutions.
In terms of my original question - whether it's able to do impersonation without setting it explicitly in the config or in the front end code. As mentioned by the above, the App Pool method does work, but only when both the client and server are on the same domain.
Since the web site client being situated in the DMZ has no access of the local network at all, meaning we are unable to impersonate any network user (this is a flaw in my original question, saying the impersonation works - it was actually not working).
So the only way to go was using certificate. Since this is internal communications, I have generated a test certificate on each of the server / client sides with the makecert. Using peer trust certificate authentications, I am able to get the communication working between the client and the server. This will ensure that no Windows / network user account information is presented in the DMZ zone.
Related
We have developed a web application to display sensitive information over our company's intranet. We had initially planned to implement sufficient security to allow remote access via the intranet to the application through a browser. But, due to an unforeseen requirements from our security team, we have decided not to allow remote access. We would still like a small number of users to be able to access the application, so here's the question. How can you host a web application in IIS visible only to users logged into the hosting machine? (The machine is both the host of the web app, and the only machine where the web app would be visible.)
I'm relatively new to IIS, so please speak as plainly as possible.
It seems like their must exist some setting in IIS to limit incoming and outgoing requests to the current machine.
It's possible to block all IP addresses with the following:
Which can be found in IIS 7 at this location:
I am facing the following issue.
1 - I have deployed WCF service with SSL enabled on remote IIS machine and trying to use it from my web client.The problem is my browser is not allowing this service to be called.Before using my web client i have to hit the service url from my browser directly and then allow the certificate.
2- Got suggestion from somewhere to export the certificate on the machine where WCF is deployed and include that certificate file in Trusted certificates group on my machine.After I did that I got same problem when tried to access web service from web client.So I hit the service url from browser and got the same page which needs me to trust the certificate with a different message that "You attempted to reach 111.121.196.226(ip address of the WCF machine), but instead you actually reached a server identifying itself as "WMSvc-domain" where "WMSvc-domain" is the value of "Issued To" field in the certificate.
I hope I have made myself clear.Waiting for suggestions.Thank you.
WMSvc-machinename is the IIS Windows Management Service which runs by default on 8172/tcp and is used for remotely managing iis. When installed the default is to create a self-signed certificate. That wouldn't trusted. It could be replaced with a "proper" CA signed cert through the Management Service icon in IIS Manager.
There are many versions of this question on stackoverflow. I have tried a lot of the solutions suggested there - but none of these work for me.
I have a VB ASP.NET application running on IIS on Windows Server 2008. It calls a webservice. The Server running the Web Service has a self signed certificate. I have imported the Cert into the Trust Store of the IIS machine. I can see the certificate in IE->Options->Content->Certificates->Trusted Root Certification Authorities.
When the webservice is called, an exception is thrown
The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
The same IIS VB ASP.NET Application runs fine on another machine with a similar setup.
These are the different basic things I have checked
The URL used to call the webservice is the same as the CN on the Cert imported into the Trusted Root CA.
Time is synced between the calling machine and the webservice host
The Cert isn't expired.
The IIS machine has Proxy settings in IIS, but Webservice Host machine as added to list of exceptions where Proxy should not be used.
I wrote a small command line test program in VB.NET calling the same webservice which runs fine.
After importing the Cert into the Trusted CA store, I have done a iisreset.
Only thing I haven't tried yet is rebooting the IIS machine - this is production machine & I cannot reboot it for at least a couple of days.
What else can I try?
Internet Explorer certificate settings apply only to the current user. It's highly unlikely that the same user you're logged in as when operating IE is the same as the one being used to host the IIS application. You could add the certificate to the trusted certs for the appropriate service account, but a simpler approach would be to add it to the "Local Computer" trusted certs.
Run Microsoft Management Console (type "mmc" in run dialog) File > Add / Remove Snap-Ins > Certificates, chose "Computer account" for the certificates to manage. This way, any user or service account on the server will see the certificate as trusted.
Alternatively, depending on how you're accessing the web-service, you could add an exception within the application itself. I would recommend code that checks the thumbprint / hash of the certificate though, as opposed to allowing it to connect to any un-trusted certificate.
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
I have an asp.net application that should access data from two SQL Servers. One of the SQL Servers is present on the same machine as IIS (let us call it SQLSERVER1) whereas the other SQL server is present on another machine (SQLSERVER2).
The connection strings are trusted for both the SQL servers. Impersonation has been set to true in my web.config file. I am using Windows authentication in both IIS and web.config.
When I try to access data from SQLSERVER2, I get login failed for user(null) error. The user through which I have logged in through Windows exists as a SQL server account in SQLSERVER2.
What could be the possible reason?
NOTE: This is a newbie question IMHO.
NOTE: The IIS used is 6.0 (Windows 2003). It is not set to IIS 5.0 isolation mode.
EDIT:The user getting impersonated is a domain user
Addition:
I also want to state that I get this error message when I access it as a client of the server where IIS is running. In other words, let me say I am working on machine A, the IIS and SQLSERVER1 are on machine B, and SQLSERVER2 is on machine C.
I do not get this error message when I am working on machine B. This is stumping me more.
This is absolutely a delegation problem. As one person pointed out, you need to make sure Kereberos authentication is being used. The old style NTLM isn't going to cut it. Here's more on Kerberos vs. NTLM.
In a nutshell, if you have a webserver and a database and you want the webserver to impersonate the user when making database requests (so that you can set up permissions on the database directly on a per-user or user-group basis) you're performing a double-hop. Credentials must past first from the user's computer to the webserver and again to the database. As you can imagine, the database has to trust the webserver to "do no evil" or this could be an extremely dangerous security hole. As a result, you have to set up what is called in the Windows Server world "delegation"...
Microsoft has a good article about all this here. Further, you can look over an article like this to get an idea of how to set it all up. We've run into this frequently, and it can be a pain at first, especially since as a developer you're probably not in control of the servers directly (especially production ones) and you'll have to spend a lot of time with the server guys down the hall.
You're probably running into this problem because non-Kerberos based impersonation (NTLM) is only valid on the local machine (the webserver). If you want to be able to use those credentials to access another machine, you're going to need to make sure you're using Kerberos.
Try this: http://support.microsoft.com/kb/810572
Your authentication to the webserver is not passed through to the sql server. The web server is authenticating to the SQL Server using the account that your application pool is running under.
You should check that the machine account for SQLSERVER1 has trusted for delegation enabled. Otherwise SQLSERVER2 won't trust the impersonation running on SQLSERVER1. This is in addition to confirming that Kerberos is used to set up the impersonation in the first place. This also assumes that the servers and the users are all members of the same domain.
BTW, are sure you want to do things this way, you end up creating a lot more connections because they end up being unique to a user?
Have you tried to access the database on server2 using SQL SErver administrator from Server1 and made a successful connection?
If not then this could be because by default SQL Server installs itself with tcp turned off by default.
You will need to make sure that this is turned on for server2 to allow server1 to connect.
server1 has no problems connecting due to the fact it can use the shared memory connection.