SSSD-AD(5)

NAME
sssd-ad - Le fichier de configuration pour SSSD

DESCRIPTION

Cette page de manuel décrit la configuration du fournisseur AD pour sssd(8). Pour une référence détaillée sur la syntaxe, cf. la section “FORMAT DE FICHIER” de la page de manuel sssd.conf(5).

Le fournisseur AD est un moteur utilisé pour se connecter à un serveur Active Directory. Ce fournisseur exige que la machine soit jointe au domaine AD et qu'un fichier keytab soit disponible.

Le fournisseur AD prend en charge la connexion à Active Directory 2008 R2 ou ultérieures. Les versions antérieures peuvent fonctionner, mais ne sont pas supportées.

The AD provider is able to provide identity information and authentication for entities from trusted domains as well. Currently only trusted domains in the same forest are recognized.

Le fournisseur AD accepte les mêmes options utilisées par le fournisseur d'identité sssd-ldap(5) et le fournisseur d'authentification sssd-krb5(5) avec les quelques exceptions décrites ci-dessous.

However, it is neither necessary nor recommended to set these options. The AD provider can also be used as an access, chpass and sudo provider. No configuration of the access provider is required on the client side.

By default, the AD provider will map UID and GID values from the objectSID parameter in Active Directory. For details on this, see the “ID MAPPING” section below. If you want to disable ID mapping and instead rely on POSIX attributes defined in Active Directory, you should set

    ldap_id_mapping = False

In order to retrieve users and groups using POSIX attributes from trusted domains, the AD administrator must make sure that the POSIX attributes are replicated to the Global Catalog.

Users, groups and other entities served by SSSD are always treated as case-insensitive in the AD provider for compatibility with Active Directory's LDAP implementation.

OPTIONS DE CONFIGURATION

Se référer à la section “SECTIONS DE DOMAINE” de la page de manuel sssd.conf(5) pour les détails sur la configuration d'un domaine SSSD.

ad_domain (string)
    Spécifie le nom du domaine Active Directory. Ceci est facultatif. S'il n'est pas fourni, le nom de domaine de la configuration est utilisé.

    Pour un fonctionnement correct, cette option doit être le nom long du domaine Active Directory, spécifié en minuscules.

    Le nom de domaine court (aussi connu comme le nom NetBIOS ou nom plat) est autodétecté par SSSD.

ad_server, ad_backup_server (string)
    La liste par ordre de préférence séparée par des virgules des noms de systèmes des serveurs AD auquel SSSD doit se connecter. Pour plus d'informations sur la redondance de serveurs et le basculement, consulter la section “BASCULEMENT”. Ceci est optionnel si la découverte automatique est activée. Pour plus d'informations sur la découverte de services, se reporter à la section de “DÉCOUVERTE DE SERVICE”.

ad_hostname (string)
    Facultatif. Peut être défini sur les machines où le hostname(5) ne reflète pas le nom pleinenent qualifié utilisé dans le domaine Active Directory pour identifier ce système.

    Ce champ est utilisé pour déterminer le principal d'hôte utilisé dans un fichier keytab. Elle doit correspondre au nom du système pour lequel a été publié un fichier keytab.

ad_enable_dns_sites (booléen)
    Active les sites DNS - découverte de service basée sur l'emplacement

    Si configuré à true et que la découverte de service (cf. le paragraphe Découverte de service au bas de la page de manuel) est activée, SSSD tentera d'abord de découvrir le serveur Active Directory auquel se connecter en utilisant Active Directory Site Discovery, puis se repliera sur l'utilisation des enregistrements DNS SRV si aucun site AD n'est trouvé. La configuration SRV du DNS, incluant la découverte de domaine, est aussi utilisée pendant la découverte de site.

    Par défaut : true

