Archives mensuelles : juin 2015

Mise en œuvre de la Remote Desktop Gateway pour Windows Azure Pack.

Lors de ma série Windows Azure Pack – IaaS : Introduction, j’avais fait l’impasse sur un sujet, la configuration de la Remote Desktop Gateway.

�

J’avais laissé le sujet de côté car, il impliquait un peu plus de travail et surtout l’introduction d’un nouveau composant dans ma maquette : Remote Desktop Gateway. Fournir un accès directe aux machines virtuelles des locataires n’étant pas envisageable d’un point de vue sécurité, il était nécessaire de fournir un intermédiaire qui puisse s’assurer que le locataire ne puisse accéder qu’à ses machines virtuelles. A la différence de Microsoft Azure, Windows Azure Pack propose deux types d’accès :

Remote Desktop
Console

�

L’accès console est une nouveauté de Windows Server 2012 R2 aussi nommée « Enhanced session mode« . La fonctionnalité est intéressante car elle propose un accès RDS à la machine virtuelle via l’hôte Hyper-V. Cela signifie que même si la machine virtuelle ne dispose pas de connectivité Internet, on peut quand même y accéder.

�

Pour mettre en œuvre cela implique une authentification basée sur un certificat client. On va donc beaucoup parler de certificats dans ce billet et accessoirement de Remote Desktop Gateway interfacé avec notre SCVMM favoris. C’est une histoire de confiance car ce certificat permettra à notre Remote Desktop Gateway de s’authentifier auprès des hôtes Hyper-V, le tout piloté par SCSM. La mise en place se déroule en quatre étapes :

La mise en place du gabarit de certificat
Configuration de l’infrastructure SCVMM
Mise en place de la Remote Desktop Gateway
Reconfiguration de Windows Azure Pack
Expérience utilisateur

�

La mise en place du gabarit de certificat

La partie fun, c’est par quel tour de magie la Remote Desktop Gateway va être ne mesure de savoir sur quel hôte Hyper-V est hébergé la machine virtuelle demandée et comment elle va s’authentifier. Tout commence avec le portail des locataires qui présente aux utilisateurs uniquement la ou les machines virtuelles auxquelles ils ont accès. Lorsque l’utilisateur demande l’accès à un de ses machines virtuelles, il faut générer un fichier RDS qui sera mis à disposition de l’utilisateur. C’est la Remote Desktop Gateway qui va s’occuper de cela.

�

Pour éviter que tout le monde de puisse demander à générer un fichier RDS, Microsoft utilise un certificat délivré par une autorité de certification interne. Il sera propagé à tous les hôtes Hyper-V grâce à SCVMM et consommé sur la Remote Desktop Gateway pour son usage « Client-Authentication ». On va donc commencer par générer ce gabarit de certificat un peu particulier car :

L’usage du certificat est limité à l’infrastructure Windows Azure Pack, il n’a pas besoin d’être reconnu à l’extérieur
Le certificat doit être exportable (avec sa clé privé)
Il doit impérativement supporter SHA256
Il doit référencer « Client Authentication » comme Extended Key Usage

�

Parmi nos gabarits de certificats, celui qui se rapproche le plus de cela, c’est le « Workstation authentication », il dispose déjà de l’Extended Key Usage dont nous avons besoin.

�

Parce que ce certificat ne sera utilisé que par des systèmes reposant sur Windows Server 2012 R2 (RDS, SCVMM, Hyper-V), on peut se permettre d’utiliser les options les plus avancées.

�

On va nommer le gabarit « RDS Console » et être généreux avec une durée de vie de deux ans.

�

Ensuite, on va s’assurer que ce certificat puisse être exportable avec sa clé privée. C’est essentiel car le certificat sera mis en place sur le ou les serveurs SCVMM ainsi que sur tous les serveurs Hyper-V.

�

Ici, l’essentiel, c’est que les demandes de certificats utilisent le fournisseur « Microsoft Enhanced RSA and AES Cryptographic Provider ». C’est une exigence de Windows Azure Pack.

�

Le nom indiqué dans le certificat étant un nom dépendant du DNS public, il est nécessaire de reconfigurer le gabarit de certificat pour qu’il utilise les informations contenues dans la demande de certificat et non pas le FQDN déclaré dans l’annuaire Active Directory.

�

Après, y a plus qu’à s’assurer que l’on puisse soumettre une demande de certificat.

�

Reste plus qu’à publier ce gabarit de certificat pour que nous puissions soumettre notre demande de certificat.

�

Configuration de l’infrastructure SCVMM

L’infrastructure SCVMM sera chargée de propager le certificat vers tous les hôtes Hyper-V. Ce sera donc sur ce serveur que nous allons réaliser la demande de certificat. Par contre, la demande est un peu particulière car sans notre intervention, le système d’exploitation n’est pas en mesure de la compléter. Il a besoin de notre aide.

�

On va commencer par compléter le subject Name. C’est un Common Name qui référence le nom public de ma RDS Gateway, donc CN=rdg.windowsazurepack.fr.

�

Ais-je besoin de Subject Alernative Name? Oui, si je suis en haute disponibilité. Dans ce cas, on ajoute aussi les FQDN de chaque serveur RDS Gateway impliqué dans la fermez ainsi que le nom associé à la VIP qui est utilisé pour la haute disponibilité (NLB/HLB). Ce n’est pas obligatoire mais pour d’y retrouver, le Friendly Name, c’est toujours bien.

�

La demande est maintenant complète, on peut la soumettre à notre autorité de certification interne.

�

Maintenant la subtilité. Ce certificat sera utilisé par SCVMM mais aussi par les hôtes Hyper-V. Il faudra donc le mettre à disposition de SCVMM au format PFX (avec la clé privée). Ce même certificat sera aussi utilisé par notre RDS Gateway (ou ferme RDS en cas de haute disponibilité). Pour cet usage, pas besoin de clé privée.

�

Pour la mise en place dans SCVMM, ça passe par un peu de Powershell. On indique à VMM que nous allons utiliser le même certificat sur SCVMM et sur les hôtes Hyper-V et que ce certificat est disponible dans un fichier PFX sécurisé par un mot de passe.

$Password = ReadHost -AsSecureString

$VMMServer = « SCVMM.WINDOWSAZUREPACK.LAN »

$PFX = « C:\TEMP\RDSConsole.PFX »

Set-SCVMMServer -VMMServer $VMMServer -VMConnectionHostIdentificationMode FQDN -VMConnectionGatewayCertificatePath $PFX -VMConnectGatewayCertificatePassword $Password -VMConnectHyperVCertificatePath $PFX -VMHyperVCertificatePassword $Password -VMConnectTimeToLiveInMinutes 1

�

Qu’est-ce que cela change sur nos Hyper-V? Déjà, il est présent dans le magasin personnel de tous les Hyper-V dépendant de mon infrastructure SCVMM

Get-ChildItem Cert:\LocalMachine\My -EKU « Client Authentication »

�

Puis nos Hyper-V ont été configurés pour ne reconnaître que l’empreinte numérique du certificat que nous allons utiliser. Seul lui sera utilisable pour l’Enhanced session mode.

Get-WMIObject -ComputerName $Env:ComputerName -Namespace « Root\Virtualization\V2″ -Class MSVM_TerminalServiceSettingData »

�

Au passage, petit rappel, ce ne sera pas le protocole RDS qui sera utilisé mais VMConnect (port 2179).

�

Mise en place de la Remote Desktop Gateway

Commençons avec le plus facile, avec la mise en place du rôle « Remote Desktop Gateway » sur un serveur dédié, membre de notre domaine. Il sera présenté sur Internet sous le nom de rdg.WindowsAzurePack.Fr, avec uniquement el flux HTTPS exposé. Qui dit HTTPS, dit certificat SSL mis en place sur le serveur avant de commencer. Coté mise en œuvre, c’est un sous-rôle du Remote Desktop Services (Nous sommes bien dans l’installation d’un rôle et non pas dans un déploiement RDS).

�

Lorsqu’on sélectionne le sous-rôle « Remote Desktop Gateway », il va automatiquement installer les composants dépendants (NPS, RPC over HTTP Proxy et le Web Server pour porter le tout). Nos locataires vont arriver en SSL, c’est la Gateway qui se chargera d’établir la connexion RDS pour leur compte vers les hôtes Hyper-V hébergeant la machine virtuelle demandée.

�

Une fois l’installation terminée, on lance la console RD Gateway. Elle nous indique tout de suite ce qui manque.

�

Plus précisément, le certificat utilisé par la Gateway pour sécuriser les connexions SSL. On va donc sélectionner le certificat que nous avons préalablement importé.

�

Vu que nous avons respectés les prérequis, le certificat avec le rôle attendu est déjà présent dans le magasin personnel du serveur. A noter que dans une mise en œuvre en haute disponibilité, le certificat devra être présent sur tous les serveurs de la ferme.

�

A ce stade, notre Remote Desktop Gateway est opérationnelle pour un usage RDS standard.

�

Je dis bien standard car le mode « Enhanced session » est un peu particulier. Nous avons besoin d’un composant additionnel présent sur le média d’installation de SCVMM 2012 R2, le System Center Virtual Machine Manager Console Gateway. Ce package est disponible sur le média d’installation du SCVMM 2012 R2 dans le répertoire AMD64\Setup\Msi\RDGateWayFedAuth.

�

Normalement, le rôle de la RDS Gateway est d’authentifier les utilisateurs avant qu’ils n’accèdent aux sessions RDS. Problème, dans le contexte de Windows Azure Pack, notre RDS Gateway n’a aucune idée du fournisseur d’identité à solliciter. Le package va donc modifier le mode de fonctionnement de la RDS Gateway pour réaliser une authentification à base de certificat.

�

Maintenant, on va commencer à transpirer un peu. Pour commencer, on va importer le certificat que nous avons obtenu sur le serveur SCVMM. Par contre, on n’a pas besoin de la clé privée qui va avec cette fois. Le certificat (livré au format CER) devra être importé dans le magasin « Local machine » du serveur Remote Desktop Gateway. La commande PowerShell Import-Certificate fera tout aussi bien l’affaire.

�

Note : Si plusieurs RDS Gateway (ferme RDS) alors, il faudra le faire sur tous.

�

C’est là que cela se complique. Il faut configurer la RDS Gateway pour utiliser notre certificat nouvellement importé. Il a une caractéristique bien précise : un EKU bien particulier. C’est ce que nous allons rechercher :

Get-ChildItem Cert:\LocalMachine\My -EKU « Client Authentication »

�

On va conserver cette information, elle va resservir immédiatement. Nous allons reconfigurer la RDS Gateway pour utiliser ce certificat. Pour la méthode, je ne l’invente pas, c’est repris du Technet : « Remote Console in System Center 2012 R2 »

$Thumbprint = « 43C301991A44386C08A8D2998AFD2CCDE74FB777 »

$TSData = Get-WmiObject -computername $Env:ComputerName -NameSpace « root\TSGatewayFedAuth2 » -Class « FedAuthSettings »

$TSData.TrustedIssuerCertificates = $Thumbprint

$TSData.Put()

�

Note : Attention, dans le contexte d’une ferme RDS, c’est sur chaque nœud qu’il faudra exécuter le script.

�

Reconfiguration de Windows Azure Pack

La reconfiguration dans Windows Azure Pack se déroule à deux niveaux. Au niveau du VM Clouds, on va renseigner notre nouvelle Remote Desktop Gateway.

�

Ou plutôt on devrait car il y a un petit bug à ce niveau. Lors de la rédaction de ce billet, je suis tombé sur un problème à ce niveau. Une fois la Remote Desktop Gateway déclarée depuis le portail d’administration de Windows Azure Pack, j’ai rapidement constaté que le Resource Provider VM Clouds ne répondait plus, que ce soit dans le portail d’administration ou celui des locataires. Après de nombreuses recherches, le problème se situait au niveau des informations enregistrées dans Service Provider Foundation (doublons). Mes recherches m’ont menées vers un excellent billet VM Cloud is missing in Windows Azure Pack. C’est une situation qui survient lorsqu’on déclare la RDS Gateway ultérieurement (comme c’est le cas de ce billet) ou lorsqu’on modifie la configuration existante à ce niveau. Donc dans notre cas on va suivre la démarche proposée par Kristian Nese, en PowerShell, depuis le serveur sur lequel est installé Service Provider Foundation :

Import-Module SPFAdmin

Get-SCSPFServer

$Stamp = Get-SCSpfStamp

$rdgw = « rdg.Windowsazurepack.Fr »

New-SCSPFServer -Name $rdgw -ServerType RDGateway -Stamps $Stamp

Get-SCSPFServer

