Estatísticas do Blog

 

Atingimos mais de 75.000 visualizações obrigado comunidade

11o no hanking MVA mundial entre os MVPs

RD Gateway com Azure Multifactor Authentication Perguntas e respostas

RD Gateway com Azure Multifactor Authentication Perguntas e respostas

Artigo em parceria com Kristin Grifin

No artigo anterior http://www.andreluiz.adm.br/2014/07/usando-rd-gateway-com-azure-multifactor.html Nós montamos um ambiente com autenticação em 2 etapas usando RD Gateway com Azure MFA. Agora vamos analisar algumas questões sobre resolução de problemas nesse ambiente:

Quando uma conexão é bem-sucedida existem terá 16 entradas de log de eventos no log de eventos.  Ele está localizado em:

Event Viewer / Applications and Services Logs / Microsooft / Windows / TerminalServices-Gateway / Operational

Estas 16 entradas seguintes correspondem a uma conexão bem sucedida:

1. User met CAP policy requirements and can connect to RD Gateway

2. User met RAP policy requirements and can connect to RD Connection Broker

3. The user connected to RD Connection Broker using HTTP

4. The user connected to RD Connection Broker using UDP

5. The user connected to RD Connection Broker using UDP Proxy

6. The user connected to RD Connection Broker using UDP (second channel)

7. The user connected to RD Connection Broker using UDP Proxy (second channel)

8. The user disconnected to RD Connection Broker using HTTP

9. The user disconnected to RD Connection Broker using UDP

10. The user disconnected to RD Connection Broker using UDP

11. User met RAP policy requirements and can connect to RD Session Host

12. The user connected to RD Session Host using HTTP

13. The user connected to RD Session Host using UDP

14. The user connected to RD Session Host using UDP Proxy

15. The user connected to RD Session Host using UDP (second channel)

16. The user connected to RD Session Host using UDP Proxy (second channel)

O que encontramos foi que, se você tem um problema com políticas mal configuradas no NPS, você provavelmente obterá um erro no log de eventos no primeiro passo. O log de eventos vai dizer que não encontrou os requisitos CAP, mesmo se você tiver feito.

