Générer un fichier .CSR à l’aide d’une MMC et faire une demande de certificat.

Dans cet article, je partage avec vous une méthode toute simple pour générer un fichier de demande de certificat (.CSR) à l’aide d’une MMC.

>>  Ouvrir une MMC sur votre serveur de certificat.

01

 

>> Fichier >> Ajouter/Supprimer un composant enfichable…

2

Certificats >> Ajouter

3

Cocher >> Un compte d’ordinateur (car on veut demander un certificat pour l’ordinateur)

4

>>  L’ordinateur local >> Terminer

5

>> OK

6

>> Cliquer-droit sur Certificats >> Toutes les tâches >> Opérations avancées >> Créer une demande personnalisée…

7

>> Suivant

8

>> Suivant

9

>> Suivant

10

>> Suivant

11

>> Cliquer sur Détails >> Propriétés

12

>> Dans l’onglet Général, entrer le nom convivial de votre certificat

Dans la fenêtre suivante, faire:

>> Objet >> Dans Nom du sujet > > Type : Nom commun >> Valeur : tosca.sibille.lan puis cliquer sur Ajouter

13

Répéter cette action pour Nom du sujet

Type Valeur
Nom commun mon.domaine.lan
Pays FR
Ville PARIS
Organisation Mon organisation
Unité d’organisation DSI
Etat IDF

Répéter cette action pour l’onglet Autre nom (seulement, si vous souhaitez que le certificat comporte des noms alternatifs pour vos serveurs)

Type Valeur
DNS
  • appli1.domaine.lan
  • serveur2.domaine.lan
  • fqdn03.domaine.lan
  • appli04.domaine.lan
  • appli05.domaine.lan

 

>> Appliquer >> OK

 

14

>> Suivant et en registrer le fichier CSR

15

Aller dans l’emplacement où est enregistrer le fichier CSR et l’ouvrir, puis copier son contenu.

16

Se connecter à l’URL de demande de certificats de votre autorité de délivrance de certificat. exemple: https://monserveur/certsrv

17

>> Coller le contenu du fichier copié précédemment dans « Demande enregistrée » puis sélectionner votre modèle de certificat dans « Modèle de certificat ».

>> Envoyer

18

>> Télécharger le certificat

Vous devrez observer ici le nom du sujet renseigné précédemment dans CN, on peut voir également les informations de validité du certificat. Je rappelle que cette information dépend du modèle de certificat que vous aurez auparavant choisi.

19

>> Détails

20

Et voilà, nous avons généré un fichier de demande de certificat, puis effectué la demande de certificat auprès de notre autorité de certificat. Je rappelle que le fichier CSR peut aussi servir à faire une demande auprès d’une autorité publique.

Dans ce billet, nous avons supposé qu’une autorité de certification était déjà en place dans votre organisation. Vous pouvez toutefois consulter l’une de mes publications précédentes qui montre comment mettre en place une autorité de certification si vous en avez pas : Déployer une PKI 3-tiers en entreprise.

A bientôt dans un prochain article 🙂 !

 

Configurer vos applications pour les connexions sécurisées LDAPs

Dans une entreprise, certaines applications peuvent avoir besoin de se connecter au serveur LDAP pour récupérer des information ou des droits d’accès pour les utilisateurs. Pour se faire, ces applications s’appuient sur un fichier de configuration, qui dans une configuration classique, peut ressembler à ceci :

#config  ldap
ldap.usersearchfilter=(samAccountName={0})
ldap.usersearchbase=DC=mondomaine,DC=lan
ldap.url=ldap://mondomaine.lan:389    # connexion non sécurisée
ldap.managerdn=CN=svc_ldapRdr,OU=Comptes services,DC=mondomaine,DC=lan #Compte de service d’accès au serveur LDAP
ldap.managerpassword= »MDP du compte svc_ldapRdr »
ldap.grouproleattribute=CN

