Latest / M365.FM – podcast o Microsoft 365, Copilot i AI po polsku / Microsoft Entra Domain Services wyjaśnione: starsze aplikacje w Azure bez własnych kontrolerów domeny (Dubbing AI)

Transcript

Microsoft Entra Domain Services wyjaśnione: starsze aplikacje w Azure bez własnych kontrolerów domeny (Dubbing AI) · M365.FM – podcast o Microsoft 365, Copilot i AI po polsku

• 0:00
  Gotowi na 10 dni Microsoft 365, Kopilota, AI, Azure oraz ludzi kształtujących przyszłość pracy?
• 0:07
  W styczniu konferencja M365 powraca i będzie jeszcze większa.
• 0:12
  Dołącz do nas na sesję na żywo praktyczne dema i wiedzę od MVP oraz ekspertów z całego świata.
• 0:18
  Żadnych ogólnych slajdów, żadnego niekończącego się żargonu.
• 0:22
  Zajmiemy się realnymi wyzwaniami, Kopilot Studio, agentami, AI, Fabrik, bezpieczeństwem, ładem i automatyzacją.
• 0:28
  Niezależnie od tego, czy jesteś informatykiem, programistą czy liderem biznesowym, przygotowaliśmy sesję dla Ciebie.
• 0:35
  Podczas 10 pełnych dni odkryjesz nowe technologie i nawiążesz kontakty z globalną społecznością.
• 0:40
  Oglądaj na żywo i zabierz praktyczne wnioski do swojej organizacji.
• 0:44
  Styczeń 2027 roku. 10 dni. Jedna społeczność Microsoft. Rejestracja jest już otwarta.
• 0:51
  Wejdź na m365con.net i zarezerwuj miejsce już dziś.
• 0:55
  To m365con.net
• 0:58
  Dołącz teraz na m365con.net. Widzimy się na żywo w styczniu.
• 1:05
  Witajcie wszyscy w kolejnym odcinku Microsoft Knowledge Nugget tutaj w M365FM.
• 1:10
  Nazywam się Mirko Peters.
• 1:11
  Wyobraź sobie, że przenosisz starą aplikację biznesową z serwera w biurze na maszynę wirtualną Azure.
• 1:16
  Aplikacja jest już w chmurze, ale nadal wymaga domeny Windows.
• 1:18
  Chce dołączyć do domeny, wyszukiwać użytkowników przez LDAP, logować ich za pomocą Kerberos i stosować zasady grupy.
• 1:24
  Większość ludzi zakłada, że EntraID zastępuje każdą funkcję Active Directory.
• 1:28
  Tak nie jest. Nowoczesne aplikacje chmurowe logują przez EntraID, ale starsze aplikacje Windows nadal oczekują domeny znanej z serwerowni.
• 1:36
  Pod koniec tego odcinka zrozumiesz, gdzie pasują EntraID Active Directory i Entra Domain Services oraz poznasz szczegół zmieniający zarządzanie tym wszystkim.
• 1:44
  Informacje o tożsamości przepływają tylko w jednym kierunku.
• 1:47
  Dlaczego samo EntraID nie obsłuży każdej starszej aplikacji?
• 1:50
  Zacznijmy od tego, co EntraID robi dobrze.
• 1:53
  To recepcja Twoich usług w chmurze.
• 1:55
  Wie, kim jesteś, sprawdza logowanie i decyduje, czy możesz wejść do Microsoft 365, Teams, SharePoint lub aplikacji biznesowej w chmurze.
• 2:01
  Logujesz się raz, a potem przechodzisz między usługami bez konieczności ciągłego wpisywania hasła.
• 2:06
  To właśnie logowanie jednokrotne SSO.
• 2:08
  EntraID może też wymagać drugiego etapu logowania przez uwierzytelnianie wieloskładnikowe, sprawdzać używane urządzenie, lokalizacje i zasady dostępu firmy.
• 2:17
  W przypadku nowoczesnych aplikacji ten model sprawdza się świetnie.
