Cấu hình Azure AD và SharePoint cho các định danh được quản lý

Làm việc với Azure AD, SharePoint và Power Platform Nó ngày càng đòi hỏi mức độ bảo mật cao hơn và cấu hình chi tiết hơn so với trước đây. Khi muốn tự động hóa các quy trình như quản lý tài liệu, tích hợp Dataverse, hoặc chuẩn bị nền tảng để tạo và quản lý người dùng trong Azure AD từ dữ liệu SharePoint, việc chỉ sử dụng thông tin đăng nhập cũ không còn đủ nữa.

Kể từ tháng 3 năm 2025, Microsoft đã thắt chặt cách thức truy cập vào... Bảng tài liệu SharePoint từ Dynamics 365 và các ứng dụng hướng mô hìnhđặc biệt khi việc truy cập được thực hiện từ Power Automate hoặc các lệnh gọi API của Dataverse. Điều này ngụ ý rằng chúng ta cần sử dụng một ứng dụng được đăng ký với Azure, danh tính được quản lý, và thông tin xác thực liên kết để tiếp tục làm việc an toàn và không bị gián đoạn.

Ngữ cảnh: Tại sao bạn cần một ứng dụng Azure để truy cập SharePoint

Khi một giải pháp kinh doanh trong Dynamics 365 hoặc Power Platform sử dụng Bảng tài liệu SharePointThông thường, việc này được thực hiện bên ngoài lưới tài liệu cổ điển của một ứng dụng hướng mô hình. Nói cách khác, SharePoint được truy cập từ... Các luồng Power Automate, plugin, trình kết nối tùy chỉnh hoặc các lệnh gọi trực tiếp đến API Dataverse. Những nơi này đòi hỏi giấy phép nghiêm ngặt đối với các địa điểm và thư viện.

Cho đến gần đây, quyền truy cập này có thể tận dụng các cơ chế cũ ít nghiêm ngặt hơn, nhưng Microsoft đã quyết định Xóa quyền truy cập đó vào tháng 3 năm 2025. Để tăng cường bảo vệ môi trường. Trên thực tế, nếu bạn không chuẩn bị cấu hình mới, bạn có thể gặp phải các quy trình làm việc ngừng hoạt động, các tích hợp không còn đọc hoặc ghi tài liệu, hoặc các quy trình tự động hóa bắt đầu gặp lỗi mà không có cảnh báo.

Giải pháp bao gồm việc tạo và cấu hình một... Ứng dụng trên Azure (Microsoft Entra ID) đóng vai trò là định danh tập trung cho các tích hợp, gán cho nó các quyền SharePoint phù hợp và liên kết nó với Dataverse bằng cách sử dụng danh tính được quản lý và thông tin xác thực liên kếtTất cả những điều này sẽ cho phép bạn tiếp tục chạy các quy trình tự động hóa, ví dụ như đọc danh sách SharePoint, quản lý tài liệu, hoặc thậm chí làm cơ sở cho các quy trình tạo hoặc quản lý người dùng trong Azure AD dựa trên thông tin đó.

Đăng ký ứng dụng trong Azure với quyền truy cập vào SharePoint.

Trụ cột đầu tiên của thiết lập này là đăng ký một Ứng dụng trên Azure (Microsoft Entra ID) Ứng dụng này sẽ đại diện cho các quy trình tự động hóa của bạn khi chúng cần giao tiếp với SharePoint. Nó sẽ hoạt động với quyền ứng dụng (không phải quyền được ủy quyền), vì vậy nó có thể hoạt động độc lập với người dùng đã đăng nhập.

Để bắt đầu, hãy nhập Cổng thông tin Azure Với tài khoản có quyền quản lý nhật ký ứng dụng và cài đặt ID Entra. Sau khi đăng nhập, hãy vào phần... "Nhật ký ứng dụng"Thông tin này thường hiển thị trong ID đăng nhập Microsoft hoặc trực tiếp trong "Dịch vụ Azure". Đây là nơi bạn sẽ tạo danh tính mà Dataverse sẽ sử dụng để truy cập SharePoint.

Bấm vào "Đăng ký mới" và đặt một tên dễ nhận biết cho ứng dụng, để dễ dàng xác định đó là ứng dụng quản lý xác thực với SharePoint (ví dụ: một cái tên gợi liên tưởng đến Power Platform hoặc tổ chức). Trong phần của "Các loại tài khoản được hỗ trợ"Chọn tùy chọn hạn chế quyền truy cập vào "Bạn chỉ có tài khoản trong thư mục tổ chức này."Vì ứng dụng sẽ hoạt động trong phạm vi người dùng cụ thể của bạn.