Se você topar com isto, verifique suas políticas. Se você tem certeza que estão corretas e, em seguida, verifique se seu CAP funciona se você usar um NPS LOCAL. Se funcionar recomendamos que você refaça suas políticas. Remova as diretivas que você tiver editado ou criado no NPS. Então refaça o apontamento do CAP no Gerenciador de Gateway RD (Fazendo isso irá recriar os parâmetros exigidos no NPS, e você pode recriar e Editar Diretivas a partir de lá.

Perguntas e Respostas

P: Existem outras maneiras para configurar a comunicação no NPS ?

R: Sim, existem várias maneiras de configurar a comunicação no NPS. Por exemplo:

• Deixar o  RD Gateway com um NPS local em vez de “redirecioná-lo” para fora.

• Adicionando dois clientes RADIUS no NPS, uma para o servidor Gateway RD e outro para o servidor do MFA.

• Configurando duas diretivas de solicitação de conexão para lidar com a comunicação do NPS para servidor MFA (um por nome amigável e o outro por endereço IP).

• Configurando duas diretivas de solicitação de conexão para lidar com a comunicação do servidor MFA para o  NPS (um por nome amigável e o outro por endereço IP).

Mas esta configuração acabou por ser muito sensível. Tivemos um problema em que tivemos que refazer as políticas no NPS e começar de novo.

Vamos percorrer outros cenários de configuração possível no nosso próximo artigo, quando falaremos de Gateway de área de trabalho remota e cenários de alta disponibilidade do Azure AMF.

P: Por que precisamos  alterar o tempo limite para o grupo de servidores remotos RADIUS no NPS de 5 segundos para 30-60 segundos?

R: Porque leva tempo para executar a autenticação primária com o RD Gateway e depois para executar a 2º autenticação antes de retornar uma resposta ao Gateway. Por isso os limites de precisam ser aumentados para 60 segundos.

P: como o Azure sabe como me cobrar quando implanto o Azure AMF on premisse ??
R: O servidor do MFA informa o número de usuários habilitados para o serviço de nuvem do MFA AMF, que relata o faturamento para o sistema de comércio do Azure.

P: Qual parte do Azure MFA se encarrega de enviar as mensagens de texto para telefones celulares?

R: todas as autenticações (2º fator) são executadas através do serviço de nuvem do MFA. Esse serviço executa as chamadas telefónicas, mensagens de texto e notificações “push” (app móvel).  Ao usar o servidor MFA on premisse  o servidor solicita a autenticação do serviço na nuvem.

P: quando recebo uma mensagem TXT do Azure MFA, aparentemente é originada de um número aleatório. Como saber se é legítimo? Existe uma maneira de identificar a or este que não seja usando o nome amigável na configuração do MFA?

R: o Azure utiliza vários provedores SMS, cada um com um pool de números a partir dos quais quais as mensagens SMS são enviadas. As informações são que a Microsoft trará em breve um código curto de SMS, e então a maior parte do tráfego SMS nos EUA será enviada a partir desse código Você também pode personalizar a mensagem SMS que é enviada em Company Settings->SMS.

P: como um servidor Azure MFA comunica-se com os serviços de nuvem Azure MFA?

R: o servidor MFA comunica-se ao serviço de nuvem pela porta 443 de saída. A Figura 1 mostra uma arquitetura de alto nível na qual mostra o servidor MFA local, Azure AD e o serviço de nuvem do MFA.

Figura 21: MFA Arquitetura de Alto nível.

Usando RD Gateway com Azure Multifactor Authentication

Usando RD Gateway com Azure Multifactor Authentication

Artigo em parceria com Kristin Grifin

Vamos examinar o cenário de um cliente que usa RD Gateway para permitir que os usuários acessem a estrutura RDS de fora da rede corporativa. Cerca de 1000 + usuários. Os usuários acessam o ambiente RDS através de dispositivos a maioria não gerenciados incluindo diferentes tipos de Tablets. A preocupação é a possibilidade desses dispositivos não gerenciados serem roubados ou extraviados oferecendo um potencial risco a acessos não autorizados ao ambiente RDS corporativo.

Pesquisando soluções para este problema (e tendo em conta a amplitude dos tipos de clientes não gerenciados que precisam ser suportados) temos uma potencial solução usando Multifactor Authentication ou autenticação multifator juntamente com RD Gateway para criar uma seqüência de autenticação que exige duas formas de identificação para acessar o ambiente RDS:

1. algo que somente o usuário sabe como por exemplo sua combinação de nome de usuário/senha

2. uma senha de uso único

Se você já usou autenticação em 2 etapas no Hotmail ou Gmail vai ficar claro do que estamos falando. Existem informações complementares nos artigos em inglês:

“The increasing need for two factor authentication”, do MVP Orin Thomas, contribuinte do site Windows IT Pro .

Nós exploramos algumas ofertas diferentes de autenticação multifator oferecidas no Microsoft Azure (Azure MFA) por três razões:

1) Preço: É excelente em comparação com algumas outras soluções concorrentes.

2) 2ª Camada : o Azure MFA pode completar a segunda camada de autenticação via telefone celular ou dispositivo inteligente (um dispositivo que a maioria das pessoas já têm) em vez de exigir um token em hardware.

3) Uso de PIN : O Azure MFA também podem ser definido para exigir um PIN exclusivo que somente o usuário sabe. Não importa qual dispositivo é usado para acessar a implantação da RDS, o usuário precisará mais do que suas credenciais de usuário (que são geralmente armazenados em cache) para entrar.

Um login via RD Gateway com Azure MFA seria assim:

1. o usuário faz logon no RD Web Access e da um duplo clique em RemoteApp (ou conexão de área de trabalho remota )

2. As credenciais de logon do usuário para o website são usadas para validar o usuário (Web SSO ), então não há necessidade de fornecer novamente.

3. O usuário então recebe uma mensagem de texto SMS em seu device ou smartphone. O SMS fornece um código de 6 dígitos numéricos que chamamos de senha de uso único (one-time password).

4. O usuário responde à mensagem de texto introduzindo o código de 6 dígitos e adicionando seu exclusivo PIN pré-definido para o final da sequência. Detalhe que o Azure MFA inclui a opção de exigir que o usuário saiba um PIN exclusivo predefinido.

5. O usuário é autenticado, e abre o RemoteApp (ou conexão de área de trabalho remota).

Nota: A autenticação de SMS não é a única maneira na qual o Azure MFA pode se comunicar com os usuários. Em um próximo artigo abordaremos as várias opções de autenticação como por exemplo autenticação por telefone e também usando um App em um smartphone.

Cenário de Testes: RD Gateway / solução Azure MFA. Primeiro, nós implementamos Azure AMF com um ambiente de RDS com apenas um servidor de Gateway RD (ambiente sem alta disponibilidade).

Depois implementamos em vários servidores RD Gateway em uma configuração de alta disponibilidade. As configurações em ambos funcionam bem, mas a instalação é diferente para estes cenários. Neste artigo nós abordaremos o cenário de APENAS UM Gateway. Em nossos próximos artigos iremos explorar configurações com alta disponibilidade.

