Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Organizacje wdrażające technologie bezhasłowe odporne na phishing zwykle potrzebują, aby niektóre ich osoby korzystały z technologii pulpitu zdalnego w celu zwiększenia produktywności, bezpieczeństwa lub administracji. Dwa podstawowe przypadki użycia to:
- Inicjowanie i uwierzytelnianie sesji połączenia pulpitu zdalnego z klienta lokalnego na maszynę zdalną przy użyciu poświadczeń bez hasła odpornych na wyłudzanie informacji
- Korzystanie z poświadczeń odpornych na phishing, działających bez hasła, podczas sesji ustabilizowanego połączenia pulpitu zdalnego.
Zapoznaj się z konkretnymi zagadnieniami dotyczącymi każdego przypadku użycia.
Składniki połączenia pulpitu zdalnego
Protokół pulpitu zdalnego systemu Windows obejmuje trzy podstawowe składniki, z których wszystkie muszą prawidłowo obsługiwać poświadczenia bez hasła odporne na wyłudzanie informacji na potrzeby inicjowania sesji połączenia pulpitu zdalnego przy użyciu tych poświadczeń. Jeśli którykolwiek z tych składników nie może prawidłowo działać lub nie obsługuje niektórych poświadczeń bez hasła, jeden lub oba opisane scenariusze nie będą działać. Ten przewodnik koncentruje się na obsłudze klucza dostępu/fiDO2 i obsłudze uwierzytelniania Cert-Based (CBA).
Zapoznaj się z poniższymi sekcjami, aby ustalić, czy wsparcie dla odpornego na phishing bezhasłowego uwierzytelniania jest oczekiwane we wszystkich trzech komponentach, z których korzystasz. Powtórz ten proces, jeśli masz wiele scenariuszy wymagających oceny.
Platforma kliencka
Istnieje kilka różnych powszechnie używanych systemów operacyjnych dla klientów lokalnych, które są używane do inicjowania sesji pulpitu zdalnego. Często używane opcje to:
- Windows 10+
- Serwer z systemem Windows
- macOS
- Ios
- Android
- Linuxa
Obsługa połączenia bez hasła odpornego na phishing oraz połączenia zdalnego pulpitu zależy od tej platformy klienckiej, która obsługuje protokoły klucza dostępu, w szczególności Client To Authenticator Protocol (CTAP) i WebAuthn. CTAP to warstwa komunikacji między modułami uwierzytelniania roamingu, takimi jak klucze zabezpieczeń FIDO2 lub klucze dostępu na urządzeniu przenośnym i platforma kliencka. Większość platform klienckich obsługuje te protokoły, ale istnieją pewne platformy, które nie. W niektórych przypadkach, takich jak w przypadku dedykowanych urządzeń typu "thin client" z wyspecjalizowanymi systemami operacyjnymi, należy skontaktować się z dostawcą, aby potwierdzić wsparcie.
Uwierzytelnianie oparte na certyfikatach firmy Microsoft (CBA) wymaga konfiguracji w identyfikatorze Entra firmy Microsoft, aby użytkownicy mogli korzystać z certyfikatów z infrastruktury kluczy publicznych (PKI) do uwierzytelniania. Ten artykuł nie dotyczy tylko lokalnych implementacji uwierzytelniania opartego na certyfikatach.
| Platforma kliencka | Obsługa fiDO | Microsoft Entra CBA | Notatki |
|---|---|---|---|
| Windows 10+ | Tak | Tak | |
| Serwer z systemem Windows | Częściowy | Tak | System Windows Server nie jest zalecany w przypadku urządzeń klienckich. Serwery przesiadkowe systemu Windows Server mogą utrudniać odporne na wyłudzanie informacji bez hasła oparte na standardach FIDO. Jeśli używasz serwerów przesiadkowych, zaleca się CBA zamiast FIDO. |
| macOS | Tak | Tak | Nie wszystkie struktury internetowe firmy Apple obsługują standard FIDO |
| Ios | Tak | Tak | Nie wszystkie struktury internetowe firmy Apple obsługują standard FIDO |
| Android | Tak | Tak | |
| Linuxa | Może | Tak | Potwierdzanie obsługi fiDO u dostawcy dystrybucji systemu Linux |
Platforma docelowa
Platforma docelowa ma kluczowe znaczenie dla określenia, czy uwierzytelnianie bez hasła odporne na wyłudzanie informacji jest obsługiwane podczas ustanawiania samej sesji połączenia pulpitu zdalnego.
| Platforma docelowa | Obsługa inicjowania sesji połączenia pulpitu zdalnego FIDO | Inicjalizacja sesji połączenia pulpitu zdalnego Microsoft Entra CBA |
|---|---|---|
| Dołączone do systemu Windows 10+ Microsoft Entra | Tak | Tak |
| Windows Server dołączył do Microsoft Entra | Tak1 | Tak |
| Przyłączone hybrydy do systemu Windows 10 lub nowszego firmy Microsoft Entra | Tak | Tak |
| Dołączony hybrydowy system Windows Server firmy Microsoft Entra | Tak1 | Tak |
| Windows 10+ usługa Microsoft Entra zarejestrowana | Nie. | Nie. |
| Tylko systemy Windows 10 lub nowsze przyłączone do lokalnej domeny | Nie. | Nie. |
| Przyłączone tylko do domeny lokalnej systemu Windows Server | Nie. | Nie. |
| Windows 10+ Grupa robocza | Nie. | Nie. |
| Autonomiczna/grupa robocza systemu Windows Server zarządzana przez usługę Azure Arc2 | Tak | Tak |
1. Dotyczy tylko serwerów połączonych z Microsoft Entra lub połączonych hybrydowo, które działają na systemie Windows Server 2022 lub nowszym
2. Dotyczy tylko serwerów połączonych z Microsoft Entra, działających na Windows Server 2025 lub nowszym
Klient połączenia pulpitu zdalnego
Obsługa platformy klienta dla uwierzytelniania odpornego na wyłudzanie informacji sama w sobie nie jest wystarczająca, aby wspierać uwierzytelnianie odporne na wyłudzanie informacji w sesjach połączenia pulpitu zdalnego. Używany klient połączenia pulpitu zdalnego musi również obsługiwać niezbędne składniki, aby te poświadczenia działały prawidłowo. Zapoznaj się z wieloma często używanymi klientami połączeń pulpitu zdalnego i ich różnymi obsługiwanymi opcjami:
| Klient połączenia pulpitu zdalnego | Obsługa inicjowania sesji połączenia pulpitu zdalnego FIDO | Inicjalizacja sesji połączenia pulpitu zdalnego Microsoft Entra CBA |
|---|---|---|
| MSTSC.exe dla klienta systemu Windows | Tak | Tak |
| MSTSC.exe dla systemu Windows Server 2022+ | Tak | Tak |
| MSTSC.exe dla systemu Windows Server 2019 lub starszego | Nie. | Nie. |
| Aplikacja systemu Windows dla systemu Windows | Tak | Tak |
| Aplikacja systemu Windows dla systemu macOS | Tak | Tak |
| Aplikacja systemu Windows dla systemu iOS | Tak | Tak |
| Aplikacja systemu Windows dla systemu Android | Tak | Tak |
| Aplikacja internetowa systemu Windows 365 | Nie. | Nie. |
| Zewnętrzny klient połączenia pulpitu zdalnego | Może | Może |
Ważne
Urządzenia klienckie i docelowe muszą być przyłączone do Microsoft Entra, hybrydowo dołączone do Microsoft Entra lub zarejestrowane w Microsoft Entra w ramach tej samej dzierżawy. Uwierzytelnianie między dzierżawami nie będzie działać. Urządzenie klienckie nie będzie mogło uwierzytelnić się na urządzeniu docelowym, jeśli są podłączone do różnych dzierżaw.
Oceń wsparcie dla swoich scenariuszy
Jeśli którykolwiek z trzech składników opisanych w tym dokumencie nie obsługuje twojego scenariusza, scenariusz nie powinien działać. Aby dokonać oceny, rozważ każdy składnik dotyczący uwierzytelniania sesji połączenia pulpitu zdalnego oraz użycia poświadczeń podczas sesji. Powtórz ten proces dla każdego scenariusza w środowisku, aby zrozumieć, które scenariusze powinny działać, a które nie powinny.
Przykład 1
Poniżej przedstawiono sposób oceny, czy w twoim scenariuszu jest "pracownicy informacyjni muszą używać swoich urządzeń z systemem Windows do uzyskiwania dostępu do usługi Azure Virtual Desktop, uwierzytelnić sesję połączenia pulpitu zdalnego przy użyciu kodu dostępu Microsoft Authenticator oraz użyć tego kodu w sesji połączenia pulpitu zdalnego w przeglądarce Microsoft Edge":
| Scenariusz | Platforma kliencka | Platforma docelowa | Klient połączenia pulpitu zdalnego | Obsługiwane? |
|---|---|---|---|---|
| Inicjowanie sesji połączenia pulpitu zdalnego przy użyciu klucza dostępu aplikacji uwierzytelniania | Windows 11 Microsoft Entra dołączony/Dołączony hybrydowo/Samodzielny | Microsoft Entra przyłączona do usługi Azure Virtual Desktop | Aplikacja Windows | Tak+Tak+Tak = Tak |
| Podłączanie pulpitu zdalnego In-Session uwierzytelnianie przy użyciu klucza dostępu aplikacji uwierzytelniania | Windows 11 Microsoft Entra dołączony/Dołączony hybrydowo/Samodzielny | Microsoft Entra przyłączona do usługi Azure Virtual Desktop | Aplikacja Windows | Tak+Tak+Tak = Tak |
W tym przykładzie zarówno sama sesja połączenia pulpitu zdalnego, jak i aplikacje w sesji mogą korzystać z klucza dostępu użytkownika. System bezhasłowy odporny na phishing powinien działać na szeroką skalę.
Przykład 2
Oto jak możesz ocenić, czy twój scenariusz to "moi pracownicy muszą korzystać z urządzeń z systemem macOS, aby uzyskać dostęp do Azure Virtual Desktop, uwierzytelniać sesję połączenia pulpitu zdalnego przy użyciu hasła jednorazowego Microsoft Authenticator i używać go wewnątrz sesji":
| Scenariusz | Platforma kliencka | Platforma docelowa | Klient połączenia pulpitu zdalnego | Obsługiwane? |
|---|---|---|---|---|
| Inicjowanie sesji połączenia pulpitu zdalnego przy użyciu klucza dostępu aplikacji uwierzytelniania | macOS 15 | Microsoft Entra przyłączona do usługi Azure Virtual Desktop | Aplikacja Windows | Tak+Tak+Tak = Tak |
| Podłączanie pulpitu zdalnego In-Session uwierzytelnianie przy użyciu klucza dostępu aplikacji uwierzytelniania | macOS 15 | Microsoft Entra przyłączona do usługi Azure Virtual Desktop | Aplikacja Windows | Tak+Tak+Nie = Nie |
W tym przykładzie użytkownicy mogą użyć swojego klucza dostępu do ustanowienia sesji połączenia pulpitu zdalnego, ale nie mogą jej używać w sesji połączenia pulpitu zdalnego, ponieważ aplikacja systemu Windows w systemie macOS nie obsługuje jeszcze tej funkcji. Możesz poczekać na lepszą obsługę passkey w kliencie połączenia pulpitu zdalnego lub przełączyć się na inne poświadczenia, takie jak certyfikaty z CBA.
Przykład 3
W ten sposób możesz ocenić, czy twoi administratorzy potrzebują używać swoich urządzeń z systemem Windows do uzyskania dostępu do lokalnych serwerów z systemem Windows, uwierzytelnić sesję połączenia pulpitu zdalnego za pomocą certyfikatu oraz użyć certyfikatu w tej sesji połączenia pulpitu zdalnego.
| Scenariusz | Platforma kliencka | Platforma docelowa | Klient połączenia pulpitu zdalnego | Obsługiwane? |
|---|---|---|---|---|
| Połączenie pulpitu zdalnego: Inicjowanie sesji przy użyciu certyfikatu | Windows 11 | Domain-Joined Windows Server | MSTSC.exe | Tak+Tak+Tak = Tak |
| Podłączanie pulpitu zdalnego In-Session uwierzytelnianie przy użyciu certyfikatu | Windows 11 | Domain-Joined Windows Server | MSTSC.exe | Tak+Tak+Tak = Tak |
W tym przykładzie użytkownicy mogą użyć certyfikatu do ustanowienia sesji połączenia pulpitu zdalnego, a także użyć certyfikatu wewnątrz sesji połączenia pulpitu zdalnego. Ten scenariusz nie zadziała jednak z hasłem, ponieważ przyłączony do domeny serwer z systemem Windows nie może użyć hasła do skonfigurowania sesji połączenia pulpitu zdalnego ani wewnątrz sesji.
Przykład 4
Oto jak można ocenić, czy w twoim scenariuszu jest "twoi pracownicy pierwszej linii muszą używać klienta cienkiego opartego na systemie Linux do uzyskiwania dostępu do klientów infrastruktury pulpitu wirtualnego Windows z domeną na miejscu, którzy nie są hybrydowo przyłączeni do Microsoft Entra, muszą uwierzytelnić sesję połączenia pulpitu zdalnego przy użyciu klucza zabezpieczeń FIDO2 i użyć tego klucza zabezpieczeń FIDO2 wewnątrz sesji połączenia pulpitu zdalnego".
| Scenariusz | Platforma kliencka | Platforma docelowa | Klient połączenia pulpitu zdalnego | Obsługiwane? |
|---|---|---|---|---|
| Inicjowanie sesji połączenia pulpitu zdalnego przy użyciu klucza zabezpieczeń FIDO2 | Dystrybucja systemu Linux Embedded | Domain-Joined Windows 11 | Klient dostarczony przez dostawcę | Może+Nie+Nie = Nie |
| Podłączanie pulpitu zdalnego In-Session uwierzytelnianie przy użyciu klucza zabezpieczeń FIDO2 | Dystrybucja systemu Linux Embedded | Domain-Joined Windows 11 | Klient dostarczony przez dostawcę | Być może+Tak+Być może = Być może |
W tym przykładzie użytkownicy prawdopodobnie nie mogą używać kluczy zabezpieczeń FIDO2 do połączenia pulpitu zdalnego w ogóle, ponieważ system operacyjny klienta elastycznego i klient połączenia pulpitu zdalnego nie obsługują kluczy FIDO2/passkey w każdym wymaganym scenariuszu. Skontaktuj się z dostawcą klienta elastycznego, aby zrozumieć swój plan pomocy technicznej. Ponadto zaplanuj dołączanie hybrydowe platformy Microsoft Entra lub dołączanie Microsoft Entra do maszyn wirtualnych platformy docelowej, aby lepiej obsługiwać klucze przejścia.