A Microsoft Entra ID konfigurálása felhasználók LDAP-címtárakba való kiépítéséhez

Az alábbi dokumentáció konfigurációs és oktatóanyagi információkat tartalmaz, amely bemutatja, hogyan építhet ki felhasználókat a Microsoft Entra ID-ból egy LDAP-címtárba.

Ez a dokumentum ismerteti azokat a lépéseket, amelyekre szükség van ahhoz, hogy a felhasználók automatikusan kiépíthessenek és kiépíthessenek felhasználókat a Microsoft Entra ID-ból egy LDAP-címtárba. A dokumentum bemutatja, hogyan építhet ki felhasználókat az AD LDS-be példa LDAP-címtárként, de az alábbi szakaszokban említett támogatott LDAP-címtárkiszolgálók bármelyikébe kiépíthet. A felhasználók Active Directory tartományi szolgáltatások való üzembe helyezése ebben a megoldásban nem támogatott.

A szolgáltatás működéséről, működéséről és a gyakori kérdésekről további információt a Microsoft Entra ID azonosítóval és helyszíni alkalmazáskiépítési architektúrával rendelkező SaaS-alkalmazások felhasználói kiépítésének és leépítésének automatizálása című témakörben talál. Az alábbi videó áttekintést nyújt a helyszíni kiépítésről.

A felhasználók LDAP-címtárba való kiépítésének előfeltételei

Helyszíni előfeltételek

  • Olyan alkalmazás, amely címtárkiszolgálót használ a felhasználók lekérdezéséhez.
  • A Active Directory tartományi szolgáltatások kivételével egy célkönyvtár, amelyben a felhasználók létrehozhatók, frissíthetők és törölhetők. Például: Active Directory Lightweight Services (AD LDS). Ez a címtárpéldány nem lehet olyan könyvtár, amely a felhasználók Microsoft Entra-azonosítóba való kiépítésére is használható, mivel mindkét forgatókönyv létrehozhat egy hurkot a Microsoft Entra Csatlakozás.
  • Olyan számítógép, amely legalább 3 GB RAM-mal rendelkezik egy kiépítési ügynök üzemeltetéséhez. A számítógépnek Windows Server 2016-os vagy újabb Windows Server-verzióval kell rendelkeznie, a célkönyvtárhoz való kapcsolódással, valamint a login.microsoftonline.com, más Microsoft Online Services - és Azure-tartományokkal való kimenő kapcsolattal. Ilyen például az Azure IaaS-ben vagy proxy mögött üzemeltetett Windows Server 2016 rendszerű virtuális gép.
  • A .NET-keretrendszer 4.7.2-t telepíteni kell.
  • Nem kötelező: Bár nem kötelező, javasoljuk, hogy töltse le a Windows Serverhez készült Microsoft Edge-et, és használja azt az Internet Explorer helyett.

Támogatott LDAP-címtárkiszolgálók

Az összekötő különböző technikákra támaszkodik az LDAP-kiszolgáló észleléséhez és azonosításához. Az összekötő a gyökér D Standard kiadás, a gyártó neve/verziója alapján vizsgálja meg a sémát, hogy egyedi objektumokat és attribútumokat találjon, amelyek bizonyos LDAP-kiszolgálókon ismertek.

  • OpenLDAP
  • Microsoft Active Directory Lightweight Directory Services
  • 389 Címtárkiszolgáló
  • Apache Directory Server
  • IBM Tivoli DS
  • Isode Directory
  • NetIQ eDirectory
  • Novell eDirectory
  • DJ megnyitása
  • A DS megnyitása
  • Oracle (korábban Sun ONE) címtárkiszolgáló Enterprise kiadás
  • RadiantOne Virtual Directory Server (VDS)

További információkért lásd az általános LDAP-Csatlakozás or-hivatkozást.

Felhőkövetelmények

  • Microsoft Entra-bérlő P1 vagy Prémium P2 azonosítóval (vagy EMS E3 vagy E5).

    A funkció használatához Microsoft Entra ID P1-licencek szükségesek. Az Ön igényeinek megfelelő licenc megtalálásához lásd: A Microsoft Entra ID általánosan elérhető funkcióinak összehasonlítása.

  • A hibrid identitás Rendszergazda istrator szerepkör a kiépítési ügynök és az alkalmazás Rendszergazda istrator vagy felhőalkalmazási Rendszergazda istrator szerepkör konfigurálásához az Azure Portalon való üzembe helyezés konfigurálásához.

  • Az LDAP-címtárba kiosztandó Microsoft Entra-felhasználókat már fel kell tölteni a címtárkiszolgáló sémája által megkövetelt és az egyes felhasználókra jellemző attribútumokkal. Ha például a címtárkiszolgáló megköveteli, hogy minden felhasználó egyedi számmal rendelkezzen 10000 és 30000 között a POSIX-számítási feladatok támogatásához, akkor vagy létre kell hoznia ezt a számot egy meglévő attribútumból a felhasználón, vagy ki kell terjesztenie a Microsoft Entra sémát, és ki kell töltenie ezt az attribútumot a felhasználókon az LDAP-alapú alkalmazás hatókörében. További címtárbővítmények létrehozásához lásd a Graph bővíthetőségét .

További javaslatok és korlátozások

Az alábbi listajelek további javaslatokat és korlátozásokat jelentenek.

  • Nem ajánlott ugyanazt az ügynököt használni a felhőszinkronizáláshoz és a helyszíni alkalmazások kiépítéséhez. A Microsoft azt javasolja, hogy használjon külön ügynököt a felhőszinkronizáláshoz, egyet pedig a helyszíni alkalmazások kiépítéséhez.
  • Az AD LDS esetében jelenleg a felhasználók nem építhetők ki jelszavakkal. Ezért le kell tiltania az AD LDS jelszószabályzatát, vagy letiltott állapotban kell kiépítenie a felhasználókat.
  • Más címtárkiszolgálók esetében megadhat egy kezdeti véletlenszerű jelszót, de a Microsoft Entra-felhasználó jelszavát nem lehet kiépíteni egy címtárkiszolgálón.
  • Nem támogatott felhasználók kiépítése a Microsoft Entra-azonosítóból a Active Directory-tartomány s Services szolgáltatásba.
  • A felhasználók LDAP-ból Microsoft Entra-azonosítóba történő kiépítése nem támogatott.
  • A csoportok és a felhasználói tagságok címtárkiszolgálóra történő kiépítése nem támogatott.

Futtatási profilok kiválasztása

Amikor létrehozza az összekötő konfigurálását a címtárkiszolgálóval való interakcióhoz, először konfigurálja, hogy az összekötő beolvassa a címtár sémáját, megfelelteti a sémát a Microsoft Entra-azonosítóhoz, majd konfigurálja azt a megközelítést, amelyet az összekötőnek folyamatosan használnia kell, futtatási profilokon keresztül. Minden konfigurálni kívánt futtatási profil meghatározza, hogy az összekötő hogyan fog LDAP-kéréseket létrehozni az adatok címtárkiszolgálóról való importálására vagy exportálására. Mielőtt üzembe helyeznénk az összekötőt egy meglévő címtárkiszolgálón, meg kell beszélnünk a szervezet címtárkiszolgáló-operátorával a címtárkiszolgálóval végrehajtandó műveletek mintáját.

  • A konfigurálás után a kiépítési szolgáltatás elindulásakor automatikusan végrehajtja a Teljes importálás futtatási profilban konfigurált interakciókat. Ebben a futtatási profilban az összekötő egy LDAP-keresési művelettel beolvassa a címtár felhasználóinak összes rekordjában. Erre a futtatási profilra azért van szükség, hogy később, ha a Microsoft Entra-azonosítónak módosítania kell egy felhasználót, a Microsoft Entra-azonosító a felhasználó meglévő objektumát frissíti a címtárban, ahelyett, hogy új objektumot hozna létre a felhasználó számára.

  • Minden alkalommal, amikor módosításokat hajtanak végre a Microsoft Entra-azonosítóban, például új felhasználót rendelnek hozzá az alkalmazáshoz, vagy frissítenek egy meglévő felhasználót, a kiépítési szolgáltatás végrehajtja az LDAP-interakciókat az Exportálás futtatási profilban. Az Exportálási profilban a Microsoft Entra ID ldAP-kéréseket fog kiadni a címtárban lévő objektumok hozzáadására, módosítására, eltávolítására vagy átnevezésére annak érdekében, hogy a címtár tartalma szinkronban legyen a Microsoft Entra-azonosítóval.

  • Ha a címtár támogatja azt, a Delta Import futtatási profilt is konfigurálhatja. Ebben a futtatási profilban a Microsoft Entra-azonosító a címtárban végrehajtott módosításokat olvassa be, a Microsoft Entra ID azonosítótól eltérően, az utolsó teljes vagy változásimportálás óta. Ez a futtatási profil nem kötelező, mivel előfordulhat, hogy a címtár nem lett konfigurálva a változásimportálás támogatására. Ha például a szervezet OpenLDAP-t használ, az OpenLDAP-t a hozzáférési napló átfedési funkciójának engedélyezésével kell üzembe helyezni.

Annak meghatározása, hogy a Microsoft Entra LDAP Csatlakozás or hogyan fogja használni a címtárkiszolgálót

