Puncte:0

Serverele Linux nu mai pot folosi PowerShell la distanță prin WinRM folosind NTLM pe serverele Windows la distanță

drapel sm

Deci, practic, avem o echipă cu servere Linux care rulează PowerShell Core (un amestec de 6 și 7) care trebuie să execute comenzi Windows PowerShell de la distanță pe serverele Windows. Problema este că echipa nu a făcut niciodată Kerberos să lucreze pentru autentificare și se bazează pe gssapi pentru ca auth NTLM să funcționeze, ceea ce AFAIK nu este suportat de MS pentru acest scenariu.

Ceea ce se întâmplă acum este că aceste servere Linux primesc erori MI_RESULT_FAILED după un timp (acest lucru tocmai a început săptămâna trecută, lucrurile mergeau bine înainte) și necesită o repornire a serviciului WinRM pe nodul de la distanță pentru ca telecomandă să funcționeze. Acest lucru funcționează aproximativ o zi înainte ca WinRM să fie respins din nou.

Acum, deoarece NTLM nu este un mecanism de autentificare acceptat de PowerShell Core pe Linux (funcționează doar datorită gssntlmssp, care este întreținut de RedHat, nu de Microsoft), calea clară de urmat aici ar fi fie să folosiți OpenSSH pentru PS Remoting din Linux, sau pivotați pentru a utiliza autentificarea Kerberos în loc de NTLM. Cu toate acestea, deoarece lucrurile funcționau înainte de săptămâna trecută, conducerea nu dorește să întrețină o autentificare sau o modificare a protocolului pentru a rezolva această problemă, ei doresc ca ceea ce funcționa să fie remediat. În acest moment îmi învârt roțile încercând să-mi dau seama de ce s-a rupt auth NTLM, iar soluțiile mele recomandate nu sunt disponibile pentru moment.

Nodurile sursă rulează RHEL8 sau AL2, nodurile la distanță sunt Windows 2016-2019, cu câteva moșteniri din 2012 în amestec. Windows la Windows PS Remoting face nu rupe aici, numai Linux la Windows.

S-a mai lovit cineva de această situație sau ceva asemănător? Aveți idei despre ce am putea încerca să rezolvăm asta?

EDIT: Am corectat eroarea de mai sus la MI_RESULT_FAILED. ACCES INTERZIS este ceea ce a spus echipa care a raportat problema, dar în reproducerea noastră a problemei vedem MI_RESULT_FAILED. Urmărirea WinRM arată că autentificarea NTLM reușește, dar eșuează chiar și atunci când pur și simplu se afișează „Hello World” prin Invocare-Comandă.

drapel cn
Ce este în jurnalul de evenimente Windows Remote Management/Operational? Acesta are de obicei detalii pentru eșec.
Bender the Greatest avatar
drapel sm
Am corectat eroarea de mai sus, dar când apare problema, singura intrare de jurnal pe care o ajung la „Windows Remote Management/Operational” este „Crearea shell WSMan pe server cu ResourceUri: %1”
duct_tape_coder avatar
drapel cn
Doar pentru a verifica, vrei să spui de fapt NTLM sau NTLMv2? În general, NTLMv1 este dezactivat din motive de securitate.
Bender the Greatest avatar
drapel sm
Ne pare rău, folosesc NTLMv2. Avem NTLMv1 dezactivat
Monticola Explorator avatar
drapel sa
Unde poți să-ți dai seama de asta? Mă confruntam cu aceeași problemă și [am rezolvat-o temporar setând WinRM CbtHardeningLevel la None pe server] (https://github.com/jborean93/omi/issues/29)
Bender the Greatest avatar
drapel sm
Nu. Magic a început să lucreze pe cont propriu. De atunci am început lansarea SSH pe Windows, deoarece aceasta a fost sugestia MS și ne îndepărtează de o configurare neacceptată.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.