User Principal Name (UPN): a fogalom jelentése és szerepe a Microsoft Active Directoryban

A modern informatikai rendszerek gerincét képező felhasználói identitáskezelés egyik alapköve a Microsoft Active Directoryban a User Principal Name, vagy röviden UPN. Ez az egyedi azonosító kulcsfontosságú szerepet játszik abban, ahogyan a felhasználók hozzáférnek a hálózati erőforrásokhoz, alkalmazásokhoz és szolgáltatásokhoz. Az UPN nem csupán egy technikai paraméter, hanem egy olyan identitásréteg, amely az egyszerűség és az interoperabilitás jegyében született, megkönnyítve a felhasználók számára a bejelentkezést és a rendszergazdák számára az identitások kezelését, különösen komplex, hibrid környezetekben.

Az Active Directory bevezetése óta az UPN az egyik leggyakrabban használt és legintuitívabb felhasználói azonosító. Felépítése emlékeztet egy e-mail címre, ami jelentősen hozzájárul a könnyű megjegyezhetőségéhez és használatához. Miközben a háttérben bonyolult mechanizmusok dolgoznak a felhasználók hitelesítésén és jogosultságainak ellenőrzésén, az UPN a felhasználó felé egy egyszerű, mégis robusztus interfészt biztosít. Ez a cikk részletesen bemutatja az UPN fogalmát, felépítését, működését, az Active Directoryban betöltött szerepét, valamint a kapcsolódó beállítási és hibaelhárítási praktikákat, különös tekintettel a modern hibrid és felhő alapú környezetekre.

Mi az a user principal name (UPN)?

A User Principal Name (UPN) egy olyan attribútum a Microsoft Active Directoryban, amely egyedi azonosítóként szolgál a felhasználók számára. Elsődleges célja, hogy a felhasználók ezzel az azonosítóval jelentkezzenek be a tartományba, illetve a különböző hálózati szolgáltatásokba. Az UPN formátuma szándékosan hasonlít egy e-mail címre, ezzel is megkönnyítve a felhasználók számára a megjegyzését és használatát.

Az UPN két fő részből áll, amelyeket a „@” jel választ el egymástól. Az első rész a felhasználónév (user logon name), a második rész pedig az UPN-utótag (UPN suffix). Például, ha egy felhasználó UPN-je janos.kovacs@valami.hu, akkor janos.kovacs a felhasználónév, és valami.hu az UPN-utótag.

Ez a struktúra nem csak intuitív, de lehetővé teszi, hogy a felhasználónév ne feltétlenül egyezzen meg a felhasználó SAM-account-name-jével (pre-Windows 2000 logon name), vagy akár az e-mail címével. Ez rugalmasságot biztosít a rendszergazdák számára az identitások kezelésében, különösen olyan esetekben, ahol több Active Directory tartomány található egy erdőben, vagy amikor egy vállalat azonos domain nevet használ a belső hálózatán, mint a külső, internetes DNS nevében.

Az UPN egy olyan univerzális identitás, amely leegyszerűsíti a felhasználói bejelentkezést, különösen komplex hálózati struktúrákban és hibrid környezetekben.

Az UPN-utótag nem feltétlenül azonos az Active Directory tartomány DNS nevével. Bár az alapértelmezett UPN-utótag megegyezik a tartomány DNS nevével, a rendszergazdák hozzáadhatnak alternatív UPN-utótagokat is az Active Directory erdőhöz. Ez a képesség rendkívül hasznos lehet például vállalatfelvásárlások vagy egyesülések során, amikor a felhasználók UPN-jeit konzisztenssé szeretnék tenni, függetlenül attól, hogy melyik eredeti tartományból származnak.

Az UPN felépítése: felhasználónév és UPN-utótag

Az UPN két elkülönülő komponense, a felhasználónév és az UPN-utótag, együttesen biztosítják az identitás egyediségét és funkcionalitását. A felhasználónév (user logon name) az UPN bal oldali része, az „@” jel előtt. Ez a rész általában egyedi a tartományon belül, bár technikailag nem kötelezően egyedi egy erdőn belül, ha az UPN-utótagok különböznek. Gyakran megegyezik a felhasználó kereszt- és vezetéknevének valamilyen kombinációjával, vagy egy rövidített azonosítóval.

A felhasználónév kiválasztásakor érdemes figyelembe venni az olvashatóságot és az egyediséget. Például, ha a tartományban már létezik kovacs.janos nevű felhasználó, egy újabb Kovács János felhasználó UPN-je lehet kovacs.janos2 vagy jkovacs. A cél, hogy a felhasználó könnyen be tudja gépelni és meg tudja jegyezni.

Az UPN-utótag (UPN suffix) az UPN jobb oldali része, az „@” jel után. Ez a rész azonosítja azt az erdőt, amelyhez a felhasználó tartozik. Az UPN-utótag lehet az Active Directory tartomány DNS neve (ez az alapértelmezett), vagy egy alternatív utótag, amelyet a rendszergazda manuálisan ad hozzá az erdőhöz. Az alternatív UPN-utótagok lehetővé teszik a szervezetek számára, hogy olyan bejelentkezési neveket használjanak, amelyek eltérnek a belső tartománynevektől, például egy külső, nyilvános DNS névvel megegyező nevet.

