Gyakori használati esetek és forgatókönyvek Azure Active Directory Domain ServicesCommon use-cases and scenarios for Azure Active Directory Domain Services

Azure Active Directory Domain Services (Azure AD DS) olyan felügyelt tartományi szolgáltatásokat biztosít, mint például a tartományhoz való csatlakozás, a csoportházirend, a Lightweight Directory Access Protocol (LDAP) és a Kerberos/NTLM hitelesítés.Azure Active Directory Domain Services (Azure AD DS) provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos / NTLM authentication. Az Azure AD DS integrálható a meglévő Azure AD-Bérlővel, ami lehetővé teszi a felhasználók számára, hogy a meglévő hitelesítő adataikkal jelentkezzenek be.Azure AD DS integrates with your existing Azure AD tenant, which makes it possible for users to sign in using their existing credentials. Ezeket a tartományi szolgáltatásokat a tartományvezérlők üzembe helyezése, kezelése és javítása nélkül használhatja a felhőben, ami zökkenőmentesebb átállást biztosít a helyszíni erőforrások számára az Azure-ba.You use these domain services without the need to deploy, manage, and patch domain controllers in the cloud, which provides a smoother lift-and-shift of on-premises resources to Azure.

Ez a cikk néhány olyan gyakori üzleti forgatókönyvet mutat be, ahol az Azure AD DS értékkel rendelkezik, és megfelel ezeknek az igényeknek.This article outlines some common business scenarios where Azure AD DS provides value and meets those needs.

A Felhőbeli identitási megoldások nyújtásának gyakori módjaiCommon ways to provide identity solutions in the cloud

Amikor meglévő számítási feladatokat telepít át a felhőbe, a címtárat támogató alkalmazások LDAP-t használhatnak a helyszíni AD DS-címtárhoz való olvasási vagy írási hozzáféréshez.When you migrate existing workloads to the cloud, directory-aware applications may use LDAP for read or write access to an on-premises AD DS directory. A Windows Serveren futó alkalmazások jellemzően tartományhoz csatlakoztatott virtuális gépeken (VM-EK) vannak telepítve, hogy biztonságosan felügyelhetők legyenek Csoportházirend használatával.Applications that run on Windows Server are typically deployed on domain-joined virtual machines (VMs) so they can be managed securely using Group Policy. A végfelhasználók hitelesítéséhez az alkalmazások Windows-integrált hitelesítéssel is támaszkodhatnak, például Kerberos-vagy NTLM-hitelesítéssel.To authenticate end users, the applications may also rely on Windows-integrated authentication, such as Kerberos or NTLM authentication.

A rendszergazdák gyakran használják az alábbi megoldások egyikét az Azure-ban futó alkalmazások azonosítására:IT administrators often use one of the following solutions to provide an identity service to applications that run in Azure:

  • Helyek közötti VPN-kapcsolat konfigurálása az Azure-ban és egy helyszíni AD DS környezetben futó munkaterhelések között.Configure a site-to-site VPN connection between workloads that run in Azure and an on-premises AD DS environment.
    • A helyszíni tartományvezérlők ezután a VPN-kapcsolaton keresztül biztosítják a hitelesítést.The on-premises domain controllers then provide authentication via the VPN connection.
  • Hozzon létre replika tartományvezérlőket az Azure Virtual Machines (VM) használatával, hogy kiterjessze a AD DS tartományt/erdőt a helyszíni környezetből.Create replica domain controllers using Azure virtual machines (VMs) to extend the AD DS domain / forest from on-premises.
    • Az Azure-beli virtuális gépeken futó tartományvezérlők hitelesítést biztosítanak, és címtáradatokat replikálnak a helyszíni AD DS környezet között.The domain controllers that run on Azure VMs provide authentication, and replicate directory information between the on-premises AD DS environment.
  • Önálló AD DS-környezet üzembe helyezése az Azure-ban Azure-beli virtuális gépeken futó tartományvezérlők használatával.Deploy a standalone AD DS environment in Azure using domain controllers that run on Azure VMs.
    • Az Azure-beli virtuális gépeken futó tartományvezérlők hitelesítést biztosítanak, de a helyszíni AD DS környezetből nem replikálódnak a címtáradatok.The domain controllers that run on Azure VMs provide authentication, but there's no directory information replicated from an on-premises AD DS environment.