�

De cette manière, on évite de se retrouver avec des doublons. Après cet interlude, c’est au niveau des souscriptions qu’il faut intervenir. Pour chaque souscription proposant le fournisseur « VM Clouds », il faut s’assurer que la case d’option « Connect to the console of virtual machines » est bien activée.

�

Expérience utilisateur

Coté locataire, c’est Client RDS 8.1 (Donc Windows 8.1) ou l’installation de la KB2830477 pour les clients Windows 7 obligatoire. Voilà pour les prérequis. Après le changement, c’est dans le portail des locataires qu’on le verra avec une option « Connect » qui est maintenant disponible pour ses machines virtuelles.

�

Lorsqu’il utilise l’option Console, il faut noter une information importante. C’est le fichier RDS qui donne accès réseau à l’hôte Hyper-V hébergeant la machine virtuelle du locataire. Donc ne pas laisser trainer ce fichier.

�

Un fichier RDS nous sera proposé. On voit bien qu’on passe par la Gateway RDS pour accéder à un hôte Hyper-V en particulier dans ma plateforme Windows Azure Pack.

�

Lorsque nos locataires vont se connecter, la Gateway n’est pas en capacité de traiter l’authentification. C’est là qu’invertirent le package System Center Virtual Machine Manager Console Gateway que nous avons installé. L’authentification est réalisée avec le certificat que nous avons mis à disposition sur la Remote Desktop Gateway.

�

L’hôte Hyper-V reconnaissant aussi ce certificat l’authentification est acceptée. On notera que la connexion initiée est bien en RDS mais pas sur le port attendu. C’est normal car c’est une session VMConnect.

�

L’option « Desktop » est un peu moins intéressante car elle propose un accès direct sans passer par la Remote Desktop Gateway. C’est donc beaucoup moins intéressant, sauf si une Gateway NVGRE est en place.

�

Conclusion

D’un point de vue sécurité, l’option console est bien plus intéressante puisque tous les connexions doivent nécessairement passer par la Remote Desktop Gateway. Elle assure aussi une rupture protocolaire car les clients se connectent à la Remote Desktop Gateway en HTTPS, pas en RDS. Subtilité supplémentaire, ce n’est pas une connexion RDS (port TCP/UDP 3389) qui est initiée mais une session VMConnect (port 2179). Enfin, parce qu’on se connecte à l’hôte Hyper-V pour accéder à la VM et non à la VM directement, on est en mesure d’accéder à la VM même si celle-ci n’est pas sur un réseau routable ou n’a pas de carte réseau.

�

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

�

Forefront Unified Access Gateway 2010 Service Pack 4 Rollup 2

Laisser un commentaire

It’s been a while since last rollup for Microsoft Forefront UAG 2010. These days, Microsoft does not abandon customers using legacy products and continue to deliver hotfix. These days, Microsoft delivered Rollup 2 for Forefront Unified Access Gateway 2010 Service Pack 4. It include the following hotfixes :

KB3066351 FIX: Client HTTP connections to the Unified Access Gateway redirect trunk receive errors after you install Rollup 1 for Forefront Unified Access Gateway 2010 Service Pack 4
KB3070067 FIX: « Error HTTP 503: The Service is unavailable » error when the connection to the UAG trunk fails in Forefront Unified Access Gateway 2010 Service Pack 4
KB3068283 FIX: « HTTP 503 » errors on a server that is running Forefront Unified Access Gateway 2010 Service Pack 4
KB3068289 FIX: Moving mailboxes as part of a hybrid Office 365 migration fails in Forefront Unified Access Gateway 2010 Service Pack 4

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Monitoring DirectAccess with Kemp

Laisser un commentaire

Introduction

DirectAccess is a wonderful remote access solution highly appreciated by end-users, happy they are to do not have to understand how it works, it just work. On the other side, we have the network team that is not really happy when they discover that monitoring DirectAccess can become complicated, especially for HLB deployments.

From an HLB point of view, DirectAccess gateways are only HTTPS endpoints. If they respond with an HTTP 200 response code, it means that it’s up and running. In reality it’s much more complicated. DirectAccess rely on multiple components. If a single one come to be unhealthy, DirectAccess is no longer able to operate properly. In many deployments, customers of mine chosen to deploy DirectAccess in HLB scenario such as F5 or Kemp. Those appliances are able to check DirectAccess gateways availability by checking IPHTTPS endpoint. Not easy to monitor.

