I. Présentation de SNMP

SNMP est un protocole réseau qui permet le monitoring et la supervision d’éléments systèmes et réseau. Généralement, un serveur de supervision utilise SNMP pour connaitre rapidement l’état du parc informatique (switch, routeur, serveurs) comme l’occupation RAM, CPU, Disque, etc.

Dans ce tutoriel, nous allons voir comment installer SNMP sous Linux, une machine Linux avec SNMP d’installé pourra alors être questionnée par une autre machine afin qu’elle puisse la superviser par exemple. Nous allons voir comment installer SNMP sous Debian 8 et sous CentOS 7.

Il est important de noter que les versions des dépôts sont différents sous Debian 8 (version 5.7.2.1 de net-snmp) et sous CentOS 7 (version 5.7.2 de net-snmp). Je vais détailler pour chaque étape, les différences de configuration entre les deux.

II. Installation de SNMPD

Il faut bien entendu commencer par installer le service SNMP sur notre machine Linux. Le service se mettra alors en écoute sur le port 161 en UDP afin d’être prêt à répondre aux sollicitations extérieures. Sous Debian, voici la commande à saisir

apt-get install snmpd snmp

Sous CentOS :

yum install net-snmp net-snmpd-utils

Net-snmp va alors s’installer, ainsi que ses dépendances.

Pour CentOS, il faudra également activer le démarrage du service SNMP au démarrage du serveur avec la commande suivante :

systemctl enable snmpd

Vous remarquerez également que je vous fait volontairement installer la partie “cliente” de SNMP sur vos serveurs via “net-snmpd-utils” et “snmp” . Cela permet de diagnostiquer plus rapidement des problèmes SNMP sur vos serveurs. Mais ce n’est pas obligatoire.

III. Mise en route

Sur les deux distributions, nous pourrons ensuite voir si le service est actif :

systemctl status snmpd

Si ce n’est pas le cas, nous pourrons le démarrer :

systemctl start snmpd

Enfin, une fois celui-ci démarré, nous verrons qu’il est actif sur le port UDP 161, cela avec la commande “ss” qui permet de lister les ports en écoute :

ss -ulnp

Pour détailler cette commande :

• l’option “u” permet de lister les ports UDP uniquement
• l’option “l” permet de lister les ports en écoute (“Listening” )
• l’option “n” permet d’afficher les numéros de ports et non leur correspondance (exemple : afficher “22” plutôt que “SSH” )
• l’option “p” permet d’afficher les processus correspondants aux ports en écoute

Dans tous les cas, nous devrions avoir quelque chose qui ressemble à cela :

Ce n’est pas le cas sous Centos, mais sous Debian, on voit ici que le port 161 est bien écoute en UDP, mais uniquement sur 127.0.0.1, ce qui empêchera les communications venant de l’extérieur. Si vous êtes sur Debian, pour ouvrir l’écoute sur l’extérieur, il faut aller modifier le fichier de configuration de snmp : /etc/snmp/snmpd.conf. On va alors voir dès les premières lignes, celles qui nous intéressent :

#  Listen for connections from the local system only
agentAddress  udp:127.0.0.1:161
#  Listen for connections on all interfaces (both IPv4 *and* IPv6)
#agentAddress udp:161,udp6:[::1]:161

La documentation est ici assez explicite, nous allons commenter la ligne suivante :

agentAddress  udp:127.0.0.1:161

Puis ajouter celle-ci :

agentAdrress udp:161

Ici, je mets en écoute mon service SNMPD sur le port 161 en UDP seulement pour l’IPv4.  S’en suivra un redémarrage de SNMP

systemctl restart snmpd

Si vous êtes sous CentOS, SNMP écoute par défaut sur l’extérieur, donc tout va bien !

IV. Configuration basique

Nous allons maintenant effectuer quelques configurations basiques, notre service SNMP écoute maintenant les sollicitations extérieures, mais il reste quelques changements à faire dans la configuration pour qu’il soit pleinement opérationnel. Notamment l’ouverture de certaines branches du MIB.

