O blog da AWS
Integrando o AppStream 2.0 com o AWS Managed Active Directory em cenários multi-forest, de Zero a Cem
Por: Caio Ribeiro César e Ivan Vargas
12 de setembro de 2022: Este blogpost foi atualizado para refletir o novo nome do AWS Single Sign-On (SSO) – AWS IAM Identity Center. Leia mais sobre a mudança de nome aqui.
O Amazon AppStream 2.0 é um serviço gerenciado de streaming de aplicativos. Você gerencia centralmente os aplicativos de desktop no AppStream 2.0 e os entrega com segurança a qualquer computador. Neste modelo, podemos escalar facilmente para qualquer número de usuários em todo o mundo sem necessidade de comprar, provisionar e operar hardware ou infraestrutura.
O protocolo NICE DCV ajusta automaticamente cada sessão de streaming de acordo com as condições de rede para oferecer uma experiência do usuário fluida. Todos os usuários acessam a mesma versão dos aplicativos. Os administradores podem gerenciar centralmente os aplicativos no AppStream 2.0 em vez de gerenciar instalações e atualizações em cada computador de usuário.
O AppStream 2.0 também estabelece conexões com o Active Directory, a rede, o armazenamento na nuvem e os compartilhamentos de arquivos. Os usuários acessam aplicativos usando suas credenciais existentes, e as políticas de segurança atuais gerenciam o acesso. Neste post, iremos discutir como integrar o Amazon Appstream com o Active Directory em um cenário multi-forest trust de Managed AD com o Active Directory no ambiente on-premises.
O modelo de post “de zero a cem” é diferente dos posts que geralmente publicamos. Este será um passo a passo completo para a implementação da arquitetura, com a documentação detalhada.
Para esta arquitetura, iremos:
a) Criar uma federação entre florestas (AWS Managed AD e Domain Controllers gerenciados [AD OnPremises];
b) Configurar o AppStreams 2.0 com um Fleet de instâncias domain joined;
c) Configurar o ADFS 3.0 com permissões especiais de contâiners para o AWS Managed AD, servindo como Provedor de Identidade (IdP) para o AppStreams 2.0.
d) Habilitar a Federação de Identidade com o AD FS 3.0 e o Amazon AppStream 2.0
Este blog post faz referência a diversos artigos da AWS, principalmente o blog post criado por Matt Guanti.
Uma floresta do Active Directory (floresta do AD) é o contêiner mais lógico em uma configuração do Active Directory que contém domínios, usuários, computadores e políticas de grupo. O modelo de multi-forest trust é a criação de uma relação de confiança entre florestas, que permitem o acesso a alguns recursos que vivem em florestas externas.
O Managed AD faz o papel de “resource forest”, em que iremos separar contas e recursos de usuários em diferentes florestas. Usaremos essa configuração para que qualquer problema com uma floresta permita que a outra continue a operação.
O ADFS (ou Active Directory Federation Services) irá permitir o Gerenciamento Federado de Identidade e Acesso neste ambiente multi-forest, ampliando a capacidade de usar a funcionalidade de logon único (Single Sign On) para o Amazon AppStream – permitindo que clientes, parceiros e fornecedores utilizem umaexperiência de usuário simplificada durante o acesso.
No Amazon Appstream, uma Fleet consiste em instâncias de streaming que executam a imagem especificada. Uma “stack” consiste em uma frota associada, políticas de acesso do usuário e configurações de armazenamento. O Fleet Auto Scaling permite alterar automaticamente o tamanho da sua fleet para corresponder o fornecimento de instâncias disponíveis à demanda do usuário. Como um usuário requer uma instância de frota, o tamanho da sua frota determina o número de usuários que podem transmitir simultaneamente. Você pode definir políticas de dimensionamento que ajustam o tamanho da sua frota automaticamente com base em uma variedade de métricas de utilização e otimizar o número de instâncias disponíveis para atender à demanda do usuário. Você também pode optar por desativar o dimensionamento automático e fazer com que a frota funcione em um tamanho fixo.
Você pode criar uma experiência dinâmica, interativa e personalizada para seus usuários incorporando uma sessão de streaming do AppStream 2.0 ao seu site. As sessões de streaming incorporadas (Embed AppStream Streaming Session) permitem que seus usuários interajam com modelos, mapas e conjuntos de dados 3D diretamente do seu site. Por exemplo, os usuários podem visualizar instruções de treinamento ou materiais educacionais ao lado da sessão de streaming do AppStream 2.0.
No momento, a utilização de pool de usuários SAML 2.0 e AppStream 2.0 não são suportados como métodos de autenticação para sessões de streaming incorporadas do AppStream 2.0 (Embed AppStream Streaming Session). Para Embeded, podemos utilizar o AWS IAM Identity Center (sucessor do AWS Single Sign-On) (porém, no modelo de AWS IAM Identity Center (sucessor do AWS Single Sign-On), os stacks não podem ser domain-joined).
Inicialmente, vamos criar um trust entre as florestas de Active Directory Gerenciado e o Managed Active Directory.
Capítulo 1, Relacionamento de Confiança entre AWS Managed AD e Active Directory
1. Active Directory ambiente on-premises.
a. No Active Directory do ambiente on-premises, executamos o “Active Directory Domains and Trusts” e selecionamos a opção “Properties”.
b. Na janela de propriedades, selecionamos a opção “Trusts”.
c. Selecionamos a opção “New Trust” e então no wizard, “Next”.
d. Adicionamos o nome da floresta para o trust. Tenha certeza de que o DNS do servidor consegue resolver o nome para o Fully Qualified Domain Name ou NETBIOS do target. Em nosso cenário, criamos um Conditional Forwarder com os IPs de DNS do Managed AD.
e. Selecionamos a opção “Forest Trust”:
f. Selecionamos a opção “Two-way”, que seria um trust bi-direcional. Isto pode ser ajustado para um trust em que apenas o Active Directory on-premises confia no AWS Managed AD.
g. Selecionamos a opção para apenas o domínio selecionado com o escopo de autenticação “Forest-wide authentication”.
h. Na etapa de trust password, iremos esperar e iniciar a configuração no serviço de Active Directory gerenciado (Managed AD).
2. Managed AD.
a. Na console AWS, iremos até o Directory Service e selecionamos o Diretório do Microsoft AD gerenciado.
b. Dentro deste diretório, selecionamos “Networking & security” e posteriormente a opção “Add trust relationship”.
c. Configuramos uma senha e optamos pelas mesmas opções de trust do ambiente “source”. Na tab de conditional forwader, adicionamos os IPs de DNS do ambiente on-premises.
3. Active Directory ambiente on-premises.
a. Retornando ao Active Directory On-Premises, iremos adicionar a mesma senha de trust.
b. Adicionamos um usuário com permissões do ambiente de Managed AD para confirmar o trust.
c. Assim que salvarmos a configuração, teremos o trust criado.
Capítulo 2, Configuração inicial do AppStream 2.0
Agora que criamos uma relação de confiança entre os ambientes de AWS Managed ad e o Active Directory on-premises, vamos ao próximo passo.
1) Na console AWS, selecionamos o serviço AppStream 2.0.
2) Em “Directory Configs”, selecionamos a opção “Create Directory Config”.
3) Criamos o Directory Config selecionando a estrutura de Organization Unit (OU) que as instâncias de AppStreams 2.0 serão criadas e a conta de serviço com permissões para efetuar a criação (AWS Managed AD).
4) Criaremos agora uma imagem utilizando a opção de domain-joined. Para isso, selecionamos a opção “Images > Image Builder > Launch Image Builder”.
5) Selecionamos a imagem desejada e no final da página, selecionamos a opção “Next”.
6) Adicionamos um nome e configuração para vCPU e memória e então selecionamos “Next”.
7) Agora iremos adicionar as configurações do nosso domínio em questão (AWS Managed AD). Basta selecionar o Directory Config criado no passo 3).
Para que esta imagem consiga efetuar o domain join, os grupos de segurança do AppStream e do AWS Managed AD devem possuir o permissionamento adequado.
Além disso, a VPC desta imagem deve resolver os nomes de todas as florestas (recomendamos a criação do Outbound Endpoint no Route 53 – mais informações sobre Hybrid DNS aqui).
Em resumo, precisamos criar Outbound Endpoints [MOU3] [RCC4] no Route 53 resolver com Forwarding Rule para os DNS de cada domínio, por exemplo:
Esta regra irá efetuar o forward de DNS do domínio “dominio.corp” para os Domain Controllers deste ambiente, que possuem os serviços de DNS [172.31.41.22 e 172.31.1.110].
Esta segunda regra irá efetuar o forward de DNS do domínio “forestB.corp” para o Domain Controller deste ambiente, que possui o serviço de DNS [172.31.43.180].
Caso o passo de DNS não seja efetuado, o domain join do AppStream irá falhar (geralmente com o código de erro 1355 ao tentar efetuar o login).
8) Criaremos um AppStream 2.0 Fleet com as mesmas configurações.
9) Crie um AppStream Stack, atribuindo o fleet criado no passo 8). Utilize o nome “ExampleStack”, pois iremos criar as regras de ADFS com este mesmo nome.
Capítulo 3, Instalando e Configurando o ADFS em um ambiente AWS Managed AD
A federação de usuários baseada em SAML 2.0 é necessária para o streaming de aplicativos que são domain-joined. Iremos utilizar o Active Directory Federation Services (ADFS) para que ele possa atuar como o nosso provedor de identidade (IdP) e para que possamos ter a funcionalidade de domain joined.
Quando os usuários entram com a URL do ADFS, eles serão autenticados no AWS Managed AD. Após a autenticação, o navegador recebe uma asserção SAML como uma resposta de autenticação do ADFS, que é postada pelo navegador no ponto de extremidade SAML de entrada da AWS. As credenciais de segurança temporárias são emitidas após a validação da asserção e os atributos incorporados.
As credenciais temporárias são usadas para criar a URL de entrada. Finalmente, o usuário é redirecionado para a sessão de streaming do provedor de serviço (AppStream 2.0). O diagrama a seguir mostra o processo:
1. O usuário navega para a URL da aplicação publicada no ADFS. A página de logon solicita autenticação para o usuário. Vale lembrar que a estação de trabalho pode estar efetuando o acesso de qualquer localização via internet e o computador em questão não precisa ser domain joined.
2. O ADFS solicita a autenticação com o Active Directory.
3. O Active Directory autentica o usuário e retorna uma resposta de autenticação para o ADFS.
4. Com as informações de autenticação (success authentication), o ADFS cria uma asserção SAML representando o contexto de segurança de logon do usuário. Como um POST binding será usado, a asserção é assinada digitalmente e depois colocada em uma mensagem SAML
5. O navegador emite uma solicitação HTTP POST para enviar o formulário no AWS Sign-In SAML endpoint (https://signin.thinkwithwp.com/saml). O AWS Sign-In recebe o SAML, processa o pedido e consequentemente autentica o usuário, efetuando um forward do token de autenticação para o serviço do AppStream 2.0.
6. Utilizando o token de autenticação, o AppStream 2.0 autoriza o usuário e apresenta a aplicação para o browser.
Para este passo do procedimento, iremos utilizar o serviço de EC2 para criar o nosso Active Directory Federation Server. Para facilitar o entendimento do cenário, iremos criar o ADFS na mesma Availability Zone do AWS Managed AD.
Como o ADFS precisa ser domain-joined, a maneira mais segura de publicar este servidor será por um Web Application Proxy. Para não prolongar este post, iremos publicar o ADFS diretamente (não recomendado em cenários de Produção).
Iremos tomar nota dos pré-requisitos em cenários multi-forest:
- O domínio ao qual os servidores do ADFS estão ingressados deve confiar em todos os domínios ou florestas que contenham usuários autenticados no serviço AD FS.
- A floresta da qual a conta de serviço do ADFS é membro deve confiar em todas as florestas de logon do usuário.
- A conta do serviço ADFS deve ter permissões para ler os atributos do usuário em todos os domínios que contenham usuários autenticados no serviço ADFS.
Em uma instalação padrão do ADFS, este usa dois contêineres que exigem permissões especiais do AD na qual sua conta administrativa do AWS Microsoft AD não possui. Para resolver isso, criaremos dois contêineres na nossa OU para o ADFS usar seguindo esta documentação.
1. No AWS Managed Active Directory, crie a conta de serviço do ADFS.
a. Vá para a OU de usuários do AWS Managed AD e selecione “Novo Objeto – Usuário”
b. Digite adfssvc na caixa de texto Nome completo & Nome de logon do usuário.
c. Clique em avançar e digite e confirme uma senha para o usuário adfssvc.
d. Desmarque a caixa de seleção O usuário deve alterar a senha no próximo logon.
e. Clique em Avançar e, em seguida, clique em Concluir.
2. Vamos criar os contêiners que o ADFS irá utilizar.
a. Em uma EC2 com acesso ao Managed AD, iremos logar com o usuário domain\admin e gerar um GUID executando o comando “(New-Guid).Guid”.
b. Crie um contêiner chamado ADFS na sua OU. A OU está localizada na raiz do domínio e tem o mesmo nome que o nome NetBIOS que você especificou ao criar seu diretório do AWS Microsoft AD [New-ADObject -Name “ADFS” -Type Container -Path “OU=SeuNomeNETBIOS,DC=DomainSuffix,DC=DomainRoot”].
c. Agora iremos criar um contêiner dentro da estrutura de ADFS. Desta vez, iremos utilizar o nome do GUID coletado no passo a) para a criação [New-ADObject -Name “GUID” -Type Container -Path “CN=ADFS,OU=YourNetBIOSName,DC=YourDomainSuffix,DC=YourDomainRoot”].
3. No EC2 criado, instale o serviço de Active Directory Federation Services:
4. Agora que instalamos o ADFS, devemos obter um certificado para uso pelo seu serviço ADFS. O certificado do ADFS desempenha um papel importante para proteger a comunicação entre o adfsserver e os clientes do ADFS e proteger os tokens emitidos. A AWS recomenda que você obtenha um certificado de um provedor de certificados SSL confiável. O nome DNS publicado para o serviço AD FS deve usar o endereço IP público do adfsserver. Neste blog, meu serviço do ADFS possui um FQDN de sts.caiocesar.xyz.
É importante observar que o nome comum e o nome alternativo do assunto (SAN) devem incluir o nome do serviço de federação que você decide usar para o servidor ADFS. No meu exemplo, o nome é sts.caiocesar.xyz. Para esta postagem no blog, não obtivemos um certificado de um provedor de certificados SSL (estamos usando um self-signed para testes).
Copie o valor de Thumbprint do seu certificado público, pois iremos utilizar esta informação no passo 4).
Para mais informações de requisitos para o ADFS, clique aqui.
5. Iremos efetuar a configuração do ADFS. Para que este passo funcione, precisamos configurar o ADFS para utilizar os contêiners criados no passo 1).
$adminConfig = @{“DKMContainerDn”=”CN=GUID,CN=ADFS,OU=YourNetBIOSName,DC=YourDomainSuffix,DC=YourDomainRoot”}
6. Digite as credenciais da conta de usuário padrão do ADFS para o usuário ADFSSVC e salve-a na variável de script, $svcCred, lembrando que em cenários multi-forest esta conta deve ter permissões para ler os atributos do usuário em todos os domínios que contenham usuários autenticados no serviço ADFS.
$svcCred = (get-credential)
7. Agora iremos adicionar as credenciais do administrador do AWS Microsoft AD e salvar na variável de script, $localAdminCred.
$localAdminCred = (get-credential)
8. Finalmente, iremos configurar o ADFS, com as informações de ThumbPrint do nosso certificado e as variáveis de sistema.
Install-ADFSFarm -CertificateThumbprint <Thumbprint ID> -FederationServiceName “YourFederationServiceName” -ServiceAccountCredential $svcCred -Credential $localAdminCred -OverwriteConfiguration -AdminConfiguration $adminConfig -SigningCertificateThumbprint <Thumbprint ID> -DecryptionCertificateThumbprint <Thumbprint ID>
9. Após o sucesso do setup, reinicie o ADFS.
Capítulo 4, Habilitando a Federação de Identidade com o ADFS 3.0 e o Amazon AppStream 2.0
Agora que terminamos a configuração inicial do ADFS, vamos habilitar a federação de identidade com o Amazon AppStream 2.0:
1. Precisamos do arquivo de metadados do servidor ADFS. O arquivo de metadados é um documento que será usado posteriormente para estabelecer a nossa relação de confiança entre o provedor de identidade (IdP, ADFS) e o provedor de serviço (AWS). Para baixar e salvar esse arquivo, iremos utilizar o browser.
Este também servirá como o primeiro teste para validar que o serviço está sendo executado e que o endereço do ADFS pode ser alcançado pela internet e que não temos erros de certificado na página. Lembre de validar os Security Groups nesta etapa (https).
Substitua o valor de <FQDN_ADFS_SERVER> pelo nome completo do servidor do ADFS.
https://<FQDN_ADFS_SERVER>/FederationMetadata/2007-06/FederationMetadata.xml
Para o nosso ADFS, acessamos o endereço: https://sts.caiocesar.xyz/FederationMetadata/2007-06/FederationMetadata.xml e salvamos o arquivo xml.
2. Agora iremos no console do IAM e criar um provedor de identidade.
Na página “Configure Provider”, para “Provider Type”, escolhemos SAML. Para Nome do provedor, digitamos o nome do ADFS e então efetuamos o upload do documento de metadados baixado anteriormente.
Também precisamos do ARN (Amazon Resource Name) do provedor de identidade (IdP) para configurar regras de declarações. Para isso, selecionamos o IdP que acabamos de criar e copiamos o valor para o ARN do Provedor. O ARN está no seguinte formato:
arn:aws:iam::123123123123123:saml-provider/ADFS
3. Agora, precisamos configurar a política com permissões para o AppStream 2.0. Este é o nível de permissões que os usuários federados têm na AWS. No console do IAM, escolha “Policies, Create Policy” e crie sua própria política. Para o nosso exemplo, seguimos uma política template.
Nesta policy, “Action”: “appstream:Stream”, é a ação que fornece aos usuários do AppStream 2.0 permissões para se conectar a sessões de streaming na stack que criamos. Para o SAML Subject NameId, seria o identificador único do usuário ques está efetuando o login.
Para stacks com domain joined fleet, o valor de NameID para o usuário deve ser fornecido no formato “domínio\nome de usuário” usando o sAMAccountName ou “nome de usuário@domínio.com” usando o valor de userPrincipalName. Se você usar o formato sAMAccountName, especifique o domínio usando o nome NetBIOS ou o nome de domínio (FQDN). Para obter mais informações, consulte Usando o Active Directory com AppStream 2.0.
4. Nesta etapa, iremos criar uma função relacionada a um grupo do Active Directory atribuído aos usuários federados do AppStream 2.0. Para essa configuração, os grupos do Active Directory e as funções da AWS diferenciam maiúsculas de minúsculas (case sensitive). Iremos criar uma função do IAM denominada “ExampleStack” e um grupo do Active Directory nomeado no formato AWS-AccountNumber-RoleName, por exemplo AWS-012345678910-ExampleStack.
a. No console do IAM, selecionamos “Roles”, “Create Role”.
b. Selecionamos a opção “SAML 2.0 Federation” e então a opção “Allow Programmatic and AWS Management Console Access”. O Provedor de Identidade criado no passo 2) deve estar listado como uma opção nesta etapa.
c. Na tab de permissões, adicione a policy criada no passo 3).
d. Criamos a role com o nome “ExampleStack”. Iremos seguir este modelo para os passos restantes.
e. Em seguida, iremos criar um grupo do AWS Managed Active Directory no formato AWS-AccountNumber-RoleName usando o nome da função “ExampleStack” que criamos. Iremos fazer referência a esse grupo do AWS Managed Active Directory nas regras de declaração do ADFS posteriormente usando regex.
Para o escopo do grupo, escolhemos a opção “global” e tipo “segurança”.
Nota: Para seguir exatamente este passo a passo, nomeie seu grupo do AWS Managed Active Directory no formato “AWS-AccountNumber-ExampleStack”, substituindo AccountNumber pelo seu AWS AccountID (sem hífens). Por exemplo:
AWS-012345678910-ExampleStack
5. Agora, iremos criar a relação de confiança entre o ADFS e a AWS.
a. Vamos até o ADFS Management console.
b. Em “Relying Party Trust”, clicamos com o botão direito e selecionamos a opção “Add Relying Party Trust”.
c. Selecione a opção “Claims Aware” e então “Start”.
d. Adicione a URL da AWS no campo de Federation metadata address hostname or URL ( https://signin.thinkwithwp.com/static/saml-metadata.xml ).
d. Adicione a URL da AWS no campo de Federation metadata address hostname or URL ( https://signin.thinkwithwp.com/static/saml-metadata.xml ).
e. Dê um nome para a relação de confiança.
f. Selecione a opção de Access Control Policy. Caso tenha um RADIUS para MFA, esta opção pode ser alterada.
g. Revise as configurações e selecione a opção “Next” e “Close”.
h. Agora, iremos abrir as propriedades do Relying Party Trust , remover a opção “Monitor Relying Party” na tab de “Monitor” e adicionar a URL https://signin.thinkwithwp.com/saml para o “Relying Party Identifier” para que o Relying Party não seja atualizado automaticamente.
6. Criando Claim Rules.
Nesta seção, criamos Claim Rules, que irão identificar contas, definir atributos LDAP, obter os grupos do Active Directory e os corresponder à função criada anteriormente.
Com o botão direito no trust recentemente criado, selecione a opção “Edit Claim Rules” e então “Add Rule”.
a. Regra 1 – NameID.
Esta regra informa ao ADFS o tipo de declaração de entrada esperada e como enviar a declaração à AWS. Por exemplo, o ADFS recebe o UPN e o identifica como o ID do nome quando é encaminhado para a AWS.
Claim rule template: Transform an Incoming Claim
Configure Claim Rule values:
Claim Rule Name: Name ID
Incoming Claim Type: UPN
Outgoing Claim Type: Name ID
Outgoing name ID format: Persistent Identifier
Pass through all claim values: selected
b. Regra 2 – RoleSessionName.
Esta regra irá configurar um unique identifier para o usuário. Neste caso, iremos utilizar o valor de Email-Address. Consequentemente, os usuários devem possuir atributos de email.
Claim rule template: Send LDAP Attributes as Claims
Configure Claim Rule values:
Claim rule name: RoleSessionName
Attribute store: Active Directory
LDAP Attribute: E-Mail-Addresses
Outgoing Claim Type: https://thinkwithwp.com/SAML/Attributes/RoleSessionName
*Alguns administradores (para facilitar a gerência das claims), utilizam outros valores, como o MSDSConsistencyGuid (CPF, EmployeeId, etc). Estes valores também funcionam, desde que sejam únicos na organização e respeitem os parâmetros de SessionRoleName, correspondendo a [a-zA-Z_0-9+=,.@-]{2,64} comprimento máximo de 64 caracteres.
c. Regra 3 – Grupos do Active Directory
Esta regra efetua um query no Active Directory e retorna os grupos em que o usuário faz parte.
Claim rule template: Send Claims Using a Custom Rule
Configure Claim Rule values:
Claim Rule Name: Get Active Directory Groups
Custom Rule: c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”] => add(store = “Active Directory”, types = (“http://temp/variable”), query = “;tokenGroups;{0}”, param = c.Value);
d. Regra 4 – Prefixo
Essa regra converte o valor do grupo do Active Directory começando com o prefixo “AWS-AccountNumber” nas funções conhecidas pela AWS. Para esta regra, precisamos do AWS IdP ARN que anotamos anteriormente.
Claim rule template: Send Claims Using a Custom Rule
Configure Claim Rule values:
Claim Rule Name: Roles
Custom Rule:
c:[Type == “http://temp/variable”, Value =~ “(?i)^AWS-“]
=> issue(Type = “https://thinkwithwp.com/SAML/Attributes/Role”, Value = RegExReplace(c.Value, “AWS-012345678910-“, “arn:aws:iam::012345678910:saml-provider/ADFS01,arn:aws:iam::012345678910:role/”));
* Altere o arn:aws:iam::012345678910:saml-provider/ADFS01 para o ARN do seu IdP.
** Altere o 012345678910 para o ID da sua conta AWS.
7. Ativando RelayState e forms authentication.
Por padrão, o ADFS 3.0 não possui o RelayState ativado. O AppStream 2.0 usa o RelayState para direcionar os usuários para o seu stack. Caso você esteja executando a versão ADFS 4.0, não efetue o procedimento abaixo.
No servidor ADFS, acessamos o servicehostconfig e efetuamos o backup do arquivo antes de qualquer alteração:
%systemroot%\adfs\Microsoft.IdentityServer.Servicehost.exe.config
Dentro do arquivo (abra com permissões administrativas), na sessão “microsoft.identityServer.web”, adicionamos a linha
“<useRelayStateForIdpInitiatedSignOn enabled=”true” />”
8. Versões ADFS 4.0: ao invés de customizar o arquivo acima, basta executar os comandos abaixo.
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
Set-AdfsProperties -EnableRelayStateForIdpInitiatedSignOn $true
9. Reinicie o ADFS
net stop adfssrv
net start adfssrv
Capítulo 5, Criando o RelayState no AppStream 2.0
1. Iremos utilizar a planilha criada neste blog para gerar a URL.
2. Iremos adicionar um usuário de teste no nosso grupo de ExampleStack.
3. Acesse a URL externamente com este usuário.
4. Após a autenticação, o usuário deve ser redirecionado para a console do AppStreams 2.0.
5. Podemos adicionar novos stacks e criar uma granularidade de permissionamento. Por exemplo, se criarmos um novo grupo no AWS Managed AD, nomeando este grupo do AWS Managed Active Directory no formato “AWS-AccountNumber-ExampleStack2”, substituindo AccountNumber pelo seu AWS AccountID (sem hífens) e posteriormente criando o IAM de maneira correta, temos um acesso à um novo stack.
Novo Stack –
AWS Managed AD –
AWS IAM Role –
AWS IAM Policy –
Iremos então testar o login com a URL, que também será alterada pelo fato de que o acesso será feito em outro Stack.
O usuário irá receber a opção de selecionar o Stack para efetuar o login.
Capítulo 6, AppStream 2.0 e o Multi-Forest
Agora que temos nosso ambiente funcionando, vamos configurar a parte de multi-forest.
1. Vá para a floresta de destino (forestB.corp) e selecione a opção “Delegate Control”.
2. Adicione a permissão de leitura para a service account do ADFS (floresta origem) para todos os objetos da floresta target.
3. Iremos criar o grupo do Stack assim como fizemos anteriormente (template de nome).
4. Efetue o acesso com um membro deste grupo, pela URL customizada. Você terá acesso ao stack via internet –
Parabéns! Você está logado com um usuário de uma floresta externa em um AppStream de uma floresta realm gerenciada pelo AWS Managed AD!
Neste post, discutimos a implementação e integração do AppStream 2.0 em um cenário multi-floresta de zero a cem. Para gerenciar este modelo em Produção:
· Utilizamos um certificado wildcard público para o ADFS.
· Utilizamos um Farm de ADFS, para possuir tolerância a falhas.
· Utilizamos 2x servidores com a role de Web Application Proxy (WAP) para publicar o ADFS para a internet. Lembrando que a topologia de rede que possuímos é o ADFS na private subnet conversando com o WAP na pubic subnet em https.
· Publicamos os WAPs via AWS Network Load Balancer, protocolos https e TCP:49443 para a autenticação de certificado.
· Com uma infraestrutura massiva (+5 ADFS Servers), as empresas precisam alterar o modelo de banco de dados do ADFS (Windows Internal Database) para utilizar um banco de dados SQL.
· Existem diversas maneiras de se implementar MFA neste cenário. Seja na camada de ADFS em uma autenticação personalizada / serviços externos ou na camada de Active Directory pela integração do AWS Managed AD com RADIUS.
· Implementamos Group Policy Objects para mais funcionalidades.
Sobre os autores
Caio Ribeiro Cesar atualmente trabalha como arquiteto de soluções especializadas em tecnologia da Microsoft na nuvem AWS. Ele iniciou sua carreira profissional como administrador de sistemas, que continuou por mais de 13 anos em áreas como Segurança da Informação, Identity Online e Plataformas de Email Corporativo. Recentemente, se tornou fã da computação em nuvem da AWS e auxilia os clientes a utilizar o poder da tecnologia da Microsoft na AWS.
Ivan Vargas é Arquiteto de Soluções na AWS focado em empresas no segmento Digital, que já nasceram ou tem a maioria da sua operação na nuvem. Atua auxiliando os clientes desenhando e influenciando soluções baseadas nos serviços AWS. Com mais de 15 anos de experiência em Arquitetura, Desenvolvimento Web e gestão de TI, Ivan atuou em diversos projetos de desenvolvimento e modernização de aplicações.