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

Simple, yes, Secure Maybe, by design for sure, Business compliant always

Common Tasks

Recent Posts

Tags

Community

Email Notifications

Blogs

Archives

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.

clip_image002

 

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.

clip_image004

 

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.

clip_image006

 

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.

clip_image008

 

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

clip_image010

 

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.

clip_image012

 

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.

clip_image014

 

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.

clip_image016

 

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

clip_image018

 

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

clip_image020

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.

clip_image022

 

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.

clip_image024

 

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.

clip_image026

 

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

clip_image028

 

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

clip_image030

 

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"

clip_image032

 

Puis nos Hyper-V ont été configurés pour ne reconnaitre 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"

clip_image034

 

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).

clip_image036

 

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.

clip_image038

 

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

clip_image040

 

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é.

clip_image042

 

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.

clip_image044

 

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

clip_image046

 

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.

clip_image048

 

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.

clip_image050

 

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"

clip_image051

 

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()

clip_image053

 

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.

clip_image055

 

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

clip_image057

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.

clip_image059

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.

clip_image061

 

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.

clip_image063

 

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.

clip_image065

 

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.

clip_image067

 

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.

clip_image069

Conclusion

D'un point de vue sécurité, l'option console est bien plus intéressante puisque toutes 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

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
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

clip_image001

 

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")}

clip_image002

 

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.

clip_image003

 

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.

clip_image004

 

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

clip_image005

 

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

clip_image006

 

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

clip_image007

 

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

clip_image008

 

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

clip_image009

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.

clip_image010

 

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

clip_image011

 

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.

clip_image012

 

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

clip_image013

 

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

Ça faisait quelques temps que j'avais pas mis les main 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.

clip_image001

 

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.

clip_image002

 

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.

clip_image003

 

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

clip_image004

 

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'

clip_image005

 

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.

clip_image006

 

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

clip_image007

 

Le Web Application Proxy est de nouveau opérationnel.

clip_image008

 

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.

clip_image009

 

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.

clip_image010

 

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

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)

Posted: 05-21-2015 19:51 by Benoît SAUTIERE | with no comments
Filed under: ,
Windows Server Techical Preview 2 : Start your engine

Pour l’instant, j’avais pas encore mis les main dans Windows 10. A cela plusieurs raisons :

  • Je passe plus de temps avec la gamme Server et les produits System Center
  • De ce que je comprenais de Windows 10 coté client, les fonctionnalités qui allaient m’intéresser n’allaient être utilisables qu’avec la version serveur qui va avec
  • Windows Azure Pack et Azure m’accaparent
  • J’ai trop de sujets en parallèle, il fallait bien que je choisisse.

 

Mais ce jour, on a enfin accès à une nouvelle Preview (seconde) de ce qui pourrait bien s’appeler Windows Server 2016?. Pour l’instant, c’est disponible sur MSDN. 

image

 

En attendant que le download se termine, je plonge dans le What’s new, il y a plein de lectures intéressantes. Network Controller et Web Application Proxy, me voila. Passage en mode matériel, demain soir, c’est cluster Hyper-V en mode Build Windows Windows Server (2016?).

 

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

Windows Azure Pack - IaaS : Introduction
Introduction

Après s'être torturé l'esprit avec l'authentification et les "Resources Providers les plus simples (SQL, et SMA), il y a un moment où il faut franchir un cap et s'attaquer au IaaS. Si vous êtes toujours là, on va se rapprocher de son grand frère Microsoft Azure. Dans cette série de billets, on va s'attaquer à la configuration du IaaS et faire le viaduc entre Windows Azure Pack et System Center Virtual Machine Manager. Ce sont deux mondes bien différents qui doivent communiquer entre eux au travers d'un nouveau composant nommé Service Provider Foundation.

Pas peur de vous faire mal? Très bien allons y. Que les survivants prennent place dans la salle des tortures.

 

Service Provider Foundation, un viaduc entre deux mondes

Encore une fois, on constate que Windows Azure Pack ne fonctionne pas comme les autres produits de chez Microsoft. C'est est un univers ou les Web Services communiquent entre eux en utilisant le standard Open Data Protocol (OData). Coté Virtual Machine Manager, il parle le PowerShell nativement. Bien, mais pour Windows Azure Pack, ça lui parle pas vraiment. Bref, on a déjà un problème de communication. Il nous faut un traducteur universel (Un genre de C3PO mais qui ne parle que deux langues).

Voilà la mission principal de Service Provider Foundation. Techniquement, il va un peu plus loin que cela mais dans l'idée générale cela reste un passe-plat entre deux mondes. Ce point permet de clore un point. Windows Azure Pack n'a aucune idée de ce qu'est System Center Virtual Machine Manager ni System Center Operation Manager. Pourtant ce sont des composants essentiels dans l'infrastructure.

Maintenant que nous avons compris cela, voyons comment cela s'intègre dans Windows Azure Pack. Pour rappel, nous avons un le Portail d'administration qui communique avec le Web Service "Admin API". Ce même Web Service permet de piloter les "Resources providers" et Service Provider Foundations sera l'un d'entre eux.

clip_image001

Là où cela se complique un peu, c'est que Service Provider Foundation fait un peu plus que traducteur Odata<=>PowerShell. Si on se souvient de l'intégration du "Resource Provider" de SQL Server, on avait les "Resources Providers" suivants :

  • Monitoring
  • MarketPlace
  • UsageService
  • SQLServers

Pour rappel, voilà comment on arrivait à ce résultat :

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL01.WindowsAzurePack.lan

