Migracja starszych aplikacji do Azure: kiedy wybrać Microsoft Entra Domain Services, a kiedy kontrolery domeny IaaS

By Mirko Peters · 2026-08-14

Porównaj Microsoft Entra Domain Services z kontrolerami domeny IaaS w Azure. Poznaj kompromisy architektoniczne przy migracji starszych aplikacji.

Automatically translated with AI from the original post. Read the English original

Podczas przenoszenia starszych aplikacji Windows do Azure architekci stają przed istotnym dylematem dotyczącym tożsamości: czy wdrożyć tradycyjne maszyny wirtualne z kontrolerami domeny Active Directory, czy skorzystać z zarządzanych usług chmurowych? Ten przewodnik omawia kompromisy architektoniczne, obciążenie operacyjne i koszty wyboru Microsoft Entra Domain Services zamiast własnych kontrolerów domeny IaaS dla starszych obciążeń w Azure.

Najważniejsze wnioski

• Microsoft Entra Domain Services zapewnia zarządzane możliwości tradycyjnej domeny Windows, bez konieczności wdrażania, aktualizowania ani odzyskiwania maszyn wirtualnych z kontrolerami domeny przez zespoły IT.
• Wdrożenie kontrolerów domeny IaaS w Azure daje administratorom pełną kontrolę, w tym dostęp RDP i uprawnienia Domain Admin, ale znacząco zwiększa obciążenie operacyjne.
• Starsze obciążenia korzystające z LDAP, Kerberos, NTLM lub zasad grupy mogą bezproblemowo działać w Azure dzięki zarządzanej warstwie zgodności z domeną.
• Entra Domain Services wymusza ścisły, jednokierunkowy model synchronizacji tożsamości, w którym rekordy użytkowników trzeba zarządzać w ich autorytatywnym źródle, a nie bezpośrednio w domenie zarządzanej.
• Wybór właściwej architektury tożsamości w dużym stopniu zależy od wymagań aplikacji, takich jak dostęp do zapisu LDAP i modyfikacje schematu.

Dylemat migracji starszych aplikacji do Azure

Przeniesienie starszej aplikacji biznesowej z lokalnej serwerowni na maszynę wirtualną Azure nie sprawia automatycznie, że aplikacja staje się natywnie chmurowa. Wiele sprawdzonych aplikacji Windows – takich jak starsze systemy ERP, platformy finansowe czy niestandardowe aplikacje .NET – powstało z myślą o tradycyjnym Active Directory. Gdy te obciążenia trafiają do chmury, nadal oczekują, że będą odpytywać usługi katalogowe przez LDAP, uwierzytelniać się biletami Kerberos lub stosować ustawienia za pomocą zasad grupy.

Architekci chmurowi od razu muszą podjąć strategiczną decyzję. Można połączyć sieć wirtualną Azure z lokalnymi kontrolerami domeny za pomocą hybrydowego tunelu VPN, ale rozwiązanie to wprowadza opóźnienia i tworzy niebezpieczny pojedynczy punkt awarii, jeśli łącze zostanie przerwane. Alternatywnie można uruchomić w Azure nowe maszyny wirtualne z systemem Windows Server, podnieść je do roli kontrolerów domeny i zbudować zupełnie nowy las lub domenę replikacyjną.

Samodzielne tworzenie maszyn wirtualnych z kontrolerami domeny w Azure daje pełną kontrolę, ale jednocześnie zamienia zespół infrastruktury chmurowej w administratorów Active Directory. Odpowiadasz wtedy w całości za aktualizacje systemu operacyjnego, monitorowanie replikacji katalogu, planowanie odzyskiwania po awarii oraz zabezpieczanie kont o wysokich uprawnieniach przed kradzieżą poświadczeń. W organizacjach, które chcą ograniczyć obciążenie operacyjne, przy jednoczesnym utrzymaniu działania starszych aplikacji, bywa to niepotrzebnym obciążeniem.

Entra Domain Services a kontrolery domeny IaaS: kluczowe różnice architektoniczne