Configuration basique de SNMP sous CentOS 7

Dans le fichier /etc/snmp/snmpd.conf à la ligne 41, nous allons changer la “community” . La community est une sorte de “mot de passe” qui va permettre de restreindre l’accès aux informations fournis par les serveurs SNMP. Par défaut, cette community est généralement “public” , c’est pourquoi il est recommandé de changer, autrement, n’importe qui dans votre réseau pourra alors questionner vos serveurs sur leurs états de santé :

# First, map the community name "public" into a "security name"

#       sec.name  source          community
com2sec notConfigUser  default       masociete

Dans le bloc ci-dessus, j’ai remplacé “public” , par “masociete” pour vous donner un exemple.

Il est également nécessaire de corriger les lignes 55 et 56 pour qu’elles ressemblent à cela :

view   systemview   included   .1.3.6.1.2.1
view   systemview   included   .1.3.6.1.2.1.25.1

Enfin, afin d’ouvrir certaines informations et de permettre qu’elles soient transmises via SNMP, nous allons décommenter les lignes suivantes :

• lignes 85
• lignes 122 à 147
• lignes 151

Aux lignes 162 et 163, il peut être utile de mettre les valeurs propres à votre serveur, par exemple :

# It is also possible to set the sysContact and sysLocation system
# variables through the snmpd.conf file:
syslocation Serveur IT-Connect 01 
syscontact mickael@itc.loc

Une fois tout cela fait, on pourra redémarrer SNMP pour recharger la configuration modifiée (“systemctl restart snmpd” ), puis passer à la phase de test de notre service SNMP.

Configuration basique de SNMP sous Debian 8

Comme pour CentOS7, nous allons aller modifier le fichier /etc/snmp/snmpd.conf, on commence par également changer le nom de la community à la ligne 52 :

rocommunity masociete  default    -V systemonly

Également à la ligne 54 si vous avez IPv6 d’actif. On va également remplir les informations permettant d’identifier  l’administrateur à la ligne  81 :

sysLocation  Serveur IT-Connect 01 
sysContact mickael@itc.loc

Une fois tout cela fait, on pourra redémarrer SNMP pour recharger la configuration modifiée (“systemctl restart snmpd” ), puis passer à la phase de test de notre service SNMP.

V. Test de communication

Nous allons maintenant effectuer quelques tests pour vérifier que notre service SNMP est fonctionnel. Étant donné que nous avons installé la partie “client” de SNMP, on peut tester cela en localhost pour l’instant, en utilisant la commande “snmpwalk” :

snmpwalk -v1 127.0.0.1 -c masociete

Noté que 127.0.0.1 signifie “moi même”. Je ne fais rien transiter sur le réseau pour l’instant. Également, “masociete” est la community que j’ai mis dans la configuration, pensez à mettre la valeur que vous avez vous même saisie. Dans ma commande je ne demande pas d’OID spécifique, si mon service est fonctionnel, je vais avoir en retour un ensemble d’informations relatives à mon système :

