> ## 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.

> Documentación de USER

# ALTER USER

Modifica las cuentas de usuario de ClickHouse.

Sintaxis:

```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' [,...] ]
```

Para usar `ALTER USER`, debe contar con el privilegio [ALTER USER](/es/reference/statements/grant#access-management).

`SET variable = value` es un alias de `MODIFY SETTING variable = value`: modifica una sola SETTING sin afectar el resto. Se prefiere (o `MODIFY SETTING`) a la cláusula `SETTINGS` simple, que reemplaza toda la lista de SETTINGS y además elimina todos los perfiles heredados (padre).

<div id="grantees-clause">
  ## Cláusula GRANTEES
</div>

Especifica los usuarios o roles que pueden recibir [privilegios](/es/reference/statements/grant#privileges) de este usuario, siempre que este usuario también tenga todos los privilegios de acceso necesarios concedidos con [GRANT OPTION](/es/reference/statements/grant#granting-privilege-syntax). Opciones de la cláusula `GRANTEES`:

* `user` — Especifica un usuario al que este usuario puede conceder privilegios.
* `role` — Especifica un rol al que este usuario puede conceder privilegios.
* `ANY` — Este usuario puede conceder privilegios a cualquier usuario o rol. Es la configuración predeterminada.
* `NONE` — Este usuario no puede conceder privilegios a ningún usuario ni rol.

Puede excluir cualquier usuario o rol mediante la expresión `EXCEPT`. Por ejemplo, `ALTER USER user1 GRANTEES ANY EXCEPT user2`. Esto significa que, si a `user1` se le han concedido algunos privilegios con `GRANT OPTION`, podrá conceder esos privilegios a cualquiera excepto a `user2`.

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

Establece los roles asignados como predeterminados:

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

Si no se han asignado roles previamente a un usuario, ClickHouse lanza una excepción.

Establezca como predeterminados todos los roles asignados:

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

Si en el futuro se asigna un rol a un usuario, pasará a ser el predeterminado automáticamente.

Establezca como predeterminados todos los roles asignados, excepto `role1` y `role2`:

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

Permite que el usuario `john` conceda sus privilegios al usuario `jack`:

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

Añade nuevos métodos de autenticación al usuario, conservando los existentes:

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

Notas:

1. Es posible que las versiones anteriores de ClickHouse no admitan la sintaxis de múltiples métodos de autenticación. Por lo tanto, si el servidor de ClickHouse contiene este tipo de usuarios y se degrada a una versión que no los admite, dichos usuarios quedarán inutilizables y algunas operaciones relacionadas con los usuarios dejarán de funcionar. Para llevar a cabo la degradación sin problemas, es necesario configurar todos los usuarios para que tengan un único método de autenticación antes de hacerlo. Como alternativa, si el servidor se degradó sin seguir el procedimiento adecuado, se deben eliminar los usuarios defectuosos.
2. `no_password` no puede coexistir con otros métodos de autenticación por motivos de seguridad.
   Por ello, no es posible `ADD` un método de autenticación `no_password`. La consulta siguiente generará un error:

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

Si quiere eliminar los métodos de autenticación de un usuario y utilizar `no_password`, debe especificarlo en la siguiente forma de sustitución.

Restablece los métodos de autenticación y añade los especificados en la consulta (efecto de un IDENTIFIED inicial sin la palabra clave ADD):

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

Restablece los métodos de autenticación y conserva el último añadido:

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

<div id="valid-until-clause">
  ## Cláusula VALID UNTIL
</div>

Permite especificar la fecha de expiración y, opcionalmente, la hora de un método de autenticación. Acepta una cadena como parámetro. Se recomienda usar el formato `YYYY-MM-DD [hh:mm:ss] [timezone]` para valores DateTime. De forma predeterminada, este parámetro es `'infinity'`. El intervalo de fechas límite aceptado abarca desde `1900-01-01 00:00:00 UTC` hasta `9999-12-31 09:59:59 UTC` —el último instante que se mantiene dentro del año 9999 en todas las zonas horarias—, de modo que el instante almacenado nunca se limita al representarse. Una fecha límite en el pasado significa que las credenciales ya han expirado. Las fechas límite anteriores a `1970-01-01 00:00:01 UTC` se aceptan únicamente como marcador de «ya expirado»: se canonicalizan al instante expirado más temprano, un segundo después de la época Unix (`1970-01-01 00:00:01 UTC`), por lo que `SHOW CREATE USER` muestra ese instante en lugar de la fecha límite indicada. Las fechas límite a partir de ese instante se almacenan exactamente.

Una fecha límite se almacena como un instante absoluto, pero `SHOW CREATE USER` y [`system.users`](/es/reference/system-tables/users) la muestran en la zona horaria del servidor o de la sesión, por lo que el mismo instante almacenado aparece como texto de hora local diferente en servidores configurados de forma distinta: por ejemplo, el instante expirado canonicalizado anterior se muestra como `1970-01-01 00:00:01` en un servidor con `UTC` y como `1970-01-01 14:00:01` en un servidor con `Pacific/Kiritimati`. La aplicación siempre usa el instante almacenado, no su representación.

La posición de la cláusula determina a qué métodos de autenticación se aplica:

* Antes de la cláusula `IDENTIFIED` (o cuando la consulta no especifica ningún método de autenticación): la fecha límite se aplica a nivel de usuario y afecta a todos los métodos de autenticación del usuario.
* Después de un método de autenticación: la fecha límite se aplica solo a ese método. Por tanto, una cláusula escrita después de toda la lista `IDENTIFIED` se asocia únicamente al último método, dejando los métodos anteriores sin expiración.

Ejemplos:

* `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'` — la fecha límite a nivel de usuario se aplica a ambos métodos.
* `ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID UNTIL '2025-01-01'` — la fecha límite se aplica solo al método `bcrypt_password`; `plaintext_password` nunca expira.

<div id="valid-for-clause">
  ## Cláusula VALID FOR
</div>

La cláusula `VALID FOR` es una forma abreviada de `VALID UNTIL`. En lugar de una fecha y hora absolutas, acepta un [intervalo](/es/reference/data-types/special-data-types/interval), y la fecha límite de expiración se calcula sumando ese intervalo a la hora actual en el momento de ejecutar la consulta. El resultado se almacena en formato `VALID UNTIL`, por lo que `SHOW CREATE USER` siempre muestra la fecha límite absoluta resultante. Sigue las mismas reglas de posición que `VALID UNTIL`: antes de `IDENTIFIED` (o sin ningún método de autenticación), es una fecha límite a nivel de usuario que se aplica a todos los métodos; después de un método de autenticación, se aplica únicamente a ese método. La fecha límite se almacena y se aplica con precisión de segundos, por lo que se rechazan los intervalos inferiores a un segundo (`NANOSECOND`, `MICROSECOND`, `MILLISECOND`); la unidad mínima aceptada es `SECOND`. Se acepta un intervalo negativo para marcar las credenciales como ya expiradas; si la fecha límite resultante es anterior a `1970-01-01 00:00:01 UTC`, se canonicaliza a ese primer instante expirado, que es el que `SHOW CREATE USER` muestra posteriormente, representado en la zona horaria del servidor o de la sesión, como se describe para [`VALID UNTIL`](#valid-until-clause).

Ejemplos:

* `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'` — la fecha límite a nivel de usuario se aplica a ambos métodos.
* `ALTER USER name1 IDENTIFIED WITH plaintext_password BY 'no_expiration', bcrypt_password BY 'expiration_set' VALID FOR INTERVAL 30 DAY` — la fecha límite se aplica únicamente al método `bcrypt_password`; `plaintext_password` nunca expira.

<div id="grants-clause">
  ## Cláusula GRANTS
</div>

Permite limitar los derechos de acceso disponibles para una sesión autenticada mediante un método de autenticación específico. Consulta la [cláusula GRANTS de CREATE USER](/es/reference/statements/create/user#grants-clause) para obtener más información.

Junto con `ADD IDENTIFIED`, proporciona una forma práctica de crear tokens para aplicaciones: una credencial adicional con fecha de expiración y un conjunto limitado de privilegios.

Ejemplo:

* `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)`