Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

Fournir ses credentials aux services Azure

Poster un commentaire

Un certain nombre de services Azure (Powershell Remoting, Azure Management, SSL…) ou de cmdlets exigent des credentials pour s’y connecter. On a alors 2 possibilités (à valider avec la doc tout de même):

  1. se connecter avec un compte professionnel
  2. Fournir un certificat

Nous allons montrer comment exploiter ces méthodes de façon concrète.

Compte professionnel

Un compte professionnel est simplement un compte déclaré dans Azure Active Directory (anciennement WAAD).

  • Lancer Powershell ISE
  • lancer la cmdlet
    add-azureaccount

Une popin vous demande de vous loguer.

  • Lancer la commande
    get-azureaccount
    Pour vérifier que tout va bien

2015-03-05_18-12-31

Note: Le jeton récupéré est valide 12 heures. Après on devra se reconnecter.

Il est possible de supprimer le login à tout moment à l’aide de :

remove-azureaccount

Certificats

Présentation générale

On est amené à manipuler des certificats dans Azure dans 3 situations:

  1. Certificat de gestion (management certificate)
    Utilisé pour accéder à Management Api et aux ressources de son abonnement Azure ainsi que les déploiements
    format .cer
    Validation par un CA non obligatoire
    Stocké au niveau de l’abonnement
  2. Certificat SSL
    Requête Https
    Format .pfx
    Validation par un CA nécessaire
    Stocké au niveau du service concerné (cloud service, web site…)
  3. Certificat RDP
    Accès en Remote Desktop à une VM
    Format .pfx
    Stocké au niveau de la VM

Les certificats utilisés dans Azure sont des certificats x.509 v3 et peuvent être soit signés par un autre certificat de confiance soit auto-signés si ce n’est pas un certificat SSL. Pour en savoir plus sur ces différents certificats:

https://msdn.microsoft.com/fr-fr/library/azure/gg981929.aspx

Azure ne prend en charge que les formats .cer et .pfx

Note:  Azure est très chatouilleux sur la casse, .cer n’est pas le même fichier que .CER!!!

Si Azure n’est pas regardant quand à l’origine des certificats (ils peuvent être auto-signés, mais doivent faire au moins 2048 bits) c’est différents pour les certificats destinés aux endpoints SSL qui doivent être validés par une autorité de certification (CA). Autrement le navigateur va afficher le message de sécurité bien connu qui ne rassurera pas les clients et ne fait pas bien sérieux sur un site professionnel et les liaisons WCF risquent d’échouer.

La liste des CA reconnus par les OS Microsoft (cad qui sont préinstallés dans Windows) se trouve ici:

Et pour les WinPhone:

Créer et exporter les certificats

On créée les certificats avec makecert. Par exemple:

makecert.exe -r -pe -a sha1 -n « CN=My Azure Management Certificate »  -ss My -sr CurrentUser -len 2048 -sky exchange -sp « Microsoft Enhanced RSA and AES Cryptographic Provider » -sy 24

Ou si on a besoin d’une date de début et de fin:

makecert.exe -r -pe -a sha1 -n « CN=My Azure Management Certificate »  -ss My -sr CurrentUser -len 2048 -sky exchange -sp « Microsoft Enhanced RSA and AES Cryptographic Provider » -sy 24 -b 02/22/2015 -e 02/22/2050

 

Ou bien un générateur plus convivial:

http://blog.pluralsight.com/selfcert-create-a-self-signed-certificate-interactively-gui-or-programmatically-in-net

 

Important: Le paramètre -n est le nom du sujet qui doit correspondre au domaine que l’on souhaite signer.

 

Les certificats sont créés dans le magasin de certificat Windows personnel ce que l’on vérifie en lançant certmgr.msc (le démarrage peut être assez lent):

2015-03-03_22-48-45

On devra ensuite télécharger les certificats sous la forme de fichiers. On trouvera la procédure complète dans l’article cité précédemment, veillez juste à ne pas vous tromper de format (voir début du chapitre) et à bien noter les mots de passe des certificats pfx.

Il ne reste plus qu’à les pousser dans Azure et tester. c’est ce que nous allons faire dans les chapitres qui suivent.

Utiliser les certificats

 Certificat de gestion