Ezekkel a megközelítésekkel a helyszíni címtárhoz való VPN-kapcsolatok sebezhetővé teszik az alkalmazásokat az átmeneti hálózati hibák és kimaradások tekintetében.With these approaches, VPN connections to the on-premises directory make applications vulnerable to transient network glitches or outages. Ha a tartományvezérlőket az Azure-beli virtuális gépek használatával telepíti, az informatikai csapatnak kezelnie kell a virtuális gépeket, majd biztonságossá, javítani, figyelnie, biztonsági mentést kell készítenie és elhárítani azokat.If you deploy domain controllers using VMs in Azure, the IT team must manage the VMs, then secure, patch, monitor, backup, and troubleshoot them.

Az Azure AD DS alternatívákat biztosít a VPN-kapcsolatok helyszíni AD DS környezetbe való visszaállításához, illetve a virtuális gépek Azure-beli futtatásához és kezeléséhez az Identity Services biztosításához.Azure AD DS offers alternatives to the need to create VPN connections back to an on-premises AD DS environment or run and manage VMs in Azure to provide identity services. Felügyelt szolgáltatásként az Azure AD DS csökkenti az összetettséget, hogy integrált identitás-megoldást hozzon létre mind a hibrid, mind a csak felhőalapú környezetekhez.As a managed service, Azure AD DS reduces the complexity to create an integrated identity solution for both hybrid and cloud-only environments.

Azure-AD DS hibrid szervezeteknélAzure AD DS for hybrid organizations

Számos szervezet olyan hibrid infrastruktúrát futtat, amely magában foglalja a Felhőbeli és a helyszíni alkalmazások számítási feladatait is.Many organizations run a hybrid infrastructure that includes both cloud and on-premises application workloads. A lift és a SHIFT stratégia részeként az Azure-ba migrált örökölt alkalmazások hagyományos LDAP-kapcsolatokat használhatnak az azonosító adatok biztosításához.Legacy applications migrated to Azure as part of a lift and shift strategy may use traditional LDAP connections to provide identity information. A hibrid infrastruktúra támogatásához a helyszíni AD DS-környezetből származó azonosító adatokat szinkronizálhatja egy Azure AD-Bérlővel.To support this hybrid infrastructure, identity information from an on-premises AD DS environment can be synchronized to an Azure AD tenant. Az Azure AD DS ezeket az örökölt alkalmazásokat az Azure-ban identitás-forrással biztosítja, anélkül, hogy konfigurálni és kezelni kellene az alkalmazások kapcsolatait a helyszíni címtárszolgáltatások számára.Azure AD DS then provides these legacy applications in Azure with an identity source, without the need to configure and manage application connectivity back to on-premises directory services.

Tekintsük át például a Litware Corporation, egy hibrid szervezet, amely a helyszíni és az Azure-erőforrásokat is futtatja:Let's look at an example for Litware Corporation, a hybrid organization that runs both on-premises and Azure resources:

Azure Active Directory Domain Services a helyszíni szinkronizálást tartalmazó hibrid szervezetek számára

  • A tartományi szolgáltatásokat igénylő alkalmazások és kiszolgálói munkaterhelések üzembe helyezése az Azure-beli virtuális hálózaton történik.Applications and server workloads that require domain services are deployed in a virtual network in Azure.
    • Ebbe beletartozhatnak az Azure-ba migrált örökölt alkalmazások a felvonó és a váltási stratégia részeként.This may include legacy applications migrated to Azure as part of a lift and shift strategy.
  • A helyszíni címtárból az Azure AD-bérlőre való adatszinkronizáláshoz a Litware Corporation üzembe helyezi Azure ad Connect.To synchronize identity information from their on-premises directory to their Azure AD tenant, Litware Corporation deploys Azure AD Connect.
    • A szinkronizált azonosító adatok felhasználói fiókokat és csoporttagságokat tartalmaznak.Identity information that is synchronized includes user accounts and group memberships.
  • A Litware IT csapata lehetővé teszi, hogy az Azure AD DS az Azure AD-bérlője számára, vagy egy egyenrangú virtuális hálózatot.Litware's IT team enables Azure AD DS for their Azure AD tenant in this, or a peered, virtual network.
  • Az Azure Virtual Networkben üzembe helyezett alkalmazások és virtuális gépek ezután az Azure AD DS funkcióit használhatják, például a tartományhoz való csatlakozás, az LDAP-olvasás, az LDAP-kötés, az NTLM és a Kerberos-hitelesítés, valamint a Csoportházirend.Applications and VMs deployed in the Azure virtual network can then use Azure AD DS features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

