segunda-feira, 25 de agosto de 2014

Uma visão geral do Active Directory ou Domain Services (DS)

 

O serviço de diretórios é um dos principais serviços e deve implementado numa rede corporativa visando organização e facilidade de gerenciamento. Nesse artigo termos uma visão geral do Active Directory Domain Service , o serviço de diretório ativo do Windows 2008 Server. Esse artigo dará uma visão geral e nos próximos nos aprofundaremos na sua arquitetura e práticas de implementação  Descreveremos o que é o Active Directory e porque usá-lo. Abordaremos sua estrutura, como a sua divisão em domínios, árvores, florestas e unidades organizacionais. Também mostraremos passo a passo uma configuração de um controlador de domínio para um novo domínio, partindo da premissa de que toda a estrutura de rede já está em funcionamento e, o mais importante, o devido planejamento foi feito.

Usaremos como base para esse artigo o Windows 2008, porém os conceitos podem ser usados em versões anteriores salvo funções específicas do sistema operacional.

Gostaríamos de ressaltar que as principais atividades na implementação do Active Directory são de planejamento. Um planejamento correto do Active Directory vai dar escalabilidade , ou seja , vai permitir o crescimento da empresa sem comprometer os investimentos já realizados. Repetiremos essa palavra muitas vezes durante o artigo pois acreditamos que o PLANEJAMENTO é a principal etapa da implementação do Active Directory nas organizações.

Esperamos que esse artigo ajude a entender e dar um início aos estudos de viabilidade da implementação do Active Directory na sua organização.

O que é Active Directory?

Por definição o Active Directory Domain Services é o serviço de diretórios do Windows 2008. Nas versões anteriores chamávamos de Active Directory ou simplesmente AD. No Windows 2008 o Active Directory foi dividido em vários serviços , que são :

•Active Directory Domain Services

•Active Directory Lightweight Directory Services

•Active Directory Certificate Services

•Active Directory Rights Management Services

•Active Directory Federation Services

Um deles , o de diretório ou Domain Services , é o do qual iremos tratar nessa série de artigos, chamado AD-DS.

O AD-DS armazena os recursos da rede como usuários, grupos, computadores, arquivos, impressoras e aplicativos, os quais chamaremos de OBJETOS. Além disso fornece os serviços que tornam essas informações disponíveis como vemos na Figura 1.

clip_image004

Figura 1. O Active Directory armazena recursos da rede.

O AD-DS usa uma estrutura hierárquica para armazenar informações. Usuários, impressoras e demais recursos, os quais são armazenados como Objetos conforme citamos anteriormente.

Lembrando a estrutura de um banco de dados os objetos tem atributos como por exemplo o nome de um usuário ou seu email. A localização de uma impressora por exemplo é um exemplo de atributo de objeto. Aproveitando, damos a dica de por exemplo preenchermos os campos de observação no cadastro de impressoras , pois esses campos podem ser úteis na localização do recurso.

Se enxergamos o Active Directory como um Banco de Dados então os objetos seriam “registros” por exemplo o usuário ANDRÉ é um “registro” e os atributos como senha , email etc. seriam os “campos” desse banco. Para acessar esses dados temos as seguintes ferramentas disponíveis :

· Ferramentas, interfaces de usuário e componentes do Windows

· APIs (.NET, VBScript, Windows PowerShell)

· LDAP (Lightweight Directory Access Protocol)

O AD-DS É um repositório central de informações de rede, é organizado em domínios, árvores e florestas como veremos no detalhe. Os objetos são mantidos num domínio, detalhado ainda nesse artigo. Podemos dizer que o domínio é uma área (lógica) de organização e segurança do AD-DS. Figura 2

clip_image006

Figura 2. O domínio é uma área de organização e segurança do AD-DS

Aprofundando:

O atributo unicodePwd armazena o “hash” da senha, ou seja em formato ilegível.e o atributo userPassword é utilizado na alteração e redefinição de senha. Então quando quando alteramos uma senha, é feita uma “gravação” no atributo userPassword. O sistema então calcula o hash e o armazena em unicodePwd. Desta forma não conseguimos “recuperar” uma senha apenas sobrepô-la.