Il existe en fait deux façons d’exploiter un certificat de gestion (management certificate).

  1. Générer un certificat et l’importer dans Azure
    C’est le certificat créé plus haut par exemple
  2. Obtenir un fichier d’abonnement (anciennement appelé fichier .publishsettings) et récupérer le certificat depuis le fichier

Commençons par la première méthode puisque nous l’avons déjà créé.

On ouvre le portail Azure et on se rend dans le menu SETTINGS dans lequel on découvre le menu MANAGEMENT CERTIFICATES. C’est dans ce menu que sont déclarés les certificats de gestion que l’on pourra utiliser pour effectuer certaines tâches administratives sur Azure.

 

Le certificat est déjà dans le magasin local. Puisque c’est de là que l’on va lancer l’application cliente on a rien de plus à faire. Dans le cas contraire on devrait récupérer le certificat .pfx et le charger dans le magasin.

On a par contre besoin de la version en .cer afin de la charger dans le magasin Azure. On fait l’export comme indiqué dans le lien déjà cité:

http://blogs.msdn.com/b/cclayton/archive/2012/03/21/windows-azure-and-x509-certificates.aspx

 

On ouvre le portail et on se rend dans MANAGEMENT CERTIFICATES.  Vous avez probablement quelque chose qui ressemble à ceci:

2015-03-01_00-04-01

On clique sur UPLOAD:

2015-03-01_00-08-43

L’interface attend un certificat au format .cer, on le lui fournit.

Le certificat est ajouté en bas de la liste:

2015-03-01_00-11-13

Comment valider? Et bien en testant.

Nous avons mis le certificat dans le magasin Personnel, donc:

string url = "https://management.core.windows.net/.....";

X509Store store = new X509Store(StoreName.My, StoreLocation.CurrentUser);
store.Open(OpenFlags.OpenExistingOnly | OpenFlags.ReadOnly);
X509Certificate2 certificate = store.Certificates.Find(X509FindType.FindByThumbprint, "85676041E80......A691EA73B664", false)[0];

Le contre montre comment récupérer le certificat. Il ne reste plus qu’à l’ajouter dans les credentials pour signer notre requête Azure.

On peut essayer de supprimer le certificat .cer du magasin Azure. On constate que l’on obtient une erreur 403.

 

Une autre façon de générer un certificat de gestion est de réclamer un fichier d’abonnement.

J’ai déjà rédigé un article pour montrer comment faire:

https://amethyste16.wordpress.com/2014/07/15/charger-le-publishsettingsfile-dans-la-console-powershell/

Regardons en le contenu d’un tel fichier:

2015-02-28_17-24-31

C’est le fichier obtenu avec deux abonnements. On y lit l’ID de l’abonnement et le certificat en base 64.

Vous avez peut être remarqué que chaque fois que la commande get-AzurePublishsettingsFile est invoquée, un certificat est ajouté à la liste des certificats de gestion. C’est le certificat .cer.

Le certificat avec la clef privée se trouve dans le fichier d’abonnement sous la forme d’un encodage base 64. On n’a alors pas besoin de le placer dans un magasin, il suffi de le lire.

Note: On ne peut pas avoir plus de 100 certificats associés à un abonnement en même temps. Au delà vous devrez faire le ménage depuis le portail. Vous remarquerez à cette occasion une petite difficulté: le certificat de gestion ne garde pas la trace de la machine ou de l’utilisateur pour lequel il a été créé. Ce n’est pas super pratique et pose un vrai problème de sécurité…

 

Et ensuite?

Tout dépend de notre contexte. Dans une application Powershell le plus simple est d’importer le fichier de publication comme expliqué dans le lien qui précède.

Dans une application C# on dispose d’autres moyens. Voyons en 2:

Si l’on dispose d’un fichier de publication on peut procéder comme dans l’exemple ci-dessous:

https://amethyste16.wordpress.com/2015/02/22/requeter-un-web-site-specifique/

On pourrait aussi consommer directement le fichier qui n’est rien d’autre qu’un XML. Je reprends l’exemple de l’article ci-dessus:

string url = "https://management.core.windows.net/...";

XDocument profile = XDocument.Load(publishingPath);
XElement subscriptionInfos = profile.Descendants("Subscription").First();

string subscriptionId = subscriptionInfos.Attribute("Id").Value;
string certificate = subscriptionInfos.Attribute("ManagementCertificate").Value;
WebRequest webRequest = WebRequest.Create(url);
webRequest.Method = "GET";
webRequest.Headers.Add("x-ms-version", "2014-04-01");
webRequest.ContentType = "application/json";

