InfoGrab DocsInfoGrab Docs

데스크톱 접근 문제 해결

요약

이 페이지에서는 Teleport로 원격 데스크톱을 등록할 때 발생할 수 있는 일반적인 문제와 이를 우회하거나 해결하는 방법을 설명합니다. 원격 데스크톱 접근이 올바르게 작동하려면 Teleport가 발급한 인증서가 여러 다른 구성 요소에 의해 검증되어야 합니다.

이 페이지에서는 Teleport로 원격 데스크톱을 등록할 때 발생할 수 있는 일반적인 문제와 이를 우회하거나 해결하는 방법을 설명합니다.

인증서 만료 또는 아직 유효하지 않음#

원격 데스크톱 접근이 올바르게 작동하려면 Teleport가 발급한 인증서가 여러 다른 구성 요소에 의해 검증되어야 합니다. 이 구성 요소들이 현재 시간에 대해 합의하지 않으면 Teleport가 올바르게 작동하지 못하도록 막는 인증서 검증 오류가 발생할 가능성이 높습니다.

이러한 오류는 어떤 시스템의 시스템 시계가 잘못되었는지에 따라 여러 가지 방식으로 나타날 수 있습니다.

예를 들어 Teleport가 원격 데스크톱 세션을 시작하지만, 원격 데스크톱의 로그인 화면에 다음과 유사한 오류가 표시될 수 있습니다:

The smartcard certificate used for authentication has expired. Please contact your system administrator.

또는 원격 데스크톱 연결이 수립되기 전에 Teleport Web UI에서 다음과 같은 오류를 볼 수도 있습니다:

Remote error tls expired certificate

해결 방법: 모든 시스템의 시스템 시계 확인#

이러한 문제를 해결하려면 다음 구성 요소들의 시스템 시계가 동기화되어 있는 것이 중요합니다:

  • Teleport Auth 서비스
  • Teleport 프록시 서비스
  • Teleport Windows Desktop Service
  • 대상 Windows 호스트

시스템 시계의 정확성을 유지하기 위해 이러한 시스템에서 NTP를 사용할 것을 권장합니다. systemd를 실행하는 Linux 시스템에서는 다음 명령어로 시스템 시계 설정을 확인할 수 있습니다:

$ timedatectl

다음은 올바르게 설정된 시스템의 예시입니다:

               Local time: Wed 2024-09-11 13:45:17 UTC
           Universal time: Wed 2024-09-11 13:45:17 UTC
                 RTC time: Wed 2024-09-11 13:45:17
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

이 예시에서 NTP 서비스가 active로 표시되고 시스템 시계가 동기화되어 있음을 확인할 수 있습니다. 출력이 위와 다르다면 시계 설정을 다시 구성해야 할 수 있습니다.

자동 로그인이 작동하지 않음#

스마트카드 서비스가 실행되고 있지 않음#

Teleport UI에서 Windows 호스트에 연결하면 Windows 로그인 화면에 도달하지만 아무 일도 일어나지 않습니다.

사용자 이름을 클릭하고 Sign-in options를 클릭한 다음 스마트카드 아이콘을 클릭할 수 있습니다. 오류 메시지는 다음과 같습니다: "No Valid Certificates Were Found on This Smart Card".

해결 방법: Smart Card 서비스 활성화#

일반적으로 이는 대상 호스트에서 Smart Card 서비스가 실행되고 있지 않음을 의미합니다.

먼저 그룹 정책에서 Smart Card 서비스를 활성화했는지 확인하세요.

그래도 도움이 되지 않으면 대상 호스트에 직접 로그인하여 "시작" 메뉴에서 "서비스" 프로그램을 열고 "Smart Card" 서비스가 "실행 중" 상태인지 확인하세요.

"Smart Card" 서비스가 실행되고 있지 않다면 PowerShell을 열고 gpupdate.exe /force를 실행하세요. 이렇게 하면 그룹 정책 동기화가 강제로 실행되어 서비스 변경 사항을 반영해야 합니다.

스마트카드 PIN이 감지되지 않음#

Teleport는 암호학적으로 안전한 난수 생성기를 사용하여 새 데스크톱 세션마다 스마트카드 PIN을 생성합니다. 스마트카드 인증서가 초기 로그인 외의 다른 용도로 사용되는 것을 방지하기 위해 이 PIN은 Teleport 사용자와 절대 공유되지 않습니다.

Teleport는 RDP 연결 단계에서 이 PIN을 데스크톱에 제공합니다. 그룹 정책이 데스크톱이 이 PIN을 확인하지 못하도록 막으면, 스마트카드가 감지되었더라도 사용자는 로그인 화면에 머물게 됩니다.

해결 방법: 그룹 정책이 자격 증명 지정을 허용하는지 확인#

스마트카드 PIN은 초기 RDP 연결 시퀀스의 비밀번호 필드를 사용하여 대상 호스트로 전송됩니다.

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host를 확장하세요.

Remote Desktop Session Host 아래에서 Security를 선택하세요.

Always prompt for password upon connection을 마우스 오른쪽 버튼으로 클릭하고 Edit를 선택한 다음 Disabled를 선택하고 OK를 클릭하세요.

참고: 이 정책 이름에 비밀번호가 언급되어 있지만, 실제로 통신선상에는 비밀번호가 전송되지 않습니다. 이 메커니즘은 스마트카드 PIN을 전송하는 용도로만 사용됩니다.

서드파티 스마트카드 드라이버가 자동 로그인을 방해함#

HID ActivID ActivClient와 같은 일부 서드파티 스마트카드 드라이버는 자동 로그인 프로세스가 올바르게 작동하는 것을 방해할 수 있습니다. 서드파티 드라이버의 존재 여부를 확인하려면, 자동 로그인이 작동하지 않는 호스트에 연결하여 Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\Identity Device (NIST SP 800-73 [PIV]) 항목의 내용을 확인하세요.

올바르게 구성된 시스템에서는 기본 Windows 드라이버를 가리키는 DLL 항목이 표시될 것으로 예상됩니다: C:\Windows\System32\msclmd.dll. 사용자 지정 드라이버가 설치된 시스템에서는 일반적으로 이 경로가 C:\Program Files 아래의 DLL을 가리키도록 재정의된 것을 볼 수 있습니다.

해결 방법: 로그온 프로세스를 방해할 수 있는 서드파티 스마트카드 도구를 비활성화하거나 제거하세요.#

제거를 완료한 후 위에서 언급한 레지스트리 항목이 msclmd.dll을 가리키는지 확인하세요.

계정에 스마트카드가 지원되지 않음#

Windows 호스트에 연결하면 다음과 같은 오류 메시지가 표시됩니다: "Signing in with a smart card isn't supported for your account." 또는 이와 유사한 메시지입니다.

