Étiquette : ActiveDirectory

Pas de commentaire

Le KB2919355 n’est jamais disponible au téléchargement via Windows Update sur Windows Server 2012 R2

  de

Le KB2919355, ce patch récalcitrant apparu il y a quelques années en portant le nom de « Update 1 » pour les systèmes Windows de bureau, est un patch cumulatif de mises à jour également disponible pour Windows Server 2012 R2 ayant posé quelques soucis lors de ses premiers jours. Nécessaire pour certaines applications ainsi que globalement pour la sécurité du système par les failles qu’il corrige, j’ai été confronté plusieurs fois de manière aléatoire sur plusieurs serveurs à une indisponibilité dans Windows Update ; c’est-à-dire que Windows Update ne se voyait jamais proposer le téléchargement et l’installation de ce KB uniquement sur certains de mes serveurs virtuels, sans qu’il n’y ait jamais de variable commune.

Et c’est exactement cette absence de paramètre commun qui était étrange : 1 vCPU et 1 Go de RAM pour mes deux contrôleurs de domaine installés initialement en Core, 4 vCPU et 4 Go de RAM sur un serveur classique sans rôle avec interface graphique, des serveurs qui ne sont fatalement pas dans la même OU, qui ne se voient pas gérés de la même manière au niveau de ma GPO Windows Update… De plus, ils étaient installés avec le même ISO, utilisant la même licence.

Voulant éviter autant que possible une installation à la main, j’ai donc essayé plusieurs remèdes :

Le premier, la désactivation de Windows Update, la suppression du répertoire SoftwareDistribution localisé dans C:\Windows et la relance du service. Cela permet de réinitialiser Windows Update et son cache, et ainsi de repartir comme si vous n’aviez jamais installé de KB sur le système (c’est-à-dire que Windows Update perd son historique, les mises à jour restent installées). Avant de réaliser la suppression du répertoire, j’ai quand même procédé à une copie de sauvegarde au cas où.

net stop wuauserv
rd c:\windows\softwaredistribution /s /q
net start wuauserv

Pas mieux après cette tentative.

Le deuxième essai aura été celui de désactiver la GPO influant sur Windows Update (indiquant à mes serveurs de télécharger les mises à jours sans les installer). Même en indiquant aux serveurs de ne plus rechercher les mises à jour automatiquement et en lançant une recherche après un redémarrage, point de salut.

Troisième tentative de correction avec l’outil DISM, afin de vérifier que tous les composants systèmes sont bien installés et ne sont pas endommagés.

dism /online /cleanup-image /scanhealth

Et… tout va bien sur le système.

Quatrième et dernière commande, sans espoir :

sfc /scannow

Espoir vain, bien évidemment. Mes serveurs ne présentaient aucun bug, aucune corruption et étaient en parfait état de marche. Mais pour autant, j’avais toujours une disparité au niveau des patchs déployés car certains de mes serveurs avaient eu le droit à l’Update 1 et pas les autres.

En réalité, ce qui empêche Windows Update de voir ce gros KB2919355 de presque 900 Mo, c’est le KB2919442, qui pour des raisons inconnues, n’est pas toujours visible par Windows Update, il faut donc l’installer à la main. Il pèse 10 Mo et est disponible sur le site de Microsoft.

Une fois ce patch ridicule installé, on relance Windows Update et… miracle !

Le patch tant attendu apparaît et est enfin disponible au téléchargement, et à l’installation. Une fois toute l’opération déroulée, on retrouve parmi les changements esthétiques les boutons sur l’écran d’accueil.

Pas de commentaire

Mise en place d’OpenFire sur Debian Jessie

  de

Depuis quelques temps, je cherchais une solution de chat permettant de m’affranchir de Facebook et des autres plateformes comme WhatsApp ou Skype, afin de pouvoir satisfaire ma curiosité à ce sujet et essayer de convertir une partie de mes proches sur un outil de chat peut-être moins fringuant mais plus privé et personnel.

Après quelques recherches, je me suis donc orienté vers OpenFire qui est un serveur utilisant le protocole XMPP, qui fonctionne sous Windows, GNU/Linux et OS X. Dans mon cas précis, je vais réaliser l’installation de ce serveur sur un système d’exploitation Debian dans sa version Jessie (8.7).