Porque usar Active Directory?

Na plataforma Microsoft ,temos duas opções de trabalhar compartilhando recursos em rede: ou usamos a  opção de grupo de trabalho (“Workgroup”) ou em forma de Domínio usando o AD-DS.

Normalmente usado em pequenas empresas ou em ambientes caseiros, a opção de trabalhar em grupo nos traz inconvenientes, por exemplo, o fato das contas de usuários e senhas serem armazenadas localmente em cada computador da rede e não existir nenhuma forma de sincronizar essas senhas. Em relação ao armazenamento de senhas podemos dizer que o AD-DS faz o armazenamento centralizado de identidades para todos os membros do domínio tendo assim um serviço de autenticação centralizado, hospedado por um servidor que desempenha o papel de um controlador de domínio do AD DS

O fato do Active Directory simplicar o gerenciamento da segurança armazenando as credenciais de usuário de uma forma centralizada, permite, por exemplo, a exclusão e inclusão de objetos para o domínio de um local só, permitindo também o Logon único em toda a rede. Outra vantagem de usarmos o AD-DS é a administração centralizada de estações de trabalho, como por exemplo, padronização da área de trabalho bem como instalações de software. Vemos assim que o AD-DS não é só usado para armazenar e fornecer informações, mas, também para gerenciar configurações.

A centralização e a organização de objetos na rede também favorece a redução de custos, principalmente os de administração. Além disso, aplicações específicas como por exemplo o servidor de correios da Microsoft, o Exchange Server utilizam suas extensões para se conectar e integrar os usuários criados no Active Directory como as caixas postais e demais serviços de colaboração, sendo possível enviar e-mails para grupos de distribuição de e-mails criados no Active Directory. Uma outro exemplo é uma aplicação que permita que funcionários do RH da empresa incluam usuários no AD usando como interface uma aplicação front-end.

Não existe nenhuma razão técnica para não usar o AD-DS , a não ser em casos extremos de redução de custos numa pequena empresa aonde não se tem recursos para implementação e administração de um ambiente de domínio.

Aprofundando

AD DS usa um protocolo de autenticação padrão do setor — ele não foi criado pela Microsoft.

O que é um Domínio ?

Como já mencionado, o DOMÍNIO é uma área lógica de segurança e é controlado por pelo menos um computador fazendo o papel de CONTROLADOR DE DOMÍNIO. Cada computador e conta de usuário faz parte de um domínio , simbolizado por um triângulo conforme vemos na Figura 2.

O que é Unidade Organizacional (OU) ?

O AD-DS pode conter milhares ou milhões de objetos, imaginemos todos esses objetos em um lugar só, teríamos um sério problema de gerenciamento. Então como podemos melhorar o gerenciamento ? Colocando os objetos em coleções chamadas de Unidades Organizacionais, as quais, podemos também chamar de OU ( sigla da nomenclatura em inglês) ou containers. Podemos dizer então, que o domínio pode ser dividido em unidades organizacionais visando melhorar o gerenciamento dos Objetos.

Com OUs você pode copiar a estrutura geográfica ou organizacional da sua empresa Figura 3 . .A divisão do domínio em unidades organizacionais requer um planejamento e acreditamos que merecem um artigo específico sobre o assunto. Em tese não existe certo ou errado no planejamento das OUs, apenas espera-se que o planejamento facilite ao máximo a gerência dos objetos.

As OUs não são apenas úteis para organização, mas, também podemos delegar tarefas administrativas para determinada OU incluindo as que estiverem abaixo dela na hierarquia, assim, usuários que não são administradores do domínio podem executar determinadas tarefas antes destinadas somente a administradores. Por exemplo, na Figura 4 podemos delegar poderes a uma equipe de help desk para reiniciar senhas para a Diretoria Administrativa. Assim, os administradores do domínio tem poderes sobre todo o domínio, mas a equipe de help desk tem poderes de reiniciar as senhas da Diretoria Administrativa e consequentemente da Contabilidade, do RH e do Financeiro, porém, a mesma equipe de help desk não pode reiniciar as senhas da diretoria industrial porque não lhe foi delegado essa tarefa.