해결 방법: Windows 호스트의 Security-Kerberos 로그에서 원인 검토#

Security-Kerberos Windows 이벤트 로그는 스마트카드 기반 인증 시도에 대한 정보를 제공합니다. 이 이벤트 로그는 기본적으로 활성화되어 있지 않습니다.

Windows 이벤트 로그를 열고 Event Viewer > Application and Services Logs > Microsoft > Windows > Security-Kerberos > Operational로 이동하세요. 이 이벤트 로그를 활성화하고 Teleport로 연결을 시도하여 로그 항목을 검토하세요.

이는 종종 도메인 컨트롤러의 KDC 인증서가 스마트카드 로그온 요구 사항을 충족하지 못하기 때문에 발생하는 문제입니다.

  • KDC 인증서가 (AD CS를 사용하는 경우) "Domain Controller" 기본 제공 템플릿으로 발급되었거나, Kerberos Authentication EKU (1.3.6.1.5.2.3.5)를 포함하고 있는지 확인하세요
  • KDC 인증서를 발급한 CA 인증서가 도메인 컨트롤러의 NTAuth 저장소에도 존재하는지 확인하세요.

자격 증명을 확인할 수 없음#

Teleport UI에서 Windows 호스트에 연결하면 Windows 로그인 화면에 도달하고 다음과 같은 오류 메시지가 표시됩니다: Your credentials could not be verified.

이는 Teleport가 제시한 스마트카드 인증서를 도메인 컨트롤러가 검증할 수 없음을 의미합니다.

해결 방법: 도메인 컨트롤러의 CAPI2 로그 검토#

Microsoft Crypto API (CAPI) 서비스 로그에는 도메인 컨트롤러가 수행하는 인증서 검사에 대한 정보가 포함되어 있습니다. 이 이벤트 로그는 기본적으로 활성화되어 있지 않습니다.

Windows 이벤트 로그를 열고 Event Viewer > Application and Services Logs > Microsoft > Windows > CAPI2 > Operational로 이동하세요. 이 이벤트 로그를 활성화하고 Teleport로 연결을 시도하여 로그 항목을 검토하세요.

참고: CAPI2 로그는 매우 상세할 수 있습니다. 최대 로그 크기를 최소 4MB로 늘리고, 문제 해결을 완료한 후에는 로그를 비활성화할 것을 권장합니다.

로그를 검토하면서 오류 상태이고 작업 범주가 "Build Chain"인 이벤트를 찾으세요. 세부 정보 섹션에는 로그온에 실패한 사용자 이름이 포함됩니다. 로그인에 실패한 사용자에 해당하는 이벤트를 찾으면 체인 요소를 순서대로 살펴보고 실패 원인을 파악하세요. 여기서 발생할 수 있는 실패 원인으로는 폐기된 인증서, 신뢰할 수 있는 루트로 체인되지 않는 인증서, 또는 인증서 폐기 확인 실패 등이 있습니다.

스마트카드 인증서가 신뢰되지 않음#

Teleport UI에서 Windows 호스트에 연결하면 Windows 로그인 화면에 도달하고 다음과 같은 오류 메시지가 표시됩니다: "The smartcard certificate used for authentication was not trusted" (또는 유사한 메시지).

해결 방법: Teleport CA 가져오기#

이는 호스트가 Teleport CA를 신뢰하지 않음을 의미합니다.

먼저 Teleport CA를 그룹 정책으로 가져왔는지 확인하세요. 마지막으로 가져온 이후 Teleport CA를 회전시킨 경우, 다음 명령어를 사용하여 새 CA를 가져와야 합니다. 이때 teleport.example.com를 사용 중인 Teleport 클러스터의 주소로 바꾸세요:

$ curl.exe -fo teleport.cer https://teleport.example.com/webapi/auth/export?type=windows

그래도 도움이 되지 않으면 대상 호스트에 직접 로그인하여 PowerShell을 열고 gpupdate.exe /force를 실행하세요. 이렇게 하면 그룹 정책 업데이트가 강제로 실행되어 새 CA를 반영해야 합니다.

Note

Teleport v18.7.0은 Windows Desktop Access 인증서 발급을 위한 Windows CA를 도입했습니다. 그 이전에는 user CA가 사용되었습니다.

v18.7.0(또는 그 이상)으로 업데이트된 클러스터는 user CA를 Windows CA로 자동 복제하므로, Windows CA가 순환(rotate)되기 전까지는 기존 신뢰 관계가 유지됩니다.

새 세션이 "멈춤"#

호스트에 도달할 수 없음#

Teleport Web UI에서 Windows 호스트의 Connect를 클릭하면 새 탭이 열리지만 상단 바 외에는 아무것도 표시되지 않습니다. 잠시 후 연결 실패에 대한 오류가 표시됩니다. 대부분의 경우 이 오류는 windows_desktop_service가 대상 Windows 호스트에 도달할 수 없을 때 발생합니다.

해결 방법: 인바운드 RDP 트래픽을 허용하도록 방화벽 규칙 수정#

먼저 RDP 포트를 열고, Teleport 연결용으로 구성한 그룹 정책 객체에서 원격 데스크톱 연결을 허용하도록 설정했는지 확인하세요.

그래도 도움이 되지 않으면 대상 호스트가 온라인 상태인지 확인하고, windows_desktop_service를 실행하는 Linux 서버에서 해당 호스트로 ping을 시도해 보세요. 호스트가 온라인 상태이지만 도달할 수 없다면, 인프라에 특정한 다른 네트워킹 장벽이 있는 것입니다.

호스트 이름이 확인되지 않음#

Windows Desktop에 대한 연결이 연결 수립 중에 멈추거나, Teleport 디버그 로그에 다음과 같은 형태의 오류가 표시됩니다: couldn't resolve winserver.example.com.

해결 방법: 방화벽이 DNS 트래픽을 허용하는지 확인#

LDAP를 통해 자동으로 검색되는 데스크톱의 경우, Teleport는 호스트 이름을 IP 주소로 확인하기 위해 LDAP 서버에 대해 DNS 쿼리를 수행합니다.

Teleport의 Windows Desktop Service를 실행하는 인스턴스에서 LDAP 서버 (Active Directory 도메인 컨트롤러)로 향하는 포트 53의 인바운드 DNS 트래픽을 방화벽이 허용하는지 확인하세요.

Teleport가 시작되지 않음#

잘못된 도메인#

Teleport가 다음과 유사한 오류와 함께 시작에 실패합니다:

LDAP Result Code 10 "Referral": 0000202B: RefErr: DSID-0310082F, data 0, 1 access points
"\tref 1: 'xample.com'"
"\x00"

