Documentation Oracle Cloud Infrastructure

Utilisation de LDAP pour l'autorisation

Découvrez comment utiliser LDAP pour l'autorisation avec File Storage.

Vous pouvez utiliser LDAP (Lightweight Directory Access Protocol) en tant que service d'informations réseau pour fournir des informations d'autorisation au service File Storage. L'utilisation de LDAP pour fournir des informations d'autorisation offre les avantages suivants :

  • Gestion centralisée des utilisateurs et des groupes UNIX.
  • Prise en charge de jusqu'à 256 groupes UNIX. Si vous activez LDAP pour les groupes UNIX secondaires plutôt que d'utiliser la liste de groupes fournie dans l'en-tête RPC d'une demande NFS, vous n'êtes pas soumis à la limite AUTH_SYS de 16 groupes.
  • L'infrastructure LDAP est requise pour par authentification utilisateur lors de l'utilisation de Kerberos. LDAP n'est pas requis pour tous les scénarios Kerberos, par exemple lorsque l'export réduit tout.

Recherche de groupe secondaire

Les systèmes de fichiers File Storage autorisent l'accès à l'aide de l'UID/GID de l'opération NFS et de la liste des groupes UNIX secondaires. Par défaut, AUTH_SYS utilise la liste de groupes fournie dans l'en-tête RPC de la demande NFS.

Lorsque l'autorisation LDAP est activée, File Storage utilise l'UID UNIX de l'en-tête RPC de la demande NFS pour extraire la liste des groupes UNIX secondaires du serveur LDAP pour l'accès AUTH_SYS. La liste GIDLIST existante dans l'en-tête RPC est remplacée par la liste GIDLIST du serveur LDAP. La récupération de groupes UNIX secondaires à partir d'un serveur LDAP permet à la demande d'autorisation d'utiliser jusqu'à 256 groupes.

Si la recherche de groupe secondaire à l'aide du mappage d'ID est activée, mais pas configurée, mal configurée ou si le service LDAP n'est pas disponible, File Storage ne peut pas mettre à jour la liste de groupes secondaires utilisée dans la demande. Cela peut entraîner des erreurs d'autorisation.

Scénarios de demande NFS pour AUTH_SYS
LDAP pour la liste des groupes activé ? Réponse LDAP Exportation de squash activée ? Demande NFS
Tout Tout Oui (tout)

Si vous écrasez tout, les options UID de squash et GID de squash sont définies dans les options de l'export.

Aucune liste de groupes secondaires.
Tout Tout Oui (racine)

En cas d'écrasement de la racine, les options UID de séquence et GID de séquence sont définies dans les options de l'export uniquement si l'UID est 0.

Aucune liste de groupes secondaires.
Non Non applicable Non Poursuit avec les UID/GID de l'en-tête RPC.
Oui Correspondance d'UID Non Utilise la liste des groupes secondaires récupérée à partir du serveur LDAP.
Oui Aucune correspondance d'UID ou erreur LDAP Non Poursuit avec les UID/GID de l'en-tête RPC. Aucune liste de groupes secondaires.
Important

Pour utiliser LDAP pour l'autorisation, vous devez activer LDAP pour la cible de montage et lors de l'export.

Si vous utilisez l'authentification Kerberos avec LDAP, le comportement est légèrement différent. Pour plus d'informations, reportez-vous à la section LDAP Lookups and Anonymous Access.

Mise en mémoire cache

File Storage utilise un modèle de mise en cache à la demande en mémoire uniquement pour stocker les informations d'autorisation afin d'augmenter les performances et de réduire la charge sur votre serveur LDAP.

Lorsqu'une demande NFS est effectuée, File Storage contacte votre serveur LDAP pour obtenir des informations d'autorisation. File Storage met en mémoire cache les informations d'autorisation, positives ou négatives, à utiliser lors des opérations NFS suivantes.

Vous pouvez configurer la durée pendant laquelle File Storage met en mémoire cache ces informations lorsque vous configurez une cible de montage pour LDAP à l'aide des options suivantes :

  • Intervalle d'actualisation du cache en secondes : durée pendant laquelle la cible de montage doit autoriser la persistance d'une entrée dans son cache avant de tenter d'actualiser l'entrée. Choisissez une valeur qui équilibre les implications en matière de sécurité et une charge acceptable sur votre serveur LDAP.
  • Durée de vie du cache en secondes : durée maximale pendant laquelle la cible de montage est autorisée à utiliser une entrée mise en cache. Si les entrées du cache ne peuvent pas être actualisées en temps opportun en raison d'une charge ou d'échecs dans l'infrastructure client, il est utile d'utiliser les anciennes entrées jusqu'à ce que la connectivité soit restaurée. Définissez la valeur sur la période la plus longue pendant laquelle vous souhaitez disposer d'une entrée obsolète dans le cache LDAP, y compris en cas d'indisponibilité du serveur LDAP pour quelque raison que ce soit.
  • Durée de vie négative du cache en secondes : durée pendant laquelle une cible de montage conserve les informations indiquant qu'un utilisateur n'a pas été trouvé dans la configuration de la correspondance d'ID. Si aucun utilisateur n'est trouvé dans la base de données LDAP, la cible de montage place une entrée dans le cache indiquant que l'utilisateur n'existe pas. Choisissez une valeur qui équilibre les implications en matière de sécurité et une charge acceptable sur votre serveur LDAP.

