'NSA'패치 설치 후 원격 데스크톱 '내부 오류'연결 연결

방금 최신 Windows 업데이트 (NSA 취약성 패치 화요일)를 설치했으며 이제 원격 데스크톱에 연결할 수 없습니다.

• 서버가 원격으로 호스팅됩니다. 물리적으로 접근 할 수 없습니다. 서버 2012 R1.
• 다행히도 모든 웹 사이트는 재부팅 후 정상적으로 실행됩니다.
• 조금 무서워서 두 번째 재부팅을 시도하지 않았습니다.
• 연결을 시도하면 즉시이 메시지가 나타납니다.
• " 원격 데스크톱 연결 : 내부 오류가 발생했습니다"

• 여러 클라이언트에서 시도했습니다. iOS 앱을 포함하여 모두 실패합니다. 또한 0x00000904 오류가 발생합니다.
• 실행 telnet servername 3389하면 연결이 시작되므로 포트가 열려 있음을 알 수 있습니다.
• 내 Win 10 (패치되지 않은) 컴퓨터에서 다른 서버에 제대로 연결할 수 있습니다.
• Win 10 크리에이터 에디션 인 두 번째 랩톱에서도 연결할 수 없습니다.
• 이벤트 뷰어에서 유용한 것을 찾을 수 없습니다.
• 나는 유용한 정보를 보여주지 않은 wireshark를 시도했다.
• 내가 진단해야 할 가장 좋은 것은 ASPX 페이지를 업로드하고 실행하는 기능입니다.

최근 'NSA 에디션'패치 라운드 업에 일부 RDP 수정 사항이 있음을 이해하지만 갑자기 문제가 발생한 주를 발견 한 다른 사람을 찾을 수 없습니다.

호스팅 회사에 연락하기 전에 문제가 무엇인지 알고 싶기 때문에 여기에 게시하고 있습니다.

최신 정보:

여전히 물리적 서버 액세스 권한이 없지만 서버 자체에 Windows 7 VM이 호스팅되어 있음을 기억했습니다. 10.0.0.1 로컬 IP에 연결하여 서버 인증서 스냅인을 열 수있었습니다.

이것은 RDP 인증서가 실제로 만료되었음을 보여줍니다. 연결 할 때 오류가 발생하지는 않습니다. 나는 확실히 매일 연결되어 있었고 2 개월 전에 만료 된 이래로 일종의 보안 업데이트가 원격 데스크톱 저장소에있는 다른 인증서를 제거하고 자체 갱신하지 않았다고 추측합니다.

이제 다른 인증서를 설치하는 방법을 찾으려고 노력하십시오.

업데이트 2

마지막으로 '관리 이벤트'아래의 이벤트 로그에서 VM을 통해 원격으로 연결하여이를 발견했습니다.

"터미널 서버가 SSL 연결에서 터미널 서버 인증에 사용할 새로운 자체 서명 인증서를 작성하지 못했습니다. 관련 상태 코드는 이미 존재합니다."

약간 다른 오류이지만 유용합니다. 오늘 밤 재부팅 할 수는 없지만 내일 다시 확인해야합니다.

https://blogs.technet.microsoft.com/the_9z_by_chris_davis/2014/02/20/event-id-1057-the-terminal-server-has-failed-to-create-a-new-self-signed-certificate/

해결책은 기본적으로 여기에 있습니다

https://blogs.technet.microsoft.com/askpfeplat/2017/02/01/removing-self-signed-rdp-certificates/

이것도 도움이되었습니다.

https://social.technet.microsoft.com/Forums/ie/en-US/a9c734c1-4e68-4f45-be46-8cae44c95257/unable-to-remote-desktop-to-windows-server-2012-due-to-- 작성 실패 자체 서명 인증서? forum = winserverTS

인증서> 원격 데스크톱> 인증서에 나열된 인증서가 유효하지 않은 것으로 이미 확인했다고 가정하면 ...

참고 : 모든 것을 고친 후이 스크린 샷 을 찍었 습니다. 따라서이 만료 날짜는 새로 만들어진 인증서입니다.

그런 다음 기본적으로이 파일의 이름을 바꾸거나 삭제해야합니다. 그러면 파일이 다시 만들어집니다.

"C : \ ProgramData \ Microsoft \ Crypto \ RSA \ MachineKeys \ f686aace6942fb7f7ceb231212eef4a4_a54b3870-f13c-44bb-98c7-d0511f3e1757"

