I am calling a remote service and authenticating using a certificate. When testing with a Console App, everything works fine. When calling from an ASP.NET Website (.NET 4.0, IIS7) I receive a response code of 401 -- Unauthorized.
I am adding the certificate using code such as:
var client = new TheGeneratedProxy();
client.ClientCertificates.Add(new X509Certificate("D:\cert.pfx", "myPassword"));
(NOTE: I have also loaded the .pfx into the local Certificate Store using IE. The certificate is loaded into my "Personal" store -- so I suspect this to be the problem, since the Website will be running under a different account.)
I think the problem is that your IIS user (Network Service / ASPNET) doesn't have access to the certificate. In order to grant Network Service to access the certificate in the store, download the following tool: winhttpcertcfg (http://www.microsoft.com/downloads/details.aspx?familyid=c42e27ac-3409-40e9-8667-c748e422833f&displaylang=en)
Now open command prompt and type:
winhttpcertcfg –g –c LOCAL_MACHINE\My –s ORGNAME –a "Network Service"
Please note that "Network Service" can be substituted with any other account. I.e. if you you have configured a custom user for your app pool, you should put this user as the value for the -a parameter.
ORGNAME should be substituted with the Organisation name you specified during the creation of your cert.
Related
I'm building an Azure web app for a client that will be provisioned into many other directories for their customers. This app will call a web API in my client's directory, which will then call back to another web API in the customer's directory. Something like this:
Other Customer AAD1 --------- My client AAD2
App --------------------------------> Web API 2
Web API 1 <-------------------------- Web API 2
We have been able to get the first call to work. This requires a corresponding App Registation for Web API 2 in AAD1. We figure that we could get the callback to work by following the same pattern, with a registration for Web API1 in AAD2. However, that might be a LOT of these 'proxy' registration in my client's AAD, so we're looking at alternatives.
We are exploring using Managed Service Identity, which we think will allow us to get tokens that are valid for resources in other tenants. If there's a better way, I'm certainly interested in knowing about it.
I've followed the code example from here using the Microsoft.Azure.Services.AppAuthentication library: https://learn.microsoft.com/en-us/azure/app-service/app-service-managed-service-identity#obtaining-tokens-for-azure-resources
// In Web API 2
using Microsoft.Azure.Services.AppAuthentication;
// ...
var azureServiceTokenProvider = new AzureServiceTokenProvider();
string accessToken = await azureServiceTokenProvider.GetAccessTokenAsync(
"https://<App ID URI for Web API1>");
Web API2 is configured to have a Managed Service Identity.
I'm currently running this on my local machine, and I've installed Azure CLI and I'm logged in. I've tried 'az account get-access-token', and I get a valid token.
When Web API2 tries to get the token to be able to call Web API1, I get an exception:
Parameters: Connectionstring: [No connection string specified], Resource: , Authority: . Exception Message: Tried the following 2 methods to get an access token, but none of them worked.
Parameters: Connectionstring: [No connection string specified], Resource: , Authority: . Exception Message: Tried to get token using Managed Service Identity. Unable to connect to the Managed Service Identity (MSI) endpoint. Please check that you are running on an Azure resource that has MSI setup.
Parameters: Connectionstring: [No connection string specified], Resource: , Authority: . Exception Message: Tried to get token using Azure CLI. Access token could not be acquired. ERROR: Get Token request returned http error: 400 and server response: {"error":"invalid_grant","error_description":"AADSTS65001: The user or administrator has not consented to use the application with ID '04b07795-8ddb-461a-bbee-02f9e1bf7b46' named 'Web API 1'. Send an interactive authorization request for this user and resource.\r\nTrace ID: f5bb0d4d-6f92-4fdd-81b7-e82a78720a00\r\nCorrelation ID: 04f92114-8d9d-40c6-b292-965168d6a919\r\nTimestamp: 2017-10-19 16:39:22Z","error_codes":[65001],"timestamp":"2017-10-19 16:39:22Z","trace_id":"f5bb0d4d-6f92-4fdd-81b7-e82a78720a00","correlation_id":"04f92114-8d9d-40c6-b292-965168d6a919"}
What's interesting is that there's no application with ID '04b07795-8ddb-461a-bbee-02f9e1bf7b46' in either AAD1 or AAD2. Is this a known Azure app? I thought that it might be the Service Management API, but I'm not sure.
In any case, I'm not sure of the proper way to grant permission. I've tried building different content URLs like this into my browser, but none of them seem to have done the trick:
https://login.microsoftonline.com/(AAD1 ID)/adminconsent
?client_id=(App ID)
&redirect_uri=https://localhost:44341
&resource=(App ID URI for Web API1)
&prompt=admin_consent
https://login.microsoftonline.com/(AAD1 ID)/adminconsent
?client_id=04b07795-8ddb-461a-bbee-02f9e1bf7b46
&redirect_uri=https://localhost:44341
&resource=(App ID URI for Web API1)
&prompt=admin_consent
(This last one tells me that the reply URL is incorrect; since it's not one of my apps, I can't find the reply URL)
Note that the tenant is AAD1.
Am I missing something, or am I not using this feature correctly?
Thanks in advance.
AzureServiceTokenProvider uses Azure CLI (among other options) for local development. For a scenario where a service calls an Azure Service, this works using the developer identity from Azure CLI, since Azure services allow access to both users and applications.
For a scenario where a service calls another custom service (like your scenario), you need to use a service principal for local development. For this, you have two options:
Login to Azure CLI using a service principal.
First, create a service principal for local development
https://learn.microsoft.com/en-us/cli/azure/create-an-azure-service-principal-azure-cli?view=azure-cli-latest
Then login to Azure CLI using it.
az login --service-principal -u 25922285-eab9-4262-ba61-8083533a929b --password <<pwd>> --tenant 72f988bf-86f1-41af-91ab-2d7cd011db47 --allow-no-subscriptions
Use the --allow-no-subscriptions argument since this service principal may not have access to any subscription.
Now, AzureServiceTokenProvider will get a token using this service principal for local development.
Specify service principal details in an environment variable. AzureServiceTokenProvider will use the specified service principal for local development. Please see the section Running the application using a service principal in local development environment in this sample on how to do that. https://github.com/Azure-Samples/app-service-msi-keyvault-dotnet
Note: Ths is only for local development. AzureServiceTokenProvider will use MSI when deployed to App Service.
I'm new to .NET Core and IdentityServer4. I started building an app on localhost using IISExpress together with Temporary Signing Credentials. Everything works great, I'm able to get access token via resource owner password, and make calls to authorized API methods.
However, when I deploy to a server (staging env), I'm always getting a 401 unauthorized for api calls that require authorization.
Before deployment, I made changes (as described below) on my localhost and tested it, result is as expected as before.
Change Temporary Signing Credentials to
services.AddIdentityServer()
.AddSigningCredential(new X509Certificate2(#"C:\Certs\DemoAuth.pfx"))
Create a self signed cert according to steps posted by David Smit
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\makecert" -n "CN=IdentityServer4Auth" -a sha256 -sv IdentityServer4Auth.pvk -r IdentityServer4Auth.cer -b 01/01/2017 -e 01/01/2025
"C:\Program Files (x86)\Windows Kits\8.1\bin\x64\pvk2pfx" -pvk IdentityServer4Auth.pvk -spc IdentityServer4Auth.cer -pfx IdentityServer4Auth.pfx
Set app pool settings to true for load user profile
Prior to setting load use profile to true, I've also tried with the following code:
services.AddIdentityServer()
.AddSigningCredential(new X509Certificate2(#"C:\Certs\DemoAuth.pfx", "pwd-here", X509KeyStorageFlags.MachineKeySet))
Can someone point me towards the right direction on the issue I'm facing when deployed?
Thanks in advance.
Make sure the certificate is in the Trusted Root Certificate Authorities (i.e. import your cert into that location in Windows Certificate Manager).
Make sure the account running the AppPool has permission to that certificate (right click the cert and use "Manage Private Keys" menu option under "All Tasks").
Actors
-Asp.net site - Client
-Wcf services - Server
Both applications runs on IIS-7.
I want to make integration test between the two applications. The client access the Server through 'https'.
I have created a certificate and assigned it to the server. I also added the certificate to the 'Trusted Root Certification Authorities' to be considered a valid certificate. When I 'hit' the server's services through my browser (IE, chrome...) the certificate appears to be valid. But when my client application tries to access the server then I get the following error:
Could not establish trust relationship for the SSL/TLS secure channel with authority **** --->
The remote certificate is invalid according to the validation procedure.
Is there any way to skip the validation procedure or to make the certificate valid for my client application?
Just to know:
1. I cannot purchase a certificate because I will only use it for testing purposes.
2. I cannot make any changes on any of the application's code (server-client)
I finally managed to figured it out.
The problem was a previous (expired) certificate with the same name that was already added to the 'Trusted Root Certification Authorities'. Every time I was installing my new certificate through the 'Certificate Import Wizard' (or through MMC) the wizard informed me that it was successfully added. However, it was keeping the instance of the previous certificate without overwriting it.
Modify the validation callback to always return true:
ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, policyErrors) => true;
Or does that violate the 'no changes to code' condition?
How did you install the certificate into your trusted root store?
If you went through a browser to do it, most likely you only added it to the current user. Try adding it through the MMC snap-in for the Local Computer Account instead; this is where we install our self-signed IIS Express certificates and WCF seems happy with them.
I'm running IIS5.0 and I am trying to change the ASP.NET process account to my domain user account.
I have followed everything possible here.
When I browse the .svc file (this is a wcf service) I am getting this error:
Server Application Unavailable The
web application you are attempting to
access on this web server is currently
unavailable. Please hit the "Refresh"
button in your web browser to retry
your request.
Administrator Note: An error message
detailing the cause of this specific
request failure can be found in the
application event log of the web
server. Please review this log entry
to discover what caused this error to
occur.
Eventlog says:
aspnet_wp.exe could not be started.
The error code for the failure is
80070522. This error can be caused when the worker process account has
insufficient rights to read the .NET
Framework files. Please ensure that
the .NET Framework is correctly
installed and that the ACLs on the
installation directory allow access to
the configured account.
When I run the client, I get the following error:
The content type text/html;
charset=utf-8 of the response message
does not match the content type of the
binding (application/soap+xml;
charset=utf-8). If using a custom
encoder, be sure that the
IsContentTypeSupported method is
implemented properly. The first 872
bytes of the response were: '
From ASP.NET 2.0 onwards, the correct method to ensure that a user account has the correct rights to run as the worker process identity is to run this command:
aspnet_regiis -ga [account]
You need to run the aspnet_regiis command that matches the ASP.NET version you plan on running:
ASP.NET 2.0 -
%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe -ga [account]
ASP.NET 4.0 -
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -ga [account]
If you put your Domain Account under IIS_WPG group, it should ideally work. If it doesn't work, there is a sure shot way of fixing it.
In IIS 6... step 1 is applicable... since you are on IIS 5, ignore step 1
Run it with Local System to begin with. If the applications runs, it means your IIS is configured well and you can proceed with the step 2.
Change the account to your domain account, and ensure that you have put the account in IIS_WPG as well. After that, run the tool called Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Browse the application now. If you still get the error, switch to the Process Monitor and stop capture [menu option].
Search for Access denied and fix it. Link
I have an ASP NET web server application that calls another process running on the same box that creates a pdf file and returns it. The second process requires a secure connection via SSL.
The second process has issued my ASP NET application with a digital certificate but I still cannot authenticate, getting a 403 error.
The code is a little hard to show but here's a simplified method ...
X509Certificate cert = X509Certificate.CreateFromCertFile("path\to\cert.cer");
string URL = "https://urltoservice?params=value";
HttpWebRequest req = HttpWebRequest.Create(URL) as HttpWebRequest;
req.ClientCertificates.Add(cert);
req.Credentials = CredentialCache.DefaultCredentials;
req.PreAuthenticate = true;
/// error happens here
WebResponse resp = req.GetResponse();
Stream input = resp.GetResponseStream();
The error text is "The remote server returned an error: (403) Forbidden."
Any pointers are welcome.
Finally fixed (wasted 6 hours on this *&%$##&)
I needed to grant access to the private keys on the digi cert to the account that the calling ASP.NET application runs under. This account is NETWORK SERVICE by default although you may want to run under a more restricted account.
Access is granted with the winhttpcertcfg tool, here's what got it working for me:
winhttpcertcfg -g -s "cert name" -c "LOCAL_MACHINE\MY" -a "NETWORK SERVICE"
where "cert name" is the CN of the digi cert.
More info at http://support.microsoft.com/kb/901183
Thanks to all who helped out with pointers on how to get this working :)
A 403 sounds like an authorization problem, not an authentication problem. It might be caused by the NTFS security settings on the files and folders accessed by your PDF service. Maybe it doesn't have permission to create the PDF file in the output folder?
Can you install the client certificate into your browser, and then access your PDF service through the browser? When you do that, do you still get a 403 or does it work?
Can you temporarily configure the PDF service to allow unencrypted HTTP connections? Does that make the problem go away?
From Windows Explorer, can you grant the "Network Service" account full control over the physical folder corresponding to the root of the PDF service site? Also grant it full control over any other directories it accesses. You should lock things down later after you've figured things out.
Or you can change the application pool to run under a different account - e.g. your own account.
Finally: if you're running IIS 7, you can turn on failed request tracing, which should give you a lot more info about why it failed.