Mielőtt üzembe helyeznénk az összekötőt egy meglévő címtárkiszolgálón, meg kell beszélnünk a szervezet címtárkiszolgáló-operátorával, hogyan integrálható a címtárkiszolgálóval. Az összegyűjtött információk közé tartoznak a címtárkiszolgálóhoz való csatlakozás hálózati információi, az összekötőnek a címtárkiszolgálóhoz való hitelesítése, a címtárkiszolgáló által a felhasználók modellezéséhez kiválasztott séma, az elnevezési környezet alap megkülönböztető neve és a címtárhierarchia szabályai, a címtárkiszolgáló felhasználóinak a Microsoft Entra ID-beli felhasználókhoz való társítása, és mi történjen, ha egy felhasználó kiesik a hatókörből a Microsoft Entra-azonosítóban. Az összekötő üzembe helyezéséhez szükség lehet a címtárkiszolgáló konfigurációjának módosítására, valamint a Microsoft Entra ID konfigurációjának módosítására. Ha a Microsoft Entra ID-t egy külső címtárkiszolgálóval integrálja éles környezetben, javasoljuk, hogy az ügyfelek a címtárkiszolgáló szállítójával vagy egy üzembe helyezési partnerrel együttműködve segítsenek, útmutatást és támogatást nyújthassanak az integrációhoz. Ez a cikk a következő mintaértékeket használja két könyvtárhoz, az AD LDS-hez és az OpenLDAP-hoz.

Konfigurációs beállítás Ahol az érték be van állítva Példaérték
a címtárkiszolgáló állomásneve Konfigurációs varázsló Csatlakozás ivity lapja APP3
a címtárkiszolgáló portszáma Konfigurációs varázsló Csatlakozás ivity lapja 636. SSL-en vagy TLS-en (LDAPS) keresztüli LDAP esetén használja a 636-os portot. Ehhez Start TLShasználja a 389-s portot.
fiók az összekötő számára, hogy azonosítsa magát a címtárkiszolgálón Konfigurációs varázsló Csatlakozás ivity lapja Az AD LDS és CN=svcAccountLDAP,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab az OpenLDAP esetében cn=admin,dc=contoso,dc=lab
az összekötő jelszava a címtárkiszolgálón való hitelesítéshez Konfigurációs varázsló Csatlakozás ivity lapja
szerkezeti objektumosztály egy felhasználó számára a címtárkiszolgálón Konfigurációs varázsló Objektumtípusok lapja Az AD LDS User és az OpenLDAP esetében inetOrgPerson
segédobjektumosztályok egy felhasználó számára a címtárkiszolgálón Az Azure Portal kiépítési oldalattribútum-leképezései OpenLDAP esetén a POSIX-sémával, posixAccount ésshadowAccount
új felhasználó által feltöltendő attribútumok Konfigurációs varázsló – Attribútumok kiválasztása lap és Az Azure Portal kiépítési lapattribútum-leképezései Az AD LDSmsDS-UserAccountDisabled, userPrincipalNameés displayName az OpenLDAP cnesetében, gidNumber, homeDirectory, mail, objectClass, sn, uiduidNumber,userPassword
a címtárkiszolgáló által megkövetelt elnevezési hierarchia Az Azure Portal kiépítési oldalattribútum-leképezései Az újonnan létrehozott felhasználó DN-jének beállítása közvetlenül az CN=CloudUsers,CN=App,DC=Contoso,DC=lab AD LDS és DC=Contoso,DC=lab az OpenLDAP esetében
attribútumok a felhasználók Microsoft Entra-azonosítóval és címtárkiszolgálóval való korrelálásához Az Azure Portal kiépítési oldalattribútum-leképezései Az AD LDS esetében nincs konfigurálva, mivel ez a példa egy eredetileg üres könyvtárhoz és az OpenLDAP-hez készült, mail
deprovisioning behavior when a user goes out of scope in Microsoft Entra ID Konfigurációs varázsló – Leépítés lap A felhasználó törlése a címtárkiszolgálóról

A címtárkiszolgáló hálózati címe állomásnév és TCP-portszám, általában 389-es vagy 636-os port. Kivéve, ha a címtárkiszolgáló ugyanazon a Windows Serveren található az összekötővel együtt, vagy hálózati szintű biztonságot használ, az összekötő és a címtárkiszolgáló közötti hálózati kapcsolatokat SSL vagy TLS használatával kell védeni. Az összekötő támogatja a 389-s porton lévő címtárkiszolgálóhoz való csatlakozást, és a TLS indítása a TLS engedélyezéséhez a munkameneten belül. Az összekötő támogatja a címtárkiszolgálóhoz való csatlakozást a 636-os porton az LDAPS – LDAP TLS-en keresztül.

Az összekötőnek azonosított fiókkal kell rendelkeznie ahhoz, hogy a címtárkiszolgálón már konfigurált címtárkiszolgálón hitelesíthesse magát. Ez a fiók általában megkülönböztető névvel van azonosítva, és társított jelszóval vagy ügyféltanúsítvánnyal rendelkezik. A csatlakoztatott címtárban lévő objektumok importálási és exportálási műveleteinek elvégzéséhez az összekötőfióknak megfelelő engedélyekkel kell rendelkeznie a címtár hozzáférés-vezérlési modelljében. Az összekötőnek írási engedélyekkel kell rendelkeznie az exportáláshoz, és olvasási engedélyekkel kell rendelkeznie az importáláshoz. Az engedélykonfiguráció a célkönyvtár felügyeleti funkcióin belül történik.

A címtárséma azokat az objektumosztályokat és attribútumokat határozza meg, amelyek a címtárban egy valós entitást képviselnek. Az összekötő támogatja a szerkezeti objektumosztályokkal képviselt felhasználókat, például inetOrgPerson, és opcionálisan további kiegészítő objektumosztályokat is. Annak érdekében, hogy az összekötő kiépíthesse a felhasználókat a címtárkiszolgálón, az Azure Portal konfigurációja során a Microsoft Entra-sémából az összes kötelező attribútumra vonatkozó leképezéseket kell meghatároznia. Ide tartoznak a szerkezeti objektumosztály kötelező attribútumai, a szerkezeti objektumosztály bármely szuperosztálya, valamint a kiegészítő objektumosztályok kötelező attribútumai. Emellett valószínűleg az osztályok választható attribútumaihoz is konfigurálja a leképezéseket. Előfordulhat például, hogy egy OpenLDAP címtárkiszolgálóhoz egy új felhasználó objektuma olyan attribútumokkal rendelkezik, mint az alábbi példa.

dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password

A címtárkiszolgáló által implementált címtárhierarchiaszabályok azt írják le, hogy az egyes felhasználók objektumai hogyan kapcsolódnak egymáshoz és a címtárban lévő meglévő objektumokhoz. A legtöbb üzemelő példányban a szervezet úgy döntött, hogy egy lapos hierarchiával rendelkezik a címtárkiszolgálón, amelyben az egyes felhasználók minden objektuma közvetlenül egy közös alapobjektum alatt található. Ha például az elnevezési környezet alap megkülönböztető neve egy címtárkiszolgálón, dc=contoso,dc=com akkor egy új felhasználónak megkülönböztető neve van, például cn=alice,dc=contoso,dc=com. Előfordulhat azonban, hogy egyes szervezetek összetettebb címtárhierarchiával rendelkeznek, ebben az esetben az összekötő megkülönböztető névleképezésének megadásakor végre kell hajtania a szabályokat. Előfordulhat például, hogy a címtárkiszolgálók részlegenként szervezeti egységekben fogják a felhasználókat, így egy új felhasználó neve olyan megkülönböztető, mint a cn=alice,ou=London,dc=contoso,dc=com. Mivel az összekötő nem hoz létre köztes objektumokat a szervezeti egységekhez, a címtárkiszolgálói szabályhierarchiában elvárt köztes objektumoknak már létezniük kell a címtárkiszolgálón.

Ezután meg kell határoznia az összekötő meghatározásának szabályait, hogy van-e már felhasználó a Microsoft Entra-felhasználónak megfelelő címtárkiszolgálón. Minden LDAP-címtárnak van egy megkülönböztető neve, amely a címtárkiszolgáló minden objektumára egyedi, azonban ez a megkülönböztető név gyakran nem jelenik meg a Microsoft Entra-azonosítóban lévő felhasználók számára. Ehelyett előfordulhat, hogy egy szervezet más attribútummal rendelkezik, például mailemployeeIda címtárkiszolgáló sémájában, amely szintén megtalálható a felhasználókon a Microsoft Entra ID-ban. Ezután, amikor az összekötő új felhasználót helyez üzembe egy címtárkiszolgálón, az összekötő rákereshet arra, hogy van-e már olyan felhasználó a címtárban, aki rendelkezik az adott attribútummal, és csak akkor hozzon létre új felhasználót a címtárkiszolgálón, ha nincs jelen.

Ha a forgatókönyvben új felhasználókat kell létrehozni az LDAP-címtárban, és nem csak a meglévő felhasználókat kell frissíteni vagy törölni, akkor azt is meg kell határoznia, hogy a címtárkiszolgálót használó alkalmazások hogyan fogják kezelni a hitelesítést. Az ajánlott módszer az, hogy az alkalmazások összevonási vagy SSO-protokollt (például SAML, OAuth vagy OpenID Csatlakozás) használnak a Microsoft Entra ID-hitelesítéshez, és csak attribútumokra támaszkodnak a címtárkiszolgálón. Az alkalmazások hagyományosan ldAP-címtárakat használhatnak a felhasználók jelszó ellenőrzésével történő hitelesítésére, de ez a használati eset nem használható többtényezős hitelesítéshez, vagy ha a felhasználó hitelesítése már megtörtént. Egyes alkalmazások lekérdezhetik a felhasználó SSH nyilvános kulcsát vagy tanúsítványát a címtárból, ami megfelelő lehet, ha a felhasználók már rendelkeznek az űrlapok hitelesítő adataival. Ha azonban a címtárkiszolgálóra támaszkodó alkalmazás nem támogatja a modern hitelesítési protokollokat vagy az erősebb hitelesítő adatokat, akkor egy alkalmazásspecifikus jelszót kell beállítania egy új felhasználó létrehozásakor a címtárban, mivel a Microsoft Entra-azonosító nem támogatja a felhasználó Microsoft Entra-jelszavának kiépítését.

