O que muda no Web Application Proxy do Windows Server Technical Preview

17 de abril de 2015 Deixe um comentário

Saudações,

Desde Julho de 2014 comecei uma série de posts falando sobre a nova funcionalidade de proxy reverso para substituir o Forefront TMG – Web Application Proxy.

Desde então foram duas palestras (MVP Show Cast e Quintas da TI), diversos artigos postados neste espaço, FastVue, Microsoft Curah e TechNet Wiki que buscaram mostrar porque o uso desta funcionalidade agrega valor e reduz custos.

Hoje quero mostrar as mudanças que foram implementadas na funcionalidade com a chegada do novo Windows Server Technical Preview.

Antes de qualquer coisa, quero registrar que as informações abaixo tem como origem o documento What’s New in Web Application Proxy in Windows Server Technical Preview

1. Pre-autenticação para publicação de aplicações em HTTP Basic

O HTTP Basic é um protocolo de autorização usado por muitos outros protocolos, incluindo ActiveSync, para conexão de smartphones ou tablets, com seu mailbox do Exchange. Atualmente o Web Application Proxy interage tradicionamente com o AD Federation Services com redirecionamentos não suportados com clientes ActiveSync.

Na nova versão do Web Application Proxy o administrador tem suporte para publicação de aplicações usando HTTP basic através de um redirecionamento non-claims no relying party trust do Active Directory Federation Service.

Para mais informações sobre publicação HTTP basic, vá em Publishing Applications using AD FS Preauthentication.

2. Publicação de aplicações no padrão Wildcard domain

Para suportar cenários envolvendo SharePoint 2013, agora é possível publicar múltiplas aplicações com uma única URL externa apontando para um domínio específico, por exemplo, https://*.uilson.net. Desta forma, a publicação de aplicações do SharePoint fica mais simples e rápido.

3. Redirecionamento HTTP para HTTPS

Para garantir que os usuários acessem uma aplicação HTTPS, mesmo digitando HTTP na barra de endereços do browser, a nova versão do Web Application Proxy vem com suporte de redirecionamento HTTP para HTTPS.

Exemplo – http://app.uilson.net ==> https://app.uilson.net

4. Publicação HTTP

Na nova versão do Web Application Proxy você poderá publicar aplicações HTTP usando pre-autenticação pass-through.

5. Publicação do Remote Desktop Gateway

Para detalhes desta nova funcionalidade clique em Publishing Applications with SharePoint, Exchange and RDG

6. New debug log for better troubleshooting and improved service log for complete audit trail and improved error handling

Para detalhes desta nova funcionalidade clique em Troubleshooting Web Application Proxy

7. Administrator Console UI improvements

Uma interface melhorada para facilitar a criação e administração do ambiente de aplicações publicadas.

8. Propagation of client IP address to backend applications

Com esta nova funcionalidade, os desenvolvedores poderão incluir em suas aplicações informações sobre o IP real de origem de um determinado acesso. Esse tipo de informação era possível no TMG, porém, envolvia uma série de verificações a serem feitas no ambiente. Neste caso, fica mais simples e rápido.

Com as informações acima, você pode acessar o site da Microsoft, baixar o último build do Windows Server Technical Preview, montar a infra estrutura que deverá seguir os passos listados neste artigo que escrevi para o TechNert Wiki e testar os itens listados.

Estou devendo para os leitores e seguidores deste blog as demonstrações práticas de posts anteriores. Assim que conseguir montar uma nova infra de laboratório estarei fazendo todas e publicando no TechNet Wiki.

Espero poder contribuir para o aprendizado de vocês!

Abraços

Uilson

Resumo e video da palestra sobre Web Application Proxy no Quintas da TI

30 de março de 2015 Deixe um comentário

Saudações,

No dia 19 de março deste ano, 20 e poucos colegas compareceram a minha palestra sobre Web Application Proxy no Quintas da TI.

Falamos teoricamente sobre a feature, como era no AD FS Proxy, como fazer o sizing, as melhores práticas na montagem da infra estrutura, dicas para quem ainda usa o Forefront TMG como proxy reverso e o passo a passo a instalação da feature, além de alguns comandos Power Shell para otimização de tarefas.

Como estou atualmente sem estrutura própria para montar o laboratório de demonstrações, quero deixar aqui minha intenção de retornar um outro dia com um conteúdo mais prático para que todos possam ver, diretamente no Windows Server 2012 R2, como se monta o ambiente.

Conforme combinado, estou deixando aqui link para acesso ao PPT:

http://pt.slideshare.net/uilsonsouza/proxy-reverso-com-web-application-proxy

