How can I troubleshoot when I'm unable to initiate a remote PowerShell session with FSx for Windows File Server over an external trust?
Last updated: 2021-03-17
I want to configure shadow copies on Amazon FSx for Windows File Server. However, I'm unable to do so because I get the following error while I set up a remote PowerShell session:
"enter-pssession : Connecting to remote server <FSx_DNS_Name> failed with the following error message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer <FSx_DNS_Name>. Verify that the computer exists on the network and that the name provided is spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic."
First, confirm that your configuration meets the following prerequisites:
- You must create a trust relationship between the on-premises Microsoft Active Directory and AWS Directory Service for Microsoft Active Directory.
Note: At minimum, you must have two one-way trust relationships. One one-way trust relationship must be an outgoing trust from the AWS Managed Microsoft AD where your Amazon FSx computer objects are. The other one-way trust relationship must be an incoming trust on the on-premises Microsoft AD.
- You must have an on-premises AD user that is part of the Amazon FSx administrators group in the AWS Managed Microsoft AD directory.
- Your Amazon FSx security group must have rules that allow traffic to and from the IP addresses or security group IDs associated with the client that you want to manage Amazon FSx and enable shadow copies from. The Amazon FSx security group must allow this inbound and outbound traffic on the following ports:
TCP/UDP 445 (SMB)
TCP 135 (RPC)
TCP/UDP 1024-65535 (Ephemeral ports for RPC)
If your configuration meets the prerequisites, but you're still getting the "Kerberos authentication: Cannot find the computer" error, then the error might be related to the Microsoft external trust. For Kerberos authentication to work with Microsoft external trust, the application building the service principal names (SPNs) must build three-part SPNs. The enter-pssession cmdlet requests only a two-part SPN, so the request fails. If you run a network trace while you run the PowerShell cmdlet, then the request returns an error message similar to "Kerberos: KRB_ERROR - KDC_ERR_S_PRINCIPAL_UNKNOWN."
To resolve this error and enable Kerberos authentication over a Microsoft external trust, configure Kerberos Forest Search Order (KFSO) for the Kerberos client in the on-premises AD domain. In the Use forest search order window, for Forests to Search, add the domain names for your self-managed AD and the AWS Managed Microsoft AD. Add the domain names in the following format and order:
After you apply these settings on the machine that you use to maintain Amazon FSx, you can proceed with enabling shadow copies for Amazon FSx.