Fontos

A Azure AD Connect csak a helyszíni AD DS környezetekkel való szinkronizálásra kell telepíteni és konfigurálni.Azure AD Connect should only be installed and configured for synchronization with on-premises AD DS environments. A felügyelt tartományokban való Azure AD Connect telepítése nem támogatott az objektumok Azure AD-be való visszaszinkronizálásához.It's not supported to install Azure AD Connect in a managed domain to synchronize objects back to Azure AD.

Azure-AD DS csak felhőalapú szervezeteknekAzure AD DS for cloud-only organizations

A csak felhőalapú Azure AD-bérlő nem rendelkezik helyszíni Identity forrással.A cloud-only Azure AD tenant doesn't have an on-premises identity source. A felhasználói fiókok és csoporttagságok például közvetlenül az Azure AD-ben jönnek létre és kezelhetők.User accounts and group memberships, for example, are created and managed directly in Azure AD.

Most nézzük meg a contoso egy példáját, amely egy csak felhőalapú szervezet, amely az Azure AD-t használja az identitáshoz.Now let's look at an example for Contoso, a cloud-only organization that uses Azure AD for identity. Az Azure AD-ben az összes felhasználói identitás, a hitelesítő adatai és a csoporttagságok is létrejönnek és kezelhetők.All user identities, their credentials, and group memberships are created and managed in Azure AD. A helyszíni címtárból származó összes identitási információ szinkronizálása nem Azure AD Connect további konfigurációval.There is no additional configuration of Azure AD Connect to synchronize any identity information from an on-premises directory.

Azure Active Directory Domain Services csak felhőalapú szervezet számára helyszíni szinkronizálás nélkül

  • A tartományi szolgáltatásokat igénylő alkalmazások és kiszolgálói munkaterhelések üzembe helyezése az Azure-beli virtuális hálózaton történik.Applications and server workloads that require domain services are deployed in a virtual network in Azure.
  • A contoso informatikai csapata lehetővé teszi, hogy az Azure AD DS az Azure AD-bérlője számára, vagy egy társ virtuális hálózatot.Contoso's IT team enables Azure AD DS for their Azure AD tenant in this, or a peered, virtual network.
  • Az Azure Virtual Networkben üzembe helyezett alkalmazások és virtuális gépek ezután az Azure AD DS funkcióit használhatják, például a tartományhoz való csatlakozás, az LDAP-olvasás, az LDAP-kötés, az NTLM és a Kerberos-hitelesítés, valamint a Csoportházirend.Applications and VMs deployed in the Azure virtual network can then use Azure AD DS features like domain join, LDAP read, LDAP bind, NTLM and Kerberos authentication, and Group Policy.

Azure-beli virtuális gépek biztonságos felügyeleteSecure administration of Azure virtual machines

Az Active Directory-beli hitelesítő adatok egyetlen készletének használatához az Azure Virtual Machines (VM) csatlakoztatható egy Azure AD DS felügyelt tartományhoz.To let you use a single set of AD credentials, Azure virtual machines (VMs) can be joined to an Azure AD DS managed domain. Ez a megközelítés csökkenti a hitelesítő adatok kezelésével kapcsolatos problémákat, például a helyi rendszergazdai fiókok karbantartását minden virtuális gépen, illetve a különböző fiókokat és jelszavakat.This approach reduces credential management issues such as maintaining local administrator accounts on each VM or separate accounts and passwords between environments.