Például, ha egy vállalat belső Active Directory tartományneve belső.local, de a nyilvános weboldaluk domain neve cegneve.hu, akkor a rendszergazda hozzáadhatja a cegneve.hu-t mint alternatív UPN-utótagot. Így a felhasználók bejelentkezhetnek felhasznalo@cegneve.hu formában, ami sokkal professzionálisabb és könnyebben kezelhető, mint a felhasznalo@belső.local.

Az UPN-utótagok kezelése az Active Directory Domains and Trusts konzolon keresztül történik. Itt lehet megtekinteni az alapértelmezett tartományi utótagot, valamint hozzáadni, szerkeszteni vagy eltávolítani az alternatív utótagokat. Fontos megjegyezni, hogy az UPN-utótagok erdő szinten konfigurálhatók, így az erdő összes tartományában elérhetővé válnak.

Az UPN történelmi kontextusa és az Active Directory integrációja

Az UPN fogalma az Active Directoryval együtt jelent meg a Windows 2000 Server operációs rendszerben. Előtte a felhasználók azonosítására és bejelentkezésére főként a SAM-account-name (Security Account Manager account name) szolgált, amely egy egyszerű, legfeljebb 20 karakter hosszúságú név volt, gyakran egyezett a felhasználó bejelentkezési nevével a NetBIOS tartományokban.

Azonban a SAM-account-name számos korláttal rendelkezett. Nem volt globálisan egyedi egy Active Directory erdőn belül, és nem volt alkalmas az internet-centrikus világ elvárásainak. Az internet térnyerésével szükségessé vált egy olyan azonosító, amely globálisan egyedi, könnyen kezelhető és illeszkedik az e-mail címek logikájához, amelyek már akkoriban is széles körben elterjedtek voltak.

Az UPN-t úgy tervezték, hogy áthidalja ezeket a korlátokat. Lehetővé tette a felhasználók számára, hogy egyetlen, könnyen megjegyezhető névvel jelentkezzenek be, függetlenül attól, hogy melyik tartományban található a felhasználói fiókjuk az Active Directory erdőn belül. Ez jelentősen leegyszerűsítette a felhasználói élményt és a rendszergazdai feladatokat, különösen nagy és elosztott hálózatokban.

Az UPN az Active Directoryban a felhasználói objektum egyik attribútumaként van tárolva, pontosabban a userPrincipalName attribútumban. Ez az attribútum indexelt, ami gyors keresést tesz lehetővé. Amikor egy felhasználó bejelentkezik az UPN-jével, a tartományvezérlő ezt az attribútumot használja a felhasználó fiókjának megkeresésére és a hitelesítés elvégzésére. Az UPN-t a Kerberos hitelesítési protokoll is használja, amely az Active Directory alapértelmezett hitelesítési mechanizmusa.

A Kerberos protokollban az UPN a Service Principal Name (SPN) része is lehet, ami lehetővé teszi a szolgáltatások számára, hogy azonosítsák magukat a tartományon belül. Ez a mély integráció teszi az UPN-t az Active Directory identitáskezelésének egyik legfontosabb elemévé, amely a helyi hálózatoktól a felhőalapú szolgáltatásokig mindenhol megjelenik.

Az UPN és más Active Directory azonosítók közötti különbségek

Az Active Directory számos azonosítót használ a felhasználók, csoportok és egyéb objektumok egyedi beazonosítására. Az UPN mellett a leggyakrabban előfordulóak a SAM-account-name, a Distinguished Name (DN) és az ObjectGUID. Fontos megérteni a köztük lévő különbségeket és azonosítási céljaikat.

SAM-account-name (pre-Windows 2000 logon name)

A SAM-account-name a hagyományos NetBIOS tartományokból örökölt azonosító. Ez egy legfeljebb 20 karakterből álló név, amelynek egyedinek kell lennie a tartományon belül. Formátuma egyszerű, például JANOSK. A felhasználók korábban ezzel a névvel jelentkeztek be, gyakran a tartomány neve elé írva (pl. DOMAIN\JANOSK). Bár az UPN vált az elsődleges bejelentkezési módszerré, a SAM-account-name továbbra is létezik minden felhasználói fiókhoz, és bizonyos régebbi alkalmazások vagy szolgáltatások még mindig ezt használhatják hitelesítésre.

Distinguished Name (DN)

A Distinguished Name (DN) egy olyan egyedi azonosító, amely pontosan meghatározza egy objektum helyét az Active Directory hierarchiájában. Ez egy hierarchikus útvonal, amely az objektumtól a tartomány gyökeréig vezet. Például, egy felhasználó DN-je lehet CN=Kovacs Janos,OU=Felhasznalok,DC=valami,DC=hu. A DN minden Active Directory objektumhoz egyedi, és a Lightweight Directory Access Protocol (LDAP) lekérdezésekben gyakran használják az objektumok megtalálására. A DN nem használható közvetlenül bejelentkezésre, célja az objektumok adminisztratív azonosítása és kezelése.