ad_access_filter (boolean)
    This option specifies LDAP access control filter that the user must match in order to be allowed access. Please note that the “access_provider” option must be explicitly set to “ad” in order for this option to have an effect.

    The option also supports specifying different filters per domain or forest. This extended filter would consist of: “KEYWORD:NAME:FILTER”. The keyword can be either “DOM”, “FOREST” or missing.

    If the keyword equals to “DOM” or is missing, then “NAME” specifies the domain or subdomain the filter applies to. If the keyword equals to “FOREST”, then the filter equals to all domains from the forest specified by “NAME”.

    Multiple filters can be separated with the “?” character, similarly to how search bases work.

    The most specific match is always used. For example, if the option specified filter for a domain the user is a member of and a global filter, the per-domain filter would be applied. If there are more matches with the same specification, the first one is used.

    Exemples :

        # apply filter on domain called dom1 only:
        dom1:(memberOf=cn=admins,ou=groups,dc=dom1,dc=com)
        # apply filter on domain called dom2 only:
        DOM:dom2:(memberOf=cn=admins,ou=groups,dc=dom2,dc=com)
        # apply filter on forest called EXAMPLE.COM only:
        FOREST:EXAMPLE.COM:(memberOf=cn=admins,ou=groups,dc=example,dc=com)

    Par défaut : non défini

ad_enable_gc (booléen)
    By default, the SSSD connects to the Global Catalog first to retrieve users from trusted domains and uses the LDAP port to retrieve group memberships or as a fallback. Disabling this option makes the SSSD only connect to the LDAP port of the current AD server.

    Please note that disabling Global Catalog support does not disable retrieving users from trusted domains. The SSSD would connect to the LDAP port of trusted domains instead. However, Global Catalog must be used in order to resolve cross-domain group memberships.

    Par défaut : true

dyndns_update (booléen)
    Facultatif. Cette option indique à SSSD de mettre à jour automatiquement le serveur DNS intégré à IPA v2 avec l'adresse IP de ce client. La mise à jour est sécurisée avec GSS-TSIG. Ainsi, l'administrateur Active Directory a uniquement besoin d'activer les mises à jour sécurisées pour la zone DNS. L'adresse IP de la connexion LDAP AD est utilisée pour les mises à jour, à moins qu'elle ne soit spécifiée par l'utilisation de l'option “dyndns_iface”.

    NOTE : Sur les systèmes plus anciens (tels que RHEL 5), afin que ce comportement fonctionne de façon fiable, le domaine Kerberos par défaut doit être défini correctement dans /etc/krb5.conf

    Par défaut : true

dyndns_ttl (entier)
    Le TTL à appliquer à l'enregistrement du client DNS lors de sa mise à jour. Si dyndns_update a la valeur false, cela n'a aucun effet. Cela remplacera le TTL côté serveur s'il est défini par un administrateur.

    Par défaut : 3600 (secondes)

dyndns_iface (chaîne)
    Facultatif. Applicable seulement quand dyndns_update est vrai. Choisit l'interface dont l'adresse IP sera utilisée pour les mises à jour dynamiques du DNS.

    Par défaut : utilise l'adresse IP de la connexion LDAP AD

dyndns_refresh_interval (entier)
    Fréquence de mise à jour des DNS par le moteur en plus des mises à jour automatiques effectuées lorsque le moteur arrive en ligne. Cette option est facultative, et n'est applicable que lorsque l'option dyndns_update est configurée à true.

    Par défaut : 86400 (24 heures)

dyndns_update_ptr (booléen)
    Selon que l'enregistrement PTR doit être explicitement mis à jour lors de la mise à jour des enregistrements DNS du client. Applicable uniquement lorsque l'option dyndns_update est configurée à true.

    Par défaut : True

dyndns_force_tcp (booléen)
    Selon que l'utilitaire nsupdate doit utiliser TCP par défaut pour la communication avec le serveur DNS.

    Par défaut : False (laisser nsupdate choisir le protocole)