Podem usar a vontade as informações contidas nos slides.

Além disso, o video da palestra já foi disponibilizado pelo pessoal do Quintas da TI. Se você não teve a chance de estar conosco ao vivo, pode rever na integra clicando no link abaixo:

https://www.youtube.com/watch?v=25kJ3j0ctN8

Se tiverem dúvidas acerca do conteúdo, terei o maior prazer em responder os questionamentos. Podem me contatar através dos comentários deste post!

Abraços

Uilson

CategoriasNão categorizado

Não perca minha palestra sobre Web Application Proxy no Quintas da TI

9 de março de 2015 Deixe um comentário

Saudações!

Mais uma vez tive a honra de ser convidado pelo pessoal do Windows Study Group para palestrar no evento online Quintas da TI.

Para quem ainda não sabe, este evento tem sido realizado já a alguns anos e tem sido um grande sucesso de audiência por parte da comunidade técnica e também traz uma série de grandes palestrantes com conteúdos valiosos para nosso aprendizado.

Este ano, vou repetir a palestra que apresentei no MVP ShowCast 2014 – Web Application Proxy.

Quem participar do evento ficará por dentro de todos os detalhes desta feature que venho mostrando em diversos artigos técnicos, posts e curations desde meados de 2014.

Vamos falar de como fazer o design, deployment e os tipos de publicação. Veremos como se dá a relação do WAP com o AD Federation Services, quais as dependências e no fim vou deixar uma vasta documentação para estudo.

Os leitores deste blog tem acompanhado aqui e no TechNet Wiki uma série de posts sobre Web Application Proxy e AD Federation Services no que tange a publicação de aplicações corporativas e sobre como substituir a parte de reverse proxy do Forefront TMG com esta feature que vem junto com o Windows Server 2012 R2.

Para se inscrever na minha palestra clique na figura abaixo:

palestra_quintas

Terei também a honra de entregar este webcast tendo o amigo Thiago Guirotto como moderador e também colaborando no conteúdo técnico da apresentação.

Além da minha palestra, outras também estão sendo entregues e eu, no seu lugar, não perderia nenhuma delas. Todas com conteúdo excelente e palestrantes da mais alta qualidade. Clique na figura abaixo para acessar o site do evento e se inscrever na palestra que for da sua conveniência:

image

 

Espero ter sua presença na palestra e peço que prestigiem os outros colegas. Você só tem a ganhar!

Vejo você lá!

Abraços

Uilson

CategoriasNão categorizado

Web Application Proxy – Backup e Restore de publicações

25 de fevereiro de 2015 Deixe um comentário

Saudações,

Demorei um pouco a escrever mais por algumas mudanças que estão ocorrendo, mas, vamos lá!

Antes de entrar no assunto principal deste post, quero compatilhar o link para um post no Application Proxy Blog. Nele você verá um anúncio com mudanças no Azure AD Application Proxy.

Se você acompanhou minha palestra no MVP Show Cast em 2014, viu que, dei uma introdução sobre esta que nada mais é que uma versão do WAP dentro do Azure.

O post fala acerca das mudanças que foram implementadas na funcionalidade, sendo uma delas muito legal! Até o lançamento desta versão, só podia usar o Azure AD App Proxy quem tinha a subscription Premium do Azure Active Directory.

A partir de agora, os clientes que usam a subscription Basic também terão direito a usar a ferramenta.

Uma excelente novidade entre outras tantas que foram implementadas e que você pode conferir no link abaixo:

http://blogs.technet.com/b/applicationproxyblog/archive/2015/02/23/new-azure-ad-application-proxy-features-are-now-available.aspx

Vamos entrar no assunto! Como no TMG, o Web Application Proxy também dá a opção de gerar um arquivo XML com tudo que foi publicado na feature.

Se formos pensar no backup de publicações, já adianto que não existe a necessidade de fazer nada no servidor do WAP Server. Uma vez que o mesmo usa o AD Federation Services como base de dados, tudo que você publicou estará ali e a preocupação principal fica em como manter uma cópia desta base de dados, seja ela a partir do Windows Internal Database ou por um servidor SQL Server (dependendo do tamanho da sua infra).

Entretanto, para casos em que você precisa testar publicações e/ou alterar as existentes (o que, nesta versão do WAP só é possível fazê-lo apagando e recriando a publicação), o procedimento de export e import ajuda muito até mesmo para evitar que uma mudança destas afete posteriormente o acesso ao back end server.

Neste post irei mostrar os comandos usados para export e import de publicações e posteriormente, irei fazer um laboratório que será publicado no TechNet Wiki.

