Sokszor nemcsak az ügyfelek, de a tanácsadók is elveszettek lehetnek, hogy melyik M365 csomagban milyen szolgáltatás szerepel, milyen limitációkkal stb.
Az alábbi két táblázat hasznos lehet, hogy eligazodjuk a “rengetegben”
M365 Enterprise csomagok összehasonlító táblázat (PDF)
M365 SMB csomagok összehasonlító táblázat (PDF)
Az Azure portálon, az AD Connect résznél szemünkbe tűnhet egy sárga háromszöges figyelmeztetés:
Pánikra nincs ok, a napi működésre nincs kihatással 🙂
De mit jelent mindez?
Áttekintés
A Seamless SSO-t beállíthatjuk, ha password hash sync vagy pass-through authentikációt határoztunk meg (a két hitelesítési mód összehasonlítása: Password hash sync vagy pass-through authentication – összehasonlítás | Zoltan Istvanffy’s IT Blog (istvanffyzoltan.com) )
A Seamless SSO segíti a felhasználói élményt, hogy domain-joined gépeken automatikusan bejelentkeznek az Azure AD-ba.
Amikor az AD Connect segítségével konfiguráljuk az SSO-t, a földi domainben létrejön egy AZUREADSSOACC computer objektum. Ez felelős érte, hogy megvalósuljon az SSO az Azure AD-val. A működésének rövid leírása:
(forrás: https://nlbit.blog/2020/08/07/seamless-sso-azureadssoacc/ )
Ez az objektumot érdemes egy külön OU-ba tenni és bekapcsolni rajta a “protect object from accidental deletion” opciót is.
A Kerberos-kulcs (decryption key) a lényeges, ezt érdemes legalább 30 napota cserélni. Ha nem tesszük, akkor kerül ki az Azure portálra a figyelmeztető ikon.
Hogyan cseréljük a Kerberos-kulcsot?
A művelethez szükségünk van Global Administrator és Domain Admin jogosultságra. Lépjünk be az AD Connect szerverre és admin powershellben navigáljunk el a “Microsoft Azure Active Directory Connect” mappába:
cd “C:\Program Files\Microsoft Azure Active Directory Connect\”
Importáljuk be az SSO modult:
Import-Module .\AzureADSSO.psd1
A következő paranccsal végrehajtjuk a hitelesítést az Azure AD felé:
New-AzureADSSOAuthenticationContext
Futtassuk le a kulcs-csere parancsot, és hitelesítsük magukat a földi AD felé:
Update-AzureADSSOForest
A hitelesítés után megtörténik a kulcs cseréje:
Rövid idő után frissül az Azure portálon is:
Összefoglalva: evvel az egyszerű művelettel érdemes legalább 30 naponta frissíteni a Kerberos-kulcsot. Az AZUREADSSOACC objektumra kevés figyelem jut, de érdemes jól “eltenni” egy külön OU-ba és bekapcsolni rajta a véletlen törlés elleni védelmet.
Az Azure AD egyik, még Preview fázisban lévő megoldása, a Continous Access Evaluation jó eszköz lehet, hogy még robosztusabb legyen a hozzáférési szabályzatunk.
Amikor egy felhasználó bejelentkezik egy online szolgáltatásba (pl. Exchange Online), akkor az Azure AD egy hozzáférési tokent állít ki számára, egy óra érvényességgel. A token érvényésségének lejártáig él a hozzáférés.
(az időtartam egyébként szabályozható, pl. conditional access session control segtíségével)
Nézzünk egy alappéldát:
Mi történik, ha letiltunk egy felhasználót?
Sajnos, a token érvényessége ettől még megmarad és továbbra is eléri az online szolgáltatást. Ez sok szervezet számára elfogadhatatlan, és szükség van granulárisabb megoldásra.
Itt jön képbe a Conditional Access Evaluation (CAE). Ennek lényege, hogy bizonyos események hatására az addigi token érvényessége azonnal megszűnik és szükséges lesz egy újra-authentikáció végrehajtása.
Milyen eseményeknél történik meg?
Valamelyik esemény bekövetkeztekor gyakorlatilag egy percen belül megszűnik a hozzáférés a Sharepoint Online, Exchange Online és Teams szolgáltatásokhoz (jelen preview állapotban ezt a két szolgáltatást támogatja). Saját tesztelés alapján 20-30 mp elteltével jöttek az authentikációs popup-ok, laptopon-telefonon-tableten egyaránt.
Milyen alkalmazások támogatják a CAE-t?
Alapesetben a kliensek megpróbálják felhasználni a már meglévő tokent a hozzáféréshez. CAE-vel a kliens az ún. claim challenge segítségével tudja, hogy nem a tárolt tokent kell használnia, hanem újat kell kérnie az Azure AD-tól (authentikáció bekérése)
Az alábbi alkalmazások CAE-kompatibilisek:
Hogyan működik a gyakorlatban?
Az alábbi példában úgy állítottuk be a Conditional Access policyt, hogy az online szolgáltatást csak meghatározott IP-tartományokól elérhető (pl. irodai hálózat)
Hogyan engedélyezzük a CAE-t?
Navigáljunk a https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/ContinuousAccessEvaluation linkre és válasszuk az Enable preview funkciót
Kijelölhetünk csoportokat, tesztelési célből, vagy alkalmazhatjuk minden felhasználóra:
Limitációk az IP-tartományokkal kapcsolatban:
A CAE nem értelmezi az MFA Trusted IP vagy a country location beállításokat. Csak az Azure AD-ba felvitt Named Location IP-ket használja.
https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/NamedNetworks
Ide kell felvinni azokat az IPv4 és IPv6 tartományokat, amikre szeretnénk ebben az esetben a CAE-t hasznáni.
Összefoglaló:
A CAE egy nagyszerű irányba mutató fejlesztés, és bízhatunk benne, hogy a preview után még több funckióval bővül. Addig is, érdemes kipróbálni és használatba venni.
Előző cikkemben (https://istvanffyzoltan.com/2020/12/15/office-365-federacio-megszuntetese/) bemutattam, hogyan lehet ADFS-ről átállni password hash sync authentikációra (PHS) az O365 esetén.
Szintén említettem értintőlegesen, hogy létezik a pass-through authentikációs megoldás is (PTA)
Felmerülhet a kérdés, hogy melyiket érdemes választani, mik az előnyeik és hátrányaik? Ezeket igyekeztem összeszedni a cikkben (feltételezve, hogy van földi környezet és az AD Connecten keresztül megtörtént a címtár szinkronizáció)
A PHS esetén a földi AD-jelszavak módosított hash-jét szinkronizáljuk fel az Azure AD-ba, és a hitelesítés ott történik meg, a tárolt hash-ek alapján.
A folyamat az alábbi ábrán látható:
Hogyan jutnak fel a jelszó hash-ek az Azure AD-be?
Látható, hogy a folyamat egészen biztonságos. Az esetleges aggodalmak eloszlatása érdekében leszögezendő:
Milyen előnyei vannak a PHS-nek?
Milyen hátrányai vannak a PHS-nek?
PTA hitelesítés esetén a validálás a földi domain controllereken történik meg. Kis túlzással hívhatjuk lightweight-ADFS megoldásnak is.
A működése a következő:
PTA agentből bármennyit telepíthetünk a földi környezetünkbe, evvel is biztosítva a redundanciát. Az agent esetleges hibája esetén az authentikáció továbblép a következőre. A működéshez nem szükséges külső elérés (azaz tűzfalon portnyitás befelé, NAT, stb), az agent az outbound 443-as porton kommunikál az Azure AD-vel.
Az alábbi környezetben 7 PTA agent került telepítése, fizikai és virtuális szerverekre egyaránt, biztosítva a magas rendelkezésreállást.
Könnyen belátható, hogy ez jóval rugalmasabb a nagytestvér ADFS-nél.
Milyen előnyei vannak a PTA-nak?
Milyen hátrányai vannak a PTA-nak?
Igen! Az AD Connect kliensben bármikor megváltoztathatjuk, hogy PTA vagy PHS hitelesítést szeretnénk használni. Ez jól jöhet olyan katasztrófa esetén, ha pl. az összes PTA agentünk elérhetetlen: át tudunk váltani PHS hitelesítésre.
Az AD Connectben állítsuk át a kívánt hitelesítési módot:
Összefoglalás
Ahogy látjuk, mindkét megoldás vannak előnyei és hátrányai; szervezettől függ, hogy milyen szabályozás alapján választ. Ha cél a földi infrastruktúra és komplexitás csökkentése, válasszuk a PHS authentikációt. Ha szorosabb a szabályozás és több kontrollt szeretnénk, a PTA hitelesítés lehet a megfelelő. A kettő között váltás bármikor megejthető, így marad mozgástér a kísérletezéshez is.
Ahol ADFS-t használnak az O365 federációra, ott érdemes elgondolkodni az alternatívákon,ugyanis az O365 felé történő authentikációs workloadot le tudjuk venni az ADFS farmunkról. Abban az esetben, ha csak emiatt tartottuk az ADFS-t, akkor le is lehet állítani, és spórolni a céges erőforrásokon (farm fenntartás, üzemeltetés, patchelés, rendelkezésre állás, hálózat, biztonsági megoldások stb. biztosítása).
A federáción kívül két lehetőségünk van az O365 felé történő hitelesítésre:
A password hash sync esetén nincs szükségünk semmilyen földi infrastruktúrára, viszont a földi domainben beállított jelszópolicy/user lock/ user disabled események nem jutnak rögtön érvényre.
A pass-through authentikáció esetén az O365 portal kéri be a hitelesítő adatokat és validáltatja a földi környezetbe telepített PTA-agentek segítségével.
A mostani cikkben az egyszerűbb, password hash sync-re (továbiakkban PHS) való áttérést taglalom.
Magyarázat:
federated domain: ahol ADFS-t használunk a hitelesítésre
managed domain: ahol PHS vagy PTA segítségével authentikálunk.
A cél, hogy a federated domaint managed domainre kapcsoljuk.
Attől függően, hogy kezdetben hogy állítottuk be az ADFS-t, kétféle lehetőségünk van:
Nézzük az első opciót, tehát ha az ADFS konfigurációt az AD Connectben tettük meg:
Első lépésként engedélyezzük az AD Connectben a password hash syncet. Ha lennének félelmeink a PHS-val kapcsolatban, itt egy részletes magyarázó cikk a működéséről: https://istvanffyzoltan.com/2020/07/12/miert-ne-feljunk-a-password-hash-szinkronizalastol/
TLDR: nem szinkronizálja a közvetlen jelszavunkat 🙂
Tehát, kapcsoljuk be a PHS syncet, ha még nem tettük volna meg:
Várjuk meg, amíg a sync végigmegy (30-60 percet)
Logokat lehet ellenőrizni:
Ahhoz hogy a domain-joined gépeken is menjen az SSO, a következő URL-eket adjuk hozzá az Intranet zónához GPO-val: (a GPO-ban az érték legyen 1)
Következő lépésben állítsuk be a PHS-t és engedélyezzük az SSO-t:
Az Azure portalon látni fogjuk, hogy eltűnt a Federation
Második opció, ha az ADFS-t nem az AD Connecten belül állítotuk be:
Itt is fontos, hogy előtte legyen beállítva a password hash sync, különben a federáció leváltásakor minden felhasználó különálló, új jelszót kap, ami komoly gondokat okozhat!
Ha működik a PHS, akkor lépjünk be az ADFS szerverünkre és futtassuk le az alábbi parancsokat admin powershellből:
install-module msonline
import-module msonline
connect-msolservice (adjuk meg a global admin account adatait)
végül kérdezzük le a federated / managed domainek listáját:
get-msoldomain
Futtasuk le a következő parancsot, megadva az ADFS szerverünk belső FQDN-jét:
Set-MsolADFSContext -Computer <ADFS FQDN>
Végül konvertáljuk át a federált domaineket managed-be:
Convert-MsolDomainToStandard -DomainName yourdomain.com -SkipUserConversion:$true -PasswordFile C:\userpasswords.txt
A SkipUserConversion értékre nagyon figyeljünk, feltétlenül legyen True az értéke, különben új jelszavakat generál az usereknek! A PasswordFile ettől függetlenül kötelező elem, adjunk meg egy érvényes útvonalat a txt filenak.
Egy újabb get-msoldomain paranccsal látjuk, hogy nincs federated domain immár:
Végül pedig állítsuk be a PHS-t:
Set-MsolDomainAuthentication -Authentication Managed -DomainName yourdomain.com
Ezt ellenőrizhetjük később az AD Connect felületén is. A teljes átváltáshoz várjunk 2-3 órát, addig előfordulhatnak login anomáliák, így ezt a műveletet érdemes munkaidőn kívül elvégezni.
Tesztelés:
Navigáljunk el a https://portal.office.com oldalra. A felhasználónév megadása után, a régi, federated scenárió esetén kaptunk egy redirectet az ADFS oldalra:
A federáció megszűntetése után viszont már az O365 portal kéri be a jelszavunkat:
Összefoglalás: ha csak az O365 miatt van ADFS szerverünk, akkor érdemes migrálni a PHS / PTA megoldások egyikére, jelentős erőforrásfogyasztás és hibalehetőséget tudunk elkerülni.
Az adathalászat az egyik legnépszerűbb kísérlet, amivel megpróbálnak céges accountokhoz (felhasználónév és jelszó páros) hozzájutni. Ennek egy tipikus formája, mikor O365 login portalt hamisítanak, és várják hogy valaki gyanútlanul beírja a név/jelszó párost.
Ebben tud segíteni az Azure AD és a Company Branding funkció. Segítségével az O365 login portal testreszabható, céges logóval, egyéb vizuális beállításokkal. A felhasználókat pedig oktatni kell, hogy csak a céges logóval ellátott portalon jelentkezzenek be.
(Megjegyzés: ha ADFS-t használunk hitelesítésre, akkor természetesen nem ezt a portált fogjuk látni, hanem a kiszolgálóét, amit szintén érdemes “brandelni”)
Nézzük, hogy néz ki, ha alapesetben az O365 portal:
Ez egy elég általános felület, könnyű hamisítani. Cseréljük le hát az alapportált egy céges design-ra:
Navigáljunk el az Azure AD portalon a Company Branding részhez:
https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/LoginTenantBranding
A Defaultnál pedig töltsünk fel logót, háttérképet:
Ezt követően a felhasználóink ezt a portalt látják:
Látszik a céglogó és a háttér, jelezve, hogy ez a valódi O365 portal.
Természetesen ez is hamisítható, de ahhoz már elég célzottan kell a támadóknak előkészülni. A Company Branding beállítástól függetlenül, a felhasználókat időszakos securiy awareness tréningek keretében emlékeztetni kell, hogy ne kattintsanak gyanús linkekre, inkább mindig kézzel írják a böngészőbe a https://portal.office.com címet és úgy végezzék el a bejelentkezést.
Az RD Gateway elég régóta létező komponens, segítségével megoldható a belső hálózaton található gépek RDP elérése, biztonságosan (TCP 443-as porton keresztül)
A pandémiás helyzet miatt sok cégnek kapóra jöhet ez a megoldás. Jön az igény: a céges PC-met el kellene érnem az otthoni gépemről, mintha azon dolgoznék. Lehetőleg biztosítva az identitásellenőrzést is, azaz a név/jelszó pároson kívül legyen többfaktoros hitelesítés is.
Lássuk, hogyan lehet ezt egy meglévő RD Gateway és Azure MFA-val megoldani! (Az RD Gateway telepítés-konfigurálás lépéseket a cikk nem tartalmazza)
Előfeltételek:
https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview linken kiolvashatjuk a tenant id-t. Ezt mentsük el a későbbi használat miatt.
Az NPS szerverre telepíteni kell az Azure MFA extensiont. Vigyázat! A telepítés után minden authentikációs kérést az Azure felé fog küldeni, ezért feltétlenül fontos, hogy külön NPS szervert használjunk. Ellenkező esetben a wifihez/vpn-hez használt NPS-t működésképtelenné teheti.
Töltsük le az extensiont és teleptsük fel:
https://www.microsoft.com/en-us/download/details.aspx?id=54688
Telepítés után konfiguráció következik. Admin powershellből navigáljunk a “c:\Program Files\Microsoft\AzureMfa\Config” folderbe és indítsuk el az .\AzureMfaNpsExtnConfigSetup.ps1 scriptet.
Majd a felugró ablakban jelentkezzünk be Global Adminként
A script bekéri majd a Tenant ID-t, ezt másoljuk be és nyomjunk Entert:
Remote Desktop connection authorization policies (RD CAPs) szükségesek az RD Gateway-hez kapcsolódáshoz. Alapértelmezetten ezek a policy lokálisan vannak tárolva, de ez esetben át kell állítani központi RD CAP Store-ra.
Nyissuk meg az RD Gateway szerveren a Remote Desktop Gateway Managert. Jobb klikk a szerver nevén, Properties, RD CAP Store és a Central Server running NPS résznél vegyük fel a kívánt NPS nevét vagy IP-jét
Adjunk meg egy erős, hosszú shared secretet és mentsük el a későbbi használathoz.
A RADIUS timeout értékét át kell állítani az alapértelmezettről, hogy a felhasználónak legyen ideje a kétfaktoros hitelesítést végrehajtani.
Ehhez az RD Gateway szerveren indítsuk el a Network Policy Server konzolt, majd menjünk a Radius Clients/Remote Radius Server részre. Nyissuk meg a TS Gateway Server Groupot. Itt megjelenik az általunk beállított radius szerver, kattintsunk az Edit…-re. A Load Balancing tabon látunk két értéket:
Number of seconds without response before request is considered dropped
Number of seconds between requests when server is identified as unavailable
Ezek értékét állítsuk át 60-ra
Az RD Gateway-en nyissuk meg a Network Policy Server konzolt, keressük meg a Policies / Connection Request Policies részt. Kattintsunk duplán a TS GATEWAY AUTHORIZATION POLICY-re, majd Settings és végül Authentication. Győződjünk meg róla, hogy a kérések biztosan a távoli NPS szerverre mennek:
Az NPS szerveren, ahol telepítettük az MFA Extsensiont, nyissuk meg az NPS konzolt, és adjunk hozzá RADIUS klienst:
A new radius client ablakban adjuk meg az RD Gateway nevét és IP/DNS nevét, illetve írjuk be a korábban elmentett Shared Secretet:
Az NPS szerveren indítsuk el az NPS konzolt, nyissuk ki a Policies ágat és válasszuk a Network Policies részt. Kattintsunk jobb klikkel a “Connections to other access servers” policyre és válasszuk a “Duplicate policy” opciót:
Nevezzük át a policyt, kapcsoljuk be a “Policy enabled” részt és válasszuk a “Grant access opciót:
Kattintsunk át a “Constraints” fülre és pipáljuk be az “Allow clients to connect without negotiating an authentication” method opciót:
Mentsük el a policyt, majd győződjünk meg róla, hogy engedélyezve van és a lista elején áll:
Miután végeztünk minden konfigurációs beállítással, teszteljünk. Indítsuk el az RDP klienst és csatlakozzunk egy belső géphez a szokásos beállításokkal:
Ha mindent jól csináltunk, a telefonon meg kell jelennie az Authenticatior üzenetnek, ahol a belépést jóváhagyhatjuk:
Probléma esetén segítségül hívhatjuk az eventlogot. Az RD Gateway szerveren nyissuk meg az Event Viewert és navigáljunk el Network Policy and Access Services custom nézethez:
Összefoglalás: az RD Gateway kényelmes és hasznos megoldás, amit az Azure MFA Extensionnal biztonságosabbá is tehetünk.
A hibrid szervezeteknél az AAD Connect egy nagyon fontos eszköz, ennek segítségével tudják naprakészen tartani az Azure AD-t is. Kiemelt jelentőségű tehát, hogy mindig a támogatott és friss verziót használjuk.
(Jó tudni, hogy a 18 hónapnál régebben kiadott AAD Connect verziók nem támogatottak (a cikk írásakor az 1.3.20.0-as verzió és régebbeiek))
Az AAD Connect elég régóta tartalmazza az Auto-Upgrade lehetőséget. A kliens meghatározott időközönként lekérdezi a Microsoft szervereit és frissíti magát.
A frissítések állapotát ellenőrzini lehet az eventlogban, Applications and Services Logs\Microsoft\AzureADConnect\AgentUpdater\Admin résznél
Viszont fontos észben tartani, hogy a fenti Auto-Upgrade nem minden esetben működik! Előfordulhat egyedi konfiguráció, illetve nem minden egyes új kiadás jelenti, hogy az AADConnect frissíti magát.
Ellenőrizzük, az Auto-Upgrade állapotát, az AAD Connect felületén:
illetve powershellből is lekérdezhető:
Get-ADSyncAutoUpgrade
Háromféle állapot lehetséges:
Az utolsó, Suspended funkciót maga az AAD Connect kliens állítja be, ennek parancssoros átállítása (Enabled) nem támogatott.
Amennyiben a Suspended állapotot látjuk, akkor érdemes párhavonta ellenőrizni hogy van-e frissebb kliens és kézzel telepíteni (in-place upgrade). Az AAD Connect verziólista itt elérhető: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history
Ha lenne mód az Auto-Upgrade használatára, de mégsem szeretnénk, hogy frissítse magát a kliens (szeretnénk előtte tesztelni stb), akkor a használjuk a következő parancsot:
Set-ADSyncAutoUpgrade -AutoUpgradeState Disabled
Ha pedig mégis visszaállnánk az automatikus frissítésre, akkor így tehetjük meg:
Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled
Nagy-Löki Balázs kollégám posztját ajánlom mindenki figyelmébe:
Az eredeti poszt linkje: https://nlbit.blog/2020/08/07/seamless-sso-azureadssoacc/
Egyszer volt, hol nem volt, telepítésre került az Azure AD connect és a sok kijelölhető opció közül bepipálásra került az “Enable single sign-on” lehetőség, mert ezzel tuti jó lesz a felhasználói élmény 🙂
Aztán böngésszük az on-premise AD-t (Private cloud AD – csak, hogy maradjunk a hivatalos megnevezéseknél) és találunk egy computer accountot, ami valahogy, valamikor létrejött, aminek a neve “AZUREADSSOACC”. Bizonyám ez összefügg azzal az opcióval amit kipipáltunk. De ez miért jött létre? Mire kell? Hogyan működik? Na ezt nézzük meg.
Az nem kérdés, hogy szeretnénk növelni a felhasználói élményt úgy, hogy a biztonság ne sérüljön, tehát a felhasználó által a private cloud-ban megszokott szolgáltatások elérése, ugyanúgy működjön a felhőben is, tehát ne kelljen újból és újból megadni a felhasználói-jelszó párost. Igen, a kerberosról beszélek.
Bizony, ezért jött létre ez a computer account, ami nem más mint az Azure AD “megszemélyesítése”. De hogyan működik? Vizsgáljuk meg.
Remélem hasznos volt! 🙂
Üdv.:
NLB
A céges hálózattól tartósan távollévő gépek menedzselésének kérdése nem újkeletű, több szervezetnek is okozott már fejfájást. Illetve új problémaként felmerült a COVID miatt, hogy sok felhasználó hirtelen távolról kényszerült dolgozni az eszközével.
Mit értünk tartósan távollévő gép alatt?
Olyan laptopokat, amik a felhasználási sajátosságok miatt alig lépnek be a céges hálózatba, legyen az irodai hálózat vagy VPN. Néhány opció:
Kiemelten jó példa a gyógyszeripari cégeknék az orvoslátogatók gépei. Kapnak céges eszközt, használják a levelezést, a munkájukat tudják végezni, az irodába nagyjából sosem mennek be, hálózatra nem csatlakoznak fel.
Mi történik menedzsment szempontból egy ilyen géppel?
Amint látjuk, ez a helyzet kellemetlen az IT-számára, hiszen ezen gépek felett gyakorlatilag elveszítette a kontrollt. A menedzselhetőség innetől a felhasználótól függ (mikor megy be az eszközzel céges hálózatra, mikor kapcsolja be a VPN-t stb…és milyen rossz az, mikor a céges bérelt vonalon kezd töltődni az akár több GB-os SCCM-csomag 🙂 ) A kockázat pedig adott: nem kerülnek fel a biztonsági frissítések, az IT nem értesül a gépet érintő incidensekről és lehetne sorolni.
Mi lehet a megoldás?
Toljuk ki a menedzsment határait a céges hálózaton kívülre! Gondoljuk át, hogy milyen nagyszerű lenne, ha az IT-felügyelet az Interneten kereszül történhetne! Az orvoslátogatók gépeinek üzemeltetői repesnének az örömtől.
Csináljunk Hybrid Azure AD joint, vagy akár Azure AD joint, Microsoft Endpoint Management (MEM) felügyeleti eszközzel párban. Evvel a következő lehetőséghez juthatunk (maradva az orvoslátogatók gépeinél)
Láthatjuk, hogy evvel a megoldással visszakapjuk az elveszett kontrollt a távollévő gépek felett.
Összegzés: érdemes átgondolni a kliensmenedzsment kérdését és válaszolni az új igényekre (céges hálózat nélkül is a kontroll megléte), erre az AzureAD és MEM egy jó alternatíva lehet.
Zoltan Istvanffy's IT Blog 