ObjectGUID

Az ObjectGUID (Globally Unique Identifier) egy 128 bites szám, amely minden Active Directory objektum létrehozásakor automatikusan generálódik. Ez az azonosító garantáltan egyedi az egész világon, és soha nem változik az objektum élettartama során, még akkor sem, ha az objektumot áthelyezik egy másik tartományba vagy átnevezik. Az ObjectGUID-t belsőleg használja az Active Directory a replikációhoz és az objektumok hivatkozásához. Mivel nehéz olvasni és megjegyezni, a felhasználók nem használják közvetlenül, de a rendszergazdák számára fontos lehet a hibaelhárításban és szkriptekben.

Összehasonlítva, az UPN a felhasználók számára készült, könnyen megjegyezhető bejelentkezési azonosító. A SAM-account-name egy régebbi, kompatibilitási célokat szolgáló azonosító. A DN az objektumok hierarchikus helyét írja le, míg az ObjectGUID egy belső, állandó, globálisan egyedi azonosító. Mindegyiknek megvan a maga szerepe az Active Directory ökoszisztémájában, de az UPN az, amely a felhasználói élmény középpontjában áll.

UPN utótagok kezelése és konfigurálása az Active Directoryban

Az UPN utótagok megfelelő kezelése kulcsfontosságú az Active Directory környezetekben, különösen akkor, ha a szervezet hibrid identitáskezelést valósít meg, vagy több tartományt foglal magában. Az UPN utótagok beállítása és módosítása az Active Directory Domains and Trusts konzolon keresztül történik.

Alapértelmezett UPN utótag

Minden Active Directory erdő rendelkezik egy vagy több alapértelmezett UPN utótaggal. Ezek az utótagok megegyeznek az erdőben található tartományok DNS neveivel. Amikor létrehoznak egy új felhasználót, az alapértelmezett UPN utótagok listájából választható ki a felhasználó UPN-jének jobb oldali része. Ha például egy tartomány neve contoso.com, akkor az alapértelmezett UPN utótag is contoso.com lesz, és a felhasználók UPN-jei felhasznalo@contoso.com formátumúak lehetnek.

Alternatív UPN utótagok hozzáadása

Számos forgatókönyv indokolja alternatív UPN utótagok hozzáadását:

• Egyszerűsítés: A belső tartománynevek (pl. belső.local) gyakran nem alkalmasak nyilvános használatra. Egy külső, nyilvános DNS név (pl. cegem.hu) UPN utótagként történő használata professzionálisabb és könnyebben kommunikálható.
• Vállalatfelvásárlások és egyesülések: Két vagy több vállalat összeolvadásakor a felhasználói identitásokat egységesíteni kell. Alternatív UPN utótagok segítségével az összes felhasználó egységes UPN formátumot kaphat, függetlenül az eredeti tartományától.
• Hibrid identitás: Az Azure Active Directory-val (AAD) való szinkronizáció során gyakran előnyös, ha az UPN-ek egyeznek a felhasználók e-mail címeivel, vagy egy nyilvánosan regisztrált domain névvel. Ez megkönnyíti a szinkronizációt és a felhasználói bejelentkezést a felhőalapú szolgáltatásokba.

Az alternatív UPN utótag hozzáadása a következő lépésekben történik:

1. Nyissa meg az Active Directory Domains and Trusts konzolt (domain.msc).
2. Kattintson jobb gombbal az „Active Directory Domains and Trusts” gyökérelemre a bal oldali panelen, majd válassza a Properties (Tulajdonságok) lehetőséget.
3. A „UPN Suffixes” (UPN utótagok) lapon adja meg az új UPN utótagot a „Alternative UPN suffixes” (Alternatív UPN utótagok) mezőbe.
4. Kattintson az Add (Hozzáadás) gombra, majd az OK gombra a módosítások mentéséhez.

Fontos, hogy az hozzáadott UPN utótag érvényes DNS név legyen, még ha nem is kell feltétlenül regisztrálva lennie az interneten. Azonban hibrid környezetben javasolt, hogy az UPN utótag egyezzen egy nyilvánosan regisztrált és ellenőrzött domain névvel az Azure AD-ben.

UPN utótagok eltávolítása

Alternatív UPN utótagokat eltávolítani is lehet, de óvatosan kell eljárni. Ha egy utótagot eltávolítanak, és azzal az utótaggal rendelkező felhasználók léteznek, azoknak a felhasználóknak a bejelentkezése meghiúsulhat az UPN-jükkel. Az eltávolítás előtt minden érintett felhasználó UPN-jét módosítani kell egy másik, érvényes UPN utótagra.

Az UPN utótagok gondos tervezése és kezelése elengedhetetlen a zökkenőmentes felhasználói élmény és az Active Directory hatékony működése szempontjából.

Felhasználói UPN-ek beállítása és módosítása