Vamos lá:

Este procedimento é possível a partir de cmdlets do Power Shell, sendo que, os comandos para import/export de publicações, além de muitos outros que podem ser usados para o Web Application Proxy são listados no link abaixo:

http://blogs.technet.com/b/applicationproxyblog/archive/2014/08/20/web-application-proxy-powershell-cheat-sheet.aspx

Para exportar as publicações criadas em seu WAP Server use o exemplo abaixo:

Get-WebApplicationProxyApplication | Export-Clixml "ExportedApps"

Para importar a partir do xml criado no exemplo acima, use a sintaxe abaixo:

Import-Clixml "ExportedApps" | Add-WebApplicationProxyApplication

Aparentemente não existe uma linha de comando para export/import de uma única publicação (esterei vendo isso e retorno aqui).

Reiterando o que disse acima, farei um laboratório mostrando o uso destes comandos na prática no TechNet Wiki.

Espero que o conteúdo possa ajudar!

Abraços

Uilson

CategoriasNão categorizado

Introdução ao AD FS Extranet Lockout

12 de janeiro de 2015 Deixe um comentário

Saudações! Um feliz 2015 a todos!

Em continuidade a série de posts que venho publicando aqui e no TechNet Wiki sobre AD FS e WAP, vou dar uma pequena introdução sobre a feature AD FS Extranet Lockout.

Para quem segue o meu blog, publiquei nos meses de agosto e outubro de 2013 alguns posts sobre a funcionalidade do Account Lockout que vinha no SP2 do Forefront TMG. Clique aqui para ler o post (nele você tem o link para o outro que publiquei e também um outro que foi para o TechNet Wiki).

Pois bem, para quem leu, ou se lembra, a funcionalidade foi criada para cobrir um problema que começou a ocorrer nos acessos externos que usam autenticação de domínio.

Um acesso ao OWA ou uma aplicação publicada no AD Federation Services poderia bloquear a conta do usuário no caso de digitar a senha errada mais vezes do que a política do domínio local permite. Isso normalmente ocorre quando o usuário altera a senha em seu notebook ou desktop e se esquece de faze-lo em um dispositivo externo como tablet ou smartphone. Outra forma é por um ataque usando o dispositivo externo e as tentativas de acesso extrapolam o limite estabelecido.

Em resumo, a idéia desta feature, tanto para o AD FS quanto para quem usa Forefront TMG, é fazer com que o bloqueio do acesso ocorra no servidor de reverse proxy e não no domínio interno evitando problemas na conta do usuário no Active Directory.

Então vamos lá, como isso funcionaria em um ambiente de proxy reverso com WAP e AD FS? Assim como no TMG, você deverá usar comandos PSH (Powershell) para configurar a funcionalidade.

No seu servidor AD FS, abra o Power Shell (de preferência com Run as Administrator) e execute o comando “get-adfsproperties”.

O retorno trará todas as informações de configuração do AD FS. No fim da tela vc verá os parâmetros que devem ser configurados:

image

ExtranetLockoutThreshold – Neste parâmetro você define a quantidade de tentativas que o AD FS irá permitir antes de bloquear o acesso. Funciona independente da política de bloqueio de senhas do domínio e, neste caso, recomenda-se que o administrador defina um valor abaixo daquele praticado pelo AD DS. Por exemplo, se o número de tentativas erradas no AD DS está em 5, você poderá definir o ExtranetLockoutThreshold em 4.

ExtranetLockoutEnabled – Este parâmetro é o que ativa a Feature do AD FS Extranet Lockout. Vem por padrão com o valor “False”. Deverá ser alterado para o valor “True”

ExtranetObservationWindow – Uma vez habilitado e definidos os parâmetros acima, o ExtranetObservationWindow define quanto tempo o acesso que extrapolou as tentativas pré-definidas ficará bloqueado. Vem por padrão o valor de 30 minutos. Este tempo já é suficiente, entretanto, você deverá defini-lo de acordo com as políticas de sua organização.

Na prática, use os comandos abaixo para habilitar e configurar a feature:

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow ( new-timespan -Minutes 30 )

No comando acima vemos que a feature do AD FS Extranet Lockout foi habilitada e estará sendo acionada após 15 tentativas erradas de senha e o bloqueio ficará ativo por 30 minutos. Ratificando que os valores expostos são apenas exemplos.

Lembrando que é essencial que o servidor possua instalado o KB2971171, pois, corrige um bug no parâmetro badPwdCount que contabiliza os acessos com senha errada.