X509Certificate2 managementCertificate = GetCredentials(certificate);
((HttpWebRequest)webRequest).Credentials = CredentialCache.DefaultCredentials;
((HttpWebRequest)webRequest).ClientCertificates.Add(managementCertificate);

List<string> ids = new List<string>();
using (WebResponse webResponse = webRequest.GetResponse())
{
    using (StreamReader streamReader = new StreamReader(webResponse.GetResponseStream()))
    {
        string json = streamReader.ReadToEnd().Trim();
        ids = JsonConvert.DeserializeObject<List<string>>(json);
    }
}

Le problème est bien entendu que l’on complique la gestion des certificats en déployant des fichiers de publication un peu partout sur les serveurs sans compter les problèmes de sécurité que cela implique.

 

En marge de cet exemple vous pouvez choisir de fabriquer vous-même votre fichier de publication:

http://gauravmantri.com/2012/09/14/about-windows-azure-publish-settings-file-and-how-to-create-your-own-publish-settings-file/

Certificat SSL

Ces certificats doivent répondre à plusieurs critères:

  • Contenir une clef privée
  • format .pfx
  • Encryption d’au moins 2048 bits
  • Le nom du  sujet doit correspondre au domaine personnalisé
  • Etre certifié par une autorité de certification

Distinguons deux termes importants à comprendre:

  1. le domaine du site web
    Le domaine en *.azurewebsites.net donné par Azure (si on parle d’un web site)
  2. le domaine personnalisé
    Le domaine de votre entité, par exemple http://www.contoso.com qu’en général on préfèrera utiliser au domaine du site

J’en resterai là, mais on peut trouver des infos ici:

http://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/

 

Par défaut https est activé sur le domaine du site, on a donc rien de particulier à faire. Plus précisément un wildcard certificate est installé sur le domaine *.azurewebsites.net.

Note: faites un essai sur un web site ou un cloud service en l’appelant en http et https

Bien sûr le cas intéressant est celui du domaine personnalisé.

 

Pour procéder on aura besoin d’un certificat signé par une autorité. On trouvera la procédure complète ici:

http://azure.microsoft.com/fr-fr/documentation/articles/web-sites-configure-ssl-certificate/

http://www.troyhunt.com/2013/09/the-complete-guide-to-loading-free-ssl.html

 

Microsoft a publié un guide complet pour indiquer comment mettre en place SSL sur un web site et un cloud service:

http://support2.microsoft.com/kb/2990804

 

Les web sites

http://azure.microsoft.com/fr-fr/documentation/articles/web-sites-configure-ssl-certificate/

Important: L’activation de SSL n’est disponible que dans le mode standard. Vous devrez peut être modifier votre plan d’hébergement.

 

Remarque: Une différence importante d’avec les web sites est que les cloud site n’ont pas par défaut de wildcard certificate sur le domaine *.cloudapp.net. On a donc pas de https par défaut.

 

Je n’ai pas accès à un DNS, je ne peut donc pas faire la démo entièrement.

Une fois que vous disposez d’un certificat, rendez vous dans l’onglet CONFIGURE:

2015-03-07_02-54-24

  • Dans MANAGE DOMAIN ajoutez votre domaine personnalisé pour lequel vous avez créé un certificat.
  • Avec UPLOAD A CERTIFICATE, chargez votre certificat
  • Dans la section SSL BINDINGS, liez le certificat au domaine personnalisé.
  • Cliquez sur SAVE

2015-03-07_03-01-43

Installer SSL n’implique pas que le site soit accessible uniquement en https. Pour imposer https on doit modifier le module de réécriture d’url dans web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
   <system.webServer>
      <rewrite>
         <rules>
            <rule name="Force HTTPS" enabled="true">
               <match url="(.*)" ignoreCase="false" />
               <conditions>
                  <add input="{HTTPS}" pattern="off" />
               </conditions>
               <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
            </rule>
         </rules>
      </rewrite>
   </system.webServer>
</configuration>

La règle mise en place retourne un code http 301 (permanent redirect) lorsque l’utilisateur arrive en http et redirige l’utilisateur sur la même requête, mais en https.

 

Si votre application est une application MVC, vous devez plutôt utiliser le filtre RequireHttpsAttribute:

