> ## Documentation Index
> Fetch the complete documentation index at: https://private-7c7dfe99-detect-table-modification.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Documentation de USER

# ALTER USER

Modifie les comptes d’utilisateur ClickHouse.

Syntaxe :

```sql theme={null}
ALTER USER [IF EXISTS] name1 [RENAME TO new_name |, name2 [,...]]
    [ON CLUSTER cluster_name]
    [{VALID UNTIL datetime | VALID FOR interval}]
    [NOT IDENTIFIED | RESET AUTHENTICATION METHODS TO NEW | {IDENTIFIED | ADD IDENTIFIED} {[WITH {plaintext_password | sha256_password | sha256_hash | double_sha1_password | double_sha1_hash}] BY {'password' | 'hash'}} | WITH NO_PASSWORD | {WITH ldap SERVER 'server_name'} | {WITH kerberos [REALM 'realm']} | {WITH ssl_certificate CN 'common_name' | SAN 'TYPE:subject_alt_name'} | {WITH ssh_key BY KEY 'public_key' TYPE 'ssh-rsa|...'} | {WITH http SERVER 'server_name' [SCHEME 'Basic']} [{VALID UNTIL datetime | VALID FOR interval}] [GRANTS (privilege ON object [,...])]
    [, {[{plaintext_password | sha256_password | sha256_hash | ...}] BY {'password' | 'hash'}} | {ldap SERVER 'server_name'} | {...} | ... [,...]]]
    [[ADD | DROP] HOST {LOCAL | NAME 'name' | REGEXP 'name_regexp' | IP 'address' | LIKE 'pattern'} [,...] | ANY | NONE]
    [IN access_storage_type]
    [DEFAULT ROLE role [,...] | ALL | ALL EXCEPT role [,...] ]
    [GRANTEES {user | role | ANY | NONE} [,...] [EXCEPT {user | role} [,...]]]
    [DROP ALL PROFILES]
    [DROP ALL SETTINGS]
    [DROP SETTINGS variable [,...] ]
    [DROP PROFILES 'profile_name' [,...] ]
    [ADD|MODIFY SETTINGS variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
    [SET variable [=value] [MIN [=] min_value] [MAX [=] max_value] [READONLY|WRITABLE|CONST|CHANGEABLE_IN_READONLY] [,...] ]
    [ADD PROFILES 'profile_name' [,...] ]
```