A felhasználói UPN-ek beállítása és módosítása az Active Directory Users and Computers (ADUC) konzolon keresztül vagy PowerShell szkriptek segítségével történhet. Mindkét módszernek megvannak a maga előnyei, attól függően, hogy egyedi módosításról vagy tömeges műveletről van szó.

Új felhasználó létrehozása UPN-nel

Amikor új felhasználót hozunk létre az ADUC-ban, a „User logon name” mező kitöltésekor automatikusan létrejön az UPN felhasználónév része. A legördülő menüből választható ki az UPN utótag, amely lehet az alapértelmezett tartományi utótag vagy bármelyik korábban hozzáadott alternatív UPN utótag.

A megfelelő UPN kiválasztása már a felhasználó létrehozásakor megteremti az alapot a zökkenőmentes bejelentkezéshez és a felhőalapú szolgáltatások integrációjához.

Ez a lépés kritikus, mivel a felhasználó ezzel az UPN-nel fog bejelentkezni a legtöbb Microsoft szolgáltatásba és alkalmazásba. Fontos, hogy az UPN egyedi legyen az erdőben, ha az UPN-utótag azonos. Ha két felhasználó UPN-je megegyezik, az bejelentkezési problémákhoz vezethet.

Már létező felhasználók UPN-jének módosítása

Egy már létező felhasználó UPN-jét az ADUC konzolon a következőképpen módosíthatja:

1. Nyissa meg az Active Directory Users and Computers konzolt (dsa.msc).
2. Keresse meg és kattintson jobb gombbal a módosítani kívánt felhasználói fiókra.
3. Válassza a Properties (Tulajdonságok) lehetőséget.
4. A „Account” (Fiók) lapon a „User logon name” (Felhasználói bejelentkezési név) részben módosíthatja a felhasználónév részt, és kiválaszthatja az új UPN utótagot a legördülő menüből.
5. Kattintson az Apply (Alkalmaz), majd az OK gombra a változtatások mentéséhez.

Az UPN módosítása után a felhasználónak az új UPN-nel kell bejelentkeznie. Fontos, hogy a felhasználót előzetesen tájékoztassuk a változásról, hogy elkerüljük a bejelentkezési problémákat.

Tömeges UPN módosítás PowerShell-lel

Nagyobb szervezetekben, vagy domain migrációk során gyakran van szükség több száz vagy akár több ezer felhasználó UPN-jének tömeges módosítására. Erre a feladatra a PowerShell a legalkalmasabb eszköz.

Például, ha az összes felhasználó UPN-utótagját regi.local-ról uj.com-ra szeretné módosítani, a következő PowerShell parancsot használhatja:

Get-ADUser -Filter {UserPrincipalName -like "*@regi.local"} -Properties UserPrincipalName | ForEach-Object {
    $newUPN = $_.UserPrincipalName.Replace("@regi.local", "@uj.com")
    Set-ADUser -Identity $_.SamAccountName -UserPrincipalName $newUPN
    Write-Host "Felhasználó: $($_.SamAccountName) UPN módosítva: $($_.UserPrincipalName) -> $newUPN"
}

Ez a szkript megkeresi az összes felhasználót, akinek az UPN-je @regi.local-ra végződik, majd lecseréli az utótagot @uj.com-ra. Fontos, hogy a szkript futtatása előtt alaposan tesztelje azt egy kis számú felhasználón, és győződjön meg arról, hogy az uj.com UPN utótag már hozzá lett adva az Active Directoryhoz.

A PowerShell rugalmasságot biztosít komplexebb forgatókönyvekhez is, például ha a felhasználónév részt is módosítani kell, vagy ha bizonyos feltételek alapján kell kiválasztani a felhasználókat. A Get-ADUser és Set-ADUser parancsmagok kulcsfontosságúak ezen műveletek végrehajtásában.

Az UPN szerepe a hibrid identitáskezelésben

A modern IT-környezetekben a helyi (on-premises) Active Directory és a felhőalapú Azure Active Directory (Azure AD) közötti hibrid identitáskezelés vált normává. Ebben a felállásban az UPN kulcsfontosságú szerepet játszik a felhasználói identitások szinkronizálásában és a zökkenőmentes bejelentkezés biztosításában a felhőalapú szolgáltatásokba, mint például a Microsoft 365.

Azure AD Connect szinkronizáció

Az Azure AD Connect eszköz felelős a helyi Active Directory felhasználói, csoportjai és egyéb objektumai szinkronizálásáért az Azure AD-be. Az Azure AD Connect alapértelmezés szerint az Active Directory felhasználók userPrincipalName attribútumát használja a felhasználó UserPrincipalName attribútumának forrásaként az Azure AD-ben.

Ez azt jelenti, hogy ha egy felhasználó UPN-je a helyi AD-ben felhasznalo@valami.hu, akkor az Azure AD-ben is ez lesz az elsődleges bejelentkezési azonosítója. Ez az illesztés kritikus a felhasználói élmény szempontjából, mivel a felhasználók a megszokott bejelentkezési nevükkel férhetnek hozzá a felhőalapú erőforrásokhoz.