• 2:20
  Otwierasz przeglądarkę, aplikacja wysyła Cię do EntraID, logujesz się, zatwierdzasz powiadomienie na telefonie, a EntraID wysyła aplikacji bezpieczny komunikat logowania w tle.
• 2:28
  Aplikacja odczytuje ten komunikat i daje Ci dostęp.
• 2:30
  W tym modelu nie ma potrzeby dołączania do domeny używania starego systemu Windows Server ani wymagania, aby aplikacja przeszukiwała klasyczny katalog firmowy.
• 2:37
  Ale starsze aplikacje wyrosły w zupełnie innym świecie.
• 2:40
  Wyobraź sobie aplikację finansową, która od lat działa na Windows Server, gdzie użytkownicy logują się z komputerów przyłączonych do domeny.
• 2:45
  Aplikacja sprawdza dane pracowników przez LDAP, co jest powszechnym sposobem przeszukiwania katalogu firmy przez starsze oprogramowanie.
• 2:50
  Może wykorzystywać protokół Kerberos, starszą metodę logowania w systemie Windows, która pozwala systemom wzajemnie sobie ufać.
• 2:55
  Może polegać na zasadach grupy, czyli zestawie reguł firmowych, które pozwalają kontrolować ustawienia na komputerach z systemem Windows.
• 3:00
  Taka aplikacja nie potrafi odczytać nowoczesnego komunikatu logowania w chmurze.
• 3:03
  Oczekuje ona możliwości połączenia się przez sieć i znalezienia tradycyjnej domeny Windows.
• 3:07
  A jeśli jej nie znajdzie, aplikacja może nie zalogować użytkowników, nie znaleźć konta usługi lub po prostu odmówić uruchomienia.
• 3:12
  Pewnie widziałeś ten schemat również poza branżą IT.
• 3:15
  Nowe gniazdko elektryczne nie pomoże, jeśli wtyczka starego urządzenia nie pasuje.
• 3:18
  Pront jest dostępny, ale połączenie jest niewłaściwe.
• 3:21
  Wyobraź sobie teraz firmę przenoszącą tę aplikację finansową i jej bazę danych na maszyny wirtualne Azure.
• 3:25
  Serwery zostały przeniesione, ale stare potrzeby pozostały.
• 3:27
  Można zostawić Active Directory w biurze i połączyć Azure z powrotem za pomocą VPN, czyli prywatnego tunelu sieciowego.
• 3:33
  Wtedy aplikacja w Azure wysyła żądania przez to połączenie, kiedy tylko potrzebuje domeny.
• 3:37
  Może to działać, ale aplikacja jest teraz zależna od dostępności łącza sieciowego oraz lokalnego kontrolera domeny.
• 3:42
  A jeśli z tym połączeniem wystąpi problem, aplikacja w chmurze również może mieć problemy.
• 3:46
  Innym wyborem jest stworzenie własnych maszyn wirtualnych z kontrolerami domeny w Azure.
• 3:49
  Kontroler to serwer obsługujący tradycyjną domenę Active Directory, zarządzający katalogiem, logowaniami i innymi zadaniami domeny.
• 3:55
  To również działa, ale teraz Twój zespół zarządza większą liczbą serwerów.
• 3:58
  Ktoś musi je aktualizować i monitorować.
• 4:01
  Potrzebujesz kopii zapasowych, planów odzyskiwania, planu synchronizacji, kontrolerów domeny oraz ochrony uprzywilejowanych kont administratorów.
• 4:07
  Dla niektórych firm taka kontrola ma sens.
• 4:09
  Dla innych to dodatkowa praca tylko po to, by utrzymać starszą aplikację w działaniu.
• 4:13
  Luka jest więc dość wąska, ale całkiem realna.
• 4:15
  Aplikacja znajduje się w Azure, a mimo to wciąż mówi językiem starego Active Directory.
• 4:19
  Czym w rzeczywistości jest Microsoft Entra Domain Services, to zarządzana domena Windows działająca wewnątrz Twojej sieci Azure.
• 4:26
  To definicja w najprostszych słowach.
