Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

RDS – Configurer le rôle License Server en ligne de commande et sans internet

Dans les environnements modernes, il est de plus en plus fréquent de rencontrer des serveurs déployés en mode “Server Core” (sans interface graphique) et bien sûr sans accès à Internet.

Le rôle RDS License Server est supporté sur ce type de serveur, mais son installation n’est pas aussi bien documentée qu’en mode graphique…

Il serait bien sûr possible de passer par une console installée sur un serveur de rebond, mais ca serait bien moins amusant! Et les informations suivantes peuvent également servir dans le cadre d’un déploiement automatisé par Ansible ou Powershell DSC.

Activation du serveur

Il est dans un premier temps nécessaire d’activer la fonctionnalité License Server. Le serveur n’ayant pas accès à Internet, il n’est pas possible de procéder à une activation automatique.

Il est cependant possible d’obtenir la clé d’activation à partir d’un autre poste disposant d’un accès à Internet :

  1. Récupérez le ProductId du License Server à l’aide de la commande suivante :
    (Get-WmiObject Win32_TSLicenseServer -Property ProductId).ProductId
    image

  1. Rendez-vous sur https://activate.microsoft.com/ et sélectionnez l’option Activate a License Server

  1. Indiquez le ProductId obtenu précédemment ainsi que le reste des informations demandées :
    image

  1. Après validation de vos informations, le site renvoie le License Server Id nécessaire à la poursuite de l’activation :
    image

  1. L’activation peut désormais être finalisée à l’aide des commandes suivantes (pensez à remplacer le License Server Id par la valeur obtenue précédemment, en supprimant les tirets)
    $serverId = ‘VTXXXXXXXXXXXXXXXXX’
    $wmiClass = ([wmiclass] »\\localhost\root\cimv2:Win32_TSLicenseServer »)
    $wmiClass.ActivateServer($serverId)

  1. En cas de réussite de l’opération, la valeur retournée pour ActivationStatus doit être 0 :
    image

Ajout des CAL

Une fois la fonctionnalité License Server activée, il est nécessaire de provisionner les licences d’accès (CAL) à proprement parler, afin qu’elles puissent être attribuées aux utilisateurs qui se connectent au bureau à distance.

  1. Récupérez le License Server Id depuis l’étape précédente ou à l’aide des commandes suivantes :
    $wmiClass = ([wmiclass] »\\localhost\root\cimv2:Win32_TSLicenseServer »)
    $wmiClass.GetLicenseServerId().sLicenseServerId
    image

  1. Rendez-vous sur https://activate.microsoft.com/ et sélectionnez l’option Install client access licenses

  1. Indiquez le License Server Id, sélectionnez le type de licence correspondant à la commande et complétez le reste des informations :
    image

  1. Indiquez le nombre de licences correspondant à la commande, ainsi que l’agreement number du contrat :
    image

  1. Confirmez. Le service d’activation renvoie la clé d’activation des CAL
    image

  1. L’activation des CAL peut désormais être finalisée à l’aide des commandes suivantes (pensez à remplacer le License Pack Id par la valeur obtenue précédemment, en supprimant les tirets)

$licensePackId = ‘Y3XXXXXXXXXXXXXXXX’

$wmiClass = ([wmiclass] »\\localhost\root\cimv2:Win32_TSLicenseKeyPack »)

$wmiClass.InstallLicenseKeyPack($licensePackId) 

  1. En cas de réussite de l’opération, Return Value doit afficher 0 et KeyPackId contient l’Id du pack de licence ajouté (incrémenté de 1 à chaque ajout d’un nouveau pack sur le serveur).
    image

Et voilà, votre serveur RDS License Server est prêt!

Defender Security Center – Collecte d’un package de diagnostique

Pour rappel, Defender Security Center représente la brique et le portail dédié associé a Defender for Endpoint, et représente l’offre SAS de Microsoft dans le domaine des EDR (Endpoint Detection and Response), encore appelé antivirus de nouvelle génération.

Dans le cadre de l’exploitation des données remontées par la solution, il peut être utile de collecter des données de diagnostique sans avoir a se connecter sur la machine cible.

1

Dans le portail Security Center, dans la zone Device Inventory, cliquer sur le device cible pour ouvrir la page du device.

2

Cliquer sur 3 et sélectionner Collect investigation package. La demande est initiée.

4

Apres quelques minutes, dans le même menu, sélectionner Action Center pour afficher la disponibilité du package

5

Cliquer sur le lien Package collection package available pour télécharger le package.

6

Le package contiens différents éléments:

7

– Programmes installés

– Diagnostiques réseaux (8)

– Une liste un dump du contenu du dossier Windows\Prefetch (9cf: Prefetcher — Wikipédia (wikipedia.org))

– Le détail des processes en cours

– les taches planifiées

– un export de l’eventlog Security

– Le détails des services

– les session SMB

– les infos du systeme (systeminfo.exe)

– les listes de contenu de differents dossier Temporaires

– Les users et groupes locaux

– La collecte de diagnostiques générée avec l’outil mpcmdrun.exe  (cf: Utiliser la ligne de commande pour gérer l’Antivirus Microsoft Defender – Windows security | Microsoft DocsCollecter des données de diagnostic de l’Antivirus Microsoft Defender – Windows security | Microsoft Docs)

O365 : Soft Match (SMTP) et Hard Match (ImmutableID)

Lorsque l’on utilise Active Direcotry et Azure Active Directory, il se peut que l’on soit confronter à des conflits car l’utilisateur existe déjà dans les deux environnements (selon divers scénarios).

Quand il s’agit bien du même utilisateur (et non pas un homonyme) il est important  de créer un « matching » entre les deux comptes pour que l’AD Connect puisse les voir comme un seul et même compte et les synchroniser.

Pour ce faire il existe deux méthodes:

  1. Le Soft Match appelé aussi SMTP Matching
  2. Et le Hard Match (basé sur l’ImmutableID)

Le Soft Match

Le soft match appelé aussi « smpt matching » consiste à s’appuyer sur l’adresse SMTP de l’utilisateur pour faire l’association entre les deux comptes.

Ce dernier est censé fonctionner dans la plupart des cas, mais pour cela il y a quelques conditions à respecter. 

  1. L’utilisateur doit posseder une adresse email sur Microsoft Exchange Online.
    1. s’il s’agit d’un contact ou d’un groupe à extension de messagerie le soft match sera basé sur l’attribt « proxyaddresses »
  2. Vous ne devrez pas modifier l’adresse SMTP principale de l’utilisateur durant l’opération.
  3. Les adresses SMTP sont considérées comme unique assurez vous que seul cet utilisateur possède cette adresse.

Le Hard Match

Le hard match entre en action lorsque le soft match n’a pas réussi, ce dernier consiste à récupérer le GUID du compte Active Directory pour le transformer en ImmutableID et enfin l’appliquer au compte Azure Active Directory.

Cette opération permettera de faire la liaison entre les deux comptes pour n’en faire qu’un synchronisé.