override_homedir (chaîne)
    Réécrit le répertoire personnel de l'utilisateur. Il est possible de fournir une valeur absolue ou un patron. Dans le cas d'un patron, les séquences suivantes sont substituées :.PP %u
        identifiant de connexion

    %U
        numéro d'UID

    %d
        nom de domaine

    %f
        nom d'utilisateur pleinement qualifié (utilisateur@domaine)

    %o
        Le répertoire utilisateur original provenant du fournisseur d'identité.

    %H
        The value of configure option homedir_substring.

    %%
        un « % » littéral

    Cette option peut aussi être définie pour chaque domaine.

    exemple :

        override_homedir = /home/%u

    Par défaut : Indéfini (SSSD utilisera la valeur récupérée de LDAP)

homedir_substring (chaîne)
    The value of this option will be used in the expansion of the override_homedir option if the template contains the format string %H. An LDAP directory entry can directly contain this template so that this option can be used to expand the home directory path for each client machine (or operating system). It can be set per-domain or globally in the [nss] section. A value specified in a domain section will override one set in the [nss] section.

    Par défaut : /home

krb5_use_enterprise_principal (booléen)
    Indique si le principal de l'utilisateur doit être traité comme un principal d'entreprise. Cf. la section 5 de la RFC 6806 pour plus de détails sur les principals d'entreprise.

    Par défaut : true

    Noter que cette valeur par défaut diffère du moteur de traitement Kerberos original.

BASCULEMENT

La fonctionnalité de basculement autorise le moteur à basculer automatiquement sur un serveur différent si le serveur actuel est défaillant.

  Syntaxe de basculement

La liste des serveurs est donnée sous forme de liste séparée par des virgules ; un nombre quelconque d'espaces est autorisé autour de la virgule. Les serveurs sont répertoriés par ordre de préférence. La liste peut contenir un nombre quelconque de serveurs.

Pour chaque option de configuration alors que le basculement est activé, il existe deux variantes : primary et backup. L'idée est que les serveurs dans la liste principale sont préférés et les serveurs de secours sont interrogés uniquement si aucun serveur primaire ne peut être atteint. Si un serveur de secours est sélectionné, un délai d'attente de 31 secondes est défini. Après ce délai d'attente, SSSD tentera périodiquement de se reconnecter à un des serveurs primaires. S'il réussit, il remplacera l'actuel serveur (de secours) actif.

  Mécanisme de basculement

Le mécanisme de basculement fait la distinction entre une machine et d'un service. Le moteur tente d'abord de résoudre le nom d'hôte d'un ordinateur donné ; en cas d'échec de cette tentative de résolution, la machine est considérée comme hors ligne. Aucune autre tentative n'est faite pour se connecter à cette machine pour tout autre service. Si la tentative de résolution réussit, le serveur principal tente de se connecter à un service sur cette machine. Si la tentative de connexion de service échoue, alors ce seul service est considéré comme hors ligne et le moteur passe automatiquement au service suivant. La machine est toujours considérée en ligne et peut toujours être considérée pour une tentative d'accès à un autre service.

Les tentatives de connexion ultérieures sont faites vers des machines ou des services marqués comme hors connexion après un délai spécifié ; ce délai est actuellement spécifié en dur à 30 secondes.

S'il n'y a plus aucune machine à essayer, le moteur dans son ensemble bascule dans le mode hors connexion et tente ensuite de se reconnecter toutes les 30 secondes.

DÉCOUVERTE DE SERVICE

La fonctionnalité de découverte de services permet aux moteurs de trouver automatiquement les serveurs appropriés auxquels se connecter à l'aide d'une requête DNS spéciale. Cette fonctionnalité n'est pas pris en charge pour sur les serveurs secondaires.

  Configuration

Si aucun serveur n'est spécifié, le moteur utilise automatiquement la découverte de services pour tenter de trouver un serveur. L'utilisateur peut aussi choisir d'utiliser des adresses de serveur et de découverte de services fixes en insérant un mot-clé spécial, “_srv_”, dans la liste des serveurs. L'ordre de préférence est maintenu. Cette fonctionnalité est utile si, par exemple, l'utilisateur préfère utiliser la découverte de services chaque fois que possible et se replier vers un serveur spécifique lorsqu'aucun serveur ne peut être découvert à l'aide du DNS.

  Le nom de domaine

