Şu anda 2 güvenilmeyen etki alanı arasında Windows Uzaktan Yönetim'i (özellikle Powershell Remoting) etkinleştirmeye çalışıyorum ve hiç şansım yok.
Kurulumumun kısa bir açıklaması:
- domain1 - iş istasyonum bu alanda
- domain2 - bağlanmak istediğim sunucu bu alanda
Bu alanlar arasında güven yoktur.
İş istasyonumdan (domain1'e katıldı) aşağıdaki komutları kullanarak Powershell uzak bağlantısı oluşturmaya çalışıyorum:
param (
[Parametresi (Zorunlu = $ True)]
$ sunucu
)
$ username = "alan \ kullanıcı"
$ password = read-host "$ kullanıcı adı için Parola Gir" -AsSecureString
$ credential = Yeni Nesne System.Management.Automation.PSCredential ($ kullanıcı adı, $ şifre)
$ session = Yeni-PSSession "$ server" -Kimlik Doğrulama CredSSP - Kimlik Bilgisi $ kimlik bilgisi -UseSSL -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)
Enter-PSSession $ oturumu
Hangi aşağıdaki hata iletisiyle sonuçlanır:
Yeni-PSSession: [computername.domain2.com] computername.domain2.com uzak sunucusuna bağlanma aşağıdaki hata iletisiyle başarısız oldu: WinRM istemcisi
istek işlenemiyor. Bilgisayar ilkesi, bilgisayara güvenilmediği için kullanıcı kimlik bilgilerinin hedef bilgisayara devredilmesine izin vermez. Hedefin kimliği
aşağıdaki komutu kullanarak geçerli bir sertifika kullanacak şekilde yapılandırırsanız bilgisayar doğrulanabilir: winrm set winrm / config / service '@ {CertificateThumbprint = ""}' Veya
Olay Görüntüleyicisi'nde, aşağıdaki SPN'nin oluşturulamadığını belirten bir olay olup olmadığını denetleyebilirsiniz: WSMAN /. Bu olayı bulursanız, SPN'yi manuel olarak
setspn.exe. SPN varsa, ancak CredSSP hedef bilgisayarın kimliğini doğrulamak için Kerberos'u kullanamazsa ve yine de kullanıcı kimlik bilgilerinin hedefe devredilmesine izin vermek istiyorsanız
bilgisayarında gpedit.msc dosyasını kullanın ve aşağıdaki ilkeye bakın: Bilgisayar Yapılandırması -> Yönetim Şablonları -> Sistem -> Kimlik Bilgileri Temsilcisi -> Yalnızca NTLM ile Yeni Kimlik Bilgilerine İzin Ver
Sunucu Kimlik Doğrulaması. Hedef bilgisayara uygun bir SPN ile etkinleştirildiğini ve yapılandırıldığını doğrulayın. Örneğin, "myserver.domain.com" hedef bilgisayar adı için SPN
şunlardan biri: WSMAN / myserver.domain.com veya WSMAN / *. domain.com. Bu değişikliklerden sonra isteği tekrar deneyin. Daha fazla bilgi için about_Remote_Tro Sorun Giderme Yardım konusuna bakın.
Aşağıdaki şeyleri denedim / doğruladım:
- Etki alanı2'de hem WSMAN \ bilgisayaradı hem de WSMAN \ bilgisayaradı.etkialanı2.com için bir SPN bulunduğunu doğruladım.
- Bilgisayar Yapılandırması -> Yönetim Şablonları -> Sistem -> Kimlik Bilgileri Temsilciliği -> Yalnızca NTLM Sunucusu Kimlik Doğrulaması ile Yeni Kimlik Bilgilerine İzin Ver seçeneğinin doğru ayarlandığından emin olun.
- Hedef bilgisayarda winrm'yi ssl kullanacak şekilde yapılandırıldı.
- Aşağıdaki komutları kullanarak hedef bilgisayarda ve yerel iş istasyonumda yapılandırılmış CredSSP:
Hedef bilgisayarda Etkin-WSManCredSSP -Role Sunucusu # Etkinleştir-WSManCredSSP -Role İstemcisi -DelegeBilgisayar * -Force
- Ağdaki bilgisayarlarda veya ağda yerel olan hiçbir FW kuralının erişimimi engellemediğini doğruladım.
Hiçbiri, domain1'deki iş istasyonumdan domain2 içindeki hedef bilgisayara başarıyla bağlanmama izin vermedi. Etki alanı2'deki sunuculara değil, etki alanı1'e katılan diğer sunuculara başarıyla bağlanabiliyorum. Aramam gereken ve / veya bunun işe yaramaya çalıştığı başka bir şey var mı?
UPDATE 06/08/2015 Aslında CredSSP kullanmadan iş istasyonumdan sunucuya bağlanabileceğimi doğrulayabildim; Ancak, SharePoint'e karşı komut dosyaları çalıştırabilmem gerekiyor ve bunu CredSSP bir izin hatasıyla başarısız olmadan yapıyor.
Enable-WSManCredSSP -Role Client -DelegateComputer WSMAN/computername.domain2.com( msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx , 3. nokta)