Végül meg kell egyeznie a leépítési viselkedésről. Ha az összekötő konfigurálva van, és a Microsoft Entra ID kapcsolatot létesített a Microsoft Entra-azonosítóban szereplő felhasználó és a címtár egy felhasználója között, akár már a címtárban lévő, akár egy új felhasználó számára, a Microsoft Entra ID képes attribútummódosításokat kiépíteni a Microsoft Entra-felhasználótól a címtárba. Ha az alkalmazáshoz rendelt felhasználó törölve van a Microsoft Entra-azonosítóban, akkor a Microsoft Entra ID törlési műveletet küld a címtárkiszolgálónak. Azt is kérheti, hogy a Microsoft Entra ID frissítse az objektumot a címtárkiszolgálón, amikor egy felhasználó túllépi az alkalmazás használatának hatókörét. Ez a viselkedés a címtárkiszolgálót használó alkalmazástól függ, mivel előfordulhat, hogy számos címtár , például az OpenLDAP nem tudja alapértelmezetten jelezni, hogy a felhasználó fiókja inaktiválva van.

Az LDAP-címtár előkészítése

Ha még nem rendelkezik címtárkiszolgálóval, és ki szeretné próbálni ezt a funkciót, akkor az Active Directory Lightweight Directory Services előkészítése a Microsoft Entra ID-ból való üzembe helyezéshez bemutatja, hogyan hozhat létre teszt AD LDS-környezetet. Ha már üzembe helyezett egy másik címtárkiszolgálót, kihagyhatja ezt a cikket, és folytathatja az ECMA-összekötő gazdagépének telepítését és konfigurálását.

A Microsoft Entra Csatlakozás kiépítési ügynök telepítése és konfigurálása

Ha már letöltötte a kiépítési ügynököt, és konfigurálta egy másik helyszíni alkalmazáshoz, folytassa az olvasást a következő szakaszban.

  1. Jelentkezzen be az Azure Portalra.
  2. Nyissa meg az Enterprise-alkalmazásokat, és válassza az Új alkalmazás lehetőséget.
  3. Keresse meg a helyszíni ECMA alkalmazásalkalmazást, adjon nevet az alkalmazásnak, és válassza a Létrehozás lehetőségeta bérlőhöz való hozzáadásához.
  4. A menüben lépjen az alkalmazás kiépítési oldalára.
  5. Válassza az Első lépések lehetőséget.
  6. A Kiépítés lapon módosítsa a módot automatikusra.

Képernyőkép az Automatikus beállításról.

  1. A Helyszíni Csatlakozás ivity területen válassza a Letöltés és telepítés, majd a Feltételek elfogadása > letöltés lehetőséget.

Képernyőkép az ügynök letöltési helyéről.

  1. Hagyja el a portált, nyissa meg a kiépítési ügynök telepítőt, fogadja el a szolgáltatási feltételeket, és válassza a Telepítés lehetőséget.
  2. Várja meg a Microsoft Entra kiépítési ügynök konfigurációs varázslóját, majd válassza a Tovább gombot.
  3. A Bővítmény kiválasztása lépésben válassza a Helyszíni alkalmazás kiépítését, majd a Tovább lehetőséget.
  4. A kiépítési ügynök az operációs rendszer webböngészőjét használja egy előugró ablak megjelenítéséhez, amely lehetővé teszi a Microsoft Entra-azonosítóval való hitelesítést, valamint a szervezet identitásszolgáltatóját is. Ha Az Internet Explorert használja böngészőként a Windows Serveren, akkor előfordulhat, hogy a JavaScript megfelelő futtatásához hozzá kell adnia a Microsoft-webhelyeket a böngésző megbízható webhelylistájához.
  5. Adja meg a Microsoft Entra rendszergazdájának hitelesítő adatait, amikor a rendszer kéri az engedélyezést. A felhasználónak hibrid identitás Rendszergazda istrator vagy globális Rendszergazda istrator szerepkörre van szüksége.
  6. A beállítás megerősítéséhez válassza a Megerősítés lehetőséget. Miután a telepítés sikeres volt, kiválaszthatja a Kilépés lehetőséget, és bezárhatja a Kiépítési ügynökcsomag telepítőt is.

A helyszíni ECMA-alkalmazás konfigurálása

  1. A portál helyszíni Csatlakozás ivity szakaszában válassza ki az üzembe helyezett ügynököt, és válassza az Ügynök(ek) hozzárendelése lehetőséget.

    Képernyőkép a kiválasztásról és az ügynök kijelöléséről és hozzárendeléséről.

  2. Tartsa nyitva ezt a böngészőablakot, miközben a konfiguráció következő lépését a konfigurációs varázslóval hajtja végre.

A Microsoft Entra ECMA Csatlakozás or gazdagéptanúsítvány konfigurálása

  1. Azon a Windows Serveren, amelyen a kiépítési ügynök telepítve van, kattintson a jobb gombbal a Microsoft ECMA2Host konfigurációs varázslóra a start menüből, és futtassa rendszergazdaként. A varázslónak Windows-rendszergazdaként kell futnia a szükséges Windows-eseménynaplók létrehozásához.
  2. Az ECMA Csatlakozás or gazdagépkonfigurációjának elindítása után, ha ez az első alkalom, hogy futtatja a varázslót, a rendszer megkéri, hogy hozzon létre egy tanúsítványt. Hagyja meg az alapértelmezett 8585-ös portot, és válassza a Tanúsítvány létrehozása lehetőséget a tanúsítvány létrehozásához. Az automatikusan létrehozott tanúsítvány önaláírt lesz a megbízható gyökér részeként. A SAN megegyezik a gazdagép nevével. A beállítások konfigurálását bemutató képernyőkép.
  3. Válassza a Mentés parancsot.

Feljegyzés

Ha úgy döntött, hogy új tanúsítványt hoz létre, jegyezze fel a tanúsítvány lejárati dátumát, hogy biztosan visszatérjen a konfigurációs varázslóhoz, és a lejárat előtt hozza létre újra a tanúsítványt.

Általános LDAP-összekötő konfigurálása