Sau khi hoàn tất trình hướng dẫn, hãy nhấp vào "Đăng ký" Để hoàn tất việc tạo ứng dụng. Trên màn hình tóm tắt của ứng dụng đã đăng ký, trong phần... "Thông tin cơ bản" hoặc "Những điều cần thiết"Bạn sẽ thấy hai giá trị quan trọng: "Mã định danh ứng dụng (khách hàng)" và "Mã định danh thư mục (người thuê)"Các mã định danh GUID này sẽ rất quan trọng sau này để liên kết ứng dụng với Dataverse và cấu hình các danh tính được quản lý.

Hãy ghi chép lại và cất giữ cẩn thận. Mã định danh ứng dụng (clientId) và Mã định danh thư mục (tenantId)Vì bạn sẽ sử dụng cả hai khi tạo bản ghi danh tính được quản lý trong Dataverse và khi xác định thông tin xác thực liên kết sẽ tạo ra mã thông báo chính xác cho SharePoint.

Tiếp theo, bạn cần cấp cho ứng dụng các quyền phù hợp trên... API SharePointTrong menu điều hướng của ứng dụng, hãy truy cập vào... "Quyền truy cập API" và chọn tùy chọn "Thêm quyền"Chọn dịch vụ SharePoint Và khi được hỏi về loại giấy phép, Mark đã trả lời. "Quyền ứng dụng"Đó là những yếu tố cho phép ứng dụng hoạt động tự động mà không cần sự tương tác của người dùng.

Trong danh sách các quyền có sẵn, hãy tìm và chọn "Sites.FullControl.All"Quyền này cấp cho ứng dụng toàn quyền kiểm soát tất cả các trang SharePoint trong tenant, điều này hữu ích trong các trường hợp Power Platform quản lý chuyên sâu các tài liệu, thư mục và siêu dữ liệu. Sau khi chọn, hãy nhấp vào "Thêm quyền" Để tích hợp nó vào ứng dụng.

Với quyền hạn được bổ sung, bước quan trọng vẫn còn thiếu: cấp quyền sự đồng ý của quản trị viênTrên cùng màn hình cấp quyền, bạn sẽ thấy tùy chọn để "Cấp quyền cho người quản trị »Hãy thực hiện thao tác này bằng tài khoản có quyền quản trị toàn cầu hoặc tương đương, để quyền truy cập SharePoint được kích hoạt và ứng dụng có thể sử dụng quyền đó trong môi trường sản xuất.

Tạo danh tính được quản lý trong Dataverse

Sau khi ứng dụng Azure đã sẵn sàng và có quyền truy cập chính xác trên SharePoint, bước tiếp theo là kết nối danh tính đó với Dataverse thông qua hồ sơ định danh được quản lýĐiều này cho phép môi trường Power Platform tự sử dụng ứng dụng đó để tạo mã thông báo và truy cập SharePoint một cách an toàn.

Quá trình này được thực hiện bằng cách tạo các bản ghi trong các bảng nội bộ của Dataverse, cụ thể là trong bảng. "nhận dạng được quản lý"Điều này thể hiện mỗi danh tính được quản lý liên kết với một môi trường. Để làm điều này, bạn có thể sử dụng API Web DataverseSử dụng các công cụ như Postman, Insomnia hoặc bất kỳ trình khách HTTP nào giúp dễ dàng gửi các yêu cầu đã được xác thực.

Trong bàn managedidentity Bạn cần chèn một hàng mới với một loạt các trường cụ thể. Trường applicationid phải chứa GUID của Mã định danh ứng dụng (khách hàng) mà bạn nhận được khi đăng ký ứng dụng trên Azure. Trong khi đó, trường tenantid sẽ lưu trữ GUID của Mã định danh thư mục (người thuê) từ cùng một hồ sơ ứng tuyển.

Ngoài các mã định danh này, còn có các trường cấu hình khác xác định loại và phạm vi thông tin xác thực. credentialsource bạn phải đặt giá trị 2, điều này cho thấy một nguồn thông tin xác thực được quản lý (IsManaged) thông qua nền tảng. Tại hiện trường subjectscope Giá trị này nên được sử dụng. 1, tương ứng với một Loại phạm vi EnvironmentScopeTức là, được liên kết với một môi trường Dataverse cụ thể.