$AdminUri = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL.WindowsAzurePack.lan

$WindowsAuthSiteUri = "https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)"

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm "http://azureservices/AdminSite" -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminURI -Token $token

$Allrp | select name, @{e={$_.AdminEndpoint.ForwardingAddress}},@{e={$_.TenantEndpoint.ForwardingAddress}},@{e={$_.UsageEndpoint.ForwardingAddress}}, @{e={$_.NotificationEndpoint.ForwardingAddress}} | Format-List

clip_image002

 

Note : Ceux qui lisent le PowerShell entre les lignes auront remarqué que j'ai soumis mon authentification auprès du WindowsAuthSite, non pas auprès de l'infrastructure ADFS. C'est normal, j'ai reconfiguré ma maquette pour ne plus utiliser ADFS, que ce soit pour les administrateurs que pour les locataires.

 

Pour SQL Server, nous avions reconfiguré les URL pour les deux portails, la mesure des usages ainsi que pour la notification (notification des jobs en cours dans les portails). Le "Resource Provider" de SQL mettant à disposition des ressources, il est logique qu'il remonte les usages qui en sont fait au "Resource Provider" en question.

Pour Service Provider Foundations, ce n'est pas un "Resource Provider" mais plusieurs :

  • SystemCenter
  • CloudServices
  • Gallery

Le "Resource Provider" SystemCenter, c'est le traducteur universel vers SCVMM. Logiquement, il fournira des éléments pour enrichir le portail des administrateurs, des locataires, des notifications ainsi que l'usage des ressources VM des locataires (monitoring & suivi des usages).

Le "Resource Provider" CloudServices est une équivalence pour la notion disponible dans Microsoft Azure, à savoir exposer des endpoints pour des machines virtuelles. Dans le contexte de Windows Azure Pack, c'est le même principe mais en utilisant SCVMM.

Le "Resource Provider" Gallery est lui dédié au portail des locataires et permet d'exposer les VHD/VHDX et VM templates de la library SCVMM pour permettre aux locataires de créer des "StandAlone virtual machines" voire même des "Virtual Machine Role".

Après, il y a les subtilités car le Service Provider Foundation va aussi fournir des éléments à d'autres "Resource Provider" :

  • Service Management Automation (SMA) va être capable d'exploiter les évènements mis à disposition par Service Provider Foundation pour y associer des Runbooks. Par exemple, il est possible de déclencher l'exécution d'un runbook à la création d'un tenant pour déclencher le provisionnement de certaines ressources (VM Network, Contrôleur de domaine, …)
  • UsageCollector va être capable d'extraire les informations de supervision en provenance de Service Provider Foundation et les stocker dans sa base de données pendant quarante jours (Usage Database). La subtilité, c'est que lui-même sera allé piocher ces informations dans la ou les instances de SCVMM qui elles même auront récupérées l'information depuis SCOM, plus précisément de son Datawarehouse. Vous suivez?

image

 

A la fin, l'objectif est d'exposer toutes les données en relation avec les usages pour produire du reporting ou même de la facturation. On connait maintenant les premiers prérequis pour Service Provider Foundation :

  • System Center Virtual Machine Manager
  • Le Datawarehouse de System Center Operation Manager
  • System Center Operation Manager

 

La suite des réjouissances

On a posé les bases pour cette séance de torture, la suite arrive bientôt :

Entrez dans la salle de torture, le bourreau vous attend, …

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

Windows Azure Pack - IaaS : Création d'un Virtual Machine Role

Félicitations à ceux qui sont arrivés jusque-là, ils ne sont pas nombreux. Ceux qui sont arrivés jusque-là peuvent prétendre créer un Virtual Machine Role. Pour ne pas surcharger cette série de billet, j'ai fait l'impasse sur la création du Virtual Network (ma maquette ne prend pas encore en charge la virtualisation du réseau et la distinction entre Provider Address Space et Customer Address Space), ce sera pour une autre séance de torture. Dans la réalité, le locataire pourrait référencer son propre plan d'adressage et mettre en place une gateway. Les plus téméraires (s'il en reste) pourront consulter l'excellente session TechDays 2014 : Hyper-V Network Virtualization dans WS2012 R2 et SC2012R2. Il faut quand même un peu de travail pour mettre cela en place.

Revenons à l'essentiel et testons le provisioning de d'une Virtual Machine Role. Pour les VM Roles, Windows Azure Pack va s'adresser à au SPF qui va lui-même s'adresser à SCVMM.

clip_image001

 

On va donc déployer le seul Virtual Machine Role à notre disposition dans notre souscription.

clip_image002

 

Notre déploiement doit avoir un nom (comme dans Microsoft Azure), c'est la notion de Cloud Service . On précise aussi la version du rôle à utiliser. Cela a son importance, car le Resource Definition Package référence aussi cette version, tout comme les disques OS et données qui y sont associés. Ils sont été tagués pour ce rôle et cette version.

clip_image003

 

Windows Azure Pack exploite le Resource Definition Package pour proposer des choix au locataire. La Gallery ne proposera que le ou les disques OS/Datas pour lesquels le "Tag" correspond à celui du package.

clip_image004

 

Le paramètre Size est intéressant. Windows Azure Pack nous parle de sizing de machine virtuelle, sauf que ça n'a absolument rien à voir avec les VM templates que nous avons préalablement référencés dans la Gallery. C'est normal, les VM Templates, c'est pour les Standalone Virtual machines. Les VM Roles, c'est comme Microsoft Azure. Donc lorsqu'on utilise les VM Roles, Windows Azure Pack demande au SPF la construction d'une machine virtuelle. Il considère que le Cloud derrière le Service Provider Foundation est un Azure-like qui propose du IaaS. En plus, c'est SCVMM qui se présente comme tel car c'est bien lui qui gère les tailles de VM Roles :

