Série Azure parte 2 – PAYG para CSP

Olá pessoal

Hoje no segundo vídeo vou demonstrar em 3 passos como podemos migrar de PAYG que é pay as you go (Pago pelo consumo) para CSP.

Muitas empresas iniciam sua jornada com as próprias pernas.

Depois o consumo aumenta e é preciso de um parceiro para diminuir os custos e ajudar nos impostos.

O licenciamento CSP (Cloud Solution Provider) é relativamente novo e tem ajudado muitas empresas a diminuir seus custos e impostos.

Este vídeo ajudará como é o processo pois a migração de workloads para CSP.

A restrição para alguns serviços e você pode dar uma conferida neste link da documentação da Microsoft.

https://docs.microsoft.com/pt-br/azure/cloud-solution-provider/migration/migration-from-payg-to-csp

Espero que ajudem.

Serie 001 Azure – Criando sua conta no Azure

Olá pessoal

Estou disponibilizando uma série que vai lhe ajudar no Azure.

Para voce que está iniciando sua carreira em Cloud venha comigo no Azure.

Uma série com mais ou menos 17 vídeos que será semanal.

Este primeiro vídeo é como criar sua conta e utilizar o Azure.

Em resumo você tem 670 reais de crédito para utilizar e testar recursos IaaS, PaaS é SaaS.

Fora vários recursos que tem gratuidade de 12 meses.

Aproveite e veja o vídeo no meu canal no YouTube.

Dúvidas estarei a disposição.

Abraços

Ativando AIP e MFA Azure AD e dicas ADFS do 3 para o 4.

Olá pessoal.

O Azure Information protection é um recurso que pode ser usado de forma hibrida entre Office 365, Azure e ambiente onpremissess no Active Directory no Windows Server 2012 em diante.

É um recurso de segurança que remete a gestão e segurança de 2 fatores neste ecossistema.

Antes de tudo é um licenciamento do AD premium versão P2.

Então cautela na escolha, repetindo é na versão P2 do AD Premium.

Sua ativação é bem simples.

Acesse o portal do Azure.

Escolha Identity e veja em amaremo Azure AD Identity Protection. Clique no botão.

É bem simples mesmo, cliquem em criar.

Depois de criado você vai acessar o portal do ad em https://aad.portal.azure.com

Vai escolher um usuário do AD e vai ativar o MFA, Multifactor autentication, que é a autenticação de duplo fator.

Pronto, vai estar ativado a função.

Para quem tem Office 365, no portal do administrador tem uma forma de acessar configurações de MFA

Veja que aqui para office 365 você pode também trabalhar de uma forma paralela em habilitar MFA.

Para quem tem ADFS

Inicie o console de gerenciamento do AD FS em seu servidor interno principal do AD FS. Navegue até AD FS → Políticas de Autenticação e clique na ação Editar Autenticação Global de Vários Fator … ou clique no link Editar em Autenticação de Vários Focos → Configurações Globais.

Va em Edit Global Multi-factor Authentication

Deixe selecionado autenticação de 2 fatores.

Acesso para Cliente do Office 365

Office 2013 e 2016 aplicativos de desktop (incluindo Outlook e Skype for Business) podem se conectar ao Office 365 após a instalação do adaptador AD FS somente se a Autenticação moderna estiver habilitada para Office 365 (ou se você tiver construído suas regras MFA para excluir aplicativos cliente do Office) ). Mais informações sobre Autenticação, incluindo uma lista de aplicativos do Office que oferecem suporte à Autenticação moderna, estão disponíveis no Blog do Office.

Atualizando o Duo para o AD FS

Para atualizar em um servidor AD FS 3 ou 4, desative primeiro o método de autenticação do de 2 fatoresfor AD FS no console de Gerenciamento do AD FS.

Inicie o console de gerenciamento do AD FS em seu servidor interno do AD FS.

Navegue até AD FS → Políticas de Autenticação e clique na ação Editar Autenticação Global de Vários Fator … (AD FS 3) ou AD FS → Serviço → Métodos de Autenticação e clique na ação Editar Métodos de Autenticação Multifator … (AD FS 4 ).