해결 방법: 도메인 수정#

이는 도메인 이름이 잘못되었을 가능성이 높음을 의미합니다. windows_desktop_serviceldap 섹션에 있는 domain 필드를 다시 확인하세요.

도메인 컨트롤러에 도달할 수 없음#

Teleport가 다음과 유사한 오류와 함께 시작에 실패합니다:

LDAP Result Code 200 "Network Error": dial tcp ad.example.com:636: i/o timeout

해결 방법: LDAP 주소 확인#

이는 도메인 컨트롤러가 다운되었거나 도달할 수 없음을 의미합니다. windows_desktop_serviceldap 섹션에 있는 addr 필드를 다시 확인하세요. 필드 값이 올바르다면, windows_desktop_service를 실행하는 서버에서 도메인 컨트롤러가 작동 중이고 도달 가능한지 확인하세요.

TLS를 통한 LDAP를 초기화할 수 없음#

Teleport가 시작 시 LDAP에 연결하지 못합니다. 다음과 유사한 오류가 표시될 수 있습니다:

LDAP Result Code 52 "Unavailable": 00000000: LdapErr: DSID-0C090F78, comment: Error initializing SSL/TLS, data 0, v2580\x00

또는

connecting to LDAP server: unable to read LDAP response packet: read tcp 172.18.0.5:35970->;172.18.0.4:636: read: connection reset by peer

해결 방법: LDAPS 활성화#

이는 LDAP 서버에 LDAP 인증서가 설치되어 있지 않거나, 포트 389에서 안전하지 않은 연결을 시도하고 있음을 의미합니다. Teleport는 일반적으로 포트 636에서 이루어지는 안전한 LDAPS 연결을 필요로 합니다. 먼저 올바른 LDAPS 포트에 연결하고 있는지 확인하세요. 그래도 문제가 해결되지 않으면 Active Directory Certificate Services (AD CS)를 설치하거나 서드파티 인증서를 가져올 수 있습니다. Active Directory는 매우 까다롭기 때문에 인증서를 올바르게 생성하도록 주의하세요.

LDAP 바인드 실패#

Teleport는 여러 목적으로 LDAP를 사용합니다:

  1. Active Directory 도메인에서 Windows 호스트를 (선택적으로) 검색하기 위해
  2. RDP 세션을 시작하기 전에 Windows 사용자의 SID를 조회하기 위해
  3. Teleport CRL을 도메인에 주기적으로 게시하기 위해

Teleport는 자체 발급한 클라이언트 인증서를 사용하여 LDAP 서버에 인증합니다. 이 상호 TLS 연결이 실패하면 다음과 유사한 오류가 표시됩니다:

ERROR: the LDAP server did not accept Teleport's client certificate, has the Teleport CA been imported correctly?,
LDAP Result Code 1 "Operations Error": 000004DC: LdapErr: DSID-0C090CE5,
  comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563

해결 방법 1: Teleport 인증서가 설치되어 있는지 확인#

Teleport Desktop Service는 Teleport가 발급한 인증서를 사용하여 LDAP 서버와 인증합니다. 이 오류는 Teleport가 인증할 수 없을 때 발생하며, 대개 Teleport의 인증 기관이 Active Directory에 의해 신뢰되지 않기 때문입니다.

먼저 Teleport CA가 LDAP NTAuth 저장소에 존재하는지 확인하세요. 다음 명령어를 실행하되, 사용 중인 도메인에 맞게 DN을 수정하세요(이 명령어에서는 example.com 도메인을 사용합니다):

$ certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com?caCertificate"

Teleport CA 인증서를 보여주는 팝업 창이 표시되어야 합니다. Teleport 인증서가 존재하지 않으면 다음 명령어로 가져오세요:

$ certutil -dspublish -f <path-to-cert> NTAuthCA

Teleport 인증서가 LDAP에 존재함을 확인했다면, 이것이 모든 데스크톱에 전파되었는지 확인해야 합니다. 연결하려는 데스크톱에서 다음 명령어를 실행하세요:

$ certutil -viewstore -enterprise NTAuth

팝업 창에 Teleport 인증서가 표시되지 않고 LDAP에는 존재했다면, 다음 명령어로 데스크톱이 강제로 동기화되도록 할 수 있습니다:

$ certutil -pulse

해결 방법 2: 충돌하는 도구 확인#

Teleport CA 인증서가 올바르게 설치되어 있음을 확인했는데도 이 오류가 계속 발생한다면, mTLS 연결을 방해할 수 있는 보안 도구나 애드온이 있는지 확인하세요. CrowdStrike의 LDAP 검사 도구나 Silverfort의 AD 어댑터와 같은 도구는 TLS를 종료시키고 클라이언트 인증서를 드롭하는 것으로 알려져 있으며, 이는 Teleport의 인증을 방해합니다.

해결 방법 3: LDAP 서비스 계정에 대한 SID를 지정했는지 확인#

Microsoft의 2025년 2월 보안 업데이트는 모든 도메인 컨트롤러를 인증서 매핑에 대한 *완전 적용 모드(full enforcement mode)*로 전환합니다. 이는 Windows가 Teleport 클라이언트 인증서를 허용하려면 인증서가 발급 대상 사용자의 SID를 포함해야 함을 의미합니다.

이를 해결하려면 windows_desktop_service의 구성 파일에서 SID를 설정했는지 확인하세요:

windows_desktop_service:
  enabled: true
  ldap:
    username: 'MYDOMAIN\svc-teleport'
    sid: S-1-5-21-...

사용자의 SID를 조회하려면 다음 PowerShell 명령어를 사용하세요:

$ Get-AdUser -Identity $USERNAME | Select SID

또한 Teleport가 사용하는 서비스 계정이 활성화되어 있고 잠기지 않았는지도 확인해야 합니다. 정책에서 계정이 먼저 비밀번호 재설정을 수행하도록 요구하는 경우 이런 문제가 발생하기도 합니다.

해결 방법 4: 시계 드리프트 확인#

(Teleport 측이든 Windows 환경이든) 잘못된 시스템 시계는 한쪽 또는 양쪽 모두가 상대방의 인증서를 수락하지 못하는 결과를 초래할 수 있습니다.

시스템 시계가 정확한지 확인하세요. 시간이 지나면서 시계가 드리프트되지 않도록 NTP를 구성할 것을 권장합니다.

클라이언트 인증서 수동 검증#

또 다른 유용한 문제 해결 단계는 tctl을 사용하여 클라이언트 인증서를 발급하고 Windows 측에서 이를 검증해 보는 것입니다.