• 4:28
  Kontrolery domeny działają w tle, w pełni zarządzane przez firmę Microsoft, podczas gdy Twoje maszyny wirtualne Azure i starsze aplikacje korzystają ze znanych usług domnowych, których oczekują.
• 4:36
  Pomyśl o swojej konfiguracji w chmurze jak o budynku biurowym.
• 4:39
  Entra ID to przednia recepcja.
• 4:40
  Sprawdza, kim jesteś, gdy logujesz się do Microsoft 365 lub innej aplikacji w chmurze i stosuje firmowe zasady dotyczące tego logowania.
• 4:46
  Entra Domain Services znajduje się w zamkniętym biurze na zapleczu.
• 4:49
  Starsze systemy nie muszą odwiedzać tej recepcji tak, jak robi to nowoczesna aplikacja w chmurze.
• 4:53
  Potrzebują w pobliżu katalogu w starym stylu, który rozumie ich język i może odpowiedzieć na ich żądania.
• 4:57
  To biuro na zapleczu to domena zarządzana.
• 5:00
  Rzecz w tym, że nie musisz samodzielnie budować kontrolerów domeny.
• 5:02
  Nie logujesz się do nich za pomocą pulpitu zdalnego.
• 5:05
  Nie decydujesz, ile ich uruchomić, nie instalujesz na nich poprawek systemu Windows, ani nie zarządzasz połączeniami między nimi.
• 5:08
  Microsoft zajmuje się tym wszystkim.
• 5:10
  Twoim zadaniem jest połączenie odpowiednich maszyn wirtualnych Azure i aplikacji z domeną zarządzaną.
• 5:14
  Gdy zostaną połączone, mogą korzystać ze znanych usług Active Directory.
• 5:17
  Maszyna wirtualna z systemem Windows może dołączyć do domeny, a starsza aplikacja może używać LDAP do wyszukiwania osób grup i szczegółów katalogu.
• 5:23
  Może używać protokołu Kerberos, metody logowania, której starsze aplikacje biznesowe często oczekują, gdy jeden serwer musi ufać innemu.
• 5:29
  Może również używać NTLM, kolejnej starszej metody logowania do systemu Windows, której niektóre aplikacje wciąż wymagają.
• 5:33
  Domena zarządzana zapewnia również usługę DNS, która pomaga systemom znaleźć odpowiedni serwer po nazwie, a nie po ciągu cyfr.
• 5:39
  Obsługuje także zasady grupy, dzięki czemu można zastosować określone ustawienia systemu Windows do komputerów i użytkowników w tej domenie zarządzanej.
• 5:45
  Wiem, ta lista brzmi technicznie.
• 5:46
  Wyobraź sobie to raczej jako biurko tłumacza.
• 5:48
  Twoja aplikacja pyta w starym języku Windows, kim jest ten użytkownik.
• 5:52
  Czy ten serwer może ufać tamtemu serwerowi?
• 5:54
  Gdzie jest baza danych?
• 5:55
  Jakich ustawień powinien używać ten komputer?
• 5:57
  Entra Domain Services rozumie te pytania i udziela odpowiedzi, jakich oczekuje aplikacja, ale nie tworzy drugiej głównej listy pracowników.
• 6:04
  Główny rekord tożsamości pozostaje w Entra ID.
• 6:07
  Użytkownicy i grupy z Entra ID są kopiowani do domeny zarządzanej, dzięki czemu starsza aplikacja może ich widzieć i używać w formie, którą rozumie.
• 6:13
  Jeśli Twoja firma posiada również lokalną usługę Active Directory, tożsamości mogą już trafiać stamtąd do Entra ID, zanim zostaną skopiowane do Domain Services.
• 6:19
  Kierunek ma tutaj znaczenie.
• 6:20
  Szczegóły tożsamości przepływają do Entra Domain Services.
• 6:23
  Nie przepływają z powrotem, więc jeśli użytkownik pochodzi z Entra ID, zarządzasz nim w Entra ID.
• 6:28
  Jeśli użytkownik pierwotnie pochodzi z Twojej lokalnej usługi Active Directory, zarządzasz nim właśnie tam.
• 6:33
  Nie należy traktować usług domnowych jako miejsca do edycji głównego rekordu pracownika.