Import-Module VirtualMachineManager

Get-CloudVMRoleSizeProfile | ft Name, Description, CpuCount, MemoryInMB –AutoSize

clip_image005

 

Dans Azure, on déploie des VMRole dans un Cloud Service, ce qui permet de faire du scale-out. Logiquement avec un VM Role dans Windows Azure Pack, on peut faire de même en fournissant le préfixe à utiliser pour la création des différences instances ainsi que le nombre minimum et maximum d'instances.

clip_image006

 

Dans le portail du locataire, on peut voir que les choses avancent. Au passage, un grand merci à Anders Bengtsson pour son billet Setting up VM Roles in WAP sans lequel je serai encore en train de chercher pourquoi mon déploiement de VM Role échouait.

clip_image007

 

Coté SCVMM, si on regarde les jobs, on constate les entrées suivantes pour le compte de benoit@simplebydesign.Fr:

  • La création d'un Cloud
  • La création d'une VM Role Resource

Import-Module VirtualMachineManager

Get-ScJobs | Where {$_.owner -match "benoit@simplebydesign.fr"} | Select -First 2

clip_image008

 

Subtilité du chef pour le dessert, du pour SCVMM, nous avons bien une machine virtuelle, mais aussi une "Cloud Resource".

Get-SCVirtualMachine | Select Name

Get-CloudResource

clip_image009

 

Ça ressemble furieusement à du Microsoft Azure IaaS. Si le locataire est patient, il a sa machine virtuelle sera provisionnée. Mon Windows Azure Pack, n'est pas aussi performant qu'un Datacenter de Microsoft Azure.

clip_image010

 

Si le portail nous indique qu'une machine virtuelle est provisionnée, notre locataire doit pouvoir faire de même en Powershell :

Get-WAPAckVM | Select CloudVMRoleName, ComputerName, Name, Status | Format-Table -Autosize

clip_image011

 

Si on revient au portail des locataires, on peut consulter l'utilisation que nous faisons de notre abonnement et où nous en sommes par rapport aux limites imposées. Visiblement, j'ai encore un peu de marge.

clip_image012

 

Notre Cloud Service contient une seule instance de notre machine virtuelle. Nous pouvons gérer chaque instance individuellement.

clip_image013

 

Pour chaque instance de notre VM Role, nous pouvons afficher les informations d'usage associées. Techniquement, ces informations sont récupérées par Service Provider Foundation auprès de SCOM qui lui-même les a collectées auprès de SCVMM. Ce sont des informations que nous fournisseur de service pouvons exploiter pour réaliser le capacity-planning de notre infrastructure.

clip_image014

 

Dans Microsoft Azure on peut Scaler le déploiement d'un Cloue Service. Dans Windows Azure Pack Aussi (Scale Up et Scale out). Dans l'exemple ci-dessous, j'ajoute une instance à mon Cloud Service existant.

clip_image015

 

Lorsqu'on regarde ce qui se passe pendant le provisioning (en Powershell), le Service Provider Foundation génère du PowerShell pour que l'infrastructure SCVMM délivre. Dans l'exemple ci-dessous c'est la tâche de scale-out que mon locataire vient juste de demander.

Import-Module VirtualMachineManager

Get-SC-Job | Where {$_.owner -match "benoit@simplebydesign.fr"} | select -First 1

clip_image016

 

Pour finir, notre locataire peut reconfigurer à souhait sa machine virtuelle, tant qu'il reste dans les limites imposées par le VM Role.

clip_image017

 

C'est la fin de cette séance de torture. Si vous avez trouvé cela complexe, dites-vous que ce n'est qu'un survol du module IaaS de Windows Azure Pack. Il reste tellement de sujets à développer :

  • La virtualisation de réseau avec NVGRE
  • La mise en place de la Gateway RDS
  • Le monitoring et le suivi des usages (System Center Service Reporting / Cloud Cruiser)

 

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

Windows Azure Pack - IaaS : L'expérience locataire

La fin se rapproche, mais c'est pas pour cela qu'on va faiblir, le bourreau est plein de ressources. Dans le portail du locataire, celui-ci dispose maintenant de la souscription nouvellement mise à disposition.

clip_image001

 

Trop facile? c'est pour cela qu'on va corser un peu plus la chose. On passe sous la moquette avec un peu de torture PowerShell, allons explorer la nouvelle souscription de notre locataire.

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL.WindowsAzurePack.lan

$AdminUri = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL.WindowsAzurePack.lan

$WindowsAuthSiteUri = "https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)"

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm "http://azureservices/AdminSite" -User $cred

Get-MgmtSvcUser -AdminUri $adminuri -Token $token

Get-MgmtsvcSubscription -AdminUri $adminuri -Token $token

clip_image002

 

Ma plateforme Windows Azure Pack accueillant son premier locataire, la commande Get-MgmtSvcUser ne retourne qu'un seul utilisateur, lequel a une seule souscription. La commande Get-MgmtSvcSubscription nous retourne l'unique souscription de notre locataire. Celle-ci est intéressante car c'est sous cet identifiant (SubscriptionID) qu'est référencé notre locataire qui vient consommer des ressources auprès du Service Provider Foundation sur notre serveur SCVMM. Vous suivez toujours? Ce qui compte pour Service Provider Foundation, c'est la souscription et non l'utilisateur qui a souscrit l'abonnement au "plan".