먼저 tctl로 클라이언트 인증서를 생성하되, --windows-user, --windows-sid, --windows-domain 플래그를 사용 환경에 맞는 값으로 반드시 바꾸세요:

# NOTE: To issue Windows certificates, you must run 'tctl auth sign' locally
# on the same machine as the Teleport auth_service. Running this command remotely
# with an identity issued by 'tsh' will result in 'ERROR: access denied'
$ tctl auth sign \
    --windows-user=svc-teleport \
    --windows-sid=S-1-5-21-3788279871-1068139173-3054872986-500 \
    --windows-domain=domain.example.com \
    --format=windows \
    --out=test

이렇게 하면 test.svc-teleport.der라는 이름의 인증서 파일이 생성됩니다.

다음으로, 이 인증서를 도메인 컨트롤러 중 하나에 복사하고 검증을 시도하세요:

$ certutil -urlfetch -verify test.svc-teleport.der

검증에 성공하면 다음과 유사한 출력으로 끝나야 합니다:

------------------------------------
Verified Application Policies:
    1.3.6.1.5.5.7.3.2 Client Authentication
    1.3.6.1.4.1.311.20.2.2 Smart Card Logon
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

비슷한 결과가 표시되지 않으면 출력에서 인증서를 검증할 수 없는 이유를 나타내는 오류를 찾아보세요.

연결 시도 실패#

RDP 서버가 표준 RDP 보안만 사용함#

데스크톱에 연결을 시도하면 다음과 유사한 오류와 함께 실패합니다

client advertised SSL, but server selected STANDARD_RDP_SECURITY

해결 방법: 강화된 RDP 보안 활성화#

표준 RDP 보안(Standard RDP Security)은 RC4 암호화를 기반으로 하며, RDP를 통해 Windows 호스트에 연결하는 가장 안전하지 않은 방식입니다. Teleport의 RDP 클라이언트는 TLS를 사용하는 강화된 RDP 보안을 요구합니다.

강화된 RDP 보안은 일반적으로 기본적으로 활성화되어 있지만, 사용 환경이 레거시 보안 방식을 요구하도록 구성되어 있을 수 있습니다.

이 구성은 다음 그룹 정책에서 사용할 수 있습니다:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security

"Require use of a specific security layer for remote (RDP) connections" 설정을 찾으세요. 이 설정은 RDP가 아니라 Negotiate 또는 SSL로 설정되어 있어야 합니다.

RDP 연결 실패#

Teleport Web UI에서 Windows 호스트의 Connect를 클릭하면 새 탭이 열리지만 상단 바 외에는 아무것도 표시되지 않습니다. RDP 연결 실패를 언급하는 오류가 표시됩니다. 다음과 유사한 오류도 볼 수 있습니다:

Rdp(Io(Os { code: 54, kind: ConnectionReset, message: "Connection reset by peer" }))

해결 방법: Windows 호스트가 안전한 암호 그룹을 사용하는지 확인#

대상 호스트가 강제로 연결을 재설정하는 경우, 이는 일반적으로 데스크톱이 TLS 연결에 대한 안전한 암호 그룹(cipher suite)을 지원하지 않음을 의미합니다. 이 문제는 최신 버전의 Windows에서는 덜 발생하지만, Windows Server 2012R2와 같은 이전 버전에서는 자주 관찰됩니다.

RDP 연결용 인증서를 구성하여 호스트가 안전한 암호 그룹을 사용하도록 강제할 수 있습니다.

CredSSP를 사용한 강화된 RDP 보안이 필요함#

데스크톱에 연결을 시도하면 실패하고 로그에 다음과 유사한 오류가 표시됩니다:

Error during negotiation step: the server requires that the client support enhanced RDP security with CredSSP

해결 방법: NLA(네트워크 수준 인증) 비활성화#

이는 RDP 서버가 NLA를 요구하고 있음을 의미합니다. 이 오류를 해결하려면 서버가 NLA를 요구하지 않도록 구성하거나, Teleport 16.2.0 이상을 실행 중이라면 NLA를 활성화할 수 있습니다.

서버가 NLA를 요구하지 않도록 구성하려면, Teleport 연결용으로 구성한 그룹 정책 객체에서 원격 데스크톱 연결을 허용하는 지침을 따르세요. Active Directory에서 NLA를 비활성화한 후에도 이 오류가 계속 발생한다면, 관리자 권한으로 Windows 명령 프롬프트에서 다음 명령어를 실행하여 정책 업데이트를 강제 실행하세요:

$ gpupdate.exe /force

NLA를 활성화하려면 Teleport의 windows_desktop_service를 실행하는 호스트에서 TELEPORT_ENABLE_RDP_NLA 환경 변수를 yes로 설정하세요. Teleport의 NLA 지원에 대한 자세한 정보는 Active Directory 가이드에서 확인할 수 있습니다.

CredSSP: Kerberos 데이터베이스에서 서버를 찾을 수 없음#

데스크톱에 연결을 시도하면 실패하고 UI에 다음과 유사한 오류가 표시됩니다:

CredSSP UnknownCredentials: server not found in Kerberos database

이는 NLA와 관련된 오류입니다. NLA를 사용하여 Windows 호스트에 연결하려면 Teleport가 Active Directory에 존재하는 그대로의 컴퓨터 이름을 지정해야 합니다. 올바른 컴퓨터 이름을 지정하지 않았거나 호스트 이름 대신 IP 주소로 연결하는 경우 이 오류가 표시됩니다.

해결 방법: 서버의 컴퓨터 이름 수정#

이 오류를 해결하려면 다음 중 하나를 확인하세요:

  • 서버의 컴퓨터 이름이 teleport.dev/computer_name 라벨에 지정되어 있는지
  • 서버의 addr 필드가 올바른 컴퓨터 이름을 지정하고 있는지

자세한 내용은 Computer Name을 참조하세요.

디렉터리 공유#

디렉터리 공유 실패#

디렉터리를 공유하려는 시도가 실패하고 다음과 같은 경고가 표시됩니다:

Failed to share directory, drive redirection may be disabled on the RDP server.

해결 방법: 장치 리디렉션이 활성화되어 있는지 확인#

Teleport의 디렉터리 공유 기능은 RDP 장치 리디렉션을 활용합니다. 장치 리디렉션이 RDP 서버에서 활성화되어 있지 않거나 허용되지 않으면 작업이 실패합니다.

장치 리디렉션은 일반적으로 기본적으로 활성화되어 있지만 그룹 정책에서 비활성화되어 있을 수 있습니다. 관련 설정은 Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection 아래에 있습니다.

Do not allow drive redirection 옵션이 설정되지 않았거나 비활성화되어 있는지 확인하세요.

데스크톱 접근 문제 해결

Teleport v18.9
원문 보기
요약

