Manuel d’administration du serveur ownCloud 9.1

Authentification utilisateur avec LDAP¶

ownCloud fournit une application LDAP permettant aux utilisateurs LDAP (y compris Active Directory) d’apparaître dans le listes d’utilisateurs d’ownCloud. Ces utilisateurs pourront s’authentifier sur ownCloud avec leurs identifiants LDAP, vous n’avez donc pas à créer de comptes ownCloud séparés pour ceux-ci. Vous pourrez gérer leur appartenance aux groupes, leur quota et leur permissions de partage comme n’importe quel autre utilisateur d’ownCloud.

Note

Le module PHP LDAP est requis. Il est fourni par le paquet php5-ldap sur Debian/Ubuntu, et php-ldap sur CentOS/Red Hat/Fedora. PHP 5.4+ est nécessaire pour ownCloud 8.1.

L’application LDAP gère :

les groupes LDAP ;
le partage de fichiers avec les utilisateurs et groupes d’ownCloud ;
l’accès via WebDAV et les clients de synchronisation ownCloud ;
le versionnement, le stockage externe et les autres fonctionnalités d’ownCloud ;
la connexion transparente à Active Directory, sans configuration supplémentaire ;
les groupes primaires dans Active Directory ;
la détection automatique des attributs LDAP tels que la base DN, l’adresse électronique et le numéro de port du serveur LDAP ;
l’accès en lecture seule sur votre serveur LDAP (la modification ou la suppression des utilisateurs sur votre serveur LDAP n’est pas gérée).

Avertissement

L’application LDAP n’est pas compatible avec l’application User backend using remote HTTP servers. Vous ne pouvez pas utiliser les deux en même temps.

Note

Une configuration correcte et non bloquante de SELinux est nécessaire pour que le service LDAP fonctionne. Veuillez consulter Configuration SELinux.

Configuration¶

Vous devez tout d’abord activer l’application LDAP user and group backend sur la page Applications d’ownCloud. Puis, rendez-vous sur la page d’administration pour la configurer.

Le panneau de configuration LDAP dispose de quatre onglets. Le premier onglet (« Serveur ») doit être correctement configuré pour pouvoir accéder aux autres onglets. Un indicateur vert apparaît quand la configuration est correcte. Passez le curseur de la souris au-dessus des champs du formulaire pour voir apparaître des info-bulles d’aide.

Onglet serveur¶

Commencez par l’onglet « Serveur ». Vous pouvez configurer plusieurs serveurs. Vous devez au minimum fournir le nom d’hôte du serveur LDAP. Si votre serveur nécessite une authentification, saisissez les identifiants sur cet onglet. ownCloud essaiera de détecter automatiquement le numéro de port du serveur et la base DN. La base DN et le numéro de port sont obligatoires, donc si ownCloud ne peut les détecter, vous devrez les saisir manuellement.

Configuration du serveur :

Configurez un ou plusieurs serveurs LDAP. Cliquez sur le bouton Suppression de la configuration pour supprimer la configuration en cours.

Hôte :

Le nom d’hôte ou l’adresse IP du serveur LDAP. Cela peut être aussi une URI ldaps:// . Si vous saisissez le numéro de port, la détection du serveur sera plus rapide.

Exemples :

annuaire.ma-societe.com
ldaps://annuaire.ma-societe.com
annuaire.ma-societe.com:9876

Port :

Le port sur lequel se connecter au serveur LDAP. Le champ est désactivé au commencement d’une nouvelle configuration. Si le serveur LDAP fonctionne sur un port standard, le port sera détecté automatiquement. Si vous utilisez un port non standard, ownCloud essaiera de le détecter. S’il échoue, vous devrez le saisir manuellement.

Exemple:

389

DN utilisateur :

Le DN de l’utilisateur qui a les droits de faire des recherches sur l’annuaire LDAP. Laissez ceci vide pour l’accès anonyme. Nous recommandons d’avoir un utilisateur spécial pour faire ces recherches.

Exemple :

uid=owncloudsystemuser,cn=sysusers,dc=ma-societe,dc=com

Mot de passe :

Le mot de passe de l’utilisateur ci-dessus. Laissez vide pour l’accès anonyme.

