Les équipements Hardwares
1. Cas d’une interface HP iLO
Les cartes iLO permettent aux administrateurs de se connecter aux serveurs lorsque ceux-ci sont "plantés" et donc injoignables depuis leur système d’exploitation. Cette carte matérielle embarque un programme appelé "logiciel embarqué" ou "firmware", indépendant donc du système d’exploitation, qui permettra d’effectuer des tâches administratives (essentiellement d’arrêt et de redémarrage du serveur) ou bien de visualiser différents états des périphériques du serveur (disque, processeur, mémoire). Ainsi, le firmware iLO peut s’interconnecter à tout type d’annuaire supportant le protocole LDAPv3 comme par exemple Microsoft Active Directory ou bien Novell e-Directory pour l’authentification et l’autorisation des utilisateurs. Par ailleurs, il se connecte aux services d’annuaire en utilisant le protocole de transport sécurisé SSL via le port 636/TCP par défaut du serveur LDAP.
Lorsqu’une carte iLO est connectée à un annuaire, il est toujours possible et recommandé d’utiliser les comptes locaux. En effet, ces derniers pourraient avoir leur utilité en cas de défaillance de l’annuaire.
¬
Rappel : ne jamais oublier d’intégrer une procédure d’urgence de connexion aux équipements et applications au cas où l’annuaire deviendrait indisponible (Emergency procédure).
a. Configuration
Afin de configurer la carte iLO pour l’utilisation de l’annuaire Openldap, il faudra au préalable s’assurer que l’annuaire possède le module memberof. S’il ne s’y trouve pas, alors il faudra le créer.
Exemple
dn: cn=module{0},cn=config 
objectClass: olcModuleList 
cn: module{0} 
olcModuleLoad: {0}syncprov.la 
olcModuleLoad: {1}ppolicy.la 
olcModuleLoad: {2}back_monitor.la 
olcModuleLoad: {3}memberof 
olcModulePath: /usr/lib64/openldap 
 
dn: olcOverlay={2}memberof,olcDatabase={1}bdb,cn=config 
objectClass: olcMemberOf 
objectClass: olcOverlayConfig 
olcOverlay: {2}memberof
Ensuite, il faudra créer un groupe qui sera utilisé par iLO et y inclure un utilisateur :
Exemple
dn: cn=adminilo,ou=groups,dc=exemple,dc=com 
objectClass: top 
objectClass: groupOfNames 
cn: adminilo 
member: cn=userA,ou=users,dc=exemple,dc=com
Il est maintenant temps de se connecter à la console graphique de la carte iLO en naviguant comme suit : Administration - Security - Directory.
La fenêtre de configuration ci-dessous apparaîtra.
¬
Figure 13-3 - Fenêtre de configuration iLO
1.	Il faudra configurer le paramètre LDAP Directory Authentication en sélectionnant :
	•	Soit "Use HP Extended Schema" : c’est un schéma à charger dans l’annuaire LDAP qui permet d’ajouter tout un tas d’attributs spécifiques iLO aux utilisateurs, permettant d’exploiter au mieux le service d’annuaire. 
	•	Ou bien ’Use Directory Default Schema’ : cette valeur spécifie d’utiliser le schéma de l’annuaire. L’authentification et l’autorisation dans iLO se feront donc en utilisant des comptes d’utilisateurs de l’annuaire.	
2.	Puis conserver la possibilité de se connecter avec des comptes locaux en spécifiant :
	•	Local User Accounts : Enabled.	
3.	Paramétrer ensuite l’adresse et le port du serveur LDAP à joindre :
	•	Directory Server Address : adresse IP ou alias DNS (maximum 127 caractères).
	•	Directory Server LDAP Port : port du service LDAP (636).	