Import-Module SPFAdmin

Get-SCSPFTenant

$Tenant = Get-SCSPFTenant | Where {$_.Name -Match "benoit@simplebydesign.fr"}

Import-Module VirtualMachineManager

Get-SCUserRole | Where {$_.ID -eq $Tenant.Id}

clip_image003

 

Là où cela se complique, c'est dans SCVMM. Pour lui, on ne peut disposer de privilèges que si l'utilisateur est associé à un Rôle. Lors de la souscription Service Provider Foundation a demandé à SCVMM de créer un rôle qui est lié à la souscription et non à l'utilisateur Windows Azure Pack. C'est l'identifiant du Tenant qui permet de faire le lien avec le rôle dans SCVMM. Dans SCVMM, on constate bien la présence du rôle. Celui-ci est bien limité pour ne pouvoir consommer des ressources que dans le Cloud que nous avons référencé.

clip_image004

 

C'est quand même assez déroutant. Maintenant allons voir comment cela se présente du point de vue "PowerShell" du locataire. Après avoir installé le module Azure, il manque quand même quelque chose. Si on demande quels sont les environnements Azure à disposition, la commande Get-AzureEnvironment nous retourne la réponse ci-dessous :

clip_image005

 

Effectivement, on a bien Microsoft Azure, mais pas de trace de notre Windows Azure Pack. Pour cela, il faut le référencer à l'aide de la commande Add-AzureEnvironment, laquelle a besoin de trois informations :

  • Le nom de l'environnement à référencer
  • L'URL publique de la Tenant API
  • L'URL de publication des informations de souscription

Add-AzureEnvironment -name "My Windows Azure Pack" -ServiceEndPoint "https://tenantpublicapi.windowsazurepack.fr" -PublishSettingsFileUrl "https://tenantportal.windowsazurepack.fr/publishsettings"

clip_image006

 

Maintenant, c'est Azure "Like" ou presque, il faut juste préciser qu'on veut utiliser notre Windows Azure Pack pour aller récupérer notre fichier PublishSettings.

clip_image007

 

Une fois authentifié, nous sommes automatiquement redirigé vers l'URL de téléchargement de notre fichier PublishSettings. C'est tout comme Microsoft Azure.

clip_image008

 

Ne reste plus qu'à l'importer le fichier décrivant nos souscriptions à l'aide de la commande Import-WAPackPublishSettingsFile qui n'est jusque qu'un alias pour la commande Import-AzurePublishSettingsFile. La seule subtilité c'est de bien préciser notre environnement Windows Azure Pack.

Import-WAPackPublishSettingsFile -PublishSettingsFile 'c:\temp\SQL Server-IaaS-4-5-15-credentials.publishsettings' -Environment "My Windows Azure Pack"

clip_image009

 

Si cela fonctionne, le "Resource Provider" exposé via l'API publique des locataires devrait être capable de nous fournir des informations sur l'environnement IaaS mis à disposition comme l'infrastructure réseau avec la commande Get-WAPackVnet :

clip_image010

 

Comme pour son grand frère, on retrouve le détail de nos souscriptions dans le portail des locataires de Windows Azure Pack ainsi que la présence du certificat auto-signé qui nous authentifie lorsqu'on utilise les commandes PowerShell d'Azure/Azure Pack.

clip_image011

 

Notre locataire va pouvoir enfin consommer des ressources. Ça tombe bien, c'était l'avant-dernier billet de cette série.

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

Windows Azure Pack - IaaS : Création du Plan

Du point de vue de nos futurs locataires, Windows Azure Pack, ce ne sont que des “plans” auxquels ils peuvent souscrire. Chaque “Plan” met à disposition des ressources en provenance d'un ou plusieurs "Resource Providers". Mettons la casquette du Service Provider et attaquons le sujet.

D'un point de vue technique, les ressources de SCVMM doivent être mises à mises à disposition de Windows Azure Pack pour permettre aux locataires de les consommer. Cette mise à disposition s'effectue sous la forme de "plan" que l'on peut traduire par abonnement auquel notre futur locataire pourra souscrire. On peut créer un nouveau "plan" ou associer nos ressources à un "plan" existant. C'est le premier scénario que j'ai retenu.

clip_image001

 

Notre nouveau plan ne va proposer qu'un seul type de ressource : des machines virtuelles. Cela ne veut pas dire que nos locataire ne pourront pas consommer du SQL as a Service mais que ce sera au travers d'un autre plan auquel il devra souscrire.

clip_image002

 

Pour cette souscription, on n'a pas encore d'extension à proposer à nos futurs locataires. On ne propose une extension aux locataires que pour étendre les moyens mis à disposition pour consommer les ressources que nous mettons à disposition.

clip_image003

 

Le "plan" nouvellement créé est pour l'instant pas encore visible par les locataires. Il est privé, uniquement disponible aux locataires si un administrateur leur associe à leur souscription (genre preview sur invitation), mais surtout, il reste de la configuration à faire.

clip_image004

 

Le portail nous indique que la souscription contient une ressource pour laquelle il manque de la configuration et que la consommation actuelle ressemble à un électrocardiogramme plat.

clip_image005

 