How to monitor DirectAccess health?

It’s a good question. Microsoft provide the Remote Access Management console, some Powershell Commandlets and a Management Pack. From HLB solution vendor hey only have HTTP response. It appear to be complicated because many network teams consider that they have to discover information by their own way.

It’s time to consider another approach. If HLB solution cannot evaluate the health status of a DirectAccess gateway maybe DirectAccess gateway can provide this information to the HLB solution. Have a look at Exchange 2013 Managed Availability. Exchange 2013 generate probe pages to be used by load-balancer solution. If they can reach the probe page, status is OK. It’s a very interesting approach.

Let’s start see how we can develop the same approach with DirectAccess. If we have a look at the Get-RemoteAccessHealth Powershell commandlet, we got almost all we need. In example bellow, I just filtered relevant components to be monitored :

Get-RemoteAccessHealth -Verbose | Where {$_.HealthState -ne « Disabled »} | Format-Table -Property Component, HealthState – AutoSize

That was only the beginning. While writing this article, a valuable MVP colleague pointed out that we don’t need to consider Network Location Server availability because if it’s not available, it does not disrupt service offered to end-users located outside company building (it’s another problem for users located on corporate network). So we will exclude this component from the tests. Here is the test we will be using to monitor DirectAccess :

Get-RemoteAccessHealth -Verbose | Where {($_.HealthState -ne « Disabled ») -And ($_.Component -Ne « Network Location Server ») -And ($_.Component -Ne « Server »)}

Note : Server was excluded from the list because it does not provide a relevant information for monitoring / troubleshooting.

Once we have relevant monitoring information, next challenge is to provide this information in a comprehensive form for a HLB solution. It’s too complicated to write rule to parse this content, that’s why I was considering the Managed Availability feature of Exchange 2013. As I’m not a dev-guy, I know I could not develop a solution like this. My approach was a little bit more basic :

Status is OK : Create a probe page to be monitored by the HLB solution
Status is not OK : Delete the probe page to be used by the HLB solution

This approach worked, but it was not as elegant as the Managed Availability feature of Exchange 2013. After some discussions with a colleague of mine, he pointed out the availability of a Powershell commandlet for Kemp load balancers. While reading the Kemp documentation, I discovered how easy it was to query and change configuration in Kemp LoadMaster appliance with just some PowerShell commands. If Kemp cannot consume monitoring information my DirectAccess gateway produce, maybe just more simple to change Kemp load balancer configuration.

The Kemp Approach

Kemp provide a pretty good Deployment guide for DirectAccess. I would like to thanks Richard Hicks, valuable MVP working like me on DirectAccess for this excellent contribution. So it was very easy to build an HLB lab in less than two hours. Diagram bellow only focus on high availability for DirectAccess deployment, you can also use Kemp solution to provide high availability for the Network Location Server.

When we setup DirectAccess in HLB scenario, up to height DirectAccess gateway will share a common configuration and some network information :

A virtual Address for the external interface managed by the External load balancer
A virtual Address for the internal interface managed by the Internal Load balancer

In Kemp, load balancing is managed with virtual services. That’s the object I will be looking for in my configuration. But first I need to configure the Web Administrative Access in Kemp as illustrated bellow to enable Kemp API access from the Internal network interface.

Now we can start using PowerShell to authenticate against the Kemp appliance with the Initialize-LoadBalancer Powershell command. We just need to build a secure string for the password. Once authenticated, we can test if communication is established with a Test-ServerConnection command.

$KempAPI = 192.168.2.115″

$KempPort = 443

$KempAdmin = « bal »

$KempPassword = « Password123 »

$SecureString = ConvertTo-SecureString -String $KempPassword -AsPlainText -Force

$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $KempAdmin, $SecureString

Initialize-LoadBalancer -Address $KempAPI, LBPort $KempPort -Credential $credential

Test-ServerConnection -ComputerName $KempApi -Port $KempPort

Note : Watch-out, account is case sensitive!!

It’s time to explore virtual services with the Get-VirtualService Powershell Command :

$VirtualServiceName = « DirectAccess-IPHTTPS »

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}

$VirtualService