4.	Et enfin, configurer le ou les "baseDN" des utilisateurs de l’annuaire à utiliser pour l’authentification sur la carte iLO par l’intermédiaire des paramètres de type Directory User Context. Ce champ est multivaleur, car il permet de se servir d’utilisateurs qui pourraient être placés à différents endroits de l’annuaire.
	•	Par exemple, si des objets utilisateurs se trouvent dans la partie ou=ITteam, dc=exemple, dc=com et dans ou=Training,team,ou=paris,dc=exemple,dc=com de l’annuaire, alors il faudra configurer deux paramètres comme suit :
	•	Directory User Context 1: ou=ITteam,dc=exemple,dc=com,
	•	Directory User Context 2: ou=Trainingteam,ou=paris,dc=exemple,dc=com.	
5.	Appuyer sur Apply settings puis Test settings et la fenêtre suivante apparaîtra. Il faudra alors entrer le "rootDN" avec son mot de passe et également un utilisateur avec son mot de passe pour tester que l’authentification au travers d’un annuaire LDAP fonctionne.	
¬
Figure 13-4 - Fenêtre de test iLO/Directory
Il faudra aussi ajouter le groupe précédemment créé dans l’annuaire OpenLDAP dans la configuration iLO : Administration -> User Administration, dans la partie Directory Groups en cochant tous les droits nécessaires.
2. Cas d’un Routeur (Cisco ASA)
Les équipements réseau Cisco récents intègrent le modèle de sécurité concernant le contrôle des accès des utilisateurs nommé "AAA" (désignant en anglais : Authentication, Authorization, Accounting/Auditing). Ce modèle permet ainsi d’accomplir les actions suivantes : l’authentification, l’autorisation et la traçabilité. C’est-à-dire qu’une fois activé et configuré sur l’équipement, il sera alors possible d’utiliser des comptes individuels et de désigner quels utilisateurs seront autorisés à s’y connecter, puis, de leur attribuer des droits d’administration déterminant ce qu’ils peuvent faire ou pas sur cet équipement.
Enfin, la fonction de traçabilité permettra d’enregistrer les actions effectuées par chaque utilisateur.
Les équipements routeur Cisco ASA supportent le protocole LDAP, mais celui-ci n’offrira dans le modèle de sécurité "AAA" que la fonction d’authentification. En effet, dans sa version actuelle, il n’est pas (encore) capable de gérer l’attribution de droits à des utilisateurs ou des groupes d’utilisateurs. Il en est de même pour la traçabilité où rien ne semble paramétrable avec le serveur LDAP. Pour ce dernier point, il existe bien entendu des techniques de configuration via le protocole "syslog" qui est un standard dans la transmission d’événements, supportés également par les routeurs Cisco ASA.
Ainsi, le routeur Cisco ASA se comportera comme un client LDAP (ou bien le terme proxy LDAP) afin d’authentifier l’utilisateur souhaitant se connecter à l’équipement auprès de l’annuaire LDAP. C’est-à-dire qu’il se connectera au serveur LDAP avec sa propre accréditation et transmettra les informations de l’utilisateur au serveur LDAP afin de valider ou non sa connexion à l’équipement.
La configuration de ce service d’authentification LDAP se fera donc en deux étapes :
	•	Configuration de la méthode d’authentification à l’annuaire LDAP (phase de bind).
	•	Configuration des informations à rechercher dans l’annuaire pour authentifier un utilisateur de l’équipement.
