Share via

Koncové body nativní pro cloud a místní prostředky

  • Článek

Tip

Při čtení o koncových bodech nativních pro cloud uvidíte následující termíny:

  • Koncový bod: Koncový bod je zařízení, například mobilní telefon, tablet, přenosný počítač nebo stolní počítač. Koncové body a zařízení se používají zaměnitelně.
  • Spravované koncové body: Koncové body, které přijímají zásady od organizace pomocí řešení MDM nebo Zásady skupiny objektů. Tato zařízení jsou obvykle vlastněná organizací, ale můžou to být také zařízení vlastními zařízeními nebo zařízení v osobním vlastnictví.
  • Koncové body nativní pro cloud: Koncové body, které jsou připojené k Azure AD. Nejsou připojené k místní službě AD.
  • Úloha: Jakýkoli program, služba nebo proces.

Koncové body nativní pro cloud mají přístup k místním prostředkům. Tento článek se podrobněji zabývá a odpovídá na některé běžné otázky.

Tato funkce platí pro:

  • Koncové body Windows nativní pro cloud

Přehled koncových bodů nativních pro cloud a jejich výhod najdete v tématu Co jsou koncové body nativní pro cloud.

Požadavky

Aby koncové body Windows nativní pro cloud přistupovaly k místním prostředkům a službám, které k ověřování používají místní Active Directory (AD), jsou vyžadovány následující požadavky:

  • Klientské aplikace musí používat integrované ověřování Windows (WIA). Podrobnější informace najdete v tématu Integrované ověřování systému Windows (WIA).

  • Nakonfigurujte Microsoft Entra Connect. Microsoft Entra Connect synchronizuje uživatelské účty z místní služby AD do Microsoft Entra. Podrobnější informace najdete v tématu Microsoft Entra Synchronizace připojení: Principy a přizpůsobení synchronizace.

    V Microsoft Entra Connect možná budete muset upravit filtrování na základě domény, abyste potvrdili, že se požadovaná data domén synchronizují s Microsoft Entra.

  • Zařízení má přímé připojení (buď přímo, nebo prostřednictvím sítě VPN) k řadiči domény z domény AD a ke službě nebo prostředku, ke které přistupujete.

Podobné místním zařízením s Windows

Koncový bod Windows nativní pro cloud se pro koncové uživatele chová stejně jako jakékoli jiné místní zařízení s Windows.

Následující seznam obsahuje běžnou sadu místních prostředků, ke kterým mají uživatelé přístup ze svých Microsoft Entra připojených zařízení:

  • Souborový server: Pomocí protokolu SMB (Server Message Block) můžete namapovat síťovou jednotku na server člena domény, který je hostitelem sdílené síťové složky nebo úložiště NAS (Network Attached Storage).

    Uživatelé můžou namapovat jednotky na sdílené a osobní dokumenty.

  • Prostředek tiskárny na serveru člena domény: Uživatelé můžou tisknout na místní nebo nejbližší tiskárně.

  • Webový server na serveru člena domény, který používá integrované zabezpečení Windows: Uživatelé mají přístup k jakékoli win32 nebo webové aplikaci.

  • Chcete spravovat místní doménu AD z koncového bodu připojeného k Microsoft Entra: Nainstalujte nástroje pro vzdálenou správu serveru:

    • Ke správě všech objektů AD použijte modul snap-in Uživatelé a počítače služby Active Directory (ADUC). Musíte ručně zadat doménu, ke které se chcete připojit.
    • Ke správě serveru DHCP připojeného k AD použijte modul snap-in DHCP. Možná budete muset zadat název nebo adresu serveru DHCP.

Tip

Abyste pochopili, jak Microsoft Entra připojená zařízení používají přihlašovací údaje uložené v mezipaměti v přístupu nativním pro cloud, watch OPS108: Interní ověřování Windows v hybridním světě (syfuhs.net) (otevře externí web).

Ověřování a přístup k místním prostředkům

Následující kroky popisují, jak Microsoft Entra připojený koncový bod ověřuje a přistupuje (na základě oprávnění) k místnímu prostředku.