A kiválasztott beállításoktól függően előfordulhat, hogy a varázsló egyes képernyői nem érhetők el, és az információk kissé eltérőek lehetnek. A példakonfiguráció alkalmazásában az AD LDS esetében a felhasználók felhasználói objektumosztályral való kiépítése, az OpenLDAP inetOrgPerson objektumosztálya pedig megjelenik. Az alábbi információk segítségével útmutatást kaphat a konfigurációhoz.

  1. Hozzon létre egy titkos jogkivonatot, amely a Microsoft Entra-azonosítónak az összekötőhöz való hitelesítéséhez lesz használva. A karakternek legalább 12 karakternek kell lennie, és minden alkalmazáshoz egyedinek kell lennie. Ha még nem rendelkezik titkos kódgenerátorsal, használhat egy PowerShell-parancsot, például az alábbiakat egy véletlenszerű példasztring létrehozásához.

    -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
    
  2. Ha még nem tette meg, indítsa el a Microsoft ECMA2Host konfigurációs varázslót a start menüből.

  3. Válassza az Új Csatlakozás or lehetőséget. Képernyőkép az Új Csatlakozás or kiválasztásáról.

  4. A Tulajdonságok lapon töltse ki a mezőket a képet követő táblázatban megadott értékekkel, és válassza a Tovább gombot. A tulajdonságok megadását bemutató képernyőkép.

    Tulajdonság Érték
    Név Az összekötőhöz választott névnek egyedinek kell lennie a környezet összes összekötőjében. Például: LDAP.
    Autoszinkron időzítő (perc) 120
    Titkos jogkivonat Itt adhatja meg a titkos jogkivonatot. Legalább 12 karakternek kell lennie.
    Bővítmény DLL-je Az általános LDAP-összekötőnél válassza a Microsoft.IAM.CsatlakozásVagy. GenericLdap.dll.
  5. A Csatlakozás ivity lapon konfigurálhatja, hogy az ECMA Csatlakozás or gazdagép hogyan kommunikáljon a címtárkiszolgálóval, és adja meg a konfigurációs beállítások egy részét. Töltse ki a mezőket a képet követő táblázatban megadott értékekkel, és válassza a Tovább gombot. A Tovább gombra kattintva az összekötő lekérdezi a címtárkiszolgáló konfigurációját. Képernyőkép a Csatlakozás ivity oldalról.

    Tulajdonság Leírás
    Gazdagép A gazdagép neve, ahol az LDAP-kiszolgáló található. Ez a minta a példa gazdagépnévként szolgál APP3 .
    Kikötő A TCP-port száma. Ha a címtárkiszolgáló SSL-en keresztül van konfigurálva az LDAP-hoz, használja a 636-os portot. Ha Start TLShálózati szintű biztonságot használ, használja a 389-es portot.
    Kapcsolat időkorlátja 180
    Kötés Ez a tulajdonság határozza meg, hogy az összekötő hogyan hitelesítse magát a címtárkiszolgálón. Basic A beállítással vagy a beállítással, valamint TLS az SSL ügyféltanúsítvány konfigurálva nincs, az összekötő egyszerű LDAP-kötést küld a megkülönböztető névvel és jelszóval történő hitelesítéshez. SSL A beállítással TLS és az ügyféltanúsítvány megadásával az összekötő LDAP SASL-kötést EXTERNAL küld az ügyféltanúsítvánnyal való hitelesítéshez.
    Felhasználónév Hogyan hitelesíti magát az ECMA Csatlakozás or a címtárkiszolgálón. Ebben az AD LDS-példában a példa felhasználóneve az CN=svcAccount,CN=ServiceAccounts,CN=App,DC=contoso,DC=lab OpenLDAP, cn=admin,dc=contoso,dc=lab
    Jelszó Annak a felhasználónak a jelszava, amelyet az ECMA Csatlakozás or hitelesít a címtárkiszolgálón.
    Tartomány/tartomány Ez a beállítás csak akkor szükséges, ha a Kötés lehetőséget választotta Kerberos a felhasználó tartományának/tartományának megadásához.
    Tanúsítvány Az ebben a szakaszban szereplő beállításokat csak akkor használja a rendszer, ha ön vagy a Kötés lehetőség van kiválasztva SSLTLS .
    Attribútum aliasai Az attribútum-aliasok szövegmezője a sémában RFC4522 szintaxissal definiált attribútumokhoz használható. Ezek az attribútumok nem észlelhetők a sémaészlelés során, és az összekötőnek segítségre van szüksége az attribútumok azonosításához. Ha például a címtárkiszolgáló nem teszi közzé userCertificate;binary , és ki szeretné építtetni ezt az attribútumot, az alábbi sztringet be kell írni az attribútum aliasai mezőbe, hogy a userCertificate attribútumot bináris attribútumként megfelelően azonosíthassa: userCertificate;binary. Ha nem igényel speciális attribútumokat a sémában, ezt üresen hagyhatja.
    Működési attribútumok belefoglalása Jelölje be a jelölőnégyzetet a Include operational attributes in schema címtárkiszolgáló által létrehozott attribútumok hozzáadásához. Ezek közé tartoznak az attribútumok, például az objektum létrehozása és a legutóbbi frissítés időpontja.
    Bővíthető attribútumok belefoglalása Jelölje be a Include extensible attributes in schema jelölőnégyzetet, ha bővíthető objektumokat (RFC4512/4.3) használnak a címtárkiszolgálón. A beállítás engedélyezésével minden attribútum használható az összes objektumon. Ha ezt a beállítást választja, a séma nagyon nagy lesz, ezért ha a csatlakoztatott könyvtár nem használja ezt a funkciót, a javaslat az, hogy ne jelölje ki a beállítást.
    Manuális horgonyválasztás engedélyezése Hagyja üresen.

    Feljegyzés

    Ha problémát tapasztal a csatlakozás során, és nem tud továbblépni a globális lapra, győződjön meg arról, hogy az AD LDS szolgáltatásfiókja vagy a másik címtárkiszolgáló engedélyezve van.

  6. A Globális lapon szükség esetén konfigurálja a változásváltozási napló megkülönböztető nevét és további LDAP-funkciókat. A lap előre ki van töltve az LDAP-kiszolgáló által megadott információkkal. Tekintse át a megjelenített értékeket, majd válassza a Tovább gombot.

    Tulajdonság Leírás
    Támogatott SASL-mechanizmusok A felső szakaszban a kiszolgáló által biztosított információk láthatók, beleértve a SASL-mechanizmusok listáját is.
    Kiszolgálótanúsítvány részletei Ha SSL meg van adva, TLS a varázsló megjeleníti a címtárkiszolgáló által visszaadott tanúsítványt. Győződjön meg arról, hogy a kiállító, a tárgy és az ujjlenyomat a megfelelő címtárkiszolgálóhoz tartozik.
    Kötelező funkciók találhatók Az összekötő azt is ellenőrzi, hogy a kötelező vezérlők megtalálhatók-e a gyökér D Standard kiadás. Ha ezek a vezérlők nincsenek felsorolva, figyelmeztetés jelenik meg. Egyes LDAP-címtárak nem sorolják fel a gyökér D Standard kiadás összes funkcióját, és előfordulhat, hogy az összekötő probléma nélkül működik, még akkor is, ha figyelmeztetés jelenik meg.
    Támogatott vezérlők A támogatott vezérlők jelölőnégyzetei bizonyos műveletek viselkedését szabályozzák
    Különbözeti importálás A változásnapló DN-jének elnevezési környezetét használja a változásnapló, például cn=changelog. Ezt az értéket meg kell adni ahhoz, hogy képes legyen a változásimportálásra.
    Jelszóattribútum Ha a címtárkiszolgáló más jelszóattribútumot vagy jelszókivonatot támogat, megadhatja a jelszómódosítások célját.
    Partíciónevek A további partíciók listájában olyan további névtereket is felvehet, amely nem észlelhető automatikusan. Ez a beállítás például akkor használható, ha több kiszolgáló alkot logikai fürtöt, amelyet egyszerre kell importálni. Ahogyan az Active Directorynak több tartománya is lehet egy erdőben, de minden tartomány egy sémával rendelkezik, ugyanez szimulálható a mezőben szereplő további névterek beírásával. Minden névtér különböző kiszolgálókról importálható, és a Partíciók és hierarchiák konfigurálása lapon is konfigurálható.
  7. A Partíciók lapon tartsa meg az alapértelmezett értéket, és válassza a Tovább gombot.

  8. A Profilok futtatása lapon győződjön meg arról, hogy az Exportálás és a Teljes importálás jelölőnégyzet be van jelölve. Ezután válassza a Tovább gombra. Képernyőkép a Profilok futtatása lapról.

    Tulajdonság Leírás
    Exportálás Futtassa a profilt, amely adatokat exportál az LDAP címtárkiszolgálóra. Ez a futtatási profil szükséges.
    Teljes importálás Futtassa a profilt, amely a korábban megadott LDAP-forrásokból importálja az összes adatot. Ez a futtatási profil szükséges.
    Delta importálása Futtassa a profilt, amely csak az LDAP módosításait importálja az utolsó teljes vagy változásimportálás óta. Csak akkor engedélyezze ezt a futtatási profilt, ha megerősítette, hogy a címtárkiszolgáló megfelel a szükséges követelményeknek. További információkért lásd az általános LDAP-Csatlakozás or-hivatkozást.
  9. Az Exportálás lapon hagyja változatlanul az alapértelmezett értékeket, és kattintson a Tovább gombra.

  10. A Teljes importálás lapon hagyja változatlanul az alapértelmezett értékeket, és kattintson a Tovább gombra.

  11. A DeltaImport lapon , ha van ilyen, hagyja változatlanul az alapértelmezett értékeket, és kattintson a Tovább gombra.

  12. Az Objektumtípusok lapon töltse ki a mezőket, és válassza a Tovább gombot.

    Tulajdonság Leírás
    Célobjektum Ez az érték egy felhasználó szerkezeti objektumosztálya az LDAP-címtárkiszolgálón. Például inetOrgPerson az OpenLDAP vagy User az AD LDS esetében. Ebben a mezőben ne adjon meg segédobjektumosztályt. Ha a címtárkiszolgáló kiegészítő objektumosztályokat igényel, azokat az Azure Portal attribútumleképezéseivel konfigurálja.
    Horgony Az attribútum értékeinek egyedinek kell lenniük a célkönyvtár minden objektumához. A Microsoft Entra kiépítési szolgáltatás a kezdeti ciklus után ezt az attribútumot használva kérdezi le az ECMA-összekötő gazdagépét. Az AD LDS használata ObjectGUIDés más címtárkiszolgálók esetében lásd az alábbi táblázatot. Vegye figyelembe, hogy a megkülönböztető név lehet kijelölve .-dn- A többértékű attribútumok, például az uid OpenLDAP-séma attribútumai nem használhatók horgonyként.
    Lekérdezési attribútum Ennek az attribútumnak meg kell egyeznie a horgonysal, például objectGUID ha az AD LDS a címtárkiszolgáló, vagy _distinguishedName az OpenLDAP.
    DN A célobjektum megkülönböztető neve. Tartsa meg -dn-.
    Automatikusan létrehozott Ellenőrizetlen

    Az alábbi táblázat az LDAP-kiszolgálókat és a használt horgonyt sorolja fel:

    Címtár Horgony
    Microsoft AD LDS és AD GC objectGUID. A horgonyként való használathoz ObjectGUID az ügynök 1.1.846.0-s vagy újabb verzióját kell használnia.
    389 Címtárkiszolgáló Dn
    Apache Directory Dn
    IBM Tivoli DS Dn
    Isode Directory Dn
    Novell/NetIQ eDirectory GUID
    DJ/DS megnyitása Dn
    AZ LDAP megnyitása Dn
    Oracle OD Standard kiadás E Dn
    RadiantOne VDS Dn
    Sun One Directory Server Dn
  13. Az ECMA-gazdagép felderíti a célkönyvtár által támogatott attribútumokat. Kiválaszthatja, hogy mely attribútumokat szeretné elérhetővé tenni a Microsoft Entra ID-nak. Ezek az attribútumok ezután konfigurálhatók az Azure Portalon a kiépítéshez. Az Attribútumok kiválasztása lapon adja hozzá egyenként a legördülő listához azokat az attribútumokat, amelyek kötelező attribútumként szükségesek, vagy amelyeket a Microsoft Entra-azonosítóból szeretne kiépíteni. Képernyőkép az Attribútumok kiválasztása lapról.
    Az Attribútum legördülő lista a célkönyvtárban felderített attribútumokat jeleníti meg, és nem a konfigurációs varázsló Attribútumok kiválasztása lapjának előző használata során lett kiválasztva.

    Győződjön meg arról, hogy Treat as single value nincs bejelölve az objectClass attribútum jelölőnégyzete, és ha userPassword be van állítva, jelölje be vagy jelölje be az userPassword attribútumot.

    Ha openLDAP-t használ az inetOrgPerson sémával, konfigurálja a láthatóságot az alábbi attribútumokhoz.

    Attribútum Kezelés egyetlen értékként
    Cn I
    levélküldés I
    objectClass
    sn I
    userPassword I

    Ha OpenLDAP-t használ a POSIX-sémával, konfigurálja a láthatóságot az alábbi attribútumokhoz.

    Attribútum Kezelés egyetlen értékként
    _distinguishedName
    -Dn-
    export_password
    Cn I
    gidNumber
    homeDirectory
    levélküldés I
    objectClass
    sn I
    Uid I
    uidNumber
    userPassword I

    Az összes releváns attribútum hozzáadása után válassza a Tovább gombot.

  14. A Deprovisioning lapon megadhatja, hogy a Microsoft Entra-azonosító eltávolítsa-e a felhasználókat a címtárból, amikor azok kimennek az alkalmazás hatóköréből. Ha igen, a Folyamat letiltása területen válassza a Törlés, majd a Folyamat törlése területen a Törlés lehetőséget. Ha Set attribute value ezt választja, az előző lapon kijelölt attribútumok nem lesznek elérhetők a leépítési lapon való kiválasztáshoz.