Yêu cầu HTTP gửi đến API web của Dataverse sẽ có dạng như sau: POST đến URL [Organization URI]/api/data/v9.2/managedidentitiesVới các tiêu đề OData thông thường (ví dụ: Content-Type application/json, OData-MaxVersion 4.0, v.v.) và phần thân JSON tương tự như thế này, được điều chỉnh cho phù hợp với các giá trị thực tế của bạn:

POST [Organization URI]/api/data/v9.2/managedidentities
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
Accept: application/json
{
"applicationid": "<appId>",
"credentialsource": 2,
"subjectscope": 1,
"tenantid": "<tenantId>"
}

Nếu mọi việc diễn ra suôn sẻ, API sẽ trả về phản hồi. HTTP 204 Không có nội dung, kèm theo tiêu đề OData-EntityId bao gồm URL của bản ghi mới được tạo. Trong URL đó, bạn sẽ thấy một GUID tương ứng với... managedidentityid, Cái gì đó như aaaaaaaa-0000-1111-2222-bbbbbbbbbbbbHãy lưu lại mã định danh đó vì bạn sẽ cần nó để liên kết với danh tính được quản lý cụ thể của SharePoint.

Liên kết danh tính được quản lý của SharePoint trong Dataverse

Sau khi cơ sở dữ liệu định danh được quản lý được tạo trong bảng. managedidentity, cần phải liên kết nó với một mục nhập thuộc loại Danh tính được quản lý bởi SharePointngười sống trên bàn sharepointmanagedidentityĐây là phần kết nối rõ ràng giữa Dataverse và việc sử dụng SharePoint thông qua định danh đó.

Để làm điều này, bạn cần chèn một hàng mới vào bảng. sharepointmanagedidentity sử dụng lại, API Web Dataverse. Cánh đồng uniquename Nó phải chứa một tên duy nhất trong môi trường, ví dụ: "new_ppmiforsharepointauth"Điều này cho thấy rõ ràng rằng danh tính này được dùng để xác thực với SharePoint.

Trong lĩnh vực name Bạn có thể sử dụng nhãn mô tả và thân thiện, chẳng hạn như: "Identidad administrada para la autenticación de SharePoint" hoặc tương tự, cho phép bạn nhanh chóng định vị nó bằng các công cụ quản trị hoặc tập lệnh.

Điều quan trọng nhất là mối quan hệ với bản ghi định danh được quản lý cơ bản mà bạn đã tạo trước đó. Việc này được thực hiện bằng cách sử dụng trường liên kết. ManagedIdentityId@odata.bind, giá trị của nó nên hướng đến nguồn lực /managedidentities(<managedidentityid>), thay thế <managedidentityid> Dựa trên GUID được trả về trước đó khi tạo danh tính được quản lý.

Yêu cầu gửi đến API web của Dataverse sẽ trông giống như thế này, một lần nữa sử dụng POST Nhưng giờ đây, dựa vào bàn. sharepointmanagedidentities:

POST [Organization URI]/api/data/v9.2/sharepointmanagedidentities
Content-Type: application/json; charset=utf-8
OData-MaxVersion: 4.0
OData-Version: 4.0
Accept: application/json
{
"uniquename": "new_ppmiforsharepointauth",
"name": "Managed Identity For SharePoint Auth",
"ManagedIdentityId@odata.bind": "/managedidentities(<managedidentityid>)"
}

Như trước đây, câu trả lời sẽ là HTTP 204 Không có nội dung với tiêu đề OData-EntityId chỉ vào đăng ký mới, ví dụ sharepointmanagedidentities(bbbbbbbb-1111-2222-3333-cccccccccccc)GUID đó là sharepointmanagedidentityidĐây là mã định danh cần thiết để bạn xây dựng mã định danh chủ thể cho chứng chỉ liên kết trong Azure.

Cấu hình thông tin xác thực liên kết trong ứng dụng Azure

Sau khi ứng dụng đã được đăng ký trong Azure và các định danh được quản lý đã được tạo trong Dataverse, bước quan trọng cuối cùng là cấu hình... chứng chỉ liên kết Trong quá trình đăng ký của ứng dụng. Thông tin xác thực này cho phép Power Platform trao đổi mã thông báo một cách an toàn với Azure AD, sử dụng mối quan hệ được thiết lập với danh tính được quản lý và SharePoint.