이 페이지에서는 Teleport로 원격 데스크톱을 등록할 때 발생할 수 있는 일반적인 문제와 이를 우회하거나 해결하는 방법을 설명합니다. 원격 데스크톱 접근이 올바르게 작동하려면 Teleport가 발급한 인증서가 여러 다른 구성 요소에 의해 검증되어야 합니다.

이 페이지에서는 Teleport로 원격 데스크톱을 등록할 때 발생할 수 있는 일반적인 문제와 이를 우회하거나 해결하는 방법을 설명합니다.

인증서 만료 또는 아직 유효하지 않음#

원격 데스크톱 접근이 올바르게 작동하려면 Teleport가 발급한 인증서가 여러 다른 구성 요소에 의해 검증되어야 합니다. 이 구성 요소들이 현재 시간에 대해 합의하지 않으면 Teleport가 올바르게 작동하지 못하도록 막는 인증서 검증 오류가 발생할 가능성이 높습니다.

이러한 오류는 어떤 시스템의 시스템 시계가 잘못되었는지에 따라 여러 가지 방식으로 나타날 수 있습니다.

예를 들어 Teleport가 원격 데스크톱 세션을 시작하지만, 원격 데스크톱의 로그인 화면에 다음과 유사한 오류가 표시될 수 있습니다:

The smartcard certificate used for authentication has expired. Please contact your system administrator.

또는 원격 데스크톱 연결이 수립되기 전에 Teleport Web UI에서 다음과 같은 오류를 볼 수도 있습니다:

Remote error tls expired certificate

해결 방법: 모든 시스템의 시스템 시계 확인#

이러한 문제를 해결하려면 다음 구성 요소들의 시스템 시계가 동기화되어 있는 것이 중요합니다:

  • Teleport Auth 서비스
  • Teleport 프록시 서비스
  • Teleport Windows Desktop Service
  • 대상 Windows 호스트

시스템 시계의 정확성을 유지하기 위해 이러한 시스템에서 NTP를 사용할 것을 권장합니다. systemd를 실행하는 Linux 시스템에서는 다음 명령어로 시스템 시계 설정을 확인할 수 있습니다:

$ timedatectl

다음은 올바르게 설정된 시스템의 예시입니다:

               Local time: Wed 2024-09-11 13:45:17 UTC
           Universal time: Wed 2024-09-11 13:45:17 UTC
                 RTC time: Wed 2024-09-11 13:45:17
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

이 예시에서 NTP 서비스가 active로 표시되고 시스템 시계가 동기화되어 있음을 확인할 수 있습니다. 출력이 위와 다르다면 시계 설정을 다시 구성해야 할 수 있습니다.

자동 로그인이 작동하지 않음#

스마트카드 서비스가 실행되고 있지 않음#

Teleport UI에서 Windows 호스트에 연결하면 Windows 로그인 화면에 도달하지만 아무 일도 일어나지 않습니다.

사용자 이름을 클릭하고 Sign-in options를 클릭한 다음 스마트카드 아이콘을 클릭할 수 있습니다. 오류 메시지는 다음과 같습니다: "No Valid Certificates Were Found on This Smart Card".

해결 방법: Smart Card 서비스 활성화#

일반적으로 이는 대상 호스트에서 Smart Card 서비스가 실행되고 있지 않음을 의미합니다.

먼저 그룹 정책에서 Smart Card 서비스를 활성화했는지 확인하세요.

그래도 도움이 되지 않으면 대상 호스트에 직접 로그인하여 "시작" 메뉴에서 "서비스" 프로그램을 열고 "Smart Card" 서비스가 "실행 중" 상태인지 확인하세요.

"Smart Card" 서비스가 실행되고 있지 않다면 PowerShell을 열고 gpupdate.exe /force를 실행하세요. 이렇게 하면 그룹 정책 동기화가 강제로 실행되어 서비스 변경 사항을 반영해야 합니다.

스마트카드 PIN이 감지되지 않음#

Teleport는 암호학적으로 안전한 난수 생성기를 사용하여 새 데스크톱 세션마다 스마트카드 PIN을 생성합니다. 스마트카드 인증서가 초기 로그인 외의 다른 용도로 사용되는 것을 방지하기 위해 이 PIN은 Teleport 사용자와 절대 공유되지 않습니다.

Teleport는 RDP 연결 단계에서 이 PIN을 데스크톱에 제공합니다. 그룹 정책이 데스크톱이 이 PIN을 확인하지 못하도록 막으면, 스마트카드가 감지되었더라도 사용자는 로그인 화면에 머물게 됩니다.

해결 방법: 그룹 정책이 자격 증명 지정을 허용하는지 확인#

스마트카드 PIN은 초기 RDP 연결 시퀀스의 비밀번호 필드를 사용하여 대상 호스트로 전송됩니다.

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host를 확장하세요.

Remote Desktop Session Host 아래에서 Security를 선택하세요.

Always prompt for password upon connection을 마우스 오른쪽 버튼으로 클릭하고 Edit를 선택한 다음 Disabled를 선택하고 OK를 클릭하세요.

참고: 이 정책 이름에 비밀번호가 언급되어 있지만, 실제로 통신선상에는 비밀번호가 전송되지 않습니다. 이 메커니즘은 스마트카드 PIN을 전송하는 용도로만 사용됩니다.

서드파티 스마트카드 드라이버가 자동 로그인을 방해함#

HID ActivID ActivClient와 같은 일부 서드파티 스마트카드 드라이버는 자동 로그인 프로세스가 올바르게 작동하는 것을 방해할 수 있습니다. 서드파티 드라이버의 존재 여부를 확인하려면, 자동 로그인이 작동하지 않는 호스트에 연결하여 Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards\Identity Device (NIST SP 800-73 [PIV]) 항목의 내용을 확인하세요.

올바르게 구성된 시스템에서는 기본 Windows 드라이버를 가리키는 DLL 항목이 표시될 것으로 예상됩니다: C:\Windows\System32\msclmd.dll. 사용자 지정 드라이버가 설치된 시스템에서는 일반적으로 이 경로가 C:\Program Files 아래의 DLL을 가리키도록 재정의된 것을 볼 수 있습니다.

해결 방법: 로그온 프로세스를 방해할 수 있는 서드파티 스마트카드 도구를 비활성화하거나 제거하세요.#

제거를 완료한 후 위에서 언급한 레지스트리 항목이 msclmd.dll을 가리키는지 확인하세요.

계정에 스마트카드가 지원되지 않음#

Windows 호스트에 연결하면 다음과 같은 오류 메시지가 표시됩니다: "Signing in with a smart card isn't supported for your account." 또는 이와 유사한 메시지입니다.