Outro bom motivo para dividirmos o domínio em OUs é a possibilidade de gerenciamento do ambiente de trabalho dos usuários e seus desktops. Esse gerenciamento de ambiente de trabalho é feito através de diretivas de grupo. As diretivas de grupo impõe determinados parâmetros aos usuários e computadores. Um exemplo, usando ainda a Figura 4 poderíamos ter uma diretiva de grupo para o a OU Financeiro direcionando a página inicial do Internet Explorer para o site da intranet do setor. As diretivas de grupo são muito importantes na gerência do domínio e serão alvo de outro artigo bem específico.

clip_image008

Figura 3. Divisão do domínio em OUs copiando a estrutura organizacional.

clip_image010

Figura 4 Ferramenta de gerencia do AD-DS na qual criamos e gerenciamos OUs.

O que é uma Árvore de domínio ?

Existem casos nos quais a administração do domínio é distribuída em países ou cidades diferentes, ai nesse caso a subdivisão do domínio feito por OUs pode não ser suficiente pois temos a administração do domínio feita por administradores diferentes em diferentes localidades e talvez em outros idiomas. Também temos casos de que a empresa usa padrões de segurança muito diferentes entre suas localidades. Existem casos que exigem que uma empresa precise se subdividir em subdomínios, figura 5, que chamamos domínios filhos formando assim uma Árvore de Domínio, figura 6.

Então uma árvore de domínio é um conjunto de Domínios e Subdomínios utilizando uma hierarquia de nomes baseada em DNS (Domain Name System), na qual o domínio filho recebe o nome do pai e cresce pela esquerda. Por exemplo a empresa comercial.com.br pode ter um subdomínio filial.comercial.com.br.

Após criado o domínio RAIZ ou ROOT os domínios filhos são adicionados diretamente abaixo. Como mencionado no parágrafo anterior, podemos observar que o nome do domínio filho cresce para a ESQUERDA mantendo-se o nome do domínio PAI.

Numa relação de domínio pai e domínio filho a relação de confiança é bidirecional , significa que , por exemplo, um usuário do domínio pode ter acesso a qualquer recurso da Àrvore ( salvo os que lhe tenham sido restringidos).

O Domínio é a fronteira máxima de uma política de senha por exemplo , se uma localidade da empresa exige uma outra política seria o caso de criarmos um subdomínio. A divisão em subdomínios é um estudo complexo e mais uma vez reiteramos a necessidade de um exaustivo planejamento evitando assim, custos e esforços desnecessários. Quanto mais subdividido o domínio mais variáveis são incluídas no ambiente, por exemplo mais controladores de domínio, mais replicações são necessárias, etc..

clip_image012

Figura 5. Divisão do domínio ADCorp.com.br nos subdomínios EUA e AFRICA.

clip_image014

Figura 6 Divisão do domínio ADCorp.com.br nos subdomínios EUA e AFRICA

O que é uma Floresta ?

O modelo de árvore de domínio conforme explicamos anteriormente é extensível a outras árvores podendo assim ser criada uma FLORESTA, Múltiplas árvores de domínio são úteis em fusões, ou aonde a empresa quer manter identidade de nomes diferentes. Então uma floresta é uma junção de uma ou mais árvores de domínio. Figura 7.

clip_image016

Figura 7. Relação de confiança entre árvores diferentes criando-se uma Floresta.

O que é Catálogo Global ?

O Catálogo global mantém alguns atributos de todos os objetos do domínio permitindo assim a localização de qualquer objeto em qualquer lugar da empresa, figura 8 , Assim é possível que um usuário do escritório de Paris (França) localize uma impressora no 2º andar do escritório de Luanda (Angola) pesquisando-se no Catálogo Global.

clip_image018

Figura 8. O catálogo global mantém uma série de atributos dos objetos do domínio.

O que é um Controlador de domínio ?

O Catálogo global é replicado pelos Controladores de Domínio (computadores designados para tal função)

, assim qualquer informação adicionada aos domínios são conhecidas por todos os controladores pela REPLICAÇÂO , o que também garante uma certa redundância das informações,Figura 9. Então um objeto criado/deletado ou modificado no subdomínio AFRICA.ADcorp.com.br é conhecido pelo servidor do domínio ADCorp.com.br porque os controladores de domínios usam a replicação para se atualizarem.