UPN illesztési problémák és megoldásuk

Gyakran előfordul, hogy a helyi Active Directory UPN-utótagja nem egyezik meg egy ellenőrzött domain névvel az Azure AD-ben. Például, ha a helyi AD-ben a felhasználók UPN-je felhasznalo@cegem.local, de az Azure AD-ben csak a cegem.hu domain van ellenőrizve, akkor szinkronizációs hibák léphetnek fel.

Ilyen esetekben az Azure AD Connect alapértelmezés szerint a helyi AD-ből származó UPN-t felülírja egy ideiglenes, .onmicrosoft.com utótaggal rendelkező UPN-nel az Azure AD-ben (pl. felhasznalo@cegem.onmicrosoft.com). Ez a felhasználó számára zavaró lehet, és megnehezíti a bejelentkezést.

A probléma megoldására a legjobb gyakorlat a következő:

1. Adjon hozzá alternatív UPN utótagot a helyi Active Directoryhoz: Győződjön meg róla, hogy a helyi AD-hez hozzáadta azt a nyilvánosan regisztrált domain nevet (pl. cegem.hu), amelyet az Azure AD-ben is ellenőrzött.
2. Módosítsa a felhasználók UPN-jét a helyi AD-ben: Frissítse a felhasználók UPN-jét a helyi AD-ben, hogy az az új, ellenőrzött UPN utótagot használja (pl. felhasznalo@cegem.hu). Ezt tömegesen PowerShell-lel lehet a leghatékonyabban elvégezni.
3. Futtasson teljes szinkronizációt az Azure AD Connecttel: Miután a helyi AD-ben módosultak az UPN-ek, futtasson egy teljes szinkronizációs ciklust az Azure AD Connecttel, hogy a változások átvezetődjenek az Azure AD-be.

Ez biztosítja, hogy a felhasználók UPN-jei konzisztensek legyenek a helyi és a felhőalapú környezetben, és zökkenőmentesen tudjanak bejelentkezni a Microsoft 365, Azure portál és más felhőalapú szolgáltatásokba.

UPN és a Microsoft 365/Office 365 szolgáltatások

A Microsoft 365 szolgáltatások, mint az Exchange Online, SharePoint Online, Teams és OneDrive, szorosan integrálódnak az Azure AD-vel. A felhasználók bejelentkezéséhez és az identitáskezeléshez az UPN az elsődleges azonosító. Ha az UPN-ek helyesen vannak konfigurálva és szinkronizálva, a felhasználók problémamentesen hozzáférhetnek ezekhez a szolgáltatásokhoz.

Az Exchange Online esetében különösen fontos az UPN és az e-mail cím közötti kapcsolat. Bár az UPN és az elsődleges SMTP cím nem feltétlenül kell, hogy megegyezzen, a legjobb gyakorlat szerint érdemes őket azonosnak tartani a felhasználói élmény egyszerűsítése érdekében. Ha az UPN és az e-mail cím eltér, a felhasználóknak két különböző azonosítót kellene megjegyezniük, ami zavart okozhat.

Az Azure AD-ben van lehetőség alternatív bejelentkezési azonosítók (Alternate Login IDs) használatára is, ami lehetővé teszi, hogy a felhasználók az UPN-jük helyett például az e-mail címükkel jelentkezzenek be. Ez hasznos lehet olyan forgatókönyvekben, ahol az UPN nem egyezik az e-mail címmel, és nem szeretnék módosítani a helyi AD UPN-jeit. Azonban az elsődleges és leggyakrabban használt azonosító továbbra is az UPN marad a legtöbb esetben.

Az UPN és a hitelesítés

Az UPN nem csupán egy azonosító, hanem alapvető szerepet játszik a felhasználók hitelesítésében is, különösen az Active Directory környezetekben, ahol a Kerberos protokoll a domináns hitelesítési mechanizmus. Emellett a modern felhőalapú hitelesítési protokollok, mint az OAuth és az OpenID Connect is támaszkodnak rá.

Kerberos hitelesítés

Amikor egy felhasználó bejelentkezik egy Windows tartományba az UPN-jével, a kliensgép egy Kerberos jegyigénylő kérést (Authentication Service Request, AS-REQ) küld a tartományvezérlőnek. Ebben a kérésben a felhasználó UPN-je szerepel, mint azonosító. A tartományvezérlő (amely egy Key Distribution Center, KDC szerepet is betölt) megkeresi a felhasználói fiókot az Active Directoryban az UPN alapján, ellenőrzi a jelszót, és ha sikeres a hitelesítés, egy jegy-adományozó jegyet (Ticket Granting Ticket, TGT) ad ki a felhasználónak.

A Service Principal Name (SPN) fogalma szorosan kapcsolódik az UPN-hez a Kerberos hitelesítésben. Az SPN egyedi azonosítója egy szolgáltatásnak, és a Kerberos protokoll használja a szolgáltatás példányának egyedi azonosítására. Bár az SPN elsősorban szolgáltatásokhoz kapcsolódik, bizonyos esetekben a felhasználói UPN is szerepet kaphat az SPN formátumában, különösen akkor, ha egy felhasználói fiók futtat valamilyen szolgáltatást.