.1.3.6.1.2.1.1.1.0 = STRING: Linux itc-serveur-02 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64
.1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.8072.3.2.10
.1.3.6.1.2.1.1.3.0 = Timeticks: (161275) 0:26:52.75
.1.3.6.1.2.1.1.4.0 = STRING: mickael@itc.loc (configure /etc/snmp/snmp.local.conf)
.1.3.6.1.2.1.1.5.0 = STRING: itc-serveur-02
.1.3.6.1.2.1.1.6.0 = STRING: Serveur IT-Connect 01 (edit /etc/snmp/snmpd.conf)
.1.3.6.1.2.1.1.8.0 = Timeticks: (3) 0:00:00.03
.1.3.6.1.2.1.1.9.1.2.1 = OID: .1.3.6.1.6.3.11.3.1.1
.1.3.6.1.2.1.1.9.1.2.2 = OID: .1.3.6.1.6.3.15.2.1.1
.1.3.6.1.2.1.1.9.1.2.3 = OID: .1.3.6.1.6.3.10.3.1.1
.1.3.6.1.2.1.1.9.1.2.4 = OID: .1.3.6.1.6.3.1
.1.3.6.1.2.1.1.9.1.2.5 = OID: .1.3.6.1.2.1.49
.1.3.6.1.2.1.1.9.1.2.6 = OID: .1.3.6.1.2.1.4
.1.3.6.1.2.1.1.9.1.2.7 = OID: .1.3.6.1.2.1.50
.1.3.6.1.2.1.1.9.1.2.8 = OID: .1.3.6.1.6.3.16.2.2.1
.1.3.6.1.2.1.1.9.1.2.9 = OID: .1.3.6.1.6.3.13.3.1.3
.1.3.6.1.2.1.1.9.1.2.10 = OID: .1.3.6.1.2.1.92
.1.3.6.1.2.1.1.9.1.3.1 = STRING: The MIB for Message Processing and Dispatching.
.1.3.6.1.2.1.1.9.1.3.2 = STRING: The management information definitions for the SNMP User-based Security Model.
.1.3.6.1.2.1.1.9.1.3.3 = STRING: The SNMP Management Architecture MIB.
.1.3.6.1.2.1.1.9.1.3.4 = STRING: The MIB module for SNMPv2 entities
.1.3.6.1.2.1.1.9.1.3.5 = STRING: The MIB module for managing TCP implementations
.1.3.6.1.2.1.1.9.1.3.6 = STRING: The MIB module for managing IP and ICMP implementations
.1.3.6.1.2.1.1.9.1.3.7 = STRING: The MIB module for managing UDP implementations
.1.3.6.1.2.1.1.9.1.3.8 = STRING: View-based Access Control Model for SNMP.
.1.3.6.1.2.1.1.9.1.3.9 = STRING: The MIB modules for managing SNMP Notification, plus filtering.
.1.3.6.1.2.1.1.9.1.3.10 = STRING: The MIB module for logging SNMP Notifications.

...

Si je veux une information plus spécifique, comme la description de mon système, je peux le demander également, par exemple :

snmpwalk -v1 127.0.0.1 -c masociete .1.3.6.1.2.1.1.1.0

La compréhension des OID et MIB peut être difficile lorsque l’on aborde SNMP, j’ai pour habitude d’utiliser l’option “-On” de snmpwalk qui permet d’afficher les OID dans leur forme numérique, qui sont plus facile à écrire.

Le tutoriel porte sur l’installation de SNMP, je n’irai donc pas m’aventurer sur les explications concernant les OID/MIB ici, mais sachez que l’on peut obtenir un grand nombre d’informations via SNMP, parfois la configuration devra être modifiée pour permettre la réponse à certaines requêtes SNMP. Il s’agira la plupart du temps d’ouvrir de nouvelle branche de notre MIB pour avoir accès à plus d’informations.

Pour terminer, vous pourrez normalement effectuer une requête similaire à distance, à travers le réseau (c’est à dire depuis une autre machine) si vous remplacer “127.0.0.1” par l’IP de la machine sur laquelle vous avez installé votre service SNMP.

En cas de problème :

• Vérifiez la connectivité réseau de vos deux machines, dans un premier temps via un ping
• Vérifiez si votre pare-feu (netfilter, iptables, nftables) ne bloque pas les paquets en entrée ou en sotie
• Vérifiez que votre service est bien en écoute sur le bon port, la bonne interface réseau, la bonne IP (v4, v6), notamment avec la commande “ss” vu dans l’article
• Vérifiez que les OID basiques soient joignables avant de questionner des OID plus spécifiques.

En espérant que tout cela soit clair et compréhensible ! Si vous avez des problèmes ou des questions, n’hésitez pas à utiliser notre forum.