La première étape de la configuration, c'est de sélectionner l'instance SCVMM préalablement déclarées à l'étape précédente et de spécifier le Cloud SCVMM dans lequel on va venir consommer les ressources. Cela va conditionner beaucoup de choses car SCVMM va nous exposer ses ressources mais aussi ses contraintes. Dans la section "Usage Limits", on peut reconfigurer les limites du VM Cloud qui seront proposées aux locataires. N'oubliez pas de cliquer sur le bouton "Save" pour valider les changements, …

clip_image006

 

Si on regarde un peu plus bas, il y a d'autres options à configurer :

  • Network
  • Hardward Profiles
  • VM templates
  • Gallery

clip_image007

 

Le Network correspond à un VM Network déclaré dans SCVMM et associé au Cloud (idéalement, il devrait supporter NVGRE). Les Hardware profiles décrivent les configurations matérielles des machines virtuelles qui ont été utilisées pour préparer les templates de VM que nous avons aussi référencés. Ce sont les éléments qui seront présentés à nos futurs locataires pour provisionner des StandAlone VM. Pour La Gallery, cela correspond aux éléments que nous avons configuré avec le GRIT pour les VM Roles .

clip_image008

 

C'est prêt, y a plus qu'à rendre le plan "public" pour que les futurs locataires puissent y souscrire.

clip_image009

 

Après un peu d'attente, notre locataire peut enfin consommer. Il est temps d'aller voir à quoi cela ressemble du point de vue de notre futur locataire. C'est l'heure de la récompense pour les survivants.

 

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

Windows Azure Pack - IaaS : Gallery Resource Import Tool

Le Gallery Resource Import Tool (GRIT), c'est un outil magique qui va nous faciliter l'adaptation des avec une interface graphique. Sinon, ce ne serait que du Powershell, autant dire que ça pique les yeux. L'outil est disponible à cette adresse et en plus cocorico, l'auteur est un Français. Avant de l'exécuter dans une invite de commande PowerShell (avec tous les privilèges), il faut configurer quelques variables :

  • SCVMM : SCVMM.WINDOWSAZUREPACK.LAN
  • SPF :SPF.WINDOWAZUREPACK.FR

clip_image001

 

Depuis la version 1.2, l'outil prend en charge l'utilisation d'un Service Provider Foundation distant. Pour cela, l'outil a besoin d'une délégation Kerberos lors de l'exécution. Celle-ci sera automatiquement mise en place et retirée à la fin de l'exécution. C'est le cas de ma maquette puisque j'exécute le GRIT depuis le serveur sur lequel sont installés les modules privilégiés de Windows Azure Pack (AdminAPI, WindowsAutSite, AdminSite).

clip_image002

 

Qui dit délégation implique une identité, ce sera celle du compte de service que nous avons utilisé pour configurer le Service Provider Foundation. Le compte WAP\FT-SPF-SVC est membre du groupe WAP\FT-SPF-Admins .

clip_image003

 

Vu que le Web Plateform Installer est disponible sur mon serveur (et que celui-ci a accès à Internet), il me propose la liste des packages disponibles. Nous, nous l'avons déjà préalablement téléchargé, nous allons donc sélectionner un fichier RESDEF préalablement téléchargé.

clip_image004

 

Pour la suite de ce billet, j'ai sélectionné le package RESDEF "WS2012_WG_VMRole_PKG". C'est bien fait car pour chaque "Gallery resource", on a un fichier Word d'explication. A ce stade, le package n'est pas encore utilisable. Le package exprime des critères d'éligibilité (version d'OS, Rôle & Feature, …) que nous devons mettre à disposition. Lors du déploiement, Windows Azure Pack va demander au SPF de localiser les ressources disques VHD/VHDX utilisable avec le package RESDEF. Pour cela, il recherchera des "Tag" sur les disques présents dans la librairie SCVMM. La ressource obligatoire, c'est un système d'exploitation à déployer. J'en ai plusieurs dans ma librairie SCVMM, ce qui manque, c'est le lien entre les deux. On va se positionner dans l'onglet "Virtual Disks Configuration".

clip_image005

 

Si on consulte le document Word associé à la “Gallery resource”, il est indiqué que nous avons besoin d'un système d'exploitation Windows Server 2012. Maintenant, il faut bien lire l'encadré, c'est m'expression des prérequis pour le disque OS. Nous, nous devons juste sélectionner le ou les disques contenant un système d'exploitation Windows Server 2012. Lorsqu'on clique sur le bouton "Apply Theses OS Disk Settings to Selected Disk(s) and Refresh List", le Tag "WindowsServer2012;R1" sera configuré sur le disque VHDX.

clip_image006

 

Note : Si on en sélectionne plusieurs, le locataire devra choisir le disque OS à utiliser parmi ceux identifiés par le tag.

 

Après exécution, le VHDX mis à jour est reconnu comme un disque OS et le tag est bien positionné.

clip_image007

 