Desmarque a caixa ao lado do método de autenticação Duo Authentication for AD FS X.X.X.X para desativar a proteção do Duo. Observe que em versões mais antigas do Duo para AD FS, o método de autenticação é chamado de Security for AD FS 3.0.

Baixe o pacote de instalador do Duo AD FS mais recente para o AD FS 3 e 4 e execute o MSI em um prompt de comando com privilégios elevados. Veja as somas de verificação para downloads do Duo aqui.

Siga as instruções na tela para concluir a instalação da atualização.

Quando o instalador terminar, repita as etapas que você originalmente seguiu para ativar o método Duo no AD FS. Os usuários podem fazer logon em serviços federados sem proteção de dois fatores até que você tenha reativado o método de autenticação de 2 fatores.

Espero que tenha ajudado.

Abraços pessoal.

Remote Desktop Services via PowerShell

Olá pessoal

O pessoal me pediu e está ai.

Remote Desktop via PowerShell.

Se dá para fazer tudo via PowerShell? Pelo menos tudo que eu fiz nos passos dá.

Então vamos lá.

Abra o Powershell e digite o comando:

Import-Module RemoteDesktopServices (Windows 2012) no Windows Server 2012R2 em diante é Import-Module RemoteDesktop. Pelo menos nos testes que fiz.

Para instalar os três componentes RDS obrigatórios em uma implantação padrão, use o cmdlet New-SessionDeployment
conforme mostrado abaixo, substituindo os valores dos parâmetros -ConnectionBroker , -WebAccessServer e -SessionHost
pelos nomes dos servidores nos quais você deseja para instalar essas funções.


New-SessionDeployment – ConnectionBroker NOMEDOSERVIDOR – WebAccessServer NOMEDOSERVIDOR – SessionHost NOMEDOSERVIDOR

Se você quiser adicionar um Host de Sessão RD ou um Licenciamento RD adicional, poderá usar o cmdlet Add-RDServer.

Add-RDServer -Server NOMEDOSERVIDOR -Role RDS-RD -SERVER -ConnectionBroker


Só aguardar, é bem rápido.

Se você optar por instalar o Licenciamento RD, precisará usar o console de gerenciamento no servidor de licenças para ativar o servidor e instalar suas licenças da Microsoft. Depois de fazer isso, você pode usar o PowerShell para associar o novo servidor de licenças ao agente de conexão existente usando o cmdlet Set-RDLicenseConfiguration . O parâmetro -Mode pode ser definido como PerDevice ou PerUser. Preste atenção no contrato que você comprou para não instalar errado.

Set-RDLicenseConfiguration -LicenseServer NOMEDOSERVIDOR -Mode PerUser -ConnectionBroker NOMEDOSERVIDOR

 Selecione ‘Y’ para sim para confirmar a operação.

Espero que tenha ajudado.

Até mais

 


 

Transferência de FSMO


Olá pessoal

Muita gente me pede como fazer a migração de AD de um sistema operacional para outro.

Estes passos eu testei do Windows Server 2008 até o Windows Server 2016.

l

O Windows Server 2019 eu ainda não testei.

Os testes aqui foram do Windows Server 2008 para Windows Server 2012 R2.

As 5 regras de operações do Active Directory, essas regras também são conhecidas como FSMO Rules (Flexible Single Master Operation). Essas regras são essenciais para a saúde do AD e o bom funcionamento do AD.

Nosso objetivo é transferir essas 5 regras para o controlador de domínio Windows Server 2012 R2.

Primeiro vamos listar as 5 regras de descobrir qual os controladores de domínio tem propriedade sobre elas para isso vamos executar o comando NETDOM QUERY FSMO.

1) No prompt de comando do Windows Server 2012 R2 execute o comando netdom query fsmo para verificar nosso schema. Observe que todas as funções fazem parte do server2008 R2.

Precisamos agora transferi-las para o Windows Server 2012 R2.


2) Antes de transferir todas as funções precisamos preparar o Domínio.

No servidor Windows Server 2012 R2 > insira o DVD do Windows Server 2012 R2 > no diretório support > acesse o diretório adprep> execute os seguintes comandos:

3) adprep.exe /forestprep