Se você ficou interessado neste assunto, além de testar em seu laboratório, você poderá ler o post que irei publicar no TechNet Wiki dentro de alguns dias com um passo a passo de como configurar essa feature.

Como base de estudo usei o artigo abaixo para escrever este post:

http://technet.microsoft.com/en-us/library/dn486806.aspx

Espero que o conteúdo possa ser útil e daqui a alguns dias irei postar o laboratório prático no TechNet Wiki.

Abraços

Uilson

TechEd North America 2014 – Tudo sobre ARR, WAP e AD FS

10 de dezembro de 2014 Deixe um comentário

Saudações,

Depois de alguns dias extremamente ocupado, voltamos aqui pra continuar nossa série de posts em que foco no aprendizado do AD Federation Services 3.0 e Web Application Proxy.

Hoje quero deixar como presente de fim de ano uma série de links onde você poderá ter acesso aos conteúdos referentes a AD Federation Services e Web Application Proxy que foram apresentados no TechEd North America de 2014.

Abaixo os links para diversos HOL (Hands On Lab) e videos das sessões em que foram tratados temas como WAP, ADFS, Claims-Aware, entre outros que estão disponíveis no site do Channel9:

HOL – Application Request Routing – ARR – Neste Lab você aprende a instalar e configurar o Application Request Routing para publicar o Lync Server.

HOL – Windows Server 2012 R2 – Implementing Claims-aware Applications – Neste lab, você aprende como configurar e implementar a nova feature de proteção de acessos e informações no Windows Server 2012 R2 incluindo WorkPlace Join e Seamless Second Factor Authentication.

HOL – Windows Server 2012 R2 – New features in Active Directory Federation Services – O Active Directory Federation Services (AD FS) usa claims-based authentication para prover single sign-on (SSO) web-based access para recursos internos em um parceiro federado ou na núvem. No Windows Server 2012 R2, o AD FS traz diversas novas funcionalidades, incluindo device registration (Workplace Join) para autenticação de dispositivos e SSO, melhorias na multi-factor authentication para gerenciamento de riscos, customização simplificada do processo de autenticação, além da possibilidade de oferecer a opção de alteração de senha para o usuário quando um dispositivo registrado está sendo usado.

Neste você aprenderá como configurar o AD FS para habilitar o Workplace Join, configurar um relying party trust, configurar o  Web Application Proxy habilitando o AD FS para clientes externos, customizar a página de sign-in do AD FS, melhorando a experiência do usuário, habilitar a alteração de senha para dispositivos registrados e configurar multi-factor authentication.

Video – Troubleshooting Active Directory Federation Services (AD FS) and the Web Application Proxy – Aprenda como efetura a análise de problemas no AD FS e no WAP.

Video – Publishing Microsoft Exchange Server: Which TLA Should You Choose? – Com a saída do Forefront TMG, veja quais opções você tem para o proxy reverso de sua infra de servidores Exchange.

Video – Introducing Web Application Proxy in Windows Server 2012 R2: Enable Work from Anywhere – Tive a oportunidade de assistir essa sessão remotamente. O conteúdo é excelente e aborda todas as funcionalidades do WAP e também entra na configuração do Azure AD Application Proxy (o WAP dentro do Azure).

Para ver todo conteúdo exposto no TechEd North America 2014 clique aqui.

Espero que o conteúdo seja útil e o ajude no seu aprendizado. Em caso de dúvidas deixe seu comentário!

Bom entretenimento!

Abraços

Uilson

Atenção durante o deployment do WAP e ADFS

6 de novembro de 2014 2 comentários

Saudações,

Em continuidade a série de posts sobre WAP (Web Application Proxy) e ADFS (Active Directory Federation Services), vamos falar sobre alguns percalços que podem impactar no planejamento de sua estrutura de servidores de proxy reverso, bem como no bom funcionamento de seu serviço de federação.

Lembrando que publiquei no TechNet Wiki os primeiros artigos desta série: Implementando o Web Application Proxy e publicando aplicações via WAP no modo Pass-through.

Além desses artigos, publiquei um post nesse blog sobre as correções lançadas para WAP. Vc pode ler o post clicando aqui.

Vamos relembrar alguns conceitos e requisitos do WAP:

1. O WAP precisa do ADFS (Active Directory Federation Services) como base de dados e para os serviços de pré-autenticação (Claims, OAuth, KCD, MFBA, etc)

2. Para que haja comunicação entre eles é necessário exportar o certificado do ADFS e, caso estejam em DMZ´s diferentes, ter as portas 80, 443 e 49443 abertas no firewall

