Error 18542 two machines running 1903 windows 10 with controlled folder access same domain "login is from an untrusted domain"
How strange! What does Controlled Folder Access do? Guessing here - it denies access via the domain? (see solution that works below)
I have a live connection to a SQL Server on my domain. I believe what happened (the triggering event) is my login from one machine ton the other inside the domain, tried to export data from the SQL Server to an Excel spreadsheet and received as Error 18542 - which is a domain access error (Error 17806, then AcceptSecurityContext failure, then 18542). The login used is an administrator on both the server running SQL Server as well as the machine running Windows using SSMS (17.9.1 2017). I can log into the server running SQL Server to get the result I want but normally development occurs from the non-server machine. I wish it were that simple... admin permissions and the like!
I recently enabled the new "feature" (really learning to hate that word) calledRansomware Protection on the laptop accessing the machine with SQL running. I'm not sure what Ransomware Protection is but I already dislike it.
Why does my new "controlled folder access" feature believe I am trying to manipulate my files. I put in a couple of exceptions for allowing the SQL Server app to punch through whatever is there. Clarifying - the machine where SQL Server 2017 is running is actually an old desktop running Windows 10 1903 but without "Ransomware protection". Both are Windows 10 Enterprise versions. Both are on the same domain and are behind a NAT with a firewall running locally. Group policy is lax - default Business Server Essentials 2016 GP.
The service account running the database service on the SQL Server machine is running on an account that is (I think) Kerberos delegated and the delegated SPNs point to the SQL Server machine -maybe not. The Kerberos account is missing from the Active Directory - did I create it as a MSA? It also looks like my profile was reset on the same machine - was that the Controlled Folder Access at work?. I'm not sure how the database service account can live on the domain and not be in the active directory if the server is running. Some of the folks on my network have a Workgroup running and won't let me join them to the domain because "Windows disables the applications we use regularly and some of them cannot be re-registered" What a mess... urgh.
The chain of events began with an event on the SQL Server that states:
1) error 17806 Severity 20 state 14 (followed by)
2) "SSPI handshake failed with error code 0x80090311, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The operating system error code indicates the cause of failure. No authority could be contacted for authentication. [CLIENT: 192.xxx.xxx.xxx]"
3) Then the domain error above (18542)
So, with my jumbled security in place... aagh then "BAM" throw the Ransomware Protection on top of that. I get the errors described above. The fix below worked "Access this computer from the network"I'd like to understand why this part works a little better. Why would the accessibility of the computer from the network suddenly crumble?
BLOG SUGGESTION:
https://blogs.msdn.microsoft.com/docast/2016/02/11/common-sspi-handshake-failed-errors-and-troubleshooting/
We added the account “contoso\sqlaccount” to “Access this computer from the network” local security policy (secpol.msc) on the SQL Server box and post which we were successfully able to connect to the instance from the application.
So what is this Ransomware Protection doing to my laptop? Is this a bug?
R, J
