An error message was received upon logon session with the client time and server time being recorded as 13:10:2.0000 10/11/2013 Z. The error code was 0x7, specifically kdc_err_s_principal_unknown, and the extended error, client realm, and client name were not provided. However, the server realm was identified as rootY.local, with the server name being krbtgt/rootX.local and the target name being krbtgt/[email protected]. The error text, file, and line were not specified, but error data is available in the record data. The error message also indicated that the ticket-granting service can issue tickets with a different network address than the one in the TGT, and that postdated tickets should not be supported in KILE (Microsoft Kerberos Protocol Extension), with proxy indicating that the network address in the ticket differs from the one in the TGT used to obtain the ticket.
Kerberos has been set up on two SharePoint farms, farm A and farm B, with the same service accounts. Additionally, Reporting Server has been integrated. Users belong to the domain rootX.local, while the SharePoint farms belong to the domain rootY.local. Although the trusts seem to be working well for farm A, farm B is encountering http/401 unauthorized errors on the datasource pages of the Report Server, which suggests Kerberos-related problems. The WFE’s Event log also displays the following error.
Message was received:
on logon session
Server Time: 13:10:2.0000 10/11/2013 Z
Error Code: 0x7
Server Realm: rootY.local
Server Name: krbtgt/rootX.local
Target Name: krbtgt/[email protected]
Error Data is in record data.
The issue may stem from a missing SPN or Delegation-setting on AD. We have extensively reviewed all SPN’s and settings related to Kerberos authentication, as we employ unconstrained delegation due to a one-way trust and cross-forest configuration.
The error message mentioning “krbtgt” is puzzling. Typically, I would anticipate that the error would specify a server or account name. However, after reviewing other online discussions regarding similar errors, it appears that the root cause is often a missing SPN.
I am completely clueless at this point. Is there someone who could advise me on what to inspect or modify?
Finally solved the error…
While reviewing the event log, I noticed SSL errors. It seemed odd since SSRS was set up as HTTP. To address this, I removed the 443 URL by eliminating the HTTPS binding in SSRS entirely.
An alternative mistake to the http/401 unauth.:
Reporting service URL
error is the inability to locate it. However, I recall a solution that involves modifying the authentication method in SSRS from NTLM to Negotiate.