• 6:37
  Zapobiega to przekształceniu domeny zarządzanej w drugą kartotekę z różnymi wersjami tej samej osoby.
• 6:41
  Jest jednak jeden element, który zaskakuje wiele osób podczas konfiguracji – hasła.
• 6:45
  Nowoczesne logowanie do chmury i starsze logowanie do systemu Windows nie używają haseł w dokładnie taki sam sposób.
• 6:49
  Aby protokoły Kerberos i NTLM działały, usługi domnowe wymagają zabezpieczonej formy danych haseł, która obsługuje te starsze metody.
• 6:55
  Firma Microsoft nigdy nie przechowuje hasła w postaci zwykłego tekstu.
• 6:58
  Zamiast tego usługa potrzebuje odpowiednich zabezpieczonych informacji o haśle,
• 7:01
  zanim użytkownik będzie mógł zalogować się do maszyny wirtualnej dołączonej do domeny lub starszej aplikacji za pośrednictwem domeny zarządzanej.
• 7:06
  W przypadku użytkowników korzystających wyłącznie z chmury często oznacza to, że użytkownik musi zmienić hasło po włączeniu usług domnowych.
• 7:12
  Ta zmiana hasła tworzy zabezpieczoną formę wymaganą przez domeny zarządzaną.
• 7:15
  Dopóki to nie nastąpi, użytkownik może bez problemu zalogować się do usługi Microsoft 365, ale nie uda mu się skorzystać ze starszego stylu domeny.
• 7:22
  Na początku może się to wydawać dziwne.
• 7:24
  Użytkownik ma już konto, hasło działa, a mimo to starsza aplikacja nadal nie może z niego skorzystać.
• 7:29
  Brakującym elementem nie jest konto użytkownika.
• 7:31
  Jest nim zabezpieczona forma hasła wymagana przez te starsze metody logowania.
• 7:34
  Usługi domnowe mają również wyraźną granicę działania.
• 7:37
  Działają one wewnątrz sieci wirtualnej platformy Azure, często nazywanej siecią w net.
• 7:41
  Maszyny wirtualne Azure muszą mieć dostęp sieciowy do tej sieci w net i muszą używać ustawień DNS domeny zarządzanej, aby móc ją znaleźć.
• 7:47
  Nie jest to publiczny katalog, z którym może się skontaktować każde urządzenie w internecie.
• 7:50
  To prywatna usługa domnowa dla obciążeń podłączonych do odpowiedniej sieci Azure.
• 7:54
  Gdy aplikacja wymaga w Azure zachowania starej usługi Active Directory, usługi domnowe zapewniają zarządzane miejsce, w którym może ona znaleźć to zachowanie.
• 8:00
  To prowadzi nas do kolejnego pytania.
• 8:02
  Jak to się ma do Entra ID i istniejącej domeny Active Directory?
• 8:05
  Nazwy brzmią podobnie, ale ich zadania są bardzo różne.
• 8:09
  Entra ID, Active Directory i usługi domnowe.
• 8:12
  Różne zadania, nazwy są zbliżone, więc łatwo jest traktować je jako różne wersje tego samego produktu.
• 8:17
  Tak nie jest.
• 8:18
  Każda z nich obsługuje inną część tożsamości firmy, a gdy już poznasz zadania każdej z nich, wybór stanie się znacznie jaśniejszy.
• 8:24
  Entra ID obsługuje tożsamość w chmurze.
• 8:26
  Gdy otwierasz Microsoft 365, Teams, SharePoint lub nowoczesną aplikację biznesową, Entra ID weryfikuje, logowanie i kontroluje, do czego masz dostęp.
• 8:33
  Obsługuje również uwierzytelnianie wieloskładnikowe i reguły dostępu, takie jak wymuszanie silniejszej kontroli logowania podczas pracy z nieznanego urządzenia.
• 8:40
  Jest stworzona z myślą o usługach w chmurze.
• 8:42
  Nowoczesna aplikacja nie musi znajdować się w tej samej sieci, co Entra ID, ponieważ wykorzystuje internetowe metody logowania.