1. Prérequis

 

Une fois l’OS de base installé, j’ajoute toujours par habitude fail2ban et proftpd, afin de pouvoir protéger le serveur par la suite et proftpd afin de faciliter le dépôt de fichiers sur la machine depuis mon filer. Ma machine étant hébergée sur un ESXi, j’installe les VMware tools.

apt-get install fail2ban
apt-get install proftpd
apt-get install open-vm-tools

A noter que par la suite, j’ajouterai certaines règles à fail2ban afin qu’il surveille les tentatives d’authentification sur le serveur OpenFire lui-même.

Dans un même souci de sécurité, je vais désactiver la connexion en root sur le serveur via SSH :

nano /etc/ssh/sshd_config

Je modifie de cette manière la ligne suivante (ancienne valeur en rouge, nouvelle valeur en vert) :

PermitRootLogin without-password
PermitRootLogin no

 Puis, un redémarrage du serveur SSH pour prendre en compte la modification :

/etc/init.d/ssh restart

Plus tard, lors de la configuration, je vais choisir l’authentification par ActiveDirectory. J’ai donc créé dans mon AD un groupe « OpenFire Users » avec le compte utilisateur dont je vais me servir afin de pouvoir me connecter à l’application. Pour des raisons de sécurité, je ne vais pas utiliser le même compte que mon compte usuel sur ma plateforme Windows mais un utilisateur tout simple. Je vais également créer un compte de service qui permettra à l’application d’avoir un accès en lecture seule uniquement à l’AD, afin de ne pas avoir à renseigner le compte d’administrateur du domaine ou mon compte d’administration personnel. Pour ce faire, je vais passer par une délégation de contrôle.

Clic droit sur le domaine « domaine.local » puis Délégation de contrôle

En choisissant le compte de service en question sur le domaine, je vais créer une tâche personnalisée à déléguer, sur ce dossier et les objets qui s’y trouvent. Enfin, je vais accorder les autorisations en lecture, en cochant Lire et Lire toutes les propriétés. Si tout s’est bien passé, le compte de service pourra lire le contenu du domaine.

2. Installation

 

Le paquet pour Debian fourni par l’éditeur d’OpenFire ne contient pas l’environnement Java nécessaire. Il faut donc l’installer préalablement. Etant donné que mon système est tout juste installé, je n’ai pas pris la peine de réaliser un apt-get update avant de lancer la commande suivante :

apt-get install default-jre

apt va installer la JRE présente dans les dépôts de Debian. La version requise par l’application est la version 1.7. Un simple java -version permet de renvoyer la version installée :

Une fois dans le répertoire dans lequel j’ai calé le paquet, un petit dpkg -i et l’installation se déroule. J’obtiens une notification comme quoi le répertoire créé pour l’utilisateur ne lui appartient pas : j’affecte un password à l’utilisateur et le rend propriétaire de son répertoire.

3. Configuration

 

L’installation étant terminée, j’ouvre donc un navigateur afin d’accéder à l’installateur web, qui va s’occuper de la création de la configuration de base ainsi que de la base de données. J’ai laissé les paramètres par défaut (encryption Blowfish, et les ports de la console d’administration, qui de toutes façons ne seront pas routés vers l’extérieur). 

Concernant la base de données, si je voulais utiliser mon serveur MySQL, vu le peu de criticité et de besoin pour l’instant, je me suis retourné vers une base de données embarquée. Si selon l’éditeur les performances sont en retrait, cela m’importe peu dans le cadre de mon utilisation personnelle. Je verrai éventuellement pour déporter la partie base vers mon serveur MySQL si l’envie m’en prend.

Vient ensuite la partie authentification. Je vais me baser sur mon domaine ActiveDirectory. La connexion se passe sans accrocs grâce aux autorisations que nous avons accordées durant les prérequis. Les DN (distinguishedName) se déduisent facilement ou peuvent être trouvées grâce à ADSI Edit.

Je laisse par défaut les configurations de mapping utilisateur et groupes, puis je spécifie temporairement mon compte comme administrateur de l’application. Je créerai un compte d’administration de l’application plus tard.

 

