J'ai eu l'occasion ces derniers temps de travailler sur les deux produits phares de Sailpoint : Identity IQ (IIQ), la version "on premise" et IdentityNow (IDN), la version SaaS = Software As A Service.
L'éditeur semble mettre en avant la solution SaaS, mais même si celle-ci évolue rapidement (sans doute beaucoup plus vite que IdentityIQ), il y a encore quelques limitations.
Lorsqu'on réalise des études comparatives sur les annuaires LDAP, il est fréquent que le client demande d'établir des tests de performances, pour s'assurer que la solution en place sera capable de répondre à ses exigences.
Pour faire cela, j'utilisais souvent les outils authrate ou searchrate présents dans les binaires des annuaires de Forgerock ou Ping.
Si ces outils permettent de tester de manière unitaire, et avec un certain nombre de paramètres, ils manquait certaines possibilités / fonctionnalités :
La question qui se pose est : pourquoi mémoriser la date de dernière authentification ?
Le principal intérêt est de mettre en place un premier niveau de gouvernance : cette date permet d'identifier les comptes qui sont obsolètes dans l'annuaire, par exemple qui n'ont pas été utilisés pour s'authentifier depuis plusieurs mois.
Par défaut, cette information n'est pas disponible sur OpenLDAP (comme cela peut l'être dans un AD).
On peut analyser les logs systèmes (avec un niveau de log OpenLDAP à 256), mais ce n'est pas optimal.
A partir de la version 8, Red Hat et CentOS n'utilisent plus iptables mais firewalld.
Par défaut, celui-ci est activé. On peut voir la liste des ports ouverts :
firewall-cmd --list-all public (active) target: default icmp-block-inversion: no interfaces: enp1s0 sources: services: cockpit dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:
Les ports correspondant aux services listés sont ouverts :
Par défaut les nouveaux annuaires LDAP issus des sources OpenDS (tels que OpenDJ / DS chez Forgerock, mais aussi Ping Directory) renforcent les contrôles sur la syntaxe des attributs, le schéma, etc.
Ceci empêche par exemple d'avoir un objet avec de multiples classes structurelles non hiérarchiques (par exemple inetorgperson et country).
Par contre lorsqu'on importe des données d'un annuaire un peu moins strict (type Sun / Oracle DSEE), on se heurte souvent à des erreurs.
Par défaut, CentOS 7 (et RHEL) embarquent une version 5.4.16 de PHP, qui est datée et peut présenter des problèmes de sécurité.
On trouve sur le web pas mal de tutoriels qui expliquent comment passer en version 7.x, en ajoutant les dépôts REMI.
Dans mon cas, le serveur est dans un réseau d'entreprise qui dispose de ses propres serveurs de dépôts, et on ne peut donc pas accéder aux dépôts externes.
On a quand même pu passer en version 7.3, en récupérant les rpm puis en les installant.
Je décris ici les étapes à mener.
J'ai récemment migré mon serveur d'une version 18.04 LTS Ubuntu vers une version 20.04.
Lors de la migration, j'ai du passer sur la version snap de LXD, en version 4. Et suite à cette migration, les containers n'avaient plus d'adresse IP (que ce soit en V4 ou en V6).
Après de nombreuses recherches sur les forums LXD, j'ai trouvé la source du problème, en analysant les différents symptômes.
Sur le serveur, le service dnsmasq ne tournait pas. ce qu'on peut vérifier par :
Dans la série d'articles sur la migration de mon site https://www.vincentliefooghe.net/content/migration-drupal-7-vers-drupal-8 j'en viens maintenant à une partie qui m'a pris pas mal de temps et demandé un peu de développement.
Sur mon site en Drupal 7, j'avais utilisé le module Media_Wysiwyg et Colorbox, qui me permettaient d'insérer des images directement dans le texte.
On va installer les 2 modules suivants : migrate_upgrade, migrate_tools.
composer require drupal/migrate_upgrade composer require drupal/migrate_tools Puis activer les modules :
drush pm:enable migrate_upgrade migrate_tools -y Dans le fichier settings.php , il faut ajouter la définition de la base source.
Important : elle doit s'appeler migrate.
Par exemple :
Le processus de migration a été testé plusieurs fois. Je suis parti sur la base d'une sauvegarde du site Drupal 7 (fichiers + base de données).
J'ai installé ça dans un container LXC sur mon PC, ce qui me permettra de supprimer tout cela une fois la migration terminée.
Au final, on a donc un container sous Debian 10 avec PHP 7.3.11 et une base MariaDB 10.1.
L'idée est donc la suivante :