Feljegyzés

Ha az Attribútum beállítása értéket használja, vegye figyelembe, hogy csak logikai értékek engedélyezettek.

  1. Válassza a Befejezés lehetőséget.

Győződjön meg arról, hogy az ECMA2Host szolgáltatás fut, és a címtárkiszolgálóról tud olvasni

Kövesse az alábbi lépéseket annak ellenőrzéséhez, hogy az összekötő-gazdagép elindult-e, és beolvassa-e a meglévő felhasználókat a címtárkiszolgálóról az összekötő gazdagépre.

  1. A Microsoft Entra ECMA Csatlakozás or gazdagépet futtató kiszolgálón válassza a Start lehetőséget.
  2. Válassza a futtatás lehetőséget, ha szükséges, majd írja be a services.msc kifejezést a mezőbe.
  3. A Szolgáltatások listában győződjön meg arról, hogy a Microsoft ECMA2Host jelen van és fut. Ha nem fut, válassza a Start lehetőséget. A szolgáltatás futását bemutató képernyőkép.
  4. Ha nemrég indította el a szolgáltatást, és sok felhasználói objektum található a címtárkiszolgálón, várjon néhány percet, amíg az összekötő kapcsolatot létesít a címtárkiszolgálóval.
  5. A Microsoft Entra ECMA Csatlakozás or gazdagépet futtató kiszolgálón indítsa el a PowerShellt.
  6. Váltson arra a mappára, amelyben az ECMA-gazdagép telepítve volt, például C:\Program Files\Microsoft ECMA2Host.
  7. Váltson az alkönyvtárra Troubleshooting.
  8. Futtassa a szkriptet TestECMA2HostConnection.ps1 a könyvtárban az alábbi példában látható módon, és adja meg argumentumként az összekötő nevét és értékét ObjectTypePathcache. Ha az összekötő gazdagépe nem figyeli a 8585-ös TCP-portot, akkor előfordulhat, hogy az -Port argumentumot is meg kell adnia. Amikor a rendszer kéri, írja be az összekötőhöz konfigurált titkos jogkivonatot.
    PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
    Supply values for the following parameters:
    SecretToken: ************
    
  9. Ha a szkript hibaüzenetet vagy figyelmeztető üzenetet jelenít meg, ellenőrizze, hogy fut-e a szolgáltatás, és az összekötő neve és titkos jogkivonata megegyezik a konfigurációs varázslóban konfigurált értékekkel.
  10. Ha a szkript megjeleníti a kimenetet False, akkor az összekötő nem látott bejegyzéseket a forráskönyvtár-kiszolgálón meglévő felhasználók számára. Ha ez egy új címtárkiszolgáló-telepítés, akkor ez a viselkedés várható, és a következő szakaszban folytathatja.
  11. Ha azonban a címtárkiszolgáló már tartalmaz egy vagy több felhasználót False, de a szkript megjelenik, akkor ez az állapot azt jelzi, hogy az összekötő nem tudott olvasni a címtárkiszolgálóról. Ha kiépítést kísérel meg, akkor előfordulhat, hogy a Microsoft Entra-azonosító nem felel meg megfelelően a forráskönyvtár felhasználóinak a Microsoft Entra ID-beli felhasználókkal. Várjon néhány percet, amíg az összekötő gazdagép befejezi az objektumok olvasását a meglévő címtárkiszolgálóról, majd futtassa újra a szkriptet. Ha a kimenet továbbra is az lesz False, ellenőrizze az összekötő konfigurációját, és a címtárkiszolgálón lévő engedélyek lehetővé teszik az összekötő számára a meglévő felhasználók olvasását.

A Microsoft Entra-azonosító és az összekötő gazdagép közötti kapcsolat tesztelése

  1. Térjen vissza arra a böngészőablakra, ahol konfigurálta az alkalmazás kiépítését a portálon.

    Feljegyzés

    Ha az ablak túllépte az időkorlátot, újra ki kell választania az ügynököt.

    1. Jelentkezzen be az Azure Portalra.
    2. Nyissa meg a Nagyvállalati alkalmazásokat és a helyszíni ECMA-alkalmazásalkalmazást .
    3. Kattintson a Kiépítés elemre.
    4. Ha megjelenik az Első lépések funkció, módosítsa a módot Automatikus módra, a Helyszíni Csatlakozás ivity szakaszban válassza ki az imént üzembe helyezett ügynököt, és válassza az Ügynök(ek) hozzárendelése lehetőséget, és várjon 10 percet. Ellenkező esetben nyissa meg a Kiépítés szerkesztése elemet.
  2. A Rendszergazda hitelesítő adatok szakaszban adja meg a következő URL-címet. Cserélje le a connectorName részt az ECMA-gazdagépen található összekötő nevére, például LDAP. Ha tanúsítványt adott meg a hitelesítésszolgáltatótól az ECMA-gazdagéphez, cserélje le localhost annak a kiszolgálónak a gazdanevére, ahol az ECMA-gazdagép telepítve van.

    Tulajdonság Érték
    Bérlő URL-címe https://localhost:8585/ecma2host_connectorName/scim
  3. Adja meg az összekötő létrehozásakor definiált titkos jogkivonat értékét.

    Feljegyzés

    Ha most rendelte hozzá az ügynököt az alkalmazáshoz, várjon 10 percet, amíg a regisztráció befejeződik. A kapcsolati teszt csak a regisztráció befejezéséig működik. Ha arra kényszeríti az ügynök regisztrációját, hogy befejezze a kiépítési ügynök újraindítását a kiszolgálón, felgyorsíthatja a regisztrációs folyamatot. Lépjen a kiszolgálóra, keressen szolgáltatásokat a Windows keresősávjában, azonosítsa a Microsoft Entra Csatlakozás Kiépítési ügynök szolgáltatást, kattintson a jobb gombbal a szolgáltatásra, és indítsa újra.

  4. Válassza a Csatlakozás ion tesztelése lehetőséget, és várjon egy percet.

  5. Miután a kapcsolati teszt sikeres volt, és azt jelzi, hogy a megadott hitelesítő adatok jogosultak a kiépítés engedélyezésére, válassza a Mentés lehetőséget.
    Az ügynök tesztelését bemutató képernyőkép.

A Microsoft Entra séma kiterjesztése (nem kötelező)

Ha a címtárkiszolgáló olyan további attribútumokat igényel, amelyek nem részei a felhasználók alapértelmezett Microsoft Entra-sémájának, akkor a kiépítéskor konfigurálhatja, hogy az attribútumok értékeit állandóból, más Microsoft Entra attribútumokból átalakított kifejezésből vagy a Microsoft Entra-séma kiterjesztésével adja meg.

Ha a címtárkiszolgáló megköveteli, hogy a felhasználók rendelkezzenek egy attribútummal, például uidNumber az OpenLDAP POSIX sémához, és ez az attribútum még nem része egy felhasználó Microsoft Entra-sémájának, és minden felhasználó esetében egyedinek kell lennie, akkor vagy egy kifejezéssel kell létrehoznia ezt az attribútumot a felhasználó más attribútumaiból, vagy a címtárbővítmény funkcióval bővítményként kell hozzáadnia ezt az attribútumot.

Ha a felhasználók Active Directory tartományi szolgáltatások származnak, és a címtárban található az attribútum, akkor a Microsoft Entra Csatlakozás vagy a Microsoft Entra Csatlakozás felhőszinkronizálással konfigurálhatja, hogy az attribútumot szinkronizálni kell Active Directory tartományi szolgáltatások a Microsoft Entra-azonosítóhoz, hogy az elérhető legyen más rendszereken való üzembe helyezéshez.

Ha a felhasználók a Microsoft Entra-azonosítóból származnak, akkor minden új attribútumhoz, amit egy felhasználón kell tárolnia, meg kell határoznia egy címtárbővítményt. Ezután frissítse a kiépíteni kívánt Microsoft Entra-felhasználókat, hogy minden felhasználónak értéket adjon ezeknek az attribútumoknak.

Attribútumleképezés konfigurálása

