Gérer les droits automatiques

• Type non défini

Ce document explique comment créer, tester, activer, désactiver et supprimer les règles qui attribuent automatiquement des droits lors de la création des objets sécurisés.

1. Principe

Une règle de droit automatique associe quatre informations :

Information	Rôle
Type d’objet	Famille d’objets sur laquelle la règle sera appliquée.
Permission	Action à autoriser ou à refuser.
Effet	Autoriser ou Refuser.
Expression du bénéficiaire	DistinguishedName fixe ou calculé à partir de variables.

Une règle active est utilisée lors de la création d’un objet par les parcours branchés au pipeline de droits automatiques. L’outil d’audit utilise les mêmes règles pour déterminer les droits attendus sur les objets existants.

2. Ouvrir la gestion des droits automatiques

1. Ouvrir /Security/Configuration avec le compte Cerebrate.
2. Repérer le type concerné.
3. Cliquer sur Droits automatiques.

La fenêtre contient :

• le testeur des variables de bénéficiaire ;
• la liste des règles existantes ;
• le formulaire de création d’une règle.

:::

3. Choisir l’effet

L’effet détermine le masque inscrit dans le droit produit :

Effet	Masque utilisé
Autoriser	Le Flag de la permission est ajouté à AuthorizedFlags.
Refuser	Le DeniedFlag est ajouté à DeniedFlags. Si la permission n’en définit pas, son Flag est utilisé.

Exemple avec Modify Map, dont le Flag vaut 5 et le DeniedFlag vaut 4 :

• une règle Autoriser produit AuthorizedFlags = 5 ;
• une règle Refuser produit DeniedFlags = 4.

Le refus n’est donc produit que si l’effet Refuser a été choisi. Lors du calcul d’accès, un refus applicable est prioritaire sur les autorisations.

4. Construire le bénéficiaire

L’expression doit produire un DistinguishedName valide. Elle peut être fixe ou contenir les variables suivantes :

Variable	Valeur utilisée
{CurrentUserDistinguishedName}	DistinguishedName de l’utilisateur qui provoque l’application du modèle ; dans le testeur, utilisateur connecté.
{SubDomainName}	Nom court du sous-domaine de sécurité de l’organisation courante.
{SubDomainDistinguishedName}	DistinguishedName complet du sous-domaine de l’organisation courante.

Exemple :

RN=Users, OU=Groups, {SubDomainDistinguishedName}

Pour une organisation dont le sous-domaine est OU=Paris, DC=example, DC=local, le résultat devient par exemple :

RN=Users, OU=Groups, OU=Paris, DC=example, DC=local

Les noms de variables sont reconnus sans tenir compte de leur casse. Toute variable inconnue est refusée lors de l’enregistrement.

5. Tester une expression

Le testeur utilise l’utilisateur connecté et l’organisation courante contrôlée par le serveur. Il affiche :

• l’organisation réellement utilisée ;
• la valeur des trois variables disponibles ;
• le DistinguishedName calculé ;
• un état vert si le bénéficiaire existe ;
• un avertissement si le DN est valide mais ne correspond à aucun objet de sécurité ;
• une erreur si le DN ou une variable est invalide.

La saisie dans le testeur ne modifie aucune règle.

6. Créer une règle

Le type doit être actif et posséder au moins une permission.

1. Sélectionner la permission.
2. Choisir l’effet Autoriser ou Refuser.
3. Saisir l’expression du bénéficiaire.
4. Vérifier le DN calculé sous le champ.
5. Cliquer sur Ajouter la règle.

La nouvelle règle est active dès sa création.

Le serveur refuse :

• une permission appartenant à un autre type ;
• un effet inconnu ;
• une expression vide ou supérieure à 2 048 caractères ;
• un DistinguishedName invalide ;
• une variable non prise en charge ;
• un doublon possédant le même type, la même permission, le même effet et la même expression.

7. Lire la liste des règles

Chaque ligne affiche :

Colonne	Signification
État	Règle active ou inactive.
Effet	Autorisation ou refus produit par la règle.
Permission	Permission dont le masque sera utilisé.
Bénéficiaire	Expression enregistrée et DN calculé dans l’organisation courante.
Actions	Activation, désactivation ou suppression.

Le nombre affiché dans la liste principale de /Security/Configuration compte toutes les règles enregistrées, y compris les règles inactives.

8. Désactiver ou supprimer une règle

Désactiver conserve la règle en base mais l’exclut du modèle chargé en mémoire. Elle pourra être réactivée ultérieurement.

Supprimer retire définitivement la règle après confirmation.

Dans les deux cas, les Right déjà produits sur les objets existants ne sont pas retirés automatiquement. La modification concerne les applications futures de la configuration et le résultat attendu par l’audit.

9. Appliquer les règles aux objets existants

Créer ou modifier une règle ne réécrit pas immédiatement tous les objets déjà présents.

Pour contrôler l’existant :

1. ouvrir /Security/Tools ;
2. accéder à l’audit des droits automatiques ;
3. filtrer par type et, si nécessaire, par organisation ;
4. examiner les états Complet, Incomplet ou Configuration incorrecte ;
5. utiliser Régulariser sur les objets incomplets.

La régularisation ajoute les droits automatiques attendus. Elle ne doit pas être interprétée comme un nettoyage général des droits supplémentaires déjà présents.

10. Exemple complet

Objectif : donner aux utilisateurs de l’organisation le droit de consulter les cartes nouvellement créées.

Paramètre	Valeur d’exemple
Type	Map
Permission	See Map
Effet	Autoriser
Bénéficiaire	RN=Users, OU=Groups, {SubDomainDistinguishedName}

Lors de l’application de la règle :

1. le serveur résout le sous-domaine de l’organisation de la carte ;
2. il construit le DistinguishedName du groupe Users ;
3. il retrouve ce groupe dans le domaine de sécurité ;
4. il crée ou complète le Right du groupe sur la carte ;
5. il ajoute le Flag de See Map à AuthorizedFlags.

Si le bénéficiaire n’existe pas, aucun droit ne peut être produit et l’audit signale un problème de configuration.

11. Règles à retenir

• Une règle active produit des droits ; elle n’est pas elle-même un droit.
• Autoriser utilise le Flag de la permission.
• Refuser utilise son DeniedFlag, ou son Flag à défaut.
• Le testeur utilise l’organisation courante sans modifier la configuration.
• Un bénéficiaire doit se résoudre vers un objet de sécurité existant pour produire un droit.
• Une nouvelle règle n’est pas rétroactive sur tous les objets existants.
• L’audit et la régularisation servent à traiter l’existant.
• Désactiver ou supprimer une règle ne retire pas automatiquement les droits déjà produits.