3. O certificado do ADFS pode ser gerado a partir de uma CA interna mesmo (Active Directory Certificate Services). Os certificados das aplicações a serem publicadas também podem ser do mesmo tipo, mas, facilita se for de CA´s externas (CertSign por exemplo). Entretanto, se o uso da CA interna para publicação de suas aplicações for mandatório, você precisa publicar a sua CRL (Certificate Revocation List) e se certificar que, os acessos externos irão ter o certificado ROOT instalado.

Lembrando que a porta 49443 é usada para configurar client certificate authentication. Se você não pretende usar essa funcionalidade, não precisa abrir essa porta.

Alguns problemas que encontrei em laboratórios e também em alguns clientes foram problemas de conexão entre o WAP e o ADFS. No momento da instalação ocorreu o erro abaixo:

An error occurred when attempting to establish a trust relationship with the federation service. Error: The underlying connection was closed: An unexpected error occurred on a send.

Este erro mostra um problema no certificado que foi exportado do ADFS para o servidor do WAP, ou seja, não é possível estabelecer uma relação de confiança entre WAP e ADFS.

Ao olhar o certificado no WAP Server, dá pra notar um pequeno detalhe (mas que diz tudo):

image

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Nesse ponto encontramos a razão do problema, mas, como se corrige isso?

Veja bem, o certificado na figura acima não contem a chave privada. Pra ter certeza, você faz um novo export a partir do ADFS e constata que a chave privada não pode ser exportada.

Chega-se a conclusão de que antes do ADFS ser instalado, um certificado para ele foi requisitado na CA interna, porém, no momento da requisição do certificado não foi selecionada a opção de fazer a chave privada ser exportável:

image

Desta forma, vemos que o problema maior do pensávamos e a solução se dá em algumas alterações no próprio ADFS. Veja abaixo como o ADFS controla esta parte de certificados:

 image

Com base na figura acima, vemos que o ADFS usa o certificado gerado para 3 finalidades – Service Communications, Token-decrypting e Token-signing. A comunicação entre WAP e ADFS se dá através do Service Communications. Para resolver este problema e outros que possam a vir a ocorrer por conta disso, é necessário seguir os passos abaixo:

* Gerar um novo certificado para o ADFS a partir do Snap-In “Certificates”, solicitando a partir da sua CA interna e com a chave privada exportável

* Alterar o certificado usado pelo Service Communications: Na figura acima, lado direito, Sessão “Actions”, opção “Set Service Communications Certificate”. Surgirá uma tela com os certificados instalados localmente e você escolhe aquele que foi gerado com a chave privada exportável.

Resolvido? Não!!! Além dos passos acima, é necessário executar comandos de power shell para que a alteração feita no ADFS, reflita no arquivo http.sys (responsável pelo gerenciamento da parte de certificados)

Para esta finalidade é necessário usar o CmdLet Set-AdfsSslCertificate para definir o novo certificado gerado para o ADFS. Além disso, você irá precisar do ThumbPrint number (a identificação do seu certificado). Na figura abaixo você verá como coletar essa informação:

image

Agora execute o comando abaixo para alterar o certificado no http.sys:

Set-ADFSCertifcate -CertificateType Service-Communication -Thumbprint xxxxxxxx

O mesmo procedimento deve ser adotado para alterar o certificado do Token-decrypting e Token-signing. Não se esqueça de exportar o certificado novo para o servidor do Web Application Proxy (com a chave privada).

Se você instalou seu ADFS somente para esta finalidade e está no começo do seu deployment, vc pode também remover o ADFS e reinstala-lo ao invés de usar os passos acima.

Uma previsão que me foi dada pelo pessoal de desenvolvimento do ADFS é que, para a próxima versão, o http.sys já entenda a alteração de certificado feita na interface gráfica do ADFS, poupando assim tempo do administrador.

Outro fator, embora pequeno, que causou problemas em cliente foi no momento da configuração do Web Application Proxy. Em determinado momento você precisa dizer ao WAP qual será o ADFS Server que ele irá usar como base de dados e para pré-autenticação:

image

Alguns erros de instalação e falha de comunicação ocorriam porque o Federation Service name não está sendo corretamente declarado (vide figura acima).

No campo “Federation Service name” você tem que colocar o nome que criou para seu ADFS (adfs.domínio.com ou federation.dominio.com, etc). O erro ocorria porque em alguns casos, era colocado o FQDN do servidor e aí, não era possível estabelecer a comunicação entre o servidor WAP e o ADFS.

Espero que o post possa ser útil e ajudar aqueles que estão pensando em usar o WAP como proxy reverso.

Abraços

Uilson

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 954 outros seguidores

%d blogueiros gostam disto: