Podczas konfigurowania kont użytkowników i zarządzania nimi możesz wybrać jeden z trzech głównych modeli tożsamości w usłudze Office 365:
Kontami użytkowników można zarządzać wyłącznie w ramach pakietu Office 365. Do zarządzania użytkownikami nie są wymagane żadne serwery lokalne; Wszystko odbywa się w chmurze. |
Synchronizuj obiekty katalogu lokalnego z usługą Office 365 i zarządzaj użytkownikami lokalnie. Możesz również zsynchronizować hasła, aby użytkownicy mieli to samo hasło lokalnie i w chmurze, ale będą musieli zalogować się ponownie, aby korzystać z usługi Office 365. |
Synchronizuj obiekty katalogu lokalnego z usługą Office 365 i zarządzaj użytkownikami lokalnie. Użytkownicy mają to samo hasło lokalnie i w chmurze i nie muszą logować się ponownie, aby korzystać z usługi Office 365. Jest to często określane jako logowanie jednokrotne. |
Ważne jest, aby dokładnie rozważyć, którego modelu tożsamości użyć, aby rozpocząć pracę. Pomyśl o czasie, istniejącej złożoności i kosztach. Czynniki te są różne dla każdej organizacji; W tym temacie omówiono te kluczowe pojęcia dotyczące każdego modelu tożsamości, aby ułatwić wybranie tożsamości, która ma być używana do wdrożenia.
Możesz również przełączyć się na inny model tożsamości, jeśli zmienią się wymagania.
W tym modelu utworzysz użytkowników i zarządzasz nimi w portalu pakietu Microsoft Office oraz przechowujesz konta w usłudze Azure AD. Usługa Azure AD weryfikuje hasła. Azure AD to katalog w chmurze używany przez usługę Office 365. Nie są wymagane żadne serwery lokalne — firma Microsoft zarządza tym wszystkim za Ciebie. Gdy tożsamość i uwierzytelnianie są obsługiwane całkowicie w chmurze, można zarządzać kontami użytkowników i licencjami użytkowników za pośrednictwem portalu online firmy Microsoft lub poleceń cmdlet programu Windows PowerShell.
Na poniższej ilustracji przedstawiono sposób zarządzania użytkownikami w modelu tożsamości w chmurze.
Administrator łączy się z portalem online firmy Microsoft na platformie chmury firmy Microsoft w celu utworzenia użytkowników lub zarządzania nimi.
Żądania tworzenia lub zarządzania nimi są przekazywane do usługi Azure AD.
Jeśli jest to żądanie zmiany, zmiana zostanie wprowadzona i skopiowana z powrotem do Portalu Microsoft Office
Nowe konta użytkowników i zmiany na istniejących kontach użytkowników są kopiowane z powrotem do portalu Microsoft Office.
Kiedy warto korzystać z tożsamości w chmurze? Tożsamość w chmurze to dobry wybór, jeśli:
Jeśli masz istniejące środowisko katalogowe lokalnie, możesz zintegrować usługę Office 365 z katalogiem przy użyciu tożsamości synchronizowanej lub logowania jednokrotnego i tożsamości federacyjnej w celu tworzenia użytkowników i zarządzania nimi w usłudze Office 365.
W tym modelu zarządzasz tożsamością użytkownika na serwerze lokalnym i synchronizujesz konta i, opcjonalnie, hasła z chmurą. Użytkownik wprowadza to samo hasło lokalnie, co w chmurze, a podczas logowania hasło jest weryfikowane przez usługę Azure AD. Ten model używa narzędzia do synchronizacji katalogów do synchronizowania tożsamości lokalnej z usługą Office 365.
Aby skonfigurować zsynchronizowany model tożsamości, musisz mieć katalog lokalny, z którego ma być synchronizowana, i musisz zainstalować narzędzie do synchronizacji katalogów. Przed zsynchronizowaniem kont uruchomisz kilka kontroli spójności w katalogu lokalnym.
Kiedy używać tożsamości zsynchronizowanych lub federacyjnych:
Ten model: |
Sprawdza się w następujących sytuacjach: |
Zsynchronizowane tożsamości |
Jeśli masz katalog lokalny i chcesz zsynchronizować konta użytkowników i opcjonalnie hasła. Jeśli synchronizujesz również hasła, użytkownicy będą używać tego samego hasła do uzyskiwania dostępu do zasobów lokalnych i usługi Office 365. Jeśli ostatecznie chcesz korzystać z tożsamości federacyjnych, ale korzystasz z pilotażu usługi Office 365 lub z jakiegoś innego powodu nie jesteś jeszcze gotowy, aby poświęcić czas na wdrożenie serwerów Active Directory Federation Services (AD FS). |
Tożsamości federacyjne |
Gdy potrzebny jest zaawansowany scenariusz, taki jak: istniejąca federacja, zasady lub wymagania techniczne |
Na poniższym diagramie przedstawiono scenariusz zsynchronizowanej tożsamości z synchronizacją haseł. Narzędzie do synchronizacji zapewnia synchronizację tożsamości użytkowników firmowych w środowisku lokalnym i w chmurze.
Instalujesz program Microsoft Azure Active Directory Connect.
Nowi użytkownicy są tworzeni w katalogu lokalnym.
Narzędzie do synchronizacji będzie okresowo sprawdzać katalog lokalny pod kątem wszelkich nowo utworzonych tożsamości. Następnie aprowizuje te tożsamości w usłudze Azure AD, łączy ze sobą tożsamości lokalne i w chmurze, synchronizuje hasła i udostępnia je za pośrednictwem portalu pakietu Microsoft Office.
Podczas wprowadzania zmian u użytkowników w katalogu lokalnym zmiany te są synchronizowane z usługą Azure AD i udostępniane za pośrednictwem portalu pakietu Microsoft Office.
Ten model wymaga tożsamości zsynchronizowanej, ale z jedną zmianą w tym modelu: hasło użytkownika jest weryfikowane przez lokalnego dostawcę tożsamości. Oznacza to, że skrót hasła nie musi być synchronizowany z usługą Azure AD. W tym modelu jest używany Active Directory Federation Services (AD FS) lub dostawca tożsamości innej firmy.
Powody używania tożsamości federacyjnej obejmują:
Istniejąca infrastruktura
Wymagania techniczne
Wymagania dotyczące zasad
Na poniższym diagramie przedstawiono scenariusz tożsamości federacyjnej z hybrydowym wdrożeniem lokalnym i w chmurze. Katalog lokalny w tym przykładzie to AD FS. Narzędzie do synchronizacji zapewnia synchronizację tożsamości użytkowników firmowych w środowisku lokalnym i w chmurze.
Instalujesz Azure Active Directory Connect Narzędzie do synchronizacji pomaga zachować aktualność usługi Azure AD o najnowsze zmiany wprowadzone w katalogu lokalnym. Aby skonfigurować logowanie jednokrotne, należy użyć niestandardowej instalacji programu Azure AD Connect.
Nowych użytkowników tworzy się w lokalnej usłudze Active Directory.
Narzędzie do synchronizacji będzie okresowo sprawdzać lokalny serwer usługi Active Directory pod kątem wszelkich nowo utworzonych tożsamości. Następnie aprowizuje te tożsamości w usłudze Azure AD, łączy tożsamości lokalne i w chmurze ze sobą i sprawia, że są one widoczne za pośrednictwem portalu pakietu Microsoft Office.
W miarę wprowadzania zmian w tożsamości w lokalna usługa Active Directory zmiany te są synchronizowane z usługą Azure AD.
Zmiany te są udostępniane za pośrednictwem portalu Microsoft Office.
Użytkownicy federacyjni logują się przy użyciu usług AD FS.
Usługi AD FS generują token zabezpieczający, który jest przekazywany do usługi Azure AD. Token jest weryfikowany i weryfikowany, a następnie użytkownicy są autoryzowani do usługi Office 365.