Le produit SentinelOne est une solution de sécurisation EndPoint type « antivirus » mais de nouvelle génération basé entre autres sur l’analyse comportementale et qui se révèle être très efficace (notamment contre les crypto/ransomware).
https://www.cegedim-outsourcing.fr/partenaires/sentinelone/ (N’hésitez pas à demander une démo !)
Cette solution de type SaaS permet la création de différents comptes et profils d’administration (classique !). Ces comptes sont créés par défaut au sein de l’application « localement ».
Il est également possible de configurer un lien SAML afin d’utiliser une source d’identification déjà existante (Azure/365 par exemple)
L’article ci-dessous pourra vous aider à mettre en place ce lien mais également à aller un peu plus loin en liant des comptes/groupes d’utilisateurs Azure à des profils d’administration SentinelOne.
1. Lien SAML
Afin de pouvoir configurer le SSO (SAML 2.0) différentes opérations sont à effectuer sur les tenants Azure et SentinelOne (vive les aller-retour !)
a. SentinelOne (Aller)
- On se place au niveau « Account » ou d’un site (en fonction de l’étendue souhaitée pour le lien SAML)
- Aller sur Settings à Integrations à SSO
- On active le SSO
- On indique le ou les domaines qui seront liés (utilisés dans le login Azure/365)
- On copie les champs (qui seront à renseigner sur Azure) à l’aide du bouton prévu :
- Assertion Consumer Service URL
- SP Entity ID
b. Azure (Aller)
Dans la configuration Azure Active Directory :
- Aller sur « Application d’entreprise »
- Puis Cliquer sur « Nouvelle Application »
- Cliquer sur « Créer votre propre Application » à laquelle on donne un nom (« SentinelOne – Admin » par exemple) et on clique sur « créer ». On ne sélectionne pas l’Application proposée « SentinelOne App For Azure Active Directory »
- Une fois l’application créée, on peut la configurer. On va sur « Authentification Unique »
- On sélectionne « SAML »
- On modifie la configuration SAML
- On indique les informations suivantes à l’aide des deux URLS copiées dans le chapitre précédent :
- Identificateur = SP Entity ID (SentineOne)
- URL de réponse = Assertion Consumer Service URL (SentinelOne)
- On ne touche pas aux autres entrées
- On enregistre
- Toujours dans sur cet écran de configuration SAML, on télécharge le certificat (base 64)
- On copie les deux URLS suivantes (on va devoir les renseigner dans SentinelOne) :
- URL de connexion
- Identificateur Azure AD
- On va ensuite dans « Utilisateurs et groupes » et on ajoute le compte avec lequel on est en train de travailler (pour validation) :
c. SentinelOne (et retour)
Quand je vous disais qu’il y’aurait des aller-retour !
- De retour sur SentinelOne (toujours sur la configuration SSO), on renseigne les informations Azure copiées précédemment :
- IDP Redirect URL = URL de connexion (Azure)
- IssuerID = Identificateur Azure AD (Azure)
- On importe le certificat
Notes :
- Le « Default role » sera le rôle donné par défaut aux nouveaux utilisateurs qui s’authentifieront grâce à leur compte Azure et sans rôle attribué. Par sécurité, il vaut mieux laisser le rôle « Viewer » par défaut.
- On choisit ou non de créer automatiquement les nouveaux utilisateurs Azure. (« Auto Provisioning »).
- Rappel : Seuls les comptes (et groupes) déclarés dans l’application Azure/SentinelOne seront autorisés à s’authentifier
On teste en bas de page et si le message « SSO Test Passed » apparait, on peut sauvegarder.
Le lien SAML est configuré !
d. Azure – Attributs en revendications (et retour ?)
Afin d’être le plus précis possible il faut également définir les Attributs et revendications comme indiqué ci-dessous dans la configuration de l’application créée sous Azure :
On efface toutes les revendications créées par défaut sous « Revendications supplémentaires » et on indique la liste suivante :
- email àmail
- full_name àdisplayname
- unique user identifier àuserprincipalname
Exemple d’ajout :
2. Gestion des utilisateurs et profils d’administration
On va maintenant voir comment ajouter des comptes et éventuellement attribuer un rôle automatiquement
a. Ajout de comptes et attribution manuelle du rôle
Maintenant que le lien est créé on peut ajouter groupes et utilisateurs sur l’application « SentinelOne – Admin » créé sur Azure.
Par défaut, les comptes listés ici auront un rôle de « viewer »
Après leur première authentification, les comptes apparaissent dans la liste des administrateurs dans SentinelOne (et ont comme source SSO) Il est alors possible de changer son « Scope Access » afin de leur attribuer d’autres droits comme pour un utilisateur interne et de définir son scope (« Account » / « Site »)
Si le compte existait déjà (même adresse mail), il sera converti en tant que compte SSO
b. Attribution automatique des rôles (Value = role)
Il est possible d’attribuer automatiquement un rôle à la première connexion. Plusieurs limites cependant :
• Il est impossible de définir le scope, le compte sera lié à « l’Account » SentinelOne (il sera toujours possible de le modifier SentinelOne). Pour avoir cette granularité, il faut activé/configurer le SSO par scope au lieu (en plus ?) du niveau « Account ».
• L’attribution du rôle se fait à la première connexion, un changement de rôle dans Azure ne changera pas le rôle dans SentinelOne (il sera toujours possible de modifier le rôle dans SentinelOne). Idem pour un changement de groupe Azure.
• Le rôle « IR TEAM » ne peut être attribué (à cause de l’espace) …. Mais on pourra contourner ça si on va plus loin (Pas de spoil pour l’instant !)
Afin de pouvoir attribuer les rôles automatiquement plusieurs choses sont à préparer :
• Dans Azure, « Application d’entreprise », « SentinelOne – Admin », « Authentification Unique », « Attributs et revendication », on ajoute la revendication suivante :
– role = user.assignedroles
- Il faut ensuite définir la liste des rôles existant dans SentinelOne. Dans « Azure », « Inscription D’applications », « SentinelOne – Admin »
- Le rôle msiam_access doit rester.
- Le champ valeur correspond au nom du rôle dans SentinelOne et n’accepte pas d’espace ce qui explique l’impossibilité d’attribuer le rôle « IR TEAM »
- En cas d’erreur dans le champ valeur, l’utilisateur ne pourra pas se connecter car SentinelOne ne pourra pas lui attribuer de rôle.
Les rôles peuvent ensuite être attribuer sur les comptes/groupes autorisés (on retrouve alors les rôles définis au-dessus). On édite et on attribue un rôle.
c. Attribution automatique des rôles (Value = role_id)
….. Mais allons plus loin pour ceux qui utilisent les rôles personnalisés ! (Et corrigeons la limite pour « IR TEAM » par la même occasion)
Dans SentinelOne il est possible de créer des rôles personnalisés où l’on définit les droits que l’on souhaite lier à ce rôle. Problème : si l’on créé un rôle et qu’on le déclare dans les rôles d’applications sur Azure comme fait juste avant …. Ça ne marche pas. La « valeur » n’est pas reconnue et l’utilisateur ne peut pas s’authentifier … On repart alors sur la première possibilité : rôle « par défaut » et on applique ensuite à l’utilisateur le rôle dans SentinelOne … Si près du but …
Pourtant il y’a une possibilité ! Au lieu d’utiliser le nom des rôles, on va utiliser leur « ID ».
Problème : Cet ID n’apparait pas dans la console SentinelOne (pratique …) et la documentation SentinelOne n’aide pas beaucoup (re pratique …)
Donc on va utiliser l’API doc de SentinelOne mais surtout son « browser » pour trouver ces ID :
- On cherche le chapitre « RBAC » et on va sur « Get all Roles »
- On clique sur « Run On Console »
- On sélectionne « True » sur IncludeChildren
- Et on lance (on peut même filtrer sur le nom d’un rôle spécifique si besoin)
- On récupère l’id du (ou des) rôle qui nous intéresse :
Formidable on a nos ID ! Mais …. On en fait quoi ? On modifie nos revendications et nos rôles dans Azure !
- On retire la ligne « role » qu’on remplace par « role_id »
- Et on change les rôles. Au lieu d’utiliser le nom des rôles dans « valeur », on utilise l’ID (ici on voit sur test). Si l’on décide d’utiliser les ID il faudra changer tous les rôles même ceux par défaut.
3. Authentification admin
Pour s’authentifier avec son compte Azure, l’admin a deux possibilités :
- Sur la console SentinelOne en cliquant sur « Login With SSO » qui lui demandera alors son adresse. L’utilisateur arrivera alors sur sa console SentinelOne (s’il est déjà authentifié auprès d’Azure/365 sinon il devra d’abord fournir son mot de passe Azure). Une fois authentifié, On voit en haut à droite son nom et son rôle (j’ai bien mon rôle customise « test »).
- Depuis le portail 365 de l’admin, un nouveau lien doit être disponible
4. Sources
Un peu de lecture (Identifiants SentinelOne nécessaires pour accéder aux liens ci-dessous)
XXX : Pensez à changer le début pour correspondre à l’URL de votre Tenant SentinelOne
Article rédigé par Jean-Philippe