• 8:47
  Logujesz się przez przeglądarkę lub aplikację Entra ID potwierdza Twoją tożsamość, a aplikacja otrzymuje dowód, że masz uprawnienia dostępu.
• 8:53
  To standardowy model dla nowych aplikacji chmurowych.
• 8:55
  Active Directory Domain Services, często nazywany w skrócie Active Directory, pełni inną funkcję.
• 9:00
  To tradycyjna domena Windows, którą wiele firm utrzymuje we własnych biurach, centrach danych lub serwerowniach.
• 9:05
  Firma jest właścicielem kontrolerów domeny, decyduje o ich konfiguracji i zarządza całą domeną od podstaw.
• 9:10
  Może ona kontrolować komputery z systemem Windows, obsługiwać serwery lokalne i zapewniać starsze metody logowania, których wymagają długo działające aplikacje biznesowe.
• 9:16
  Taki poziom kontroli wiąże się z dużą odpowiedzialnością.
• 9:19
  Twój zespół ID zarządza domeną, dba o serwery i decyduje o tym, jak katalog ma funkcjonować w firmie.
• 9:24
  Entra Domain Services znajduje się pomiędzy tymi dwoma światami.
• 9:27
  Zapewnia obciążeniom w Azure zarządzaną domeny Windows, gdy wymagają one starszego zachowania Active Directory, przy czym Microsoft zajmuje się stroną kontrolerów domeny.
• 9:34
  Możesz korzystać z domeny dla maszyn wirtualnych Azure i starszych aplikacji, nie przejmując na siebie pełnego zadania prowadzenia tradycyjnej domeny Active Directory.
• 9:40
  Pomyśl o tym, jak o systemie kartotek.
• 9:42
  Entra ID przechowuje główny rejestr pracowników do pracy w chmurze.
• 9:46
  To tam firma przechowuje dokumentację używaną dla Microsoft 365 i nowoczesnych logowań chmurowych.
• 9:50
  Domain Services dostarcza starszym aplikacjom Azure kompatybilną kopię rejestrów, których potrzebują.
• 9:55
  Aplikacje te mogą otwierać znany im typ kartoteki i znajdować użytkowników, grupy oraz szczegóły logowania w starym formacie, które rozumieją.
• 10:01
  Nie musisz przebudowywać aplikacji tylko dlatego, że przeniosła się do Azure.
• 10:04
  Firma korzystająca wyłącznie z chmury również może użyć tej konfiguracji.
• 10:07
  Wyobraź sobie firmę, która nigdy nie korzystała z lokalnych kontrolerów domeny.
• 10:10
  Wszyscy logują się do Microsoft 365 przez Entra ID, a firma zaczyna używać maszyn wirtualnych Azure dla starszej aplikacji Windows.
• 10:16
  Firma ta nie musi tworzyć lokalnej domeny Active Directory tylko dla tej jednej aplikacji.
• 10:20
  Zamiast tego może użyć Entra Domain Services dla maszyn wirtualnych Azure wymagających zachowania domeny,
• 10:25
  podczas gdy reszta firmy nadal używa Entra ID do standardowej pracy w chmurze.
• 10:28
  Firma hybrydowa ma inny punkt wyjścia.
• 10:30
  Może już prowadzić Active Directory w swoim biurze z użytkownikami i grupami synchronizowanymi z Entra ID.
• 10:35
  Osoby te mogą następnie pojawić się w Entra Domain Services dla obciążeń działających w Azure.
• 10:39
  Przepływ wygląda następująco.
• 10:41
  Istniejące w firmie Active Directory przesyła szczegóły tożsamości do Entra ID,
• 10:45
  a Entra ID udostępnia kompatybilną kopię dla Domain Services.
• 10:48
  Nie oznacza to jednak, że Domain Services zastępuje oryginalną lokalną domenę.
• 10:52
  Biuro może nadal potrzebować własnej domeny Active Directory dla lokalnych komputerów,
• 10:56
  serwerów, systemów fabrycznych czy aplikacji pozostających na miejscu.