Ebben a szakaszban konfigurálja a Microsoft Entra-felhasználó attribútumai és az ECMA-gazdagép konfigurációs varázslójában korábban kiválasztott attribútumok közötti megfeleltetést. Később, amikor az összekötő létrehoz egy objektumot egy címtárkiszolgálón, a Microsoft Entra-felhasználó attribútumai az összekötőn keresztül lesznek elküldve a címtárkiszolgálóra, hogy az az új objektum része legyen.

  1. A Microsoft Entra Felügyeleti központban a Nagyvállalati alkalmazások területen válassza ki a helyszíni ECMA alkalmazásalkalmazást, majd válassza a Kiépítés lapot.

  2. Válassza a Kiépítés szerkesztése lehetőséget.

  3. Bontsa ki a leképezéseket , és válassza a Microsoft Entra-felhasználók kiosztása lehetőséget. Ha most először konfigurálta az alkalmazás attribútumleképezéseit, csak egy leképezés lesz jelen egy helyőrzőhöz.

  4. Ha ellenőrizni szeretné, hogy a címtárkiszolgáló sémája elérhető-e a Microsoft Entra-azonosítóban, jelölje be a Speciális beállítások megjelenítése jelölőnégyzetet, és válassza a ScimOnPremises attribútumlistájának szerkesztése lehetőséget. Győződjön meg arról, hogy a konfigurációs varázslóban kiválasztott összes attribútum szerepel a listában. Ha nem, várjon néhány percet, amíg a séma frissül, majd válassza az Attribútumleképezés lehetőséget a navigációs sorban, majd a ScimOnPremises attribútumlistájának szerkesztése lehetőséget ismét a lap újbóli betöltéséhez. Miután meglátja a felsorolt attribútumokat, szakítsa meg ezt a lapot a leképezési listához való visszatéréshez.

  5. A címtárban minden felhasználónak egyedi megkülönböztető névvel kell rendelkeznie. Attribútumleképezéssel megadhatja, hogy az összekötő hogyan hozzon létre megkülönböztető nevet. Válassza az Új leképezés hozzáadása lehetőséget. Az alábbi példában szereplő értékekkel hozza létre a leképezést, és módosítsa a kifejezés megkülönböztető neveit úgy, hogy azok megfeleljenek a célkönyvtárban lévő szervezeti egység vagy más tároló neveinek.

    • Leképezés típusa: kifejezés
    • Kifejezés, ha kiépítés az AD LDS-be: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,CN=App,DC=Contoso,DC=lab")
    • Kifejezés az OpenLDAP-be való kiépítés esetén: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
    • Célattribútum: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
    • A leképezés alkalmazása: csak az objektum létrehozása során
  6. Ha a címtárkiszolgáló több szerkezeti objektumosztály-értéket vagy segédobjektumosztály-értéket igényel az objectClass attribútumban, adjon hozzá egy leképezést az attribútumhoz. Ebben a példában az AD LDS-be való kiépítéshez a leképezés objectClass nem szükséges, de más címtárkiszolgálókhoz vagy más sémákhoz szükséges lehet. Ha hozzá szeretne adni egy leképezést, objectClassválassza az Új leképezés hozzáadása lehetőséget. Az alábbi példában szereplő értékekkel hozza létre a leképezést, és módosítsa a kifejezés objektumosztálynevét úgy, hogy az megfeleljen a célkönyvtár sémájának.

    • Leképezés típusa: kifejezés
    • Kifejezés, ha az inetOrgPerson sémát építi ki: Split("inetOrgPerson",",")
    • Kifejezés, ha a POSIX-sémát építi ki: Split("inetOrgPerson,posixAccount,shadowAccount",",")
    • Célattribútum: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
    • A leképezés alkalmazása: csak az objektum létrehozása során
  7. Ha az AD LDS-be épít be, és a userPrincipalName és a HELYŐRZŐ között van egy leképezés, kattintson a leképezésre, és szerkessze azt. A leképezés frissítéséhez használja az alábbi értékeket.

    • Leképezés típusa: közvetlen
    • Forrásattribútum: userPrincipalName
    • Célattribútum: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPrincipalName
    • Egyező sorrend: 1
    • A leképezés alkalmazása: csak az objektum létrehozása során
  8. Ha az AD LDS-be épít be, adja hozzá az isSoftDeleted leképezését. Válassza az Új leképezés hozzáadása lehetőséget. A leképezés létrehozásához használja az alábbi értékeket.

    • Leképezés típusa: közvetlen
    • Forrásattribútum: isSoftDeleted
    • Célattribútum: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:msDS-UserAccountDisabled
  9. A címtárkiszolgáló alábbi táblázatában szereplő leképezések mindegyikéhez válassza az Új leképezés hozzáadása lehetőséget, és adja meg a forrás- és célattribútumokat. Ha meglévő címtárba épít be meglévő felhasználókkal, szerkesztenie kell az attribútum leképezését, amely közös ahhoz, hogy az objektumokat ezzel az attribútummal állítsa be az adott attribútumhoz . Az attribútumleképezésről itt olvashat bővebben.

    AD LDS esetén:

    Leképezés típusa Forrásattribútum Célattribútum
    Közvetlen displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:displayName

    OpenLDAP esetén:

    Leképezés típusa Forrásattribútum Célattribútum
    Közvetlen displayName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn
    Közvetlen surname urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn
    Közvetlen userPrincipalName urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail

    A POSIX-sémával rendelkező OpenLDAP esetében a , homeDirectoryuid és uidNumber attribútumokat gidNumberis meg kell adnia. Minden felhasználónak egyedi uid és egyedi uidNumberkell. Általában a homeDirectory felhasználó userID azonosítójából származó kifejezés állítja be. Ha például egy uid felhasználó nevét a felhasználónévből származtatott kifejezés hozza létre, akkor a felhasználó kezdőkönyvtárának értékét létrehozhatja egy, a felhasználónévből is származtatott hasonló kifejezés. A használati esettől függően előfordulhat, hogy azt szeretné, hogy az összes felhasználó ugyanabban a csoportban legyen, ezért egy állandóból rendelné hozzá a gidNumber felhasználót.

    Leképezés típusa Forrásattribútum Célattribútum
    Expression ToLower(Word([userPrincipalName], 1, "@"), ) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid
    Közvetlen (a címtárra jellemző attribútum) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber
    Expression Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), )) urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory
    Állandó 10000 urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber
  10. Ha az AD LDS-étől eltérő könyvtárba épít be, akkor adjon hozzá egy leképezést urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword , amely beállít egy kezdeti véletlenszerű jelszót a felhasználó számára. Az AD LDS esetében nincs megfeleltetés a userPassword parancshoz.

  11. Válassza a Mentés lehetőséget.

Győződjön meg arról, hogy az alkalmazáshoz kiosztandó felhasználók rendelkeznek a Microsoft Entra ID-ban szükséges attribútumokkal

Ha vannak olyan személyek, akik már rendelkeznek felhasználói fiókkal az LDAP-címtárban, akkor gondoskodnia kell arról, hogy a Microsoft Entra felhasználói reprezentációja rendelkezzen az egyezéshez szükséges attribútumokkal.

Ha új felhasználókat szeretne létrehozni az LDAP-címtárban, akkor gondoskodnia kell arról, hogy a felhasználók Microsoft Entra-reprezentációi rendelkezzenek a célkönyvtár felhasználói sémája által megkövetelt forrásattribútumokkal.

A Microsoft Graph PowerShell-parancsmagokkal automatizálhatja a szükséges attribútumok felhasználóinak ellenőrzését.

Tegyük fel például, hogy a kiépítéshez három attribútumra DisplayNamevolt szükség a felhasználóknak,surname és extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty. A parancsmaggal lekérheti az Get-MgUser egyes felhasználókat, és ellenőrizheti, hogy vannak-e a szükséges attribútumok. Vegye figyelembe, hogy a Graph 1.0-s Get-MgUser parancsmag alapértelmezés szerint nem ad vissza egy felhasználó címtárbővítmény-attribútumait, kivéve, ha az attribútumok a kérésben a visszaadandó tulajdonságok egyikeként vannak megadva.

$userPrincipalNames = (
 "alice@contoso.com",
 "bob@contoso.com",
 "carol@contoso.com" )

$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")

$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}

foreach ($un in $userPrincipalNames) {
   $nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
   foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
   foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}

Meglévő felhasználók gyűjtése az LDAP-címtárból

Számos LDAP-címtár, például az Active Directory tartalmaz egy parancsot, amely megjeleníti a felhasználók listáját.

  1. Azonosítsa, hogy a címtárban szereplő felhasználók közül mely felhasználók tartoznak az alkalmazás felhasználói hatókörébe. Ez a választás az alkalmazás konfigurációjától függ. Egyes alkalmazások esetében az LDAP-címtárban található összes felhasználó érvényes felhasználó. Más alkalmazások esetében előfordulhat, hogy a felhasználónak rendelkeznie kell egy adott attribútummal, vagy tagja egy csoportnak a címtárban.

  2. Futtassa azt a parancsot, amely lekéri a felhasználók egy részét az LDAP-címtárból. Győződjön meg arról, hogy a kimenet tartalmazza a Microsoft Entra-azonosítóval való egyeztetéshez használt felhasználók attribútumait. Ilyen attribútumok például az alkalmazottak azonosítója, a fiók neve és az e-mail-cím.

    Ez az AD LDS-programot csvde használó Windows-parancs például egy CSV-fájlt hoz létre az aktuális fájlrendszer könyvtárában, a userPrincipalName címtár minden személyének attribútumával:

    $out_filename = ".\users.csv"
    csvde -f $out_filename -l userPrincipalName,cn -r "(objectclass=person)"
    
  3. Szükség esetén vigye át a felhasználók listáját tartalmazó CSV-fájlt egy rendszerbe a Telepített Microsoft Graph PowerShell-parancsmagokkal .

  4. Most, hogy rendelkezik az alkalmazásból beszerzett összes felhasználó listájával, az alkalmazás adattárából származó felhasználókat a Microsoft Entra-azonosítóban lévő felhasználókkal fogja egyeztetni. A folytatás előtt tekintse át a forrás- és célrendszerek megfelelő felhasználóival kapcsolatos információkat.

A felhasználók azonosítóinak lekérése a Microsoft Entra-azonosítóban

Ez a szakasz bemutatja, hogyan használhatja a Microsoft Entra ID-t Microsoft Graph PowerShell-parancsmagok használatával.