Pour le disque Data (qui n'est pas obligatoire mais vivement recommandé), le package RESDEF contient une expression des prérequis attendus. Dans l'illustration ci-dessous, j'ai plusieurs VHDX éligibles. J'en ai retenu un seul et cliqué sur le bouton "Apply theses OS Disk Settings to Selected Disk(s) and Refresh List".

clip_image008

 

Le tag "DataDisk" a été associé au fichier VHDX présent dans ma librairie.

clip_image009

 

On peut le vérifier dans SCVMM en demandant la liste des disques contenu dans la librairie pour lesquels la propriété “FamilyName” contient le tag "WindowsServer2012-R1" que nous venons de positionner, il n'y en a qu'un.

Import-module VirtualMachineManager

Get-ScVirtualHardDisk | Where {$_.FamilyName -Match "WindowsServer2012-R1"}

clip_image010

 

Note : Pour le disque de données, c'est le même principe sauf que le contenu de l'attribut “FamilyName” sera "DataDisk".

 

Passons maintenant à l'étape suivante avec les importations. Le package Resource Definition (RESDEF) est à destination de Windows Azure Pack et l'éventuel package RESDEFEXT est lui à destination de notre instance SCVMM. Dans le cas de notre VM Role Windows Server 2012 Workgroup, il n'y a aucune personnalisation à apporter post-installation, il n'y a donc rien à importer dans SCVMM. Pour cette raison, le GRIT ne nous propose pas de spécifier une instance de librairie SCVMM dans laquelle réaliser l'importation.

clip_image011

 

Derrière, le GRIT a fait le job, à savoir mettre à jour les deux disques et importé le Resource Definition Package dans Windows Azure Pack.

clip_image012

 

Note : Pour ceux qui se posent la question du versioning, chaque Resource Definition Package contient une version, c'est cette version qui sera utilisée pour rechercher le disque ayant le bon tag et la bonne version. Plusieurs versions peuvent ainsi être proposées au locataire.

 

Pour illustrer, je n'ai pas utilisé le GRIT pour réaliser l'importation du package RESDEF. Allons dans le portail d'administration de Windows Azure Pack, nous n'avions pas encore exploré la Gallery.

clip_image013

 

Y a plus qu'à sélectionner le Resource Definition package (Extension RESDEFPKG) à importer.

clip_image014

 

Notre Resource Definition Package est maintenant disponible dans Windows Azure Pack.

clip_image015

 

On peut consulter les informations qui seront accessibles aux futurs locataires. Bien entendu, c'est personnalisable avec le VM Authoring Tool.

clip_image016

 

Ne nous reste plus qu'à rendre cette ressource accessible en la rendant publique, sans cela, on ne pourra pas l'associer à un plan.

clip_image017

 

Arrivé à ce stade, dites-vous que le plus difficile est fait. La prochaine étape, c'est plus du marketing / Business que de la technique. Félicitation aux survivants qui ont tenu jusque-là.

 

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

Windows Azure Pack - IaaS : Standalone VM versus Virtual Machine Role

Nous savons déjà que Windows Azure Pack ne communique pas directement avec SCVMM. Coté Windows Azure Pack, il a juste besoin d'avoir une définition de ce qu'il doit demander avec la liste des prérequis à demander au locataire. Windows Azure Pack est capable de provisionner deux types de machines virtuelles :

  • StandAlone Virtual Machine
  • Virtual Machine Role

Pour une StandAlone Virtual Machine, Windows Azure Pack va se reposer sur SCVMM pour exploiter deux types de ressources : Les images VHD/VHDX et les templates de machines virtuelles . Ce sont des éléments de SCVMM que nous avons préalablement associé au Cloud utilisé dans Windows Azure Pack. C'est une approche simpliste puisque cela ne permet aucune forme de personnalisation (ajout de rôle, installation d'application via SCVMM ou même scale-out de la machine virtuelle). Pour le futur locataire, voilà à quoi cela ressemble :

clip_image001

 

Il sélectionne son template de machine virtuelle et on lance le déploiement. Pour les Virtual Machines Roles, c'est un peu plus sophistiqué. On va uniquement exploiter un ou plusieurs VHD/VHDX mis à disposition dans la librairie SCVMM pour composer une machine virtuelle personnalisable (JSON rules again). D'une part l'utilisateur pourra fournir des paramètres qui seront utilisés lors du déploiement de sa machine virtuelle mais en plus on sera capable de réaliser des actions post-déploiement tel que l'installation de rôles, logiciels. Cerise sur le gâteau, les Virtual Machine Roles sont scalables. C'est ce concept que nous allons développer, c'est bien plus "capilo-tracté". Pour arriver à ce tour de force, Windows Azure Pack a besoin de deux fichiers :

  • Le Resource Definition Package (RESDEF)
  • Le Resource Extension Package (RESDEFEXT)

Le Resource Definition Package (RESDEF) permet de spécifier les paramètres qui seront utilisés par Windows Azure Pack pour composer la future machine virtuelle. Cela comprend la définition des paramètres attendus lors de la création de la machine virtuelle et tout ce qui est nécessaire pour construire une interface facilitant le déploiement pour notre futur locataire. C'est donc un fichier qui est consommé par Windows Azure Pack, plus précisément par la Gallery.

Le Resource Extension Package (RESDEFEXT) exploite une capacité de SCVMM pour personnaliser la machine virtuelle nouvellement déployée sous la forme de scripts exécutés lors de la première ouverture de session ainsi que d'applications à déployer grâce à SCVMM. C’est donc un package qui est injecté lors du déploiement avec les paramètres attendus.

 

Prenons un cas concret avec le déploiement d'un contrôleur de domaine :

  • Le Resource Definition Package (RESDEF) contient de quoi déployer le système d'exploitation (NOM, IP, …) mais aussi de quoi poser les bonnes questions à notre locataire (Nom DNS du futur domaine, son nom NETBIOS, mot de passe DSRM, …).
  • Le Resource Extension Package (RESDEFEXT) utilise nos paramètres pour réaliser la promotion du contrôleur de domaine en exécutant un script lors d'une première ouverture de session.

clip_image002

 