A felügyelt tartományhoz csatlakoztatott virtuális gépeket a csoportházirend használatával is felügyelheti és biztonságossá teheti.VMs that are joined to a managed domain can also be administered and secured using group policy. A szükséges biztonsági alaptervek alkalmazhatók a virtuális gépekre, hogy a vállalati biztonsági irányelveknek megfelelően zárolják őket.Required security baselines can be applied to VMs to lock them down in accordance with corporate security guidelines. A Csoportházirend kezelése funkció segítségével például korlátozhatja a virtuális gépen indítható alkalmazások típusát.For example, you can use group policy management capabilities to restrict the types of applications that can be launched on the VM.

Azure-beli virtuális gépek egyszerűbb felügyelete

Nézzük meg egy gyakori példát.Let's look at a common example scenario. Mivel a kiszolgálók és más infrastruktúra eléri a teljes élettartamot, a contoso a helyileg üzemeltetett alkalmazásokat szeretné áthelyezni a felhőbe.As servers and other infrastructure reaches end-of-life, Contoso wants to move applications currently hosted on premises to the cloud. Az aktuális IT standard megbízatása szerint a vállalati alkalmazásokat üzemeltető kiszolgálóknak tartományhoz kell csatlakozniuk, és a csoportházirend használatával kell felügyelni őket.Their current IT standard mandates that servers hosting corporate applications must be domain-joined and managed using group policy.

A contoso informatikai rendszergazdája szívesebben szeretné az Azure-ban üzembe helyezett virtuális gépeket csatlakozni a felügyelet megkönnyítéséhez, mivel a felhasználók a vállalati hitelesítő adataikkal jelentkezhetnek be.Contoso's IT administrator would prefer to domain join VMs deployed in Azure to make administration easier as users can then sign in using their corporate credentials. A tartományhoz csatlakoztatott virtuális gépek úgy is konfigurálhatók, hogy a csoportházirend-objektumok (GPO-k) használatával betartsák a szükséges biztonsági alapterveket.When domain-joined, VMs can also be configured to comply with required security baselines using group policy objects (GPOs). A contoso szívesebben nem helyezheti üzembe, figyelheti és felügyelheti saját tartományvezérlőit az Azure-ban.Contoso would prefer not to deploy, monitor, and manage their own domain controllers in Azure.

Az Azure AD DS kiválóan alkalmas ehhez a használati esethez.Azure AD DS is a great fit for this use-case. A felügyelt tartományok lehetővé teszi a tartományhoz való csatlakozást, a hitelesítő adatok egyetlen készletének használatát és a csoportházirend alkalmazását.A managed domain lets you domain-join VMs, use a single set of credentials, and apply group policy. Mivel ez egy felügyelt tartomány, nem kell önállóan konfigurálnia és fenntartania a tartományvezérlőket.And because it's a managed domain, you don't have to configure and maintain the domain controllers yourself.

Üzembe helyezési megjegyzésekDeployment notes

A következő üzembe helyezési szempontok vonatkoznak erre a példa használatára:The following deployment considerations apply to this example use case:

  • A felügyelt tartományok alapértelmezés szerint egyetlen, lapos szervezeti egység (OU) struktúrát használnak.Managed domains use a single, flat Organizational Unit (OU) structure by default. Minden tartományhoz csatlakoztatott virtuális gép egyetlen szervezeti egységben található.All domain-joined VMs are in a single OU. Ha szükséges, létrehozhat Egyéni szervezeti egységeketis.If desired, you can create custom OUs.
  • Az Azure AD DS egy beépített csoportházirend-objektumot használ a felhasználók és számítógépek tárolók számára.Azure AD DS uses a built-in GPO each for the users and computers containers. További szabályozáshoz létrehozhat egyéni csoportházirend-objektumokat , és megcélozhatja azokat egyéni szervezeti egységekre.For additional control, you can create custom GPOs and target them to custom OUs.
  • Az Azure AD DS támogatja az alapszintű AD számítógép-objektum sémáját.Azure AD DS supports the base AD computer object schema. A számítógép-objektum sémája nem terjeszthető ki.You can't extend the computer object's schema.

LDAP-kötési hitelesítést használó helyszíni alkalmazások átemelése és átirányításaLift-and-shift on-premises applications that use LDAP bind authentication