a. Les méthodes d’authentification à l’annuaire LDAP
Le routeur Cisco ASA supporte le mécanisme d’authentification de base (appelé en anglais : simple bind), mais aussi certains des mécanismes SASL parmi lesquels Digest-MD5 et Kerberos. Il est bien entendu possible de le configurer afin d’utiliser plusieurs mécanismes SASL. Dans ce cas, le client et serveur LDAP établiront une liste de mécanismes d’authentification qu’ils ont en commun et choisiront le plus "fort". Par exemple, si le serveur LDAP et le routeur Cisco ASA prennent en charge les deux mécanismes précédemment cités, alors ils sélectionneront "Kerberos" comme mécanisme d’authentification.
Dans le cas de l’environnement de démonstration choisi pour cet ouvrage, une authentification simple, mais toujours relayée par SSL/TLS sera appliquée.
b. Les informations à rechercher
Une fois que le client s’est authentifié auprès du serveur LDAP, il faudra qu’il puisse formuler la bonne requête LDAP auprès de ce dernier pour cette fois authentifier l’utilisateur final. Pour ce faire, il faudra configurer les informations de base de recherche (basedn) avec sa portée (base, one ou bien subtree) et du type d’attribut à chercher (par exemple uid).
c. La configuration
Tout d’abord s’assurer de la version de l’ios du routeur Cisco ASA.
# Version du routeur / FW 
prod-fw-01# sho run 
: Saved 
:  
: Serial Number: JMX1623X026 
: Hardware:   ASA5510, 1024 MB RAM, CPU Pentium 4 Celeron 1600 MHz 
: 
ASA Version 8.4(7)28
Il faudra ensuite créer les objets "serveur LDAP".
# Créer les objets des serveurs LDAP 
Router>en 
Router#conf t 
Router(config)#object network PROD-LDAP-01 
Router(config)#host xxx.xxx.xxx.xxx 
Router(config)#description First ldap server 
Router(config)#object network PROD-LDAP-02 
Router(config)#host xxx.xxx.xxx.xxx 
Router(config)# description Second ldap server
Créer le groupe d’authentification LDAP "aaa-server" dans lequel on configurera chacun des serveurs LDAP avec les informations d’authentification et de recherche dans l’arborescence.
La syntaxe de base est : aaa-server server_group [ interface_name ] host server_ip.
Les commandes ci-dessous montrent comment créer un groupe d’authentification LDAP :
# Création du groupe et des serveurs LDAP 
Router(config)# aaa-server LDAP_SRV_GRP protocol ldap 
Router(config-aaa-server-group)# max-failed-attempts 2 
Router(config-aaa-server-group)# reactivation-mode depletion deadtime 20 
Router(config-aaa-server-group)#exit 
Router(config)# aaa-server LDAP_SRV_GRP (TELCO_0) host PROD-LDAP-01 
Router(config-aaa-server-group)# ldap-base-dn dc=exemple,dc=com 
Router(config-aaa-server-group)# ldap-scope subtree 
Router(config-aaa-server-group)# ldap-naming-attribute uid 
Router(config-aaa-server-group)# ldap-login-password ***** 
Router(config-aaa-server-group)# ldap-login-dn  
cn=device,ou=binds,dc=exemple,dc=com 
Router(config-aaa-server-group)# ldap-over-ssl enable 
Router(config-aaa-server-group)# server-type openldap 
Router(config-aaa-server-group)#exit 
Router(config)# aaa-server LDAP_SRV_GRP (TELCO_0) host PROD-LDAP-02 
Router(config-aaa-server-group)# ldap-base-dn dc=exemple,dc=com 
Router(config-aaa-server-group)# ldap-scope subtree 
Router(config-aaa-server-group)# ldap-naming-attribute uid 
Router(config-aaa-server-group)# ldap-login-password ***** 
Router(config-aaa-server-group)# ldap-login-dn  
cn=device,ou=binds,dc=exemple,dc=com 
Router(config-aaa-server-group)# ldap-over-ssl enable 
Router(config-aaa-server-group)# server-type openldap 
Router(config-aaa-server-group)#exit 
Router(config)#
	•	Le paramètre ldap-base-dn permet de définir l’endroit où le routeur/FW commencera à rechercher l’utilisateur à authentifier. 
	•	Le paramètre ldap-scope=subtree indique de rechercher cet utilisateur dans n’importe quelle sous-branche à partir de la base fournie précédemment.
	•	Le paramètre ldap-naming-attribute indique que l’attribut sAMAccountName sera utilisé comme identifiant du nom de connexion.
	•	Les paramètres ldap-login-dn et ldap-login-password permettent de configurer l’utilisateur de liaison qui sera utilisé pour se connecter au serveur LDAP.