4. Administration

 

En me connectant avec le login déclaré comme administrateur de l’application, je peux parcourir les différents réglages de l’application. Les délégations permettent à l’application de bien parcourir le domaine, cependant l’application ne gère pas l’écriture dans un annuaire LDAP, par conséquent, la création d’utilisateurs, la modification de mot de passe ou autres opérations ne sont pas possibles ; il faudra se connecter sur une console ActiveDirectory pour procéder à une quelconque manipulations sur les comptes.

La première chose que je vais réaliser est un blocage des comptes d’utilisateurs qui ne sont pas dans le groupe « OpenFire Users » que j’ai créé au départ. Ainsi, des utilisateurs peuvent se connecter à l’application sans avoir forcément de comptes sur mes machines, ou un accès à une machine ne donne pas forcément d’accès à l’application.

L’option est des plus explicites. Dans la liste des utilisateurs visibles, on y retrouve un icône en plus d’avoir son nom barré pour signifier que cet utilisateur n’aura pas d’accès à l’application.

Ensuite, étant donné que je suis situé derrière un pare-feu et que j’utilise le NAT pour n’utiliser qu’une seule IP pour toutes mes machines virtuelles, je vais devoir faire quelques opérations de routage sur mon appliance pfSense (que j’aurai l’occasion d’aborder dans un futur billet). Dans l’interface d’administration, chaque port est plutôt bien détaillé.

Je vais changer les ports qui ont été inscrits par défaut, et en profiter pour forcer des connexions sécurisées afin que les données ne transitent pas en clair sur le réseau. En fonction de mes besoins au départ, il y a des connexions que je ne vais pas autoriser. Quelques paramètres de sécurité méritent également le détour (qui peut se connecter, plages IP autorisées, inscriptions en ligne…).

5. Tests de connectivité cliente

 

Maintenant que tout est configuré côté serveur – même si il y a sans doute de quoi peaufiner – il ne reste plus qu’à faire un essai en local, et un essai depuis le web.
Je réaliserai l’essai en local depuis une machine virtuelle Debian. Le client qui se connecte à OpenFire s’appelle Spark et il est édité par la même communauté. Tout comme le serveur, le client est disponible sur Windows, OS X et GNU/Linux. Et tout comme le serveur, le paquet pour Debian est livré sans Java, il faudra donc l’installer à part. Java étant déjà installé sur ma machine, je suis donc parti pour un dpkg -i du paquet spark, cependant, je me suis heurté à un mur :

 

J’ajoute dans ma liste de dépôts les dépôts jessie-backports sans oublier de les rafraîchir juste après :

deb http://ftp.fr.debian.net/debian jessie-backports main

Puis, je lance un aptitude install -s afin de simuler une installation du paquet et de voir exactement ce qui merde. En cause, des dépendances non satisfaites à cause de la différence de version entre les paquets dans la branche usuelle et la branche backports de Jessie.

aptitude install -s permet de simuler une installation des paquets pour diagnostiquer ce qui ne fonctionne pas correctement.
Je finis par accepter l’installation de ce paquet dans la version la plus récente, disponible dans le dépôt ajouté précédemment.
Le paquet s’installe bien.

Enfin, je peux conclure en installant le paquet Java final.

Je peux enfin réaliser mon dpkg -i spark_2_8_3.deb et exécuter l’application.

Vu que je ne possède pas de certificats, je vais cocher les deux options pour accepter tous les certificats et pour ne pas vérifier le nom du serveur afin de pouvoir me connecter. Je saisis ensuite mes identifiants… Et ça marche !

Il ne me reste plus qu’à réaliser un test de connexion depuis l’extérieur, ajouter les quelques règles fail2ban si nécessaires… et demander à mes proches d’installer cette petite appli pour discuter en tout temps. Le serveur étant plus orienté utilisation professionnelle que personnelle, il n’y a pas d’application tout du moins sur iOS.

Pas de commentaire

Sauvegarde wbadmin impossible sur contrôleur de domaine virtuel 2012 R2

  de