4) Pressione C > ENTER

5) Verifique que as informações de toda a floresta já foram atualizadas.


6) Execute agora:

adprep.exe /domainprep


7) Verifique que as informações de todo o domínio já foram atualizadas.


8) Execute agora:

adprep.exe /rodcprep


9) Rodcprep concluído com êxito.


10) Execute agora:

adprep.exe /domainprep /gpprep


11) Verifique que não é necessário atualizações de GPO porque já foram realizadas.


Vamos agora utilizar o utilitário NTDSUTIL que é uma ferramenta de administração avançada do Active Directory para realizar a transferência.

Abra o prompt de comando do Windows Server 2008 R2 > execute os seguintes comandos:

1) ntdsutil

2) roles

3) connections

4) connect to server server2012r2 ( onde server2012r2 é o hostname do servidor 2012r2)

5) q

6) transfer schema master


7) Confirme SIM


b) Digite:

1) transfer PDC


2) Confirme SIM


c) Digite:

1) transfer naming master


2) Confirme SIM


d) Digite:

1) transfer RID master


2) Confirme SIM


e) Digite:

1) transfer infrastructure master


2) Confirme SIM


3) Execute netdom query fsmo> para verificar que foram transferidas todas as funções para o servidor Windows Server 2012 R2.


Rebaixando o AD do Windows server2008 R2

OBS: Se você tem alguma dúvida sobre todo processo realizado, não rebaixe o Windows Server 2008 R2 ainda, apenas deligue ele e se algum processo sair errado você ainda pode recorrer a ele.

Agora vamos rebaixar o Active Directory do Windows Server 2008 R2, ou seja, ele não terá mais função de controlador de domínio.

1) Execute:


2) Avançar


3) Não marque a opção “Este servidor é o último controlador de domínio no domínio” > Avançar


4) Digite uma nova senha para o Administrador local do Servidor 2008> Avançar


5) Avançar


6) Removendo


7) AD removido > Concluir.


8) Console do AD no Windows Server 2012 R2, observe que agora o server2008r2 não é mais membro de Domain Controller mas de Computers.

Bom pessoal, acredito que com este post você poderá migrar se Active Directory.

OBS: Observação para GPO´s, DNS se estiver no mesmo servidor do AD, DHCP que são itens geralmente relacionados a um servidor só.

Estes itens e serviços já devem estar migrados.

Até mais.

Vantagens em usar Azure

Olá pessoal

 

Fiz uma live com o pessoal da Cloud Treinamentos orientando vantagens e práticas de mercado do uso do Azure.

Confira na Íntegra:

Quem nao conseguiu assistir ao Vivo veja no Youtube. Vantagens de usar Microsoft Azure.

Certificado RDWEB 2008 e 2008 R2

Certificados desempenham um papel importante em implantações de serviços de área de trabalho remota (RDS). Elas ajudam a proteger as comunicações entre cliente e servidor. Elas confirmam a identidade do servidor ou do Web site ao qual você está se conectando. Eles também assinar arquivos Remote Desktop Protocol (RDP) para assegurar-lhes que eles são de uma fonte confiável.

Você deve usar certificados com cada serviço de função RDS. Aqui está o que você precisa saber para instalar certificados em cada servidor de papel usando ferramentas local ou diretiva de grupo. Primeiro, configure todos os Host de Sessão RD por servidor segurança configurações de conexão do separador Geral do proto­caixa de diálogo de propriedades do ouvinte col da ferramenta de configuração do RD. Para chegar lá, vá em Ferramentas administrativas | Serviços de área de trabalho remota | Configuração do Host da sessão área de trabalho remota. Em seguida, faça duplo clique em RDP-Tcp na seção Connections do painel do meio. Esta é também onde você adiciona o certificado do servidor SSL.

Você pode definir essas configurações em uma base por servidor. Você também pode definir essas configurações usando a diretiva de grupo, aplicando o seguinte conjunto de configurações de objeto de diretiva de grupo (GPO) a unidade organizacional do Host de Sessão RD server (UO) de configuração do computador | Políticas | Modelos administrativos | Componentes do Windows | Serviços de área de trabalho remota | Host de sessão de área de trabalho remota | Segurança:

  • Definir nível de criptografia da conexão de cliente
  • Exigir a utilização de camada de segurança específicas para remotos conexões (RDP)
  • Modelo de certificado de autenticação de servidor
  • Exigir autenticação do usuário para conexões remotas usando autenticação no nível da rede (NLA)

