Utilisation de LDAP pour l'autorisation
Voyez comment utiliser LDAP pour une autorisation avec File Storage.
Vous pouvez utiliser le protocole LDAP (Lightweight Directory Access Protocol) en tant que service d'informations réseau pour fournir des informations d'autorisation au service de stockage de fichiers. 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 d'un maximum de 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 une exigence 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 entraîne un plantage total.
Consultation de groupe secondaire
Les systèmes de fichiers du service de stockage de fichiers 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 de connexion d'appairage distant de la demande NFS.
Lorsque l'autorisation LDAP est activée, le stockage de fichiers utilise l'UID UNIX à partir 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. L'extraction de groupes UNIX secondaires à partir d'un serveur LDAP permet à la demande d'autorisation d'utiliser jusqu'à 256 groupes.
Si la consultation de groupe secondaire à l'aide du mappage d'ID est activée, mais non configurée, mal configurée ou si le service LDAP n'est pas disponible, le stockage de fichiers ne peut pas mettre à jour la liste de groupes secondaires utilisée dans la demande. Cela peut entraîner des erreurs d'autorisation.
LDAP pour la liste de groupes activé? | Réponse LDAP | Exportation de squash activée? | Demande NFS |
---|---|---|---|
Peu importe | Peu importe | Oui (toutes) |
Si tout est écrasé, l'UID squash et l'IDG squash sont définis dans les options de l'exportation. Aucune liste de groupes secondaires. |
Peu importe | Peu importe | Oui (racine) |
Si la racine est écrasée, l'UID squash et l'IDG squash sont définis dans les options de l'exportation 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 de groupes secondaires extraite 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. |
Pour utiliser LDAP pour l'autorisation, vous devez activer LDAP pour la cible de montage et lors de l'exportation.
Si vous utilisez l'authentification Kerberos avec LDAP, le comportement est légèrement différent. Pour plus de détails, voir Consultations LDAP et accès anonyme.
Mise en mémoire cache
Le service de stockage de fichiers utilise un modèle de mise en cache en mémoire uniquement à la demande 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 communique avec votre serveur LDAP pour obtenir des informations d'autorisation. Le stockage de fichiers met en mémoire cache les informations d'autorisation, qu'elles soient positives ou négatives, pour une utilisation dans les opérations NFS suivantes.
Vous pouvez configurer la durée pendant laquelle le service de stockage de fichiers met ces informations en mémoire cache lorsque vous configurez une cible de montage pour LDAP à l'aide des options suivantes :
- Intervalle d'actualisation de la mémoire cache en secondes : Durée pendant laquelle la cible de montage doit autoriser la persistance d'une entrée dans sa mémoire 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 en mémoire cache en secondes : Durée maximale pendant laquelle la cible de montage est autorisée à utiliser une entrée en mémoire 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 rétablie. Réglez la valeur à la période la plus longue pendant laquelle vous êtes prêt à avoir une entrée périmée dans le cache LDAP, y compris les cas d'indisponibilité du serveur LDAP pour quelque raison que ce soit.
- Durée de vie de la mémoire cache négative en secondes : Durée pendant laquelle une cible de montage tient à jour les informations indiquant qu'un utilisateur n'est pas trouvé dans la configuration de mappage 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éalables
Conditions requises :
- 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 du stockage de fichiers du répertoire LDAP.
-
Compte de connexion au serveur LDAP qu'une cible de montage du service de stockage de fichiers peut utiliser pour rechercher des informations sur les utilisateurs et les groupes conformes à RFC2307.
- Le serveur LDAP doit avoir les attributs d'utilisateur suivants :
- ObjectClass : posixAccount - Cette classe d'objet fournit les attributs suivants pour l'utilisateur.
- uidNumber - ID utilisateur UNIX.
- gidNumber - ID 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 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.
- Le serveur LDAP doit avoir les attributs d'utilisateur suivants :
- Serveur DNS permettant à la cible de montage de rechercher des noms d'hôte, y compris le serveur LDAP.
- Communication avec le service DNS sur le port TCP/UDP 53.
- 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.
- Données chiffrées au repos dans le service de stockage de fichiers.
Infrastructure LDAP
Le service de stockage de fichiers requiert un connecteur sortant pour que les cibles de montage puissent communiquer avec un serveur LDAP sur son port LDAPS. Le connecteur sortant nécessite que vous fournissiez le nom de domaine complet (FQDN) du serveur LDAP, un nom d'utilisateur et un mot de passe de liaison au serveur LDAP, ainsi que la base de recherche des utilisateurs et des groupes.
Pour permettre au stockage de fichiers d'atteindre le serveur LDAP, vérifiez les points suivants :
- Le pare-feu du serveur LDAP doit autoriser le trafic entrant à partir de la cible de montage du stockage de fichiers à l'aide de TCP 636 (par défaut).
- Toutes les listes de sécurité et groupes de sécurité de 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 le VCN et le sous-réseau. Pour plus d'informations, voir DNS dans le réseau en nuage virtuel. - Utilisation du DNS privé OCI avec des zones privées - Les zones DNS pour un domaine personnalisé sont hébergées dans le DNS OCI. 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, voir 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 :
- Configurez les options DHCP dans le sous-réseau pour utiliser un serveur DNS géré par le client.
- Utilisez le résolveur VCN avec un point d'extrémité de transmission et une règle de transmission afin que les interrogations DNS du VCN soient transmises à un serveur DNS géré par le client.
- 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
Le stockage de fichiers ne prend pas en charge SSLv2, SSLv3, TLSv1 ou TLSv1.1 pour l'autorisation LDAPS. Le stockage de fichiers prend en charge les suites de chiffrement OpenSSL suivantes 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 d'interrogation suivants pour vous assurer que le stockage de fichiers peut consulter les informations sur les utilisateurs et les groupes 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
$ 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
$ 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
$ 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
Vous pouvez créer des alarmes basées sur des mesures du système de fichiers qui vous aident à détecter et à diagnostiquer rapidement les problèmes de connectivité LDAP.
Surveillance et alertes
Il est important de prendre rapidement conscience d'un problème lors de l'utilisation de LDAP. Si l'infrastructure LDAP ne fonctionne pas correctement, les clients NFS peuvent perdre l'accès aux systèmes de fichiers de stockage de fichiers mis à disposition par le biais de ses exportations. Pour détecter de tels problèmes, nous vous recommandons de définir des alarmes sur les mesures de la cible de montage. Les alarmes peuvent vous alerter en quelques minutes sur les problèmes d'infrastructure.
Les alarmes créées à partir d'erreurs de connexion LDAP et d'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 d'interrogation 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, voir Aperçu de la surveillance. Pour plus d'informations sur les avis relatifs aux alarmes, voir Aperçu des avis.
Politique GIA requise
Le stockage de fichiers doit accéder aux clés secrètes de chambre forte du 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.
Ces politiques doivent être créées pour que vous puissiez configurer des cibles de montage afin qu'elles utilisent LDAP pour l'autorisation.
Politique de gestion des clés secrètes de chambre forte
Accordez à l'utilisateur ou au groupe qui crée les autorisations de clé secrète de la chambre forte. Pour plus d'informations, voir Gestion des clés secrètes de chambre forte.
Politique pour activer la configuration de la cible de montage
Accordez à l'utilisateur ou au groupe configurant LDAP sur une cible de montage des autorisations à l'aide d'une politique telle que :
allow <user|group> to read secret-family in compartment <Compartment_ID> where any { target.secret.id = <LDAP_Password_Secret_ID> }
L'utilisateur peut ainsi exécuter des commandes de stockage de fichiers qui lisent les clés secrètes du service de chambre forte et affichent des parties de la clé secrète pour validation lors de la configuration.
Politique 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. Le service de stockage de fichiers utilise des principaux de ressource pour accorder à un jeu spécifique de cibles de montage l'accès à la clé secrète de la chambre forte. Il s'agit d'un processus en deux étapes, d'abord les cibles de montage qui ont besoin d'accès doivent être placées dans un groupe dynamique, puis le groupe dynamique est autorisé à lire les clés secrètes.
-
Créez un groupe dynamique pour les cibles de montage avec une politique telle que :
ALL { resource.type='mounttarget', resource.compartment.id = '<mount_target_compartment_id>' }
Note
Si vous avez plusieurs règles dans le groupe dynamique, assurez-vous d'utiliser l'optionMatch any rules defined below
. -
Créez une politique IAM qui donne au groupe dynamique de cibles de montage l'accès en lecture aux clés secrètes du service de chambre forte :
allow dynamic-group <dynamic_group_name> to read secret-family in compartment <secret_compartment_name>
Étapes suivantes
Voir Configuration de LDAP pour l'autorisation pour les étapes suivantes.