Amikor a szervezet először használja ezeket a parancsmagokat ehhez a forgatókönyvhöz, globális Rendszergazda istrator szerepkörrel kell rendelkeznie, hogy lehetővé tegye a Microsoft Graph PowerShell használatát a bérlőjében. A későbbi interakciók alacsonyabb jogosultságú szerepkört is használhatnak, például:

  • Felhasználó Rendszergazda istrator, ha új felhasználókat szeretne létrehozni.
  • Alkalmazás-Rendszergazda istrator vagy identitásszabályozási Rendszergazda istrator, ha csak az alkalmazásszerepkör-hozzárendeléseket kezeli.
  1. Nyissa meg a PowerShellt.

  2. Ha még nem telepítette a Microsoft Graph PowerShell-modulokat , telepítse a modult és másokat a Microsoft.Graph.Users következő paranccsal:

    Install-Module Microsoft.Graph
    

    Ha már telepítve vannak a modulok, győződjön meg arról, hogy a legújabb verziót használja:

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
    
  3. Csatlakozás a Microsoft Entra-azonosítóhoz:

    $msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"
    
  4. Ha ez az első alkalom, hogy használja ezt a parancsot, előfordulhat, hogy hozzá kell adnia ahhoz, hogy a Microsoft Graph parancssori eszközei rendelkezzenek ezekkel az engedélyekkel.

  5. Olvassa el az alkalmazás adattárából a PowerShell-munkamenetbe beolvasott felhasználók listáját. Ha a felhasználók listája CSV-fájlban volt, használhatja a PowerShell-parancsmagot Import-Csv , és argumentumként megadhatja az előző szakaszból származó fájl nevét.

    Ha például az SAP Cloud Identity Services szolgáltatásból beszerzett fájl neve Users-exported-from-sap.csv , és az aktuális könyvtárban található, írja be ezt a parancsot.

    $filename = ".\Users-exported-from-sap.csv"
    $dbusers = Import-Csv -Path $filename -Encoding UTF8
    

    Egy másik példa, ha adatbázist vagy könyvtárat használ, ha a fájl neve users.csv , és az aktuális könyvtárban található, adja meg ezt a parancsot:

    $filename = ".\users.csv"
    $dbusers = Import-Csv -Path $filename -Encoding UTF8
    
  6. Válassza ki annak a users.csv fájlnak az oszlopát, amely megfelel a Microsoft Entra ID-ban egy felhasználó attribútumának.

    Ha SAP Cloud Identity Servicest használ, akkor az alapértelmezett leképezés az SAP SCIM attribútum userName a Microsoft Entra ID attribútummal userPrincipalName:

    $db_match_column_name = "userName"
    $azuread_match_attr_name = "userPrincipalName"
    

    Egy másik példa, ha adatbázist vagy könyvtárat használ, előfordulhat, hogy vannak olyan felhasználói az adatbázisban, ahol a névvel ellátott EMail oszlop értéke ugyanaz, mint a Microsoft Entra attribútumban userPrincipalName:

    $db_match_column_name = "EMail"
    $azuread_match_attr_name = "userPrincipalName"
    
  7. Kérje le a felhasználók azonosítóit a Microsoft Entra-azonosítóban.

    Az alábbi PowerShell-szkript a $dbuserskorábban megadott , $db_match_column_nameés $azuread_match_attr_name értékeket használja. Lekérdezi a Microsoft Entra azonosítóját, és megkeres egy olyan felhasználót, akinek attribútuma megegyezik a forrásfájl minden rekordjának megfelelő értékével. Ha a forrás SAP Cloud Identity Servicesből, adatbázisból vagy könyvtárból beszerzett fájlban sok felhasználó található, ez a szkript több percet is igénybe vehet. Ha nem rendelkezik olyan attribútummal a Microsoft Entra-azonosítóban, amely rendelkezik az értékkel, és egy contains vagy más szűrőkifejezést kell használnia, akkor testre kell szabnia ezt a szkriptet, és az alábbi 11. lépésben egy másik szűrőkifejezést kell használnia.

    $dbu_not_queried_list = @()
    $dbu_not_matched_list = @()
    $dbu_match_ambiguous_list = @()
    $dbu_query_failed_list = @()
    $azuread_match_id_list = @()
    $azuread_not_enabled_list = @()
    $dbu_values = @()
    $dbu_duplicate_list = @()
    
    foreach ($dbu in $dbusers) { 
       if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
          $val = $dbu.$db_match_column_name
          $escval = $val -replace "'","''"
          if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
          $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
          try {
             $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
             if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
                $id = $ul[0].id; 
                $azuread_match_id_list += $id;
                if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
             } 
          } catch { $dbu_query_failed_list += $dbu } 
        } else { $dbu_not_queried_list += $dbu }
    }
    
    
  8. Az előző lekérdezések eredményeinek megtekintése. Ellenőrizze, hogy az SAP Cloud Identity Services egyik felhasználója, az adatbázis vagy a könyvtár nem található-e a Microsoft Entra-azonosítóban hibák vagy hiányzó egyezések miatt.

    A következő PowerShell-szkript megjeleníti a nem található rekordok számát:

    $dbu_not_queried_count = $dbu_not_queried_list.Count
    if ($dbu_not_queried_count -ne 0) {
      Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
    }
    $dbu_duplicate_count = $dbu_duplicate_list.Count
    if ($dbu_duplicate_count -ne 0) {
      Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
    }
    $dbu_not_matched_count = $dbu_not_matched_list.Count
    if ($dbu_not_matched_count -ne 0) {
      Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
    }
    $dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
    if ($dbu_match_ambiguous_count -ne 0) {
      Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
    }
    $dbu_query_failed_count = $dbu_query_failed_list.Count
    if ($dbu_query_failed_count -ne 0) {
      Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
    }
    $azuread_not_enabled_count = $azuread_not_enabled_list.Count
    if ($azuread_not_enabled_count -ne 0) {
     Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
    }
    if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
     Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
    }
    $azuread_match_count = $azuread_match_id_list.Count
    Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID." 
    
  9. Ha a szkript befejeződött, hibát jelez, ha az adatforrásból származó rekordok nem a Microsoft Entra-azonosítóban találhatók. Ha az alkalmazás adattárában lévő felhasználók összes rekordja nem szerepelhet felhasználókként a Microsoft Entra-azonosítóban, meg kell vizsgálnia, hogy mely rekordok nem egyeztek meg és miért.

    Előfordulhat például, hogy valaki e-mail-címe és userPrincipalName-címe módosult a Microsoft Entra-azonosítóban anélkül, hogy a megfelelő mail tulajdonsága frissült volna az alkalmazás adatforrásában. Vagy előfordulhat, hogy a felhasználó már elhagyta a szervezetet, de továbbra is az alkalmazás adatforrásában van. Vagy előfordulhat, hogy az alkalmazás adatforrásában olyan szállítói vagy felügyelői fiók található, amely nem felel meg a Microsoft Entra-azonosító egyik konkrét személyének sem.

  10. Ha voltak olyan felhasználók, akik nem találhatók a Microsoft Entra-azonosítóban, vagy nem voltak aktívak, és nem tudtak bejelentkezni, de ellenőrizni szeretné a hozzáférésüket vagy az attribútumaikat az SAP Cloud Identity Servicesben, az adatbázisban vagy a címtárban, frissítenie kell az alkalmazást, a megfelelő szabályt, vagy frissítenie kell vagy létre kell hoznia a Microsoft Entra-felhasználókat számukra. A módosítással kapcsolatos további információkért tekintse meg a Microsoft Entra-azonosítóban szereplő felhasználókkal nem egyező alkalmazások leképezéseinek és felhasználói fiókjainak kezelését.

    Ha a Microsoft Entra ID-ban a felhasználók létrehozásának lehetőségét választja, tömegesen hozhat létre felhasználókat az alábbi lehetőségek valamelyikével:

    • CsV-fájl a Felhasználók tömeges létrehozása a Microsoft Entra felügyeleti központban című cikkben leírtak szerint
    • A New-MgUser parancsmag

    Győződjön meg arról, hogy ezek az új felhasználók fel vannak töltve a Microsoft Entra-azonosítóhoz szükséges attribútumokkal, hogy később megegyezhessenek az alkalmazás meglévő felhasználóival, valamint a Microsoft Entra ID által megkövetelt attribútumokkal, köztük az userPrincipalName, mailNickname és displayName. Ennek userPrincipalName egyedinek kell lennie a címtár összes felhasználója között.

    Előfordulhat például, hogy vannak olyan felhasználói az adatbázisban, ahol a névvel ellátott EMail oszlop értéke a Microsoft Entra felhasználónévként használni kívánt érték, az oszlopban Alias lévő érték a Microsoft Entra ID e-mail becenevet, az oszlopban Full name pedig a felhasználó megjelenítendő nevét tartalmazza:

    $db_display_name_column_name = "Full name"
    $db_user_principal_name_column_name = "Email"
    $db_mail_nickname_column_name = "Alias"
    

    Ezután ezzel a szkripttel Microsoft Entra-felhasználókat hozhat létre az SAP Cloud Identity Servicesben, az adatbázisban vagy könyvtárban lévő felhasználók számára, amelyek nem egyeztek meg a Microsoft Entra-azonosítóban szereplő felhasználókkal. Vegye figyelembe, hogy előfordulhat, hogy módosítania kell ezt a szkriptet, hogy további Microsoft Entra-attribútumokat adjon hozzá a szervezetéhez, vagy ha nem $azuread_match_attr_namemailNicknameuserPrincipalNameis, akkor a Microsoft Entra attribútum megadásához.

    $dbu_missing_columns_list = @()
    $dbu_creation_failed_list = @()
    foreach ($dbu in $dbu_not_matched_list) {
       if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
           ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
           ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
          $params = @{
             accountEnabled = $false
             displayName = $dbu.$db_display_name_column_name
             mailNickname = $dbu.$db_mail_nickname_column_name
             userPrincipalName = $dbu.$db_user_principal_name_column_name
             passwordProfile = @{
               Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
             }
          }
          try {
            New-MgUser -BodyParameter $params
          } catch { $dbu_creation_failed_list += $dbu; throw }
       } else {
          $dbu_missing_columns_list += $dbu
       }
    }
    
  11. Miután hozzáadta a hiányzó felhasználókat a Microsoft Entra-azonosítóhoz, futtassa újra a szkriptet a 7. lépésben. Ezután futtassa a szkriptet a 8. lépésben. Ellenőrizze, hogy nincsenek-e hibajelentések.

    $dbu_not_queried_list = @()
    $dbu_not_matched_list = @()
    $dbu_match_ambiguous_list = @()
    $dbu_query_failed_list = @()
    $azuread_match_id_list = @()
    $azuread_not_enabled_list = @()
    $dbu_values = @()
    $dbu_duplicate_list = @()
    
    foreach ($dbu in $dbusers) { 
       if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
          $val = $dbu.$db_match_column_name
          $escval = $val -replace "'","''"
          if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
          $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
          try {
             $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
             if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
                $id = $ul[0].id; 
                $azuread_match_id_list += $id;
                if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
             } 
          } catch { $dbu_query_failed_list += $dbu } 
        } else { $dbu_not_queried_list += $dbu }
    }
    
    $dbu_not_queried_count = $dbu_not_queried_list.Count
    if ($dbu_not_queried_count -ne 0) {
      Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
    }
    $dbu_duplicate_count = $dbu_duplicate_list.Count
    if ($dbu_duplicate_count -ne 0) {
      Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
    }
    $dbu_not_matched_count = $dbu_not_matched_list.Count
    if ($dbu_not_matched_count -ne 0) {
      Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
    }
    $dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
    if ($dbu_match_ambiguous_count -ne 0) {
      Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
    }
    $dbu_query_failed_count = $dbu_query_failed_list.Count
    if ($dbu_query_failed_count -ne 0) {
      Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
    }
    $azuread_not_enabled_count = $azuread_not_enabled_list.Count
    if ($azuread_not_enabled_count -ne 0) {
     Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
    }
    if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
     Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
    }
    $azuread_match_count = $azuread_match_id_list.Count
    Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID." 
    