clip_image020

Figura 9. Os controladores se domínio compartilham o catálogo global atualizado

Em uma organização grande, é recomendável pelo menos dois controladores de domínio por local físico pois assim garantimos o ambiente no caso de falha de um dos controladores naquele local. A ausência de um controlador num local físico implica que será necessário um tráfego na wan em busca de informações que estão no AD-DS como a autenticação de usuários por exemplo. Em empresas menores podemos ter apenas um controlador para o domínio todo, porém é sempre bom lembrar que deve ser levado em conta o tráfego de rede em locais que usam um controlador de domínio localizado através de um link WAN além da indisponibilidade causada na falha desse único servidor .

Entre outras funções um controlador de domínio deve :

• Manter uma cópia do Active Directory

• Responder a pesquisas ao Active Directory

• Autenticar os usuários para a rede

Aprofundando:

Em ambientes virtualizados é uma recomendação do autor que pelo menos um controlador de domínio seja configurado em um host físico pois assim garantimos o ambiente no caso de problema na estrutura de virtualização;

Dentre as vantagens de virtualização do controlador de um controlador de domínio podemos citar :

· Consolidação. Você pode consolidar vários controladores de domínio com outros servidores

· Testes. Você pode montar um ambiente de produção usando muito menos hardware do que faria com servidores físicos

· Desempenho. Segundo o site da Microsoft “Se você seguir todas as recomendações de desempenho ... poderá esperar uma redução em desempenho de apenas 2 por cento para 12 por cento em um único controlador de domínio executado em uma máquina virtual sob carga pesada em comparação a um controlador de domínio executado em hardware nativo com as mesmas especificações.”

Em relação as desvantagens quase todas apontam para o uso dos VHDs e os cuidados com os mesmos, principalmente em relação a segurança das pessoas que tem autoridade para manipulação dos discos virtuais.

Como o banco de Dados do Active directory é armazenado ?

O banco de dados do active directory é na realidade um arquivo e uma pasta. O arquivo NTDS.DIT é o “banco de dados” que dá suporte aos objetos e atributos e a pasta SYSVOL seria um “banco de dados” (de tipos) que dá suporte ao gerenciamento baseado em diretiva (scripts e diretivas) ambos estão localizados nos controladores de domínio. Por exemplo a pasta Sysvol , que é compartilhado com o nome de NETLOGON para efeito de compatibilidade , pode conter scripts de logon , scripts que serão executados assim que um usuário dá LOG ON no domínio.

O arquivo NTDS.DIT localizado em %systemroot%\NTDS\ntds.dit contém partições, Figura 10,

§ Esquema

§ Configuração

§ Contexto de nomenclatura de domínio

§ DNS (partições de aplicativos)

§ Catálogo global também chamado de
Conjunto de Atributos Parcial (PAS)

clip_image022

Figura10. Conteúdo do arquivo NTDS.DIT

No caso da existência de vários domínios a partição de configuração e o esquema são replicados para todos os domínios da floresta, mas a partição de Domínio, aonde temos dados completos dos objetos, é compartilhada apenas pelos controladores do mesmo domínio. Então como um usuário de um domínio pode localizar dados de outro domínio ?

Já explicamos anteriormente o Catálogo Global , então podemos agora nos aprofundar e dizer que o catálogo global leva uma parte dos atributos para os outros domínios funcionando como se fosse um índice ,

Quando um usuário pesquisa dados de um objeto pertencente a outro domínio , é feita uma consulta ao Catálogo Global que detém os objetos e alguns atributos básicos para sua localização, Figura 8. Localizado o objeto no catálogo, é possível buscar o restante dos atributos na partição de domínio no domínio original do objeto.

Vamos analisar a Figura 11. Um usuário do domínio B (amarelo) faz uma pesquisa por um usuário pertencente ao domínio A (verde). Como uma parte da partição de domínio A é replicada para o domínio B é possível localizar o usuário. Um detalhe que, essa parte de um domínio replicada para outro (dentro da mesma floresta) não leva todos os dados do objeto, mas apenas os atributos mais comuns para consultas úteis , por exemplo nome e sobrenome, reforçando assim nossa idéia de funcionar como um índice.