Elles représentent sans aucun doute une étape importante dans la course lancée depuis plusieurs années maintenant pour rendre le datacenter plus flexible et l’informatique globalement plus agile. Elles ? Ce sont les appliances hyper-convergées, des solutions qui idéalement doivent combiner puissance de traitement, composants réseaux, capacité de stockage et, bien entendu, logiciels. Avec plusieurs bénéfices à la clé : assurer la virtualisation des ressources embarquées (le stockage y compris), garantir des temps de configuration et de mise en route très courts et, aussi, une forte évolutivité.

Ne nous trompons pas, c’est bien le logiciel qui constitue la valeur ajoutée d’une telle appliance et qui contribue à la mise en place d’un véritable « Software Defined Data Center » (SDDC). En témoigne, l’appliance EMC VSPEX BLUE qui, outre les logiciels de VMware vSphere et VSAN (pour la virtualisation serveur et stockage) reçoit aussi des fonctionnalités logicielles complémentaires pour étendre les capacités de stockage au cloud. Elle permet également des réplications par machine virtuelle et assure une surveillance sécurisée à distance.

Cette pile logicielle, combinée avec une forte intégration matérielle, explique les temps de déploiement très courts. Dans le cas de EMC VSPEX BLUE moins de quinze minutes sont nécessaires pour déployer les premières machines virtuelles. Au-delà de la mise en route, cette simplicité reste de mise pour la gestion des opérations courtes et met ainsi l’appliance à la portée des PME. D’autant plus que chaque nœud VSPEXBLUE embarque une capacité de stockage local et dispense donc les clients de recourir à un stockage externe (SAN ou NAS).

Quant à l’évolutivité, elle est, elle aussi, à l’ordre du jour, notamment en mode « scale out », donc par ajout de nœuds au fil de l’évolution des besoins.

Avec ces atouts, il n’est pas étonnant d’observer que les appliances suscitent d’ores et déjà l’intérêt, et cela bien au-delà des projets VDI (Virtualisation Desktop Infrastructure), leur terrain de prédilection initial. L’hyper-convergence est en marche…

Pour plus d’infos : EMC VSPEX BLUE

En passant de 35 à 25 dollars, le Raspberry Pi Model B+ devient encore plus accessible, notamment pour ceux qui souhaitent réaliser des projets à faible coût. Ce tarif est également plus en adéquation avec le prix du tout dernier Raspberry Pi 2, qui est vendu 35 dollars.

Avant cette baisse de prix, il n’y avait plus d’intérêt à acquérir un modèle B+, nettement moins performant que le dernier modèle. Désormais, le modèle B+ dispose d’un prix en adéquation avec sa configuration.

Pour résumer, voici les différents tarifs :

– Raspberry Pi Model A+ : 20 dollars
– Raspberry Pi Model B+ : 25 dollars
– Raspberry Pi 2 : 35 dollars

Les différents sites marchand ne devraient pas tarder à mettre à jour le prix du Rapsberry Pi Model B+ sur leur boutique.

Source

I. Présentation de Local Administrator Password Solution

La sécurité de vos postes de travail Windows doit être régulièrement au cœur de vos préoccupations, notamment le compte Administrateur local, qui représente une porte d’entrée importante sur votre machine. La portée d’un compte administrateur local est limitée puisqu’il a des autorisations uniquement sur la machine en elle-même.

Néanmoins, il peut s’avérer intéressant de sécuriser le compte Administrateur local de vos postes de travail, par exemple en renommant ce compte, ou encore avec un mot de passe complexe, qui sera bien souvent identique sur la majorité des machines (pour simplifier l’administration, et notamment si on déploie les machines via des images modèles).

Pour répondre à ce besoin de sécurité, Microsoft met à disposition un outil gratuit nommé « Local Administrator Password Solution » que l’on appellera « LAPS » qui permet de gérer automatiquement le mot de passe du compte « Administrateur » local de toutes les machines de votre domaine. Avec LAPS, le mot de passe est :