http://azure.microsoft.com/en-us/documentation/articles/web-sites-dotnet-deploy-aspnet-mvc-app-membership-oauth-sql-database/

 

Note finale: On ne peut pas ajouter de certificat pour le domaine du site web (demofredo.azurewebsites.net dans cet exemple).

 

Les cloud services

http://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-create-deploy/ 

Les certificats RDP

Les VM sont crées dans un cloud service. C’est au niveau du cloud service que l’on déclare le certificat. Normalement un certificat est créé en même temps que la VM afin de prendre à charge tout scénarios comme RDP ou configurer SSL nécessitant un certificat.

Nous allons surtout nous intéresser à RDP. On peut générer un fichier .rdp en cliquant sur le bouton CONNECT de la VM:

2015-03-05_22-34-52

Si le bouton CONNECT est en grisé vérifiez deux choses:

  1. la VM est lancée
  2. Il existe un endpoint privé sur le port 3389

Le port 3389 est utilisé pour se connecter à la VM en RDP (Remote Desktop Protocol).

 

Créez une VM dans votre abonnement Azure. Peu importe son profil. Vérifiez que vous vous connectez bien en RDP.

Dans CLOUD SERVICES allez dans l’onglet CERTIFICATE et repérez l’empreinte du certificat associé:

2015-03-05_23-26-45

Rendez vous dans la VM et:

2015-03-05_23-28-57

C’est le même certificat.

Note: on remarquera également que dans le portail Azure les certificats sont communs à tous les slots. On a donc pas de migration à faire.

 

Intéressons nous à PowerShell Remoting. Je m’inspire de cet excellent article:

https://blogs.endjin.com/2014/03/a-step-by-step-guide-to-connecting-to-an-azure-virtual-machine-with-powershell-remoting/

Windows Server 2012 R2 active Powershell remoting par défaut et Azure ajoute également un endpoint:

2015-03-07_12-42-56

On devrait pouvoir se connecter à une VM en remoting via PowerShell avec la commande suivante:

Enter-PSSession -ComputerName <machinename>.cloudapp.net -Port <remoting-endpoint> -Credential <username> -UseSSL

Il nous est demandé un mot de passe et ceci s’affiche:

2015-03-07_16-38-58

 

La connexion au serveur distant demoamethyste.cloudapp.net a échoué avec le message d’erreur suivant: Le certificat serveur de  l’ordinateur de destination (demoamethyste.cloudapp.net:5986) comporte les erreurs suivantes:   
Le certificat SSL est signé par une autorité de certification inconnue. Pour plus d’informations, voir la rubrique d’aide about_Remote_Troubleshooting.

Le message est clair. On va récupérer ce fameux certificat et l’installer dans notre magasin.

On lance la requête de remoting:

https://demoFredo.cloudapp.net:5986

Comme prévu un message d’erreur s’affiche:

2015-03-07_16-55-09

Récupérer le certificat est plus facile avec Chrome (je ne sais pas le faire avec IE):

2015-03-07_17-13-25

Un clic droit:

2015-03-07_17-16-37

On sélectionne CERTIFICATE INFORMATION:

2015-03-07_17-17-37

On vérifie que l’empreinte est bien celle du certificat installé lors de la création de la VM:

2015-03-07_17-19-38

On exporte dans un premier temps le certificat en cliquant sur COPIER DANS UN FICHIER:

2015-03-07_17-21-17

On choisit le format .cer. Une fois le certificat exporté on lance crtmgr:

2015-03-07_17-23-24

On importe le certificat dans le magasin: Autorités de certification racines de confiance. A un certain moment ce formulaire s’ouvre:

2015-03-07_17-24-45

On clique OUI.

On peut relancer la commande Powershell:

2015-03-07_17-26-21

Voilà, on accède en remoting à la VM.

 

On peut être amené à changer le certificat parce qu’il est obsolète par exemple. On se procure un certificat .pfx.

Dans le portail du cloud service de la VM, on se rend dans l’onglet CERTIFICATES:

2015-03-04_22-45-45

Cliquer sur UPLOAD.

2015-03-04_22-50-58

On renseigne le formulaire puis OK:

2015-03-04_22-52-04

 

Et pour finir un petit script qui fait tout seul le travail de récupération du certificat:

https://gallery.technet.microsoft.com/scriptcenter/Configures-Secure-Remote-b137f2fe

Bibliographie

 

 

 

 

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s