Példaként a contoso egy olyan helyszíni alkalmazást tartalmaz, amelyet számos éve vásárolt egy ISV-ben.As a sample scenario, Contoso has an on-premises application that was purchased from an ISV many years ago. Az alkalmazás jelenleg karbantartási módban van az ISV számára, és az alkalmazás módosításainak kérelmezése megfizethetetlenül drága.The application is currently in maintenance mode by the ISV and requesting changes to the application is prohibitively expensive. Az alkalmazás webes felülettel rendelkezik, amely webes űrlap használatával gyűjti a felhasználói hitelesítő adatokat, majd a helyszíni AD DS környezethez LDAP-kötést hajt végre.This application has a web-based frontend that collects user credentials using a web form and then authenticates users by performing an LDAP bind to the on-premises AD DS environment.

LDAP-kötés

A contoso szeretné áttelepíteni az alkalmazást az Azure-ba.Contoso would like to migrate this application to Azure. Az alkalmazásnak továbbra is működőképesnek kell lennie, és nincs szükség módosításra.The application should continue to works as-is, with no changes needed. Emellett a felhasználóknak a meglévő vállalati hitelesítő adataikkal és további képzés nélkül kell tudniuk hitelesíteni magukat.Additionally, users should be able to authenticate using their existing corporate credentials and without additional training. Transzparensnek kell lennie az alkalmazást futtató végfelhasználók számára.It should be transparent to end users where the application is running.

Ebben az esetben az Azure AD DS lehetővé teszi, hogy az alkalmazások LDAP-kötéseket végezzenek a hitelesítési folyamat részeként.For this scenario, Azure AD DS lets applications perform LDAP binds as part of the authentication process. A régi helyszíni alkalmazások a konfiguráció vagy a felhasználói élmény módosítása nélkül is elvégezhetik az Azure-ba való áttérést és a felhasználók zökkenőmentes hitelesítését.Legacy on-premises applications can lift-and-shift into Azure and continue to seamlessly authenticate users without any change in configuration or user experience.

Üzembe helyezési megjegyzésekDeployment notes

A következő üzembe helyezési szempontok vonatkoznak erre a példa használatára:The following deployment considerations apply to this example use case:

  • Győződjön meg arról, hogy az alkalmazásnak nem kell módosítania/írnia a könyvtárat.Make sure that the application doesn't need to modify/write to the directory. A felügyelt tartományokhoz való LDAP-írási hozzáférés nem támogatott.LDAP write access to a managed domain isn't supported.
  • A jelszavakat nem módosíthatja közvetlenül egy felügyelt tartományon.You can't change passwords directly against a managed domain. A végfelhasználók módosíthatják a jelszavukat az Azure ad önkiszolgáló jelszó-módosítási mechanizmusával vagy a helyszíni címtárral.End users can change their password either using Azure AD's self-service password change mechanism or against the on-premises directory. Ezeket a módosításokat a rendszer automatikusan szinkronizálja és elérhetővé a felügyelt tartományban.These changes are then automatically synchronized and available in the managed domain.

Az LDAP-t használó helyszíni alkalmazások átemelése a címtár eléréséhezLift-and-shift on-premises applications that use LDAP read to access the directory

Az előző példához hasonlóan tegyük fel, hogy a contoso egy olyan helyszíni üzletági (LOB) alkalmazással rendelkezik, amelyet majdnem egy évtizeden át fejlesztettünk ki.Like the previous example scenario, let's assume Contoso has an on-premises line-of-business (LOB) application that was developed almost a decade ago. Ez az alkalmazás a címtárral tisztában van, és a rendszer az LDAP használatával olvasta el a felhasználókkal kapcsolatos információkat és attribútumokat AD DS.This application is directory aware and was designed to use LDAP to read information/attributes about users from AD DS. Az alkalmazás nem módosítja az attribútumokat, vagy más módon ír a könyvtárba.The application doesn't modify attributes or otherwise write to the directory.

A contoso szeretné áttelepíteni ezt az alkalmazást az Azure-ba, és kivonni az alkalmazást futtató, a helyszíni helyi hardvert.Contoso wants to migrate this application to Azure and retire the aging on-premises hardware currently hosting this application. Az alkalmazás nem írható át olyan modern címtár-API-k használatára, mint például a REST-alapú Microsoft Graph API.The application can't be rewritten to use modern directory APIs such as the REST-based Microsoft Graph API. A rendszer egy emelt szintű váltási lehetőséget választ arra az esetre, ha az alkalmazás a felhőben való futtatásra, kód módosítása vagy az alkalmazás átírása nélkül telepíthető.A lift-and-shift option is desired where the application can be migrated to run in the cloud, without modifying code or rewriting the application.