– Unique sur chaque poste de travail géré
– Généré aléatoirement
– Stocké de manière sécurisée dans l’annuaire Active Directory

L’intérêt est que cette solution s’intègre parfaitement dans un annuaire Active Directory déjà en place, et il n’est pas nécessaire d’installer et de gérer une solution tierce. Pour fonctionner, LAPS s’appuie sur les stratégies de groupe, deux attributs dans l’annuaire et quelques DLL.

Pour fonctionner l’application nécessite d’être installée les deux parties : les postes clients et sur au moins un contrôleur de domaine. Ce qui permettra de générer un nouveau mot de passe sur une machine lorsqu’il est expiré et le stocker dans l’annuaire Active Directory directement au niveau de l’objet ordinateur concerné, au sein d’un attribut spécifique.

Le contrôle de domaine doit être au minimum sous Windows Server 2003 SP1 et les postes clients au minimum sous Windows Vista. Pour les outils d’administration, PowerShell 2.0 au minimum et le .NET Framework 4.0.

Télécharger LAPS

II. LAPS – Installation sur le contrôleur de domaine

On commence par installer LAPS sur un contrôleur de domaine. Ce contrôleur de domaine doit être « Maître de Schéma » car il y a une mise à jour du schéma à faire à la suite de l’installation.
L’installation est très simple, suivez l’assistant jusqu’à l’étape de sélection des composants…

Étant donné que l’on se trouve sur le contrôleur de domaine, il est nécessaire d’installer les outils de gestion (Management Tools).

– Fat Client UI : Une interface qui permet de visualiser les mots de passe et options de façon graphique
– PowerShell module : Indispensable pour intégrer LAPS dans son infrastructure (AdmPwd.PS)
– GPO Editor Template : Intégration de paramètres GPO pour LAPS, via un fichier ADMX

Poursuivez la suite de l’installation, qui est classique et sans option particulière.

Avant de poursuivre la configuration du serveur, on va faire un saut sur la configuration des postes clients.

III. LAPS – Installation du client

« Local Administrator Password Solution » se présente sous la forme d’un package MSI, ce qui permet de le déployer facilement sur diverses machines via GPO, sinon on exécute l’installation en locale.

Pour procéder à une installation silencieuse (adaptez le chemin vers le fichier MSI) :

msiexec /i C :\LAPS.x64.msi /quiet

Si le fichier MSI se situe sur un partage, ça marche aussi bien entendu (intéressant pour scripter). Par exemple :

msiexec /i \\serveur\partage\LAPS.x64.msi /quiet

L’installation par défaut n’intègre pas les outils de gestion, ce qui permet de réaliser l’installation en mode silencieux. Dans la liste des programmes, LAPS apparaît bien suite à l’installation :

Pour le client, c’est tout il n’y a rien à faire d’autres. Enfin si, vous pouvez vérifier que le compte Administrateur local est bien actif sur la machine, au cas où.

IV. LAPS – Préparation du schéma Active Directory

Pour le bon fonctionnement de LAPS, le schéma de l’annuaire Active Directory doit être modifié afin d’ajouter deux nouveaux attributs :

– ms-MCS-AdmPwd : Stocke le mot de passe en clair
– ms-MCS-AdmPwdExpirationTime : Stocke la date d’expiration du mot de passe

Pour réaliser l’opération, il suffit d’exécuter deux commandes, la première pour charger le module PowerShell, la seconde pour déclencher la modification :

Import-Module AdmPwd.PS
Update-AdmPwdADSchema

Ce qui donnera le résultat suivant :

S’il y a un RODC dans votre infrastructure, prenez en considération cet article du TechNet pour intégrer les nouveaux attributs dessus : RODC LAPS

V. Les permissions – ACLs

