Foire aux questions

Modifier en ligne

Existe-t-il des informations supplémentaires concernant les paramètres de configuration pour la synchronisation des attributs?

Cette configuration est utilisée par Directory Sync pour générer des appels à l'API REST SCIM concernant les utilisateurs et les groupes, afin de mettre à jour le registre des locataires. La configuration est donc similaire à celle requise par ces API; la documentation de cette API peut donc vous aider à mieux la comprendre. https://docs.verify.ibm.com/verify/reference/createuser Voir les opérations POST, PATCH et PUT pour /v2.0/Users et /v2.0/Groups, par exemple.

Faut-il utiliser « urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm et unqualifiedUserName » ou simplement userName « avec @realm»?

urn:ietf:params:scim:schemas:extension:ibm:2.0:User.realm et unqualifiedUserName sont ignorés et supprimés du fichier de configuration d'exemple. Utilisez le userName avec @realm. Par exemple, si votre userName attribut userPrincipalName a pour valeur testuser@adomain.com et que le domaine de vérification est "verify-realm", définissez userName en suivant l'exemple ci-dessous.

{
  "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}}"}
    }
  }
}

Ce qui donne une userName valeur de "testuser@adomain.com@verify-realm" pour les valeurs de l'exemple précédent.

Remarque : si l'agent IBM® Verify Bridge est également utilisé avec le même registre sur site, le paramètre @realm « set on » userName doit correspondre à la source d'identité associée à l'agent Bridge.

La "ldap-base-dn" configuration n'est pas suffisamment précise lorsque l'on utilise l'option « Active Directory ». Quelles sont les autres solutions possibles?

Active Directory fournit un attribut opérationnel qui permet de faire correspondre des groupes spécifiques de DN, "msDs-parentdistname". Cet attribut peut être ajouté à la "ldap-search-filter" chaîne de configuration afin de limiter la correspondance des utilisateurs et des groupes à des zones spécifiques de l'annuaire. "msDs-parentdistname" concerne true tous les enfants directs du DN correspondant. Il ne s'agit pas d'une correspondance de sous-arbre, mais d'une correspondance à un seul niveau. Par exemple :

"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))"

Ce filtre ne sélectionne que les utilisateurs tels que cn=testuser, CN=SyncUsers, DC=adomain, DC=com, et les groupes tels que CN=testgroup, CN=SyncGroups, DC=adomain, DC=com.

Les utilisateurs faisant l'objet de la synchronisation peuvent-ils être identifiés uniquement par leur appartenance à un groupe?

"ldap-search-filter" Oui, mais n'utilisez jamais l'appartenance à un groupe comme condition. Lorsqu'une entrée utilisateur est créée pour la première fois dans Active Directory, aucune affiliation à un groupe n'est définie. Il est ajouté après l'étape de création. Ainsi, l'événement de création d'utilisateur est ignoré et perdu lorsqu'il est utilisé dans "ldap-search-filter". La solution consiste à utiliser l'entrée "user-sync-filter" de configuration. Voir l'objet JSON « The cloud-bridge ». memberOfCet élément de configuration ne se limite pas uniquement à. D'autres attributs utilisateur peuvent également être utilisés de la même manière.

L'attribut dans Verify SaaS est-il upn obligatoire?

Bien que l'attribut UPN (User Principal Name) ne soit pas techniquement obligatoire pour les intégrations Active Directory (AD), il est recommandé. Si une application ou une intégration, telle qu' Azure AD ou un fournisseur de services SAML ou OIDC spécifique, requiert explicitement l'attribut UPN, vous pouvez le configurer en tant qu'attribut personnalisé dans IBM Verify. Cela n'est nécessaire que si votre cas d'utilisation implique des assertions SSO ou des mappages d'attributs qui dépendent de l'UPN, en particulier lorsque :

Utilisation d'une page de connexion personnalisée qui redirige en fonction de l'UPN
Prise en charge de plusieurs domaines ou instances
Mise en œuvre de scénarios d'authentification unique (SSO)

Est-il recommandé de séparer les instances de Bridge (Utilisateurs, Administrateurs, Groupes)?

Non, cette séparation ne correspond pas à l'approche recommandée par les bonnes pratiques d' IBM. IBM Verify Bridge for Directory Sync est conçu pour gérer à la fois les utilisateurs et les groupes au sein d'une seule instance. Le modèle de déploiement standard prévoit un pont Directory Sync par source d'annuaire, avec des instances redondantes en veille pour assurer la haute disponibilité. Il n'est pas non plus recommandé de procéder à une séparation par fonction (utilisateurs, groupes), car cela accroît la complexité et peut entraîner des problèmes de synchronisation.

Pourquoi y a-t-il deux attributs « username » dans IBM Verify (preferred_username et username) et quelle est la différence?

IBM Verify utilise deux attributs distincts liés au nom d'utilisateur.

userName est l'identifiant principal utilisé pour l'authentification et les opérations système. Il sert d'identifiant unique principal pour l'utilisateur dans le système et doit être unique au sein d'un domaine. Il est utilisé pour les processus d'authentification, la recherche d'utilisateurs et les opérations système. Il est souvent associé à l'UPN userPrincipalName ( Active Directory ) et joue un rôle essentiel dans le fonctionnement du système.
preferred_username est un pseudonyme alternatif généralement utilisé à des fins d'affichage. Il sert principalement à des fins d'affichage dans l'interface utilisateur et permet d'afficher un nom plus convivial. Il peut apparaître dans les profils utilisateur et les éléments de l'interface utilisateur. Il n'est pas utilisé pour l'authentification ni pour les requêtes système et peut être modifié sans affecter le cœur du système d'authentification.

Quel type d'utilisateurs Directory Sync doit-il créer lorsqu'il est associé à un agent Bridge pour l'authentification par mot de passe : des utilisateurs fédérés ou des utilisateurs standard?

Les utilisateurs fédérés constituent la bonne option. Les IBM Verify utilisateurs fédérés prennent en charge les fonctionnalités d'authentification unique (SSO). Ils considèrent le registre sur site comme la source faisant autorité en matière d'informations d'identité. Ils s'authentifient auprès de la source d'identité externe (agent Bridge sur site) et leurs attributs sont synchronisés à partir du registre sur site.