Để cấu hình, hãy quay lại phần trước. Cổng thông tin Azure và truy cập ID đầu vào của MicrosoftTrong menu, hãy vào "Nhật ký ứng dụng" Tìm bản ghi cụ thể mà bạn đã tạo để quản lý quyền truy cập vào SharePoint. Mở bản ghi đó để chỉnh sửa cài đặt xác thực và chứng chỉ.

Trong bảng điều khiển bên cạnh của trình đăng ký, nhập "Chứng chỉ và bí mật"và sau đó chuyển đến tab của "Chứng chỉ liên kết"Tại đó bạn sẽ có tùy chọn để "Thêm thông tin đăng nhập"Đây là nơi bạn sẽ xác định cả bên phát hành và chủ thể đại diện cho Dataverse.

Trong lĩnh vực "Phong cảnh" Đối với thông tin xác thực liên kết, hãy chọn "Một tổ chức phát hành khác"Vì bạn sẽ tự chỉ định cả URL người gửi và mẫu định danh chủ thể, điều này mang lại cho bạn sự linh hoạt để khớp chính xác cấu hình mà Power Platform yêu cầu cho các định danh được quản lý bởi SharePoint.

Trong lĩnh vực "Máy phát" Bạn phải viết URL theo định dạng sau: https://login.microsoftonline.com/<tenantId>/v2.0, thay thế <tenantId> bằng GUID của Mã định danh thư mục (người thuê) Từ ứng dụng Azure của bạn. URL đó đại diện cho điểm phát hành mã thông báo Azure AD cho người thuê của bạn.

Lĩnh vực trọng tâm là lĩnh vực của "Giá trị", nơi mà mã định danh đối tượng sẽ được sử dụng trong mối quan hệ liên kết. Định dạng dự kiến ​​là một chuỗi có dạng:
/eid1/c/pub/t/<base64-encoded-tenantId>/a/<base64-encoded-appid>/Env/<orgid>/sharepointmanagedidentity/<sharepointmanagedidentityid>

Trong cấu trúc đó, tenantId được mã hóa Base64 an toàn cho URL Được đặt trong <base64-encoded-tenantId>và mã định danh ứng dụng Power Platform đóng vai trò là Danh tính được quản lý (một AppId cụ thể do Microsoft cung cấp) cũng được mã hóa Base64. <base64-encoded-appid>. Ngoài ra, <orgid> là GUID của môi trường hoặc tổ chức Dataverse, trong khi <sharepointmanagedidentityid> tương ứng với GUID của mục được tạo trong bảng. sharepointmanagedidentity.

Sau khi điền đầy đủ thông tin, hãy nhấp vào "Thêm vào" Để tạo thông tin xác thực liên kết. Từ thời điểm đó trở đi, danh tính được quản lý bởi Dataverse liên kết với SharePoint sẽ có thể lấy mã thông báo thông qua cấu hình này, cho phép các luồng, plugin hoặc tích hợp bên ngoài truy cập vào bảng tài liệu SharePoint một cách có kiểm soát và an toàn.

Tạo mã định danh đối tượng bằng PowerShell

Lắp ráp chuỗi bằng tay Tiêu đề Đối với thông tin xác thực liên kết, điều này có thể khá rắc rối, đặc biệt là vì nó liên quan đến việc mã hóa GUID thành Base64 một cách an toàn cho URL và tuân thủ một cấu trúc rất cụ thể. Để đơn giản hóa nhiệm vụ này, bạn có thể sử dụng một Tập lệnh PowerShell Điều này tự động tạo ra cả mã định danh đối tượng và các giá trị liên quan khác.

Đoạn mã được đề xuất định nghĩa một hàm có tên là GetSharePointManagedIdentifyConfig, nhận một số tham số bắt buộc: loại môi trường (EnvironmentType), GUID của Danh tính được quản lý của SharePoint (SharePointManagedIdentityId), tenantId và EnvironmentId Liên quan đến môi trường Dataverse nơi bạn áp dụng cấu hình.

Tham số Loại môi trường Đây chắc hẳn là một trong những giá trị được kịch bản nhận biết: Public, Gov, GovFR, High, DoD, MoonCake, USNat o USSecMỗi loại đều gắn liền với một tổ hợp khác nhau của các thành phần. URL của nhà phát hành và URL tài nguyên trao đổi tokenvì các đám mây độc lập và khu vực khác nhau sử dụng các điểm cuối xác thực khác nhau.