We have here some valuable piece of information. First, we know that external VIP is running and directing HTTPS network traffic to some Real Servers. In my environment, I have two DirectAccess gateway configured in a single HLB configuration. So it’s logic to have two real servers behind the external VIP. Let’s have more details about real servers by exploring the Virtual Service Object :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

We just need to be more precise, what is the status of the Real server linked to a specific DirectAccess gateway. We just need to know the external IPv4 address of our DirectAccess gateway. Too easy :

$InternetInterfaceName = (Get-DaServer).InternetInterface

$InternetIPAddress = ((Get-NetIPConfiguration -InterfaceAlias $InternetInterfaceName).IPv4Address).IpAddress

$InternetIPAddress

Now the magic trick

We know the status of our DirectAccess gateway, we know how to query the status of the external VIP and related real servers. Now we just need to be able to change the status of the real server linked to our DirectAccess gateway. In case bellow, I will be considering that my second gateway is no longer able to service end-users. I will be using the Disable-RealServer Powershell Command to disable the linked real server :

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

Disable-RealServer -IpAddress $InternetIpAddress

$VirtualService = Get-VirtualService | Where {$_.Nickname -Match $VirtualServiceName}

$VirtualService

$VirtualService.RS | Format-Table -Property Status, Addr, Port, Enable -AutoSize

Related real service is now disabled on Kemp external load balancer.

Envision the big picture

Before starting developing the big thing, here are the guideline I used to develop my script :

Each DirectAccess gateway will be responsible to evaluate its own status (So script will be running on all DirectAccess gateway composing my HLB deployment)
Each DirectAccess gateway will be updating only linked real server (We’ve just seen how to get it)
Each gateway must manage a « maintenance flag » in order to close service (for patch management for example)
All activity must be logged in event logs in order to keep trace of information in monitoring solution such as SCOM
Keep the script as simple as possible
Script will be relying on Powershell wrapper provided by Kemp

Script is available at this location. It was designed to run as scheduled task on each DirectAccess node involved in an HLB configuration. Script accept the following parameters :

KempAPI : Mandatory parameter that must contain name or IP address of the Kemp LoadMaster with Web Administrative Access enabled
KempPort : Not mandatory parameter, default value is 443
KempAdmin : Mandatory parameter that must contain account with administrative access to Kemp LoadMaster. Watch-out, Kemp is case sensitive for account!!
KempPassword : Mandatory parameter that must contain the password to be used with the KempAdmin parameter
VirtualServiceName : Mandatory parameter that must contain name of the virtual service for the External VIP of DirectAccess

Let’s see some situations. Script detect that DirectAccess node is not healthy and reconfigure real server status to do not forward network traffic to that failing node.

In Kemp management portal, we see that real server corresponding to 192.168.2.211 status is now disabled.

When problem was fixed, script detected that DirectAccess node is now healthy, Real server status for 192.168.2.211 is updated to forward network traffic to restored node.

In Kemp management portal, we see that real server corresponding to 192.168.2.211 status is now Enabled.

So it’s not so complicated to monitor DirectAccess after all.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Web Application Proxy erreur 0x8007520C

Laisser un commentaire

Ça faisait quelques temps que j’avais pas mis les mains dans ma plateforme Windows Azure Pack. C’est lors de la séquence de patch management mensuelle que je suis tombé sur ce problème.

Problème

Mon WAP (Web Application Proxy) qui ne démarrait plus.

Dans les faits, le service ADFS (adfssrv) est bien démarré mais le service Web Application Proxy (AppProxySvc) refuse de démarrer. Il indique même une erreur 401. En cherchant un peu dans le journal « AD FS/Admin », on nous parle d’accès refusé (ce qui correspond au code erreur 401) et d’une empreinte de certificat.

Sur la ferme ADFS, on trouve une erreur en corrélation qui fait référence au même certificat avec la même empreinte numérique.

Analyse

On sait maintenant que cela concerne le certificat « ADFS ProxyTrust -WEBAPPROXY ». On voit bien que cela concerne un certificat auto-signé, dont la durée de vie est de quelques jours (10 jours). Vu que mon infrastructure a été offline pendant plus de 10 jours, il est logique que le certificat ne soit plus valide. Ce qu’on a du mal à comprendre, c’est de ne pas retrouver le certificat en question sur le serveur Web Application Proxy. Avec un peu de lecture ici et là, on finit par tomber sur ce billet de l’équipe produit : Understanding and fixing Proxy Trust CTL Issues with AD FS 2012 R2 and Web Application Proxy.