Nous allons voir une série d’ajustement à effectuer au niveau des permissions pour que LAPS fonctionne et que ce soit sécurisé. Dans cet exemple, on appliquera les droits sur une OU nommée « Informatique » et qui contient un poste de travail nommé « WORK01 », faisant office de poste de travail de test pour ce tutoriel.

L’objectif sera de donner les droits au groupe « Admins du domaine » pour qu’il puisse avoir accès à la consultation des mots de passe, ainsi qu’à la modification notamment de la date d’expiration.

La procédure n’est pas généralisée pour tout l’annuaire, à chaque fois vous verrez que l’on cible une unité d’organisation en particulier. Ceci permet de gérer les autorisations finement, selon le niveau de l’OU dans l’arborescence.

A. Retirer les autorisations étendues

Certains groupes et utilisateurs sont en mesures de disposer d’autorisations étendues au sein de l’annuaire, ce qui permet de consulter la valeur de certains attributs, notamment ceux ajouté par LAPS.

Pour gérer ces droits, ouvrez la console ADSI avec le module « Contexte d’attribution de noms par défaut ». On effectue un clic droit sur l’OU « Informatique » et on accède aux propriétés.

Sélectionnez dans la liste l’utilisateur ou le groupe qui ne doit pas être capable de visualiser les mots de passe, et retirer l’autorisation « Tous les droits étendus » (si elle est active). Cette permission permet de lire la valeur de l’attribut ms-MCS-AdmPwd et les paramètres confidentiels.

A l’inverse donnez cette autorisation au groupe ou à l’utilisateur qui doit être capable de consulter cet attribut. Je précise que les « Admins du domaine » ont par défaut cette autorisation.

Après avoir effectué vos différents changements, validez et passez sur une console PowerShell.

Pour visualiser qui dispose des droits étendus sur une unité d’organisation, le module PowerShell de LAPS intègre une commande adaptée. Il suffit d’ajouter le nom de l’OU à la suite du paramètre « Identity ».

Find-AdmPwdExtendedRights -Identity informatique | ft ExtendedRightHolders

Cette première phase est terminée, passons à la seconde !

B. Donner les droits d’écriture aux machines

Les machines doivent être en mesure de mettre à jour les attributs ms-MCS-AdmPwdExpirationTime et ms-MCS-AdmPwd dans l’annuaire Active Directory, notamment pour indiquer la date d’expiration à venir et de mettre à jour les mots de passe.

Il y a un commandlet PowerShell tout simple pour cela, où il suffit d’indiquer le nom de l’OU cible :

Set-AdmPwdComputerSelfPermission -OrgUnit Informatique

Répétez cette opération pour chaque unité d’organisation concernée.

C. Autoriser la visualisation du mot de passe

Maintenant, on va donner l’autorisation à un groupe, en l’occurrence « Admins du domaine » de visualiser les mots de passe des ordinateurs administrés et situés dans l’OU « Informatique ».

Set-AdmPwdReadPasswordPermission -OrgUnit Informatique -AllowedPrincipals "Admins du domaine" | ft Name, DistinguishedName, Status

D. Réinitialisation du mot de passe

Les utilisateurs sont susceptibles de modifier la date d’expiration d’un mot de passe sur un objet ordinateur spécifique, notamment pour forcer la réinitialisation du mot de passe. De ce fait, une autorisation d’écriture doit être ajoutée sur l’attribut « ms-MCS-AdmPwdExpirationTime ».

Pour définir cette autorisation, on fait à nouveau appel au PowerShell et plus particulièrement au commandlet « Set-AdmPwdResetPasswordPermission ». Deux paramètres seront à définir :

– L’unité d’organisation cible (qui contient les ordinateurs administrés via LAPS)
– L’utilisateur ou le groupe auquel il faut donner l’autorisation

Set-AdmPwdResetPasswordPermission -OrgUnit Informatique -AllowedPrincipals "Admins du domaine"