Autenticação de rede

NLA não é exigida por padrão. Para requerer o uso de NLA para conexão com o servidor Host de Sessão RD, selecione a appropri­comeu a caixa de seleção. Ao fazê-lo irá impedir a conexão com o servidor de quaisquer clientes que não oferecem suporte a NLA (qualquer cliente que executam o RDC antes a versão 6. x e qualquer sistema operacional que não oferece suporte a provedor de suporte de segurança de credenciais ou CredSSP). Apenas clientes que executam o Windows 7, Windows Vista e Windows XP SP3 suportam CredSSP.

Autenticação do servidor

Defina o servidor configurações autenticação na seção de camada de segurança. O padrão é Nego­tiate, significado que cliente e servidor serão usar segurança de camada de transporte (TLS) para autenticação de servidor, que se sup­portado.

Você pode editar essa configuração para forçar a autenticação de servidor usando o protocolo TLS. Se você não puder autenticar o servidor, você pode definir o comportamento do cliente das configurações na guia Avançado do cliente Desktop remoto:

  • Não conectar se a autenticação falhar
  • Avisar se autenticação falhar
  • Sempre conectar, mesmo se a autenticação falhar

Você pode escolher o certificado que o servidor deve usar para autenticar-se clicando em Selecione na parte inferior da tela. Se você clicar em Select, você pode obter mais detalhes sobre o certificado, incluindo o que ele é usado, o nome da autoridade de certificação (CA), e quando ela expira.

O certificado deve conter o nome DNS do servidor Host de Sessão RD. Isso será algo como rdsh1.domain.local, por exemplo. Se você implementou um farm de servidor, o certificado deve conter o nome DNS do farm de servidor Host de Sessão RD — por exemplo, farm.domain.local.

O servidor Host de Sessão RD é definido para usar um certificado auto-assinado, por padrão. Este certificado não se destina a ser usado em ambientes de produção por três razões:

  • O autenticidade de certificado não é avaliado em tudo.
  • O certificado não é confiável por clientes porque ele não é assinado por uma parte confiável (como uma CA pública ou a solução de infra-estrutura de chave pública interna da empresa).
  • Se você estiver implementando um farm de servidores, o nome do certificado padrão não vai corresponder nome do farm de servidor RD sessão host, para que verificar a identidade do servidor falhará.

Assinatura de VMs em pool e pessoais

Você pode ter colocado em pool e pessoais máquinas virtuais (VMs) assinado por instalando um certificado SSL sobre o agente de conexão RD usando o Gerenciador de conexão de RD (se Figura 1).

Figura 1 você pode usar o Gerenciador de conexão de RD para assinar em pool ou único VMs.

Assinatura RemoteApps

Assinar RemoteApps usando o certificado instalado no Gerenciador de RemoteApp no servidor Host de Sessão RD (veja Figura 2).

Figura 2 você também pode assinar RemoteApps; Use o certificado no Gerenciador de RemoteApp.

Se você configurar um farm de servidores Host de Sessão RD, certifique-se de instalar o exato mesmo certificado em todos os servidores Host de Sessão RD no farm e em outras explorações agrícolas que você implanta. Dessa forma Web single sign-on (SSO) funcionará em todos os membros do farm de servidores e em todos os farms.

Para isso, exporte o certificado, incluindo a chave privada, de um servidor. Importá-lo para outro servidor usando o snap-in certificados no Microsoft Management Console (MMC) — adicionar a conta do computador, não a conta de usuário.

