We're experiencing issues with a third-party application running on Windows 2016 that uses Kerberos and SSPI (Windows Security Support Provider interface) where the vendor has suggested this could be related to Kerberos authentication failures. The service runs as a domain service account. In the Windows 2016 domain controller security logs we're seeing Event ID 5071 failure audits with the description:
Key access denied by Microsoft key distribution service
This all worked in the past and similar configuration works in other parts of our system (different service accounts, servers, domain controllers). In fact, we have a full hardware level clone of our setup as a test system and the issue doesn't exist there.
There is limited information online that we've been able to find on this particular event. We are in the process of performing all the normal Kerberos advanced troubleshooting so don't need assistance from that angle. We have a ticket open with Microsoft so will post their response here.
Has anyone encountered this event previously and has any insight into the potential cause(s)?
Related
We have a bunch of Windows server applications that currently handle secrets as follows; our apps are in C#.
We store them in settings files in code
We store them encrypted, using a certificate
The servers have this certificate with the private key, so they can decrypt the secret
We're looking at implementing Hashicorp Vault. It seems easy enough to simply replace the encrypt-store-decrypt with storing the secret in Vault in the KV engine, and just grabbing it in our apps - that takes that certificate out of the picture entirely. Since we're on-prem, I'll need to figure out our auth method.
We have different apps running on different machines, and it's somewhat dynamic (not as much as an autoscaling scenario, but not permanent - so we can't just assign servers to roles one time and depend on Kerberos auth).
I'm unsure how to make AppRole work in our scenario. We don't have one of the example "trusted platforms" or "trusted entities", there's no Nomad, Chef, Terraform, etc. We have Windows machines, in a domain, and we have a homegrown orchestrator that could be queried to say "This machine name runs these apps", so maybe there's something that can be done there?
Am I in "write your own auth plugin" territory, to speak to our homegrown orchestrator?
Edit - someone on Reddit suggested that this is a simple solution if our apps are all 1-to-1 with the Windows domain account they run under, because then we can just use kerb authentication. That's not currently the way we're architected, but we've got to solve this somehow, and that might do it nicely.
2nd edit - replaced "services" with "apps", since most of our services aren't actually running as Windows services, just processes. The launcher is a Windows service but the individual processes it launches are not.
How about Group Managed Service Accounts?
https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
Essentially you created one "trusted platform" (to your key vault service).
Your service can still has its own identity but delegation to the gMSA when you want to retrieve the secrets.
For future visibility, here's what we landed on:
TLS certificate authentication. Using Vault, we issue a handful of certs, each will correspond to a security policy/profile, so that any machine that holds that certificate will be able to authenticate and retrieve the secrets they should have access to.
Kerberos ended up being a dead-end for two reasons. The vault.exe agent (which is part of this use case) can't use the native Windows Kerberos SSPI, so we'd have to manage and distribute keytab files. Also, if we used machine authentication, it would blow up our client count (we're using the cloud-hosted HCP Vault, where pricing is partially based on client count).
Custom plugins can't be loaded into the HCP, of course
Azure won't work, it requires Managed Identities which you can't assign to on-prem machines. Otherwise this might have been a great fit
I am creating a logic app that will trigger when a form request is submitted.
The MS Form connector requires me to sign in. This is acceptable during development, but we have a lot of logic apps and so use DevOps to automate deployment.
With the current connector, after deployment we still have to:
manually open the logic app in the portal.
connect using authorized credentials.
save the logic app.
This manual process completely defeats the point of using DevOps with Logic Apps.
Its a similar issue when using the Outlook connector.
Is there a way to supply server principal credentials to these connectors, so that they are correct at deployment time and require no manual intervention?
It seems that it's not supported to login on MS Forms connector with service principal. Connectors that can use service principal authentication will have "Connect with Service Principal" option, like Azure Data explorer. You can give your voice on this feedback to promote this feature.
API Connections with OAuth authentication, like Office 365 and Microsoft Team connectors etc, require manual consent. Unfortunately, at this point in time, authentication for those cannot be fully automated.
Here is a ticket you can refer to.
I am trying to publish a very simple workflow from SharePoint Designer 2013 to SharePoint Online.
The following error appears:
Microsoft.SharePoint.SPPrincipalManagementException: An error occurred
while attempting to execute a principal management operation. Please
contact your administrator. --->
System.ServiceModel.FaultException`1[Microsoft.Online.Administration.WebService.PropertyValidationException]:
Invalid property specified
Server stack trace: at
System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime
operation, ProxyRpc& rpc) at
System.ServiceModel.Channels.ServiceChannel.Cal
How can I handle this?
You can try create a new sub-site from your site collect then upload your workflow to see if its viable.
If not, you can check whether the Central Admin > Manage Service Application-> “App Management Service” is started.
Also heck whether the “Configure service application associations”, ”App Management Service” is already associated.
Then check whether the “Manage Services on server” and the “App Management Service” is started.
In addition, try to re-register Workflow Service.
If the issues still exists, please follow the steps in the Steps to Verify that Server Is Correctly Set Up. After you verified that the server is correctly set up, follow the steps in the Steps to Troubleshoot Workflow Management Service and Troubleshooting the Service Bus for Windows Server then retry your action.
If all above doesn't solve problem, then you should create a service request to Microsoft in SharePoint Online Admin Portal directly. Since issue is more likely related to SharePoint Online Server Back end.
I can see the message using network capture tool Microsoft Message Analyzer. I can see the I receive Kerberos error "KDC_ERR_C_PRINCIPAL_UNKNOWN: Client not found in Kerberos database".
I can see all parts of the message, I have been searching online and tried a few things and did not work.
But in order to understand the problem, what does the "client" mean here?
- Is it the Server / Computer that is requesting
- Is it the Application that is requesting
The error is for KRB_TGS_REQ which means that its requesting for a token.
Would be great if anyone could help understand, which I believe can lead to a resolution.
Added more Details:
We have a SharePoint farm setup with SQL Reporting Services (SharePoint Integrated mode) and Excel Services. We have a datasource defined in Sharepoint which are used in SSRS Reports and Excel Reports. We use Windows Authentication from Sharepoint to SQL. When we test connection on Sharepoint datasource we get an error which says Cannot convert Windows token to Claims token. On opening the reports in SSRS we also receive error.
Strange part is that it works for some users which is why I'm not sure how to tackle this issue. If its SQL Server previlage issue, we have assigned sys admin role, this user also added as admin in SSRS. If AD or SPN issue it must not work for all users not for individual users.
I can see successful KRB_TGS_REQ for an admin user but fails for a normal user. No clue what to look for.
Kerberos Message :
KRB_TGS_ERROR, KDC_ERR_C_PRINCIPAL_UNKNOWN: Client not found in Kerberos database, Cname: nothing, Realm: SUB.DOMAIN.COM, Sname: SP_SVC_ACT
Does this mean that the delegation is not working?
We have implemented Single Sign-On (SSO) using Kerberos in our production environment.
The configuration of our application is as below.
Operating System: Solaris10
Application Server: WebSphere7.0.0.11
Things are working fine for the Parent domain (MAIL.COM). But the users from child domains (like CO.MAIL.COM, BO.MAIL.COM..) are unable to login to the application.
We have the Kerberos Configuration file with the child domain details also. My doubt is "What are the changes needs to be done at the WAS console (realm related, domain related etc..)"
Thank you very much in advance..!!!