Como o Azure MFA funciona com o RD Gateway

Vamos olhar mais de perto como funciona o MFA com RD Gateway para fornecer autenticação em 2 etapas. Em primeiro lugar, precisamos entender como o Gateway funciona para autenticar usuários.

RD Gateway e o NPS

RD Gateway usa o NPS (Network Policy Services), um recurso do Windows Server 2012 para manter as diretivas de rede (na interface do Gerenciador de Gateway de RD estas políticas são chamadas de RD Connection Access policies (diretivas de acesso de conexão de área de trabalho remota, ou RD CAPs). Em geral, RD Gateway (e NPS) trabalham juntos para autenticar um usuário como podemos ver abaixo:

1. As credenciais de logon do usuário é enviado para o Gateway.

2. NPS verifica as credenciais contra suas políticas de rede para ver se o usuário tem permissão para acessar o Gateway.

Se as credenciais forem permitidas pelo NPS, então:

3. RD Gateway verifica as credenciais do usuário contra suas políticas de autorização de recurso Resource Authorization Policies (RD RAPs que estão alojados em um arquivo XML no servidor

Adicionando o Azure MFA

No cenário em duas etapas o processo seria esse:

1. as credenciais de logon do usuário é enviado para o Gateway.

2. NPS verifica as credenciais contra suas políticas de rede para ver se o usuário tem permissão para acessar o Gateway RD).

Se as credenciais forem permitidas pelo NPS, então:

3. a solicitação de logon é enviada ao servidor MFA

4. MFA Server se comunica com o usuário final (por texto SMS, chamada telefónica, app móvel ou token) pedindo para responder de volta a sequência de letra/número adicionando seu PIN exclusivo ao final, no caso do ambiente ser configurado para exigir um PIN pessoal.

5. MFA recebe a resposta do usuário, verifica a resposta. Se a resposta estiver correta, então o MFA envia uma resposta de "aceitar" para o Gateway.

Se o RD Gateway receber uma resposta de aceite do MFA então:

6. RD Gateway verifica as credenciais do usuário contra suas RD RAPs para ver se o usuário tem permissão para acesso solicitado e permite ou então nega a conexão.

Incluindo o Azure MFA na sequência de autenticação

Quando você tiver um servidor RD Gateway RD em execução junto com um serviço NPS (a configuração padrão), você tem que ter alguma maneira enviar para o servidor MFA a sequência de comunicação. Como mostrado na Figura 1. Para fazer isso, vamos “enganar” o RD Gateway – vamos configurar o Gateway para usar um servidor NPS centralizado, mas apontando para o servidor MFA na nuvem. A comunicação funciona assim:

Figura 1: “Enganamos” o RD Gateway para ele “achar” que está usando um NPS centralizado.

1. RDG recebe a requisição de login do usuário

2. RD Gateway encaminha uma requisição RADIUS para o servidor MFA através do NPS.

3. O servidor MFA encaminha para o NPS para validação de credenciais.

4. RD Gateway valida a credencial do usuário e faz um check com as Diretivas de autorização de conexão da Área de Trabalho Remota (RD CAP).

5. NPS envia um ACCEPT ou REJECT para o servidor MFA.

6. No caso de ACCEPT, MFA realiza  a sequência de autenticação em duas etapas com o usuário (através de telefonema, texto ou app móvel). Se o usuário retorna a “contra-senha” ele envia um ACCEPT para o RD Gateway.

7. Finalmente o RD Gateway irá verificar as Diretivas de autorização de recursos da Área de Trabalho Remota (RD RAPs) e também permitir ou negar a conexão.

Implementando um servidor de AMF Azure On Premise com RD Gateway

A solução Azure MFA pode ser usado em um cenário de nuvem mas também em aplicações “on premise” aonde focamos aqui. Vamos mostrar como configurar um servidor “on premise” Azure MFA para prover autenticação em 2 etapas numa implementação RD gateway também “on premisse”.

Primeiro algumas configurações que precisamos:

· Um ambiente de trabalho RDS, incluindo RD Gateway (executando o NPS localmente)

· Um site RD Web Access publicado RemoteApps ou desktops.

· Uma conta de Azure configurada com informações defaturamento. Este artigo pressupõe que já configurou isso. Se você ainda não tem veja em: https://account.windowsazure.com/SignUp.

· Um servidor no Domínio (físico ou VM) designado para ser o servidor Azure MFA local

· Um telefone celular para responder aos pedidos de SMS do Azure MFA.

· Um cliente de teste (um PC ou um tablet, por exemplo) de preferência com Internet Explorer

Agora caminharemos através desses principais passos de instalação:

1. Instalar os pré-requisitos no servidor designado para o Azure MFA 

2. Criar um provedor de autenticação em duas etapas no Azure (MFA)

3. Baixar e instalar o software on premise do servidor MFA.

4. Configurar o servidor MFA, RD Gateway RD e NPS

5. 5. configurar um usuário de teste no servidor Azure MFA e fazer alguns testes

Pré-Requisitos

Uma premissa para instalação do servidor MFA Azure é o .NET Framework 3.5 Instale como mostrado (mostrado na Figura 2).

Figura 2: Instalação do.NET Framework 3.5

Criar um provedor de autenticação em duas etapas no Azure (MFA

Siga os seguintes passos :

1. Do servidor MFA, entre no portal Microsoft Azure Management: https://manage.windowsazure.com/.

2. Escolha o botão “+New” ou “Novo” na versão em Ptb (Figura 3)

Figure 3: Criação de um provedor MFA no Azure

3. A Figura 4 mostra cinco colunas do qual você irá selecionar propriedades do novo provedor MFA.

a. Selecione serviços de Aplicativos

b. Selecione Active Directory

c. Selecione o provedor de autenticação Multifator na terceira

d. Clique no botão criação rápida.

e. Preencha o formulário que aparece.

Observação:

· Na opção da cobrança por usuário você paga uma taxa fixa para cada usuário cadastrado e tem o uso ilimitado.

· Na opção cobrança por Autenticação nesse caso você paga por cada 10 autenticações com usuários ilimitados

Ambos podem ser usados nesse caso. É preciso um estudo para escolha do melhor modelo porque isso não pode ser mudado posteriormente

As opções do diretório permitem que você conecte este provedor MFA com o Active Directory do Azure. Como nessa implementação usamos um servidor MFA on premisse que é membro do domínio deixe a opção definida como “Do not link a directory” ou “não vincular um diretório”.

Figure 4: Configurando o provedor MFA .

4. Na página principal voce pode ver seu provedor MFA criado selecione-o e clique no ícone “manage” no final da página como mostra a Figura 5.

Figura 5: Selecionando o Provedor criado e clicando no botão de gerenciamento.

Download e Instalação do Azure MFA Server Software On Premise

O portal de gerenciamento do Azure Multifactor será aberto como mostra a Figura 6.

Figure 6: Portal de gerenciamento

Siga estas etapas para baixar e instalar o software Azure MFA.

1. Clique no botão de DOWNLOADS. Você obterá a tela mostrada na Figura 7.

Figure 7: Baixe o software e gere as credenciais de ativação.

2. Salve e execute o arquivo.

3. Cique no botão gerar novas credenciais de ativação. As credenciais de ativação só servem para 10 minutos. Insira as credenciais de ativação na tela ativar da instalação mostrada na Figura 8. Se suas credenciais expirarem antes de você digitá-los, clique no botão gerar novas credenciais de ativação novamente para obter um novo conjunto.

Figure 8: Especifique as credenciais.

Dica: Para isso funcionar você precisa uma saída pela porta 443. Em cenários onde o servidor MFA usa proxy, execute o seguinte comando:

netsh WinHTTP Set Proxy proxy-server="FQDN_of_Proxy_Server:8080"

Caso contrário, você pode executar no seguinte erro mostrado na Figura 9:

Figura 9: Esse erro indica que o serviço MFA não foi localizado.

Configurando o RD Gateway Server, NPS e o MFA Server

Agora precisamos configurar o RD Gateway, NPS, e o MFA para se comunicarem.

RD Gateway

Vamos “enganar” o RD Gateway e configura-lo para usar o “Central RD CAP”, mas vamos apontar para o servidor MFA server:

1. Abra o RD Gateway Manager, clique o lado direito no nome do servidor e abra “Properties”.

2. Selecione a guia “RD CAP Store” (Figura 10).

3. Selecione “Central server running NPS”.

4. Forneça o nome ou IP do servidor MFA e clique “Add”.

5. Entre uma senha e clique em OK.

Figura 10: Configurando o RD Gateway para usar o “central NPS”

Fazendo o NPS e o MFA se comunicarem

Ambos usam um cliente e um servidor RADIUS para se comunicarem. Então configuramos um cliente e um servidor RADIUS (Figura 11) em cada servidor:

· No servidor Gateway RD/NPS configuramos duas diretivas de solicitação de conexão:

a) A primeira enviará comunicação ao servidor do MFA através de um grupo de servidores RADIUS remotos (Remote RADIUS Server Group)

b) A segunda recebe comunicação do MFA server via cliente RADIUS.