NTLM hitelesítés

Bár a Kerberos az elsődleges hitelesítési protokoll az Active Directoryban, az NTLM (NT LAN Manager) protokoll még mindig használatban van bizonyos régebbi rendszerekben vagy olyan esetekben, amikor a Kerberos nem elérhető (pl. munkacsoport-környezetekben vagy nem megbízható tartományok közötti kommunikáció során). Az NTLM hitelesítés során a felhasználók általában a SAM-account-name-jükkel vagy a DOMAIN\SAM-account-name formátummal jelentkeznek be, és nem az UPN-jükkel. Ez egyike azon különbségeknek, amelyek kiemelik az UPN modern, internet-centrikus megközelítését a régebbi NTLM-hez képest.

Modern hitelesítési protokollok és az UPN

A felhőalapú szolgáltatások és a webes alkalmazások térnyerésével új hitelesítési protokollok, mint az OAuth 2.0 és az OpenID Connect kerültek előtérbe. Ezek a protokollok gyakran használják az UPN-t vagy annak egy ekvivalensét a felhasználói identitás azonosítására. Amikor egy felhasználó bejelentkezik egy felhőalapú alkalmazásba, amely az Azure AD-t használja identitás-szolgáltatóként, az UPN az elsődleges azonosító, amelyet az alkalmazás megkap az azonosító tokenben (ID token) a felhasználó beazonosítására.

Az Azure AD Connect által szinkronizált UPN-ek biztosítják a konzisztenciát a helyi és a felhőalapú hitelesítés között. Ez lehetővé teszi az egyszeri bejelentkezés (Single Sign-On, SSO) megvalósítását, ahol a felhasználó egyszer jelentkezik be a helyi hálózaton, és automatikusan hozzáfér a felhőalapú erőforrásokhoz is, anélkül, hogy újra be kellene írnia a hitelesítő adatait.

Pass-through Authentication (PTA) és Password Hash Synchronization (PHS)

Az Azure AD Connect két fő hitelesítési módszert kínál a hibrid környezetekben:

• Password Hash Synchronization (PHS): Ebben az esetben a helyi AD-ből a felhasználói jelszavak hash-ei szinkronizálásra kerülnek az Azure AD-be. Amikor a felhasználó bejelentkezik az Azure AD-be az UPN-jével, a hitelesítés az Azure AD-ben történik, a szinkronizált jelszó hash segítségével.
• Pass-through Authentication (PTA): Ebben a módszerben a felhasználói jelszavak nem szinkronizálódnak az Azure AD-be. Amikor a felhasználó bejelentkezik az Azure AD-be az UPN-jével, az Azure AD a hitelesítési kérést átirányítja egy helyi AD tartományvezérlőhöz, amely elvégzi a hitelesítést.

Mindkét esetben az UPN a felhasználó elsődleges azonosítója a bejelentkezés során, biztosítva a felhasználói fiók egyedi azonosítását és a megfelelő hitelesítési folyamat elindítását.

Biztonsági megfontolások az UPN használatával

Az UPN kényelmes és felhasználóbarát azonosító, de használata során fontos figyelembe venni bizonyos biztonsági szempontokat. A helytelen konfiguráció vagy a nem megfelelő kezelés potenciális kockázatokat rejthet magában.

Adatvédelmi kockázatok

Ha az UPN megegyezik a felhasználó e-mail címével, ami gyakori gyakorlat, az adatvédelmi aggályokat vethet fel. Az e-mail címek gyakran nyilvánosan elérhetők, és ha ez azonos az UPN-nel, akkor egy támadó könnyen megszerezheti a felhasználó bejelentkezési nevét. Ez önmagában nem jelent közvetlen veszélyt, de megkönnyítheti a jelszó spray támadásokat.

A jelszó spray támadások során a támadó nem egy felhasználóhoz próbál meg sok jelszót, hanem sok felhasználóhoz próbál meg néhány gyakori jelszót. Ha a bejelentkezési név (UPN) könnyen kitalálható vagy nyilvános, a támadó célzottabban tudja elvégezni ezeket a támadásokat.

Jelszó spray támadások elleni védelem

A jelszó spray támadások elleni védekezés érdekében a következő intézkedések javasoltak:

• Erős jelszóházirend: Kötelezővé kell tenni az erős, komplex jelszavakat, amelyek nehezen kitalálhatók.
• Fiókzárási házirend: Az Active Directory fiókzárási házirendjét úgy kell beállítani, hogy bizonyos számú sikertelen bejelentkezési kísérlet után zárolja a fiókot. Fontos a küszöbérték körültekintő beállítása, hogy elkerüljük a szolgáltatásmegtagadási támadásokat (DoS).
• Multi-Factor Authentication (MFA): Ez a legfontosabb védelmi réteg. Az MFA megköveteli a felhasználóktól, hogy a jelszavukon kívül egy második hitelesítési tényezőt (pl. telefonos értesítés, biometrikus azonosító) is biztosítsanak. Ez drasztikusan csökkenti a jelszó spray támadások sikerességét, még akkor is, ha a támadó ismeri az UPN-t és a jelszót.
• Felhasználói viselkedés elemzése (UEBA): Az anomáliák észlelésére szolgáló rendszerek segíthetnek azonosítani a gyanús bejelentkezési mintázatokat, például több fiók sikertelen bejelentkezési kísérleteit rövid időn belül.

