PI Services

Le blog des collaborateurs de PI Services

Azure DNS : Du mieux dans les zones privées !

Bref rappel : Azure DNS est un service PaaS qui propose d’héberger vos zones DNS sans que vous n’ayez besoin de vous préoccuper de la gestion de l’infrastructure sous-jacente.

De plus, comme tout service « cloud », il est possible de gérer ces zones et leurs entrées à l’aide d’une API REST, ce qui apporte une flexibilité certaine face au fonctionnement encore un peu archaïque du service Windows DNS dont la gestion passe nécessairement par la MMC DNS ou par Powershell, voire par l’utilisation de dnscmd.exe pour ceux d’entre vous qui lisent cet article en 1992.

Microsoft a introduit il y a quelques mois un type de zone « Private » à ce service, permettant ainsi d’héberger des zones qui ne seraient pas résolvables depuis l’extérieur de votre environnement ; mais ce mode souffrait de lacunes sérieuses, qui le rendaient inexploitable dans un contexte réel :

  • Il n’était disponible qu’en Powershell
  • Seules les requêtes provenant d’un unique VNet avaient le droit de créer des entrées dans une zone donnée
  • Seuls 10 VNet avaient le droit de lire les entrées d’une zone donnée
  • Ces VNet devaient être déclarés manuellement
  • Ces VNet ne devaient contenir aucune ressource au moment de leur déclaration (!!)
  • Les enregistrements étaient invisibles via powershell ou l’API REST, mais étaient bel et bien resolvables
  • … etc.

Une mise à jour majeure est apparue la semaine dernière, et elle corrige la majorité de ces défauts :

  • On peut désormais créer les zones privées directement dans le portail Azure
  • On peut lier jusqu’à 1000 VNet à une zone privée, même si ces VNet contiennent déjà des ressources ; et les notions de VNet « enregistreur » ou « requêteur » disparaissent
  • On peut désormais accéder aux enregistrements via l’API ou Powershell

Bref, on peut maintenant raisonnablement utiliser ce service dans un environnement réel… mais attention tout de même, il est toujours en Public Preview et susceptible d’évoluer n’importe quand !

Notez également que la résolution dans une zone Private DNS ne fonctionne par défaut que si votre VNet est configuré pour utiliser la résolution DNS native d’Azure.

Si vous utilisez une résolution « Custom » (un contrôleur de domaine déployé dans votre tenant par exemple), il faudra créer un conditional forwarder pour votre zone Private DNS, pointant vers l’IP d’Azure DNS (unique pour tous les tenant et toutes les régions) : 168.63.129.16

Enfin, comme la résolution dans une zone Private DNS n’est possible que depuis un VNet, il faudra également prévoir un forwarder différent sur les serveurs DNS de votre Lan si vous souhaitez pouvoir résoudre depuis cet emplacement !

L’occasion idéale pour mettre en place une partition DNS à réplication limitée

Windows DNS - créer un scope de réplication limité

Les partitions DNS intégrées à Active Directory, permettant ainsi leur réplication et leur gestion sur tous les contrôleurs de domaine disposant du rôle DNS, sont depuis longtemps la norme dans un environnement Windows.

Il existe cependant une possibilité moins connue de ce mécanisme : la partition DNS « custom », qui permet de définir un scope de réplication limité à seulement un ou quelques contrôleurs de domaine de votre choix.

J’ai eu recours à cette possibilité afin de résoudre un problème lié à l’utilisation de Conditional Forwarders que vous pourriez bien rencontrer dans votre propre environnement sans même le savoir : les Conditional Fowarders sont répliqués dans toute votre forêt de la même façon que les zones DNS « classiques » (foward et reverse), mais si vous en utilisez il est fort possible que seuls certains de vos contrôleurs de domaine soient réellement en mesure de les atteindre en raison de contraintes réseaux propres à votre environnement.

Il devient alors nécessaire de limiter la réplication de ces Conditional Forwarders aux seuls serveurs DNS qui y ont accès !

La création d’une partition DNS se fait uniquement en powershell (en tant qu’administrateur) :

Add-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition"

Il est ensuite nécessaire d’y ajouter les contrôleurs de domaine qui répliqueront cette partition :

Register-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition" -ComputerName "DC01.cogip.com"

Répétez cette opération pour chaque contrôleur pour lequel vous souhaitez activer la réplication sans trop prêter attention aux possibles erreurs que vous pourriez obtenir : ca marche quand même (… normalement !) ; puis vérifiez justement que les serveurs sont bien ajoutés à la zone :

Get-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition"

clip_image002

Il est désormais possible de créer ou de déplacer un conditional forwarder dans cette partition, simplement à l’aide de la MMC DNS :

clip_image004

Attention : dans le cas du déplacement d’un forwarder existant déjà, assurez -vous qu’il n’est pas protégé contre la suppression ! Si c’est le cas, le déplacement échouera avec un message peu explicite, et toutes les tentatives successives échoueront également même si vous retirez la protection entre temps ! La seule solution sera ici d’utiliser ADSI Edit pour aller faire le ménage dans la partition DC=ConditionalForwardersPartition …

Azure Storage - Failed to create blob container

La création d’un conteneur Blob dans un compte Azure Storage est une opération devenue plutôt banale, mais qui peut toutefois encore donner lieu à des messages d’erreur assez cryptiques :

clip_image002

Failed to create blob container.

Details : This request is not authorized to perform this operation.

Le message d’erreur pourrait laisser penser à un manque de droits, mais l’utilisateur dispose bien de permissions suffisantes dans ce Storage Account.

Par contre, dans le cas qui nous intéresse ici, le filtrage par adresse IP est activé sur le Storage Account utilisé, et la VM qui tente d’accéder au Storage Account est déployée dans un tenant Azure différent ; le filtrage est donc réalisé à l’aide de l’IP publique de la VM :

clip_image004

Or, les connexions entrantes dans le storage account sont s-natées à l’intérieur d’un même Datacenter Azure, comme indiqué ici : https://github.com/MicrosoftDocs/azure-docs/issues/10359 . Ce n’est donc pas l’IP publique de la VM qui se présente en entrée du Storage Account, et cela explique le blocage rencontré…

Deux solutions sont toutefois disponibles :

  • Déployer le Storage Account dans une région Azure différente de celle de la VM : ca sera alors bien l’IP publique de cette dernière qui se présentera en entrée du Storage Account
  • Utiliser le filtrage par VNET à la place du filtrage par IP. Cette solution reste possible même si le VNET de la VM est dans un tenant différent de celui du Storage Account, mais il faudra que l’utilisateur qui réalise la configuration dispose de permissions spécifiques sur le VNET de la VM : https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security#grant-access-from-a-virtual-network