Il est important de préciser que lorsque le mot de passe est transféré entre la machine cliente et le contrôleur de domaine, il est protégé grâce au chiffrement Kerberos. Au niveau de l’annuaire, l’accès à l’attribut qui contient les mots de passe et géré par ACL.

Passons maintenant à la mise en place d’une stratégie de groupe qui permet de configurer LAPS sur les postes clients.

VI. Configurer la GPO « LAPS »

Désormais on va s’intéresser à la création de la GPO, puisque je vous rappelle que LAPS ajoute un fichier ADMX sur le serveur, ce qui ajoutera forcément de nouveaux paramètres. Ouvrez la console d’édition des stratégies de groupe et créez ou modifiez une stratégie de groupe (GPO).

Grâce au template ADMX ajouté lors de l’installation de LAPS, une nouvelle catégorie est disponible dans les paramètres liés à l’ordinateur. Elle s’appelle tout simplement « LAPS ».

Au menu, rien de monstrueux mais tout de même 4 paramètres à notre disposition :

– Password Settings : Définir la complexité du mot de passe, sa longueur et sa durée de vie

– Name of administrator account to manage : Définir un compte administrateur à configurer autre que le compte Administrateur intégré à Windows. En effet, le compte Administrateur BUILT-IN est automatiquement détecté, grâce au SID (Identifiant de sécurité unique) même s’il est renommé.

– Do not allow password expiration longer than required by policy : Ne pas autoriser une expiration du mot de passe plus longue que le permet la stratégie

– Enable local admin password management : Activer ou désactiver la gestion du mot de passe administrateur avec LAPS.

On commence par définir une stratégie quant à la complexité des mots de passe. Il suffit d’éditer et de configurer le paramètre « Password Settings ».

Avec la stratégie indiquée sur la copie d’écran ci-dessous, on obtient des mots de passe très complexes, comme « 6F5g@FRlb)1KE. »

Il convient également d’activer le paramètre « Enable local admin password management » sinon LAPS ne sera pas actif et ne gérera pas les mots de passe.

Les deux autres paramètres sont optionnels. Il ne reste plus qu’à effectuer une mise à jour de la stratégie de groupe sur les postes clients ciblés (gpupdate).

VII. Visualiser un mot de passe

Un point crucial de l’utilisation de cet outil : la visualisation des mots de passe. Connecté en tant qu’administrateur du domaine sur mon contrôleur de domaine, j’accède aux propriétés de mon poste client « WORK01 » après avoir passé la console en mode avancé (ceci permet de visualiser des onglets supplémentaires).

Dans l’onglet « Editeur d’attributs », on obtient la liste de tous les attributs de cet objet ordinateur, et on trouvera nos deux attributs LAPS. Comme on peut le voir dans la copie d’écran ci-dessous, le mot de passe apparaît en clair, et la date d’expiration est indiquée en timestamp. D’ailleurs, pour convertir le timestamp en valeur compréhensible il existe des convertisseurs en ligne, comme : EpochConverter

Lors de l’installation sur le serveur, on a installé divers outils de gestion dont « LAPS UI ». Cet outil très intéressant est plus efficace que la lecture des données dans l’annuaire.

Après l’avoir démarré, il suffit d’indiquer un nom d’ordinateur dans le champ « ComputerName » de cliquer sur « Search », et le mot de passe apparaîtra en clair ainsi que la date d’expiration directement traduite !

Intéressant aussi, la possibilité de définir une nouvelle date d’expiration voir même une réinitialisation immédiate en laissant vide, et en cliquant sur « Set ».

Ce tutoriel sur l’outil « Local Administrator Password Solution » touche à sa fin. J’estime que cet outil apporte un vrai plus en matière de sécurité avec cette gestion intelligente des mots de passe. De plus, il est simple à mettre en œuvre et s’appuie sur des fonctions natives de l’Active Directory et supportées intégralement par les postes clients.