Felhasználók hozzárendelése egy alkalmazáshoz

Most, hogy a Microsoft Entra ECMA Csatlakozás or gazdagép a Microsoft Entra-azonosítóval és az attribútumleképezés konfigurálva van, továbbléphet a kiépítés hatókörében lévő felhasználók konfigurálására.

Fontos

Ha hibrid identitás Rendszergazda istrator szerepkörrel jelentkezett be, akkor ehhez a szakaszhoz ki kell jelentkeznie és be kell jelentkeznie egy olyan fiókkal, amely rendelkezik az Alkalmazás Rendszergazda istrator, a Felhőalkalmazás Rendszergazda istrator vagy a Globális Rendszergazda istrator szerepkörrel. A Hibrid identitás Rendszergazda istrator szerepkör nem rendelkezik jogosultságokkal a felhasználók alkalmazásokhoz való hozzárendeléséhez.

Ha vannak meglévő felhasználók az LDAP-címtárban, akkor a Microsoft Entra ID azonosítójában kell létrehoznia az alkalmazásszerepkör-hozzárendeléseket a meglévő felhasználók számára. Ha többet szeretne megtudni arról, hogyan hozhat létre tömegesen New-MgServicePrincipalAppRoleAssignedToalkalmazásszerepkör-hozzárendeléseket, tekintse meg az alkalmazás meglévő felhasználóinak szabályozását a Microsoft Entra-azonosítóban.

Ellenkező esetben, ha az LDAP-címtár üres, akkor válasszon ki egy tesztfelhasználót a Microsoft Entra-azonosítóból, aki rendelkezik a szükséges attribútumokkal, és ki lesz építve az alkalmazás címtárkiszolgálójára.

  1. Győződjön meg arról, hogy a felhasználó kiválasztja az összes tulajdonságot, amely a címtárkiszolgáló-séma szükséges attribútumaihoz lesz megfeleltetve.
  2. Az Azure Portalon válassza ki a Nagyvállalati alkalmazásokat.
  3. Válassza ki a helyszíni ECMA alkalmazásalkalmazást .
  4. A bal oldalon, a Kezelés csoportban válassza a Felhasználók és csoportok lehetőséget.
  5. Válassza a Felhasználó/csoport hozzáadása lehetőséget. A felhasználó hozzáadását bemutató képernyőkép.
  6. A Felhasználók csoportban válassza a Nincs kijelölve lehetőséget. Képernyőkép a Nincs kijelölve elemet ábrázoló képernyőképről.
  7. Válasszon ki egy felhasználót a jobb oldalon, és válassza a Kiválasztás gombot.
    A Felhasználók kijelölése lehetőséget bemutató képernyőkép.
  8. Most válassza a Hozzárendelés lehetőséget. Képernyőkép a Felhasználók hozzárendelése gombra.

Kiépítés tesztelése

Most, hogy az attribútumok le vannak képezve, és egy kezdeti felhasználó van hozzárendelve, tesztelheti az igény szerinti kiépítést az egyik felhasználóval.

  1. A Microsoft Entra ECMA Csatlakozás or gazdagépet futtató kiszolgálón válassza a Start lehetőséget.

  2. Írja be a futtatás kifejezést, és írja be a services.msc kifejezést a mezőbe.

  3. A Szolgáltatások listában győződjön meg arról, hogy a Microsoft Entra Csatlakozás Provisioning Agent szolgáltatás és a Microsoft ECMA2Host szolgáltatások is futnak. Ha nem, válassza a Start lehetőséget.

  4. Az Azure Portalon válassza ki a Nagyvállalati alkalmazásokat.

  5. Válassza ki a helyszíni ECMA alkalmazásalkalmazást .

  6. A bal oldalon válassza a Kiépítés lehetőséget.

  7. Válassza az Igény szerinti kiépítés lehetőséget.

  8. Keressen rá az egyik tesztfelhasználóra, és válassza a Kiépítés lehetőséget. Képernyőkép az igény szerinti kiépítés teszteléséről.

  9. Néhány másodperc elteltével megjelenik a célrendszerben sikeresen létrehozott felhasználót tartalmazó üzenet a felhasználói attribútumok listájával. Ha ehelyett hiba jelenik meg, tekintse meg a kiépítési hibák hibaelhárítását.

Felhasználók üzembe helyezésének megkezdése

Az igény szerinti kiépítés sikeres tesztelése után adja hozzá a többi felhasználót.

  1. Az Azure Portalon válassza ki az alkalmazást.
  2. A bal oldalon, a Kezelés csoportban válassza a Felhasználók és csoportok lehetőséget.
  3. Győződjön meg arról, hogy minden felhasználó hozzá van rendelve az alkalmazásszerepkörhöz.
  4. Térjen vissza a kiépítés konfigurációs oldalára.
  5. Győződjön meg arról, hogy a hatókör csak a hozzárendelt felhasználókra és csoportokra van beállítva, kapcsolja be a kiépítés állapotát, és válassza a Mentés lehetőséget.
  6. Várjon néhány percet a kiépítés elindításához. Akár 40 percet is igénybe vehet. A kiépítési feladat befejezése után, a következő szakaszban leírtak szerint,

Kiépítési hibák elhárítása

Ha hiba jelenik meg, válassza a Kiépítési naplók megtekintése lehetőséget. Keresse meg a naplóban azt a sort, amelyben az állapot hiba, és kattintson erre a sorra.

Ha a hibaüzenet nem sikerült létrehozni a felhasználót, ellenőrizze a címtárséma követelményeinek megfelelő attribútumokat.

További információ: Hibaelhárítás &Javaslatok lap.

Ha a hibaelhárítási hibaüzenetben szerepel az objectClass érték invalid per syntax, győződjön meg arról, hogy az attribútum kiépítési objectClass attribútuma csak a címtárkiszolgáló által felismert objektumosztályok nevét tartalmazza.

További hibákért tekintse meg a helyszíni alkalmazások kiépítésének hibaelhárítását.

Ha fel szeretné függeszteni az alkalmazás üzembe helyezését, a kiépítés konfigurációs lapján a kiépítés állapotát Ki gombra állíthatja, és válassza a Mentés lehetőséget. Ez a művelet megakadályozza, hogy a kiépítési szolgáltatás a jövőben fusson.

Ellenőrizze, hogy a felhasználók sikeresen ki lettek-e építve

Várakozás után ellenőrizze a címtárkiszolgálót, hogy a felhasználók ki vannak-e építve. A címtárkiszolgálón végrehajtott lekérdezés attól függ, hogy a címtárkiszolgáló milyen parancsokat biztosít.

Az alábbi utasítások bemutatják, hogyan ellenőrizheti az AD LDS-t.

  1. Nyissa meg a Kiszolgálókezelő, és válassza az AD LDS lehetőséget a bal oldalon.
  2. Kattintson a jobb gombbal az AD LDS-példányra, és válassza ldp.exe az előugró ablakból. Képernyőkép az Ldp eszköz helyéről.
  3. A ldp.exe tetején válassza a Csatlakozás ion és a Csatlakozás lehetőséget.
  4. Adja meg a következő adatokat, és kattintson az OK gombra.
    • Kiszolgáló: APP3
    • Port: 636
    • Jelölje be az SSL-jelölőnégyzetet Képernyőkép a felhasználók ellenőrzéséhez használt LDP-kapcsolatról.
  5. A tetején, a Csatlakozás ion alatt válassza a Kötés lehetőséget.
  6. Hagyja meg az alapértelmezett értékeket, és kattintson az OK gombra.
  7. Felül válassza a Nézet és fa lehetőséget
  8. A BaseDN-hez írja be a CN=App,DC=contoso, DC=lab értéket, és kattintson az OK gombra.
  9. A bal oldalon bontsa ki a DN-t, és kattintson a CN=CloudUsers,CN=App,DC=contoso, DC=lab elemre. Látnia kell azokat a felhasználókat, akik a Microsoft Entra-azonosítóból lettek kiépítve. A felhasználók ldp-kötését bemutató képernyőkép.

Az alábbi utasítások bemutatják, hogyan ellenőrizheti az OpenLDAP-t.

  1. Nyisson meg egy terminálablakot egy parancshéjjal a rendszeren az OpenLDAP használatával.
  2. Írja be a parancsot ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson)
  3. Ellenőrizze, hogy az eredményként kapott LDIF tartalmazza-e a Microsoft Entra-azonosítóból kiépített felhasználókat.

Következő lépések