Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA em português / Microsoft Entra Domain Services explicado: apps legadas no Azure sem controladores de domínio próprios (Dublagem IA)

Transcript

Microsoft Entra Domain Services explicado: apps legadas no Azure sem controladores de domínio próprios (Dublagem IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA em português

• 0:00
  Preparado para 10 dias de Microsoft 365, Copilot, IA, Azure e as pessoas que estão moldando o futuro do trabalho?
• 0:07
  Em janeiro, a M365 Conference está de volta e ainda maior.
• 0:12
  Junte-se a nós para as sessões ao vivo, demonstrações reais e conhecimento prático com MVPs e especialistas do setor em todo o mundo.
• 0:18
  Nada de slide genérico, nada de jargões sem fim.
• 0:21
  Estamos enfrentando os desafios reais.
• 0:23
  Copilot Studio, agente de IA, fábrica, segurança, governança e automação.
• 0:28
  Seja você um profissional de TI, desenvolvedor ou líder de negócios, há sessões projetadas para você.
• 0:35
  Com 10 dias completos, você pode explorar várias tecnologias e se conectar com uma comunidade global.
• 0:40
  Assista ao vivo e leve insights práticos para a sua organização.
• 0:45
  Janeiro de 2027, 10 dias, uma única comunidade Microsoft.
• 0:49
  As inscrições já estão abertas.
• 0:51
  Acesse m365com.net e garanta sua vaga hoje mesmo.
• 0:55
  É m365com.net
• 0:58
  Participe agora em m365com.net e nos vemos ao vivo em janeiro.
• 1:05
  Olá a todos e bem-vindos a mais um episódio de Pílulas de Conhecimento Microsoft aqui na M365FM.
• 1:10
  Eu sou o Mikko Peters.
• 1:11
  Imagine que você move um aplicativo de negócio antigo de um servidor no seu escritório para uma máquina virtual do ar.
• 1:16
  O aplicativo agora está na nuvem, mas ainda solicita um domínio Windows.
• 1:18
  Ele quer ingressar nesse domínio, buscar pessoas via LIDAP, autenticar usuários com quebrados e aplicar políticas de grupo.
• 1:24
  A maioria das pessoas assume que o EntryG substitui todas as funções do Active Directory.
• 1:28
  Não substitui.
• 1:29
  Aplicativos de nuvem modernos podem autenticar você via EntryG.
• 1:32
  Mas aplicativos Windows mais antigos ainda esperam o mesmo tipo de domínio que usavam na sala de servidores.
• 1:36
  Ao final deste episódio, você verá onde o EntryG, o Active Directory e o Entry Domain Services se encaixam.
• 1:41
  E há um detalhe que muda como você gerencia tudo isso.
• 1:44
  As informações de identidade viajam apenas em uma direção.
• 1:46
  Por que o EntryG sozinho não consegue executar todos os aplicativos da Gato?
• 1:50
  Vamos começar com o que o EntryG faz bem.
• 1:52
  Ele é a recepção dos seus serviços em nuvem.
• 1:55
  Ele sabe quem você é, verifica seu login e decide se você pode acessar um Microsoft 365,
• 1:59
  Teams, SharePoint ou um aplicativo de negócio na nuvem.
• 2:01
  Você faz login uma vez e transita entre serviços sem precisar digitar sua senha repetidamente.
• 2:06
  Esse é o logo único, single sign.
• 2:08
  O EntryG também pode solicitar uma segunda verificação de login e autenticação multifator,
• 2:12
  analisar o dispositivo que você está usando, de onde você está se conectando e as regras de acesso da sua empresa.
• 2:17
  Para um aplicativo moderno, esse padrão funciona muito.
• 2:19
  Se abre um navegador, o aplicativo envia para o EntryG, você faz login, talvez aprove uma solicitação no seu telefone,
• 2:25
  então o EntryG envia o aplicativo uma mensagem de login e segura em segundo plano.
• 2:28
  O aplicativo lê essa mensagem e permite a sua entrada.
• 2:30
  Com esse padrão, não há necessidade de ingresso no domínio, nenhum Windows Server antigo envolvido
• 2:34
  e não é preciso que o aplicativo pesquise um diretório corporativo clássico,
• 2:37
  mas aplicativos mais antigos cresceram em um mundo diferente.
• 2:39
  Imagine um aplicativo financeiro que roda em um Windows Server há anos,
• 2:42
  onde os usuários fazem login a partir de PCs ingressados no domínio.
• 2:45
  O aplicativo busca detalhes dos funcionários via LIDAP,
• 2:47
  uma maneira comum de softwares antigos pesquisarem um diretório corporativo.
• 2:51
  Ele pode usar Kerberos, um método de login antigo do Windows que permite que os sistemas confiem os outros.
• 2:55
  Ele pode depender de políticas de grupo,
• 2:56
  o conjunto de regras da empresa que controla configurações montadoras Windows.
• 3:00
  Esse aplicativo não sabe como ler uma mensagem de login moderna, na nuvem.
• 3:02
  Ele espera chamar pela rede e encontrar um domínio Windows tradicional.
• 3:07
  E se ele não encontrar um aplicativo que pode falhar o lugar dos usuários,
• 3:09
  não encontrar uma conta de serviço ou simplesmente se recusar a iniciar.
• 3:12
  Você provavelmente já viu esse padrão fora da TI também.
• 3:15
  Uma tomada nova não ajuda quando o plugue de uma máquina antiga não encaixa.
• 3:18
  A eletricidade está lá, mas a conexão está errada.
• 3:20
  Agora imagine a empresa movendo esse aplicativo financeiro e seu banco de dados para máquinas virtuais do OSB.
• 3:25
  Servidores mudaram, mas a necessidade antiga não.
• 3:27
  Você poderia deixar o Active Directory no escritório e conectar o Azure a ele por meio de uma VPN e um túnel de rede privada.
• 3:32
  Assim, o aplicativo no Azure envia solicitações por essa conexão sempre que precisa do domínio.
• 3:37
  Isso pode funcionar, mas o aplicativo agora depende da conexão de rede e da disponibilidade do controlador de domínio local.
• 3:42
  E se essa conexão tiver um problema, o aplicativo em nuvem também pode ter.
• 3:46
  Outra opção é criar suas próprias máquinas virtuais de controlador de domínio no Azure.
• 3:49
  Um controlador é o servidor que executa o domínio tradicional do Active Directory, gerenciando diretório, logins e outras tarefas do domínio.
• 3:56
  Isso também funciona, mas agora sua equipe é responsável por mais servidores.
• 3:58
  Alguém precisa atualizá-los e monitorar.
• 4:00
  Você precisa de backups, planos de recuperação, planos para manter os controladores de domínio sincronizados e também precisa proteger as poderosas contas de administrador que controlam.
• 4:07
  Para algumas empresas esse controle faz sentido.
• 4:09
  Para outras, é trabalho extra apenas para manter um aplicativo antigo funcionando bem.
• 4:13
  Portanto, a lacuna é bastante estreita, mas é real.
• 4:14
  O aplicativo vive no Azure, mas ainda fala a linguagem antiga do Active Directory.
• 4:19
  É o Microsoft Enter Domain Services, na verdade, o Microsoft Enter Domain Services é um domínio Windows gerenciado que roda dentro da sua rede Azure.
• 4:26
  Essa é a definição simples.
• 4:28
  Os controladores de domínio rodam nos bastidores totalmente gerenciados pela Microsoft,
• 4:32
  enquanto suas máquinas virtuais do Azure e aplicativos mais antigos usam os serviços de domínio familiares que esperam.
• 4:36
  Pense na sua configuração de nuvem como um prédio de escritório.
• 4:38
  O Win 3D é a recepção principal.
• 4:40
  Ele verifica quem você é quando você entra no Microsoft 365 ou em outro aplicativo de nuvem
• 4:44
  e aplica as regras da empresa para esse login.
• 4:46
  O Inter Domain Services fica em uma sala administrativa trancada.
• 4:49
  Sistemas mais antigos não precisam visitar a recepção da mesma forma que o aplicativo de nuvem moderno faz.
• 4:53
  Eles precisam de um diretório de estilo antigo por perto,
• 4:55
  um que entenda sua linguagem e possa responder as suas citações.
• 4:58
  Essa sala administrativa é o domínio gerenciado.
• 5:00
  O ponto é, você não precisa criar os controladores de domínio por conta própria.
• 5:03
  Você não entra neles com áreas de trabalho remoto.
• 5:05
  O DC não decide quantos rodar, não aplica patches do Windows neles, nem gerencia a conexão entre eles.
• 5:08
  A Microsoft cuida de tudo isso.
• 5:10
  Seu trabalho é conectar as máquinas virtuais do Azure e aplicativos certos ao domínio gerenciado.
• 5:14
  Uma vez conectados, eles podem usar os serviços familiares do Active Directory.
• 5:17
  Uma VM em Windows pode ingressar no domínio.
• 5:19
  Um aplicativo antigo pode usar a IDAP para pesquisar pessoas, grupos e detalhes do diretório.
• 5:23
  Ele pode usar Kerberos, um método de login que aplicativos de negócios mais antigos
• 5:26
  frequentemente esperam quando o servidor precisa confiar em um.
• 5:29
  Ele também pode usar a NTLM, outro método de login antigo do Windows que alguns aplicativos ainda exigem.
• 5:33
  O domínio gerenciado também fornece DNS,
• 5:35
  que ajuda os sistemas a encontrar o servidor certo pelo nome em vez de uma sequência de números.
• 5:39
  E ele suporta a diretiva de grupo para que você possa aplicar certas configurações do Windows
• 5:42
  a computadores e usuários nesse domínio gerenciado.
• 5:45
  Essa lista parece técnica, eu sei.
• 5:46
  Imagine isso como uma mesa de tradução.
• 5:48
  Seu aplicativo pergunta na linguagem antiga do Windows,
• 5:50
  quem é este usuário?
• 5:52
  Este servidor pode confiar naquele servidor?
• 5:54
  Onde está o banco de dados?
• 5:55
  Quais configurações este computador deve usar?
• 5:57
  O Entra Domain Services entende essas perguntas e fornece o tipo de resposta que o aplicativo espera,
• 6:01
  mas não cria uma segunda lista principal de funcionários.
• 6:04
  O registro de identidade principal permanece no EntraID.
• 6:07
  Usuários e grupos do EntraID são copiados para o domínio gerenciado
• 6:09
  para que o aplicativo mais antigo possa vê-los e usá-los na forma que entende.
• 6:13
  Se sua empresa também possui um Active Directory local,
• 6:15
  as identidades podem já chegar ao EntraID a partir de lá antes de serem copiadas para o Domain Services.
• 6:19
  A direção importa aqui.
• 6:20
  Os detalhes de identidade fluem para o Entra Domain Services.
• 6:23
  Eles não fluem de volta para fora.
• 6:24
  Portanto, se um usuário vem do EntraID, você gerencia esse usuário no EntraID.
• 6:28
  Se o usuário vem originalmente do seu Active Directory local, você gerencia o usuário lá.
• 6:32
  Você não deve tratar o Domain Services como local para editar o registro principal de funcionários.
• 6:36
  Isso evita que o domínio gerenciado se torne um segundo arquivo com versões diferentes da mesma pessoa.
• 6:41
  Agora, uma parte que pega muita gente durante a configuração é senhas.
• 6:45
  O login moderno em nuvem e o login antigo do Windows não usam senhas da mesma forma nos bastidores.
• 6:50
  Para que o Kerberos VNTLM funcione,
• 6:51
  o Domain Services precisa de uma forma protegida de dados de senha que suporte esses métodos antigos.
• 6:55
  A Microsoft nunca mantém sua senha como texto simples.
• 6:58
  Em vez disso, o serviço precisa das informações de senha protegidas corretas
• 7:01
  antes que um usuário possa entrar em uma VM ingressada no domínio
• 7:03
  ou em um aplicativo antigo por meio do domínio gerenciado.
• 7:05
  Para usuários, apenas não.
• 7:07
  Nuvem, isso geralmente significa que o usuário precisa alterar sua senha após a ativação do Domain Services.
• 7:12
  Essa alteração de senha cria a forma protegida necessária para o domínio gerenciado.
• 7:16
  Até que isso aconteça, o usuário pode entrar no Microsoft 365 perfeitamente bem,
• 7:19
  mas ainda falhar ao tentar usar o domínio de estilo antigo.
• 7:22
  Pode parecer estranho isso.
• 7:24
  O usuário já tem uma conta, a senha já funciona, mas o aplicativo legado.
• 7:27
  Ainda não consegue usá-la.
• 7:29
  A peça que falta não é a conta de usuário.
• 7:30
  É a forma de senha protegida e exigida por esses métodos de login mais antigos.
• 7:34
  Domain Services também tem um limite claro sobre onde ele funciona.
• 7:37
  Ele é executado dentro de uma rede virtual do Azure, frequentemente chamada de VM.
• 7:40
  Suas VMs do Azure precisam de acesso de rede a essa VNet
• 7:43
  e precisam usar a configuração de DNS do domínio gerenciado para que possam encontrá-lo.
• 7:47
  Este não é um diretório público que qualquer dispositivo na internet pode contatar.
• 7:50
  É um serviço de domínio privado para cargas de trabalho conectadas à rede correta do Azure.
• 7:54
  Portanto, quando um aplicativo precisa do comportamento antigo do Active Directory no Azure,
• 7:57
  o Domain Services oferece um local gerenciado para encontrar esse comportamento.
• 8:00
  Isso nos leva à próxima pergunta.
• 8:02
  Onde isso se encaixa ao lado do Entre-ID e do seu domínio do Active Directory existente?
• 8:06
  Os nomes são parecidos, mas suas funções são muito diferentes.
• 8:09
  Entre-ID, Active Directory e Domain Services, funções diferentes.
• 8:13
  Os nomes são próximos, então é fácil tratá-los como versões diferentes do mesmo produto.
• 8:17
  Eles não são.
• 8:18
  Cada um lida com uma parte diferente do cenário de identidade da sua empresa,
• 8:21
  e uma vez que você vê a função de cada um, a escolha se torna muito mais clara.
• 8:24
  Entre-ID é com a identidade na nuca.
• 8:26
  Quando você abre o Microsoft 365, Teams, SharePoint ou um aplicativo de negócios moderno,
• 8:30
  o Entre-ID verifica seu login e controla o que você pode acessar.
• 8:33
  Ele também oferece suporte à autenticação, multiviatura e regras de acesso,
• 8:36
  como solicitar uma verificação de login mais forte quando você trabalha a partir de um dispositivo desconhecido.
• 8:40
  Ele foi criado para ser vizinho.
• 8:42
  Um aplicativo moderno não precisa estar na mesma rede que o Entre-ID,
• 8:44
  porque utiliza métodos de login baseados na web.
• 8:47
  Você faz login por meio de um navegador ou aplicativo,
• 8:49
  o Entre-ID confirma quem você é e o aplicativo recebe uma prova de que você tem permissão de acesso.
• 8:53
  Esse é o padrão normal para novos aplicativos em nome.
• 8:55
  O Active Directory Domain Services, frequentemente abreviado como Active Directory,
• 8:58
  realiza um trabalho diferente.
• 9:00
  Este é o domínio Windows tradicional que muitas empresas executam em seus próprios escritórios,
• 9:03
  data centers ou salas de servidores.
• 9:05
  A empresa é proprietária dos controladores de domínio e escolhe como configurá-los
• 9:08
  e gerencia todo o domínio de cima a baixo.
• 9:10
  Ele pode controlar PCs com Windows, dar suporte a servidores locais
• 9:13
  e fornecer os métodos de login mais antigos que o aplicativo de negócio dá.
• 9:16
  Esse nível de controle traz responsabilidade.
• 9:18
  Sua equipe de TI gerencia o domínio, cuida dos servidores
• 9:21
  e decide como o diretório deve funcionar para a empresa.
• 9:25
  O Entre-Domain Services situa-se entre esses dois mundos.
• 9:27
  Ele oferece as cargas de trabalho do Azure em um domínio Windows gerenciado
• 9:30
  quando precisam do comportamento do Active Directory antigo,
• 9:32
  mas a Microsoft cuida da parte do controlador de domínio.
• 9:34
  Você usa o domínio para VMs do Agile e aplicativos mais antigos
• 9:37
  sem assumir todo o trabalho de gerenciar um domínio Active Directory tradicional por conta própria.
• 9:41
  Pense nisso como um sistema de arquivo.
• 9:42
  O Entrade mantém o registro principal dos funcionários para o trabalho em nuvem.
• 9:45
  É lá que a empresa mantém o registro de trabalho usado para o Microsoft 365
• 9:48
  e logins modernos em nuvem.
• 9:50
  O Domain Services fornece aos aplicativos mais antigos do Azure
• 9:53
  uma cópia compatível dos registros de que precisa.
• 9:55
  Esses aplicativos podem abrir o tipo familiar de arquivo
• 9:57
  e encontrar usuários, grupos e detalhes de login
• 9:59
  no formato antigo que eles compreendem.
• 10:01
  Você não precisa reconstruir o aplicativo só porque ele foi movido para o Azure.
• 10:04
  Uma empresa que utiliza apenas nuvem também pode usar essa configuração.
• 10:07
  Imagine uma empresa que nunca executou controladores de domínio local.
• 10:09
  Todos fazem login no Microsoft 360D e a empresa começa a usar VMs do Azure
• 10:14
  para um aplicativo Windows mais antigo.
• 10:16
  Essa empresa não precisa criar um domínio Active Directory local apenas para esse aplicativo.
• 10:21
  Em vez disso, ela pode usar o Entra Domain Services para as VMs do Azure
• 10:23
  que precisam de comportamento de domínio
• 10:25
  enquanto o restante da empresa continua usando o Entra ID para o trabalho normal ainda.
• 10:28
  Uma empresa híbrida tem um ponto de partida diferente.
• 10:30
  Ela pode já executar o Active Directory em seu escritório
• 10:32
  com usuários e grupos que são sincronizados com o Entra ID.
• 10:34
  Essas pessoas podem então aparecer no Entra Domain Services
• 10:37
  para cargas de trabalho executadas no Azure.
• 10:39
  O fluxo funciona assim.
• 10:41
  O Active Directory, existente da empresa, envia detalhes de identidade para o Entra ID
• 10:44
  e o Entra ID fornece a cópia compatível para o Domain Services.
• 10:48
  Isso não significa que o Domain Services substitui o domínio local original.
• 10:52
  O escritório ainda pode precisar de seu próprio domínio do Active Directory
• 10:54
  para PCs locais, servidores locais, sistemas de fábrica ou aplicativos que permanecem no local.
• 10:59
  O Domain Services lida apenas com a parte do Azure
• 11:01
  em que o comportamento de domínio antigo gerenciado se ajusta à carga de trabalho.
• 11:04
  E ele também não transforma o Entra ID em um Active Directory completo.
• 11:07
  O Entra ID continua sendo um serviço de identidade em nuvem.
• 11:09
  O Domain Services adiciona um domínio gerenciado para certas necessidades antigas,
• 11:14
  mas não oferece todas as opções e níveis de controle
• 11:16
  que você teria ao executar o Active Directory por conta própria.
• 11:19
  Imagina três funções distintas.
• 11:21
  O Entra ID lida com logins modernos na NU.
• 11:23
  O Active Directory lida com o domínio do Windows, que sua empresa gerencia por si mesmo.
• 11:26
  O Entra Domain Services lida com cargas de trabalho legadas no Azure,
• 11:29
  que ainda precisam de um domínio do Windows
• 11:31
  sem exigir que você execute os controladores de domínio com essas funções.
• 11:33
  Você pode fazer uma pergunta muito melhor.
• 11:36
  Quando o Domain Services se ajusta à carga de trabalho?
• 11:38
  Quando você deve escolher outra coisa?
• 11:40
  Quando o Domain Services se encaixa?
• 11:42
  Quando não?
• 11:42
  Comece pelo aplicativo, não pelo nome do produto.
• 11:45
  Se um aplicativo antigo usa LDAP,
• 11:46
  que é uma linguagem antiga para verificar nomes de usuários e senhas,
• 11:49
  e você está migrando para o Azure,
• 11:50
  o Domain Services pode ser uma ótima opção.
• 11:52
  O aplicativo continua usando o que já entende,
• 11:54
  sem forçar uma reescrita completa.
• 11:56
  Isso importa quando o aplicativo ainda funciona,
• 11:57
  a empresa precisa dele reescrever o código de login,
• 11:59
  que custaria muito tempo ou dinheiro.
• 12:00
  Outro cenário comum,
• 12:02
  um grupo de máquinas virtuais do Azure
• 12:04
  precisa agir como computadores de domínio normais.
• 12:07
  A equipe pode precisar entrar no Windows com sua conta de trabalho.
• 12:09
  Um serviço pode precisar de uma conta de serviço,
• 12:11
  uma conta que um aplicativo usa para se conectar a outro sistema,
• 12:13
  como um banco de dados.
• 12:15
  Você pode precisar da política de grupo
• 12:16
  para aplicar configurações da empresa a essas máquinas virtuais.
• 12:18
  Nesses casos,
• 12:19
  o Domain Services oferece às máquinas do Azure
• 12:21
  o comportamento de domínio que elas esperam.
• 12:23
  O serviço de área de trabalho remota também se encaixa.
• 12:25
  Imagine funcionários se conectando a áreas de trabalho
• 12:26
  ao aplicativos Windows, compartilhados no Azure.
• 12:29
  Esses sistemas geralmente dependem de um domínio do Windows
• 12:31
  para login de usuário e gerenciamento de computadores.
• 12:34
  O Domain Services fornece essa camada de domínio
• 12:35
  sem que sua equipe precise criar máquinas virtuais
• 12:37
  de controlador de domínio do zero.
• 12:39
  Aplicativos mais antigos geralmente têm mais de uma.
• 12:41
  Pode haver um servidor web na frente,
• 12:43
  um servidor de aplicativos no meio
• 12:44
  e um banco de dados atrás.
• 12:45
  O servidor de aplicativos precisa aprovar sua identidade
• 12:47
  antes que o banco de dados aceite uma conexão.
• 12:50
  Quando essa confiança depende de contas de serviço do Windows,
• 12:52
  o Domain Services mantém essas conexões funcionando após a migração.
• 12:54
  O ponto é, sua equipe obtém o comportamento de domínio antigo
• 12:58
  de que a carga de trabalho precisa,
• 12:59
  enquanto a Microsoft cuida do trabalho de controlador de domínio
• 13:02
  que de outra forma ficaria na sua lista de servidores.
• 13:04
  Mas não escolha o Domain Services só porque você está usando o Azure.
• 13:07
  Um novo aplicativo em nuvem deve realizar o login diretamente pelo Entry.
• 13:10
  Se ele suportar métodos de login modernos,
• 13:12
  ele encaminha os usuários ao EntryD,
• 13:13
  recebe a confirmação do login e se beneficia das regras de acesso na nuvem
• 13:16
  e da autenticação multifator.
• 13:18
  E da autenticação multifator.
• 13:19
  Esse é o caminho mais limpo para softwares no.
• 13:21
  Domain Services ajuda aplicativos que utilizam a linguagem antiga.
• 13:23
  Não é uma razão para ensinar essa linguagem antiga a novos aplicativos.
• 13:26
  Também existem limites rígidos que você precisa verificar primeiro.
• 13:29
  Alguns aplicativos não apenas lendo Active Directory e gravam informações, não.
• 13:32
  Por exemplo, um aplicativo pode precisar criar ou alterar
• 13:35
  entradas de diretório como parte de superação normal.
• 13:38
  O Domain Services não é adequado
• 13:39
  quando o aplicativo requer acesso escrita via LDAP.
• 13:42
  O mesmo aviso se aplica se um aplicativo
• 13:43
  precisar alterar o esquema do Active Directory,
• 13:45
  conjunto de campos que definem o que o diretório pode armazenar.
• 13:48
  Alguns softwares mais antigos pedem para você
• 13:50
  adicionar seus próprios campos antes de serem executados.
• 13:52
  Um domínio gerenciado não permite que você altere esse design sobre o já ser.
• 13:55
  Você também deve parar e pensar se sua equipe
• 13:56
  precisa de controle total sobre o próprio jogo.
• 13:58
  Talvez você precise de acesso direto aos controladores de domínio.
• 14:01
  Talvez você precise de direitos de administrador de domínio
• 14:02
  que oferecem um controle muito amplo.
• 14:04
  Ou talvez você precise de um design de diretório complexo
• 14:06
  que deseja construir e executar do seu jeito.
• 14:08
  Isso aponta para a necessidade de executar o Active Directory
• 14:10
  por conta própria, seja localmente
• 14:12
  ou em máquinas virtuais no Azure.
• 14:14
  Domain Services oferece deliberadamente menos controle
• 14:16
  porque a Microsoft gerencia o serviço de domínio principal.
• 14:18
  Portanto, faça uma pergunta simples antes de escolher um caminho.
• 14:21
  Esta carga de trabalho precisa da linguagem antiga do Active Directory
• 14:24
  e ela pode falar a linguagem moderna da Entry.
• 14:26
  Se ela puder usar o Entry moderno, comece por aí.
• 14:28
  Se ela precisar do comportamento de domínio antigo,
• 14:30
  mas não exigir que você seja dono de cada parte do domínio,
• 14:32
  o Domain Services pode ser muito adequado.
• 14:34
  E se o aplicativo precisar reescrever o diretório,
• 14:36
  alterar seu esquema ou dar à sua equipe controle total do domínio,
• 14:39
  ele precisa de outro local.
• 14:40
  Escolher um domínio gerenciado significa aceitar uma troca.
• 14:42
  A Microsoft cuida dos controladores de domínio
• 14:44
  e você abre mão de parte do controle que teria ao gerenciá-los por conta própria.
• 14:48
  As trocas do serviço gerenciado que você precisa conhecer
• 14:50
  Essa abordagem gerenciada economiza trabalho,
• 14:52
  mas também muda o que sua equipe de TI pode controlar.
• 14:55
  A Microsoft executa os controladores de domínio,
• 14:57
  mantém a sincronização, aplica patches
• 14:58
  e cuida da disponibilidade nos bastidores.
• 15:00
  Você não precisa planejar onde cada controlador de domínio
• 15:03
  ficará nem recuperar um após uma falha de servidor.
• 15:05
  É por isso que muitas equipes o escolhem,
• 15:06
  mas você não pode acessar esses controladores via área de trabalho remota
• 15:09
  nem obtém direitos de administrador de domínio ou de empresa,
• 15:12
  pois isso daria controle sobre as partes gerenciadas pela Microsoft.
• 15:15
  Em vez disso, a Microsoft fornece um grupo
• 15:16
  chamado Administradores do Entra Domain Services.
• 15:19
  Coloque as pessoas que precisam gerenciar o domínio desse grupo
• 15:21
  e use uma máquina virtual de gerenciamento conectada ao domínio gerenciado.
• 15:25
  A partir dessa máquina, você pode usar ferramentas familiares
• 15:27
  do Active Directory até gerenciar o que a Microsoft permite.
• 15:30
  Por exemplo, você pode criar suas próprias unidades organizacionais ou UOS.
• 15:33
  Pense nelas como pastas para objetos de domínio
• 15:35
  como computadores ou contas de serviço.
• 15:36
  Você pode gerenciar registros DNS,
• 15:38
  criar e aplicar políticas de grupo para configurações compatíveis.
• 15:40
  Você também pode gerenciar os computadores que ingressam no domínio,
• 15:43
  o que geralmente é o principal motivo da existência do serviço.
• 15:45
  Esses limites são propositários.
• 15:47
  Você não pode adicionar mais controladores de domínio,
• 15:49
  alterar o esquema do Active Directory
• 15:50
  ou tratar o domínio gerenciado como um local
• 15:52
  onde as alterações fluem de volta para o EntraID.
• 15:54
  Portanto, mantenha o gerenciamento de usuários e grupos no diretório de olho.
• 15:57
  Para uma empresa apenas na nuvem,
• 15:58
  essa origem é o EntraID.
• 16:00
  Para uma empresa híbrida,
• 16:01
  é o Active Directory local que sincroniza com o EntraID.
• 16:05
  Essa regra evita um erro que vemos com frequência.
• 16:07
  Alguém vê um usuário no domínio gerenciado
• 16:09
  e o altera lá, assumindo que a mudança será permanente.
• 16:11
  Mas essa alteração não se tornará o registro da empresa
• 16:13
  no EntraID ou no Active Directory local.
• 16:16
  Mantenha o domínio gerenciado e privado dentro da rede do Azul.
• 16:19
  Ele deve suportar apenas as cargas de trabalho que precisam dele,
• 16:21
  não se tornar um diretor geral da empresa.
• 16:23
  Limite o acesso à rede,
• 16:24
  proteja a máquina de gerenciamento
• 16:26
  e conceda acesso administrativo apenas a quem precisa.
• 16:29
  Você está escolhendo um serviço com mecanismo de proteção.
• 16:30
  Esses mecanismos eliminam parte do trabalho
• 16:32
  enquanto impedem que você altere as partes que pertencem à Microsoft.
• 16:34
  Uma história simples de migração próxima.
• 16:38
  Imagine uma empresa financeira
• 16:39
  executando um aplicativo antigo em servidores
• 16:41
  dentro do seu próprio escritório.
• 16:42
  Esse aplicativo depende de Herdapia para localizar funcionários.
• 16:44
  Ele usa Kerberos quando as pessoas fazem login.
• 16:46
  E seu servidor autentica com uma conta de serviço
• 16:48
  para acessar o banco de dados financeiro.
• 16:50
  A empresa quer mover tanto o aplicativo
• 16:51
  quanto o banco de dados para máquinas virtuais do Azul.
• 16:54
  Uma opção é manter o aplicativo conectado
• 16:56
  ao domínio do escritório por meio de uma VPN,
• 16:58
  mas então o aplicativo no Azul dependerá
• 16:59
  dessa conexão de rede e dos controladores de domínio locais todos os dias.
• 17:02
  Outra opção é executar novas máquinas virtuais
• 17:04
  de controlador de domínio no Azul.
• 17:06
  Isso mantém mais tráfego dentro do Azul,
• 17:07
  mas adiciona servidores Windows
• 17:08
  que a equipe de TI precisa corrigir,
• 17:10
  monitorar, fazer backup e recuperar.
• 17:12
  A equipe segue um caminho diferente.
• 17:13
  Seus usuários e grupos já são sincronizados com o EntraID.
• 17:16
  Eles habilitam o EntraDomain Services,
• 17:18
  conectam a rede virtual do Azul e...
• 17:19
  O EntraDomain Services,