I'm building an wcf service that is meant to run in an intranet environment using Windows Authentication. I have been merrily working along with some kind of default settings on the local computer.
Problem now is that I need to test it installed to an off site demo computer. I just need to get it running with username password used against the wcf service computer's user accounts.
This is my client code:
using (ImportServiceClient client = new ImportServiceClient("ImportServiceSoap12", REMOTE_ADDRESS))
{
client.ClientCredentials.Windows.AllowNtlm = true;
client.ClientCredentials.Windows.ClientCredential =
new NetworkCredential(userName, password, computerName);
result = client.Sync(items.ToArray());
}
Is it possible to configure the wcf service such that it translates the credential to a windows account on it's machine?
I've been reading contradicting posts here and there, but I feel rather sure IIS shouldn't be part of the authentication. I'm unsure wether ASP.Net authentication node applies or if it's all binding configuration.
Ideally I'd like it to be an NTLM type authentication so that I wouldn't need to set up https.
Is it possible to configure the wcf service such that it translates the credential to a windows account on its machine?
No. Integrated Windows Authentication requires that both the server and the client are part of the same domain (or domains with a trust relationship, in any case). You can't usefully run IWA against local computer accounts on the server.
You will have to use some other (potentially custom) form of authentication and then impersonate to the user you want to run as in the server code.
Related
Is there an advantage in using a trusted connection vs a sql login for web application? Is there any pros/cons from one to another?
I usually use Windows Authentication, which is more secure, with a service account. If you are doing an internal application within your own domain and you want to authenticate your users to the database server, you will need to set up delegation on that service account along with the IIS and SQL services. If it is outward facing or you aren't concerned with authenticating users to the database, you simply need to give the relevant permissions to the service account login in SQL. In either case, assuming your webserver is IIS, you would change the web application to run under the service account. This will encrypt and store the credentials on the webserver.
The main reason windows authentication is more secure is it makes use of the Active Directory infrastructure to authenticate users using encrypted messages between the servers. With SQL Authentication the credentials are passed across the network. If you do use SQL Authentication, you should make sure to encrypt the connection string portion of your web config, as you would embed the credentials including the password.
I have a web application that calls an object of a referenced dll/api that calls a wcf service.
Machine 1 = where the wcf service resides
Machine 2 = IIS server, the web application that uses the api that calls the service from Machine 1
My code:
using (WindowsAuthenticationContext ctx = identity.Impersonate()){
//Call to the API goes here
}
When I access the website from Machine 2(IIS Server), It works. But when I access the website from another client machine, it gives me an error "The Request Token Could not be satisfied".
NOTE: The api is already final, and cannot modify it anymore.
Any help would be greatly appreciated.
Thanks
You cannot do NTLM and then Kerberos over multiple hops (servers). You need to use Kerberos to delegate windows authentication over all the hops.
You need to configure SPNS to enable kerberos to delegate authentication across machines.
To configure these, you will have to issue the following commands - assuming you have right to modify AD:
SETSPN -S HTTP/Machine1 ADDomain\AppPoolCredential1
SETSPN -S HTTP/Machine1.domainname.com ADDomain\AppPoolCredential1
SETSPN -S HTTP/Machine2 ADDomain\AppPoolCredential2
SETSPN -S HTTP/Machine2.domainname.com ADDomain\AppPoolCredential2
Where ADDomain\AppPoolCredential is the credential of the app pool - note you cannot use Network Service as the app pool credential to get Kerberos delegation to work. You need to use a domain account.
IN AD, you need to enable the following objects for allow Kerberos Delegation:
ADDomain\AppPoolCredential1
ADDomain\AppPoolCredential2
Machine1
Machine2
For more information, see here
NTLM works in the machine with the local security context. If you want to use NTLM over different machines these machines should share the same security context like Active Directory Domain. If your site (where machines are in) does not have the same security context this would not work. You can use client certificate by changing the service's config. Not changing the dll or code.
I am trying to call a Sharepoint Web Service via WCF from inside a .ASHX on a different server. My code works if I run inside of Visual Studio's debug web server, but not from IIS. The working server works in various authentication modes (Kerberos, NTLM), and the non-working one doesn't work in any. I am impersonating the same user in both cases.
Using NTLM, I recorded a working session and non-working session in Wireshark. In the working one, Wireshark parses the NTLM data and reports a DOMAIN and USER NAME that I expect. In the non-working one, it shows
DOMAIN: NULL
USER NAME: NULL
I have debugged in IIS and impersonation is definitely working at the point of the service call. If I check WindowsIdentity.GetCurrent(), it's the user I expect.
If I inspect the WCF service proxy on the working and non-working servers, they look identical -- the part that deals with ClientCredentials is set to "" for Username and Password for both versions.
Any ideas on what else to check? Why would the NTLM data have DOMAIN and USER NAME set to NULL -- where does it pick that up from?
According to this:
http://support.microsoft.com/kb/207671
When IIS services an HTTP request, IIS performs impersonation so that access to resources to handle the request is limited appropriately. The impersonated security context is based on the kind of authentication performed for the request. The five different types of authentication available from IIS 4.0 are:
Authentication Type Impersonation Type
------------------------------------ ---------------------
Anonymous Access (no authentication) Network
Auto Password Synchronization is
ON (ON=default)
Anonymous Access (no authentication) IIS Clear Text
Auto Password Synchronization is OFF
Basic Authentication IIS Clear Text
NT Challenge/Response Authentication Network
Client SSL Certificate Mapping Interactive
In my case, I have a Network Token, but
Network tokens are "NOT" permitted to access network resources. (Network tokens are named so because this kind of token is traditionally created by a server when a user is authenticated across the network. To allow the server to use a network token to act as a network client and access another server is called "delegation" and is considered a possible security hole.)
The KB has many possible ways to avoid the problem
I want to let remote administrators (with local or domain credentials) control my Windows service via a WCF TCP binding. To do this, I need to authenticate the remote user as an administrator. I can check the principal user/roles, but I don't know how to prompt the remote user for the correct user details/token.
This is related to my previous question on Restricting WCF TCP endpoint to Administrators. Instead of adding [PrincipalPermission(SecurityAction.Demand, Role = "Administrator")] to my restricted service method and catching a SecurityException, it seems I can check for it with:
if (!System.Threading.Thread.CurrentPrincipal.IsInRole("Administrators"))
return MethodResult.AccessDenied;
// haven't tested if it's the service thread or the remote user yet.
How do I prompt the remote user for Windows authentication if a Access Denied result was returned so I can reinitiate the connection as a different principal?
Of course, the change would need to be effected on the remote user's client application. Perhaps there is a cleaner WCF way to do it?
Edit: Searching for ".net impersonation" led me to this on CodeProject. Haven't had a chance to look, but this may be the way to go.
You need to pass in the user's credentials with your WCF call. Normally the client application just "captures" the currently running user's credentials. Alternatively you can specify a username and password explicitly. So you could prompt the user for an alternative set of credentials if you wish.
Either way, the client app needs to prompt the user. Your WCF call should return an error (code or exception) upon authorization failure and your client should capture that return and display a prompt to the user and retry with the new credentials. WCF by itself cannot handle prompting the user.
Here is an article on various means of passing credentials:
http://blogs.msdn.com/b/sonuarora/archive/2007/04/21/setting-client-credentials.aspx
Assuming this is hosted in IIS you need to turn off anonymouse authentication in the IIS Manager. This should force the user to login to the machine using a Windows account. You may also need to enable ASP.NET Impersonation.
Here is how you can prompt the user using the standard windows dialog using pInvoke How to show authentication dialog in C# .Net 3.5 SP1
I like to use wcf (windows communication foundation) with windows authentication.
Do I need Active directory for this purpose?
How the server knows about the identity of the client?
If someone can found out the pass of the client that is using the wcf services, can he create the same user name on different computer and use the password to access the wcf services ?
Yes, if you want to use Windows authentication, you need Active Directory as the source where the user gets validated.
The way this happens is by means of a user "token" - when your client logs into his PC with his Windows credentials, the login process will check with AD whether the user is legit and issue a "token". This token is then used in calls to a WCF service to determine who it is that is calling the service.