On y découvre que c’est bien un problème d’authentification par certificat. Le certificat auto-signé généré lors de la configuration du Web Application Proxy doit normalement être injecté dans la configuration de la ferme ADFS ainsi que dans le magasin de certificats AdfsTrustedDevices des serveurs de la ferme ADFS. Allons faire un tour dans le magasin certificats de notre serveur Web Application Proxy pour retrouver notre certificat auto-signé :

Get-ChildItem Cert:\LocalMachine\My | Where {$_.Subject -match « CN=ADFS ProxyTrust »} | Format-Table -Property Subject, NotBefore, NotAfter, Thumbprint -Autosize

Correction

Il y a beaucoup trop de certificats auto-signés. Beaucoup de tentatives pour corriger le problème mais sans résultat. Le message sur la ferme ADFS nous recommande de refaire l’initialisation du Web Application Proxy, c’est ce que nous allons faire. Pour cela un peu de Powershell pour retrouver le certificat public que nous avons utilisé pour publier notre infrastructure ADFS :

Get-ChildItem Cert:\Localmachine\My | Where {$_.Subject -match « CN=adfs.Windowsazurepack.Fr »} | Format-Table -Property Subject, Thumbprint

$Cred = Get-Credential

Install-WebApplicationProxy -FederationServiceName ‘adfs.windowsazurepack.fr’ -FederationServiceTrustCredential $cred -certificateThumbprint ‘XXXXXXXXXXX’

Maintenant le service est de nouveau opérationnel. Sur la ferme ADFS, on peut constater la présence d’un nouveau certificat auto-signé sur notre serveur Web Application Proxy.

On retrouve la trace de ce même certificat auto-signé dans le conteneur ADFSTrustedDevices sur ma ferme ADFS.

Le Web Application Proxy est de nouveau opérationnel.

Dans le journal « AD FS/Admin », on constate la présence de l’évènement 245, qui reviendra cycliquement toutes les minutes. C’est ce qui nous indique que le Web Application Proxy est bien opérationnel pour sa fonction Proxy de l’infrastructure ADFS.

Ainsi que l’Event 396, nous indiquant que le certificat auto-signé nouvellement généré est bien reconnu par notre ferme ADFS pour authentification.

Conclusion

Ce problème amène deux réflexions :

Si votre maquette ADFS n’est pas online en permanence, oubliez le Web Application Proxy dans votre lab.
Quand on va renouveler le certificat public de l’infrastructure ADFS, va y avoir un peu de travail

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Microsoft Local Administrator Password solution

Laisser un commentaire

LAPS ou Local Administrator Password Solution est le nouveau nom pour ADMPWD, une solution développée par un consultant Microsoft dont j’ai déjà parlé ici ou là sur mon blog :

Pourquoi ce changement de nom? Tout simplement par que c’est maintenant une solution intégrée à part entière du système d’exploitation. Ce qui est bien, c’est que Microsoft s’est assuré que ce soit disponible pour le maximum de systèmes d’exploitation : Windows 10 , Windows 7, Windows 8, Windows 8.1, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Vista.

Les contraintes sont toujours les mêmes :

.Net Framework 4.0 minimum
PowerShell 2.0 minimum

La solution n’a pas changé, sinon qu’elle est pleinement supporté par Microsoft puisque maintenant intégrée au système d’exploitation. Seule limite, LAPS ne s’installe pas sur Windows XP, vu que le système d’exploitation n’est plus supporté par Microsoft. Il n’y a donc maintenant plus aucune raison d’installer LAPS alias KB3062591.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Simple and secure by Design but Business compliant [Benoît SAUTIERE / MVP]

With disruptive flag enabled

Archives mensuelles : juin 2015

Mise en œuvre de la Remote Desktop Gateway pour Windows Azure Pack.

Forefront Unified Access Gateway 2010 Service Pack 4 Rollup 2

Monitoring DirectAccess with Kemp

Introduction

How to monitor DirectAccess health?

The Kemp Approach

Now the magic trick

Envision the big picture

Web Application Proxy erreur 0x8007520C

Problème

Analyse

Conclusion

Microsoft Local Administrator Password solution