Quando instalamos o primeiro controlador de domínio ele detém a função de Catálogo Global (GC global catalog) , porém quando colocamos controladores de domínio adicionais ele pode ou não deter essa função.

Seguindo a prática recomendada atualmente, o ideal seria transformar cada controlador de domínio em um GC. Talvez haja algumas situações (muito raras) em que não seja apropriado, mas na grande maioria podemos confirmar essa recomendação principalmente em empresas que utilizam o Exchange, o servidor de colaboração da Microsoft. Além da presença do Exchange server podemos afirmar que é recomendável todo controlador de domínio ser um GC principalmente nos casos de um site consultar o GC pela porta 3268 ou uma conexão em um GC em outro site não for confiável ou lenta.

clip_image024

Figura11. Partição PAS é replicada nos outros domínios.

Como criar uma nova floresta no windows 2008 ?

Toda confguraçãode ADDS passa por um exaustivo planejamento, Os dados que precisamos planejar antes de criar a nova floresta e configurar o primeiro controlador de domínio são

· Nome DNS do domínio (ex ADgroup.com)

· Nome NetBIOS do domínio (ex ADgroup)

· A nova floresta precisará dar suporte a controladores de domínio que estão executando versões anteriores do Windows (opção nível funcional)

· Detalhes sobre como o DNS será implementado para dar suporte ao AD DS

· Configuração IP do controlador de domínio

· Nome de usuário e senha de uma conta no grupo Administradores do servidor. Localização do armazenamento de dados (ntds.dit) e de SYSVOL sendo que o padrão é %systemroot% (c:\windows)

Com esses dados podemos já configurar o primeiro controlador de domínio da floresta.

Conclusão

O Active directory é o serviço de diretórios do Windows 2008 server , chamado aqui de AD-DS. Descrevemos como o AD-DS é estruturado discorremos sobre suas principais ferramentas e configurações além de discutirmos alguns pontos de planejamento. Comentamos sobre Unidades Organizacionais (OUs) e vagamente sobre as GPOs ( Diretivas de Grupo)

O conhecimento profundo do AD DS requer um estudo aprofundado e algumas horas de laboratório e experimentação. O domínio das ferramentas de manutenção e as técnicas também são importantes para um administrador ter sucesso num ambiente complexo com o AD-DS. O Backup também não foi abordado e acreditamos ser uma parte importante das funções do administrador.

Existem vários pontos que não abordamos como por exemplo grupos de segurança específicos como o grupo Universal, Níveis funcionais de domínios e florestas, transferências de funções master entre controladores de domínio entre outros. Temas que esperamos abordar nos próximos artigos. Algumas ações mais complexas também devem ser alvos de estudos atenciosos como por exemplo problemas de replicação , problemas de conflitos durante a replicação , recuperação de objetos deletados, etc..

No momento a Microsoft já liberou algumas informções do Windows Server 8 que deve trazer muitas mudanças principalmente na área do AD-DS e de Virtualização , fiquemos atentos.

Esperamos que esse artigo seja o início de sua jornada pelo conhecimento do AD-DS bem como seu planejamento e sua manutenção.


segunda-feira, 28 de julho de 2014

segunda-feira, 21 de julho de 2014

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.

clip_image002

Figura 21: MFA Arquitetura de Alto nível.

terça-feira, 15 de julho de 2014

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:

clip_image002

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).

clip_image004

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)

clip_image006

clip_image008

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”.

clip_image010

clip_image012

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.

clip_image014

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.

clip_image016

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.

clip_image018

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.

clip_image020

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:

clip_image022

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.

clip_image024

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.

clip_image026

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.

clip_image028

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.

clip_image029

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.

clip_image031

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.

clip_image032

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.

clip_image034

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.

clip_image036

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).

clip_image038

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:

clip_image040

Figura 19: Abrindo sessão RDP

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

clip_image042

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.

sábado, 3 de maio de 2014

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

648.medium

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.

sexta-feira, 26 de julho de 2013

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.





terça-feira, 23 de julho de 2013