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 limitation AUTH_SYS de 16 groupes.
  • L'infrastructure LDAP est requise pour l'authentification par utilisateur lors de l'utilisation de Kerberos. LDAP n'est pas requis pour tous les scénarios Kerberos, par exemple lorsque l'exportation est écrasante.

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, configurée de manière incorrecte 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 Ecrasement d'exportation activé ? Demande NFS
Tout Tout Oui (tout)

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

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

Si la racine est écrasante, l'UID de squash et le GID de squash sont définis dans les options de l'export uniquement si l'UID est 0.

Aucune liste de groupes secondaires.
Non Non applicable Non Poursuite avec les UID/GID de l'en-tête RPC.
Oui Correspondance d'UID Non Utilise la liste de groupes secondaires extraite du serveur LDAP.
Oui Aucune correspondance d'UID ou erreur LDAP Non Poursuite 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 à 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 mémoire cache à la demande uniquement en mémoire pour stocker les informations d'autorisation afin d'améliorer 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 cache les informations d'autorisation, qu'elles soient positives ou négatives, à utiliser dans les opérations NFS suivantes.

Vous pouvez configurer la durée pendant laquelle File Storage met en 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 une entrée à persister 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 qui prend 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 requise 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 sur les utilisateurs et les groupes RFC2307-compliant.

    • 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 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 avoir plusieurs utilisateurs dans le groupe.
    Conseil

    Vous pouvez tester la prise en charge du schéma 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 chiffrées au repos dans File Storage.

Infrastructure LDAP

File Storage nécessite un connecteur sortant afin 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 et la base de recherche pour les utilisateurs et les groupes.

Pour permettre à File Storage d'accéder au serveur LDAP, vérifiez les points suivants :

  • Le pare-feu du serveur LDAP doit autoriser le trafic entrant à partir de la cible de montage File Storage à l'aide du protocole TCP 636 (par défaut).
  • Toute liste de sécurité et groupe de sécurité réseau en cours d'utilisation doit autoriser le trafic de la cible de montage et du serveur LDAP.
  • Le DNS est configuré pour la cible de montage et les clients pour résoudre le nom d'hôte. Les options de configuration DNS sont les suivantes :
    • Utilisation d'OCI DNS 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 le 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. Au lieu de cela, configurez le VCN pour utiliser votre propre serveur DNS en utilisant 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 afin 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 sur les utilisateurs et les groupes RFC2307-compliant à 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 des mesures de système de fichiers qui vous aident à détecter et à diagnostiquer rapidement les problèmes de connectivité LDAP.

Surveillance et alarmes

Il est important de connaître rapidement un problème lorsque vous utilisez 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 détecter de tels problèmes, nous vous recommandons de définir des alarmes sur les mesures de cible de montage. Les alarmes peuvent vous alerter en quelques minutes sur les problèmes d'infrastructure.

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 du mot de passe du serveur LDAP. L'utilisateur qui configure la cible de montage et la cible de montage lui-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 permettant de gérer les clés secrètes Vault

Accordez à l'utilisateur ou au groupe créant 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 des autorisations de cible de montage à 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'exécuter des commandes File Storage qui lisent les clés secrètes Vault et affichent des parties de la clé secrète à valider 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 Vault. Il s'agit d'un processus en deux étapes : les cibles de montage nécessitant un accès doivent d'abord être placées dans un groupe dynamique, puis le groupe dynamique dispose d'un accès en lecture aux 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>