Přehled najdete v následujících krocích. Podrobnější informace, včetně podrobných obrázků plaveckých drah, které popisují celý proces, najdete v tématu Primární obnovovací token (PRT) a Microsoft Entra.

  1. Když se uživatelé přihlásí, odesílají se jejich přihlašovací údaje do zprostředkovatele cloudového ověřování (CloudAP) a správce webových účtů (WAM).

  2. Modul plug-in CloudAP odešle přihlašovací údaje uživatele a zařízení do Microsoft Entra. Nebo se ověřuje pomocí Windows Hello pro firmy.

  3. Během přihlašování k Windows modul plug-in Microsoft Entra CloudAP požádá o primární obnovovací token (PRT) z Microsoft Entra pomocí přihlašovacích údajů uživatele. Také ukládá do mezipaměti PRT, který umožňuje přihlášení v mezipaměti, když uživatelé nemají připojení k internetu. Když se uživatelé pokusí získat přístup k aplikacím, modul plug-in Microsoft Entra WAM použije prt k povolení jednotného přihlašování.

  4. Microsoft Entra ověří uživatele a zařízení a vrátí prt & token ID. Token ID obsahuje následující atributy uživatele:

    • sAMAccountName
    • netBIOSDomainName
    • dnsDomainName

    Tyto atributy se synchronizují z místní služby AD pomocí Microsoft Entra Connect.

    Zprostředkovatel ověřování kerberos obdrží přihlašovací údaje a atributy. Služba LSA (Local Security Authority) systému Windows na zařízení povolí ověřování protokoly Kerberos a NTLM.

  5. Během pokusu o přístup k místnímu prostředku, který žádá o ověření protokolem Kerberos nebo NTLM, zařízení pomocí lokátoru řadiče domény vyhledá atributy související s názvem domény.

    • Pokud se řadič domény najde, odešle přihlašovací údaje a sAMAccountName přihlašovací údaje řadiči domény k ověření.
    • Pokud používáte Windows Hello pro firmy, provede PKINIT s certifikátem Windows Hello pro firmy.
    • Pokud se nenajde žádný řadič domény, nedojde k žádnému místnímu ověřování.

    Poznámka

    PKINIT je mechanismus předběžného ověřování pro Protokol Kerberos 5, který používá certifikáty X.509 k ověření centra distribuce klíčů (KDC) u klientů a naopak.

    MS-PKCA: Kryptografie veřejného klíče pro počáteční ověřování (PKINIT) v protokolu Kerberos

  6. Řadič domény ověří uživatele. Řadič domény vrátí protokol TGT (Kerberos Ticket-Granting Ticket) nebo token NTLM na základě protokolu, který místní prostředek nebo aplikace podporuje. Systém Windows ukládá vrácený token TGT nebo NTLM do mezipaměti pro budoucí použití.

    Pokud se pokus o získání tokenu Kerberos TGT nebo NTLM pro doménu nezdaří (související vypršení časového limitu DCLocatoru může způsobit zpoždění), pokusí se znovu provést Správce přihlašovacích údajů systému Windows. Nebo se uživateli může zobrazit automaticky otevírané okno s žádostí o přihlašovací údaje pro místní prostředek.

  7. Všechny aplikace, které používají integrované ověřování Windows (WIA), automaticky používají jednotné přihlašování, když se uživatel pokusí o přístup k aplikacím. WIA zahrnuje standardní ověřování uživatelů k místní doméně AD pomocí protokolu NTLM nebo Kerberos při přístupu k místním službám nebo prostředkům.

    Další informace najdete v tématu Jak jednotné přihlašování k místním prostředkům funguje na Microsoft Entra připojených zařízeních.

    Je důležité zdůraznit hodnotu integrovaného ověřování systému Windows. Nativní koncové body cloudu jednoduše "fungují" s libovolnou aplikací nakonfigurovanou pro WIA.

    Když uživatelé přistupují k prostředku, který používá wia (souborový server, tiskárnu, webový server atd.), TGT se vymění za lístek služby Kerberos, což je obvyklý pracovní postup kerberos.

Postupujte podle pokynů ke koncovým bodům nativním pro cloud.

  1. Přehled: Co jsou koncové body nativní pro cloud?
  2. Kurz: Začínáme s koncovými body Windows nativními pro cloud
  3. Koncept: připojení Microsoft Entra vs. připojení k hybridnímu Microsoft Entra
  4. 🡺 Koncept: Koncové body nativní pro cloud a místní prostředky (jste tady)
  5. Průvodce plánováním na vysoké úrovni
  6. Známé problémy a důležité informace

Užitečné online zdroje