PI Services

Nous allons voir comment ajouter un serveur Nano dans le domaine à partir du fichier unattend.xml qui sera exécuté au premier lancement du serveur Nano à l’aide du contenu du fichier blob.

Dans un premier temps, sur votre contrôleur de domaine lancer la commande suivante :

djoin  /provision /domain labo.local /machine HYPV-1 /SAVEFILE HYPV-1

pour le commutateur /domain vous devez préciser le nom de votre domaine.

pour /machine, vous devez préciser le nom de la machine qui sera provisionner dans le domaine

pour /SaveFile, il s’agit du nom de fichier

Un fichier Blob a été généré

Observer son contenu en l’ouvrant avec notepad

Le contenu de ce fichier devra être présent dans le fichier unattend.xml du serveur entre les balises <AccountData> et </AccountData>.

Corps de l’unattend:

<?xml version='1.0' encoding='utf-8'?>  
<unattend xmlns="urn:schemas-microsoft-com:unattend" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  
  <settings pass="offlineServicing">  
    <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">  
        <OfflineIdentification>                
           <Provisioning>    
             <AccountData></AccountData>  
           </Provisioning>    
         </OfflineIdentification>    
    </component>  
  </settings>  
  
  <settings pass="oobeSystem">  
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">  
      <UserAccounts>  
        <AdministratorPassword>  
           <Value>MonMotDePasse</Value>  
           <PlainText>true</PlainText>  
        </AdministratorPassword>  
      </UserAccounts>  
      <TimeZone>Pacific Standard Time</TimeZone>  
    </component>  
  </settings>  
  
  <settings pass="specialize">  
    <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">  
      <RegisteredOwner>My Team</RegisteredOwner>  
      <RegisteredOrganization>My Corporation</RegisteredOrganization>  
    </component>  
  </settings>  
</unattend>  

Copier coller le contenu entre les balises.

Depuis un accès Offline, appliquer maintenant le fichier unattend sur le serveur

Démarrer le serveur

Authentifier vous avec un compte admin du domaine

L’authentification a réussi. On remarque également que notre serveur est maintenant dans le domaine.

Si vous rencontrer sous cette erreur en démarrant une machine virtuelle en utilisant la fonctionnalité Nested sous TP5

Cela est du au faite que votre Hyperviseur hôte n’est pas dans la bonne version de Build.

Pour que ce message n’apparaisse plus, il faut que la version de l’Hyperviseur hôte démarrant des VM Hyper-v TP5 soit également en version TP5.

Contexte

Dans cet article la mise en place du mode hybride entre Skype for Business (SfB) OnPremise et Skype Online sera expliquée. La partie hybride Cloud PBX ne sera pas évoquée.

La mise en place du mode hybride étant légèrement différente entre Skype for Business et Lync Server, cet article sera découpé en deux parties. La première partie sur portera sur Skype for Business 2015 / Skype Online. La seconde partie portera sur Lync Server 2010-2013 / Skype Online.

Mode hybride Skype for Business / Skype Online

Prérequis

Pour pouvoir mettre en place le mode hybride entre SfB OnPremise et Skype Online, certains prérequis doivent être respectés :

• Une architecture Skype for Business 2015 (avec les dernières mises à jour) contenant au minimum un serveur Edge
• Un tenant Office 365
• La synchronisation des comptes utilisateurs entre l’Active Directory et Office 365 (DirSync, Azure AD Connect,...)
• L’ADFS doit être configurée
• Des licences utilisateurs Office 365
• Un compte utilisateur ayant les droits CSAdministrator
• Un compte utilisateur ayant les droits d’administration Skype Entreprise dans Office 365
• La liste des domaines fédérées dans Skype Online doit être identique à celle de Skype for Business OnPremise

Note : L’ensemble des entrées DNS doivent pointer sur les serveurs Skype for Business OnPremise. Aucun changement n’est à prévoir.

Mise en place