Zrozumienie architektonicznej różnicy między korzystaniem z Microsoft Entra Domain Services a budowaniem własnych kontrolerów domeny IaaS jest kluczowe dla projektowania odpornych środowisk chmurowych w Azure. Entra Domain Services działa jako zarządzana warstwa zgodności. Microsoft uruchamia i utrzymuje infrastrukturę kontrolerów domeny w tle, zapewniając wysoką dostępność, automatyczne kopie zapasowe i synchronizację w tle z Entra ID.

Gdy korzystasz z Entra Domain Services, maszyny wirtualne Azure mogą dołączać do domeny, wykonywać zapytania LDAP oraz obsługiwać logowania Kerberos lub NTLM, bez konieczności łączenia się pulpitem zdalnym z kontrolerem domeny przez Twoich inżynierów. Ten kompromis związany z usługą zarządzaną oznacza jednak, że rezygnujesz z bezpośredniej kontroli administracyjnej. Nie masz dostępu do bazowego systemu operacyjnego, nie możesz modyfikować schematu Active Directory i nie otrzymujesz uprawnień Domain Admin ani Enterprise Admin.

Z kolei wdrożenie kontrolerów domeny IaaS daje pełną kontrolę nad architekturą katalogu. Możesz rozszerzać schemat, konfigurować niestandardowe relacje zaufania, dodawać dowolne jednostki organizacyjne i wdrażać wyspecjalizowane obiekty zasad grupy bez ograniczeń. Ceną tej elastyczności jest utrzymanie. Twój zespół musi zarządzać całym cyklem życia domeny, w tym proaktywnymi kontrolami stanu, defragmentacją bazy danych oraz awaryjnymi procedurami przywracania, gdy kontroler domeny ulegnie awarii.

Kompromisy operacyjne i ograniczenia administracyjne

Zanim zdecydujesz się na zarządzane rozwiązanie domeny w Azure, administratorzy chmury muszą dokładnie ocenić, jak zmienią się codzienne operacje. Przy własnych kontrolerach domeny IaaS Twój zespół ma szczegółową kontrolę nad każdym aspektem katalogu. Możesz pisać własne skrypty PowerShell do automatyzacji zadań administracyjnych, instalować bezpośrednio na kontrolerach domeny agentów zabezpieczeń innych producentów oraz diagnozować błędy replikacji za pomocą natywnych narzędzi, takich jak repadmin.

Microsoft Entra Domain Services zastępuje to bezpośrednie podejście zarządzanymi ograniczeniami. Administracja odbywa się za pośrednictwem dedykowanej grupy o nazwie Entra Domain Services Administrators, przy użyciu narzędzi do zarządzania zainstalowanych na osobnej maszynie wirtualnej z systemem Windows, dołączonej do domeny. Choć możesz tworzyć niestandardowe jednostki organizacyjne, zarządzać rekordami DNS i stosować obsługiwane ustawienia zasad grupy, to jesteś ściśle odcięty od podstawowej infrastruktury.

Ponadto zarządzanie tożsamościami opiera się na ścisłym modelu jednokierunkowej synchronizacji. Tożsamości użytkowników i grup płyną ze źródła autorytatywnego — czy to użytkowników wyłącznie w chmurze w Entra ID, czy zsynchronizowanych tożsamości z lokalnego Active Directory — do zarządzanej domeny. Nigdy nie należy traktować Entra Domain Services jako głównego katalogu do modyfikowania atrybutów użytkowników, ponieważ te zmiany nie zsynchronizują się z powrotem i w końcu zostaną nadpisane.

Ramy decyzyjne: wybór właściwej architektury

Wybór odpowiedniego podejścia wymaga oceny szczegółowych wymagań technicznych organizacji oraz długoterminowej strategii chmurowej. Jeśli Twoim głównym celem jest migracja starszych obciążeń do Azure przy jednoczesnym wyeliminowaniu kosztu operacyjnego utrzymywania maszyn wirtualnych z Windows Server jako kontrolerów domeny, usługa zarządzana jest niemal zawsze preferowaną drogą.

Użyj Microsoft Entra Domain Services, gdy:

• Migrujesz do Azure starsze aplikacje, które wymagają odczytu w LDAP, obsługi Kerberos, NTLM lub możliwości dołączania do domeny.
• Twoja organizacja chce uniknąć nakładu pracy związanego z aktualizowaniem, monitorowaniem i odzyskiwaniem niestandardowych maszyn wirtualnych kontrolerów domeny w Azure.
• Działasz jako organizacja, która najpierw stawia na chmurę lub działa wyłącznie w chmurze, i potrzebujesz tradycyjnych usług domenowych dla niewielkiego podzbioru obciążeń Azure, bez budowania lokalnej infrastruktury.
• Aplikacje wymagają standardowego stosowania zasad grupy lub zarządzania kontami usług w bezpiecznej sieci wirtualnej.

Wybierz własne kontrolery domeny IaaS, gdy:

• Twoje starsze aplikacje wymagają zapisu w LDAP lub wymagają modyfikacji schematu Active Directory.
• Architektura Twojego przedsiębiorstwa wymaga złożonych lasów wielodomenowych, niestandardowych konfiguracji zaufania lub bezpośredniego dostępu do systemów operacyjnych kontrolerów domeny.
• Zespół bezpieczeństwa wymaga pełnej kontroli administracyjnej, w tym uprawnień Enterprise Admin oraz bezpośredniego wdrażania wyspecjalizowanych narzędzi do audytu katalogu.

Podsumowanie i kolejne kroki

Projektowanie solidnej architektury tożsamości w Azure wymaga dopasowania każdego obciążenia do dokładnie takiego modelu uwierzytelniania, jakiego potrzebuje. Nowoczesne aplikacje chmurowe korzystają z Microsoft Entra ID, aby zapewnić bezpieczne logowanie jednokrotne opoparte na tokenach oraz uwierzytelnianie wieloskładnikowe, natomiast starsze obciążenia często wymagają tradycyjnych usług domenowych systemu Windows. Decyzja, czy wdrożyć zarządzane usługi chmurowe, czy zbudować własną infrastrukturę IaaS, determinuje bieżące obciążenie operacyjne Twojego zespołu.

Aby zgłębić ten temat i poznać opinie ekspertów na temat bezpieczeństwa nowoczesnego miejsca pracy, architektury chmurowej i strategii Microsoft 365, posłuchaj pełnej dyskusji w podcaście. Posłuchaj całego odcinka, aby dowiedzieć się więcej o zarządzaniu tożsamością w Microsoft.

Często zadawane pytania

Czy mogę połączyć się przez RDP z kontrolerami domeny, korzystając z Entra Domain Services?

Nie. Microsoft w pełni zarządza infrastrukturą kontrolerów domeny, co oznacza, że nie masz administracyjnego dostępu do systemu operacyjnego ani możliwości zdalnego połączenia z pulpitem kontrolerów domeny.

Co się dzieje z hasłami użytkowników po włączeniu Entra Domain Services?

Aby uwierzytelnianie Kerberos i NTLM działało poprawnie, Entra Domain Services wymaga specjalnych danych skrótów haseł. W przypadku użytkowników wyłącznie chmurowych zwykle oznacza to, że po włączeniu zarządzanej domeny użytkownicy muszą zmienić hasło, aby zostały wygenerowane niezbędne skróty kryptograficzne.

Czy mogę modyfikować schemat Active Directory w Entra Domain Services?

Nie. Ponieważ jest to w pełni zarządzana usługa chmurowa, administratorzy nie mogą zmieniać bazowego schematu Active Directory ani wykonywać operacji zapisu LDAP modyfikujących podstawowe struktury katalogu.

Jak tożsamości są synchronizowane z Entra Domain Services?

Tożsamości przepływają jednokierunkowo ze źródła autorytatywnego (Entra ID dla użytkowników chmurowych lub lokalnego Active Directory za pośrednictwem Entra Connect) do zarządzanej domeny. Zmiany wprowadzone bezpośrednio w zarządzanej domenie nie są synchronizowane z powrotem do źródła.