Ebben az esetben az Azure AD DS lehetővé teszi, hogy az alkalmazások LDAP-olvasási műveleteket végezzenek a felügyelt tartományon, hogy megkapják a szükséges attribútum-információkat.To help with this scenario, Azure AD DS lets applications perform LDAP reads against the managed domain to get the attribute information it needs. Az alkalmazást nem kell újraírni, így az Azure-ba való átállással a felhasználók továbbra is használhatják az alkalmazást anélkül, hogy megtörtént a futtatásuk.The application doesn't need to be rewritten, so a lift-and-shift into Azure lets users continue to use the app without realizing there's a change in where it runs.

Üzembe helyezési megjegyzésekDeployment notes

A következő üzembe helyezési szempontok vonatkoznak erre a példa használatára:The following deployment considerations apply to this example use case:

  • Győződjön meg arról, hogy az alkalmazásnak nem kell módosítania/írnia a könyvtárat.Make sure that the application doesn't need to modify/write to the directory. A felügyelt tartományokhoz való LDAP-írási hozzáférés nem támogatott.LDAP write access to a managed domain isn't supported.
  • Győződjön meg arról, hogy az alkalmazásnak nincs szüksége egyéni/kiterjesztett Active Directory sémára.Make sure that the application doesn't need a custom/extended Active Directory schema. A séma-bővítmények nem támogatottak az Azure AD DSban.Schema extensions aren't supported in Azure AD DS.

Helyszíni szolgáltatás vagy Daemon-alkalmazás migrálása az Azure-baMigrate an on-premises service or daemon application to Azure

Néhány alkalmazás több szintet is tartalmaz, amelyekben az egyik rétegnek hitelesített hívásokat kell végrehajtania egy háttérrendszer-réteghez, például egy adatbázishoz.Some applications include multiple tiers, where one of the tiers needs to perform authenticated calls to a backend tier, such as a database. Az AD-szolgáltatásfiókok általában ezekben a forgatókönyvekben használatosak.AD service accounts are commonly used in these scenarios. Ha az Azure-ba emelt szintű alkalmazásokat helyez át, az Azure AD DS lehetővé teszi, hogy a szolgáltatásfiókok ugyanúgy működjenek.When you lift-and-shift applications into Azure, Azure AD DS lets you continue to use service accounts in the same way. Azt is megteheti, hogy ugyanazt a szolgáltatásfiókot használja, amelyet a helyszíni címtárból az Azure AD-ba Szinkronizál, vagy létrehozhat egy egyéni szervezeti egységet, majd létrehoz egy külön szolgáltatásfiókot a szervezeti egységben.You can choose to use the same service account that is synchronized from your on-premises directory to Azure AD or create a custom OU and then create a separate service account in that OU. Mindkét módszer esetében az alkalmazások továbbra is ugyanúgy működnek, mint a hitelesített hívásokat más rétegekbe és szolgáltatásokra.With either approach, applications continue to function the same way to make authenticated calls to other tiers and services.

Szolgáltatásfiók a WIA használatával

Ebben a példában a contoso egy egyéni kialakítású, a webes kezelőfelülettel, egy SQL Server-kiszolgálóval és egy háttérbeli FTP-kiszolgálóval elkészített szoftver-tároló alkalmazást tartalmaz.In this example scenario, Contoso has a custom-built software vault application that includes a web front end, a SQL server, and a backend FTP server. A Windows-alapú hitelesítés a szolgáltatásfiókok használatával hitelesíti a webes előtért az FTP-kiszolgáló felé.Windows-integrated authentication using service accounts authenticates the web front end to the FTP server. A webes kezelőfelület úgy van beállítva, hogy szolgáltatásfiókként fusson.The web front end is set up to run as a service account. A háttér-kiszolgáló úgy van konfigurálva, hogy engedélyezze a hozzáférést a webes kezelőfelülethez tartozó szolgáltatásfiók számára.The backend server is configured to authorize access from the service account for the web front end. A contoso nem szeretné telepíteni és felügyelni a saját tartományvezérlő virtuális gépeket a felhőben az alkalmazás Azure-ba való áthelyezéséhez.Contoso doesn't want to deploy and manage their own domain controller VMs in the cloud to move this application to Azure.

