As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# AWS CloudHSM O usuário ou a política do SDK 5 do cliente contém valores inconsistentes
<a name="troubleshoot-sdk5-inconsistent-value"></a>

AWS CloudHSM não sincroniza automaticamente usuários ou políticas (como configurações de mTLS) entre HSMs em um cluster. A CLI do CloudHSM executa ao máximo a sincronização dessas operações em HSMs, mas ainda podem ocorrer inconsistências. Esta página descreve como identificar e resolver inconsistências tanto para usuários quanto para políticas. 

## Resolva valores inconsistentes do usuário
<a name="troubleshoot-sdk5-inconsistent-value-users"></a>

O `user list` comando no AWS CloudHSM Client SDK 5 retorna uma lista de todos os usuários e propriedades do usuário em seu cluster. Se alguma das propriedades de um usuário tiver o valor "**inconsistente** “, esse usuário não será sincronizado em seu cluster. Isso significa que o usuário existe com propriedades diferentes em HSMs diferentes no cluster. Com base em qual propriedade é inconsistente, diferentes etapas de reparo podem ser feitas. 

 A tabela a seguir inclui etapas para resolver inconsistências para um único usuário. Se um único usuário tiver várias inconsistências, resolva-as seguindo estas etapas de cima para baixo. Se houver vários usuários com inconsistências, analise essa lista para cada usuário, resolvendo totalmente as inconsistências desse usuário antes de passar para a próxima. 

**nota**  
Para executar essas etapas, o ideal é estar logado como administrador. Se sua conta de administrador não for consistente, siga estas etapas fazendo login como administrador e repetindo as etapas até que todas as propriedades estejam consistentes. Depois que sua conta de administrador estiver consistente, você poderá continuar usando esse administrador para sincronizar outros usuários no cluster.


| Propriedade inconsistente | Exemplo de saída da lista de usuários | Implicação  | Método de recuperação  | 
| --- | --- | --- | --- | 
| A “função” do usuário é “inconsistente” | <pre>{<br />"username": <br />"test_user",    <br />"role": "inconsistent",    <br />"locked": "false",    <br />"mfa": [],     <br />"cluster-coverage": "full"<br />}</pre> | Esse usuário está CryptoUser em alguns HSMs e é administrador em outros HSMs. Isso pode acontecer se dois SDKs tentarem criar o mesmo usuário, ao mesmo tempo, com funções diferentes. Você deve remover esse usuário e recriá-lo com a função desejada. |  1. Faça login como administrador.<br />2.  Exclua o usuário em todos os HSMs: <br />**user delete --username **<user's name>** --role admin** <br />**user delete --username **<user's name>** --role crypto-user** <br />3.  Crie o usuário com a função desejada: <br />**user create --username **<user's name>** --role **<desired role>**** <br />****   | 
| A “cobertura do cluster” do usuário é “inconsistente” | <pre>{<br />"username": "test_user",    <br />"role": "crypto-user",    <br />"locked": "false",    <br />"mfa": [],     <br />"cluster-coverage": "inconsistent"<br />}</pre> | Esse usuário existe em um subconjunto de HSMs no cluster. Isso pode acontecer se um **user create** for parcialmente bem-sucedido ou **user delete** parcialmente bem-sucedido. <br />Você deve concluir sua operação anterior, criando ou removendo esse usuário do seu cluster. | Se o usuário não deve existir, siga estas etapas:1. Faça login como administrador.<br />2. Execute este comando:  <br />**user delete --username**<user's name>** --role admin** <br />3. Execute o seguinte comando: <br />**user delete --username**<user's name>** --role crypto-user** <br />Se o usuário deve existir, siga estas etapas:1. Faça login como administrador.<br />2. Execute o seguinte comando: <br /> **user create --username **<user's name>** --role **<desired role>****   | 
| O parâmetro “bloqueado” do usuário é “inconsistente” ou “verdadeiro” | <pre>{<br />"username": <br />"test_user",    <br />"role": "crypto-user",    <br />"locked": inconsistent,    <br />"mfa": [],     <br />"cluster-coverage": "full"<br />}</pre> | Esse usuário está bloqueado em um subconjunto de HSMs.<br />Isso pode acontecer se um usuário usar a senha errada e se conectar somente a um subconjunto de HSMs no cluster.<br />Você deve alterar as credenciais do usuário para que sejam consistentes em todo o cluster. | Se o usuário tiver o MFA ativado, siga estas etapas:1. Faça login como administrador.<br />2. Execute o comando a seguir para desativar temporariamente o MFA: <br /> **user change-mfa token-sign --username **<user's name>** --role **<desired role>** --disable**  <br />3. Altere a senha do usuário para que ele possa fazer login em todos os HSMs: <br /> **user change-password --username **<user's name>** --role **<desired role>****  <br />Se o MFA estiver ativado para o usuário, siga estas etapas:1. Faça com que o usuário faça login e reative o MFA (isso exigirá que ele assine tokens e forneça sua chave pública em um arquivo PEM):  <br /> **user change-mfa token-sign --username **<user's name>** --role **<desired role>** —token <File>**   | 
| O status do MFA é “inconsistente” | <pre>{    <br />"username": "test_user",    <br />"role": "crypto-user",    <br />"locked": "false",    <br />"mfa": [<br />  {            <br />   "strategy": "token-sign",<br />   "status": "inconsistent"<br />   }    <br />],     <br />"cluster-coverage": "full"<br />}</pre> | Esse usuário tem diferentes sinalizadores de MFA em diferentes HSMs no cluster.<br />Isso pode acontecer se uma operação de MFA for concluída somente em um subconjunto de HSMs.<br />Você deve redefinir a senha do usuário e permitir que ele reative o MFA. | Se o usuário tiver o MFA ativado, siga estas etapas:1. Faça login como administrador.<br />2. Execute o comando a seguir para desativar temporariamente o MFA: <br /> **user change-mfa token-sign --username **<user's name>** --role **<desired role>** --disable**  <br />3.  Também será necessário alterar a senha do usuário para que ele possa fazer login em todos os HSMs: <br /> **user change-password --username **<user's name>** --role **<desired role>****  <br />Se o MFA estiver ativado para o usuário, siga estas etapas:1. Faça com que o usuário faça login e reative o MFA (isso exigirá que ele assine tokens e forneça sua chave pública em um arquivo PEM):  <br /> **user change-mfa token-sign --username **<user's name>** --role **<desired role>** —token <File>**   | 