Prérequis

Exigences :

  • Infrastructure LDAP gérée par le client, y compris un serveur LDAP prenant en charge un schéma posix RFC2307. Les serveurs LDAP peuvent être basés sur OpenLDAP ou Microsoft Active Directory. Une configuration personnalisée peut être nécessaire pour la prise en charge de File Storage de l'annuaire LDAP.

  • Compte de connexion au serveur LDAP qu'une cible de montage File Storage peut utiliser pour rechercher des informations de groupe et d'utilisateur conformes à RFC2307.

    • Le serveur LDAP doit avoir les attributs utilisateur suivants :
      • ObjectClass : posixAccount : cette classe d'objet fournit les attributs suivants pour l'utilisateur.
      • uidNumber : ID utilisateur UNIX.
      • gidNumber : ID de groupe UNIX du groupe principal de l'utilisateur.
      • uid - Nom d'utilisateur de l'utilisateur
    • Le serveur LDAP doit avoir les attributs de groupe suivants :
      • ObjectClass : posixGroup : cette classe d'objet fournit les attributs suivants pour le groupe.
      • gidNumber : ID de groupe UNIX pour le groupe
      • memberUid : attribut uid des utilisateurs qui sont membres de ce groupe. Cet attribut peut être ajouté plusieurs fois pour inclure plusieurs utilisateurs dans le groupe.
    Conseil

    Vous pouvez tester la prise en charge des schémas LDAP.
  • Serveur DNS permettant à la cible de montage de rechercher des noms d'hôte, y compris le serveur LDAP.
Cette image présente l'infrastructure gérée par le client et gérée par OCI requise pour l'autorisation LDAP.
  1. Communication avec le service DNS via le port TCP/UDP 53.
  2. Communication avec le service LDAP géré par le client sur le port TCP configuré dans le connecteur sortant. La valeur par défaut est le port TCP 636.
  3. Données cryptées lorsqu'elles sont inactives dans File Storage.

Infrastructure LDAP

File Storage nécessite un connecteur sortant pour que les cibles de montage puissent communiquer avec un serveur LDAP sur son port LDAPS. Le connecteur sortant requiert que vous fournissiez le nom de domaine qualifié complet du serveur LDAP, un nom utilisateur et un mot de passe de liaison au serveur LDAP, ainsi que la base de recherche des utilisateurs et des groupes.

Pour autoriser File Storage à atteindre le serveur LDAP, vérifiez les points suivants :

  • Le pare-feu du serveur LDAP doit autoriser le trafic entrant provenant de la cible de montage File Storage à l'aide du protocole TCP 636 (par défaut).
  • Les listes de sécurité et groupes de sécurité réseau utilisés doivent autoriser le trafic de la cible de montage et du serveur LDAP.
  • Le DNS est configuré pour que la cible de montage et les clients résolvent le nom d'hôte. Les options de configuration DNS sont les suivantes :
    • Utilisation du DNS OCI avec la résolution par défaut et les noms d'hôte dans votre VCN - Cette option n'offre pas la flexibilité des noms DNS personnalisés. Les noms d'hôte se terminent par oraclevcn.com avec des sous-domaines pour VCN et le sous-réseau. Pour plus d'informations, reportez-vous à DNS dans votre réseau cloud virtuel.
    • Utilisation d'OCI DNS privé avec des zones privées : les zones DNS d'un domaine personnalisé sont hébergées dans OCI DNS. Avec cette option, il n'est pas nécessaire de gérer votre propre serveur DNS, car OCI gère entièrement le DNS. Vous devez gérer les zones et les enregistrements. Pour plus d'informations, reportez-vous à DNS privé.
    • Utilisation d'un serveur DNS géré par le client - Lorsque vous créez un VCN, ne sélectionnez pas Utiliser les noms d'hôte DNS dans ce VCN. Configurez plutôt le VCN pour qu'il utilise votre propre serveur DNS à l'aide de l'une des méthodes suivantes :
      1. Configurez les options DHCP dans le sous-réseau afin d'utiliser un serveur DNS géré par le client.
      2. Utilisez le résolveur VCN avec une adresse de transfert et une règle de transfert de sorte que les requêtes DNS dans le VCN soient transmises à un serveur DNS géré par le client.

File Storage ne prend pas en charge SSLv2, SSLv3, TLSv1 ou TLSv1.1 pour l'autorisation LDAPS. File Storage prend en charge les mécanismes de cryptage OpenSSL suivants pour l'autorisation LDAPS :

  • DHE-DSS-AES128-GCM-SHA256
  • DHE-DSS-AES256-GCM-SHA384
  • DHE-RSA-AES128-GCM-SHA256
  • DHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES256-GCM-SHA384
  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384