• 10:59
  Usługa Domain Services obsługuje tylko tę część platformy Azure,
• 11:01
  w której zarządzane zachowanie domeny w starym stylu pasuje do obciążenia.
• 11:04
  I nie zmienia ona również usługi Entra ID w pełnoprawną usługę Active Directory.
• 11:07
  Entra ID pozostaje chmurową usługą tożsamości.
• 11:10
  Domain Services dodaje zarządzaną domenę dla określonych starszych potrzeb,
• 11:13
  ale nie zapewnia wszystkich opcji i pełnej kontroli, jaką masz, gdy sam obsługujesz Active Directory.
• 11:18
  Wyobraź sobie więc trzy osobne zadania.
• 11:21
  Entra ID obsługuje nowoczesne logowania w chmurze.
• 11:23
  Active Directory obsługuje domeny Windows, którą Twoja firma prowadzi samodzielnie.
• 11:27
  Entra Domain Services obsługuje starsze obciążenia w Azure,
• 11:29
  które nadal wymagają domeny Windows bez konieczności samodzielnego utrzymywania kontrolerów domeny.
• 11:34
  Możesz zadać znacznie lepsze pytanie.
• 11:36
  Kiedy Domain Services pasuje do obciążenia, a kiedy należy wybrać coś innego?
• 11:40
  Kiedy Domain Services się sprawdza, a kiedy nie.
• 11:42
  Zacznij od aplikacji, a nie od nazwy produktu.
• 11:45
  Jeśli starsza aplikacja używa LDAP, czyli starego języka do sprawdzania nazw użytkowników i haseł,
• 11:49
  a Ty przenosisz ją do Azure, Domain Services może być świetnym rozwiązaniem.
• 11:52
  Aplikacja nadal używa tego, co już rozumie, bez konieczności pełnego przepisywania kodu.
• 11:56
  Ma to znaczenie, gdy aplikacja nadal działa, biznes jej potrzebuje,
• 11:58
  a przepisanie kodu logowania kosztowałoby zbyt wiele czasu lub pieniędzy.
• 12:01
  Inny, częsty scenariusz, grupa maszyn wirtualnych Azure musi zachowywać się jak zwykłe komputery domnowe.
• 12:06
  Personel może potrzebować logowania do systemu Windows przy użyciu swojego konta służbowego.
• 12:10
  Usługa może wymagać konta serwisowego konta, którego aplikacja używa do łączenia się z innym systemem, takim jak baza danych.
• 12:14
  Możesz potrzebować zasad grupy, aby zastosować ustawienia firmowe do tych maszyn wirtualnych.
• 12:18
  W takich przypadkach Domain Services zapewnia maszynom w Azure zachowanie domnowe, którego oczekują.
• 12:23
  Usługi pulpitu zdalnego również tutaj pasują.
• 12:25
  Wyobraź sobie pracowników łączących się ze współdzielonymi pulpitami lub aplikacjami Windows w Azure.
• 12:29
  Systemy te często polegają na domenie Windows w kwestii logowania użytkowników i zarządzania komputerami.
• 12:33
  Domain Services dostarcza tę warstwę domeny bez konieczności tworzenia od podstaw maszyn wirtualnych z kontrolerami domeny przez Twój zespół.
• 12:39
  Starsze aplikacje często składają się z więcej niż jednej części.
• 12:42
  Może to być serwer www z przodu, serwer aplikacji w środku i baza danych na zapleczu.
• 12:45
  Serwer aplikacji musi potwierdzić swoją tożsamość, zanim baza danych zaakceptuje połączenie.
• 12:50
  Jeśli to zaufanie opiera się na kontach serwisowych Windows, Domain Services utrzymuje te połączenia po przeniesieniu.
• 12:55
  Oto sedno, Twój zespół otrzymuje starsze zachowanie domeny, którego wymaga obciążenie, podczas gdy Microsoft zajmuje się pracą kontrolera domeny, która inaczej obciążałaby Twoją listę serwerów.
• 13:04
  Pamiętaj jednak, by nie wybierać Domain Services tylko dlatego, że używasz Azure.
