We're facing an error while trying to deploy a WCF webservice in a server. While connecting to Dynamics (CRM on premise) we get this error: The authentication endpoint Username was not found on the configured Secure Token Service
If we test it locally, it's working but if the deploy the webservice in the server, this is the code which performs the login:
Uri serviceUri = new Uri(OrgServiceUri);
proxy = new OrganizationServiceProxy(serviceUri, null, authCredentials, null);
proxy.EnableProxyTypes();
_service = (IOrganizationService)proxy;
Guid userid = ((WhoAmIResponse)_service.Execute(new WhoAmIRequest())).UserId;
if (userid != Guid.Empty)
{
Console.WriteLine(userid);
return true;
}
else
{
return false;
}
Any guess?
Thank you!!
First, make sure the user you have set up as the service account has Read/Write access to CRM and has a security role assigned that enables it to log into CRM remotely.
Next, make sure the Username endpoint is configured in the ADFS deployment that this CRM org is using:
Log onto the ADFS server and open the ADFS management console. Go to ADFS > Service > Endpoints
You’ll see a list of endpoint URLs here. Find the one for /adfs/services/trust/13/username of type WS-Trust 1.3
Make sure that this endpoint has “Yes” set for both the Enabled and Proxy Enabled settings.
If you have to make a change to this endpoint, after making the change re-start the ADFS server and the CRM server, then try to register again.
Lastly, if the above looks okay, it could be a resolution or routing issue blocking the connection. Make sure that there are external DNS entries for the path to your ADFS server. Also, make sure that your firewall permits external access to the ADFS server. If you are able to, try to use a computer that is outside of your domain to navigate directly to the ADFS server to test its accessibility.
This is a problem with the same error as you, and it has been resolved, you can refer to: The authentication endpoint Username was not found on the configured Secure Token Service
Finally we found it was an issue with ADFS service per-se, networking related, since it wasnt able to connect SSO site. After fixing that, it started to work as a charm.
If you are running ADFS on-prem, the ADFS windows service might be stopped (Because of a power failure / unexpected server restart).
You just need to start it.
Related
I am having trouble authenticating my C# service for a remote cluster. Trying to use my svc gets Forbidden, so I am hoping to work around with this. I know that inClusterConfig does work properly when this service is in the Cluster, but I am trying to run local and host jobs in my remote cluster.
This is what I am trying:
Environment.SetEnvironmentVariable("KUBERNETES_SERVICE_HOST", "Value1");
Environment.SetEnvironmentVariable("KUBERNETES_SERVICE_PORT", "Value1");
KubernetesClientConfiguration config = new KubernetesClientConfiguration();
config.Host = "https://xx";
config = KubernetesClientConfiguration.InClusterConfig();
Not sure if this is possible. Currently getting error
Unable to load in-cluster configuration, KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT must be defined
Thanks
In addition to the environment variables, KubernetesClientConfiguration.IsInCluster also requires a token and certificate:
if (!FileUtils.FileSystem().File.Exists(tokenPath))
{
return false;
}
// ...
return FileUtils.FileSystem().File.Exists(certPath);
The details of authentication are explained in this answer:
When accessing the API from a Pod, the client certificate is located
on /var/run/secrets/kubernetes.io/serviceaccount/ca.crt and in
addition, you need to authenticate using the token located on
/var/run/secrets/kubernetes.io/serviceaccount/token
Once a connection is being attempted, per this answer:
InClusterConfig uses the default service account of the namespace
where you are deploying the pod. By default that service account will
not have any RBAC which leads to Forbidden error.
I am struggling to get a token from "https://login.microsoftonline.com/common/oauth2/token" with an Azure function by a post-request. The token will give permissions to access SharePoint though CSOM. Here is my code snippet with the post request:
var clientId = defaultAADAppId;
var body = $"resource={resource}&client_id={clientId}&grant_type=password&username={HttpUtility.UrlEncode(username)}&password={HttpUtility.UrlEncode(password)}";
using (var stringContent = new StringContent(body, Encoding.UTF8, "application/x-www-form-urlencoded"))
{
var result = await httpClient.PostAsync(tokenEndpoint, stringContent);
var tokenResult = JsonSerializer.Deserialize<JsonElement>(result);
var token = tokenResult.GetProperty("access_token").GetString();
}
When testing locally, both when running the function in Visual studio and when I try with Postman, I am able to achieve an access token. However, as soon as I publish the function to my Function app in Azure I receive the following error message:
"AADSTS53003: Access has been blocked by Conditional Access policies. The access policy does not allow token issuance"
I have enabled an app registration in the portal and as mentioned, it all works fine until I publish everything to Azure.
Any ideas on how to solve this?
I got it to work now. First of all I reviewed the CA policies as #CaseyCrookston suggested. What I found out was that our CA policies blocked calls outside the country we operate from. However, the calls from the App registration/Azure function were registered from the Azure data centre location and thus, blocked by our CA policies. When running them locally the calls where registered in my country and therefore no errors were showing while debugging.
My first step was trying to add my Client app to the CA policy, which was not possible. The client/secret authentication that I used based on the suggestions in this CSOM guide by Microsoft prevented the App registration to be whitelisted from the CA policies (Github issue).
Based on this I had to change the authentication to a Certificate-based authentication as suggested here: Access token request with a certificate and here: SO answer. With this I was able to whitelist the App registration in the CA policies and successfully authenticate to the Sharepoint CSOM.
As the error message says, your app is blocked by CA policy. Possible causes can be unknown client app, blocking external IP addresses, etc.
You can perform one of the below workarounds:
Add your Client app to your CA policy.
I wouldn’t recommend this because this affects your security - if you take the risk you could exclude the “Microsoft Azure Management” from your CA policy which blocks unknown clients / requires device state and still protect the sign-in with MFA.
A better approach is to use another OAuth 2.0 and OpenID connect flow like the delegated flow where you sign-in directly within the app, if possible.
I have the following architecture:
Client1(Browser-App) -> Server1 (WebAPI/IIS) -> Server2 (WebAPI/IIS)
I am using ASP.NET for my server-side applications/apis and the user should be authenticated via "windows integrated authentication".
As you can see there is a second hop from server1 to server2. NTML does not support the second hop if both WebAPIs are not on the same server.
So I configured an AD domain to support "kerberos".
It works now with the second hop.
My test-WebAPIs output the identity of the user like this:
server1: test.domain/user1
server2: test.domain/user1
But if I change the logged-in user on Client1 and execute the same request as "otherUser2", only the first hop gets the correct identity:
server1: test.domain/otherUser2
server2: test.domain/user1
On the second hop the old user of the first request is displayed.
I tested multiple scenarios: Same behaviour if the following requests come from another client with another windows user...
It looks like the windows identity of the first request is cached on the server2... This is a big problem for me and I think this should not be possible... It's a big security hole if a request is executed in the wrong user context!
Is this a known problem? Did I do something wrong?
Is there a solution or a better configuration?
On the first ASP.NET WebAPI I use impersonation like this:
WindowsIdentity identity = (WindowsIdentity)HttpContext.Current.User.Identity;
using (var wic = identity.Impersonate())
{
try
{
WebClient c = new WebClient
{
UseDefaultCredentials = true
};
I use the WebClient class of .NET.
Both IIS server have "Windows Authentication" with "Negotiation" and "NTML" configured.
Server1 is the DomainController, DNS and DHCP-Server (+IIS)
Server2 is only a normal server with IIS installed.
All computers are in the same domain.
I cannot explain me this behavior... It makes no sense to me. Why should the first incoming request's identity should be cached on 'server2'?
If I restart the IIS and re-execute the requests with another windows identity, this is the "first working request" and the others get his identity on 'server2'.
I found the solution/problem.
It was in fact a caching problem... The identity of the first user was cached.
You can change this behavior with this "IIS settings":
authPersistNonNTLM
authPersistSingleRequest
Or your HTTP-Client at API1 can disable TCP-Connection caching:
Connection: close
instead of
Connection: keep-alive
But the actual problem in my scenario was fiddler (a HTTP proxy tool).
I configured fiddler as proxy in the web.config at API1. This kept the connection open and the first identity was reused...
I hope I can help some others with this answer.
I'm developing UWP application using C#.net and it has WCF service with Windows Authentication enabled. I struggling to pass default NetworkCredential after consume a service call using Add service reference option.
Please find below my examinations.
When I pass correct windows authentication credentials, it is working as expected.
var service = new ServiceReference.Service1Client();
service.ClientCredentials.Windows.ClientCredential =new NetworkCredential("pradeep","****");
var test = await service.GetDataAsync(1);
but, I wanted pass default network credentials while using my service methis
var service = new ServiceReference.Service1Client();
service.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials;
var test = await service.GetDataAsync(1);
I also tried below option.
service.ClientCredentials.Windows.ClientCredential = (NetworkCredential)CredentialCache.DefaultCredentials;
When I pass default credentials. I'm getting below exception.
The HTTP request is unauthorized with client authentication scheme
'Negotiate'. The authentication header received from the server was
'Negotiate, NTLM'.
I tested same service call with default NetworkCredential in WPF application which is working as expected.
In order to pass the default credentials for the WCF Windows Authentication in UWP by using the System.Net.CredentialCache.DefaultNetworkCredentials, first please make sure that you have added the Enterprise Authentication and Private Networks(Client & Server) capabilities as following:
For the Enterprise Authentication capability, it is because that Windows domain credentials enable a user to log into remote resources using their credentials, and act as if a user provided their user name and password. The enterprise Authentication special capability is typically used in line-of-business apps that connect to servers within an enterprise.
For the Private Networks(Client & Server) capability, it is because that currently in Windows Runtime we can only pass the default credential in the Intranet. For the Internet we have to use the Username and Password as credential.
For more information about the Capabilities, please check:
https://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx .
After that please try to use your Computer name or Fully Qualified Computer name instead of the IP address for your WCF Services like this: http://YourComputerName:YourPortNumber/Service1.svc.
At last please use another computer as client to test the WCF Windows Authentication in UWP with the System.Net.CredentialCache.DefaultNetworkCredentials, then it should work fine.
Thanks.
I have an asp.net site on IIS using windows authentication (pass through) and I am trying to connect to the TFS API programmatically.
When I run it on my dev machine all is fine but once the site is on IIS I keep getting {"TF30063: You are not authorized to access http://mytfsserver."}
I have debugged the live site and it seems like it always takes the user as "NT SYSTEM" instead of the actual logged in user.
If I put my account details for the application pool it works as expected.
Any idea on how I can bypass this?
Code where it fails:
Uri collectionUri = new Uri(rootWebConfig.AppSettings.Settings["TFS_TEST_URI"].Value); //TEST ENV
tpc = new TfsTeamProjectCollection(collectionUri, CredentialCache.DefaultNetworkCredentials);
tpc.Authenticate();
workItemStore = tpc.GetService<WorkItemStore>();
You are hitting a standard active directory double hop authentication issue.
You have two options:
Username & password - if you ask the user to physically enter their username and password you can authenticate as them.
Kerberos - if you enable and configure Kerberos you can enable passthrough authentication. You need properly configured SPN: http://blogs.technet.com/b/askds/archive/2008/06/13/understanding-kerberos-double-hop.aspx
I would go with kerberos tokens. It's a pain to configure but works a treat. Your only other alternative is to run your web app on the TFS server and bypass double hop.