Se você estiver implementando o SSO da Web com acesso via Web RD e você estiver usando o agente de conexão RD como fonte de acesso via Web RD, em seguida, você deve instalar o mesmo certificado no agente de conexão RD como você faz em todos os servidores Host de Sessão RD (o mesmo certificado usado para assinar RemoteApps). Isso pode ser confuso por duas razões:

  1. A seção onde você instala o certificado no agente de conexão RD é chamada “Virtual Desktops: Recursos e configuração,”que é enganosa. O certificado instalado aqui não é somente usado para a assinatura de infra-estrutura de desktop virtual (VDI) VMs, ele também é usado no processo de SSO da Web para a assinatura de RemoteApps quando agente de conexão RD está envolvido. Os certificados de autenticação no servidor Agente de conexão RD e Host de Sessão RD RemoteApp Manager devem corresponder ou SSO da Web falhará.
  2. Quando você inicia um RemoteApp, e o certificado instalado no agente de conexão RD é diferente daquele instalado nos servidores Host de Sessão RD, SSO da Web não funcionará. Não há nenhuma indicação, no entanto, o certificado é realmente diferente no agente de conexão RD. A janela pop-up mostra apenas o certificado no Gerenciador de RemoteApp, por isso, é difícil dizer que há um problema de certificado.

Verifique blog “Introducing Web Single Sign-On para e Desktop conexões RemoteApp” para obter mais informações sobre como configurar o SSO da Web.

Protegendo o Site de acesso Web RD

Protegendo um site não é específico do RDS. Para proteger o site do acesso via Web RD, adicione um certificado com o nome DNS do Web site no IIS (consulte Figura 3).

Figura 3 Adicionar um certificado com o nome DNS pode proteger um site acesso via Web RD.

Certificados instalados para armazenamento do servidor do computador pessoal que tem a chave privada incluída aparecerão como opções na caixa de lista suspensa correspondente no menu Editar.

Configurando o Gateway RD com um certificado

A instalação de Gateway RD requer um certificado para criptografar as comunicações entre cliente e servidor, especialmente através da Internet. O certificado SSL deve conter o nome DNS do servidor Gateway RD que os usuários externos podem resolver (nome do DNS externo, por exemplo: rdgateway.Domain.com).

Instalar o certificado RD Gateway por meio da guia certificado SSL nas propriedades do Gerenciador de Gateway RD (veja Figura 4). Veja mais informações sobre certificados de Gateway RD na TechNet Library.

Figura 4 instalar o certificado de Gateway RD.

Você pode configurar certificados em sua implantação de RDS para comunicações seguras e autenticar o cliente e servidor. Não há requisitos de certificado específico para cada serviço de função. Isso deve ajudá-lo a entender porque você precisa de certificados em implementações de RDS e como e onde implementar certificados com cada serviço de função RDS.

Fonte: https://technet.microsoft.com/pt-br/library/hh987041.aspx

Apache Guacamole

Olá pessoal.

Estava procurando informações sobre desktop, VDI, VDA, acesso remoto com inteligência, Desktop como serviço e alternativas mais acessíveis para meus clientes.

Me deparei com esta excelente ferramenta. O Projeto excelente chamado Apache Guacamole.

O nome não soa legal em uma visão corporativa, mas quando você instala e configura tudo isso apaga.

O Apache Guacamole é um gateway de desktop remoto sem cliente. Ele suporta protocolos padrão como VNC, RDP e SSH.

É sem cliente porque nenhum plug-in ou software cliente é necessário. Graças ao HTML5, uma vez que o Guacamole é instalado em um servidor, tudo que você precisa para acessar seus desktops é um navegador da web.

Veja o modelo instalei e que criei no Azure abaixo:

Como o cliente Guacamole é um aplicativo da Web HTML5, o uso de seus computadores não está vinculado a nenhum dispositivo ou local. Contanto que você tenha acesso a um navegador da Web, você terá acesso às suas máquinas.


Os desktops acessados ​​através do Guacamole não precisam existir fisicamente. Com o Guacamole e um sistema operacional de desktop hospedado na nuvem, você pode combinar a conveniência do Guacamole com a resiliência e a flexibilidade da computação em nuvem.

Fonte livre e aberta

O Apache Guacamole é e sempre será um software livre e de código aberto . Ele é licenciado sob a Licença Apache, Versão 2.0 , e é mantido ativamente por uma comunidade de desenvolvedores que usam o Guacamole para acessar seus próprios ambientes de desenvolvimento.