• 13:07
  Nowa aplikacja w chmurze powinna logować się bezpośrednio przez EntraID.
• 13:10
  Jeśli obsługuje nowoczesne metody logowania, przekierowuje użytkowników do EntraID, otrzymuje potwierdzenie logowania i korzysta z zasad dostępu do chmury oraz uwierzytelniania wieloskładnikowego.
• 13:18
  To czystsza ścieżka dla nowego oprogramowania.
• 13:21
  Domain Services pomaga aplikacjom, które posługują się starym językiem.
• 13:25
  Nowe aplikacje tego starego języka.
• 13:26
  Istnieją również twarde ograniczenia, które należy najpierw sprawdzić.
• 13:29
  Niektóre aplikacje nie tylko odczytują dane z Active Directory, ale też zapisują je z powrotem.
• 13:33
  Na przykład aplikacja może chcieć tworzyć lub zmieniać wpisy w katalogu w ramach swojej normalnej pracy.
• 13:38
  Domain Services nie sprawdzi się, gdy aplikacja wymaga zapisu przez LDAP.
• 13:42
  To samo ostrzeżenie dotyczy sytuacji, gdy aplikacja musi zmienić schemat Active Directory, czyli zestaw pól określających, co katalog może przechowywać.
• 13:48
  Niektóre starsze programy wymagają dodania własnych pól przed uruchomieniem.
• 13:51
  Zarządzana domena nie pozwala na zmianę tego podstawowego projektu.
• 13:54
  Powinieneś się również zatrzymać, jeśli twój zespół potrzebuje pełnej kontroli nad samą domeną.
• 13:58
  Być może potrzebujesz bezpośredniego dostępu do kontrolerów domeny.
• 14:01
  Może potrzebujesz uprawnień administratora domeny, które dają bardzo szeroką kontrolę.
• 14:04
  A może potrzebujesz skomplikowanej struktury katalogu, którą chcesz zbudować i prowadzić po swojemu.
• 14:08
  Wtedy lepiej samodzielnie zarządzać Active Directory lokalnie lub na maszynach wirtualnych w Azure.
• 14:14
  Domain Services celowo zapewnia mniejszą kontrolę, ponieważ to Microsoft zarządza podstawową usługą domnową.
• 14:18
  Zadaj więc jedno proste pytanie, zanim wybierzesz ścieżkę.
• 14:21
  Czy to obciążenie potrzebuje starego języka Active Directory, czy może korzystać z nowoczesnego Entra ID?
• 14:26
  Jeśli może używać nowoczesnego Entra ID, zacznij od tego.
• 14:28
  Jeśli potrzebuje starego zachowania domeny, ale nie wymaga posiadania pełnej kontroli nad każdym jej elementem,
• 14:32
  Domain Services może być dobrym rozwiązaniem.
• 14:34
  A jeśli aplikacja musi zapisywać w katalogu, zmieniać jego schemat lub wymaga pełnej kontroli domeny,
• 14:39
  potrzebuje innego miejsca.
• 14:40
  Wybór zarządzanej domeny oznacza akceptację pewnego kompromisu.
• 14:43
  Microsoft zajmuje się kontrolerami domeny, a Ty rezygnujesz z części kontroli, którą masz przy samodzielnym ich prowadzeniu.
• 14:48
  Kompromisy zarządzanej usługi, o których musisz wiedzieć.
• 14:51
  Takie zarządzane podejście oszczędza pracę, ale zmienia również zakres kontroli Twojego zespołu ID.
• 14:55
  Microsoft obsługuje kontrolery domeny, utrzymuje je w synchronizacji, stosuje poprawki i dba o dostępność w tle.
• 15:00
  Nie musisz planować lokalizacji każdego kontrolera domeny, ani odzyskiwać go po awarii serwera.
• 15:05
  Dlatego wiele zespołów wybiera to rozwiązanie, ale nie masz dostępu zdalnego do tych kontrolerów
• 15:09
  i nie otrzymujesz uprawnień administratora domeny lub przedsiębiorstwa, ponieważ dawałyby one kontrolę nad elementami zarządzanymi przez Microsoft.