· No servidor MFA:

a) Um cliente RADIUS para receber a comunicação do NPS server.

b) Um destino A RADIUS para mandar a comunicação para o servidor NPS.

Figura 11: NPS e o servidor MFA usam cliente e servidor RADIUS para comunicação.

Configurando NPS

Umas das coisas que precisamos fazer é evitar o Time Out do NPS enquanto não é completada a autenticação MFA (Figure 12):

1. Em NPS, clicar “RADIUS Clients and Servers” e “Remote RADIUS Server Groups”.

2. Quando configuramos o Gateway RD é criada uma entrada “TS GATEWAY SERVER GROUP”. Clique com o lado direito e selecione “Properties”.

3. Selecione o servidor MFA e Edit.

4. Selecione a guia “Load Balancing”.

5. Mude o parâmetro “Number of seconds without response before request is considered dropped” e “Number of seconds between requests when server is identified as unavailable” para 60 segundos.

Figure 12: Ajustando os parâmetros do RADIUS server no NPS.

Você precisa configurar o NPS para receber as autenticações RADIUS do servidor MFA:

1. Duplo clique em “RADIUS Clients” e “New”.

2. Adicione um nome amigável e um endereço do servidor MFA Figura 13.

3. Adicione a senha e OK.

Figura 13: Criando um cliente RADIUS no NPS.

Em seguida, configure as duas diretivas de solicitação de conexão no NPS - um para encaminhar as solicitações para o grupo de servidores RADIUS (que é definida para encaminhar ao servidor MFA), e o outro para receber solicitações do servidor MFA (para serem manipulados localmente).

A maneira mais fácil de fazer isso é usar a diretiva existente que foi criada quando você criou uma RD CAP. Siga estes passos:

1. Na seção de diretiras em NPS em Connection Request Policies. Veremos a diretiva criada chamada “TS GATEWAY AUTHORIZATION POLICY”.

2. Lado direito do mouse e selecione “Duplicate Policy”.

Note: Para facilitar renomeamos as diretivas :

· De “TS GATEWAY AUTHORIZATION POLICY” para “To MFA”

· De “Copy of TS GATEWAY AUTHORIZATION POLICY” para “From MFA”

3. Duplo clique na nova diretiva duplicada e selecione a guia “Conditions”.

4. Adicione um nome amigável como na Figura 14. Use o mesmo nome amigável que configuramos para o cliente RADIUS anteriormente.

Figura 14: Adicionando um “Client Friendly Name” para “TS GATEWAY AUTHORIZATION POLICY”.

5. Selecione a guia “Settings” e mude o parâmetro “Authentication” para “Authenticate requests on this server” Figura 15.

Figura 15: Mudando a diretiva para autenticação local.

6. Selecione “Accounting” e certifique-se que a check box “Forward accounting requests…” está desmarcada. Então clique em OK. A Interface de diretivas deve ficar como na Figura 16.

Figura 16: Visão das configurações de diretivas “From MFA”

7. Certifique-se de que a diretiva (cópia) esteja em primeiro lugar antes da diretiva original.

8. Apesar de não mexermos na diretiva original é prudente verificar para confirmar os parâmetros conforme Figura 17.

Figura 17: A diretiva mantém os parâmetros originais.

Configurando o servidor MFA

Agora precisamos configurar o cliente e o destino RADIUS do servidor MFA. Essas são as etapas:

1. no servidor MFA abrir o servidor de autenticação Multifator e clique no ícone “RADIUS Authentication”.

2. Verifique se a caixa de seleção autenticação está ativada.

3. Na guia “Clients” clique no botão “ADD” (Adicionar)

4. Adicionar o IP do servidor Gateway de RD / NPS e a chave compartilhada correspondente ao adicionado à configuração do “Central CAP Store”.

5. Clique na guia “Target” e escolha “RADIUS servers”.

6. clique “ADD” (Adicionar) e digite o endereço IP, chave compartilhada e portas do servidor NPS. A chave compartilhada deve corresponder ao configurados para o cliente RADIUS no servidor NPS.

Testando

Para adicionar um usuário de teste:

1. No servidor MFA server abra o Multi-Factor Authentication Server e selecione o ícone “Users”.

2. Clique no botão “Import Users from Active Directory”.

3. Selecione a conta que quer importar e clique “Import”.

4. Duplo clique na conta criada (Figura 18).

Figure 20: Configurando os parâmetros do usuário de teste.

Na guia “General”:

· Código do país (country code) e o telefone (phone number) do celular que vai ser usado para teste.

· Selecione a opção “Text Message”. Então selecione “OTP + PIN”.

· Entre com um PIN ou clique em “Generate” para gerar um novo código.

5. Selecione “Enabled” e “Apply” para salvar as configurações.

Agora as ações para o teste do cenário:

1. A partir do dispositivo cliente, abra o Internet Explorer e navegue até o site de acesso RD Web e faça o login.

2. Abra um aplicativo remoto ou área de trabalho remota. A caixa de diálogo mostrada na Figura 19 permanecerá aberta até que tenha sido concluída a autenticação em duas etapas:

Figura 19: Abrindo sessão RDP

3. Será enviada uma mensagem de texto (Figure 20).

Figure 20: Mensagem de texto do MFA server.

4. Respondemos ao texto digitando uma a senha e adicionando o PIN no final da resposta.

5. Se estiver correto a sessão abrirá.

Outros artigos úteis

· Getting started with Windows Azure Multi-Factor Authentication

· RADIUS Authentication

· Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS

Sumário

Esta configuração é exemplo – um único Gateway de RD e um único servidor MFA “on premisse” ótimo para testar o conceito. Nos próximos artigos mostraremos como configurar uma solução altamente disponível, incluindo vários Gateways RD, vários servidores MFA. Também exploraremos vários métodos de autenticação como telefonema e opções de aplicativo móvel. Verifique www.RDSGurus.com e www.andreluiz.adm.br para atualizações.

Webcast Junho

clique aqui e faça sua inscrição

Inscrição: http://www.qticertificacaoms.eventize.com.br/

Próxima Palestra Online - Quintas de TI dia 26/06

http://www.windowsstudygroup.com.br/proximos-eventos/quintas-da-ti-2014

Certificações Microsoft e o mercado de trabalho

Quinta-Feira, 26 de junho 2014, 23:00 - 00:00 hrs 

Palestrantes: Alexandro Prado, Profº André Luiz, Paulo Sant'anna

Tecnologias: Certificações Microsoft

Inscrição: http://www.qticertificacaoms.eventize.com.br/

Infra Day–Palestras Gratuitas no INFNET dia 17/05/2014

 

Dia 17/05/14    Instituição: Infnet
Rua São José, 90 - 2º andar, Centro, Rio de Janeiro - RJ ( ver mapa )

Grátis

PROGRAMAÇÃO

08h30 - Credenciamento

09h00 - Apresentação do Evento

09h20 - Overview do Windows 8.1 e seus Recursos Corporativos - com Carlos Finet e Carlos Lauff

Apresentação aprofundada do novo sistema operacional da Microsoft, demonstrando alguns de seus recursos corporativos em ambientes com o Windows Server 2012 R2.

10h40 - Migrando o DC para Windows Server 2012 R2 - com Paulo Roberto Sant'anna

Aprenda na prática como migrar seu Controlador de Domínio para Windows Server 2012 R2.

11h40 - Almoço

13h00 - Conceitos de Cloud Computing - com Danilo Monteiro e André Mattos

Venha conosco conhecer os principais conceitos de computação em nuvem juntamente com a plataforma Microsoft Azure.

13h30 - Conhecendo o Microsoft Azure - com André Mattos e Carlos Lauff

Aprenda sobre Cloud Computing com o poder da plataforma Microsoft Azure.

14h20 - Por dentro do System Center 2012 R2 - com Alexandro Pradro e Paulo Roberto Sant'anna

Apresentação das Ferramentas da Família System Center de uma maneira mais agradável e didática. Aprenda as  principais funcionalidades e uso desta família robusta e confiável.

15h15 - Break

15h30 - Microsoft Azure e System Center com o Windows Server 2012 R2 - com Alexandro Pradro e Carlos Lauff

Conheça na prática o cenário onde utilizamos o Windows Server 2012 R2 com System Center e o Microsoft Azure.

16h30 - Encerramento

PALESTRANTES

Alexandro Prado

Arquiteto de Soluções Microsoft. Especializado em ambientes de virtualização, Active Diretory e System Center. Líder do Grupo MS-InfraRio. Microsoft MVP Windows Expert-IT Pro. MCT, MCSE, MCSA, MCITP, MCDST, MCTS, MCP, MTA, VCP.

André Luiz Mattos Oliveira

