> For the complete documentation index, see [llms.txt](https://help.glpi-project.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.glpi-project.org/tutorials/fr/rules/authorizations_assignment_rules.md).

# Règles d'habilitations

Dans cet article, nous allons voir comment définir une **Règle** pour affecter automatiquement une habilitation à un utilisateur provenant d'une source LDAP.

{% hint style="info" %}
**Rappel**

* Une **Règle** est la combinaison de **Critères** et **Actions**, les actions seront déclenchées si les critères sont remplis.

* Une règle est définie par son opérateur logique : **ET** ou **OU**.
  * **`ET`** = Tous les critères doivent être remplis
  * **`OU`** = Un des critères doit être rempli

* Le moteur de règles pour les habilitations exécute TOUTES les règles. Faites donc attention à leur cohérence / ordre.
  {% endhint %}

* Pour définir une règle, allez dans le menu **`Administration`** > **`Règles`** > **`Règles d'affectation des habilitations à un utilisateur`**.

* Ajoutez une nouvelle règle en cliquant sur **`ajouter`**

## Critères

Il est nécessaire de définir un ou plusieurs critères. Dans notre cas, il faut cibler les critères LDAP.

GLPI permet de sélectionner plusieurs attributs LDAP, par exemple :

* **`MemberOf`** ;
* **`Email`** ;
* **`TelephoneNumber`** ;
* **`User ID`** ;
* **`Common Name`** ;
* etc.

Une fois votre critère sélectionné, vous devez définir **comment** GLPI doit prendre ce critère en compte en définissant un **opérateur**, par exemple :

* **`est`** ;
* **`contient`** ;
* **`finit par`** ;
* **`existe`** ;
* **`n'existe pas`** ;
* etc.

Prenons un cas concret. Je veux établir une règle pour mes utilisateurs membres d'un groupe contenant le terme SECURITY dans le nom.

* Mon critère sera donc **`MemberOf`** et l'action sera **`contient`**.
* J'entre ensuite la valeur de mon critère. Ici ce sera **`SECURITY`**.

![Alt text](https://1227510999-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqmRzI15ndDbFHGd5BnM4%2Fuploads%2Fgit-blob-d36b218d1a1a62b7b21d0fbb00b4e43b95a74558%2Fauthorizations_assignment_rules-2.png?alt=media)

## Actions

Rappel :

Une **habilitation** est la combinaison des trois concepts suivants :

* Utilisateur ;
* Profil ;
* Entité.

**Exemple** :

| Utilisateur | Profil     | Entité         |
| ----------- | ---------- | -------------- |
| John        | technicien | Infrastructure |

Transformé en règle d'habilitation :

* **`Critère`** = Utilisateur
* **`Actions`** = Entité + Profil

Nos critères étant définis, nous pouvons maintenant créer au moins deux actions nécessaires pour affecter un profil et une entité.

![Alt text](https://1227510999-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FqmRzI15ndDbFHGd5BnM4%2Fuploads%2Fgit-blob-3124286c8e2373059314255d74a36b778f73ddc8%2Fauthorizations_assignment_rules-3.png?alt=media)

GLPI permet aussi d'influer sur d'autres objets ou statuts utilisateur, par exemple :

* **`Actif`** (oui ou non) ;
* **`Récursif`** (oui ou non) ;
* **`Entité par défaut`** ;
* etc.

À ce stade, notre règle est fonctionnelle.

Les utilisateurs ayant **`SECURITY`** dans leur attribut **`MemberOf`** seront **`Technicien`** dans l'entité **`Infrastructure`**.

{% hint style="success" %}
**À savoir**

La règle sera appliquée lors de la connexion des utilisateurs ou à chaque synchronisation LDAP avec GLPI.
{% endhint %}

## Références

[Documentation GLPI "Profils utilisateurs"](https://glpi-user-documentation.readthedocs.io/fr/latest/modules/administration/profiles/profiles.html#administration)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.glpi-project.org/tutorials/fr/rules/authorizations_assignment_rules.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.