Construído em uma API bem documentada

O Apache Guacamole é construído com base em sua própria APIs, que são documentadas detalhadamente , incluindo tutoriais básicos e visões gerais conceituais no manual on – line . Essas APIs permitem que o Guacamole seja totalmente integrado a outras aplicações, sejam elas de código aberto ou proprietárias.

Aqui no Brasil ainda não é muito difundido.

Sua interface é bem simples


Totalmente baseado em HTML5

Esta é uma demonstração oficial do site de uso do Guacamole.

Esta é uma demonstração que fiz que esta neste link.
https://1drv.ms/v/s!An-dPolj_Ee_hdc1qLvHHCudRXaFmw

Este eu fiz no Azure e integrei com o Office 365 através do AIP para acesso condicional.
Veja a arquitetura do ambiente.

 

O guacd

O guacd é o coração do Guacamole que carrega dinamicamente o suporte para protocolos de área de trabalho remota (chamado de “plug-ins de cliente”) e os conecta a áreas de trabalho remotas com base nas instruções recebidas do aplicativo da web.

O guacd é um processo daemon que é instalado junto com o Guacamole e é executado em segundo plano, escutando as conexões TCP do aplicativo da web. O guacd também não entende nenhum protocolo de desktop remoto específico, mas implementa apenas o suficiente do protocolo Guacamole para determinar qual suporte de protocolo precisa ser carregado e quais argumentos devem ser passados para ele. Uma vez que um plugin do cliente é carregado, ele é executado independentemente do guacd e tem controle total da comunicação entre ele e o aplicativo da web até que o plugin do cliente seja encerrado.

O guacd e todos os plug-ins do cliente dependem de uma biblioteca comum, o libguac, que torna a comunicação via protocolo Guacamole mais fácil e um pouco mais abstrata.

Para instalar é bem simples.

Segue o processo de implantação oficial do Apache Guacamole Servidor em outro sistema Linux, que não seja o Ubuntu, recomendo usar a documentação oficial como referência de instalação.

Para fazer download do script de instalação no Ubuntu 16.04:

wget https://raw.githubusercontent.com/MysticRyuujin/guac-install/master/guac-install.sh

Conceder permissão de execução:

chmod +x guac-install.sh

Executar script:

sudo ./guac-install.sh

O basico para instalação após o acesso é acessar URL http://IP:8080/guacamole – com usuário e senha padrão guacadmin

001.PNG

No menu de connection você pode inserir o desktop ou servidor que você quer acessar.

002

É só inserir um nova conexão RDP, SSH ou VNC para que você possa acessar via browser e montar seu próprio ambiente.

0021

As configurações são bem simples para acesso via web.

Mas ele tem configurações para impressoras, armazenamento em resumo.

005

Este é o menu de preferencias.

AZURE.

Eu fiz uma instalação no Azure através do git.

Em resumo foi uma maquina para o Guacamole e outra maquina Windows 10 Enterprise para acessar via Browser.

006

 

12Veja a Matrix dentro da Matrix.

 

Veja neste links.

https://github.com/silvapfabio/azure-quickstart-templates

https://azure.microsoft.com/en-us/resources/templates/guacamole-rdp-vnc-gateway-existing-vnet/

Fiz algumas alterações no arquivo .json ao meu “paladar” claro, mas é bem simples.

Dando as honras para o Gabriel Nepomuceno que foi um orientador.

Embreve irei mostrar funcionando no RaspberriPy como um Thinclient para acesso via web com Guacamole e outros protocolos como Citrix e RDP.

Independente ele funciona em qualquer ambiente cloud como AWS e também local.

Eu espero que tenha gostado.

Até mais

 

 

Comando de Defesa Cibernética do Exército Brasileiro coordena treinamento contra ataques cibernéticos

SegInfo - Portal, Podcast e Evento sobre Segurança da Informação

No último dia 3 de julho, foi iniciado um treinamento simulado de proteção a ataques cibernéticos, denominado Exercício Guardião Cibernético, voltado aos setores financeiro e nuclear.  A atividade é realizada utilizando o Simulador de Operações Cibernéticas (Simulador Virtual – SIMOC). O treinamento foi finalizado no dia 6 de julho de 2018 e ocorreu no Forte Marechal Rondon, Setor Habitacional Taquari, Lago Norte, Brasília (DF).

