Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Configurer l' App-Only authentification Microsoft Entra ID pour SharePoint L' App-Only authentification Microsoft Entra ID (`ENTRA_ID_APP_ONLY`) est la méthode d'authentification recommandée pour une source de SharePoint données. Il utilise le flux d'informations d'identification du client OAuth 2.0 (application uniquement) : une application Microsoft Entra s'authentifie à l'aide d'un certificat, de sorte qu'aucune connexion utilisateur n'est requise au moment de l'analyse ou de la requête. Il s'agit de la seule méthode d'authentification qui prend en charge le contrôle d'accès au niveau du document (ACL). Pour une comparaison avec la `OAUTH2_APP` méthode alternative, voir[Méthodes d’authentification](kb-managed-ds-sharepoint.md#kb-managed-sharepoint-auth-methods). Cette configuration couvre deux systèmes (Microsoft Entra ID et votre AWS compte) et le certificat est l'identifiant qui les lie. Le connecteur stocke le certificat (clé privée incluse) sous forme de fichier PKCS \#12 (`.p12`) dans Amazon S3 et l'utilise pour signer des assertions d'authentification à Microsoft ; le certificat public correspondant est chargé lors de l'enregistrement de l'application Entra afin que Microsoft puisse valider ces assertions. **Accès administratif requis** Cette configuration nécessite un administrateur Microsoft Entra ID (administrateur global ou administrateur de rôles privilégiés) pour enregistrer l'application, configurer les autorisations et accorder le consentement de l'administrateur. Si vous utilisez l'étendue des `Sites.Selected` autorisations, vous avez également besoin d'un SharePoint administrateur pour accorder l'accès par site. Le tableau **des étapes de configuration et des rôles** ci-dessous indique l'accès requis pour chaque étape. ## Étapes de configuration et rôles Cette procédure implique à la fois un administrateur Microsoft Entra ID et un AWS administrateur. Selon la répartition des responsabilités au sein de votre organisation, une ou plusieurs personnes peuvent effectuer ces étapes. Utilisez le tableau suivant pour identifier l'accès requis par chaque étape. **Étapes de configuration et accès requis pour chacune** | Step (Étape) | Ce que tu fais | Accès nécessaire | | --- | --- | --- | | 1. Enregistrez l'application | Créez l'enregistrement de l'application Entra et enregistrez ses identifiants de client et de locataire. | Administrateur Microsoft Entra ID (administrateur global ou administrateur de rôles privilégiés) | | 2. Ajouter des autorisations et accorder le consentement | Attribuez les autorisations d'application pour votre configuration et accordez le consentement de l'administrateur. | Administrateur Microsoft Entra ID | | 3. Générez le certificat | Créez un certificat auto-signé et un bundle PKCS \#12 (.p12) avec OpenSSL. | Toute personne disposant d'un terminal local (OpenSSL requis) | | 4. Téléchargez le certificat public sur Entra | Ajoutez le certificat public aux clés d'enregistrement de l'application. | Administrateur Microsoft Entra ID | | 5. Accorder l'accès par site (Sites.Selecteduniquement) | Accordez à l'application l'accès à chaque SharePoint site via l'API Microsoft Graph. | Administrateur Microsoft Entra ID | | 6. Téléchargez le certificat sur Amazon S3 | Stockez le .p12 bundle dans un compartiment Amazon S3. | AWS administrateur (Amazon S3) | | 7. Créez le secret. | Conservez les informations d'identification dans un AWS Secrets Manager secret. | AWS administrateur (Secrets Manager) | | 8. Accorder au rôle de service l'accès au certificat | Ajoutez des autorisations de lecture Amazon S3 à votre rôle de service de base de connaissances. | AWS administrateur (IAM) | ## Choisissez votre configuration Avant de commencer, prenez deux décisions. Ils déterminent les autorisations que vous attribuez à l'étape 2 et la manière dont vous accordez l'accès au site. + **Document-level contrôle d'accès (ACL)** — Décidez si la source de données filtre les résultats des requêtes en fonction des SharePoint autorisations de chaque utilisateur. L'exploration des ACL nécessite Microsoft Graph et des SharePoint autorisations supplémentaires. Vous ne pouvez pas modifier ce paramètre après avoir créé la source de données. Pour en savoir plus, consultez [Document-level contrôles d'accès](kb-managed-ds-sharepoint-acl.md). + **Étendue des autorisations** — Décidez si l'application peut lire tous les SharePoint sites de votre client (**tous les sites**, l'option la plus simple) ou uniquement les sites que vous accordez explicitement (**`Sites.Selected`**option du moindre privilège). `Sites.Selected`Vous avez ensuite obtenu une subvention supplémentaire par site à l'étape 5, et tous les sites que vous ajouterez ultérieurement auront besoin de leur propre subvention. La combinaison de ces deux choix permet de sélectionner l'un des ensembles d'autorisations présentés dans la section suivante. ## Référence des autorisations Attribuez les autorisations d'application correspondant à votre configuration. Toutes les autorisations sont des autorisations d'**application** (non déléguées), et chacune nécessite le consentement de l'administrateur. Le connecteur s'authentifie auprès de deux ressources Microsoft : **Microsoft Graph** (pour énumérer les sites et, pour les ACL, pour résoudre les problèmes d'utilisateurs et de groupes) et l'**SharePoint**API REST (pour lire le contenu du site et, pour les ACL, les autorisations au niveau des éléments). **Important** Lorsque vous ajoutez ces autorisations dans le portail Entra, choisissez l'onglet **Autorisations de l'application**, et non **les autorisations déléguées**. App-only l'authentification utilise les autorisations des applications. Sélectionnez l'onglet correspondant à votre configuration pour voir le Microsoft Graph exact et SharePoint les autorisations à attribuer. ------ #### [ All sites, no ACLs ] **Tous les sites, contenu uniquement** | API | Autorisations | Objectif | | --- | --- | --- | | Microsoft Graph | Sites.Read.All | Énumérez et lisez tous les SharePoint sites. | | SharePoint | Sites.Read.All | Lisez le contenu du site via l' SharePoint API REST. | ------ #### [ All sites, with ACLs ] **Tous les sites, avec ACL** | API | Autorisations | Objectif | | --- | --- | --- | | Microsoft Graph | Sites.Read.All | Énumérez et lisez tous les SharePoint sites. | | Microsoft Graph | User.Read.All | Résolvez les utilisateurs pour les ACL au niveau du document. | | Microsoft Graph | GroupMember.Read.All | Résolvez l'appartenance à un groupe pour les ACL au niveau du document. | | SharePoint | Sites.FullControl.All | Lisez les autorisations au niveau des éléments pour l'analyse des ACL et vérifiez l'accès au moment de la requête. Sites.Read.Alln'est pas suffisant pour cette vérification. | ------ #### [ Sites.Selected, no ACLs ] **Sites.Selected, contenu uniquement** | API | Autorisations | Objectif | | --- | --- | --- | | Microsoft Graph | Sites.Selected | Accédez uniquement aux sites que vous autorisez explicitement (Microsoft Graph). | | SharePoint | Sites.Selected | Accédez uniquement aux sites que vous autorisez explicitement (SharePoint REST). Accordez le read rôle par site à l'étape 5. | ------ #### [ Sites.Selected, with ACLs ] **Sites.Selected, avec ACL** | API | Autorisations | Objectif | | --- | --- | --- | | Microsoft Graph | Sites.Selected | Accédez uniquement aux sites que vous autorisez explicitement (Microsoft Graph). | | Microsoft Graph | User.Read.All | Résolvez les utilisateurs pour les ACL au niveau du document. | | Microsoft Graph | GroupMember.Read.All | Résolvez l'appartenance à un groupe pour les ACL au niveau du document. | | SharePoint | Sites.Selected | Accédez uniquement aux sites que vous autorisez explicitement. Accordez le fullcontrol rôle par site à l'étape 5 (obligatoire pour lire les autorisations au niveau des éléments pour les ACL). | ------ **Note** `Sites.FullControl.All`accorde un large accès à tous les sites du locataire. Si votre organisation requiert le moins de privilèges, utilisez `Sites.Selected` et accordez un accès par site à l'étape 5. ## Valeurs que vous collectez lors de la configuration Vous créez ou collectez les valeurs suivantes au fur et à mesure que vous suivez les étapes. Vous les utilisez lorsque vous créez la source de données. Pour en savoir plus, consultez [Connecter une source SharePoint de données](kb-managed-ds-sharepoint-connect.md). **Référence de valeurs** | Value | Créé en | Utilisé pour | | --- | --- | --- | | ID de l’application (client) | Étape 1 | Le secret (clientId). | | ID du répertoire (locataire) | Étape 1 | La source de donnéestenantId. | | Certificat — PKCS \#12 bundle (.p12) et son mot de passe | Étape 3 | Le bundle (certificat et clé privée) est chargé sur Amazon S3 (étape 6) ; le mot de passe est stocké dans le secret (certificatePassword). | | Certificat — certificat public (.cer) | Étape 3 | La moitié publique du même certificat, téléchargée lors de l'enregistrement de l'application Entra (étape 4). | | Nom et clé du compartiment Amazon S3 | Étape 6 | La source de donnéescertificateS3Path. | | ARN du secret | Étape 7 | La source de donnéessecretArn. | ## Étape 1 : enregistrer l'application dans Microsoft Entra ID 1. Connectez-vous au [centre d’administration Microsoft Entra](https://entra.microsoft.com/). 1. Dans le menu de navigation de gauche, **développez Entra ID** et choisissez **App registration**. 1. Choisissez **Nouvel enregistrement**. 1. Dans **Nom**, entrez un nom descriptif, tel que`bedrock-sharepoint-connector`. 1. Pour les **types de comptes pris en charge**, sélectionnez **Comptes dans ce répertoire organisationnel uniquement (locataire unique)**. 1. Laissez l'**URI de redirection** vide. Un URI de redirection n'est pas nécessaire car l'application utilise le flux d'informations d'identification du client, et non un flux de connexion interactif. 1. Choisissez **S’inscrire**. 1. Sur la page de **présentation** de l'application, enregistrez l'ID de **l'application (client) et l'ID** du **répertoire (locataire)**. Tu auras besoin des deux plus tard. ## Étape 2 : ajouter des autorisations d'API et accorder le consentement de l'administrateur Ajoutez les autorisations pour votre configuration à partir de[Référence des autorisations](#kb-managed-sharepoint-entra-permissions). 1. Lors de l'enregistrement de votre application, choisissez **Autorisations API**, puis **Ajouter une autorisation**. 1. Choisissez **Microsoft Graph**, puis **Autorisations de l'application**. Recherchez et sélectionnez chaque autorisation Microsoft Graph pour votre configuration, puis choisissez **Ajouter des autorisations**. 1. Choisissez **à nouveau Ajouter une autorisation**. Choisissez **SharePoint**(sous **Microsoft APIs**), puis **Autorisations de l'application**. Sélectionnez chaque SharePoint autorisation pour votre configuration, puis choisissez **Ajouter des autorisations**. 1. Sur la page **des autorisations d'API**, choisissez **Accorder le consentement de l'administrateur pour [votre organisation]** et confirmez. Sans le consentement de l'administrateur, l'application ne peut pas accéder aux SharePoint données. **Note** L' App-Only authentification Microsoft Entra ID utilise le certificat (issu de l'étape 3) comme identifiant, de sorte que vous ne créez pas de secret client pour cette application. ## Étape 3 : générer le certificat d'authentification Générez un certificat auto-signé et empaquetez-le sous forme de bundle PKCS \#12 (`.p12`). Le bundle contient à la fois le certificat et sa clé privée, protégés par un mot de passe. Vous chargez le certificat public vers Entra (étape 4) et le `.p12` bundle vers Amazon S3 (étape 6). Sélectionnez l'onglet correspondant à votre système d'exploitation pour voir les commandes. **Note** Amazon Bedrock lit la clé privée du `.p12` bundle pour signer les assertions d'authentification. Le bundle doit donc être protégé par mot de passe et stocké en toute sécurité. Choisissez un mot de passe fort et aléatoire. Vous le stockez dans le secret comme `certificatePassword` à l'étape 7. ------ #### [ Linux or macOS (OpenSSL) ] **Génération d'une clé privée et d'un certificat auto-signé** ``` openssl req -x509 -newkey rsa:2048 -keyout private_key.pem -out certificate.cer \ -days 365 -nodes \ -subj "/CN={{bedrock-sharepoint-connector}}" ``` **Package du certificat et de la clé sous forme de bundle PKCS \#12 (`.p12`)** Entrez un mot de passe d'exportation robuste lorsque vous y êtes invité. Enregistrez-le pour l'étape 7. ``` openssl pkcs12 -export -out certificate.p12 \ -inkey private_key.pem -in certificate.cer ``` Vous disposez désormais de trois fichiers : la clé privée (`private_key.pem`), le certificat public (`certificate.cer`) et le bundle (`certificate.p12`). Vous chargez le certificat public sur Entra à l'étape 4 et le `.p12` bundle sur Amazon S3 à l'étape 6. ------ #### [ Windows (PowerShell) ] **Génération d'un certificat auto-signé** Les PowerShell commandes suivantes génèrent un certificat autosigné RSA de 2048 bits avec une période de validité d'un an et le stockent dans le magasin de certificats de l'utilisateur actuel. {{your-password}}Remplacez-le par un mot de passe fort et aléatoire. Vous le stockez dans le secret comme `certificatePassword` à l'étape 7. ``` $cert = New-SelfSignedCertificate ` -Subject "CN={{bedrock-sharepoint-connector}}" ` -CertStoreLocation "Cert:\CurrentUser\My" ` -KeyAlgorithm RSA ` -KeyLength 2048 ` -KeyExportPolicy Exportable ` -NotAfter (Get-Date).AddYears(1) ``` **Exporter le certificat public** ``` Export-Certificate -Cert $cert -FilePath certificate.cer -Type CERT ``` **Exportez le bundle PKCS \#12 (`.p12`)** ``` $password = ConvertTo-SecureString -String "{{your-password}}" -Force -AsPlainText Export-PfxCertificate -Cert $cert -FilePath certificate.p12 -Password $password ``` Vous avez maintenant deux fichiers : le certificat public (`certificate.cer`) et le bundle (`certificate.p12`). Vous chargez le certificat public sur Entra à l'étape 4 et le `.p12` bundle sur Amazon S3 à l'étape 6. ------ **Important** Stockez le `.p12` bundle dans Amazon S3 (et non dans le `.cer` fichier `.pem` or). Le bundle contient la clé privée qu'Amazon Bedrock utilise pour s'authentifier. Document-level le contrôle d'accès (ACL) nécessite le `.p12` format. Pour l'analyse du contenu uniquement sans ACL, vous pouvez stocker un PEM-encoded certificat à la place. Comme il `.p12` fonctionne pour toutes les configurations, ce guide l'utilise dans l'ensemble. `.p12` **Note** Le certificat est valide pendant un an par défaut. Un certificat expiré entraîne l'échec de toutes les synchronisations. Faites donc pivoter le certificat avant son expiration. Pour modifier la période de validité, ajustez l'`-days`option (OpenSSL) ou `-NotAfter` l'argument (). PowerShell Pour les étapes de rotation, voir[Faites pivoter le certificat](kb-managed-ds-sharepoint-troubleshooting.md#kb-managed-ds-sharepoint-rotate-cert). ## Étape 4 : Téléchargez le certificat public sur Entra 1. Lors de l'enregistrement de votre application, choisissez **Certificats et secrets**, puis l'onglet **Certificats**. 1. Choisissez **Télécharger le certificat** et sélectionnez le `certificate.cer` fichier que vous avez généré à l'étape 3 (le certificat public uniquement ; ne téléchargez jamais le `.p12` bundle ou la clé privée dans Entra). 1. Choisissez **Ajouter**. ## Étape 5 (Sites.Selected uniquement) : Accorder l'accès par site **Note** Cette étape s'applique uniquement si vous avez choisi l'étendue des `Sites.Selected` autorisations à l'étape 2. Si vous avez utilisé le champ d'application pour tous les sites (`Sites.Read.All`ou`Sites.FullControl.All`), passez à[Étape 6 : télécharger le certificat sur Amazon S3](#kb-managed-sharepoint-entra-step6). Avec`Sites.Selected`, vous accordez à votre application de connecteur l'accès à chaque SharePoint site individuellement via l'API Microsoft Graph. Cela nécessite une demande temporaire distincte qui contient `Sites.FullControl.All` et est utilisée uniquement pour exécuter les subventions. Amazon Bedrock ne voit jamais cette application temporaire ni ses informations d'identification. 1. **Créez une demande de subvention temporaire.** Dans le centre d'administration Entra, enregistrez une deuxième application (par exemple,`bedrock-sharepoint-granter`) en tant que client unique sans URI de redirection. Ajoutez l'autorisation d'`Sites.FullControl.All`application Microsoft Graph, accordez le consentement de l'administrateur et créez un secret client. Enregistrez son identifiant client et sa valeur secrète. 1. **Obtenez un jeton d'accès pour la demande de subvention.** Remplacez les espaces réservés par l'identifiant client et le code secret de l'application bénéficiaire, ainsi que par votre identifiant de locataire. ``` curl -s -X POST \ "https://login.microsoftonline.com/{{TENANT_ID}}/oauth2/v2.0/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "grant_type=client_credentials" \ -d "client_id={{GRANTER_CLIENT_ID}}" \ -d "client_secret={{GRANTER_CLIENT_SECRET}}" \ -d "scope=https://graph.microsoft.com/.default" ``` La réponse contient un`access_token`. Utilisez-le comme jeton porteur dans les commandes suivantes. 1. **Résolvez l'URL de chaque site en un identifiant de site.** Utilisez le nom d'hôte du site et le chemin relatif au serveur. ``` curl -s \ "https://graph.microsoft.com/v1.0/sites/{{contoso}}.sharepoint.com:/sites/{{engineering}}" \ -H "Authorization: Bearer {{ACCESS_TOKEN}}" ``` Le `id` champ de la réponse est l'ID du site. 1. **Accordez à l'application du connecteur l'accès au site.** `read`À utiliser pour l'analyse du contenu uniquement ou `fullcontrol` pour l'analyse des ACL. {{CONNECTOR\_CLIENT\_ID}}Remplacez-le par l'ID de l'application (client) indiqué à l'étape 1. ``` curl -s -X POST \ "https://graph.microsoft.com/v1.0/sites/{{SITE_ID}}/permissions" \ -H "Authorization: Bearer {{ACCESS_TOKEN}}" \ -H "Content-Type: application/json" \ -d '{ "roles": ["{{fullcontrol}}"], "grantedToIdentities": [{ "application": { "id": "{{CONNECTOR_CLIENT_ID}}", "displayName": "{{bedrock-sharepoint-connector}}" } }] }' ``` 1. Répétez les commandes resolve-and-grant pour chaque site que vous incluez dans la source de données. Une fois que vous avez terminé, vous pouvez supprimer la demande de subvention temporaire ; les subventions par site restent en vigueur. **Important** Per-site les subventions ne sont pas rétroactives. Si vous ajoutez un site à la source de données ultérieurement, accordez à l'application du connecteur l'accès à ce site avant la prochaine synchronisation, sinon son contenu ne sera pas analysé. ## Étape 6 : télécharger le certificat sur Amazon S3 Téléchargez le `.p12` bundle de l'étape 3 vers un compartiment Amazon S3 situé dans la même AWS région que votre base de connaissances. Enregistrez le nom et la clé du compartiment : vous les utilisez comme source de données`certificateS3Path`. ``` aws s3api put-object \ --bucket {{your-certificate-bucket}} \ --key {{certs/certificate.p12}} \ --body certificate.p12 \ --server-side-encryption AES256 ``` **Note** Nous vous recommandons d'activer le chiffrement côté serveur sur l'objet de certificat et de limiter le compartiment aux principaux qui en ont besoin. Le bundle contient la clé privée. ## Étape 7 : Création du secret du Gestionnaire de Secrets Conservez les informations d'identification dans un AWS Secrets Manager secret. Pour l' App-Only authentification Entra ID, incluez les paires clé-valeur suivantes : + `clientId`(obligatoire) : l'ID de l'application (client) indiqué à l'étape 1. + `certificatePassword`(recommandé) : le mot de passe que vous avez défini sur le `.p12` pack à l'étape 3. Voir la note qui suit. ``` { "clientId": "{{your-client-id}}", "certificatePassword": "{{your-certificate-password}}" } ``` Créez le secret avec AWS Command Line Interface : ``` aws secretsmanager create-secret \ --name {{bedrock-sharepoint-creds}} \ --secret-string file://secret.json ``` Enregistrez l'ARN secret de la réponse. Vous l'utilisez comme source de données`secretArn`. **Note** Définissez le mot `certificatePassword` de passe que vous avez utilisé lors de la création du `.p12` bundle à l'étape 3. Si vous omettez ce champ, Amazon Bedrock ouvre le bundle en utilisant l'ID client de votre application comme mot de passe. Le bundle doit donc avoir été créé avec l'ID client comme mot de passe. Nous vous recommandons de toujours définir un mot de passe explicite à entropie élevée et de stocker la clé privée en toute sécurité. **Note** **Utiliser plutôt un certificat PEM.** Ce guide utilise un `.p12` bundle qui fonctionne pour toutes les configurations. Si vous analysez uniquement le contenu (aucun contrôle d'accès au niveau du document), vous pouvez utiliser un certificat PEM à la place. Dans ce cas, téléchargez uniquement le certificat *public* sur Amazon S3 (pas un `.p12` bundle) et stockez la clé privée dans le secret sous la forme `privateKey` (PKCS \#8 non crypté codé en base64, sans ligne d'en-tête) à la place de : `certificatePassword` ``` { "clientId": "{{your-client-id}}", "privateKey": "{{your-base64-pkcs8-private-key}}" } ``` ## Étape 8 : Accorder au rôle de service l'accès au certificat Votre rôle de service de base de connaissances doit être capable de lire l'objet de certificat depuis Amazon S3. Ajoutez la déclaration suivante à la politique d'autorisation du rôle, en remplaçant le nom du compartiment et la clé par vos valeurs. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "S3ListCertificateBucket", "Effect": "Allow", "Action": ["s3:ListBucket"], "Resource": ["arn:aws:s3:::{{your-certificate-bucket}}"], "Condition": { "StringEquals": { "aws:ResourceAccount": ["{{123456789012}}"] } } }, { "Sid": "S3GetCertificate", "Effect": "Allow", "Action": ["s3:GetObject"], "Resource": [ "arn:aws:s3:::{{your-certificate-bucket}}/{{certs/certificate.p12}}", "arn:aws:s3:::{{your-certificate-bucket}}/{{certs/certificate.p12}}.metadata.json" ], "Condition": { "StringEquals": { "aws:ResourceAccount": ["{{123456789012}}"] } } } ] } ``` **Note** La politique autorise également l'accès en lecture à un `.metadata.json` fichier facultatif à côté du certificat. Amazon Bedrock n'a pas besoin de ce fichier ; l'inclusion de cette autorisation permet d'éviter les erreurs d'accès en cas de présence d'une telle autorisation. **Si l'objet du certificat est chiffré avec une clé AWS KMS** La commande de téléchargement [Étape 6 : télécharger le certificat sur Amazon S3](#kb-managed-sharepoint-entra-step6) utilise Amazon S3-managed encryption (`AES256`), qui ne nécessite aucune autorisation supplémentaire. Si vous chiffrez plutôt l'objet du certificat avec le chiffrement côté serveur Amazon S3 à l'aide d'une clé KMS gérée par le client (SSE-KMS), le rôle de service doit également disposer d'une `kms:Decrypt` autorisation sur cette clé, et la politique de la clé doit autoriser le rôle à l'utiliser. Les objets chiffrés AWS à l'aide de la `aws/s3` clé gérée ne nécessitent pas cette autorisation supplémentaire. ``` { "Sid": "KmsDecryptCertificate", "Effect": "Allow", "Action": ["kms:Decrypt"], "Resource": ["arn:aws:kms:{{us-west-2}}:{{123456789012}}:key/{{your-key-id}}"] } ``` L'accès en lecture est uniquement requis`kms:Decrypt`. Pour plus d'informations, consultez la section [Utilisation du chiffrement côté serveur avec des clés AWS KMS () SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html). Pour obtenir l'ensemble complet des autorisations relatives aux rôles de service de la base de connaissances, consultez[Autorisations d’accès aux sources de données](kb-permissions.md#kb-permissions-access-ds). ## Étapes suivantes Vous disposez désormais de tout ce dont vous avez besoin pour créer la source de données : l'ARN secret, votre identifiant de locataire et l'emplacement du certificat sur Amazon S3. Pour créer la source de SharePoint données à l'aide de l'API AWS Management Console ou de l'API, consultez[Connecter une source SharePoint de données](kb-managed-ds-sharepoint-connect.md). **Important** Pour `ENTRA_ID_APP_ONLY` l'authentification, vous devez le fournir `certificateS3Path` lorsque vous créez la source de données, même lorsque les ACL sont désactivées. Une source de SharePoint données créée avec ce type d'authentification sans certificat échoue.