¬
Il est important de renseigner le chemin complet de l’utilisateur de liaison comme indiqué dans l’exemple ci-dessus.
	•	Le paramètre ldap-over-ssl permet d’activer la communication sécurisée LDAPS.
	•	Et enfin, le paramètre server-type permet de spécifier la nature du serveur LDAP.
Ainsi, dès lors que le protocole LDAPS sera utilisé, il faudra importer le certificat de l’autorité de certification qui aura émis le certificat du serveur LDAP. Pour ce faire, il faudra tout d’abord créer un ’Trustpoint’ dans lequel le certificat de l’autorité de certification sera importé.
La création du ’Trustpoint’ s’effectuera à l’aide des commandes de l’exemple ci-dessous :
Exemple
Router(config)# crypto ca trustpoint <trustpoint-name> 
Router(config-ca-trustpoint)# revocation-check crl none 
Router(config-ca-trustpoint)#  enrollment terminal 
Router(config-ca-trustpoint)#  ip-address xxx.xxx.xxx.xxx 
Router(config-ca-trustpoint)#  crl configure 
Router(config-ca-trustpoint)#  exit 
Router(config)# wri mem
Le chargement du certificat de l’autorité de certification s’effectuera à l’aide des commandes de l’exemple ci-dessous :
Exemple
Router(config)# crypto ca authenticate <trustpoint-name>  
Enter the base 64 encoded CA certificate.  
End with a blank line or the word "quit" on a line by itself  
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs 
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j 
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowcDEL 
. . .  
0wGjIChBWUMo0oHjqvbsezt3tkBigAVBRQHvFwY+3sAzm2fTYS5yh+Rp/BIAV0Ae 
cPUeybQ=  
quit  
INFO: Certificate has the following attributes:  
Fingerprint: 24b81533 409b3fd5 a5431659 8dtt0d34  
Do you accept this certificate? [yes/no]: y  
Trustpoint CA certificate accepted.  
% Certificate successfully imported 
¬
Il faut effectuer un copier/coller du certificat depuis son format ascii.
Il est maintenant possible de revoir la configuration effectuée à l’aide de la commande :
show run aaa
Puis il est possible de tester la configuration à l’aide de la commande test aaa-server authentication, comme dans l’exemple ci-dessous :
Exemple
Router # test aaa-server authentication LDAP_SRV_GRP username 
’userA’ password xxxx 
 
INFO: Authentication Successful
¬
En cas de l’échec du test, une aide supplémentaire peut être obtenue en activant le debug par la commande debug ldap 255, puis en essayant de nouveau le test.
Et enfin, dès que l’accès aux serveurs LDAP est validé, il faudra déclarer les associations "Service de connexion/méthodes d’authentification".
L’exemple ci-dessous montre que l’authentification via l’interface série (ou modem) du routeur utilisera seulement les comptes des utilisateurs locaux, alors que par le port console et les ports réseau via ssh, les comptes des utilisateurs contenus dans l’annuaire LDAP pourront être utilisés en plus des utilisateurs locaux.
# Configuration du port série ou aux pour une connexion avec un 
modem en utilisant les utilisateurs locaux 
aaa authentication serial LOCAL  
 
# Configuration du service ssh et du port console pour utiliser 
l’annuaire LDAP puis la base de compte LOCAL si échec de l’annuaire LDAP. 
aaa authentication ssh console LDAP_SRV_GRP LOCAL
¬
Le fait de configurer une deuxième méthode d’authentification permet seulement de l’utiliser lorsque la première méthode est indisponible. Ainsi, dans l’exemple précédent, l’authentification avec un compte d’un utilisateur local ne pourra se réaliser que si tous les serveurs LDAP sont indisponibles.