Azure-docs: RBAC Binding Issues with User Subject

[droessmj]

Working with AKS v1.12.7 and Azure AD RBAC enabled, we found that ObjectId works as expected when assigning a RoleBinding to a Group -- exactly as specified above. However, when testing bindings for individual users we found that were receiving "Forbidden" errors when using the user's AAD objectId. Further digging and experimentation shows that using the user's email address as the value for the name field above resolves this issue.

Is this a documentation miss or a regression in newer versions?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a47c6df7-5103-1336-eb0b-68f95155e6c8
• Version Independent ID: f4420b08-9b57-f581-fcb4-f069afdd5b0c
• Content: Integrate Azure Active Directory with Azure Kubernetes Service
• Content Source: articles/aks/aad-integration.md
• Service: container-service
• GitHub Login: @iainfoulds
• Microsoft Alias: iainfou

[mimckitt]

Thanks for the feedback! We are currently investigating and will update you shortly.

[Karishma-Tiwari-MSFT]

@iainfoulds Can you please share your insights, are you aware of this being a regression issue or missing from the doc. Thanks. :)

[Karishma-Tiwari-MSFT]

@iainfoulds I found this issue where the doc changes were made to change the name from user's email address to object id in rbac-aad-user.yaml file. You mentioned that there was a known problem which was fixed.
Can you please take a look at this one or provide me the names of the product team members who were involved in this and I can reach out to them? Thanks. :)

[iainfoulds]

There was an issue when the user existed in a different tenant, so the objectId can't be used. The workaround was to specify the e-mail instead.

@palma21 to comment on the behavior experienced here as to why that doesn't appear to work correctly.

[palma21]

Correct:
Today the UPN (aka [email protected]) only works when using the user's tenant (domain.com) since otherwise, for guest users, they won't have UPN.

For users within the tenant (domain.com) it will look before on the UPN, we are making it fallback to objectID so that it works on all scenarios, so for users within the tenant please use UPN.

[Karishma-Tiwari-MSFT]

@droessmj Does that help answer your question? Let us know.

[droessmj]

@Karishma-Tiwari-MSFT I believe this helps. To restate the above, if we're using a user within our tenant we would be expected to specify UPN. If we're granting permissions to a user outside our tenant but still within AAD, we would specify ObjectId. For groups, we continue to use ObjectId.

If all that is true, then it sounds like the only item outstanding is a minor documentation amendment. Thanks y'all.

[Karishma-Tiwari-MSFT]

Thanks @droessmj for sharing the update.
We will now close this issue. If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.