Tweet
Trong Azure, trước khi nói đến Virtual Machine, Storage hay Virtual Network, có một câu hỏi rất quan trọng cần giải quyết: Ai được phép đăng nhập và người đó được phép làm gì?
Lab 01 của AZ-104 tập trung vào nền tảng đó: quản lý Identity trong Microsoft Entra ID, tên gọi hiện nay của Azure Active Directory (Azure AD).
Thời gian thực hành dự kiến: 30 phút. Bối cảnh của bài Lab
Giả sử Contoso cần cho nhân viên sử dụng Microsoft Entra ID để xác thực và truy cập các tài nguyên Cloud.
Administrator được giao các yêu cầu:
Qua một bài Lab khá ngắn, chúng ta có thể thực hành nhiều khái niệm Identity quan trọng của Azure. Task 1: Tạo và cấu hình User
Đầu tiên, chúng ta tạo các Cloud User trong tenant mặc định.
Ví dụ:
az104-01a-aaduser1
Tài khoản được cấu hình:
Job title: Cloud Administrator
Department: IT
và được gán role:
User Administrator
User Administrator là một Microsoft Entra role cho phép thực hiện các tác vụ quản trị người dùng phù hợp với phạm vi quyền của role.
User thứ hai:
az104-01a-aaduser2
được cấu hình:
Job title: System Administrator
Department: IT
Điểm cần chú ý ở đây là các thuộc tính như Job Title và Department không đơn thuần chỉ là thông tin hồ sơ. Chúng có thể được sử dụng làm điều kiện để tự động hóa việc quản lý Identity. Task 2: Assigned Group và Dynamic Group
Tiếp theo, chúng ta tạo các Group với hai cơ chế membership quan trọng.
Assigned membership nghĩa là Administrator chủ động thêm hoặc xóa thành viên.
Ví dụ:
IT Lab Administrators
Ngược lại, Dynamic User membership cho phép Microsoft Entra ID tự động xác định thành viên dựa trên thuộc tính của User.
Ví dụ có thể xây dựng rule theo logic:
jobTitle = Cloud Administrator
Khi đó user có Job Title phù hợp sẽ tự động trở thành thành viên của nhóm IT Cloud Administrators.
Tương tự:
jobTitle = System Administrator
có thể được sử dụng để đưa người dùng vào IT System Administrators.
Điểm thú vị là khi nhân viên thay đổi vị trí công việc và thuộc tính của họ được cập nhật, membership có thể được hệ thống tự động đánh giá lại.
Thay vì:
Admin → tìm User → tìm Group → Add Member
chúng ta chuyển sang:
Thuộc tính User → Dynamic Rule → Group Membership
Đây là một ví dụ rất rõ về tự động hóa Identity Management. Task 3: Tạo một Microsoft Entra Tenant mới
Bài Lab tiếp tục bằng việc tạo một tenant riêng:
Contoso Lab
Trong tenant này, chúng ta tạo Cloud User:
az104-01b-aaduser1
với:
Job title: System Administrator
Department: IT
Đây cũng là lúc cần hiểu rõ khái niệm Tenant.
Microsoft Entra tenant là một instance riêng biệt của Microsoft Entra ID, đại diện cho một tổ chức và chứa các đối tượng như Users, Groups, Applications, Devices và các cấu hình Identity liên quan.
Một Azure Administrator thường xuyên phải phân biệt rõ:
Microsoft Entra tenant ≠ Azure subscription
Tenant liên quan đến Identity, trong khi Subscription chủ yếu là phạm vi quản lý, thanh toán và tổ chức Azure resources. Giữa hai khái niệm có mối liên hệ, nhưng chúng không phải là một. Task 4: Quản lý Guest User
Đây là phần khá hay của bài Lab.
User az104-01b-aaduser1 thuộc tenant Contoso Lab, nhưng chúng ta muốn người này cộng tác hoặc truy cập tài nguyên của tenant chính.
Không cần tạo thêm một danh tính hoàn toàn độc lập trong tenant chính.
Thay vào đó, chúng ta có thể mời tài khoản đó dưới dạng:
Guest User
Đây là một tình huống điển hình của Microsoft Entra External ID/B2B collaboration.
Guest User sau đó có thể được thêm vào Group:
IT Lab Administrators
và được cấp quyền phù hợp.
Mô hình này rất thực tế khi doanh nghiệp cần làm việc với:
Thay vì chia sẻ tài khoản nội bộ, doanh nghiệp có thể cho người bên ngoài sử dụng danh tính của họ và kiểm soát quyền truy cập vào tài nguyên của mình. Kiến trúc của Lab
Có thể hình dung toàn bộ bài thực hành theo luồng:
Default Microsoft Entra tenant
→ Tạo Cloud Users
→ Cấu hình thuộc tính User
→ Tạo Assigned/Dynamic Groups
→ Gán Microsoft Entra role
Sau đó:
New tenant: Contoso Lab
→ Tạo User thử nghiệm
→ Mời User sang tenant chính dưới dạng Guest
→ Đưa Guest vào Group
→ Kiểm soát quyền truy cập
Chỉ trong khoảng 30 phút, bài Lab đã kết nối khá nhiều khái niệm quan trọng của Microsoft Entra ID: User, Group, Role, Dynamic Membership, Tenant và Guest Identity. Điều quan trọng nhất cần rút ra
Quản trị Identity hiệu quả không phải là tạo thật nhiều User rồi cấp quyền thủ công cho từng người.
Một thiết kế tốt sẽ hướng đến:
User attributes → Groups → Roles/Permissions → Resources
Khi kết hợp thêm Dynamic Group và Role-Based Access Control (RBAC), chúng ta có thể giảm đáng kể công việc quản trị thủ công và áp dụng nguyên tắc Least Privilege tốt hơn.
Đây cũng chính là nền tảng mà một Azure Administrator cần nắm chắc trước khi đi sâu hơn vào quản trị tài nguyên Azure.
Lab repository chính thức của khóa AZ-104:
#AZ104 #MicrosoftEntraID azuread #AzureAdministrator #Identity #AzureRBAC #CloudSecurity #MicrosoftAzure MCSA vnpro #MCSAAzureAWS
Lab 01 của AZ-104 tập trung vào nền tảng đó: quản lý Identity trong Microsoft Entra ID, tên gọi hiện nay của Azure Active Directory (Azure AD).
Thời gian thực hành dự kiến: 30 phút. Bối cảnh của bài Lab
Giả sử Contoso cần cho nhân viên sử dụng Microsoft Entra ID để xác thực và truy cập các tài nguyên Cloud.
Administrator được giao các yêu cầu:
- Provision các User Account.
- Tạo và quản lý Group.
- Tự động cập nhật thành viên Group dựa trên Job Title.
- Tạo thêm một Microsoft Entra tenant dùng cho Lab.
- Tạo tài khoản thử nghiệm trong tenant mới.
- Mời tài khoản đó quay trở lại tenant chính dưới dạng Guest User và cấp quyền phù hợp.
Qua một bài Lab khá ngắn, chúng ta có thể thực hành nhiều khái niệm Identity quan trọng của Azure. Task 1: Tạo và cấu hình User
Đầu tiên, chúng ta tạo các Cloud User trong tenant mặc định.
Ví dụ:
az104-01a-aaduser1
Tài khoản được cấu hình:
Job title: Cloud Administrator
Department: IT
và được gán role:
User Administrator
User Administrator là một Microsoft Entra role cho phép thực hiện các tác vụ quản trị người dùng phù hợp với phạm vi quyền của role.
User thứ hai:
az104-01a-aaduser2
được cấu hình:
Job title: System Administrator
Department: IT
Điểm cần chú ý ở đây là các thuộc tính như Job Title và Department không đơn thuần chỉ là thông tin hồ sơ. Chúng có thể được sử dụng làm điều kiện để tự động hóa việc quản lý Identity. Task 2: Assigned Group và Dynamic Group
Tiếp theo, chúng ta tạo các Group với hai cơ chế membership quan trọng.
Assigned membership nghĩa là Administrator chủ động thêm hoặc xóa thành viên.
Ví dụ:
IT Lab Administrators
Ngược lại, Dynamic User membership cho phép Microsoft Entra ID tự động xác định thành viên dựa trên thuộc tính của User.
Ví dụ có thể xây dựng rule theo logic:
jobTitle = Cloud Administrator
Khi đó user có Job Title phù hợp sẽ tự động trở thành thành viên của nhóm IT Cloud Administrators.
Tương tự:
jobTitle = System Administrator
có thể được sử dụng để đưa người dùng vào IT System Administrators.
Điểm thú vị là khi nhân viên thay đổi vị trí công việc và thuộc tính của họ được cập nhật, membership có thể được hệ thống tự động đánh giá lại.
Thay vì:
Admin → tìm User → tìm Group → Add Member
chúng ta chuyển sang:
Thuộc tính User → Dynamic Rule → Group Membership
Đây là một ví dụ rất rõ về tự động hóa Identity Management. Task 3: Tạo một Microsoft Entra Tenant mới
Bài Lab tiếp tục bằng việc tạo một tenant riêng:
Contoso Lab
Trong tenant này, chúng ta tạo Cloud User:
az104-01b-aaduser1
với:
Job title: System Administrator
Department: IT
Đây cũng là lúc cần hiểu rõ khái niệm Tenant.
Microsoft Entra tenant là một instance riêng biệt của Microsoft Entra ID, đại diện cho một tổ chức và chứa các đối tượng như Users, Groups, Applications, Devices và các cấu hình Identity liên quan.
Một Azure Administrator thường xuyên phải phân biệt rõ:
Microsoft Entra tenant ≠ Azure subscription
Tenant liên quan đến Identity, trong khi Subscription chủ yếu là phạm vi quản lý, thanh toán và tổ chức Azure resources. Giữa hai khái niệm có mối liên hệ, nhưng chúng không phải là một. Task 4: Quản lý Guest User
Đây là phần khá hay của bài Lab.
User az104-01b-aaduser1 thuộc tenant Contoso Lab, nhưng chúng ta muốn người này cộng tác hoặc truy cập tài nguyên của tenant chính.
Không cần tạo thêm một danh tính hoàn toàn độc lập trong tenant chính.
Thay vào đó, chúng ta có thể mời tài khoản đó dưới dạng:
Guest User
Đây là một tình huống điển hình của Microsoft Entra External ID/B2B collaboration.
Guest User sau đó có thể được thêm vào Group:
IT Lab Administrators
và được cấp quyền phù hợp.
Mô hình này rất thực tế khi doanh nghiệp cần làm việc với:
- Đối tác
- Nhà thầu
- Consultant
- Vendor
- Nhân viên thuộc công ty khác
Thay vì chia sẻ tài khoản nội bộ, doanh nghiệp có thể cho người bên ngoài sử dụng danh tính của họ và kiểm soát quyền truy cập vào tài nguyên của mình. Kiến trúc của Lab
Có thể hình dung toàn bộ bài thực hành theo luồng:
Default Microsoft Entra tenant
→ Tạo Cloud Users
→ Cấu hình thuộc tính User
→ Tạo Assigned/Dynamic Groups
→ Gán Microsoft Entra role
Sau đó:
New tenant: Contoso Lab
→ Tạo User thử nghiệm
→ Mời User sang tenant chính dưới dạng Guest
→ Đưa Guest vào Group
→ Kiểm soát quyền truy cập
Chỉ trong khoảng 30 phút, bài Lab đã kết nối khá nhiều khái niệm quan trọng của Microsoft Entra ID: User, Group, Role, Dynamic Membership, Tenant và Guest Identity. Điều quan trọng nhất cần rút ra
Quản trị Identity hiệu quả không phải là tạo thật nhiều User rồi cấp quyền thủ công cho từng người.
Một thiết kế tốt sẽ hướng đến:
User attributes → Groups → Roles/Permissions → Resources
Khi kết hợp thêm Dynamic Group và Role-Based Access Control (RBAC), chúng ta có thể giảm đáng kể công việc quản trị thủ công và áp dụng nguyên tắc Least Privilege tốt hơn.
Đây cũng chính là nền tảng mà một Azure Administrator cần nắm chắc trước khi đi sâu hơn vào quản trị tài nguyên Azure.
Lab repository chính thức của khóa AZ-104:
#AZ104 #MicrosoftEntraID azuread #AzureAdministrator #Identity #AzureRBAC #CloudSecurity #MicrosoftAzure MCSA vnpro #MCSAAzureAWS
Attached Files