일반적인 문제 및 해결 단계.

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

원격 데스크톱 접근이 올바르게 작동하려면, 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 서비스
• 대상 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 서비스가 활성으로 표시되고 시스템 시계가 동기화된 것을 볼 수 있습니다. 출력이 위와 다르면 시계 설정을 재구성해야 할 수 있습니다.

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

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

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

사용자 이름을 클릭하고, Sign-in options를 클릭한 다음 스마트 카드 아이콘을 클릭할 수 있습니다. 오류 메시지: "No Valid Certificates Were Found on This 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 인증서가 "Domain Controller" 기본 제공 템플릿으로 발급되거나(AD CS 사용 시) 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 클러스터 주소로 바꿉니다:

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

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

새 세션이 "멈춤"#

호스트에 도달할 수 없음#

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

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

먼저 RDP 포트를 열고 Teleport 연결을 위해 구성한 그룹 정책 개체에서 원격 데스크톱 연결을 허용했는지 확인합니다.

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

호스트 이름이 해석되지 않음#

Windows 데스크톱에 대한 연결이 연결 설정 중에 멈추거나, Teleport 디버그 로그에 couldn't resolve winserver.example.com 형태의 오류가 표시됩니다.

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

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

방화벽이 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_service의 ldap 섹션에 있는 domain 필드를 다시 확인합니다.

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

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

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

해결 방법: LDAP 주소 확인#

이는 도메인 컨트롤러가 다운되거나 도달할 수 없음을 의미합니다. windows_desktop_service의 ldap 섹션에 있는 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 인증서 서비스를 설치 (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가 인증할 수 없을 때 발생하며, 이는 종종 인증 기관이 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월 보안 업데이트는 모든 도메인 컨트롤러를 인증서 매핑에 대해 완전 적용 모드로 전환합니다. 즉, 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 플래그를 환경에 적합한 값으로 교체합니다:

# 참고: Windows 인증서를 발급하려면 Teleport auth_service와 동일한 머신에서 로컬로
# 'tctl auth sign'을 실행해야 합니다. 'tsh'로 발급된 신원으로 이 명령어를 원격으로 실행하면
# '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 보안은 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 연결을 위한 보안 암호 스위트를 지원하지 않는다는 것을 의미합니다. 이 문제는 최신 버전의 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 필드가 올바른 컴퓨터 이름을 지정하는지

자세한 내용은 컴퓨터 이름을 참조하세요.

디렉터리 공유#

디렉터리 공유 실패#

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

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 옵션이 설정 해제되거나 비활성화되어 있는지 확인합니다.