Trong kịch bản, một hàm nội bộ được khai báo và gọi là Convert-ToBase64Url, chịu trách nhiệm chuyển đổi GUID thành phiên bản mã hóa của nó trong URL an toàn Base64Quy trình này chuyển đổi GUID thành mảng byte, mã hóa nó thành Base64 và loại bỏ các ký tự đệm (=) và thay thế các ký tự + y / qua - y _ Tương ứng, nhờ đó đảm bảo kết quả hợp lệ để sử dụng trong URL.

Đoạn mã cũng định nghĩa một hằng số với Power Platform Managed Identity AppId, 58e835ab-2e39-46a9-b797-accce6633447Đây là mã định danh được Dataverse sử dụng cho các tích hợp này. Giá trị này cũng được chuyển qua hàm mã hóa Base64 an toàn cho URL để phù hợp với chuỗi chủ thể cuối cùng.

Cấu hình môi trường được quản lý thông qua một danh sách ($environmentConfigList) gán cho mỗi nhóm môi trường một IssuerUrl, One TokenExchangeResourceUrl và một Tiền tố chủ đềVí dụ, đối với các môi trường thuộc loại Public, Gov y GovFR bộ phát được sử dụng https://login.microsoftonline.com/ và tiền tố chủ ngữ /eid1/c/pubtrong khi đó đối với môi trường loại High o DoD Được sử dụng https://login.microsoftonline.us/ với tiền tố khác.

Khi bạn gọi hàm GetSharePointManagedIdentifyConfigQuá trình này tìm kiếm cấu hình phù hợp theo... Loại môi trường được cung cấp, xây dựng URL của nhà phát hành nối tenantId và hậu tố lại với nhau. /v2.0và mã hóa tenantId và managed AppId dưới dạng Base64. Với tất cả những điều đó, nó tạo ra chuỗi chủ thể theo mẫu sau:
{SubjectPrefix}/t/{encodedTenantId}/a/{encodedAppId}/Env/{EnvironmentId}/sharepointmanagedidentity/{SharePointManagedIdentityId}

Hàm này trả về kết quả được định dạng bao gồm dữ liệu đầu vào, các giá trị đã tính toán và cuối cùng là... URL chủ thể cho cấu hình thông tin xác thực liên kếtGiá trị cuối cùng đó là giá trị bạn nên sao chép và dán vào trường "Giá trị" khi tạo thông tin xác thực liên kết trong ứng dụng Azure.

Để sử dụng tập lệnh, trước tiên hãy lưu nó lại dưới dạng GetSharePointManagedIdentifyConfig.ps1 và sau đó bạn tạo một kịch bản thứ hai test.ps1 Nhập nó và cung cấp các tham số thích hợp. test.ps1 Cấu trúc bảng băm như thế này thường được sử dụng:

. .\GetSharePointManagedIdentifyConfig.ps1
$configInput = @{
environmentType = "<environmentType>"
sharePointManagedIdentityId = "<sharePointManagedIdentityId>"
tenantId = "<tenantId>"
environmentId = "<environmentId>"
}
GetSharePointManagedIdentifyConfig @configInput

Khi chạy test.ps1Bạn sẽ thấy kết quả đầu ra bao gồm dữ liệu đầu vào, ID đã mã hóa, tổ chức phát hành đã tính toán và kết quả cuối cùng. URL chủ đềGiá trị cuối cùng đó là giá trị được sử dụng trong chứng chỉ liên kết; ví dụ, một cái gì đó tương tự như:
/eid1/c/pub/t/u7uqqgAAzMwREd3dIiLu7g/a/qzXoWDkuqUa3l6zM5mM0Rw/Env/a0a0a0a0-bbbb-cccc-dddd-e1e1e1e1e1e1/sharepointmanagedidentity/bbbbbbbb-1111-2222-3333-cccccccccccc

Với sự kết hợp này Ứng dụng Azure với quyền truy cập SharePoint, danh tính được quản lý trong Dataverse và thông tin xác thực liên kết được cấu hình cẩn thận.Bạn đã có một nền tảng vững chắc phù hợp với các yêu cầu bảo mật mới nhất của Microsoft. Từ đó, bạn có thể thiết kế các quy trình làm việc và giải pháp tận dụng danh sách và tài liệu SharePoint làm nguồn dữ liệu cho các quy trình nâng cao (bao gồm tạo và quản lý người dùng trong Azure AD), đồng thời đảm bảo rằng quá trình xác thực được xử lý tốt, có khả năng mở rộng và đáp ứng các yêu cầu bảo mật của môi trường hiện đại.