O Simulador Virtual possui alguns eventos cibernéticos, tais como: uma grade de ações de agentes maliciosos nos setores financeiro, defesa e nuclear. Para tomar decisões sobre esses evento, cada grupo utilizou um software livre, o Request Tracker, configurado pelo ComDCiber (Comando De Defesa Cibernética). Dessa forma, os participantes foram treinados para responder aos crimes virtuais e as vulnerabilidades de seus sistemas.

“É virtualmente impossível proteger a todos os ativos de uma nação sem trabalho colaborativo. Temos que trabalhar incansavelmente para reduzir nossas vulnerabilidades, porque, nesse…

Ver o post original 184 mais palavras

Bloqueio de IMAP, POP e outros aplicativos herdados do Office 365 usando o acesso condicional do Active Directory do Azure

Olá pessoal

O acesso condicional do Active Directory do Azure tem um novo recurso, atualmente em pré-visualização, que permite aos clientes bloquear aplicativos e protocolos legados, como POP, IMAP ou qualquer coisa que não suporte autenticação moderna.

Veja um exemplo de como isso é útil para clientes do Office 365 . Nesse caso, o usuário Dave Bedrat é solicitado para autenticação de vários fatores ao acessar sua caixa de correio do Exchange Online usando o Outlook na Web. Esse aviso é causado por uma regra de acesso condicional no Azure AD que exige autenticação de vários fatores se o usuário estiver se conectando de um computador sem domínio.

No entanto, o uso do cliente de e-mail Thunderbird para se conectar à caixa de correio por meio do IMAP, que usa autenticação básica, é bem-sucedido.

Se o IMAP fosse o único problema, você poderia simplesmente desabilitar o protocolo IMAP em todas as suas caixas de correio do Exchange Online e usar um plano de caixa de correio para desabilitá-lo para qualquer nova caixa de correio . Mas isso não resolve o problema para outros cenários básicos de autenticação. É aí que o novo recurso de acesso condicional do Azure AD para bloquear aplicativos herdados é útil.

Crie uma política de acesso condicional para os usuários e aplicativos na nuvem que você deseja controlar. Na seção Aplicativos cliente da política, você pode selecionar Outros clientes (veja a captura de tela acima), que inclui aplicativos de autenticação legados e básicos que usam protocolos como POP e IMAP.

Você pode usar uma regra de acesso condicional para bloquear aplicativos herdados, mas não é possível usar nenhum dos outros controles, como a exigência de autenticação de vários fatores ou a exigência de dispositivos compatíveis. Todos esses controles dependem da autenticação moderna. Portanto, uma implementação prática desse novo recurso seria configurar uma regra de acesso condicional separada do Azure AD para bloquear todos os aplicativos herdados. Se necessário, você pode definir exceções nos usuários ou nos locais de rede que ainda podem usar protocolos herdados.

A Microsoft documentou esse recurso aqui, incluindo uma FAQ. É possível levar até 24 horas para que uma nova política de acesso condicional comece a bloquear clientes legados. Nas primeiras horas de implementação da política, ainda consegui me conectar com o cliente de e-mail Thunderbird. Quando tentou novamente 24 horas depois, as conexões IMAP estavam sendo negadas.

Espero ter ajudado vocês.

Até o próximo post.

randieri.com

Il blog di Cristian Randieri

TEC OFFICE PRODUTIVO

Tec Office Produtivo é um grupo de treinamentos, dicas e tutorias de informática sobre aplicativos utilizados em escritórios.

Escadas Especiais

Projetos, fabricação e instalação de escadas em geral

Jaqueline Ramos

Devops & Cloud

Blog do Douglas Romão

MVP Office Servers and Services | Especialista .NET/SharePoint

Thiago Lúcio - Desenvolvimento Web/ Web Designer

Blog de Thiago Lúcio Bittencourt. Web Designer e Desenvolvedor Front-end.

🔵Fábio FOL

Gestão Estratégica Corporativa de uma forma Executiva e Prática