Test de la prise en charge des schémas LDAP

Vous pouvez utiliser les exemples de requête suivants pour vous assurer que File Storage peut rechercher des informations de groupe et d'utilisateur conformes à RFC2307 à partir d'un serveur LDAP avec une configuration prise en charge.

ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uid=<username>))' uidNumber gidNumber
Exemple de sortie de requête
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uid=root))' uidNumber gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uid=root))
# requesting: uidNumber gidNumber
#

# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uidNumber: 0

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
ldapsearch -b <user_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixAccount)(uidNumber=<user_uid>))' uid gidNumber
Exemple de sortie de requête
$ ldapsearch -b 'ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixAccount)(uidNumber=0))' uid gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixAccount)(uidNumber=0))
# requesting: uid gidNumber
#
# root, Users, nfs_kerberos.fss_test.com
dn: uid=root,ou=Users,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
uid: root
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
ldapsearch -b <group_searchbase> -H ldaps://<ldaps_server_fqdn>:<ldaps_port> -D <bind_DN> -W -s sub '(&(objectClass=posixGroup)(memberuid=<username>))' gidNumber
Exemple de sortie de requête
$ ldapsearch -b 'ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com' -H 'ldaps://example.com:636' -D 'cn=admin,dc=fss_test,dc=com' -W -s sub '(&(objectClass=posixGroup)(memberuid=root))' gidNumber
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com> with scope subtree
# filter: (&(objectClass=posixGroup)(memberuid=root))
# requesting: gidNumber
#
# root, Groups, nfs_kerberos.fss_test.com
dn: cn=root,ou=Groups,dc=nfs_kerberos,dc=fss_test,dc=com
gidNumber: 0
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Conseil

Vous pouvez créer des alarmes basées sur les mesures de système de fichiers qui vous aident à repérer et à diagnostiquer rapidement les problèmes de connectivité LDAP.

Surveillance et alarmes

Il est important de connaître rapidement un problème lors de l'utilisation de LDAP. Si l'infrastructure LDAP ne fonctionne pas correctement, les clients NFS risquent de perdre l'accès aux systèmes de fichiers File Storage mis à disposition via ses exports. Pour repérer de tels problèmes, nous vous recommandons de définir des alarmes sur des mesures de cible de montage. Les alarmes peuvent vous alerter de problèmes d'infrastructure en quelques minutes.

Les alarmes créées à partir des erreurs de connexion LDAP et des erreurs de demande LDAP détectent les problèmes de connectivité entre les cibles de montage, les connecteurs sortants et l'infrastructure LDAP gérée par le client.

L'exemple de requête suivant peut être utilisé pour créer une alarme pour la connectivité LDAP :

LdapConnectionErrors[1m]{resourceType = "outboundconnector", mtResourceName = "<mount_target_name>", errorType != "success"}.max() >= 1

Pour plus d'informations sur la surveillance des mesures et l'utilisation des alarmes, reportez-vous à Présentation de Monitoring. Pour plus d'informations sur les notifications relatives aux alarmes, reportez-vous à Présentation de Notifications.

Stratégie IAM requise

File Storage doit accéder aux clés secrètes Vault de mot de passe du serveur LDAP. L'utilisateur qui configure la cible de montage et la cible de montage elle-même ont besoin d'un accès en lecture.

Important

Ces stratégies doivent être créées pour que vous puissiez configurer des cibles de montage afin qu'elles utilisent LDAP pour l'autorisation.

Stratégie de gestion des clés secrètes de coffre

Accordez à l'utilisateur ou au groupe qui crée les droits d'accès de clé secrète Vault. Pour plus d'informations, reportez-vous à Gestion des clés secrètes Vault.

Stratégie permettant d'activer la configuration de la cible de montage

Accordez à l'utilisateur ou au groupe qui configure LDAP sur une cible de montage des droits d'accès à l'aide d'une stratégie telle que la suivante :

allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID> }

Cela permet à l'utilisateur d'émettre des commandes File Storage qui lisent les clés secrètes Vault et affichent des parties de la clé secrète pour validation lors de la configuration.

Stratégie permettant à une cible de montage d'extraire des clés secrètes

Le service File Storage nécessite la possibilité de lire les clés secrètes. File Storage utilise des principaux de ressource pour accorder à un ensemble spécifique de cibles de montage l'accès à la clé secrète du coffre. Il s'agit d'un processus en deux étapes, d'abord les cibles de montage nécessitant un accès doivent être placées dans un groupe dynamique, puis le groupe dynamique est autorisé à lire les clés secrètes.

  1. Créez un groupe dynamique pour les cibles de montage avec une stratégie telle que la suivante :

    ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
    Remarque

    Si le groupe dynamique contient plusieurs règles, veillez à utiliser l'option Match any rules defined below.

  2. Créez une stratégie IAM qui donne au groupe dynamique de cibles de montage un accès en lecture aux clés secrètes Vault :

     allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>