Professor André Luiz é graduado em Análise de Sistemas e MBA em Gerência de Projetos. Certificado PMP pelo PMI , Itil (f) pela Exim, MCITP , MCSE MCSA MCTS MCT  pela Microsoft. Atualmente  MVP Microsoft a 7 anos. 19 anos de mercado e atualmente atuando como gerente de projetos em Infra Microsoft e Vmware e Desenvolvimento em Sharepoint e professor universitário.

Carlos Finet

Consultor de TI, Fundador do portal CooperaTI, certificado em MCT, MCDST, MCSA, MCSE, MCTS, MCITP-SA com foco em infraestrutura com 14 anos de experiencia na area de T.I Integrante do programa MTAC: Microsoft Technical Audience Contributor e MCT (Microsoft Certified Trainer).

Carlos Lauff

Consultor de TI, fundador do Portal CooperaTI,  especialista em tecnologias Microsoft com foco nas áreas de infraestrutra, Active Directory e virtualização. Possui as certificações MS, MCTS, MCITP, MCSA e MCSE Windows Server 2012 Server Infrastructure - Charter Member. Integrante do programa MTAC: Microsoft Technical Audience Contributor e MCT (Microsoft Certified Trainer).

Danilo Monteiro

Profissional de Tecnologia da Informação a 10 anos com experiência em soluções Microsoft atua como Coordenador de TI. Graduando em Gestão da TI pelo Instituto Infnet. Possui Certificação Microsoft em Windows Server e faz parte do time dos Microsoft Student Partners.

Paulo Roberto Sant´anna Cardoso

Profissional de TI com 14 anos de experiência com especialização e foco em infraestrutura, suporte, consultoria, segurança da informação, governança e treinamentos. Eleito Microsoft Value Professional (MVP) na categoria Windows Expert-IT Pro. Possui as certificações SECURITY+, ISO 27002, COBIT, ITIL V3, GREEN IT CITIZEN, MCT, MCSE,  MCSA, MCTS, MCP, MTA, CCA, CCSA, ACA.

Podcast sobre o Fim do Suporte ao Windows XP

Um podcast discutindo o Fim do suporte ao Windows xp com os amigos  Carlos Lauff , Paulo Santana e Alexandro Prado

 

http://paulosantanna.com/2014/02/15/podcast-22-sobre-o-fim-do-suporte-ao-windows-xp/

Como funciona o Multi Point Server

Como funciona o Microsoft  Multi Point Server 

O conceito do Windows Multipoint Server é fácil. Ele utiliza a força excedente de um computador e a compartilha com vários usuários finais. Essa é a conhecida "computação compartilhada" também chamada às vezes de "áreas de trabalho virtuais"; isso é possível devido aos avanças na tecnologia. No passado, os PCs eram desenvolvidos de forma simples e usados individualmente. Os servidores tinham potência suficiente para lidar com as necessidades de computação de vários usuários em uma organização, mas precisavam de profissionais de TI habilidosos para sua execução. Isso está mudando.

Hoje em dia, os PCs são tão poderosos que, apesar dos gráficos e vídeos de qualidade que possuem, ainda têm força excedente. O Windows MultiPoint Server aproveita a força excedente de um PC e a transforma em um servidor capaz de acionar várias sessões de uma vez. É o sistema operacional do software que executa a “sessão” do Windows 7 personalizada de cada usuário final no computador host. Em seguida, ele oferece uma experiência de “área de trabalho virtual” por meio dos dispositivos de acesso a cada usuário que está trabalhando em seu próprio monitor, teclado e mouse. É fácil de instalar e gerenciar.

Host

O computador host executa o software Windows MultiPoint Server e habilita a experiência do professor e dos estudantes. O WMS requer um processador de 64 bits, com força de processamento (CPU) e capacidade de memória suficientes para atender às demandas de desempenho de inúmeros usuários e aplicativos usados simultaneamente. Os requisitos do sistema dependerão dos programas e dos recursos instalados, do número de usuários e de como o sistema será usado. Por exemplo, uma configuração com 5 ou 6 estudantes usando aplicativos de produtividade como o Office 2010 exigiria menos força de processamento e RAM do que uma com 15 a 20 estações e uso intenso de multimídia. Para ver o hardware recomendado, clique aqui ou consulte o Guia de planejamento do Windows MultiPoint Server .

Dispositivos de acesso

Os dispositivos de acesso conectam o computador host às estações individuais, permitindo que várias pessoas compartilhem o mesmo computador, embora tenham uma experiência de computação própria e independente. Algumas vezes conhecidos como "thin clients" ou "clientes zero", esses dispositivos de acesso permitem a conexão física, além do fluxo eficiente dos dados e vídeo para vários monitores. Há três formas importantes de se conectar: Conexão direta (com uma placa PCI ou de vídeo na parte posterior do computador host), conexão USB (dispositivo de acesso conectado ao computador host via cabo USB) ou conexão LAN (estações do usuário final conectadas via um thin client à rede, e não conectadas fisicamente ao computador host). Você pode combinar esses métodos e organizar as estações de usuário da melhor forma para o espaço e disposição da sua sala de aula. Clique aqui para ver uma variedade de soluções oferecidas pelos parceiros.