Base DN :

Le DN de la racine du serveur LDAP, à partir de laquelle les utilisateurs et les groupes seront recherchés. Vous pouvez saisir plusieurs racines, une par ligne. (Les DN des racines des utilisateurs et des groupes peuvent être définis dans l’onglet « Avancé »). Ce champ est obligatoire. ownCloud essaie de déterminer la base DN en fonction du DN utilisateur fourni ou à partir de l’hôte. Vous devrez le saisir manuellement si ownCloud n’arrive pas à la détecter.

Exemple :

dc=ma-societe,dc=com

Filtre utilisateur¶

Utilisez ceci pour contrôler quels utilisateurs LDAP seront affichés comme utilisateurs ownCloud sur votre serveur ownCloud. Les utilisateurs LDAP qui ont un accès mais ne sont pas listés comme utilisateurs (s’il en existe) seront des utilisateurs cachés. Vous pouvez passer outre les champs du formulaire et saisir le flitre directement.

seulement ces classes d’objets :

ownCloud déterminera les classes d’objets typiquement disponibles pour les objets utilisateurs dans votre annuaire LDAP. ownCloud sélectionnera automatiquement la classe d’objet renvoyant le plus grand nombre d’utilisateurs. Vous pouvez saisir plusieurs classes d’objets.

seulement de ces groupes :

Si votre serveur LDAP gère member-of-overlay dans les filtres LDAP, vous pouvez définir que seuls les utilisateurs d’un ou plusieurs groupes sont autorisés à apparaître dans les listes d’utilisateurs d’ownCloud. Par défaut, aucune valeur n’est sélectionnée. Vous pouvez sélectionner plusieurs groupes.

Si votre serveur LDAP ne gère pas member-of-overlay dans les filtres LDAP, le champ est désactivé. Veuillez contacter votre administrateur LDAP.

Éditer le filtre raw à la place :

Cliquer sur ce lien permet de saisir le filtre directement. Exemple:

(&(objectClass=inetOrgPerson)(memberOf=cn=owncloudusers,ou=groups,
dc=ma-societe,dc=com))

x utilisateurs trouvés :

Ceci est un indicateur fournissant le nombre approximatif d’utilisateurs qui seront listés dans ownCloud. Ce nombre se met à jour automatiquement après chaque modification du filtre.

Filtre de login¶

Les paramètres du filtre de login déterminent quels utilisateurs LDAP peuvent se connecter à ownCloud et quels attributs correspondront au compte de connexion (par exemple le nom d’utilisateur LDAP/AD, l’adresse électronique). Vous pouvez sélectionner plusieurs attributs. Vous pouvez également passer outre les champs du formulaire et saisir le filtre directement si vous le voulez.

Vous pouvez passer outre les paramètres définis dans l’onglet « Filtre utilisateur » en saisissant le filtre directement.

Nom d’utilisateur LDAP :

Si cette case est cochée, la valeur du login sera comparée au noom d’utilisateur dans l’annuaire LDAP. L’attribut correspondant qui est généralement uid ou samaccountname sera détecté automatiquement par ownCloud.

Adresse email LDAP :

Si cette case est cochée, la valeur du login sera comparée à une adresse électronique dans l’annuaire LDAP. Plus spécifiquement, les attributs mailPrimaryAddress et mail.

Autres attributs :

Cette liste à sélection multiple permet de sélectionner d’autres attributes pour la comparaison. La liste est générée automatiquement à partir des attributs de l’objet utilisateur dans votre annuaire LDAP.

Éditer le filtre raw à la place :

Cliquer sur ce lien permet de saisir le filtre directement.

Le terme privilégié (placeholder) %uid est remplacé par le nom de login saisi par l’utilisateur lors de la connexion.

Exemples :

only username:

(&(objectClass=inetOrgPerson)(memberOf=cn=owncloudusers,ou=groups,
dc=ma-societe,dc=com)(uid=%uid)

username or email address:

((&(objectClass=inetOrgPerson)(memberOf=cn=owncloudusers,ou=groups,
dc=ma-societe,dc=com)(|(uid=%uid)(mail=%uid)))

Filtres de groupes¶

Par défaut, aucun groupe LDAP n’est disponible dans ownCloud. Les paramètres de cet onglet détermineront quels groupes seront disponibles dans ownCloud.

seulement ces classes d’objet :

ownCloud déterminra quelles classes d’objet sont typiquement disponibles pour les objets groupes dans votre serveur LDAP. ownCloud ne listera que les classes d’objets qui renvoient au moins un objet groupe. Vous pouvez sélectionner plusieurs classes d’objets. Les classes d’objets typiques sont « group » et « posixGroup ».

seulement de ces groupes :

ownCloud générera une liste des groupes disponibles trouvés dans votre serveur LDAP. Vous pourrez alors sélectionner le ou les groupes qui pourront accéder à votre serveur ownCloud.

Éditer le filtre raw à la place :

Cliquer sur ce lien permet de saisir le filtre directement.

Exemple:

objectClass=group
objectClass=posixGroup

x groupes trouvés :

Ceci est un indicateur fournissant le nombre approximatif de groupes qui seront listés dans ownCloud. Ce nombre se met à jour automatiquement après chaque modification du filtre.

Avancé¶

L’onglet « Avancé » contient des options qui ne sont pas obligatoires pour avoir une connexion opérationnelle. Il fournit des contrôle pour désactiver la configuration, configurer des serveurs de réplique et diverses options pour améliorer les performances.

Les paramètres avancés sont structurés en trois parties :

Paramètres de connexion
Paramètres du répertoire
Attribus spéciaux

Paramètres de connexion¶

Configuration active :

Active ou désactive la configuration en cours. Par défaut, elle est désactivée. Quand ownCloud réussit le test de connexion, elle est automatiquement activée.

Serveur de backup (réplique) :

Si vous avez un serveur LDAP de secours, saisissez les paramètres de connexion ici. ownCloud se connectera alors automatiquement sur ce serveur si le serveur principal ne peut être contacté. Le serveur de secours doit être une réplique du serveur principal afin que les objets UUID correspondent.

Exemple :

annuaire2.ma-societe.com

Port du serveur de backup (réplique) :

Le port de connexion du serveur LDAP de secours. Si aucun port n’est donnée, mais seulement l’hôte, alors le numéro de port du serveur principal sera utilisé.

Exemple :

389

Désactiver le serveur principal :

Vous pouvez forcer la désactivation du serveur principal et forcer ownCloud à se connecter sur le serveur de secours. Ceci est utile pour effectuer une maintenance sur le serveur principal.

Désactiver la validation des certificats SSL :

Désactive la vérification des certificats SSL. À n’utiliser que pour faire des tests !

Durée de vie du cache (TTL) :

Un cache est introduit pour éviter du trafic LDAP inutile, par exemple les noms d’utilisateur pour éviter d’interroger le serveur LDAP pour chaque page et accélérer le chargement de la page Utilisateurs. L’enregistrement de la configuration vide le cache. La durée est exprimée en secondes.

Veuillez noter que la plupart des requêtes PHP nécessite une nouvelle connexion au serveur LDAP. Si vous avez besoin de requêtes PHP à jour, nous recommandons de définir une durée de vie de 15 secondes par exemple plutôt que de désactiver totalement le cache.

Exemples :

dix minutes : 600
une heure : 3600

Consulter la section « Cache » ci-dessous pour des informations détaillées sur la gestion du cache.

Paramètres du répertoire¶

Champ “nom d’affichage” de l’utilisateur :

L’attribut qui doit être utilisé pour le nom d’affichage dans ownCloud.

Exemple : displayName

DN racine de l’arbre utilisateurs :

Le DN de la racine LDAP, à partie de laquelle les utilisateurs seront recherchés. Ce doit être un DN complet, quel que soit ce que vous avez saisi dans le DN racine dans les paramètres de base. Vous pouvez définir plusieurs racines, une par ligne.

Exemple :

cn=programmeurs,dc=ma-societe,dc=com

cn=designers,dc=ma-societe,dc=com

Attributs de recherche utilisateurs :

Ces attributs sont utilisés quand des recherches d’utilisateurs sont effectuées, par exemple dans le dialogue de partage. Le nom d’affichage de l’utilisateur est l’attribut par défaut. Vous pouvez indiquer plusieurs attributs, un par ligne.

Si un attribut n’est pas disponible pour un objet utilisateur, l’utilisateur ne sera pas listé et ne pourra pas se connecter. Cela affecte également l’attribut « displayName ». Si vos changez la valeur par défaut, vous devez indiquer ici l’attribut pour le nom d’affichage.

Exemple :

displayName

mail

Champ “nom d’affichage” du groupe :

L’attribut qui doit être utilisé pour le nom de groupe ownCloud. ownCloud autorise un jeu limité de caractères (a-zA-Z0-9.-_@). Une fois que le nom du groupe a été assigné, il ne peut être modifié.

Example : cn

Base Group Tree :

Le DN de la racine LDAP, à partie de laquelles les groupes seront recherchés. Ce doit être un DN complet, quel que soit ce que vous avez saisi dans le DN racine dans les paramètres de base. Vous pouvez définir plusieurs racines, une par ligne.

Exemple :

cn=barcelone,dc=ma-societe,dc=com

cn=madrid,dc=ma-societe,dc=com

Attributs de recherche des groupes :

Ces attributs sont utilisés quand des recherches de groupes sont effectuées, par exemple dans le dialogue de partage. Le nom d’affichage du groupe est l’attribut par défaut. Vous pouvez indiquer plusieurs attributs, un par ligne.

Si vous avez changé la valeur par défaut, l’attribut de nom d’affichage du groupe ne sera pas pris en compte, à moins de le spécifier.

Exemple :

cn

description

Association groupe-membre :

L’attribut utilisé pour indiquer l’appartenance aux groupes, c’est-à-dire l’attribut utilisé par les groupes LDAP pour se référer à leurs utilisateurs.

ownCloud détecte la valeur automatiquement. Vous ne devriez le changer que si vous avez une très bonne raison et que vous savez ce que vous faites.

Exemple : uniquemember

Attributs spéciaux¶

Champ du quota :

ownCloud peut lire un attribut LDAP et définir le quota de l’utilisateur en fonction de sa valeur. Indiquer l’attribut ici et il renverra des valeurs compréhensibles, comme « 2 GB ». Les quotas définis dans LDAP ont la priorité sur ceux définis dans la page de gestion des utilisateurs d’ownCloud.

Exemple : ownCloudQuota

Quota par défaut :

Remplace le quota par défaut d’ownCloud pour les utilisateurs n’ayant pas de quota défini dans le champ « Champ du quota ».

Exemple : 15 GB

Champ Email :

Définit l’adresse électronique de l’utilisateur à partir de son attribut LDAP. Laisser vide pour avoir le comportement par défaut.

Exemple : mail

Convention de nommage du répertoire utilisateur :

Par défaut, le serveur ownCloud crée le répertoire utilisateur dans le répertoire data d’ownCloud et lui donne le nom de l’utilisateur, par exemple /var/www/owncloud/data/alice. Vous pourriez vouloir changer ce paramètre et le nommer en fonction d’une valeur d’attribut LDAP. L’attribut peut également renvoyer un chemin absolu, par exemple /mnt/storage43/alice. Laisser vide pour avoir le comportement par défaut.

Exemple : cn

Dans les nouvelles installations d’ownCloud (8.0.10, 8.1.5, 8.2.0 et suivantes), la convention de nommage du répertoire utilisateur est mise en œuvre. Cela signifie qu’une fois définie la convention de nommage du répertoire utilisateur, (obtenir le répertoire utilisateur à partir d’un attribut LDAP), le répertoire doit être disponible pour tous les utilisateurs. Si ce n’est pas le cas pour un utilisateur, alors celui-ci ne pourra pas se connecter. De plus, le système de fichiers ne sera pas défini pour cet utilisateur, et donc ses partages de fichiers ne seront pas disponibles pour les autres utilisateurs.

Dans les installations ownCloud existantes, l’ancien comportement s’applique toujours, c’est-à-dire que le nom d’utilisateur est utilisé pour le répertoire utilisateur quand l’attribut LDAP n’est pas défini. Vous pouvez changer ceci en mettant en œuvre la convention de nommage du répertoire utilisateur avec la commande occ dans ownCloud 8.2, comme dans cet exemple pour Ubuntu:

sudo -u www-data php occ config:app:set user_ldap enforce_home_folder_naming_rule --value=1

Expert¶

Avertissement

Dans les paramètres Expert, le comportement de base peut être adapté à vos besoins. La configuration doit être bien testée avant d’être mise en production.

Nom d’utilisateur interne

Le nom d’utilisateur interne est l’identifiant ownCloud pour les utilisateurs LDAP. Par défaut, il est créé à partir de l’attribut UUID. L’attribut UUID permet d’assurer que le nom d’utilisateur est unique et que les caractères n’ont pas besoin d’être convertis. Seuls les caractères suivants sont acceptés : [a-zA-Z0-9_.@-]. Les autres caractères sont remplacés par leurs équivalents ASCII ou tout simplement omis.

Le service LDAP s’assure qu’il n’y a pas de doublons de noms d’utilisateurs internes dans ownCloud, c’est-à-dire qu’il vérifie tous les autres services de gestion d’utilisateurs (y compris les utilisateurs locaux d’ownCloud). En cas de collisions, un nombre aléatoire(entre 1000 et 9999) est ajouté à la valeur récupérée. Par exemple, si « alice » existe, le nom d’utilisateur suivant pourra être « alice_1337 ».

Le nom d’utilisateur interne est le nom par défaut du répertoire utilisateur dans ownCloud. C’est aussi une partie des URL distantes, comme par exemple tous les services *DAV.

Vous pouvez changer tout cela en utilisant le paramètre « Nom d’utilisateur interne ». Laisser vide pour conserver le comportement par défaut. Les modifications n’affecterons que les nouveaux utilisateurs LDAP connectés à owncloud.

Example : uid

Surcharger la détection d’UUID

Par défaut, ownCloud détecte automatiquemnt l’attribut UUID. L’attribut UUID est utilisé pour identifier de façon unique les utilisateurs et les groupes LDAP. Le nom d’utilisateur interne est créé sur la base de l’UUID, sauf indications contraires.

Vous pouvez passer outre ce paramètre et indiquer l’attribut de votre choix. Vous devez vous assurer que l’attribut choisi peut être récupéré pour les utilisateurs et les groupes et qu’il est unique. Laisser vide pour conserver le comportement par défaut. Les modifications ne prendront effet que sur les nouveaux groupes et utilisateurs LDAP connectés à ownCloud. Cela prendra effet également quand le DN d’un utilisateur ou d’un groupe change et qu’un ancien UUID est en cache, ce qui aura pour résultat un nouvel utilisateur ou groupe. Pour cette raison, le paramètre doit être mis en œuvre avant la mise en production d’ownCloud et le nettoyage des liaisons (voir la section Correspondances utilisateur et groupe ci-dessous).

Example : cn

Association Nom d’utilisateur-Utilisateur LDAP

ownCloud utilise les noms d’utilisateurs comme clés pour stocker et assigner les données. Afin d’identifier précisément et de reconnaître les utilisateurs, chaque utilisateur LDAP a un nom d’utilisateur interne à ownCloud. Ceci nécessite une correspondance entre le nom d’utilisateur ownCloud et le nom d’utilisateur LDAP. Le nom d’utilisateur créé est associé à l’UUID de l’utilisateur LDAP. De plus, le DN est mis en cache pour réduire l’interaction avec LDAP, mais n’est pas utilisé pour l’identification. Si le DN change, le changement sera détecté par ownCloud en vérifiant la valeur de l’UUID.

Ceci s’applique aussi aux groupes.

Le nom interne ownCloud est utilisé partout dans ownCloud. La suppression des associations laissera des traces partout. Ne supprimer jamais les associations dans un environnement de production, mais seulement en test ou sur un serveur expérimental.

La suppression des associations n’est pas propre à la configuration en cours, elle affecte toutes les configurations !

Test de la configuration¶

Le bouton Tester la configuration vérifie les valeurs données dans les champs de saisie. Vous n’avez pas besoin de sauvegarder avant de tester. En cliquant sur le bouton, ownCloud essaiera d’établir la liaison en utilisant les paramètres actuellement déifinis dans les champs de saisie. Si la liaison échoue, vous verrez un bandeau jaune avec le message suivant : « La configuration est invalide. Veuillez consulter le fichier journal d’ownCloud pour plus de détails. ».

Quand le test de connexion est réussi, sauvegarder la configuration et vérifier que les utilisateurs et les groupes sont correctement récupérés sur la page Utilisateurs.

Intégration des avatars dans ownCloud¶

ownCloud gère les photos de profil utilisateur, aussi appelées avatars. Si un utilisateur a une photo stockée dans l’attribut jpegPhoto ou thumbnailPhoto de votre annuaire LDAP, elle sera utilisée comme avatar. Dans ce cas, l’utilisateur ne pourra pas modifier son avatar sur sa page personnelle car elle doit être chagée dans l’annuaire LDAP. L’attribut jpegPhoto est préféré à l’attribut thumbnailPhoto.

Si l’attribut jpegPhoto ou thumbnailPhoto n’est pas défini ou vide, les utilisateurs peuvent alors téléverser leur avatar sur leur page personnelle. Les avatars gérés dans ownCloud ne sont pas stockés dans le serveur LDAP.

L’attribut jpegPhoto ou thumbnailPhoto est vérifié une fois par jour pour s’assurer que la photo de l’annuaire LDAP est utilisée dans ownCloud. Les avatars LDAP ont la priorité sur les avatars d’ownCloud, et quand la photo de l’annuaire LDAP est supprimée, l’avatar le plus récent dans ownCloud la remplace.

Les photos récupérées dans l’annuaire LDAP sont automatiquement redimensionnées dans ownCloud. Ceci n’affecte que la présentation et la photo originale n’est pas modifiée.

Dépannage et astuce¶

Vérification de certificat SSL (LDAPS, TLS)¶

Une erreur courante avec les cetificats SSL est qu’ils peuvent ne pas être connus dans PHP. Si vous avez des problèmes avec la validation de certificats, assurez-vous que :

le certificat du serveur concerné est bien installé sur le serveur ownCloud ;
le certificat est indiqué dans le fichier de configuration LDAP (généralement /etc/ldap/ldap.conf) ;

d’utiliser LDAPS ; assurez-vous également que le port est correctement configuré (par défaut 636).

Microsoft Active Directory¶

Par rapport aux précédentes versions d’ownCloud, aucun autre paramétrage n’a besoin d’être effectué pour qu’ownCloud fonctionne avec Active Directory. ownCloud trouve automatiquement la configuration correcte pendant le processus de paramétrage initial.

Permissions de lecture de memberOf¶

Si vous voulez autoriser memberOf comme filtre, vous pourriez avoir besoin de donner à l’utilisateur LDAP faisant les requêtes de l’utiliser. Pour Microsoft Active Directory, ceci est décrit ici.

Duplication de configurations de serveur¶

Dans le cas où vous avez une configuration opérationnelle et que voulez en créer une similaire ou prendre une « photo » des configurations avant de les modifier, vous pouvez faire ce qui suit :

rendez-vous dans l’onglet Serveur ;
dans la liste déroulante Serveur choisissez Ajouter une configuration du serveur ;
à la question Récupérer les paramètres depuis une configuration récente du serveur ?, répondez Oui ;
(facultatif) rendez-vous dans l’onglet Avancé et déselectionner la case Configuration active dans les Paramètres de connexion de sorte que la nouvelle configuration ne soit pas utilisée lors de l’enregistrement ;
cliquez sur le bouton Sauvegarder.

Vous pouvez maintenant modifier et activer la configuration.

Cache¶

Utilisation du cache pour accélérer les recherches. Consulter Configuration de la mémoire cache). Le cache d’ownCloud est rempli à la demande et demeure et demeure jusqu’à ce que la Durée de vie du cache (TTL) pour chaque requête unique expire. Les identifiants des utilisateurs ne sont pas mis en cache, donc, si vous voulez améliorer les temps de connexion, il faudra installer un serveur LDAP esclave pour partager la charge.

Vous pouvez ajuster la valeur de la Durée de vie du cache (TTL) pour trouver le bon équilibre entre performance et fraîcheur des données LDAP. Par défaut, toutes les requêtes LDAP sont mise en cache pendant 10 minutes, et vous pouvez modifier cette valeur avec le paramètre Durée de vie du cache (TTL). Le cache répond à chaque requête identique à une requête précédente pendant la durée de vie de la requête originale plutôt que d’interroger le serveur LDAP.

La Durée de vie du cache (TTL) est liée à chaque requête. Après l’expiration d’une entrée de cache, il n’y a pas de déclencheur automatique pour récupérer à jour, car le cache est alimenté seulement par les nouvelles requêtes, par exemple en ouvrant la page d’administration des utilisateurs ou en effectuant une recherche dan un dialogue de partage.

Il n’existe qu’un déclencheur qui est automatiquement déclenché par une tâche de fond qui conserve les données de user-group-mappings à jour et en cache.

Dans des circonstances normales, tous les utilisateurs ne sont pass chargés en même temps. Typiquement, le chargement des utilisateurs intervient quand les pages de résultats sont générées, par lot de 30 jusqu’à ce que la limite soit atteinte ou qu’il n’y ait plus de résultats. Pour que ceci fonctionne pour un serveur ownCloud et LDAP, Paged Results doit être géré, ce qui suppose d’utiliser PHP au moins dans sa version 5.4.

ownCloud se souvient de la configuration LDAP à laquelle appartient un utilisateur. Cela signifie que chaque requête sera toujours dirigée vers le bon serveur, sauf si l’utilisateur n’existe plus, par exemple à cause de la migration d’un serveur ou parce qu’il est injoignable. Dans ce cas, les autres serveurs recevront aussi la requête.

Indexation LDAP¶

Activer l’indexation. Le choix des attributs à indexer dépend de votre configuration et du serveur LDAP utilisé. Consulter index openLDAP pour openLDAP, et Comment indexer un attribut dans Active Directory pour Active Directory. Le guide openLDAP est particulièrement utile pour savoir quels attributs indexer.

Utilisation d’une base DN précise¶

Plus la base DN sera précise, plus les requêtes LDAP seront rapides car le serveur devra parcourir moins de branches pour les recherches.

Utilisation de filtre précis¶

Utiliser de bons filtres pour limiter l’étendue des recherches LDAP, et pour diriger intelligemment le serveur dans ses recherches plutôt que de faire des recherches sur tous les objets.

Fonctionnement LDAP d’ownCloud¶

Certains aspects du fonctionnement du service LDAP d’ownCoud sont décrits ici.

Correspondances utilisateur et groupe¶

Dans ownCloud, le nom de l’utilisateur ou du groupe est utilisé pour avoir toutes les informations pertinentes assignées dans la base de données. Pour fonctionner de manière fiable, un nom d’utilisateur ou de groupe interne est créé et associé au DN et à l’UUID LDAP. Si le DN change dans LDAP, owncloud le détecte et il n’y aura alors pas de conflit.

Ces correspondances sont faites dans les tables ldap_user_mapping et ldap_group_mapping de la base de données. Le nom d’utilisateur est aussi utilisé pour le nom du répertoire utilisateur (sauf indication contraire dans Convention de nommage du répertoire utilisateur), qui contient les fichiers et les méta-données.

À compter de la version 5 d’ownCloud, le nom d’utilisateur et le nom d’affichage sont distincts. Ce n’est pas le cas pour les noms de groupe, c’est-à-dire qu’un nom de groupe ne peut être altéré.

Ceci signifie que votre configuration LDAP doit être finalisée et correcte avant de passer en production. Les tables de correspondances sont remplies rapidement, mais tant que vous n’êtes pas en production, vous pouvez les vider à tout moment. Ne faites pas cela en production.

Serveur de secours¶

Quand ownCloud n’arrive pas à contacter le serveur principal LDAP, il suppose que celui-ci est éteint et n’essaiera pas de s’y reconnecter pendant la durée spécifiée de la Durée de vie du cache (TTL). Si vos avez un serveur de secours configuré, ownCloud se connectera alors sur celui-ci. Quand vous avez planifié une maintenance, cochez la case Désactiver le serveur principal pour éviter des tentatives de connexion inutiles.