해결 방법: Windows 호스트의 Security-Kerberos 로그에서 원인 검토#

Security-Kerberos Windows 이벤트 로그는 스마트카드 기반 인증 시도에 대한 정보를 제공합니다. 이 이벤트 로그는 기본적으로 활성화되어 있지 않습니다.

Windows 이벤트 로그를 열고 Event Viewer > Application and Services Logs > Microsoft > Windows > Security-Kerberos > Operational로 이동하세요. 이 이벤트 로그를 활성화하고 Teleport로 연결을 시도하여 로그 항목을 검토하세요.

이는 종종 도메인 컨트롤러의 KDC 인증서가 스마트카드 로그온 요구 사항을 충족하지 못하기 때문에 발생하는 문제입니다.

  • KDC 인증서가 (AD CS를 사용하는 경우) "Domain Controller" 기본 제공 템플릿으로 발급되었거나, Kerberos Authentication EKU (1.3.6.1.5.2.3.5)를 포함하고 있는지 확인하세요
  • KDC 인증서를 발급한 CA 인증서가 도메인 컨트롤러의 NTAuth 저장소에도 존재하는지 확인하세요.

자격 증명을 확인할 수 없음#

Teleport UI에서 Windows 호스트에 연결하면 Windows 로그인 화면에 도달하고 다음과 같은 오류 메시지가 표시됩니다: Your credentials could not be verified.

이는 Teleport가 제시한 스마트카드 인증서를 도메인 컨트롤러가 검증할 수 없음을 의미합니다.

해결 방법: 도메인 컨트롤러의 CAPI2 로그 검토#

Microsoft Crypto API (CAPI) 서비스 로그에는 도메인 컨트롤러가 수행하는 인증서 검사에 대한 정보가 포함되어 있습니다. 이 이벤트 로그는 기본적으로 활성화되어 있지 않습니다.

Windows 이벤트 로그를 열고 Event Viewer > Application and Services Logs > Microsoft > Windows > CAPI2 > Operational로 이동하세요. 이 이벤트 로그를 활성화하고 Teleport로 연결을 시도하여 로그 항목을 검토하세요.

참고: CAPI2 로그는 매우 상세할 수 있습니다. 최대 로그 크기를 최소 4MB로 늘리고, 문제 해결을 완료한 후에는 로그를 비활성화할 것을 권장합니다.

로그를 검토하면서 오류 상태이고 작업 범주가 "Build Chain"인 이벤트를 찾으세요. 세부 정보 섹션에는 로그온에 실패한 사용자 이름이 포함됩니다. 로그인에 실패한 사용자에 해당하는 이벤트를 찾으면 체인 요소를 순서대로 살펴보고 실패 원인을 파악하세요. 여기서 발생할 수 있는 실패 원인으로는 폐기된 인증서, 신뢰할 수 있는 루트로 체인되지 않는 인증서, 또는 인증서 폐기 확인 실패 등이 있습니다.

스마트카드 인증서가 신뢰되지 않음#

Teleport UI에서 Windows 호스트에 연결하면 Windows 로그인 화면에 도달하고 다음과 같은 오류 메시지가 표시됩니다: "The smartcard certificate used for authentication was not trusted" (또는 유사한 메시지).

해결 방법: Teleport CA 가져오기#

이는 호스트가 Teleport CA를 신뢰하지 않음을 의미합니다.

먼저 Teleport CA를 그룹 정책으로 가져왔는지 확인하세요. 마지막으로 가져온 이후 Teleport CA를 회전시킨 경우, 다음 명령어를 사용하여 새 CA를 가져와야 합니다. 이때 teleport.example.com를 사용 중인 Teleport 클러스터의 주소로 바꾸세요:

$ curl.exe -fo teleport.cer https://teleport.example.com/webapi/auth/export?type=windows

그래도 도움이 되지 않으면 대상 호스트에 직접 로그인하여 PowerShell을 열고 gpupdate.exe /force를 실행하세요. 이렇게 하면 그룹 정책 업데이트가 강제로 실행되어 새 CA를 반영해야 합니다.

Note

Teleport v18.7.0은 Windows Desktop Access 인증서 발급을 위한 Windows CA를 도입했습니다. 그 이전에는 user CA가 사용되었습니다.

v18.7.0(또는 그 이상)으로 업데이트된 클러스터는 user CA를 Windows CA로 자동 복제하므로, Windows CA가 순환(rotate)되기 전까지는 기존 신뢰 관계가 유지됩니다.

새 세션이 "멈춤"#

호스트에 도달할 수 없음#

Teleport Web UI에서 Windows 호스트의 Connect를 클릭하면 새 탭이 열리지만 상단 바 외에는 아무것도 표시되지 않습니다. 잠시 후 연결 실패에 대한 오류가 표시됩니다. 대부분의 경우 이 오류는 windows_desktop_service가 대상 Windows 호스트에 도달할 수 없을 때 발생합니다.

해결 방법: 인바운드 RDP 트래픽을 허용하도록 방화벽 규칙 수정#

먼저 RDP 포트를 열고, Teleport 연결용으로 구성한 그룹 정책 객체에서 원격 데스크톱 연결을 허용하도록 설정했는지 확인하세요.

그래도 도움이 되지 않으면 대상 호스트가 온라인 상태인지 확인하고, windows_desktop_service를 실행하는 Linux 서버에서 해당 호스트로 ping을 시도해 보세요. 호스트가 온라인 상태이지만 도달할 수 없다면, 인프라에 특정한 다른 네트워킹 장벽이 있는 것입니다.

호스트 이름이 확인되지 않음#

Windows Desktop에 대한 연결이 연결 수립 중에 멈추거나, Teleport 디버그 로그에 다음과 같은 형태의 오류가 표시됩니다: couldn't resolve winserver.example.com.

해결 방법: 방화벽이 DNS 트래픽을 허용하는지 확인#

LDAP를 통해 자동으로 검색되는 데스크톱의 경우, Teleport는 호스트 이름을 IP 주소로 확인하기 위해 LDAP 서버에 대해 DNS 쿼리를 수행합니다.

Teleport의 Windows Desktop Service를 실행하는 인스턴스에서 LDAP 서버 (Active Directory 도메인 컨트롤러)로 향하는 포트 53의 인바운드 DNS 트래픽을 방화벽이 허용하는지 확인하세요.

Teleport가 시작되지 않음#

잘못된 도메인#

Teleport가 다음과 유사한 오류와 함께 시작에 실패합니다:

LDAP Result Code 10 "Referral": 0000202B: RefErr: DSID-0310082F, data 0, 1 access points
"\tref 1: 'xample.com'"
"\x00"

해결 방법: 도메인 수정#