On peut remarquer que la connexion ici n’est pas sécurisée car utilise un simple bind (port 389), pas sécurité. cela veut dire qu’on peut récupérer les mots de passe si on place un sniffer (wireshark par exemple) entre l’application et le serveur LDAP.

Pour une connexion sécurisée, on aurait plutôt utilisé la configuration suivante:

#config  ldap
ldap.usersearchfilter=(samAccountName={0})
ldap.usersearchbase=DC=mondomaine,DC=lan
ldap.url=ldaps://mondomaine.lan:636      # connexion sécurisée à LDAP
ldap.managerdn=CN=svc_ldapRdr,OU=Comptes services,DC=mondomaine,DC=lan #Compte de service d’accès au serveur LDAP
ldap.managerpassword= »MDP du compte svc_ldapRdr »
ldap.grouproleattribute=CN

Afin de réaliser une connexion sécurisée en SSL sur un serveur LDAP à a partir d’un serveur tomcat installé sous Windows. Il est nécessaire d’enregistrer les certificats SSL au niveau de la JVM du tomcat (keystore). Pour cela on va utiliser les outils suivants :

Keytool qui est un outil de gestion des certificats proposé dans les binaires de la JDK
Un programme JAVA : InstallCert.java permettant de récupérer les certificats SSL sur un serveur donné et de les importer dans la JVM.

Exemple:
Notre serveur LDAP de domaine (Active Directory) et un point d’entrée qui redirige vers un de ces contrôleurs :

Point d’entrée :

ldaps://mondomaine.lan:636

Notre serveur LDAP :

DC01.mondomaine.lan

L’applicatif se connectant sur le LDAP doit se connecter sur l’adresse suivante

ldaps://mondomaine.lan:636

Pour enregistrer les certificats SSL des serveurs LDAP dans le keystore de la JVM, il faut :
– Compiler le programme InstallCert en lançant la commande : javac InstallCert
– Lancer le programme InstallCert sur les 4 serveurs afin de récupérer les certificats :

java InstallCert DC01.mondomaine.lan:636

Après le lancement de ces programmes un fichier jssecacerts à été généré dans le répertoire courant
– Il faut maintenant exporter les certificats contenus dans le fichier jssecacerts pour chaque serveur en lançant les commandes suivantes :

« C:\Program Files\Java\jre7\bin\keytool.exe »  -exportcert -alias dc01.mondomaine.lan -keystore jssecacerts -storepass changeit -file DC01.mondomaine.lan.cer

– Une fois les exportations terminées, il faut importer les certificats générés dans le keystore de la JVM en lançant les commandes suivantes :

« C:\Program Files\Java\jre7\bin\keytool.exe » -keystore « C:\Program Files\Java\jre7\lib\security\cacerts » -importcert -alias DC01.mondomaine.lan -file dc01.mondomaine.lan.cer

Et voilà, j’espère que cet article vous aura été utile 🙂

Mettre en oeuvre la fédération d’identité avec AD FS

Le nom de notre serveur est SRVADFS01

1 – Ajout du rôle Active Directroy Federation Services

Ouvrir la session sur notre seveur Windows Server 2012 R2. Se connecter au Gestionnaire de serveur et ajouter un rôle

ADFS01

Add Roles and Features

ADFS02

ADFS03

ADFS04

ADFS05

Cocher la case « Active Directory Federation Services » puis cliquer sur Suivant

ADFS06

ADFS_Install_Confirmation

ADFS07

L’installation est terminée, fermer l’assistant d’installation.

2 – Demander un certificat pour notre serveur AD FS

Créer un fichier .CSR

ADFS08

ADFS09

ADFS10

3 -Terminer la configuration du serveur AD FS

Toujours sur notre serveur SRVADFS01

ADFS11

ADFS12

ADFS13

ADFS14

ADFS15

ADFS16

Et voilà, votre serveur ADFS est installé…

Gérer les mises à jour (MAJ) de sécurité avec WSUS dans un domaine AD