Depuis un serveur Front-End, lancez la commande suivante depuis le Management Shell (en tant qu'administrateur) pour vérifier que les paramètres AllowFederatedUsers et AllowOutsideUsers sont à True et que le paramètre RoutingMethod corresponde à UseDnsSrvRouting :

Get-CsAccessEdgeConfiguration

Si ce n’est pas le cas, exécutez la commande suivante :

Set-CSAccessEdgeConfiguration -AllowOutsideUsers $True -AllowFederatedUsers $True -UseDnsSrvRouting

Exécutez la commande Get-CsHostingProvider pour identifier le provider Skype for Business (ou Lync Online).

Supprimez le provider Skype for Business existant via la commande Remove-CsHostingProvider.

Exécutez la commande suivante pour recréer le provider avec les bons paramètres :

New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn "sipfed.online.lync.com" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

Une fois la partie OnPremise configurée, il faut configurer la partie Online. Pour cela vous devez vous connecter à Skype Online en PowerShell (via le module Skype for Business Online https://www.microsoft.com/en-us/download/details.aspx?id=39366).

Exécutez les commandes suivantes :

Import-Module SkypeOnlineConnector

$cred = Get-Credential <Compte administrateur Skype Online>

$CSSession = New-CsOnlineSession –Credential $cred

Import-PSSession $CSSession –AllowClobber

Ensuite vérifiez dans la configuration du tenant si le paramètre SharedSipAddressSpace est à True.

Si ce n’est pas le cas, utilisez la commande suivante pour le passer à True :

Set-CsTenantFederationConfiguration –SharedSipAddressSpace $true

Allez sur le portail d'administration Skype Online, vérifiez que le paramètre External Access soit à On except for blocked domains ou à On only for allowed domains.

Maintenant que ces commandes sont passées, connectez-vous sur la console d’administration de SfB OnPremise, cliquez sur Sign in to Office 365 et indiquez le compte administrateur de Skype Online.

Des que vous êtes connectés, cliquez sur Set up hybrid with Skype for Business Online.

Cliquez sur Next.

Si au moment de la validation du mode hybride les erreurs suivantes apparaissent, patientez quelques instants que la réplication des paramètres modifiés précédemment soient prise en compte sur l’ensemble des serveurs.

Une fois tous les paramètres synchronisés, la fenêtre suivante s’affiche et le mode hybride est actif.

Bascule d’utilisateurs

Une fois que le mode hybride est actif, il est possible de migrer un utilisateur de SfB OnPremise vers Skype Online (et inversement).

Attention : La migration d'un utilisateur peut lui faire perdre l'ensemble de ses contacts Skype.

Pour migrer un utilisateur, vérifiez qu'il possède une licence comprenant la fonctionnalité Skype Online.

Depuis la console d’administration SfB OnPremise, recherchez l’utilisateur, sélectionnez-le, cliquez sur Action et enfin sur Move selected users to Skype for Business Online…

Validez les différentes étapes en cliquant sur Next.

L’utilisateur est alors dans Skype for Business Online.

La migration d’un utilisateur Online vers OnPremise se fait par le même procédé en sélectionnant Move selected users from Skype for Business Online…

Contexte

Ce billet est la seconde partie de l’article sur la mise en place du mode hybride avec Skype Online. Dans cet article la mise en place de l’hybridation entre Lync Server 2010 (ou 2013) sera traitée.

La grande différence entre l’hybridation SfB / Skype Online et Lync 2010-2013 / Skype Online est la gestion des comptes utilisateurs. En effet dans le cas du mode hybride avec Lync Server 2010/2013 toutes les migrations d’utilisateurs (OnPremise <-> Online) se fait uniquement par PowerShell.

Mode Hybride Lync Server 2010-2013 / Skype Online

Prérequis

Pour pouvoir mettre en place le mode hybride entre Lync Server 2010-2013 et Skype Online, certains prérequis doivent être respectés :

• Une architecture Lync Server 2010 ou 2013 (avec les dernières mises à jour) contenant au minimum un serveur Edge
• Pour une architecture Lync Server 2010, un serveur supplémentaire avec les outils d’administration Lync Server 2013 est obligatoire
• Un tenant Office 365
• La synchronisation des comptes utilisateurs entre l’Active Directory et Office 365 (DirSync, Azure AD Connect,...)
• L’ADFS doit être configurée
• Des licences utilisateurs Office 365
• Un compte utilisateur ayant les droits CSAdministrator
• Un compte utilisateur ayant les droits d’administration Skype Entreprise dans Office 365
• La liste des domaines fédérées dans Skype Online doit être identique à celle de Lync Server

Note : L’ensemble des entrées DNS doivent pointer sur les serveurs Skype for Business OnPremise. Aucun changement n’est à prévoir.

Mise en place

Comme décrit précédemment, les outils d’administration Lync Server 2013 sont obligatoires, donc si vous avez une architecture Lync Server 2010, installez-les sur un serveur d'administration depuis l’iso de Lync Server 2013.

Remarque : Les outils d'administration Lync Server 2013 ne peuvent pas être installés sur un serveur ayant des services Lync Server 2010.

Depuis un serveur Front-End (ou le serveur d’administration), lancez la commande suivante depuis le Management Shell (en tant qu'administrateur) pour vérifier que les paramètres AllowFederatedUsers et AllowOutsideUsers sont à True et que le paramètre RoutingMethod est à UseDnsSrvRouting :

Get-CsAccessEdgeConfiguration

Si ce n’est pas le cas, exécutez la commande suivante :

Set-CSAccessEdgeConfiguration -AllowOutsideUsers $True -AllowFederatedUsers $True -UseDnsSrvRouting

Exécutez la commande Get-CsHostingProvider pour identifier le provider Skype for Business (ou Lync Online). 

Supprimez le provider existant via la commande Remove-CsHostingProvider.

Exécutez la commande suivante pour recréer le provider avec les bons paramètres :

New-CSHostingProvider -Identity SkypeforBusinessOnline -ProxyFqdn "sipfed.online.lync.com" -Enabled $true -EnabledSharedAddressSpace $true -HostsOCSUsers $true -VerificationLevel UseSourceVerification -IsLocal $false -AutodiscoverUrl https://webdir.online.lync.com/Autodiscover/AutodiscoverService.svc/root

Une fois la partie OnPremise configurée, il faut configurer la partie Online. Pour cela vous devez vous connecter à Skype Online en PowerShell (via le module Skype for Business Online https://www.microsoft.com/en-us/download/details.aspx?id=39366).

Exécutez les commandes suivantes :

Import-Module SkypeOnlineConnector

$cred = Get-Credential <Compte administrateur Skype Online>

$CSSession = New-CsOnlineSession –Credential $cred

Import-PSSession $CSSession –AllowClobber

Ensuite vérifiez dans la configuration du tenant si le paramètre SharedSipAddressSpace est à True.

Si ce n’est pas le cas, utilisez la commande suivante pour le passer à True :

Set-CsTenantFederationConfiguration –SharedSipAddressSpace $true

Allez sur le portail d'administration Skype Online, vérifiez que le paramètre External Access soit à On except for blocked domains ou à On only for allowed domains.

Le mode hyrbide est désormais en place.

Bascule d’utilisateurs

Attention : La migration d'un utilisateur peut lui faire perdre l'ensemble de ses contacts Lync.

Dans un premier temps, connectez-vous au portail d’administration de Skype Online et récupérez le début de l’URL, dans le cas ci-dessous https://admin1e.online.lync.com/

Pour migrer des utilisateurs vous devrez utiliser le début de l’URL complétée par HostedMigration/hostedmigrationservice.svc.

Ici, l’URL finale sera https://admin1e.online.lync.com/HostedMigration/hostedmigrationservice.svc

Maintenant pour migrer un utilisateur OnPremise vers Online, exécutez la commande depuis le Management Shell Lync Server 2013 (depuis le serveur d’administration si vous avez une architecture Lync 2010).

$cred = Get-Credentials <Compte administrateur Skype Online>

Move-CsUser –Identity <UPN> -Target sipfed.online.lync.com -Credential $cred –HostedMigrationOverrideUrl <URL>

Pour migrer un utilisateur Online vers OnPremise, exécutez la commande depuis le Management Shell Lync Server 2013 (depuis le serveur d’administration si vous avez une architecture Lync 2010).

$cred = Get-Credentials <Compte administrateur Skype Online>

Move-CsUser –Identity <UPN> –Target <FQDN Front-End>-Credential $cred –HostedMigrationOverrideUrl <URL>

Lors de la création d’une machine virtuelle, on ne se contente en général pas d’un seul « disque dur » (vhd/vmdk). Il est d’usage de conserver le volume principal pour le système, et d’ajouter un ou plusieurs volumes pour les données, les sauvegardes…

Lors de la création de la VM, ces volumes y sont bien rattachés mais ils sont dans un état « brut » : non initialisés, ni partitionnés, ni formatés, ni nommés, et ne disposant pas de lettre de lecteur.

Et si ces opérations peuvent s’avérer fastidieuses lorsqu’il s’agit d’un déploiement manuel, elles deviennent inacceptables lorsqu’il s’agit de VM déployées automatiquement via un portail self-service déclenchant un processus d’orchestration : la VM doit être livrée « prête à fonctionner » à l’utilisateur qui en a fait la demande.

Heureusement, le vénérable outil diskpart peut être scripté, automatisant ainsi le procédé.

Le script powershell que je vous propose ci-dessous doit être exécuté en tant qu’administrateur local, dès que la VM est démarrée. Il détecte tous les disques qui ne disposent d’aucune partition, les initialise, les partitionne (une seule partition primaire), les formate, les renomme DATAxxx et leur attribue la première lettre disponible.

$datadisks = get-wmiobject win32_diskdrive | where partitions -eq 0

$i = 1

foreach ($disk in $datadisks) {

$diskID = $disk.index

$diskname = "DATA" + $i

$dpscript = @"

SELECT DISK $diskID

ATTRIBUTES DISK CLEAR READONLY

CREATE PARTITION PRIMARY

FORMAT fs=ntfs quick label=$diskname

ASSIGN

"@

$i++

$dpscript | diskpart

}

Il ne reste plus qu’à intégrer ce script à votre processus de déploiement, qu’il s’agisse d’une tâche post-installation dans SCVMM ou d’un runbook Orchestrator :

Il s’agit ici d’un déploiement de VM dans Azure ne disposant que d’un compte administrateur local hors domaine. On commence par monter le disque D : de la VM (disque temporaire créé automatiquement) en tant que partage, puis on y crée le script proposé ci-dessus, on l’exécute à l’aide de la commande powershell.exe -ExecutionPolicy ByPass "& ""D:\diskpart.ps1"""  et on termine en démontant le partage réseau.

L’exécution du script ne prend que quelques minutes même avec plusieurs volumes à formater, et il s’adapte automatiquement quel que soit leur nombre.

Certains scripts powershell peuvent nécessiter un accès au Web, comme par exemple ceux utilisés pour piloter un tenant Azure.

Or, la majorité des organisations utilisent aujourd’hui des proxy pour contrôler ces accès à Internet et il est préférable d’éviter autant que possible les exceptions à cette règle, y compris lorsque c’est un script qui a besoin de se connecter.

Certains cmdlet ont en plus une facheuse tendance à ignorer les paramètres de proxy de l’utilisateur qui les exécute (c’est le cas des cmdlet Azure Powershell tels que Login-AzureRmAccount), et il n’est pas toujours possible ou souhaitable de définir un proxy au niveau du système, via la commande netsh winhttp set proxy…

Heureusement, il est possible de spécifier ces paramètres directement au sein du script !

Dans un premier temps, il est nécessaire de spécifier l’adresse du Proxy :

$proxyAddress = "http://1.2.3.4:8080"

$proxyUri = new-object System.Uri($proxyAddress)

[System.Net.WebRequest]::DefaultWebProxy = new-object System.Net.WebProxy ($proxyUri, $true)

Si le proxy accepte les connexions anonymes, cela peut suffire.

Autrement, il sera nécessaire de spécifier des credentials autorisés à s’y connecter. Dans ce cas, deux possibilité :

- Soit vous ré-utilisez les credentials de l’utilisateur qui exécute le script :

[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

- Soit vous utilisez les credentials d’un autre compte  :

$proxyAccountName = "domain\user"

$proxyPassword = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force

$proxyCred = New-Object System.Management.Automation.PSCredential($proxyAccountName, $proxyPassword)

[System.Net.WebRequest]::DefaultWebProxy.Credentials = $proxycred

En plaçant ces quelques lignes avant toute exécution de cmdlet nécessitant un accès au Web, vous ne devriez plus rencontrer de problème!

Il peut parfois s’avérer nécessaire dans un script de récupérer l’adresse IP d’une VM Azure alors que celle-ci n’est pas enregistrée dans le DNS.

Dans Azure « classic» (l’ancienne version), cette information était renvoyée directement à l’aide du cmdlet Get-AzureVM :

Malheureusement, pour les VM créées dans Azure Resource Manager (Azure RM, la « nouvelle » version), le cmdlet Get-AzureRmVM fonctionne différemment et ne renvoie plus directement cette information :

Il renvoie par contre une information intéressante : l’ID de la carte réseau associée à la VM, via la propriété NetworkInterfaceIDs :

La fin de cet ID représente le « display name » de la carte réseau, qui va nous permettre de retrouver les propriétés détaillées de cette carte à l’aide du cmdlet Get-AzureRmNetworkInterface :

Dans ces propriétés détaillées, une en particulier nous intéresse : IpConfigurationsText.
Comme son nom l’indique, elle contient le détail de la configuration Ip de la carte réseau, dont la PrivateIpAddress qui nous intéresse :

Afin d’automatiser ce processus, j’ai réalisé une fonction Get-AzureRmVMIP qui prend en entrée le nom de la VM et celui de son Resource Group, et qui renvoie le nom de la carte réseau et son IP :

Fonction dont voici le code source, que vous pouvez réutiliser ou adapter à votre guise dans vos propres scripts.

Function Get-AzureRmVMIP

{ param

(

[Parameter(Mandatory=$true,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]

[string]

$Name,

[Parameter(Mandatory=$true,ValueFromPipelineByPropertyName=$true)]

[string]

$ResourceGroupName

)

Process

{

$VM = Get-AzureRmVM -Name $Name -ResourceGroupName $ResourceGroupName

$NICs = get-AzureRmNetworkInterface -name $vm.NetworkInterfaceIDs.split("/")[-1] -ResourceGroupName $ResourceGroupName

$VMIPAddresses = @()

foreach ($NIC in $NICs) {

$VMIPAddresses += @{$NIC.Name = $NIC.IpConfigurations.PrivateIpAddress}

}

Return $VMIPAddresses

}

}

"Operations Management Suite" est un service cloud proposé par Microsoft pour afficher et corréler sous forme de dashboard divers les informations issus de diverses sources de données (La liste evolue) y compris issus d’autres éditeurs. Ces sources de données concerne la supervision, l’automation de processes, les sauvegardes et restaurations, L’analyse d’audit de sécurité, l’analyse du traffic réseau et d’autres sources encore.

SCOM n’est bien sur pas oublié. A la différence que OMS peux fonctionner avec des agent « Microsoft Monitoring Agent » sans SCOM.

Voyons tout de même comment configurer un SCOM existant pour le connecter a un compte OMS.

N.B : Facturé au volume de donnée uploadé, Microsoft propose un compte gratuit limité a 500 MB / jour et 7 jours de retentions de données mais non limité dans le temps. Ce compte est utilisé dans l’exemple ci-dessous.

Il peut être crée via le lien suivant :

https://www.microsoft.com/en-us/server-cloud/operations-management-suite/trial.aspx

Si dans la console SCOM, le nœud n’existe pas encore on commence par une mise à jour des managements pack Advisor (ancien nom du service OMS)

Importer les mises à jour des MP Advisor situé dans le dossier d'installation de SCOM a la suite de l'application du dernier RU:

C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\Management Packs for Update Rollups

Fermer et rouvrez la console SCOM

A la suite de cette mise ajour le noeud "Advisor" a disparu et le noeud "Operations Management Suite" est apparu.

Se positionner sur le nœud "Operations Management Suite"

Sélectionner Register to Operations Management Suite

Renseigner le compte de connexion au service OMS.

NB : Cette verification n’est faite qu’a titre de sécurité pour le compte utilisé.

Selectionner Envoyer le code.

Renseigner le code et Envoyer.

Sélectionner le nom du workspace associé au compte OMS précédemment crée.

Cliquer Next.

Cliquer Create

Cliquer Close

La datasource du groupe de management scom connecté apparait dans le portail du service.

https://<nom_du_workspace>.portal.mms.microsoft.com/?returnUrl=%2F#Workspace/overview/index

La zone solution Gallery permet d'ajouter des services.

Selectionner par ex Alert Management et cliquer Add

La zone Solutions affiche les solutions installées

Aller sur la console SCOM sur le noeud "Operations Manager Suite\Connection"

Cliquer sur "Add a Computer/Group" en haut à droite

Ajoutez des agents.

La zone "Managed Computers" du noeud "Operations Manager Suite\Connection" contiens les agents ajoutés

Apres quelques minutes la zone « Connected Source » de la console OMS affiche la présence des machines gérés et la fraicheur des données remontées.

La zone « OverView\Settings Dashboard\DATA » permet de configurer les éléments à remonter dans la console OMS (EventLog, Compteur de Performance …) independemment de SCOM.

La zone Search est un bon moyen de rechercher rapidement tout les types de données remontés.

Selectionner par ex « All computers with their most recent data »

Nous avons ici 4 serveurs gérés avec leur donnés (TYPE).

La sélection des éléments modifie de manière dynamique la barre de requête en haut de la page comme dans l’exemple ci-dessous permettant d’afficher les données de performance…

…Et plus précisément un compteur en particulier.

N.B : Un ebook gratuit a été mis à disposition pour une immersion assez complete dans OMS :

https://gallery.technet.microsoft.com/Inside-the-Operations-2928e342

Introduction

Disponible depuis SQL Server 2008 Enterprise TDE permet de chiffrer un base de données de manière totalement transparente pour les application qui s’en appuient. A l’aide de TDM, les fichier .mdf et .ldf ainsi que les sauvegardes sont chiffrées avec les standards AES ou 3DES.

Le chiffrement est réalisé au niveau de la page. La donnée est chiffrée lors de son écriture sur le disque et déchiffrée lors de sa lecture, chiffrer et déchiffrer l’information au niveau de la page permet aux applications clientes de ne pas nécessiter de prérequis.

Dans le cas où la base de donnée est utilisée dans un mode de réplication (AlwaysOn, Mirroring ou Log Shipping), toutes les bases participant à la réplication seront chiffrées.

Attention, TDM chiffre la donnée au niveau de son support physique ce qui permet de la protéger en d’accès au disque contenant la base de donnée, les communications (client/server) ne sont elles pas chiffrées, une connexion SSL client/server doit être utilisée dans ce cas.

Prérequis et commandes utilisées

• CONTROL DATABASE sur la base de données master
• CREATE CERTIFICATE sur la base de données master
• CONTROL DATABASE sur la base de données chiffrée et l'autorisation VIEW DEFINITION
• CREATE MASTER KEY (Transact-SQL)
• CREATE DATABASE ENCRYPTION KEY (Transact-SQL)
• ALTER DATABASE SET Options (Transact-SQL)
• CREATE CERTIFICATE (Transact-SQL)

Réalisation

1.Créer la “Master Key” de la base de donnée

Afin d’activer TDE, il est nécessaire de créer une master key. La master key doit être créée depuis la base master.

Microsoft recommande de la clé principale à l'aide de l'instruction BACKUP MASTER KEY et stocker la sauvegarde en lieu sûr.

2. Créer un certificat pour proteger “Master Key” créé précédemment

Créer un certificat appelé “MyDatabase” dans l’exemple plus haut.

3. Créer la “Database Encryption Key”

Se positionner sur la base à chiffrer.

Créer la clé utilisée pour protéger la base de donnée, cette clé est appelée DEK (Database Encryption Key), cette clé est sécurisée à l’aide du certificat créé précédemment.

Les algorithmes de chiffrement suivant sont proposés :

• AES_128
• AES_192
• AES_256
• TRIPLE_DES_3KEY

4. Activer le chiffrement au niveau de la base à chiffrer

Durant le chiffrement la base est toujours accessible le processus de chiffrement étant réalisé en arrière-plan, cependant, des dégradation des performances sont à prévoir.

Vérification

La commande suivante permet de vérifier la progression du chiffrement :

SELECT db_name(database_id),encryption_state,percent_complete,

key_algorithm,key_length
FROM sys.dm_database_encryption_keys

Exploitation

En plus des tâches de sauvegarde usuelles, l’utilisation de TDM impose la sauvegarde du certificat utilisé pour le chiffrement de la base. Sans ce certificat, il est impossible d’accéder aux données chiffrée, même depuis une sauvegarde (le chiffrement s’appliquant au niveau de la page).

Le script suivant est un exemple qui présente comment sauvegarder le certificat ainsi que la clé privée (inutile de préciser l’emplacement entre parenthèses dans le switch “WITH PRIVATE KEY” si l’on souhaite exporter le certificat avec sa clé privée) utilisés pour le chiffrement :

Introduction

Afin de déplacer ou restaurer une base de donnée chiffrée à l’aide de TDE (Transparent Data Encryption), il est nécessaire de restaurer le certificat utilisé pour le chiffrement de la base sur la future instance SQL hôte.

Prérequis et commandes utilisées

• Le certificat utilisé pour chiffrée la base à déplacer/restaurer et sa clé privée
• Une instance hôté SQL Server compatible TDE (à partir de SQL Server 2008 Enterprise)
  • CONTROL DATABASE sur la base de données master
  • CREATE CERTIFICATE sur la base de données master
  • CONTROL DATABASE sur la base de données chiffrée et l'autorisation VIEW DEFINITION
  • CREATE MASTER KEY (Transact-SQL)
  • CREATE DATABASE ENCRYPTION KEY (Transact-SQL)
  • ALTER DATABASE SET Options (Transact-SQL)
  • CREATE CERTIFICATE (Transact-SQL)

Réalisation

Le script suivant permet de créer une master key depuis la base master de l’instance SQL cible :

Avant de restaurer la base, le certificat (avec la clé privée) provenant de l’instance source doivent être restaurés :

La base peut maintenant être restaurée.

Vérification

La commande suivante requête la vue sys.certificates et la vue sys.dm_database_encryption_keys afin de retourner les bases chiffrées (dont l’encryption state est à “3”)

USE master

GO
SELECT * FROM sys.certificates
SELECT * FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;