• 15:15
  Zamiast tego Microsoft udostępnia grupę o nazwie Entra Domain Services Administrators.
• 15:19
  Dodaj osoby, które mają zarządzać domeną do tej grupy, a następnie użyj maszyny wirtualnej do zarządzania dołączonej do domeny zarządzanej.
• 15:25
  Z poziomu tej maszyny możesz używać znanych narzędzi Active Directory do zarządzania tym, na co pozwala Microsoft.
• 15:30
  Na przykład możesz tworzyć własne jednostki organizacyjne, czyli OU.
• 15:33
  Traktuj je jak foldery na obiekty domnowe, takie jak komputery czy konta usług.
• 15:37
  Możesz zarządzać rekordami DNS oraz tworzyć i stosować zasady grupy dla obsługiwanych ustawień.
• 15:41
  Możesz również zarządzać komputerami dołączonymi do domeny, co często jest głównym powodem istnienia tej usługi.
• 15:45
  Te ograniczenia są celowe.
• 15:47
  Nie możesz dodawać kolejnych kontrolerów domeny, zmieniać schematu Active Directory,
• 15:50
  ani traktować domeny zarządzanej jako miejsca, z którego zmiany wracają do Entra ID.
• 15:54
  Dlatego zarządzanie użytkownikami i grupami należy zachować w katalogu źródłowym.
• 15:57
  Dla firmy korzystającej wyłącznie z chmury tym źródłem jest Entra ID.
• 16:00
  Dla firmy w modelu hybrydowym jest to lokalny Active Directory synchronizowany z Entra ID.
• 16:05
  Ta zasada zapobiega częstemu błędowi.
• 16:07
  Ktoś widzi użytkownika w domenie zarządzanej i wprowadza zmiany, zakładając, że zostaną one zapisane.
• 16:11
  Jednak ta zmiana nie stanie się rekordem firmy w Entra ID, ani w lokalnym Active Directory.
• 16:16
  Utrzymuj domenę zarządzaną jako prywatną wewnątrz sieci Azure.
• 16:19
  Powinna ona obsługiwać tylko potrzebne obciążenia, a nie być głównym katalogiem firmy.
• 16:23
  Ogranicz dostęp sieciowy, chroń maszynę do zarządzania i przyznawaj dostęp administratora tylko tym, którzy go potrzebują.
• 16:28
  Wybierasz usługę z określonymi zabezpieczeniami.
• 16:31
  Te zabezpieczenia zdejmują z Ciebie część pracy, jednocześnie uniemożliwiając zmianę elementów należących do Microsoftu.
• 16:36
  Prosta historia migracji do Azure.
• 16:38
  Wyobraź sobie firmę finansową korzystającą ze starej aplikacji na serwerach wewnątrz własnego biura.
• 16:42
  Ta aplikacja polega na LDAP przy wyszukiwaniu pracowników.
• 16:44
  Podczas logowania użytkowników korzysta z protokołu Kerberos,
• 16:46
  a jej serwer uwierzytelnia się za pomocą konta usługi, aby uzyskać dostęp do bazy danych finansowych.
• 16:50
  Firma chce przenieść zarówno aplikację, jak i bazę danych do maszyn wirtualnych Azure.
• 16:54
  Jedną z opcji jest utrzymanie połączenia aplikacji z domeną biurową przez VPN,
• 16:58
  ale wtedy aplikacja w Azure codziennie zależy od tego połączenia sieciowego i lokalnych kontrolerów domeny.
• 17:02
  Inną opcją jest uruchomienie nowych maszyn wirtualnych kontrolerów domeny w Azure.
• 17:06
  Dzięki temu więcej ruchu pozostaje wewnątrz Azure, ale dochodzą serwery Windows,
• 17:08
  które zespół IT musi aktualizować, monitorować, archiwizować i odzyskiwać.
• 17:12
  Zespół wybiera inne rozwiązanie.
• 17:13
  Ich użytkownicy i grupy są już synchronizowane z Entra ID.
• 17:16
  Włączają usługi do nowe Entra, podłączają wirtualną sieć Azure.