UPN elrejtése a bejelentkezési képernyőn

Bizonyos esetekben, különösen magas biztonsági követelményekkel rendelkező környezetekben, megfontolható az UPN (vagy a felhasználónév) elrejtése a bejelentkezési képernyőn. Ez megakadályozza, hogy a potenciális támadók könnyen hozzájussanak a bejelentkezési nevekhez. Ezt a Windows Group Policy beállításain keresztül lehet konfigurálni, például a „Interactive logon: Do not display last user name” (Interaktív bejelentkezés: Ne jelenítse meg az utolsó felhasználónevet) házirend bekapcsolásával.

Ez a beállítás növeli a „security by obscurity” szintjét, de nem helyettesíti az alapvető biztonsági intézkedéseket, mint az erős jelszavak és az MFA. A rétegzett védelem (defense in depth) elvét követve érdemes kombinálni a különböző biztonsági mechanizmusokat.

Azonosítók és jogosultságok elkülönítése

Az UPN-t elsősorban bejelentkezési azonosítóként használják. Fontos, hogy a jogosultságok kezelése ne kizárólag az UPN-re épüljön, hanem a felhasználói fiókokhoz rendelt biztonsági csoportokra. Ez biztosítja a rugalmasságot és a könnyebb kezelhetőséget, valamint elkerüli, hogy az UPN módosítása esetén a jogosultságok elveszjenek vagy hibásan működjenek.

A biztonsági szempontok alapos mérlegelése és a legjobb gyakorlatok alkalmazása elengedhetetlen az UPN hatékony és biztonságos használatához az Active Directory és hibrid környezetekben.

Gyakori problémák és hibaelhárítás az UPN-nel

Bár az UPN egy robusztus azonosító, a nem megfelelő konfiguráció vagy a szinkronizációs hibák problémákat okozhatnak. A rendszergazdák számára elengedhetetlen a gyakori hibák ismerete és a hibaelhárítási lépések elsajátítása.

UPN ütközések (duplikált UPN-ek)

Az UPN-nek egyedinek kell lennie az egész Active Directory erdőben, ha az UPN-utótagok is azonosak. Ha két felhasználónak ugyanaz az UPN-je, az bejelentkezési problémákhoz vezethet, mivel a tartományvezérlő nem tudja egyértelműen azonosítani a felhasználót. Ez különösen akkor fordulhat elő, ha több tartomány van egy erdőben, és a rendszergazdák nem figyelnek az egyediségre.

Hibaelhárítás:

• Keresés duplikált UPN-ekre: PowerShell-lel könnyen azonosíthatók a duplikált UPN-ek. A következő parancs listázza azokat az UPN-eket, amelyekből több is létezik:

  Get-ADUser -Filter * -Properties UserPrincipalName | Group-Object -Property UserPrincipalName | Where-Object {$_.Count -gt 1} | Select-Object Name, Count

• UPN módosítása: Az azonosított duplikált UPN-ek egyikét (vagy mindkettőt) módosítani kell egy egyedi értékre.

Bejelentkezési problémák helytelen UPN miatt

Ha a felhasználó nem tud bejelentkezni az UPN-jével, a probléma oka lehet, hogy az UPN helytelenül van beállítva, vagy a felhasználó nem a megfelelő UPN-t használja.

Hibaelhárítás:

• UPN ellenőrzése az AD-ben: Ellenőrizze a felhasználó UPN-jét az Active Directory Users and Computers konzolon. Győződjön meg róla, hogy helyes a felhasználónév rész és az UPN-utótag is.
• Alternatív UPN utótagok ellenőrzése: Győződjön meg arról, hogy az UPN-ben használt utótag létezik és érvényes az Active Directory Domains and Trusts konzolon.
• Jelszó ellenőrzése: Győződjön meg arról, hogy a felhasználó a helyes jelszót használja.
• Fiókzárás ellenőrzése: Lehet, hogy a fiók zárolva van túl sok sikertelen bejelentkezési kísérlet miatt.
• Kerberos naplózás: A tartományvezérlők eseménynaplói (Security log) részletes információkat tartalmazhatnak a Kerberos hitelesítési hibákról. Keresse az 4768, 4769, 4771, 4776 eseményazonosítókat.

Szinkronizációs hibák az Azure AD Connectben (UPN attribútum)

A hibrid környezetekben az Azure AD Connect szinkronizációs hibái gyakran az UPN-hez kapcsolódnak.

Hibaelhárítás:

• Ellenőrzött tartományok az Azure AD-ben: Győződjön meg róla, hogy az UPN-ben használt összes tartomány (utótag) ellenőrizve van az Azure AD-ben. Ha nincs, akkor a felhasználók UPN-jei módosulhatnak .onmicrosoft.com utótagra, vagy szinkronizációs hibák léphetnek fel.
• Azure AD Connect Sync Service Manager: Ez az eszköz részletes információkat nyújt a szinkronizációs hibákról. Keresse meg azokat a hibákat, amelyek az userPrincipalName attribútumhoz kapcsolódnak.
• Attribútum-szinkronizációs szabályok: Ellenőrizze az Azure AD Connect attribútum-szinkronizációs szabályait, különösen azokat, amelyek a userPrincipalName attribútumot érintik. Előfordulhat, hogy egy egyéni szabály felülírja az alapértelmezett viselkedést.
• Soft Match / Hard Match: Ha egy felhasználói fiók már létezik az Azure AD-ben, és megpróbálják szinkronizálni egy helyi AD fiókkal, az UPN (és az ImmutableID) kulcsfontosságú a fiókok illesztésében. Ha az UPN-ek nem egyeznek, az „Soft Match” hibához vezethet.

A hatékony hibaelhárítás érdekében fontos a részletes naplózás engedélyezése és az Active Directory, az Azure AD Connect és az Azure AD közötti adatfolyam megértése.

Az UPN és a modern identitáskezelés jövője

Az UPN, mint az Active Directory alapvető azonosítója, továbbra is kulcsszerepet játszik a modern identitáskezelési stratégiákban, különösen a felhőalapú és hibrid környezetekben. Azonban az identitáskezelés folyamatosan fejlődik, és az UPN szerepe is változik a jövőben.

Felhő alapú identitáskezelés dominanciája

A felhőalapú identitáskezelés, mint az Azure Active Directory, egyre inkább dominánssá válik. Bár az UPN továbbra is az elsődleges bejelentkezési azonosító marad a legtöbb esetben, az Azure AD rugalmasabbá teszi az identitások kezelését. Lehetővé teszi alternatív bejelentkezési azonosítók használatát (pl. e-mail cím), és támogatja a jelszó nélküli bejelentkezési módszereket, amelyek csökkentik az UPN közvetlen szerepét a felhasználói interakcióban.

Jelszó nélküli hitelesítés és az UPN

A jelszó nélküli hitelesítés, mint a FIDO2 biztonsági kulcsok, Windows Hello for Business vagy a Microsoft Authenticator alkalmazás, egyre nagyobb teret nyer. Ezek a módszerek jelentősen növelik a biztonságot és javítják a felhasználói élményt. Bár a felhasználó nem feltétlenül írja be az UPN-jét a bejelentkezéskor, az UPN továbbra is a háttérben működő identitás azonosítója marad, amelyhez a jelszó nélküli hitelesítő adatok kapcsolódnak.

Ez azt jelenti, hogy az UPN továbbra is alapvető azonosítóként fog szolgálni az identitáskezelési rendszerekben, de a felhasználók egyre kevésbé fognak közvetlenül interakcióba lépni vele a bejelentkezési folyamat során.

Decentralizált identitás (DID) és az UPN szerepe

A decentralizált identitás (Decentralized Identity, DID) egy új, feltörekvő paradigmája az identitáskezelésnek, amelyben a felhasználók nagyobb kontrollal rendelkeznek saját digitális identitásuk felett, és nem egy központi szolgáltató kezeli azt. Bár ez a technológia még viszonylag új, hosszú távon átalakíthatja az identitáskezelés világát.

A DID rendszerekben a felhasználók saját „digitális pénztárcájukban” tárolják az igazolványaikat, és ezeket osztják meg a szolgáltatókkal. Az UPN, mint egy központilag kezelt azonosító, valószínűleg nem illeszkedik közvetlenül a DID modellbe. Azonban az Active Directory és az Azure AD továbbra is alapvető identitás-forrásként szolgálhat a DID rendszerek számára, ahol az UPN lehet az alapja annak az igazolványnak, amelyet a felhasználó a DID ökoszisztémában bemutat.

A Microsoft stratégiája

A Microsoft folyamatosan fejleszti az identitáskezelési megoldásait, és az UPN továbbra is központi eleme marad a stratégiájuknak. Az Azure AD, mint a Microsoft Cloud identitásplatformja, szorosan integrálódik az UPN-nel, és biztosítja a zökkenőmentes átmenetet a helyi Active Directoryból a felhőbe.

A hangsúly a biztonság növelésén (MFA, jelszó nélküli hitelesítés), az egyszerűsített felhasználói élményen és a rugalmas integráción van a különböző alkalmazásokkal és szolgáltatásokkal. Az UPN, mint egyedi és könnyen azonosítható attribútum, továbbra is alapvető építőeleme lesz ennek a jövőbeli identitás-ökoszisztémának, még ha a felhasználók egyre kevésbé is fognak tudatosan interakcióba lépni vele a mindennapi bejelentkezések során.