Preparar o single sign-on

Publicada: Junho de 2012

Atualizada: Fevereiro de 2013

Aplica-se a: Office 365, Windows Intune

Com o single sign-on, os utilizadores podem aceder ao serviço baseado na nuvem Microsoft com as respetivas credenciais empresariais existentes do Active Directory (nome de utilizador e palavra-passe). Para configurar o single sign-on, terá de configurar um ou mais servidores no local como um serviço de tokens de segurança (STS). Um STS permite a federação de identidade, alargando a noção de autenticação e autorização centralizadas, bem como de SSO, a serviços e aplicações Web localizados virtualmente em qualquer lado, incluindo redes de perímetro, redes de parceiros e a nuvem. Quando configurar um STS para fornecer acesso single sign-on ao serviço baseado na nuvem Microsoft, estará a criar uma fidedignidade federada entre o STS no local e o domínio federado que especificou no Windows Azure Active Directory.

O Windows Azure AD suporta o single sign-on com qualquer um dos seguintes serviços de tokens de segurança:

• Serviços de Federação do Active Directory (AD FS) 2.0

• Fornecedor de Identidade do Shibboleth

A secção seguinte deste artigo discute as vantagens, as experiências de utilizador e os requisitos do single sign-on. Indica igualmente o modo como pode verificar se a configuração atual do Active Directory é compatível com os requisitos do single sign-on.

Neste artigo

• Vantagens da utilização do single sign-on

• Experiência do utilizador com o single sign-on em diferentes localizações

• Requisitos do single sign-on

• Preparação do Active Directory

• Passo seguinte

Vantagens da utilização do single sign-on

Existe uma clara vantagem para os utilizadores quando se configura o single sign-on: permite-lhes utilizar as respetivas credenciais empresariais para aceder ao serviço baseado na nuvem que a empresa tenha subscrito. Os utilizadores não têm de voltar a iniciar sessão nem memorizar várias palavras-passe.

Além das vantagens para os utilizadores, há também diversos benefícios para os administradores:

• Controlo de políticas: o administrador pode controlar as políticas de conta através do Active Directory, o que lhe permite gerir políticas de palavras-passe, restrições de estações de trabalho, controlos de bloqueio, etc., sem ter de efetuar tarefas adicionais na nuvem.

• Controlo de acesso: o administrador pode restringir o acesso ao serviço baseado na nuvem de modo a poder aceder aos serviços através do ambiente empresarial, de servidores online ou de ambos.

• Redução das chamadas para o suporte: o esquecimento da palavra-passe é um motivo comum para contactar o suporte, em todas as empresas. Se os utilizadores tiverem menos palavras-passe para memorizar, é menos provável que as esqueçam.

• Segurança: as identidades e informações dos utilizadores estão protegidas, porque todos os servidores e serviços utilizados com o single sign-on são controlados no local.

• Suporte para autenticação segura: pode utilizar a autenticação segura (também denominada autenticação de dois fatores) com o serviço baseado na nuvem. No entanto, se utilizar a autenticação segura, terá de utilizar o single sign-on. Existem algumas restrições na utilização da autenticação segura. Se pretender utilizar o AD FS 2.0 para o STS, consulte Configuring Advanced Options for AD FS 2.0 (Configurar Opções Avançadas para o AD FS 2.0) para mais informações.

Neste artigo

Experiência do utilizador com o single sign-on em diferentes localizações

A experiência de um utilizador no que respeita ao single sign-on varia consoante a forma como o computador desse utilizador estiver ligado à rede da empresa e o sistema operativo que tiver instalado, e como o administrador configurou a infraestrutura do respetivo STS.

Descrevem-se a seguir as experiências dos utilizadores com o single sign-on a partir de dentro da rede:

• Computador de trabalho numa rede empresarial: quando os utilizadores estão no local de trabalho, com sessão iniciada na rede empresarial, o single sign-on permite-lhes aceder ao serviço baseado na nuvem sem terem de voltar a iniciar sessão.

Se o utilizador estabelecer ligação a partir do exterior da rede da empresa ou aceder a serviços a partir de aplicações ou dispositivos pessoais, como é o caso das situações seguintes, tem de implementar um proxy de STS. Se pretender utilizar o AD FS 2.0 para o STS, consulte Plan for and deploy AD FS 2.0 for use with single sign-on para mais informações sobre como configurar um proxy do AD FS 2.0.

• Computador de trabalho, em roaming: os utilizadores com sessão iniciada em computadores associados a um domínio através das respetivas credenciais empresariais, mas que não estão ligados à rede empresarial (por exemplo, um computador de trabalho utilizado em casa ou num hotel), podem aceder ao serviço baseado na nuvem.