Pour utiliser `ALTER USER`, vous devez disposer du privilège [ALTER USER](/fr/reference/statements/grant#access-management).

`SET variable = value` est un alias de `MODIFY SETTING variable = value` : il modifie un seul paramètre sans toucher aux autres. Préférez-le (ou `MODIFY SETTING`) à la clause `SETTINGS` seule, qui remplace l’intégralité de la liste des paramètres et supprime également tous les profils hérités (parents).

<div id="grantees-clause">
  ## Clause GRANTEES
</div>

Spécifie les utilisateurs ou les rôles autorisés à recevoir des [privilèges](/fr/reference/statements/grant#privileges) de cet utilisateur, à condition que celui-ci dispose également de tous les droits d’accès requis accordés avec [GRANT OPTION](/fr/reference/statements/grant#granting-privilege-syntax). Options de la clause `GRANTEES` :

* `user` — Spécifie un utilisateur auquel cet utilisateur peut accorder des privilèges.
* `role` — Spécifie un rôle auquel cet utilisateur peut accorder des privilèges.
* `ANY` — Cet utilisateur peut accorder des privilèges à n’importe qui. Il s’agit du paramètre par défaut.
* `NONE` — Cet utilisateur ne peut accorder de privilèges à personne.

Vous pouvez exclure n’importe quel utilisateur ou rôle à l’aide de l’expression `EXCEPT`. Par exemple, `ALTER USER user1 GRANTEES ANY EXCEPT user2`. Cela signifie que si `user1` dispose de privilèges accordés avec `GRANT OPTION`, il pourra les accorder à n’importe qui, sauf à `user2`.

<div id="examples">
  ## Exemples
</div>

Définissez les rôles attribués comme rôles par défaut :

```sql theme={null}
ALTER USER user DEFAULT ROLE role1, role2
```

Si aucun rôle n’a été attribué au préalable à un utilisateur, ClickHouse lève une exception.

Définissez tous les rôles attribués comme rôles par défaut :

```sql theme={null}
ALTER USER user DEFAULT ROLE ALL
```

Si un rôle est attribué à un utilisateur ultérieurement, il deviendra automatiquement le rôle par défaut.

Définissez tous les rôles attribués par défaut, à l’exception de `role1` et `role2` :

```sql theme={null}
ALTER USER user DEFAULT ROLE ALL EXCEPT role1, role2
```

Permet à l’utilisateur du compte `john` d’accorder ses privilèges à l’utilisateur du compte `jack` :

```sql theme={null}
ALTER USER john GRANTEES jack;
```

Ajoute de nouvelles méthodes d’authentification à l’utilisateur tout en conservant celles existantes :

```sql theme={null}
ALTER USER user1 ADD IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'
```

Remarques :

1. Les anciennes versions de ClickHouse peuvent ne pas prendre en charge la syntaxe associée à plusieurs méthodes d’authentification. Par conséquent, si le serveur ClickHouse contient de tels utilisateurs et qu’il est rétrogradé vers une version qui ne prend pas cette syntaxe en charge, ces utilisateurs deviendront inutilisables et certaines opérations liées aux utilisateurs ne fonctionneront plus. Pour effectuer la rétrogradation correctement, il faut configurer tous les utilisateurs de sorte qu’ils n’aient qu’une seule méthode d’authentification avant la rétrogradation. Sinon, si le serveur a été rétrogradé sans suivre la procédure appropriée, les utilisateurs défectueux doivent être supprimés.
2. `no_password` ne peut pas coexister avec d’autres méthodes d’authentification pour des raisons de sécurité.
   Pour cette raison, il n’est pas possible d’`ADD` une méthode d’authentification `no_password`. La requête ci-dessous générera une erreur :

```sql theme={null}
ALTER USER user1 ADD IDENTIFIED WITH no_password
```

Si vous souhaitez supprimer les méthodes d’authentification d’un utilisateur et utiliser `no_password`, vous devez le préciser dans le formulaire de remplacement ci-dessous.

Réinitialise les méthodes d’authentification et ajoute celles spécifiées dans la requête (effet de IDENTIFIED en tête sans le mot-clé ADD) :

```sql theme={null}
ALTER USER user1 IDENTIFIED WITH plaintext_password by '1', bcrypt_password by '2', plaintext_password by '3'
```

Réinitialisez les méthodes d’authentification et ne conservez que la dernière ajoutée :

```sql theme={null}
ALTER USER user1 RESET AUTHENTICATION METHODS TO NEW
```

<div id="valid-until-clause">
  ## Clause VALID UNTIL
</div>

Permet de spécifier la date d'expiration et, éventuellement, l'heure d'une méthode d'authentification. Elle accepte une chaîne de caractères comme paramètre. Il est recommandé d'utiliser le format `YYYY-MM-DD [hh:mm:ss] [timezone]` pour les valeurs de date et d'heure. Par défaut, ce paramètre est égal à `'infinity'`. La plage d'échéances acceptées va de `1900-01-01 00:00:00 UTC` à `9999-12-31 09:59:59 UTC` — le dernier instant qui reste dans l'année 9999 dans tous les fuseaux horaires, afin que l'instant stocké ne soit jamais borné lors de son affichage. Une échéance passée signifie que les identifiants ont déjà expiré. Les échéances antérieures à `1970-01-01 00:00:01 UTC` ne sont acceptées que comme marqueur « déjà expiré » : elles sont normalisées vers le plus ancien instant expiré, soit une seconde après l'époque Unix (`1970-01-01 00:00:01 UTC`), de sorte que `SHOW CREATE USER` affiche cet instant au lieu de l'échéance indiquée. Les échéances à partir de cet instant sont stockées telles quelles.

Une échéance est stockée sous la forme d'un instant absolu, mais `SHOW CREATE USER` et [`system.users`](/fr/reference/system-tables/users) l'affichent dans le fuseau horaire du serveur ou de la session. Ainsi, un même instant stocké apparaît sous la forme d'heures locales différentes sur des serveurs configurés différemment : par exemple, l'instant expiré normalisé ci-dessus s'affiche sous la forme `1970-01-01 00:00:01` sur un serveur en `UTC` et `1970-01-01 14:00:01` sur un serveur en `Pacific/Kiritimati`. L'application de l'échéance utilise toujours l'instant stocké, et non son affichage.

La position de la clause détermine les méthodes d'authentification auxquelles elle s'applique :

* Avant la clause `IDENTIFIED` (ou lorsque la requête ne spécifie aucune méthode d'authentification) : l'échéance est définie au niveau de l'utilisateur et s'applique à toutes ses méthodes d'authentification.
* Après une méthode d'authentification : l'échéance s'applique uniquement à cette méthode. Une clause placée après toute la liste `IDENTIFIED` s'applique donc uniquement à la dernière méthode, les méthodes précédentes n'ayant pas d'expiration.

Exemples :

* `ALTER USER name1 VALID UNTIL '2025-01-01'`
* `ALTER USER name1 VALID UNTIL '2025-01-01 12:00:00 UTC'`
* `ALTER USER name1 VALID UNTIL 'infinity'`
* `ALTER USER name1 VALID UNTIL '2025-01-01' IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — l'échéance définie au niveau de l'utilisateur s'applique aux deux méthodes.
* `ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'` — l'échéance s'applique uniquement à la méthode `bcrypt_password` ; `plaintext_password` n'expire jamais.

<div id="valid-for-clause">
  ## Clause VALID FOR
</div>

La clause `VALID FOR` est un raccourci pratique pour `VALID UNTIL`. Au lieu d'une date et d'une heure absolues, elle accepte un [intervalle](/fr/reference/data-types/special-data-types/interval), et l'échéance est calculée en ajoutant cet intervalle à l'heure actuelle au moment de l'exécution de la requête. Le résultat est stocké sous la forme `VALID UNTIL`, de sorte que `SHOW CREATE USER` affiche toujours l'échéance absolue résolue. Elle suit les mêmes règles de positionnement que `VALID UNTIL` : avant `IDENTIFIED` (ou sans méthode d'authentification), elle définit une échéance au niveau de l'utilisateur qui s'applique à toutes les méthodes, tandis qu'après une méthode d'authentification, elle ne s'applique qu'à cette méthode. L'échéance est stockée et appliquée avec une précision à la seconde ; les intervalles inférieurs à la seconde (`NANOSECOND`, `MICROSECOND`, `MILLISECOND`) sont donc rejetés, et la plus petite unité acceptée est `SECOND`. Un intervalle négatif permet de marquer les identifiants comme déjà expirés ; si l'échéance obtenue est antérieure à `1970-01-01 00:00:01 UTC`, elle est normalisée à cet instant expiré minimal, que `SHOW CREATE USER` affiche ensuite dans le fuseau horaire du serveur ou de la session, comme décrit pour [`VALID UNTIL`](#valid-until-clause).

Exemples :

* `ALTER USER name1 VALID FOR INTERVAL 1 DAY`
* `ALTER USER name1 VALID FOR INTERVAL 3 MONTH`
* `ALTER USER name1 VALID FOR INTERVAL 30 DAY IDENTIFIED WITH plaintext_password BY 'password_1', bcrypt_password BY 'password_2'` — l'échéance au niveau de l'utilisateur s'applique aux deux méthodes.
* `ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY` — l'échéance s'applique uniquement à la méthode `bcrypt_password` ; `plaintext_password` n'expire jamais.

<div id="grants-clause">
  ## Clause GRANTS
</div>

Permet de limiter les droits d'accès disponibles pour une session authentifiée à l'aide d'une méthode d'authentification donnée. Consultez la [clause GRANTS de CREATE USER](/fr/reference/statements/create/user#grants-clause) pour plus de détails.

Associée à `ADD IDENTIFIED`, cette clause offre un moyen pratique de créer des jetons pour les applications : des identifiants supplémentaires assortis d'une date d'expiration et d'un ensemble limité de privilèges.

Exemple :

* `ALTER USER name1 ADD IDENTIFIED WITH plaintext_password BY 'app_token' VALID UNTIL '2026-12-31' GRANTS (SELECT ON db.table, INSERT ON db.table)`