Que pensez-vous de Local Administrator Password Solution, cet outil gratuit proposé par Microsoft ?

I. Présentation du HB4009

Aujourd’hui je vais vous parler d’un petit boitier plutôt pratique : le HB4009 d’Inateck. Ce boitier n’est en apparence qu’un hub USB, à savoir un boitier qui se branche en USB et qui se compose de plusieurs autres ports USB, voyez plutôt :

Outre le fait que ce boitier possède 3 ports USB 3.0, on trouvera également une petite surprise : le “M-Port” ou “Magic Port” :

Il s’agit en effet d’un port USB présent sur l’autre extrémité du boitier et qui permet d’étendre de manière importante les possibilités limitées du simple “Hub USB“.

Au premier abord, la fonction USB est bien remplie, les ports USB permettent des transferts très intéressants, même avec plusieurs appareils connectés. Pour rappel, la fonction Hub USB est le simple fait d’avoir plusieurs ports USB supplémentaires via un seul appareil qui se connectera lui avec une seule prise USB sur la machine. On peut comparer cela à la fonction d’une multiprise électrique, mais pour les ports USB.

II. Mac KM Link : fonctionnalité surprise

Outre la fonction de Hub USB, le HB4009 propose une fonction permettant de créer un lien direct entre deux machines, de façon classique pour échanger des fichiers, mais pas seulement.

L’échange de fichiers entre deux machines est encore une problématique dans bien des contextes, souvent lorsque cela doit être rapide et qu’il serait trop fastidieux de créer un partage, y positionner les bons droits, etc. On passe alors souvent par l’échange par le Cloud ou par la clé USB (qui se font de plus en plus rare dans nos poches).

Le HB4009 permet de résoudre cette problématique via un petit logiciel qui se déploie sur les postes reliés et qui est intégré au hub USB : Mac KM Link

Lorsque l’on relie un PC au hub, celui-ci nous propose l’installation de ce petit utilitaire qui permet alors d’effectuer plusieurs actions entre les PC reliés :

• Échanger des fichiers en USB 3.0, avec un débit maximum théorique de 5Gb/s
• Partager souris et clavier, pour prendre le contrôle du PC relié
• Partager le presse-papier
• Faire transiter du son au travers

La fonctionnalité la plus intéressante à mon goût reste tout de même la possibilité de partager souris et clavier entre deux PC. Il est alors possible d’utiliser un second PC exactement comme le premier sans changer de clavier et de souris.

La possibilité de copier des données rapidement entre deux PC reste l’utilisation principale du HB4009, on peut alors oublier les problématiques de transfert entre deux postes en utilisant une clé USB ou une plateforme Cloud, il suffit de brancher le HB4009 !

Pour vous donner un rapide aperçu, une fois que les PC sont reliés, on peut simplement transférer un fichier en faisant un copié/collé de l’un vers l’autre. On aura également accès à l’application GO! Bridge qui permet d’avoir un aperçu direct des répertoires de la machine reliée :

On peut alors également y glisser/déposer des fichiers rapidement. Cela va bien sûr dans les deux sens puisque Mac KM Link sera installé sur les deux postes. On peut également noter que cela évite de faire deux transferts (machine A -> Clé USB puis Clé USB -> machine B) :

Outre l’échange de fichiers, diverses options permettent également la configuration du partage de la souris et du clavier, par exemple la position du deuxième PC par rapport au premier :

Cela dans le but de faire transiter les mouvements du curseur d’un PC à un autre lorsqu’il touche le bord associé, ce qui se fait de façon plutôt fluide.

Il faut d’ailleurs noter que ces fonctionnalités sont opérationnelles naturellement sous Windows, mais également sous Android et Mac OS.

Nous avons fait le tour de ce petit outil très pratique qu’est le HB4009 ! Pour ma part, je l’utilise surtout pour sa fonction de partage d’écran sans avoir à passer par un outil utilisant le réseau et aussi pour le transfert de fichiers entre PC.