• Computador doméstico ou público: quando o utilizador se serve de um computador não associado ao domínio empresarial, ele tem de iniciar sessão com as credenciais empresariais para aceder ao serviço baseado na nuvem.

• Smartphone: num smartphone, para aceder ao serviço baseado na nuvem, como o Microsoft Exchange Online, através do Microsoft Exchange ActiveSync, o utilizador tem de iniciar sessão com as credenciais empresariais.

• Microsoft Outlook ou outros clientes de correio eletrónico: o utilizador tem de iniciar sessão com as respetivas credenciais empresariais para aceder ao correio eletrónico, caso esteja a utilizar o Outlook ou um cliente de correio eletrónico que não faça parte do Office; por exemplo, um cliente IMAP ou POP.

  Se utilizar o Shibboleth como o STS, certifique-se de que instala a extensão de ECP do Fornecedor de Identidade do Shibboleth para que o single sign-on funcione com um smartphone, com o Microsoft Outlook ou com outros clientes. Para obter mais informações, consulte Configurar o Shibboleth para utilizar com o single sign-on.

Para obter informações detalhadas sobre o single sign-on com o AD FS 2.0, consulte How single sign-on works (Como funciona o single sign-on).

Neste artigo

Requisitos do single sign-on

Para utilizar o single sign-on, é necessário:

• Ter o Active Directory implementado e a executar o Windows Server 2003 R2, Windows Server 2008 ou Windows Server 2008 R2, com um nível funcional de modo misto ou nativo.

• Se pretender utilizar o AD FS 2.0 como o STS, terá de transferir, instalar e implementar o AD FS 2.0 num servidor com Windows Server 2008 ou Windows Server 2008 R2. Além disso, se os utilizadores estabelecerem ligação a partir do exterior da rede da empresa, tem de implementar um proxy do AD FS 2.0.

• Com base no tipo de STS que configurar, utilizar o Módulo do Windows Azure Active Directory para Windows PowerShell adequado para estabelecer uma fidedignidade federada entre o STS no local e o Windows Azure AD.

• Instalar as atualizações necessárias para o serviço baseado na nuvem Microsoft a partir da página de transferências dos serviços baseados na nuvem, para garantir que os utilizadores estão a executar as atualizações mais recentes do Windows 7, Windows Vista ou Windows XP. Para aceder à página de transferências do serviço baseado na nuvem, inicie sessão no portal do serviço baseado na nuvem e, em Recursos, clique em Transferências. As funcionalidades do serviço baseado na nuvem não irão funcionar corretamente sem as versões apropriadas dos sistemas operativos, browsers e software. Para obter mais informações, consulte Requisitos software.

Neste artigo

Preparação do Active Directory

O Active Directory tem de ter determinadas definições configuradas para poder funcionar devidamente com o single sign-on. Em particular, o nome principal do utilizador (UPN), também denominado nome de início de sessão do utilizador, tem de ser configurado de uma forma específica para cada utilizador.

Em função de cada um dos seus domínios, é possível que:

• O UPN tenha de ser definido pelo utilizador e do conhecimento do mesmo.

• O sufixo do domínio do UPN tenha de pertencer ao domínio que escolher para a configuração do single sign-on.

• O domínio que escolher para a federação tenha de ser registado como domínio público numa entidade de registo de domínios ou nos seus próprios servidores DNS públicos.

• Para criar UPNs, siga as instruções no tópico sobre o Active Directory, Adicionar Sufixos de Nome Principal de Utilizador. Tenha em conta que os UPN utilizados para o single sign-on só podem conter letras, números, pontos, travessões e carateres de sublinhado.

• Se o seu nome de domínio do Active Directory não for um domínio público da Internet (por exemplo, se tiver um sufixo “.local”), tem de definir um UPN para ter um sufixo de domínio subordinado a um nome de domínio da Internet que possa ser registado publicamente. Recomendamos que utilize algo que os utilizadores já conheçam, tal como o domínio de correio eletrónico.

• Caso já tenha configurado a sincronização do Active Directory, o UPN do utilizador pode não corresponder ao respetivo UPN no local definido no Active Directory. Para corrigir esta situação, mude o UPN do utilizador através do cmdlet Set-MsolUserPrincipalName no Módulo do Windows Azure Active Directory para Windows PowerShell.

Neste artigo

Passo seguinte

Após a preparação para o single sign-on, é necessário configurar o STS. Para obter instruções passo a passo, clique numa das seguintes hiperligações, consoante a opção de STS que a organização utilizar.

• Opção de STS 1: Utilizar o AD FS 2.0 para implementar e gerir single sign-on

• Opção de STS 2: Utilizar o Fornecedor de Identidade do Shibboleth para implementar o single sign-on.

Neste artigo

Ver Também

Conceitos

Plano do single sign-on
Informações gerais sobre a sincronização de diretórios