Estações de usuário

O professor e os estudantes têm suas próprias estações, com um monitor, teclado e mouse exclusivos. Os professores orquestram e monitoram a experiência de aprendizagem em sua estação. No modo de exibição do professor no console de gerenciamento do MultiPoint, é possível ver miniaturas das áreas de trabalho dos estudantes, permitir o acesso a certos sites e enviar mensagens individuais aos estudantes ou à turma inteira. Os professores podem também usar o controle remoto para ajudar o estudante que precisar.

Os estudantes aprendem de forma eficiente e produtiva em suas próprias estações. Eles exibem conteúdo e compartilham arquivos sempre que precisam, trabalham e salvam arquivos em suas pastas privadas ou em unidades USB e têm uma experiência de aprendizagem aprimorada. Um só monitor pode ser usado por dois estudantes com uma "tela dividida" para permitir a colaboração lado a lado. Alguns monitores avançados também vêm com dispositivos de acesso para economizar espaço e reduzir o número de dispositivos para cada estação de trabalho.

Você também pode reutilizar os monitores, teclados e mouses que já tem.

Veja mais em http://www.microsoft.com/brasil/windows/multipoint/howitworks.aspx

Community Zone 2012 Sede Da Microsoft SP - Set 2012

Community Zone 2012 Sede Da Microsoft SP - Set 2012

Mais uma vez um excelente evento com a Comunidade e os MVPs

Workshop System Center em 05/06/2013

Workshop na NSI com Alexandro Prado e Hygor  System Center 2012 05/06/2013

Falamos um pouco de RDS na nuvem ótimo cenário.

Com distribuição de Brindes e o Thiago foi o sortudo

Estastíticas do Blog - Numeros da comunidade

Estastíticas do Blog - Numeros da comunidade

Publicando Aplicações no RDS Windows Server 2012

Publicando Aplicações no RDS 2012
Continuando a fazer o deploy dos serviços RDS usando como referência o Blog do time da Microsoft
http://blogs.msdn.com/b/rds/archive/2012/08/06/remotefx-adaptive-graphics-in-windows-server-2012-and-windows-8.aspx
Vamos agora criar coleções e publicar aplicações que serão acessadas via RDS.
1. Em Server Manager, opção  Remote Desktop Services e  Collections

2. Em Collection Section, opção Tasks e  Create Session Collection

3. Next

4. Digite o nome da coleção ( Collection ) e Next

5. Especifique o servidor  RD Session Host e Next. (previamente criados)

6. Especifique o “User Groups” e Next

7. Aponte o disco de perfil de usuáro “User Profile Disk’ com o caminho  UNC se estiver usando esse recurso e Next

8. Confirme e clique em Create

Após alguns minutos o processo de criação estará completo. A partir desse momento você poderá publicar aplicativos remotos
1. selecione  RemoteApp em Collections e Publish Remote App Programs

2. Selecione os programas que serão publicados (Remote APP Programs)  e  Next

3. Confirme e clique em  Publish

4. na tela RemoteApp Programs, os aplicativos remotos estarão listados .

5. Podemos atribuir aplicatos remotos para usuários específico. Botão do Lado direito em cima do aplicativo e Properties.


6. Os aplicativos podem ser publicados em pastas virtuais ou virtual folders.
7. Expanda User Assignment  e selecione Only specified users and groups

Pronto, aplicativos publicados. Mas como acessá-los?
Temos 2 métodos suportados para acessar os aplicativos remotos (RemoteApps)

1. Web Access
2. WebFeed ( Remote App Desktop Connections)

Web Access
Esse método (Web Access) pode ser utilizado para acessar (launch) RemoteApps ou sessões Desktos.

WebFeed (RemoteApp e conexões Desktop )
Para configuração na máquina CLIENTE :
1. Control Panel ,  Remote App e Desktop Connections

2. Digite a Url e Next. Ex: nome do servidor/rdweb/Feed/webfeed.aspx

3.Finish


4. Pronto veremos os atalhos na tela inicial do Windows 8.

Veja mais na academia virtual de 2012 (VDI)
http://www.microsoftvirtualacademy.com/tracks/visao-geral-do-windows-server-2012