Se reporter au paramètre “dns_discovery_domain” dans la page de manuel sssd.conf(5) pour plus de détails.

  Le protocole

Les requêtes spécifient généralement _tcp comme protocole. Les exceptions sont documentées dans les descriptions respectives des options.

  Voir aussi

Pour plus d'informations sur le mécanisme de découverte de services, se reporter à la RFC 2782.

CORRESPONDANCE D'IDENTIFIANTS

La fonctionnalité de correspondance d'ID permet à SSSD d'agir comme un client de Active Directory sans demander aux administrateurs d'étendre les attributs utilisateur pour prendre en charge les attributs POSIX pour les identifiants d'utilisateur et de groupe.

Remarque : Lorsque la mise en correspondance des ID est activée, les attributs uidNumber et gidNumber sont ignorés. Ceci afin d'éviter les risques de conflit entre les valeurs attribuées automatiquement et assignées manuellement. Si vous avez besoin d'utiliser des valeurs attribuées manuellement, TOUTES les valeurs doivent être assignées manuellement.

Please note that changing the ID mapping related configuration options will cause user and group IDs to change. At the moment, SSSD does not support changing IDs, so the SSSD database must be removed. Because cached passwords are also stored in the database, removing the database should only be performed while the authentication servers are reachable, otherwise users might get locked out. In order to cache the password, an authentication must be performed. It is not sufficient to use sss_cache(8) to remove the database, rather the process consists of:

    • Making sure the remote servers are reachable

    • Arrêter le service SSSD

    • Supprimer la base de donnée

    • Démarrer le service SSSD

Moreover, as the change of IDs might necessitate the adjustment of other system properties such as file and directory ownership, it's advisable to plan ahead and test the ID mapping configuration thoroughly.

  Algorithme de correspondance

Active Directory fournit un objectSID pour chaque objet d'utilisateur et de groupe dans l'annuaire. Cet objectSID peut être divisé en composants qui représentent l'identité de domaine Active Directory et l'identificateur relatif (RID) de l'objet utilisateur ou groupe.

L'algorithme de mise en correspondance des ID de SSSD tient un éventail d'uid disponibles et le divise en sections de même taille, appelées « tranches ». Chaque tranche représente l'espace disponible dans un domaine Active Directory.

Lorsqu'une entrée d'utilisateur ou de groupe pour un domaine particulier est rencontrée pour la première fois, SSSD alloue une des plages disponibles pour ce domaine. Afin de rendre cette affectation de plage reproductible sur les ordinateurs clients différents, l'algorithme de sélection de plage suivant est utilisé :

La chaîne du SID est passée par l'intermédiaire de l'algorithme murmurhash3 pour le convertir en une valeur de hachage de 32 bits. Nous prenons ensuite le modulo de cette valeur avec le nombre total des tranches disponibles pour prendre la tranche.

