Perguntas mais frequentes

Editar online

Existem mais detalhes sobre as entradas de configuração para a sincronização de atributos?
Essa configuração é utilizada pelo Directory Sync para criar chamadas da API REST SCIM de usuários e grupos, a fim de atualizar o registro do locatário. A configuração é, portanto, semelhante à entrada dessas APIs, de modo que a documentação desta API pode ajudar na compreensão. https://docs.verify.ibm.com/verify/reference/createuser Veja as operações POST, PATCH e PUT para /v2.0/Users e /v2.0/Groups, por exemplo.
Qual usar, urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm e unqualifiedUserName ou apenas userName com @realm?
urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm e unqualifiedUserName são ignorados e removidos do arquivo de configuração de exemplo. Use o userName com @realm. Por exemplo, se o seu userName for o atributo userPrincipalName com o valor testuser@adomain.com e o domínio de verificação for "verify-realm", defina o userName seguindo o exemplo a seguir.
{
  "ldap": "userPrincipalName",
  "tweaks": {
    "append": "@verify-realm"
  }
  "new-attr":{
    "scim":{"userName":"{{value}}"}
  },
  "mod-attr":{
    "scim":{
      "add":{"op":"add","path":"userName","value":"{{value}}"},
      "remove":{"op":"remove","path":"userName"},
      "replace":{"op":"replace","path":"userName","value":"{{value}}"}
    }
  }
}
O que faz com que userName seja definido como "testuser@adomain.com@verify-realm" para os valores do exemplo anterior.
Observação: Se o IBM® Verify agente Bridge também estiver sendo usado com o mesmo registro local, a @realm configuração userName deve corresponder à fonte de identidade associada ao agente Bridge.
A "ldap-base-dn" configuração não é suficientemente detalhada quando se utiliza o ` Active Directory `. Que soluções alternativas existem?
Active Directory fornece um atributo operacional que permite a correspondência de grupos específicos de DNs, "msDs-parentdistname". Esse atributo pode ser adicionado à cadeia "ldap-search-filter" de configuração para restringir a correspondência de usuários e grupos a áreas específicas do diretório. "msDs-parentdistname" refere-se true a todos os filhos diretos do DN correspondente. Essa correspondência não é uma correspondência de subárvore, mas sim uma correspondência de um único nível. Por exemplo,
"ldap-base-dn": "DC=adomain,DC=com",
"ldap-search-filter":"(|(&(objectClass=user)(msDs-parentdistname=CN=SyncUsers,DC=adomain,DC=com))(&(objectClass=group)(msDs-
parentdistname=CN=SyncGroups,DC=adomain,DC=com))"
Este filtro seleciona apenas usuários como cn=testuser, CN=SyncUsers, DC=adomain, DC=com, e grupos como CN=testgroup, CN=SyncGroups, DC=adomain, DC=com.
Os usuários que estão sendo sincronizados podem ser identificados apenas pela sua participação em um grupo?
Sim, mas nunca use a pertença a um grupo como condição "ldap-search-filter" . Quando um registro de usuário é criado inicialmente no ` Active Directory `, ele não possui nenhuma associação a grupos. Isso é adicionado após a etapa de criação. Assim, o evento de criação do usuário é ignorado e perdido quando é utilizado em "ldap-search-filter". A solução é usar a "user-sync-filter" entrada de configuração. Consulte o objeto JSON da Cloud-Bridge. memberOfEste item de configuração não se limita apenas a. Outros atributos de usuário também podem ser usados de maneira semelhante.
O upn atributo em VerifySaaS é obrigatório?
Embora o atributo UPN (User Principal Name) não seja tecnicamente obrigatório para integrações com o Active Directory (AD), ele é recomendado. Se um aplicativo ou integração, como o AD d Azure, um provedor de serviços específico d SAML ou OIDC, exigir explicitamente o atributo UPN, você pode configurá-lo como um atributo personalizado dentro de IBM Verify. Isso só é necessário quando o seu caso de uso envolve asserções de SSO ou mapeamentos de atributos que dependem do UPN, especialmente quando:
  • Utilização de uma página de login personalizada que redireciona com base no UPN
  • Suporte a vários domínios ou reinos
  • Implementação de cenários de SSO
É recomendável separar as instâncias do Bridge (Usuários, Administradores, Grupos)?
Não, essa separação não é a abordagem recomendada de acordo com as melhores práticas d IBM. IBM Verify Bridge for Directory Sync foi projetado para gerenciar usuários e grupos em uma única instância. O modelo de implantação padrão consiste em uma ponte do Directory Sync por fonte de diretório, com instâncias redundantes em espera para garantir alta disponibilidade. Além disso, não é recomendável separar por função (usuários, grupos), pois isso aumenta a complexidade e pode causar problemas de sincronização.
Por que existem dois atributos de nome de usuário em IBM Verify (preferred_username e username) e qual é a diferença?
IBM Verify utiliza dois atributos distintos relacionados ao nome de usuário.
  • userName é o principal identificador utilizado para autenticação e operações do sistema. Ele serve como o principal identificador exclusivo do usuário no sistema e deve ser único dentro de um domínio. É utilizado em processos de autenticação, consultas de usuários e operações do sistema. Geralmente é mapeado para o userPrincipalName (UPN) de Active Directory e é essencial para o funcionamento do sistema.
  • preferred_username é um nome de usuário alternativo que geralmente é usado para fins de exibição. É utilizado principalmente para fins de exibição na interface do usuário e oferece um nome de exibição mais intuitivo. Pode ser exibido nos perfis de usuário e nos elementos da interface do usuário. Ele não é utilizado para autenticação ou consultas ao sistema e pode ser alterado sem afetar a autenticação principal.
Qual tipo de usuário é mais adequado para o Directory Sync criar quando combinado com um agente Bridge para autenticação por senha: usuários federados ou usuários comuns?
Os usuários federados são a opção correta. Os usuários federados oferecem IBM Verify suporte a recursos de SSO. Eles mantêm o registro local como a fonte oficial de informações de identidade. Eles realizam a autenticação por meio da fonte de identidade externa (agente Bridge local) e seus atributos são sincronizados a partir do registro local.