Comme premier article, je vais aborder le problème auquel j’ai été confronté récemment après avoir mis en place ma petite infrastructure que je présenterai éventuellement dans un prochain billet.

Je possède un contrôleur de domaine fonctionnant sous Windows Server 2012 R2, le seul de la forêt. Je possède un autre serveur 2012 R2, qui va recevoir sur un disque virtuel dédié les fichiers de sauvegarde des autres serveurs Windows ainsi que les fichiers des quelques scripts de sauvegardes de mes machines Linux.

Je veux donc concentrer sur ce serveur les sauvegardes Windows Server afin de pouvoir les sauvegarder en ligne plus facilement par la suite.

Sur mon contrôleur de domaine, j’installe donc la fonctionnalité Windows Server, et tente d’exécuter une première sauvegarde. Pour des raisons de performances disques (disques mécaniques en SATA3) et vu le peu de criticité, je ne souhaite pas effectuer de sauvegarde planifiée mais des sauvegardes uniques que je réaliserai de temps en temps. Je choisis donc de sauvegarder le serveur complet.

Je précise l’emplacement réseau du lecteur de sauvegarde, et je lance l’opération. Quelques minutes plus tard, la sauvegarde rentre en erreur au moment de sauvegarder le disque C:.

Dans les logs, rien de bien transcendant : c:\windows\logs\WindowsImageBackup

J’essaye donc de sauvegarder un autre serveur exactement de la même manière et avec le même compte de sauvegarde (un compte de service qui est le seul à avoir les droits complets sur le dossier du partage réseau, et qui est membre du groupe Opérateurs de Sauvegarde). Cela fonctionne, cela signifie que ce n’est pas le partage réseau qui pose problème.

Autre piste suggérée : la taille des secteurs n’est pas la même. En regardant sur les deux machines grâce à msinfo32.exe, je vois qu’ils font bien la même taille de 512 K.

Je tente un sfc /scannow sur le contrôleur de domaine afin de vérifier l’état des fichiers système, même si le serveur a été installé il y a moins de 48 heures. Pas d’erreur décelée. Je monte un second disque virtuel afin d’effectuer une sauvegarde en local, toujours impossible, le problème semble donc venir de l’accès au C:.

Finalement, je décide alors de boycotter l’interface graphique de wbadmin ainsi que l’utilisation en ligne de commande qui ne donne pas plus de résultats, même avec un lancement en tant qu’administrateur du domaine. Je recherche rapidement sur le web comment utiliser PowerShell pour se substituer au cmd et tombe sur un script fourni sur une plateforme Microsoft.
Etant donné que je n’ai pas besoin de toute la partie envoi de mail ni suivi du nombre de sauvegarde, je l’ai quelque peu simplifié.

Add-PsSnapin Windows.ServerBackup
$Server = « \\serveur »
$Folder = ($Server+ »\dossier »)
$WBPolicy = New-WBPolicy
Add-WBBareMetalRecovery -Policy $WBPolicy | Out-Null
$BackupLocation = New-WBBackupTarget -network ($Folder)
Add-WBBackupTarget -Policy $WBPolicy -Target $BackupLocation -force | Out-Null
$WBPolicy | Out-Null
Start-WBBackup -Policy $WBPolicy

On spécifie donc un serveur de sauvegarde, un répertoire accessible, on spécifie les paramètres souhaités dans la policy, et on exécute.
Via PowerShell, la sauvegarde s’est bien déroulée, il ne me restera plus qu’à appeler ce script lorsque je souhaiterai réaliser une sauvegarde. A noter que le script d’origine permet de sauvegarder également les autres volumes du systèmes qui sont non critiques (non swap, non système), mais n’ayant qu’un volume sur ce DC, l’option ne me concerne pas. Vous pouvez trouver le script d’origine en suivant ce lien. Apparemment la fonctionnalité WBBackup de PowerShell est conseillée par rapport au wbadmin. Question d’habitudes, j’utilisais toujours wbadmin avant.

Il ne me reste plus qu’à uploader sur mon ftp la sauvegarde pour être tranquille, et la faire redescendre sur ma station de travail au cas où.

Vous pouvez récupérer le script présent dans ce billet en le téléchargeant sur mon miroir de fichiers.