이는 도메인 이름이 잘못되었을 가능성이 높음을 의미합니다. windows_desktop_serviceldap 섹션에 있는 domain 필드를 다시 확인하세요.

도메인 컨트롤러에 도달할 수 없음#

Teleport가 다음과 유사한 오류와 함께 시작에 실패합니다:

LDAP Result Code 200 "Network Error": dial tcp ad.example.com:636: i/o timeout

해결 방법: LDAP 주소 확인#

이는 도메인 컨트롤러가 다운되었거나 도달할 수 없음을 의미합니다. windows_desktop_serviceldap 섹션에 있는 addr 필드를 다시 확인하세요. 필드 값이 올바르다면, windows_desktop_service를 실행하는 서버에서 도메인 컨트롤러가 작동 중이고 도달 가능한지 확인하세요.

TLS를 통한 LDAP를 초기화할 수 없음#

Teleport가 시작 시 LDAP에 연결하지 못합니다. 다음과 유사한 오류가 표시될 수 있습니다:

LDAP Result Code 52 "Unavailable": 00000000: LdapErr: DSID-0C090F78, comment: Error initializing SSL/TLS, data 0, v2580\x00

또는

connecting to LDAP server: unable to read LDAP response packet: read tcp 172.18.0.5:35970->;172.18.0.4:636: read: connection reset by peer

해결 방법: LDAPS 활성화#

이는 LDAP 서버에 LDAP 인증서가 설치되어 있지 않거나, 포트 389에서 안전하지 않은 연결을 시도하고 있음을 의미합니다. Teleport는 일반적으로 포트 636에서 이루어지는 안전한 LDAPS 연결을 필요로 합니다. 먼저 올바른 LDAPS 포트에 연결하고 있는지 확인하세요. 그래도 문제가 해결되지 않으면 Active Directory Certificate Services (AD CS)를 설치하거나 서드파티 인증서를 가져올 수 있습니다. Active Directory는 매우 까다롭기 때문에 인증서를 올바르게 생성하도록 주의하세요.

LDAP 바인드 실패#

Teleport는 여러 목적으로 LDAP를 사용합니다:

  1. Active Directory 도메인에서 Windows 호스트를 (선택적으로) 검색하기 위해
  2. RDP 세션을 시작하기 전에 Windows 사용자의 SID를 조회하기 위해
  3. Teleport CRL을 도메인에 주기적으로 게시하기 위해

Teleport는 자체 발급한 클라이언트 인증서를 사용하여 LDAP 서버에 인증합니다. 이 상호 TLS 연결이 실패하면 다음과 유사한 오류가 표시됩니다:

ERROR: the LDAP server did not accept Teleport's client certificate, has the Teleport CA been imported correctly?,
LDAP Result Code 1 &#34;Operations Error&#34;: 000004DC: LdapErr: DSID-0C090CE5,
  comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v4563

해결 방법 1: Teleport 인증서가 설치되어 있는지 확인#

Teleport Desktop Service는 Teleport가 발급한 인증서를 사용하여 LDAP 서버와 인증합니다. 이 오류는 Teleport가 인증할 수 없을 때 발생하며, 대개 Teleport의 인증 기관이 Active Directory에 의해 신뢰되지 않기 때문입니다.

먼저 Teleport CA가 LDAP NTAuth 저장소에 존재하는지 확인하세요. 다음 명령어를 실행하되, 사용 중인 도메인에 맞게 DN을 수정하세요(이 명령어에서는 example.com 도메인을 사용합니다):

$ certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com?caCertificate"

Teleport CA 인증서를 보여주는 팝업 창이 표시되어야 합니다. Teleport 인증서가 존재하지 않으면 다음 명령어로 가져오세요:

$ certutil -dspublish -f <path-to-cert> NTAuthCA

Teleport 인증서가 LDAP에 존재함을 확인했다면, 이것이 모든 데스크톱에 전파되었는지 확인해야 합니다. 연결하려는 데스크톱에서 다음 명령어를 실행하세요:

$ certutil -viewstore -enterprise NTAuth

팝업 창에 Teleport 인증서가 표시되지 않고 LDAP에는 존재했다면, 다음 명령어로 데스크톱이 강제로 동기화되도록 할 수 있습니다:

$ certutil -pulse

해결 방법 2: 충돌하는 도구 확인#

Teleport CA 인증서가 올바르게 설치되어 있음을 확인했는데도 이 오류가 계속 발생한다면, mTLS 연결을 방해할 수 있는 보안 도구나 애드온이 있는지 확인하세요. CrowdStrike의 LDAP 검사 도구나 Silverfort의 AD 어댑터와 같은 도구는 TLS를 종료시키고 클라이언트 인증서를 드롭하는 것으로 알려져 있으며, 이는 Teleport의 인증을 방해합니다.

해결 방법 3: LDAP 서비스 계정에 대한 SID를 지정했는지 확인#

Microsoft의 2025년 2월 보안 업데이트는 모든 도메인 컨트롤러를 인증서 매핑에 대한 *완전 적용 모드(full enforcement mode)*로 전환합니다. 이는 Windows가 Teleport 클라이언트 인증서를 허용하려면 인증서가 발급 대상 사용자의 SID를 포함해야 함을 의미합니다.

이를 해결하려면 windows_desktop_service의 구성 파일에서 SID를 설정했는지 확인하세요:

windows_desktop_service:
  enabled: true
  ldap:
    username: 'MYDOMAIN\svc-teleport'
    sid: S-1-5-21-...

사용자의 SID를 조회하려면 다음 PowerShell 명령어를 사용하세요:

$ Get-AdUser -Identity $USERNAME | Select SID

또한 Teleport가 사용하는 서비스 계정이 활성화되어 있고 잠기지 않았는지도 확인해야 합니다. 정책에서 계정이 먼저 비밀번호 재설정을 수행하도록 요구하는 경우 이런 문제가 발생하기도 합니다.

해결 방법 4: 시계 드리프트 확인#

(Teleport 측이든 Windows 환경이든) 잘못된 시스템 시계는 한쪽 또는 양쪽 모두가 상대방의 인증서를 수락하지 못하는 결과를 초래할 수 있습니다.

시스템 시계가 정확한지 확인하세요. 시간이 지나면서 시계가 드리프트되지 않도록 NTP를 구성할 것을 권장합니다.

클라이언트 인증서 수동 검증#

또 다른 유용한 문제 해결 단계는 tctl을 사용하여 클라이언트 인증서를 발급하고 Windows 측에서 이를 검증해 보는 것입니다.

먼저 tctl로 클라이언트 인증서를 생성하되, --windows-user, --windows-sid, --windows-domain 플래그를 사용 환경에 맞는 값으로 반드시 바꾸세요:

# NOTE: To issue Windows certificates, you must run 'tctl auth sign' locally
# on the same machine as the Teleport auth_service. Running this command remotely
# with an identity issued by 'tsh' will result in 'ERROR: access denied'
$ tctl auth sign \
    --windows-user=svc-teleport \
    --windows-sid=S-1-5-21-3788279871-1068139173-3054872986-500 \
    --windows-domain=domain.example.com \
    --format=windows \
    --out=test

이렇게 하면 test.svc-teleport.der라는 이름의 인증서 파일이 생성됩니다.

다음으로, 이 인증서를 도메인 컨트롤러 중 하나에 복사하고 검증을 시도하세요:

$ certutil -urlfetch -verify test.svc-teleport.der

검증에 성공하면 다음과 유사한 출력으로 끝나야 합니다:

------------------------------------
Verified Application Policies:
    1.3.6.1.5.5.7.3.2 Client Authentication
    1.3.6.1.4.1.311.20.2.2 Smart Card Logon
Cert is an End Entity certificate
Leaf certificate revocation check passed
CertUtil: -verify command completed successfully.

비슷한 결과가 표시되지 않으면 출력에서 인증서를 검증할 수 없는 이유를 나타내는 오류를 찾아보세요.

연결 시도 실패#

RDP 서버가 표준 RDP 보안만 사용함#

데스크톱에 연결을 시도하면 다음과 유사한 오류와 함께 실패합니다

client advertised SSL, but server selected STANDARD_RDP_SECURITY

해결 방법: 강화된 RDP 보안 활성화#

표준 RDP 보안(Standard RDP Security)은 RC4 암호화를 기반으로 하며, RDP를 통해 Windows 호스트에 연결하는 가장 안전하지 않은 방식입니다. Teleport의 RDP 클라이언트는 TLS를 사용하는 강화된 RDP 보안을 요구합니다.

강화된 RDP 보안은 일반적으로 기본적으로 활성화되어 있지만, 사용 환경이 레거시 보안 방식을 요구하도록 구성되어 있을 수 있습니다.

이 구성은 다음 그룹 정책에서 사용할 수 있습니다:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security

"Require use of a specific security layer for remote (RDP) connections" 설정을 찾으세요. 이 설정은 RDP가 아니라 Negotiate 또는 SSL로 설정되어 있어야 합니다.

RDP 연결 실패#

Teleport Web UI에서 Windows 호스트의 Connect를 클릭하면 새 탭이 열리지만 상단 바 외에는 아무것도 표시되지 않습니다. RDP 연결 실패를 언급하는 오류가 표시됩니다. 다음과 유사한 오류도 볼 수 있습니다:

Rdp(Io(Os { code: 54, kind: ConnectionReset, message: "Connection reset by peer" }))

해결 방법: Windows 호스트가 안전한 암호 그룹을 사용하는지 확인#

대상 호스트가 강제로 연결을 재설정하는 경우, 이는 일반적으로 데스크톱이 TLS 연결에 대한 안전한 암호 그룹(cipher suite)을 지원하지 않음을 의미합니다. 이 문제는 최신 버전의 Windows에서는 덜 발생하지만, Windows Server 2012R2와 같은 이전 버전에서는 자주 관찰됩니다.

RDP 연결용 인증서를 구성하여 호스트가 안전한 암호 그룹을 사용하도록 강제할 수 있습니다.

CredSSP를 사용한 강화된 RDP 보안이 필요함#

데스크톱에 연결을 시도하면 실패하고 로그에 다음과 유사한 오류가 표시됩니다:

Error during negotiation step: the server requires that the client support enhanced RDP security with CredSSP

해결 방법: NLA(네트워크 수준 인증) 비활성화#

이는 RDP 서버가 NLA를 요구하고 있음을 의미합니다. 이 오류를 해결하려면 서버가 NLA를 요구하지 않도록 구성하거나, Teleport 16.2.0 이상을 실행 중이라면 NLA를 활성화할 수 있습니다.

서버가 NLA를 요구하지 않도록 구성하려면, Teleport 연결용으로 구성한 그룹 정책 객체에서 원격 데스크톱 연결을 허용하는 지침을 따르세요. Active Directory에서 NLA를 비활성화한 후에도 이 오류가 계속 발생한다면, 관리자 권한으로 Windows 명령 프롬프트에서 다음 명령어를 실행하여 정책 업데이트를 강제 실행하세요:

$ gpupdate.exe /force

NLA를 활성화하려면 Teleport의 windows_desktop_service를 실행하는 호스트에서 TELEPORT_ENABLE_RDP_NLA 환경 변수를 yes로 설정하세요. Teleport의 NLA 지원에 대한 자세한 정보는 Active Directory 가이드에서 확인할 수 있습니다.

CredSSP: Kerberos 데이터베이스에서 서버를 찾을 수 없음#

데스크톱에 연결을 시도하면 실패하고 UI에 다음과 유사한 오류가 표시됩니다:

CredSSP UnknownCredentials: server not found in Kerberos database

이는 NLA와 관련된 오류입니다. NLA를 사용하여 Windows 호스트에 연결하려면 Teleport가 Active Directory에 존재하는 그대로의 컴퓨터 이름을 지정해야 합니다. 올바른 컴퓨터 이름을 지정하지 않았거나 호스트 이름 대신 IP 주소로 연결하는 경우 이 오류가 표시됩니다.

해결 방법: 서버의 컴퓨터 이름 수정#

이 오류를 해결하려면 다음 중 하나를 확인하세요:

  • 서버의 컴퓨터 이름이 teleport.dev/computer_name 라벨에 지정되어 있는지
  • 서버의 addr 필드가 올바른 컴퓨터 이름을 지정하고 있는지

자세한 내용은 Computer Name을 참조하세요.

디렉터리 공유#

디렉터리 공유 실패#

디렉터리를 공유하려는 시도가 실패하고 다음과 같은 경고가 표시됩니다:

Failed to share directory, drive redirection may be disabled on the RDP server.

해결 방법: 장치 리디렉션이 활성화되어 있는지 확인#

Teleport의 디렉터리 공유 기능은 RDP 장치 리디렉션을 활용합니다. 장치 리디렉션이 RDP 서버에서 활성화되어 있지 않거나 허용되지 않으면 작업이 실패합니다.

장치 리디렉션은 일반적으로 기본적으로 활성화되어 있지만 그룹 정책에서 비활성화되어 있을 수 있습니다. 관련 설정은 Computer configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection 아래에 있습니다.

Do not allow drive redirection 옵션이 설정되지 않았거나 비활성화되어 있는지 확인하세요.