Ebben az esetben a webes előtért, az SQL Servert és az FTP-kiszolgálót futtató kiszolgálók áttelepíthetők az Azure-beli virtuális gépekre, és egy felügyelt tartományhoz csatlakoznak.For this scenario, the servers hosting the web front end, SQL server, and the FTP server can be migrated to Azure VMs and joined to a managed domain. A virtuális gépek ezután ugyanazt a szolgáltatásfiókot használhatják a helyszíni címtárban az alkalmazás hitelesítési céljaihoz, amelyet az Azure AD-val szinkronizál a Azure AD Connect használatával.The VMs can then use the same service account in their on-premises directory for the app's authentication purposes, which is synchronized through Azure AD using Azure AD Connect.

Üzembe helyezési megjegyzésekDeployment notes

A következő üzembe helyezési szempontok vonatkoznak erre a példa használatára:The following deployment considerations apply to this example use case:

  • Győződjön meg arról, hogy az alkalmazások felhasználónevet és jelszót használnak a hitelesítéshez.Make sure that the applications use a username and password for authentication. Az Azure AD DS nem támogatja a tanúsítvány-vagy intelligenskártya-alapú hitelesítést.Certificate or smartcard-based authentication isn't supported by Azure AD DS.
  • A jelszavakat nem módosíthatja közvetlenül egy felügyelt tartományon.You can't change passwords directly against a managed domain. A végfelhasználók módosíthatják a jelszavukat az Azure ad önkiszolgáló jelszó-módosítási mechanizmusával vagy a helyszíni címtárral.End users can change their password either using Azure AD's self-service password change mechanism or against the on-premises directory. Ezeket a módosításokat a rendszer automatikusan szinkronizálja és elérhetővé a felügyelt tartományban.These changes are then automatically synchronized and available in the managed domain.

Windows Server Távoli asztali szolgáltatások üzembe helyezése az Azure-banWindows Server remote desktop services deployments in Azure

Az Azure AD DS használatával felügyelt tartományi szolgáltatásokat biztosíthat az Azure-ban üzembe helyezett távoli asztali kiszolgálókhoz.You can use Azure AD DS to provide managed domain services to remote desktop servers deployed in Azure.

További információ erről az üzembe helyezési forgatókönyvről: Azure ad Domain Services integrálása az RDS-környezettel.For more information about this deployment scenario, see how to integrate Azure AD Domain Services with your RDS deployment.

Tartományhoz csatlakoztatott HDInsight-fürtökDomain-joined HDInsight clusters

Beállíthat egy olyan Azure HDInsight-fürtöt, amely egy felügyelt tartományhoz van csatlakoztatva, és engedélyezve van az Apache Ranger.You can set up an Azure HDInsight cluster that is joined to a managed domain with Apache Ranger enabled. Az Apache Ranger segítségével hozhat létre és alkalmazhat kaptár-házirendeket, és lehetővé teheti a felhasználók, például az adatszakértők számára, hogy az ODBC-alapú eszközök, például az Excel vagy a tabló használatával csatlakozzanak a Kaptárhoz.You can create and apply Hive policies through Apache Ranger, and allow users, such as data scientists, to connect to Hive using ODBC-based tools like Excel or Tableau. Továbbra is dolgozunk további munkaterhelések, például a HBase, a Spark és a Storm hozzáadásával a tartományhoz csatlakoztatott HDInsight.We continue to work to add other workloads, such as HBase, Spark, and Storm to domain-joined HDInsight.

További információ erről az üzembe helyezési forgatókönyvről: tartományhoz csatlakoztatott HDInsight-fürtök konfigurálásaFor more information about this deployment scenario, see how to configure domain-joined HDInsight clusters

Következő lépésekNext steps

Első lépésként hozzon létre és konfiguráljon egy Azure Active Directory Domain Services felügyelt tartományt.To get started, Create and configure an Azure Active Directory Domain Services managed domain.