On remarque tout de suite que cette approche a une limite, notre Virtual Machine Role ne peut contenir qu'une seule machine virtuelle. Pourtant dans le Web Plateform Installer, on nous propose de déployer des infrastructures Lync et SharePoint. Il y a une astuce mais c'est une autre histoire . Voila pour la version courte. Pour la version "Hurt me plenty baby", je conseille les lectures suivantes pour découvrir un univers à part dans Windows Azure Pack :

 

Maintenant que le décors est posé, peuplons notre Gallery. Pour avoir du contenu, on peut utiliser les ressources déjà mises à disposition par Microsoft. Si on reconfigure le Feed utilisé par le Web Plateform Installer à l'URL suivante http://www.microsoft.com/web/webpi/partners/servicemodels.xml, on arrive au contenu présenté ci-dessous : les Gallery Resources :

clip_image003

 

Une Gallery resource, c'est une ressource IaaS à laquelle nos locataire pourront souscrire. C’est du prêt à consommer. L'avantage, c'est qu'on peut proposer tout un éventail de machines virtuelles, de la plus basique, à la plus évoluée. J'ai fait mon marché en prenant de quoi faire un premier jeu de test basé sur Windows Server 2012 et Windows Server 2012 R2 pour des déploiement en Workgroup. La base quoi.

clip_image004

 

La liste de courses est complète, y a plus qu'à lancer le téléchargement et récupérer le contenu.

clip_image005

 

Je récupère ce contenu et le mets à disposition de de mon Windows Azure Pack.

clip_image006

 

Nous avons du contenu mais il n'est pas encore utilisable dans Windows Azure Pack. Ce contenu n'est même pas encore adapté à notre environnement. Les plus téméraires peuvent explorer le Resource Definition Package (RESDEFPKG) à l'aide du VM Authoring Tool mais ça va piquer les yeux. C'est un sujet sur lequel je reviendrait certainement dans un prochain billet.

Nous nous allons poursuivre avec l'adaptation et l'importation de ces packages (Resource Definition Package et Resource Extension Package) dans Windows Azure Pack et SCVMM. Vu que ce sont des packages génériques, ils ne savent pas quelles ressources utiliser dans SCVMM (disques OS, disques de données en particulier). Pour faire le lien entre les deux, il faut tagger les ressources à l'aide du Gallery Resource Import Tool. Ce sera l’objet du prochain billet.

 

Après ceux qui trouvent que je la joue petit bras en déployant du simple Windows, je leur recommande le téléchargement du Gallery resource “CPS WorkLoads Multi tier Gallery Resource” et les saines lectures associées :

 

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

Windows Azure Pack - IaaS : Déclaration du VM Cloud

Nous avons référencé une instance de Service Provider avec Windows Azure Pack, reste maintenant à configurer l'autre partie, à savoir déclarer le/les instances de SCVMM, lesquelles peuvent exposer un ou plusieurs Cloud dans lesquels on va pouvoir consommer des ressources. Il est possible d'instancier jusqu'à cinq SCVMM différents pour une seule instance du Service Provider Foundation.

clip_image001

 

Pour chaque association entre notre instance de Service Provider Foundation et une instance de SCVMM, nous devons référencer au moins deux informations :

  • Le FQDN de l'instance SCVMM
  • Le port utilisé pour administrer l'instance SCVMM

La configuration de la Remote Desktop Gateway n'est qu'optionnelle. C'est grâce à ce composant que nos locataires pourront se connecter en RDP aux instances de machines virtuelles sans que celles-ci ne soient directement exposées sur Internet. Le service existe à l'identique dans Microsoft Azure. La seule différence, c'est que dans Windows Azure Pack, il permettra à nos locataires d'accéder à leurs machines virtuelles même éteintes. Derrière, c'est une fonctionnalité de SCVMM 2012 R2 (Remote Console in System Center 2012 R2) qui est exploitée avec la Gateway de Remote Desktop Services. C'est un sujet un peu à part, il sera donc traité dans une série de billet distincte.

clip_image002

 

Note : Pour que cela fonctionne, cela implique que le contexte de Web Service VMM inclus dans Service Provider Foundation se présenter devant SCVMM avec le niveau de privilège le plus élevé, à savoir Administrator. C'est sous ce contexte (WAP\FT-SPF-SVC) que Windows Azure Pack se présentera auprès de SCVMM pour faire traiter ses demandes. Pour que le tout fonctionne, il y a quelques prérequis, juste un peu, ...

 

Ci-dessous, le cas de ma maquette, mon instance de SCVMM ne contient un seul Cloud qui annonce ses capacités. On peut déjà dire tout de suite que les capacités annoncées sont loin d'être illimitées.

clip_image003

 

En dessous, il faut comprendre que ce n'est pas le Windows Azure Pack que nous configurons pour utiliser notre instance de SCVMM mais bien le Service Provider Foundation. Plus précisément, on déclare un Stamp. Un Stamp représente un package de ressources (Compute, storage, Network, …) qui est géré par une instance de Virtual Machine Manager. Service Provider Foundation peut être connecté à de multiples stamp représentant des SCVMM distincts. Au final, Windows Azure Pack n'a aucune notion de ce qu'il y a derrière, Service provider Foundation agissant comme une couche d'abstraction qui permet de délivrer du service IaaS.

Derrière un Stamp, on peut tout à fait avoir un Datacenter ou même plusieurs Datacenters si tous sont managés avec une même instance de SCVMM. Suite à cette configuration, on peut constater que c'est bien dans le Service Provider Foundation qui a été configuré pour référencer notre SCVMM, pas Windows Azure Pack.

clip_image004

 

Vu que notre Stamp est tout neuf, il n'y a donc aucune ressource consommée dedans.