이것은로 시작하는 잘 알려진 파일 이름입니다 f686aace. 그런 다음 Remote Desktop Configuration서비스를 다시 시작하면 다시 작성해야합니다. (참고 : 실제로 서비스를 다시 시작하지 않아도 될 수 있습니다. 1 분 동안 동일한 파일 이름으로 다시 작성되는지 확인하십시오.)

권한에 문제가 생길 수 있으며 파일의 소유권을 얻은 다음 권한을 적용해야 할 수도 있습니다. 참고 : 소유권은 권한을 의미하지 않습니다. 소유권을 얻은 후 권한을 추가해야합니다.

내가 말했듯이 서버에 물리적으로 액세스 할 수는 없습니다. 그렇다면 위의 것으로 충분합니다.

같은 로컬 네트워크의 다른 컴퓨터를 통해 원격으로 연결하고 레지스트리를 변경할 수있어서 운이 좋았습니다.

인증을 비활성화하고 원격으로 연결하고 액세스 할 수 있기를 원했습니다. 이를위한 레지스트리 항목은HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

기존의 키 설정 SecurityLayer과 UserAuthentication에를0

RDP 파일을 작성하고 (mstsc를 열고 서버 이름을 입력 한 후 저장을 클릭하십시오) 메모장에서 행을 enablecredsspsupport:i:0어딘가에 추가하십시오 . 보안 기대를 비활성화합니다.

그런 다음 RDP 파일을 실행하면 확실하게 연결하여 서버에 액세스 할 수 있습니다.

연결하자마자이 두 레지스트리 항목을 다시 변경 한 다음 f686...파일을 삭제 하십시오.

이 설정은 내 문제를 해결했습니다.

1. 제어판에서 관리 도구를 클릭 한 다음 로컬 보안 정책을 두 번 클릭하십시오.

로컬 보안 설정에서 로컬 정책을 확장 한 다음 보안 옵션을 클릭합니다.

오른쪽 창의 정책에서 시스템 암호화 : 암호화, 해싱 및 서명에 FIPS 호환 알고리즘 사용을 두 번 클릭 한 다음 사용을 클릭합니다. 내 경우에는 비활성화되었습니다. 그래서 방금 활성화하고 아래 나열된 명령을 발행했습니다.

4. gpupdate / force를 실행하십시오.

이 문제를 해결할 다른 옵션은 다음과 같습니다.

서버에서 프로토콜이 활성화되지 않았습니다. IIScrypto를 사용하고 TLS1.2를 활성화했으며 모든 것이 작동하기 시작했습니다.

안녕하세요, 내 환경의 모든 사람은 새로운 자체 서명 인증서가 생성되었을 때 TLS 1.0이 레지스트리에서 비활성화되었거나 레지스트리에없고 새 자체 서명 인증서가 신뢰할 수있는 루트 인증 기관 저장소에 없었을 때 발생했습니다.

레지스트리를 편집하기 전에이 두 가지 방법을 증명할 수 있습니다. IIS Crypto를 다운로드하고 프로토콜, 암호, 해시 및 키 교환에서 활성화 및 비활성화 된 내용을 확인하십시오.

때로는 IIS Crypto가 레지스트리에서 FYI 만 사용하도록 설정하지 않아도 TLS가 사용 가능함을 표시합니다.

다음 옵션은 로컬 그룹 정책에서 FIPS를 설정하여 TLS 1.0, 1.1 및 1.2를 켜고 사용하는 것입니다. FIPS를 켜고 시스템에 RDP를 시도하면 레지스트리에서 TLS가 비활성화되어 있어도 이번에는 작동합니다. 문제 해결을위한 것 일지라도 영구적으로 FIPS를 사용하지 않으려면 서버에서 사용하지 않도록 설정하고 레지스트리로 이동하십시오.

머리 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL및 프로토콜에 따라 세 가지 새로운 키 제목을 추가 그들을 TLS 1.0, TLS 1.1그리고 TLS 1.2각 TLS 항목 제목 그 아래 두 개의 서브 키 생성 Client및 Server.

내부 Client및 Server키는 두 개의 32 비트 표기 DWORD 항목 하나 생성 DisabledByDefault으로 Value0 및 설정 Enabled값을 1로 세트한다.

이 작업을 수행하고 자체 서명 된 인증서가 만료되지 않고 올바른 저장소에 있으면 서버에 다시 RDP를 사용할 수 있습니다.