… parce qu’un peu de théorie avant la pratique n’a jamais fait de mal 🙂

Architecture :

  • Un serveur WSUS membre du domaine AD
  • Un accès internet pour le serveur WSUS
  • Configurer des GPOs pour cibler les ordinateurs qu’on souhaite patcher
  • Gérer les MAJ pour les ordinateurs non-membres du domaine
  • Mettre en place un planning de gestion des mises à jour (MAJ)

Petit rappel :

Windows Server Update Services (WSUS) permet aux administrateurs systèmes de déployer les dernières mises à jour de produits Microsoft sur les ordinateurs qui exécutent le système d’exploitation Windows. En utilisant WSUS, les administrateurs peuvent gérer entièrement la distribution des mises à jour publiées via Microsoft Update sur les ordinateurs de leur réseau. Pour plus d’information sur le produit, consulter le site dédié à WSUS.

Microsoft publie tous les deuxièmes mardis de chaque mois un bulletin de sécurité (Tuesday patch) pour ses applications et systèmes d’exploitation, consultable sur ici.

Gestion des MAJs en entreprise (retour d’expérience) :

Je vous propose dans cette rubrique, ce retour d’expérience sur la façon de gérer le patch management mensuel en environnement de production.

Semaines Plan de mise à jour
Semaine 1:

Ne pas déployer de mise à jour.

Les admins ont aussi droit à des journées tranquilles non? 🙂

En réalité, cette période doit servir à préparer le patch du mois en cours, s’assurer :

  • de l’état de santé du serveur WSUS
  • de ce que les ordinateurs à patcher communiquent bien avec le serveur WSUS
  • développer des scripts de reporting, reboot etc…
Semaine 2 :

Postes/Serveurs pilotes

  1. Sortie des mises à jour par Microsoft
  2. Appliquer les mises à jour de sécurité et les mises à jour critiques sur les postes/serveurs pilotes
  3. Redémarrer les postes/serveurs pilotes
  4. Surveiller les postes mis à jour
  5. Corriger les éventuels bugs/anomalies
Semaine 3 :

Postes/Serveurs de Production 1

  1. Appliquer sur un groupe de postes/serveurs en production
  2. Redémarrer les postes/serveurs de production
Semaine 4 :

Postes/Serveurs de Production 2

  1. Appliquer les mises à jour des serveurs critiques
  2. Redémarrer les serveurs critiques

NB: Pour les serveurs redondants c’est-à-dire en Load balancing ou en Cluster de basculement, éviter de patcher les deux dans la même vague de mises à jour.

Exemple: Mise à jour de serveurs Exchange membres d’un DAG à trois (03) noeuds. supposons qu’il y a des bases actives uniquement sur 2 noeuds (SRVEX01 et SRVEX02), le troisième (SRVEX03) étant dédié aux copies passives.

Dans le cadre d’un patch management, on pourra suivre l’ordre suivant:

  1. Mise à jour de SRVEX03 (semaine 2, dans le lot des serveurs pilotes)
  2. Ensuite, passer à la maj du serveur SRVEX01 (Semaine 3, dans la première vague de cette semaine)
  3. Terminer avec SRVEX02, toujours dans la semaine 3, vague 2 par exemple.

NB: les semaines étant composées de 5 jours ouvrés, je vous conseille les vagues horaires suivantes:

  1. Vague 1 : Nuit de Lundi à Mardi
  2. Vague 2 : Nuit de Mardi à Mercredi
  3. Vague 3 : Nuit de Mercredi à Jeudi

Attention !

Les journées de Jeudi et de vendredi peuvent être utiles à la résolution d’éventuels incidents liés au patch management. C’est pourquoi je vous conseille de ne surtout pas faire de maj durant cette période et aussi la veille des jours fériés au risque de les consacrer à la résolution d’incidents 🙂 …

…Dans une prochaine rubrique, je vous expliquerai comment installer WSUS pour la gestion des mises à jour.