## Resolva valores inconsistentes da política de mTLS
<a name="troubleshoot-sdk5-inconsistent-value-policies"></a>

Assim como os usuários, as políticas de mTLS (âncoras de confiança e nível de fiscalização) não são sincronizadas automaticamente entre os HSMs. A CLI do CloudHSM executa a sincronização com os melhores esforços quando você executa comandos mTLS, mas ainda podem ocorrer inconsistências. Você pode verificar o status de sincronização da sua configuração mTLS usando os seguintes comandos. 

### Verifique a sincronização da âncora de confiança do mTLS
<a name="troubleshoot-sdk5-inconsistent-mtls-trust-anchors"></a>

Execute o **cluster mtls list-trust-anchors** comando para verificar o status de sincronização de suas âncoras de confiança. Na saída, cada âncora de confiança tem um `cluster-coverage` campo. Se o valor for "**full** “, a âncora de confiança estará presente em todos os HSMs. Se o valor não for “completo”, a âncora de confiança não será sincronizada em todos os HSMs no cluster. 

```
{
  "error_code": 0,
  "data": {
    "trust_anchors": [
      {
        "certificate-reference": "0x01",
        "certificate": "{{<PEM Encoded Certificate>}}",
        "cluster-coverage": "full"
      }
    ]
  }
}
```

Se uma âncora confiável tiver uma cobertura de cluster inconsistente, execute novamente o comando de registro ou cancelamento de registro para concluir a operação:
+ Para finalizar o registro de uma âncora de confiança que está ausente em alguns HSMs:

  **cluster mtls register-trust-anchor --path **<path-to-certificate>****
+ Para concluir o cancelamento do registro de uma âncora de confiança que deve ser removida:

  **cluster mtls deregister-trust-anchor --certificate-reference **<certificate-reference>****

Para obter mais informações sobre como configurar o mTLS, consulte [Configurar o TLS mútuo entre cliente e. AWS CloudHSM](getting-started-setup-mtls.md)