Controle remoto para desktops virtualizados
Active Directory está morto: Viva Active Directory. Enquanto do Microsoft Windows Server Active Directory (WSAD) não é capaz de atender às necessidades de hoje, o seu irmão mais novo Azure Active Directory (AAD) parece pronto para tomar o mundo pela tempestade.
Tenho dado a uma vez mais e estou impressionado com a tecnologia - mas também ambivalentes sobre suas implicações.
Eu sou conhecido por ser cético em relação a nuvem pública, mas estamos muito além do ponto em que uma empresa competitiva pode fazer toda a sua TI em casa. A realidade hoje é que há tanta TI para além do firewall corporativo, por trás dele.
O mecanismo de autenticação em apenas do estabelecimento comercial que nos fez bem para os últimos 15 anos já não se encaixa no projeto.
Os antigos caminhos
Com força de vontade suficiente e capital político em sua organização um CIO carismático poderia impor VPNs, gestão de endpoint e outras ferramentas herdadas do comércio para smartphones, tablets e até mesmo PCs caseiros para os membros da equipe teletrabalho.
Cadernos Corporativos poderia ser bloqueado para baixo e tudo poderia ser amarrado para trás para a infra-estrutura existente WSAD.
A maioria das empresas ainda executar este caminho. A partir da experiência, no entanto, é tudo uma dor bem no proverbial. Os usuários que se acostumaram a assinar em praticamente qualquer site usando suas credenciais do Facebook ou do Google acabar frustrado na negociação de uma pista de obstáculos diária de ligar vários Widgetry à rede corporativa.
A abordagem tradicional também falta quando se trata de integração com o software como serviço (SaaS). Se você quisesse criar um single sign-on para as suas contas Dropbox corporativos, bem como as suas contas WSAD nos estabelecimentos comerciais, você tem que confiar em software de terceiros , como o previsto pela Centrify .
Em certo sentido, AAD é muito semelhante a produtos como Centrify, que permite conectar aplicativos SaaS para o seu WSAD instalar, como faz AAD. Uma olhada na Tutorial Dropbox irá mostrar essas semelhanças.
Claro, AAD tem indo para ele que os produtos da Microsoft ter sempre indo para elas: integração profunda em todas as coisas da Microsoft. Apoio AAD deve ser integrado ao Windows 10. É, certamente, cozido em Azure e Office 365.
Vai ser tanto uma parte de cada produto Microsoft de próxima geração como WSAD fazia parte do passado. AAD terá mais aplicativos de terceiros que o apoiam. Ele será mais profundamente integrada em cada aspecto da Microsoft e será o serviço de identidade facto de os próximos 15 anos.
Então, o que é?
Ties That Bind
O mundo da identidade Microsoft tem potencialmente um monte de peças em movimento. Nas instalações temos WSAD. Aqueles familiarizados com as tecnologias da Microsoft também pode ter ouvido de Forefront Identity Manager (FIM).
Você pode pensar em FIM como Active Directory em esteróides: seu trabalho é conectar WSAD para consumo no local da forma que se conecta a AAD aplicativos SaaS.
Se o Active Directory é a base da gestão de identidade moderna, FIM e AAD pode ser pensado como cola de middleware, que interliga as aplicações, cada qual armazena diferentes pedaços de informações sobre os usuários, todos com nomes diferentes.
Uma aplicação pode chamar de uma "posição" de campo, enquanto outro chama de "título de trabalho", mas eles precisam ser mapeados para o mesmo campo em todos os aplicativos se as pessoas estão a ficar sã tentando manter registros em linha reta.
FIM requer alguma ajuda na conexão com o mundo da whacky as-a-service diversão nublado
Versão atual do FIM - 2010 R2 - não é inata nuvem consciente. Como WSAD, requer alguma ajuda na conexão com o novo mundo de whacky como serviço-fun nublado. Para fazer isso tudo acontecer, contamos com uma ferramenta chamada Dirsync (que em breve será substituído por AAD Sync).
Se você tem FIM configurar você vai querer usar AAD Premium e você terá que configurar Dirsync / AAD Sincronizar manualmente. Esta não é a mais bonita de processos, mas é muito mais fácil do que, digamos, a criação de System Center.
Se você não tem FIM e só estão usando WSAD, então você está com sorte. Microsoft Connect torna a ligação WSAD para AAD um "next, next, next, finish" tipo de caso.
Basta encontrar um servidor x64 que é Server 2008 R2 ou mais recente e não é um controlador de domínio (usuários desculpe SBS). Executar o Microsoft Connect. Ele irá verificar os pré-requisitos, como .NET, as AAD PowerShell módulo e Microsoft Online Services Sign-In Assistant. Ele vai baixar, instalar e configurar Dirsync / AAD Sync e ativá-lo no seu inquilino Azure.
Microsoft Connect irá criar ou sincronização senha ou AD FS; se você não sabe o AD FS é, escolher a opção de senha de sincronização. Microsoft Connect, então, executar várias verificações para garantir que tudo é bom para ir.
Há uma ressalva. Se você quiser que os usuários possam entrar usando o usando o usuário local nome principal (UPN), em seguida, o seu atributo UPN precisa usar um domínio roteáveis publicamente. Em outras palavras, se o seu domínio local é algo como "vulturenorth.local" ou "vulturenorth.intranet" você vai correr em alguns problemas.
Não é uma solução rápida. Vá aqui e role para baixo até encontrar a seção intitulada "adicionar alternativa sufixo UPN para o Active Directory". Basta seguir os passos bastante simples descritas lá e todos os seus problemas com a conexão a sua configuração WSAD local para AAD usando Microsoft Connect deve ir embora.
DESCANSO fácil
É claro que, apertando os botões para fazer uma palestra para B é apenas uma parte desse processo. Outro objetivo é permitir que os computadores fora nas internets lanosos selvagens para autenticar com seu WSAD instalação local.
Além disso, o foco mais amplo da Microsoft é permitir que os desenvolvedores de amanhã para amarrar suas aplicações para AAD, de preferência após o desenvolvimento de suas aplicações para Azure.
Para garantir que estas novas aplicações pode tirar proveito de tudo o que tem para oferecer AAD, AAD, naturalmente, tem uma API REST completa. O objetivo é garantir que os desenvolvedores não perca tempo a construir o seu próprio gerenciamento de identidade para cada aplicação. Não há necessidade de criar e acompanhar os usuários ou se preocupar com hashes de senha e assim por diante.
Do ponto de vista puramente pragmático, a Microsoft é provável que fazer um trabalho melhor de lidar com usuários e segurança do usuário do que se cada desenvolvedor tentou reinventar esta roda especial para cada aplicação.
Microsoft já está alavancando single-sign-on do AAD capacidades para unir Office 365, Dynamics CRM, o Windows Intune e outros produtos de nuvem da Microsoft.
A Microsoft não é a construção de um jardim murado completa aqui. Redes de identidade de terceiros, tais como Facebook e Google - e sua constelação de aplicativos e serviços ligados - pode ser integrado. Este é o lugar onde as coisas ficam um pouco complicado.
Dificuldade Padrão
As várias empresas que pretendem governar-nos através dos nossos logons ainda estão discutindo sobre quais padrões de identidade para apoiar. Isto significa que enquanto estes serviços podem jogar juntos, em maior ou menor grau, existem algumas coisas que não podemos ter.
Onde todo mundo joga bonito, criando um usuário na interface AAD criará esse usuário em todas as aplicações conectadas e serviços de identidade. Onde há uma cabeçada de cabeças sobre normas, espera ter para criar o usuário, tanto na AAD e em um aplicativo de terceiros ou serviço identidade. Depois que você começa a mapear manualmente os usuários um para o outro.
Até as guerras de padrões para o híbrido gerenciamento de identidades federadas chegar a um fim, esperamos que este seja o novo normal.
Há uma enorme quantidade de bumf de marketing disponíveis para AAD: o que é bom para, por que devemos cuidar e assim por diante. Cortar à perseguição, você precisa entender como Microsoft prevê que usaremos AAD, se você quiser ver se ele é um bom ajuste para a sua organização.
Naturalmente, a Microsoft prevê que todos nós irá sincronizar nosso WSAD para AAD. Isso é bom para o single sign-on, mas estritamente falando, não é necessária.
Se os seus funcionários são capazes de compreender que eles têm dois logins separados - um para coisas por trás do firewall corporativo e outra para serviços em nuvem - então você pode manter os dois separados e criar um modelo de segurança que é diferente da Microsoft propõe. A escolha é sua.
AAD no centro
Microsoft também vê todos usando suas ferramentas de gestão AAD para gerenciar usuários. É teoricamente possível usar suas ferramentas locais para fazer alterações WSAD e tem aqueles empurrado até a nuvem, ou para gerenciar tudo através de um aplicativo de terceiros e tê-lo propagar as mudanças para o resto de sua rede de identidade através das APIs - mas esta não é a visão da Microsoft do futuro.
Microsoft Azure posiciona no centro de sua vida digital, preenchendo o papel que o Windows Server realizada durante os 15 anos anteriores. Assim, quer as interfaces Azure - incluindo AAD - para ser o novo normal, e os meios pelos quais podemos interagir com toda a nossa rede de identidade.
Tudo está centrado na criação de uma experiência de usuário harmonizada, desde que você começar e terminar em Azure.
Junto com isso é a capacidade de inspecionar os padrões de login do usuário para ver se algo está errado. Alguém está tentando entrar a partir de múltiplas fontes desconhecidas? A partir de uma parte diferente do mundo do que o normal? Eles estão usando um serviço de VPN comercial? Não assinar em durante o seu tempo normal do dia?
Eles podem ser banidos, forçado a socos em um código de segurança e ter um e-mail enviado ao administrador informando deles desta "atividade suspeita".
Cuidado com os usuários
Microsoft propõe igualmente a "empoderar" os usuários finais. Como um administrador de sistema cínico, eu não quero que meus usuários habilitada. Usuários habilitados leva a loucura cedo sysadmin início.
O primeiro pedaço de capacitação do usuário dá aos usuários o direito de alterar suas próprias senhas. Há também um "painel de acesso", que serve como um lançador de aplicativos SaaS que o usuário tem acesso. Não vejo problemas aqui.
Mas AAD empoderamento também dá aos utilizadores finais o direito de criar e gerenciar grupos. É uma coisa para os usuários a ser capaz de empurrar seus contatos no Outlook em grupos, mas fico inquieto quando começamos a falar sobre os usuários que são capazes de fazer qualquer coisa além de mudar sua senha.
Na mesma linha, eu tenho preocupações sobre o nível de acesso que todos os pedaços de identidade nublado federado pode ou não pode ter um com o outro.
Meu cenário de pesadelo é alguém que não está me ser capaz de criar um usuário no AAD com privilégios administrativos (ou atribuir privilégios administrativos para um usuário existente) e ter essas alterações replicar de volta para minha infra-estrutura WSAD no local.
O culpado pode ser um canalha que rachou minha Azure senha de administrador global, ou um aplicativo de terceiros mal codificadas emitir comandos através da API.
A este respeito, AAD Sync é um avanço enorme em Dirsync . Ele oferece um controle muito mais preciso sobre o que pode e não pode sincronizar e oferece alguma esperança de que premeditação e planejamento pode manter esses cenários de pesadelo na baía.
Apesar das minhas preocupações, é difícil argumentar com a utilidade do AAD. Ele fornece a funcionalidade necessária para o mundo juntaram-up de hoje, e faz isso de forma simples e robusta. As primeiras versões tinham muitos problemas iniciais, mas a maioria dos que foram elaborados.
AAD é um serviço de identidade federada totalmente moderno pronto para lidar com os pedidos de ontem, hoje e amanhã. ®
Obter treinamento gratuito sobre Diretório Azure, com as mãos nos: Implementando Azure Active Directory Regcast aqui .