clip_image005

 

A ce stade, nous avons n'avons encore aucune ressource à proposer à nos futurs locataires. Il est temps de se soucier de proposer un peu de contenu. La construction de l’infrastructure est terminée. On passe maintenant en mode “Fournisseur de service”. Finalement, c’était pas si compliqué (Si VMM est bien configuré et que l’installation du SPF a été réalisée dans les règles de l’art).

 

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

Solve W2K12R2 DirectAccess OTP activation problem with Powershell

I was working on a DirectAccess POC for a customer of mine a few months ago. Now it’s time to go in production and moving from Windows 2012 to Windows Server 2012 R2. I was rebuilding my lab and have a closer look at KB2883952 to avoid most of problems. This time, problem is not in the list. I was not able to configure OTP authentication for DirectAccess because no capable ADCS can be used to provide required certificates.

0

Not logic, my lab worked like a charm in Windows Server 2012, so ADCS role configuration was good. Because it’s only a prerequisite check, let’s try to configure OTP scenario using the Enable-DAOTPAuthentication PowerShell commandlet and surprised, it worked !

1

Even if it worked from the PowerShell commandlet, the console does not recognize ADCS as compatible but it’s no longer blocking in the configuration process.

2

PowerShell rules!

Edit 24/04/2015 : Now KB3047733 fix that problem. My workaround is no longer required.

 

BenoîtS – Simple and secure by design but Business compliant

Windows Azure Pack - IaaS : Intégration de Service Provider Foundation

Du point de vue de Windows Azure Pack, nous devons déclarer notre C3PO, alias Service Provider Foundation. Dans le portail d'administration, cela se passe dans le nœud "VM Cloud".

clip_image001

 

L'URL attendue, c'est l'URL de base de du site web présent sur l'hôte sur lequel Service Provider Foundation a été installé. Pour le contexte de sécurité, c'est le compte WAP\SPF-SVC utilisé pour le le Web Service d'administration du Service Provider Foundation.

clip_image002

 

Si tous les prérequis d'installation ont été respectés, l'enregistrement doit fonctionner. Nous avons même une notification dans le portail.

clip_image003

 

Dans les subtilités, j'avais annoncé que le Service Provider Foundation fournissait des évènements sur lequel Service Management Automation pouvait venir s'interfacer. Pour cela, encore faut-il déclarer auprès de quel SMA annoncer ces évènements.

clip_image004

 

Ma maquette disposant déjà d'un Service Management Automation, il suffit juste d'en référencer l'URL qui a été utilisée pour le “Resource Provider”.

clip_image005

 

Nous recevons une notification comme quoi le "System Center Automation endpoint" a été créé.

clip_image006

 

Cela signifie que Service Management Automation sera en mesure d'exploiter les évènements générés par Service Provider Foundation et d'y attacher des Runbooks pour exécution. La subtilité, c'est que seuls les Runbooks ayant le tag SPF pourront être utilisés.

Pour finir, nous devons référencer le endpoint qui expose l'usage des machines virtuelles : https://spf.windowsazurepack.Fr:8090/USAGE avec le compte qui va avec.

clip_image007

 

Nous sommes notifiés comme quoi le endpoint a bien été référencé. C'est maintenant que les choses intéressantes commencent.

clip_image008

 

Allons voir ce que cela a changé du point de vue des “Resource Providers” déclarés dans Windows Azure Pack. On retourne donc explorer le CommandLet Powershell MgmtsvcAdmin :

Import-Module MgmtSvcAdmin

$Securepassword = ConvertTo-SecureString -String "********" -AsPlainText -Force

$Cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "Administrator", $Securepassword

$AdminAPIInfos = Get-MgmtSvcFqdn -Namespace adminapi -Server SQL.WindowsAzurePack.lan

$adminApiUri = "https://$($AdminAPIInfos.FullyQualifiedDomainName):$($AdminAPIInfos.Port)"

$WindowsAuthSiteInfos = Get-MgmtSvcFqdn -Namespace WindowsAuthSite -Server SQL.WindowsAzurePack.lan

$WindowsAuthSiteUri = "https://$($WindowsAuthSiteInfos.FullyQualifiedDomainName):$($WindowsAuthSiteInfos.Port)"

$token = Get-MgmtSvcToken -Type Windows -AuthenticationSite $WindowsAuthSiteUri -ClientRealm "http://azureservices/AdminSite" -User $cred

$AllRPs = Get-MgmtSvcResourceProvider -IncludeSystemResourceProviders -AdminUri $AdminUri -Token $Token

$AllRPs | Select Name, @{e={$_.AdminEndPoint.ForwardingAddress}}, @{e={$_.TenantEndpoint.ForwardingAddress}}, @{e={$_.UsageEndpoint.ForwardingAddress}}, @{e={$_.NotificationEndpoint.ForwardingAddress}} | Format-table -AutoSize

clip_image009

 

On constate la présence de nouveaux "Resource Providers" :

  • System Center
  • CloudServices
  • Gallery

 

La bonne nouvelle, c'est que vu que nous n'avons pas utilisé de certificat auto-signé, pas besoin de revenir corriger les FQDN, c'est déjà opérationnel.

 

Note : Ceux qui lisent le PowerShell entre les lignes auront remarqué que j'ai soumis mon authentification auprès du WindowsAuthSite, non pas auprès de l'infrastructure ADFS. C'est normal, j'ai reconfiguré ma maquette pour ne plus utiliser ADFS, que ce soit pour les administrateurs que pour les locataires.

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

More Posts Next page »