Latest / M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano / Microsoft Entra Domain Services spiegato: app legacy in Azure senza domain controller propri (Doppiaggio IA)

Transcript

Microsoft Entra Domain Services spiegato: app legacy in Azure senza domain controller propri (Doppiaggio IA) · M365.FM – Podcast su Microsoft 365, Copilot e IA in italiano

0:00
Pronti per dieci giorni di Microsoft 365 e Copilot IA, azzurre le persone che stanno plasmando il futuro del lavoro?
0:07
A gennaio torna la M3665 Conference e faremo le cose ancora più in grande.
0:12
Unitevi a noi per sessioni dal vivo, demo reali e conoscenze pratiche da MVP ed esperti del settore e da tutto il mondo.
0:18
Niente slide generiche, niente gergo infinito.
0:21
Affrontiamo le sfide reali, Copilot Studio, agenti IA, Fabric, Sicurezza, Governance e Automazione e Automazione.
0:29
Che siate professionisti IT, sviluppatori o leader aziendali, ci sono sessioni pensate per voi.
0:35
Con dieci giorni interi potrete esplorare diverse tecnologie e connettervi con una community globale.
0:40
Seguite dal vivo e portate intuizioni pratiche nella vostra organizzazione.
0:45
Gennaio 2027, dieci giorni, un'unica community Microsoft.
0:48
Le iscrizioni sono aperte.
0:51
Andate su m365con.net e assicuratevi il vostro posto oggi stesso.
0:55
È m365con.net
0:58
Iscrivetevi ora su m365con.net e ci vediamo a gennaio.
1:05
Ciao a tutti e benvenuti a un altro episodio di Microsoft Knowledge Nuggets qui su m365fm.
1:10
Sono Mirko Peters.
1:11
Immaginate di spostare una vecchia app aziendale da un server in ufficio a una macchina virtuale a zoo.
1:15
L'app è ora nel cloud ma richiede ancora dominio Windows.
1:19
Vuole unirsi a dominio, cercare persone tramite il DAP, autenticare gli utenti con Kerberos e applicare i criteri di gruppo.
1:24
Molti pensano che EntraID sostituisca ogni funzione di Active Directory.
1:28
Non è così.
1:29
Le moderne app cloud possono autenticarvi tramite EntraID, ma le vecchie app Windows si aspettano lo stesso tipo di dominio usato nella sala server.
1:36
Alla fine di questo episodio capirete dove si collocano EntraID, Active Directory ed Entro Domain Services
1:41
e c'è un dettaglio che cambia la gestione del tutto.
1:43
Le informazioni di identità viaggiano in una sola direzione.
1:47
Perché EntraID da solo non può gestire ogni app legacy.
1:50
Partiamo da ciò che EntraID sa fare bene.
1:52
È la reception dei vostri servizi cloud?
1:55
Sa chi siete?
1:55
Verifica l'accesso e decide se potete entrare in Microsoft 365, Teams, SharePoint o in un'app aziendale nel cloud.
2:02
Accedete una volta sola, poi vi spostate tra i servizi senza dover digitare continuamente la password.
2:06
È il single sign-on.
2:08
EntraID può anche richiedere una seconda verifica tramite autenticazione a più fattori,
2:12
esaminando il dispositivo usato, la provenienza dell'accesso e le regole aziendali.
2:17
Per un'app moderna questo schema funziona molto bene.
2:19
Aprite il browser, l'app vi invia EntraID, accedete, approvate magari una richiesta sul telefono
2:24
e poi EntraID invia all'app un messaggio di accesso sicuro.
2:28
L'app legge il messaggio e vi fa entrare.
2:30
Con questo modello non è necessario conjoin al dominio, non vengono coinvolti i vecchi Windows Server
2:34
e l'app non deve consultare una directory aziendale classica.
2:37
Ma le app più vecchie sono nate in un mondo diverso.
2:39
Immagina un'app finanziaria che gira su Windows Server da anni,
2:42
dove gli utenti accedono da PC aggiunti al dominio.
2:44
L'app cerca i dettagli dei dipendenti tramite il DAP,
2:47
un metodo comune usato dai software più datati per interrogare una directory aziendale.
2:51
Potrebbe usare Kerberos, un vecchio metodo di accesso Windows che permette ai sistemi di fidarsi l'Undel.
2:55
Potrebbe basarsi sulle criteri di gruppo,
2:57
l'insieme di regole aziendali che possano controllare le impostazioni su computer Windows.
3:00
Quell'app non sa come leggere un moderno messaggio di accesso al cloud.
3:03
Si aspetta di chiamare attraverso la rete e trovare un tradizionale dominio Windows.
3:06
E se non riesce a trovarne uno, l'app potrebbe non riuscire ad accedere agli utenti,
3:10
non trovare un account di servizio senza rifiutarsi di avere.
3:12
Probabilmente hai visto questo schema anche al di fuori dell'IT.
3:15
Una nuova presa elettrica non serve a nulla se la spina di un vecchio macchinario non si adatta.
3:18
L'elettricità c'è, ma la connessione è quella sbagliata?
3:20
Ora, immagina l'azienda che sposta quell'app finanziaria e il suo database in macchine virtuali Azure.
3:25
I server si sono spostati, ma le vecchie esigenze non.
3:27
Potresti lasciare Active Directory in ufficio e collegare Azure adesso tramite una VPN,
3:31
un tunnel di rete privato.
3:32
Così, l'app in Azure invia richieste attraverso quella connessione ogni volta che ha bisogno del dominio.
3:37
Può funzionare, ma l'app dipende ora dal collegamento di rete e dalla disponibilità del domain controller locale.
3:42
E se quella connessione ha un problema, anche l'app cloud potrebbe averne uno.
3:46
Un'altra scelta è creare le tue macchine virtuali di domain controller in Azure.
3:50
Un controller è il server che esegue il tradizionale dominio Active Directory,
3:53
gestendo directory, accessi e altri compiti di dominio.
3:55
Anche questa funzione a mora è il tuo team più server da gestire.
3:58
Qualcuno deve aggiornarli e monitorarli.
4:00
Servono backup, piani di ripristi in un piano per mantenere sincronizzati i domain controller
4:04
e devi anche proteggere i potenti account admin che controllano il dominio.
4:07
Per alcune aziende quel controllo ha senso.
4:09
Per altre è solo lavoro extra per mantenere operativa un'app più vecchia.
4:13
Quindi il divario è piuttosto stretto ma è reale.
4:15
Un'app vive in Azure, eppure parla ancora il vecchio linguaggio di Active Directory.
4:19
Cos'è in realtà Microsoft Enter Domain Services?
4:21
Microsoft Enter Domain Services è un dominio Windows gestito che viene eseguito all'interno della tua rete Azure.
4:26
Questa è la definizione in parole semplici.
4:28
I controller di dominio funzionano dietro le quinte gestiti interamente da Microsoft,
4:31
mentre le tue macchine virtuali Azure e le app meno recenti utilizzano i familiari servizi di dominio che si aspettano.
4:36
Immagina la tua configurazione cloud come un edificio per uffe.
4:38
Entra i D e la reception all'ingresso.
4:40
Verifica chi sei quando accede a Microsoft 365 o a un'altra app cloud e applica le regole aziendali relative a tale accesso.
4:46
Entra la Domain Services e si trova in un ufficioso chiave.
4:48
I sistemi più datati non hanno bisogno di visitare quella reception come farebbe una moderna app cloud.
4:53
Hanno bisogno di una directory di vecchio stampo nelle vicinanze che capisca il loro linguaggio e possa rispondere alle loro chiusi.
4:58
Quell'ufficio sul retro e dominio gestito.
5:00
Ecco il punto.
5:00
Non devi creare tu stesso i controller di domino.
5:02
Non accedi a essi con il desktop remoto.
5:04
Non devi decidere quanti eseguirne, applicare patch a Windows su di essi o gestire la connessione tra loro.
5:08
Microsoft si occupa di tutto questo.
5:10
Il tuo compito è connettere le macchine virtuali a Azure e le app corrette al dominio gestito.
5:14
Una volta connessi, possono utilizzare i familiari servizi di Active Directory.
5:17
Una VM Windows può unirsi al dominio.
5:19
Un'app meno recente può usare il Dapp per cercare persone, gruppi e dettagli della directory.
5:23
Può usare Kerberos, il metodo di accesso che le app aziendali datate spesso richiedono quando un server deve fidarsi di un altro.
5:29
Può anche usare Ntlm, un altro metodo di accesso a Windows più vecchio che alcune app richiedono ancora.
5:33
Il dominio gestito fornisce anche il DNS, che aiuta i sistemi a trovare il server giusto per nome anziché tramite una sequenza di numeri.
5:39
E supporta i criteri di gruppo, così puoi applicare determinate impostazioni Windows a computer e utenti in quel dominio gestito.
5:45
Quell'elenco sembra tecnico, lo so.
5:46
Immaginano invece come un banco di traduzione.
5:48
La tua app chiede nel vecchio linguaggio Windows chi è quest'utente.
5:52
Questo server può fidarsi di quell'altro server.
5:54
Dov'è il database?
5:55
Quali impostazioni dovrebbe usare questo computer?
5:57
Entra a Domain Services, comprende quelle domande e fornisce il tipo di risposta che l'app si aspetta.
6:01
Ma non crea un secondo elenco principale di dipendenti.
6:04
Il record di identità principale rimane in 3D.
6:06
Utenti e gruppi di EntraID vengono copiati nel dominio gestito, così l'app datata può vederli e usarli nel formato che comprende.
6:13
Se la tua azienda dispone anche di un Active Directory locale, le identità potrebbero già raggiungere EntraID da lì prima di essere copiata in Domain Services.
6:19
Qui la direzione è importante.
6:20
I dettagli dell'identità fluiscono in Entra Domain Services.
6:23
Non fluiscono verso l'esterno.
6:24
Quindi, se un utente proviene da EntraID, gestisci tale utente in EntraID.
6:27
Se l'utente proviene originariamente dal tuo Active Directory locale, gestisci l'utente da lì.
6:33
Non si usa Domain Services per modificare il record principale dei dipendenti.
6:37
Ciò impedisce che il dominio gestito diventi un secondo archivio con versioni diverse della stessa persona.
6:41
Ora c'è un aspetto che mette in difficoltà molte persone durante la configurazione.
6:44
L'accesso al cloud moderno e quello Windows più datato non usano le password esattamente allo stesso modo.
6:49
Per far funzionare Kerberos e NTLM, Domain Services richiede una forma protetta di password che supporti quei metodi obsoleti.
6:55
Microsoft non conserva mai la tua password in questo semplice.
6:58
Il servizio ha bisogno delle corrette informazioni protette prima che un utente possa accedere a una VM o una Plagacy tramite il dominio gestito.
7:06
Per gli utenti solo cloud, spesso significa che devono cambiare la password dopo aver attivato Domain Services.
7:12
Quel cambio password crea la forma protetta necessaria per il dominio gestito.
7:15
Fino ad allora, l'utente potrebbe accedere a Microsoft 305 senza problemi, ma fallire nel tentativo di usare il dominio vecchio stile.
7:22
All'inizio può sembrare strano.
7:24
L'utente ha già un account, la password funziona, eppure l'app Legacy non riesce a usarla.
7:29
Il pezzo mancante non è account utente.
7:31
È la forma protetta della password richiesta da quei metodi di accesso più datati.
7:34
Domain Services ha anche un confine chiaro entro cui opera.
7:37
Viene eseguito all'interno di una rete virtuale azzur, spesso chiamata VNet.
7:40
Le tue VM azzur necessitano di accesso a quella VNet e devono usare le impostazioni DNS del dominio gestito per trovarlo.
7:47
Non è una directory pubblica che ogni dispositivo su internet può contattare.
7:50
È un servizio di dominio privato per carichi di lavoro connessi alla rete azzur corretta.
7:54
Quindi, quando un'app richiede il comportamento del vecchio Active Directory in Azure,
7:58
Domain Services offre un luogo gestito per trovarlo.
8:00
Qui ci porta alla prossima domanda.
8:02
Come si colloca rispetto a EntraID e al tuo dominio Active Directory esistente?
8:06
I nomi suonano simili, ma i loro compiti sono molto diversi.
8:08
EntraID, Active Directory, Domain Services, compiti diversi.
8:13
I nomi sono simili, quindi è facile considerare le versioni diverse dello stesso prodotto.
8:17
Non lo sono.
8:18
Ognuno gestisce una parte diversa del quadro delle identità aziendali
8:21
e una volta capito il loro ruolo, la scelta diventa molto più chiara.
8:24
EntraID gestisce l'identità nel cloud.
8:26
Quando apri Microsoft 365, Teams, SharePoint o un'app aziendale moderna,
8:30
EntraID verifica il tuo accesso e controlla cosa puoi consultare.
8:32
Supporta anche l'autenticazione a più fattori e le regole di accesso.
8:36
Come richiedere una verifica più forte se lavori da un dispositivo sconosciuto?
8:40
È progettato per i servizi cloud.
8:42
Un'app moderna non deve trovarsi sulla stessa rete di EntraID
8:44
perché utilizza metodi di accesso basati sul web.
8:47
Ti connetti tramite un browser o un'app, EntraID conferma la tua identità
8:50
e l'app riceve la prova che è l'autorizzazione per accedere.
8:53
Questo è il modello standard per le nuove app cloud.
8:55
Active Directory Domain Services, spesso abbreviato in Active Directory,
8:58
e svolge un compito diverso.
9:00
Si tratta del tradizionale dominio Windows
9:01
che molte aziende gestiscono nei propri uffici, data center o sale server.
9:05
L'azienda possiede i controller di dominio,
9:07
sceglie come configurarli e gestisce l'intero dominio dall'inizio alla fine.
9:10
Può controllare PC Windows, supportare server locali
9:13
e fornire metodi di accesso più dotati richiesti
9:14
dalle applicazioni aziendali di lunga data.
9:16
Quel livello di controllo comporta delle responsabilità.
9:19
Il tuo team IT gestisce il dominio, si occupa dei server
9:21
e decide come la directory debba funzionare per l'azienda.
9:25
Entra a Domain Services e si colloca tra questi due mondi.
9:27
Offre ai carichi di lavoro Azure un dominio Windows gestito
9:29
quando necessitano del comportamento di Active Directory,
9:32
ma Microsoft si occupa del lato controller di domini.
9:34
Utilizzi il dominio per macchine virtuali Azure e app meno recenti
9:37
senza doverti occupare personalmente della gestione
9:39
di un dominio Active Directory tradizionale.
9:41
Immaginelo come un sistema di archivizzazione.
9:42
Entra ID contiene il registro principale dei dipendenti
9:44
per il lavoro sul cloud.
9:46
È lì che l'azienda conserva il registro di lavoro
9:47
utilizzato per Microsoft 365 e per gli accessi cloud model.
9:50
Domain Services fornisce alle app Azure più datate
9:52
e una copia compatibile dei record di cui hanno bisogno.
9:54
Quelle app possono aprire il familiare tipo di archivi
9:57
e trovare utenti, gruppi e dettagli di accesso
9:59
nel formato originale che riconoscono.
10:01
Non è necessario ricostruire l'app solo perché è stata spostata su.
10:04
Anche un'azienda esclusivamente cloud può utilizzare questa configurazione.
10:07
Immagina un'azienda che non ha mai gestito controlli di dominio locale.
10:10
Tutti accedono a Microsoft 365 tramite Entra ID
10:12
e l'azienda inizia a utilizzare macchine virtuali Azure
10:14
per un'app Windows datata.
10:16
Quell'azienda non ha bisogno di creare un dominio Active Directory locale
10:19
solo per quell'app.
10:20
Invece può utilizzare Entra Domain Services per le macchine virtuali Azure
10:24
che richiedono il comportamento di dominio
10:25
mentre il resto dell'azienda continua a usare Entra ID per il lavoro cloud stack.
10:28
Un'azienda ibrida ha un punto di partenza diverso.
10:30
Potrebbe già gestire Active Directory in ufficio
10:32
con utenti e gruppi sincronizzati in Entra ID.
10:35
Quelle persone possono poi apparire in Entra Domain Services
10:37
per i carichi di lavoro eseguiti in Azure.
10:39
Il flusso è questo.
10:40
L'Active Directory esistente dell'azienda
10:43
invia dettagli di identità a Entra ID
10:44
ed Entra ID fornisce la copia compatibile a Domain Services.
10:47
Ciò non significa che Domain Services sostituisca il dominio locale originale.
10:52
L'ufficio potrebbe avere ancora bisogno del proprio dominio Active Directory
10:55
per PC locali, server locali, sistemi di fabbrica o applicazioni che rimangono in sede.
10:59
Domain Services gestisce solo la parte di Azure
11:01
in cui il comportamento di un dominio gestito di tipo tradizionale adatto al carico di lavoro
11:04
e non trasforma nemmeno Entra ID in un Active Directory completo.
11:07
Entra ID rimane un servizio di identità cloud.
11:10
Domain Services aggiunge un dominio gestito per alcune esigenze datate
11:13
ma non offre tutte le opzioni e il livello di controllo che si avrebbero gestendo Active Directory in autonomia.
11:19
Immagina tre compi di destino.
11:21
Entra ID e gestisci i moderni accessi al cloud.
11:23
Active Directory gestisce il dominio Windows che la tua azienda gestisce interna.
11:26
Entra Domain Services gestisce i carichi di lavoro Azure Legacy
11:29
che richiedono ancora un dominio Windows
11:30
senza chiederti di gestire i controller di dominio con tali incarichi.
11:33
Puoi porti una domanda molto più pertinente.
11:36
Quando Domain Services è adatto al carico di lavoro e quando dovresti scegliere qualcos'altro?
11:40
Quando Domain Services è indicato e quando non lo è.
11:42
Parti dall'app, non dal nome del prodotto.
11:45
Se un'app datata usa il Dapp, un vecchio linguaggio per verificare il nome utente e password
11:49
e la stai spostando su Azure, Domain Services può essere viviale.
11:52
L'app continua a usare ciò che già comprende senza costringerti a una riscrittura completa.
11:56
È importante quando l'app funziona ancora, l'azienda ne ha bisogno
11:58
e riscrivere il codice di accesso richiederebbe troppo tempo o denaro.
12:01
Un altro scenario comune.
12:02
Un gruppo di macchine virtuali Azure deve comportarsi come normali computer di dominio.
12:07
Il personale potrebbe aver bisogno di accedere a Windows con il proprio account.
12:09
Un servizio potrebbe richiedere un account di servizio,
12:11
ovvero un account che l'app usa per connettersi ad un altro sistema, come un database.
12:14
Potresti aver bisogno di criteri di gruppo per applicare le impostazioni aziendali a quelle macchine virtuali.
12:18
In questi casi, Domain Services fornisce alle macchine Azure il comportamento di dominio che si aspettano.
12:23
Anche i servizi desktop remoto rientrano in questo.
12:25
Immagina dipendenti che si connettono a desktop o app Windows condivisi in Azure.
12:29
Questi sistemi dipendono spesso da un dominio Windows
12:31
per l'accesso degli utenti e la gestione dei computer.
12:34
Domain Services fornisce quel livello di dominio
12:35
senza che il tuo team debba creare macchine virtuali controller di dominio da zero.
12:39
Le app datate hanno spesso più di una parte.
12:41
Potrebbe esserci un server web all'inizio, un server app nel mezzo a un database alla fine.
12:45
Il server app deve dimostrare la propria identità
12:47
prima che il database accetti una connessione.
12:50
Quando tale attendibilità si basa su account di servizio Windows,
12:52
Domain Services mantiene attive quelle connessioni dopo lo spostamento.
12:55
Il punto è che il tuo team ottiene il comportamento di dominio tradizionale necessario
12:58
per il carico di lavoro, mentre Microsoft gestisce il lavoro del controller di dominio
13:02
che altrimenti graverebbe sui tuoi server.
13:04
Tuttavia non scegliere Domain Services solo perché stai usando Azure.
13:07
Una nuova app cloud dovrebbe autenticarsi direttamente tramite end.
13:10
Se supporta i metodi di accesso moderni,
13:12
invia gli utenti a Entry.id, riceve la conferma dell'accesso
13:14
e beneficia delle regole di accesso al cloud e dell'autenticazione a più fattori.
13:19
Questa è la strada più pulita per il nuovo software.
13:21
Domain Services aiuta le app che comunicano con il linguaggio precedente.
13:24
Non è un motivo per insegnare nuove app col vecchio linguaggio.
13:26
Ci sono anche dei limiti rigidi che devi verificare prima.
13:29
Alcune app non si limitano a leggere da Active Directory ma vi scrivono sopra.
13:32
Ad esempio, un'app potrebbe voler creare e modificare voci di directory
13:35
come parte del suo normale funzionamento.
13:38
Domain Services non è adatto quando l'app richiede l'accesso in scrittura L d'app.
13:42
Lo stesso avvertimento vale se un'app deve modificare lo schema di Active Directory
13:45
insieme di campi che definiscono ciò che la directory può archiviare.
13:48
Alcuni software meno recenti richiedono di aggiungere i propri campi prima di essere segni.
13:51
Un dominio gestito non ti consente di modificare quella struttura di base.
13:55
Dovresti anche fermarti a riflettere se il tuo team necessita del controllo totale su un minuto.
13:58
Forse ti serve l'accesso diretto ai controller di dominio.
14:01
Forse ti servono i diritti di amministratore di dominio che offrono un controllo molto ampio.
14:04
Oppure forse hai bisogno di una struttura di directory complessa che vuoi creare e gestire a modo tuo.
14:08
Questo suggerisce di gestire Active Directory autonomamente,
14:11
in locale o su macchine virtuali, in Azure,
14:14
dove il service ti offre deliberatamente meno controllo
14:16
perché Microsoft gestisce il servizio di dominio principale.
14:18
Quindi pone una semplice domanda prima di scegliere una direzione.
14:22
Questo carico di lavoro necessita il vecchio linguaggio Active Directory
14:24
o può utilizzare il moderno ENTRAID.
14:25
Se puoi usare il moderno ENTRAID, parti da lì.
14:28
Se necessita del comportamento del vecchio dominio,
14:30
ma non richiede che tu possieda ogni parte di esso domain services,
14:32
potrebbe essere perfetto.
14:34
E se l'app deve riscrivere la directory,
14:35
modificarne lo schema o dare al tuo team il controllo totale del dominio,
14:38
ha bisogno di una soluzione diversa.
14:40
Scegliere un dominio gestito significa accettare un compromesso.
14:43
Microsoft si occupa dei controller di dominio
14:45
e tu rinunci a parte del controllo che avresti gestendoli da solo.
14:48
I compromessi del servizio gestito che devi conoscere.
14:50
Questo approccio gestito fa risparmiare lavoro,
14:52
ma cambia anche ciò che il tuo team IT può controllare.
14:54
Microsoft gestisce i controller di dominio,
14:57
li mantiene sincronizzati, applica patch
14:58
e gestisce la disponibilità di trolle quinte.
15:00
Non devi pianificare dove si trovi ogni controller di dominio
15:03
né ripristinarlo dopo un errore del server.
15:05
È per questo che molti team lo scelgono,
15:07
ma non puoi accedere tramite desktop remoto a quei controller di dominio
15:09
e non ottieni i diritti di amministratore di dominio o di impresa,
15:12
poiché darebbero il controllo sulle parti gestite da Microsoft.
15:15
Invece Microsoft fornisce un gruppo chiamato
15:17
Entra Domain Services Administrators.
15:19
Inserisci le persone che devono gestire il dominio in quel gruppo,
15:22
quindi usa una macchina virtuale di gestione unita al dominio gestito.
15:25
Da quella macchina puoi utilizzare i familiari strumenti di Active Directory
15:28
per gestire ciò che Microsoft consente.
15:30
Ad esempio, puoi creare le tue unità organizzative, o OU.
15:33
Considerare come cartelle per gli oggetti di dominio,
15:35
come computer o account di servizio.
15:37
Puoi gestire il record DNS,
15:38
creare e applicare criteri di gruppo per le impostazioni supportate.
15:40
Puoi anche gestire i computer che si uniscono al dominio,
15:43
che è spesso il motivo principale per cui esiste il servizio.
15:45
Questi limiti sono intenzionali.
15:47
Non puoi aggiungere altri controller di dominio,
15:49
modificare lo schema di Active Directory,
15:50
o trattare il dominio gestito come un luogo in cui le modifiche rifluiscono in Entra ID.
15:54
Quindi mantieni la gestione di utenti e gruppi nella directory di origine.
15:57
Per un'azienda esclusivamente cloud, tale origine è Entra ID.
16:00
Per un'azienda ibrida, è l'Active Directory locale che si sincronizza con Entra ID.
16:05
Questa regola previene un errore che vediamo spesso.
16:07
Qualcuno vede un utente nel dominio gestito,
16:08
lo modifica lì presumendo che la modifica sia permanente.
16:11
Tuttavia, tale modifica non diventerà il record aziendale in Entra ID
16:14
o nell'Active Directory locale.
16:15
Mantieni il dominio gestito o privato all'interno della rete a Zoom.
16:19
Dovrebbe supportare solo i carichi di lavoro che ne hanno bisogno,
16:21
non diventare una directory aziendale generale.
16:23
Limita l'accesso alla rete,
16:24
proteggi la macchina di gestione e concedi l'accesso amministrativo solo a chi ne ha bisogno.
16:29
Stai scegliendo un servizio con dei binari di protezione.
16:31
Questi binari eliminano parte del lavoro,
16:32
impedendoti di modificare le parti di proprietà di Microsoft.
16:34
Una semplice storia di migrazione ad Azure.
16:38
Immagina una società finanziaria che esegue una vecchia app su server all'interno del proprio ufficio.
16:42
Quell'app si affidale da app per trovare i dipendenti.
16:44
Utilizza Kerberos quando ha accesso o non ha accesso.
16:46
E il suo server si autentica come un account di servizio per raggiungere il database finanziario.
16:50
L'azienda vuole spostare sia l'app che il suo database in macchine virtuali Azure.
16:53
Un'opzione è mantenere l'app connessa al dominio dell'ufficio tramite VPN,
16:57
ma in tal caso l'app Azure dipende da quella connessione di rete e da controller di dominio locali ogni singolo giorno.
17:02
Un'altra opzione è eseguire nuove macchine virtuali controller di dominio in Azure.
17:06
Ciò mantiene più traffico all'interno di Azure,
17:07
ma aggiunge server Windows che il team IT deve aggiornare, monitorare, eseguire backup e ripristinare.
17:12
E sceglie una strada diversa.
17:13
I loro utenti e gruppi si sincronizzano già in Entry.
17:16
Abilitano Entra Domain Services e connettono la rete virtuale Azure.