Remarque : Il est possible de rencontrer les collisions dans le hachage et le modulo en découlant. Dans ces situations, la tranche suivante disponible sera sélectionnée, mais il n'est pas possible de reproduire le même jeu exact des tranches sur d'autres machines (puisque l'ordre dans lequel elles sont rencontrées déterminera leur tranche). Dans ce cas, il est recommandé de passer à l'utilisation des attributs POSIX explicites dans Active Directory (en désactivant la correspondance d'ID) ou configurer un domaine par défaut afin de garantir qu'au moins un est toujours cohérent. Pour plus d'informations, voir “Configuration”.

  Configuration

Configuration minimale (dans la section “[domain/DOMAINNAME]”) :

    ldap_id_mapping = True
    ldap_schema = ad

La configuration par défaut active 10 000 tranches, chacune pouvant contenir jusqu'à 200 000 identifiants, démarrant à 10 001 et allant jusqu'à 2 000 100 000. Cela devrait être suffisant pour la plupart des déploiements.

Configuration avancée

    ldap_idmap_range_min (integer)
        Spécifie la limite inférieure de la plage d'ID POSIX à utiliser pour la mise en correspondance d'identifiants utilisateurs et groupes Active Directory.

        NOTE : Cette option est différente de “min_id” en ce sens que “min_id” agit comme filtre sur le résultat des requêtes vers ce domaine, alors que cette option contrôle les plages de correspondance d'ID. Il s'agit d'une distinction subtile, mais les bonnes pratiques conseillent d'avoir “min_id” inférieur ou égal à “ldap_idmap_range_min”

        Par défaut : 200000

    ldap_idmap_range_max (integer)
        Spécifie la limite supérieure de la plage d'ID POSIX à utiliser pour la mise en correspondance d'identifiants utilisateurs et groupes Active Directory.

        NOTE : Cette option est différente de “max_id” en ce sens que “max_id” agit comme filtre sur le résultat des requêtes vers ce domaine, alors que cette option contrôle les plages de correspondance d'ID. Il s'agit d'une distinction subtile, mais les bonnes pratiques conseillent d'avoir “max_id” supérieur ou égal à “ldap_idmap_range_max”

        Par défaut : 2000200000

    ldap_idmap_range_size (integer)
        Spécifie le nombre d'identifiants pour chaque tranche. Si la taille de la plage ne divise pas uniformément dans les valeurs minimale et maximale, des tranches complètes seront créées autant que possible.

        Par défaut : 200000

    ldap_idmap_default_domain_sid (chaîne)
        Spécifier le SID de domaine du domaine par défaut. Cela garantira que ce domaine est toujours affecté à la tranche zéro dans la carte d'ID, sans passer par l'algorithme murmurhash décrit ci-dessus.

        Par défaut : non défini

    ldap_idmap_default_domain (chaîne)
        Spécifier le nom de domaine par défaut.

        Par défaut : non défini

    ldap_idmap_autorid_compat (boolean)
        Modifie le comportement de l'algorithme de mise en correspondance des ID afin qu'il se comporte de manière identique à celui “idmap_autorid” de winbind.

        Lorsque cette option est configurée, les domaines seront alloués en commençant par la tranche zéro et augmentant de manière monotone pour chaque domaine supplémentaire.

        Remarque : Cet algorithme n'est pas déterministe (il dépend de l'ordre dans lequel utilisateurs et groupes sont invités). Si ce mode est nécessaire pour assurer la compatibilité avec les ordinateurs qui utilisent winbind, il est recommandé d'utiliser également l'option “ldap_idmap_default_domain_sid” pour garantir qu'au moins un domaine est systématiquement alloué à la tranche zéro.

        Par défaut : False

EXEMPLE

L'exemple suivant suppose que SSSD est correctement configuré et example.com est un des domaines de la section [sssd]. Ces exemples montrent seulement les options spécifiques au fournisseur AD.

    [domain/EXAMPLE]
    id_provider = ad
    auth_provider = ad
    access_provider = ad
    chpass_provider = ad
    ad_server = dc1.example.com
    ad_hostname = client.example.com
    ad_domain = example.com

NOTES

Le fournisseur de contrôle d'accès AD vérifie si le compte a expiré. Cela a le même effet que la configuration suivante du fournisseur LDAP :

    access_provider = ldap
    ldap_access_order = expire
    ldap_account_expire_policy = ad

Cependant, à moins que le fournisseur de contrôle d'accès “ad” soit explicitement configué, le fournisseur de contrôle d'accès par défaut est “permit”.

VOIR AUSSI

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-sudo(5), sss_cache(8), sss_debuglevel(8), sss_groupadd(8), sss_groupdel(8), sss_groupshow(8), sss_groupmod(8), sss_useradd(8), sss_userdel(8), sss_usermod(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8).

AUTHORS

Le projet SSSD - http://fedorahosted.org/sssd