The following error occurred while using kerberos authentication cannot find the computer

PowerShell New-PSSession - WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer

imageВ предыдущей заметке я рассматривал вопрос автоматизации перевода объектов мониторинга в режим обслуживания на SCOM. Позже пришла в голову мысль об использовании в качестве имени сервера SCOM (при вызове скрипта управления режимом обслуживания) вместо FQDN-имени какого-то отдельно взятого сервера управления SCOM, имени NLB экземпляра, у которого в бакэнде 2 сервера управления SCOM. Однако в таком режиме вызова скрипта я столкнулся с ошибкой, говорящей о том, что сервер, с которого запускается скрипт, не имеет доверия к NLB-имени и удалённая сессия PSSession не может использовать механизм аутентификации Kerberos.

New-PSSession : [KOM-AD01-SCOMCL.holding.com] Connecting to remote server KOM-AD01-SCOMCL.holding.com failed with the following error message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer KOM-AD01-SCOMCL.holding.com. 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.

Последнее предложение в сообщении об ошибке содержит отсылку на справочную информацию PS, почитав которую можно понять суть проблемы. Вызвать эту справочную информацию можно командой:

Get-Help about_Remote_Troubleshooting | more

Кстати, если при попытке чтения справки PowerShell вы столкнётесь с ошибкой Интернет-обновления этой самой справки при условии, что у вас используется прокси, то, возможно, вам пригодится заметка Как выполнить обновление справки PowerShell (Update-Help) при использовании прокси.

Чтобы хост, с которого мы выполняем запуск скрипта доверял указанному нами имени удалённого хоста, нужно чтобы он был добавлен в пространство WSMan:localhostClientTrustedHosts

Посмотреть текущее значение этого пространства можно так:

Get-Item WSMan:localhostClientTrustedHosts

Установить новое значение (предыдущее значение будет переписано) можно так:

Set-Item WSMan:localhostClientTrustedHosts -Value "KOM-AD01-SCOMCL.holding.com"

Если установка значения будет использоваться где-то в скриптах, чтобы подавить запрос на изменение значения, можно добавить к команде ключ -Force

Чтобы полностью ослабить этот механизм проверки можно воспользоваться командой:

Set-Item WSMan:localhostClientTrustedHosts -Value "*" -Force

image

После этого скрипт направленный на имя хоста не имеющее привязки к Kerberos (или даже вообще при использовании IP адреса вместо имени) выполниться без вышеописанной ошибки.

Источник
  • Remove From My Forums

  • Question

  • Greetings,

    I’m attempting to set up a small test cluster for S2D testing and I’ve been following a handful of tutorials on setting it up without any success.  One of the bigger road blocks is happening early on in the «Test-Cluster» portion.  When
    I execute…

    Test-Cluster -Node myserver.mydomain.mylan -Include "Storage Spaces Direct",Inventory,Network,"System Configuration"

    … I get a bunch of warnings for the Storage Spaces Direct section…. like every one of the tests actually.  List All Disks, List file Shares, List Storage Enclosures, etc. etc.  I open up the report file to see what the fuss is about and for
    every one of them I’m getting the following error message:

      An error occurred while executing the test.
      One or more errors occurred.

      There was an error retrieving information about the Disks from node ‘myserver.mydomain.mylan’.

      ERROR CODE : 0x80131500;
      NATIVE ERROR CODE : 1.
      WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer myserver.mydomain.mylan. Verify that the computer exists on the network and that the name provided is spelled correctly.

    I’m running the PS command locally from the server.  Even so, I’ve enabled remote PS, set trusted hosts to * (tried setting by IP, server name, and FQDN too), turned off the firewall, tried using the enterprise admin and local server admin accounts….
    still no joy.  I actually soldiered on past the warnings and continued to follow steps to set up the cluster (it’s just a test after all), but when it came to adding disks to the storage cluster things went down hill fast. My hunch is it’s related to
    the warnings with the WinRM/Kerberos errors.  I’m at wits end for trying to decipher what it is that’s causing the authentication error.  Any help would be greatly appreciated.  

    Other notable information: for now there is only one DC and it’s being hosted as a VM on the Hyper-V storage node that I’m trying to do the test against.  The Hyper-V server is joined to the domain hosted by the DC. There’s only one physical server
    for now as parts are on backorder for a second server to make a true cluster (from what I’ve read, the tests for stuff like gathering local disks on a node should not fail because of that though). DC and HV can ping and talk to each other through the virtual
    switch which is set up for «External network».

    Thanks in advance for any help,

    Craig

    • Edited by

      Monday, February 6, 2017 11:08 AM
      paragraph spacing was all jacked up

    • Moved by
      Leo Han
      Tuesday, February 7, 2017 6:40 AM
      Related to failover cluster

Answers

  • This is a true Face-Palm moment…

    So, I deleted everything and started over. A clean slate install of everything from the ground up. When I first loaded the OS, I set up roles and conducted the test before joining the domain… everything passed (more or less… there some warnings, but
    no WinRM/kerberos authentication failures). I set up the DC again and joined the server to the domain… the test failed. After banging my head for a while longer, I realized that I was logged into the server using the
    local admin     account, not the domain admin account. After I logged in with the domain admin account… everything passed.

    Long story short… Make sure you use a domain account, not a local account. That was a lot of time wasted for such a simple fix.

    • Marked as answer by
      Craig Haydock
      Thursday, February 9, 2017 10:30 PM

Источник

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.»

Resolution

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:

selfmanaged.example.com;awsmanaged.example.com

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.

Did this article help?

Do you need billing or technical support?

AWS support for Internet Explorer ends on 07/31/2022. Supported browsers are Chrome, Firefox, Edge, and Safari.
Learn more »

Источник

Понравилась статья? Поделить с друзьями:
  • The following error occurred while executing this line перевод
  • The following error occurred while applying patch
  • The following error occurred when trying to configure iis express for project
  • The following error occurred validating the name a general network error occurred
  • The following error occurred unknown reason