# Azure CLI Example:
az role assignment create --role Reader --assignee 1bc23456-2456-4a8a-8b9a-c327f407d41e --scope /
NOTE: In the above example “1bc23456-2456-4a8a-8b9a-c327f407d41e” is the Azure AD Object ID of the user or service principal who received the error. Find this value with Get-AzAdUser / Get-AzAdServiceprincipal or az ad user / az ad sp cmds.
To grant an Azure AD B2C support engineer proper consent to your Azure AD B2C tenant diagnostic logs, please follow the below steps.
Note: These steps must be followed by a user who has a valid Guest\External account access to your Azure AD B2C tenant. Meaning, you can use the Azure Portal’s directory switcher to switch between your standard Azure AD tenant and login to your Azure AD B2C tenant. This user should also have administrative permissions in the Azure AD B2C tenant.
If you have password writeback enabled and a user performs self service password reset (SSPR), the user’s new password should be written back to on-premise AD as a non-expired password. That is, after the password is written back to on-premise attribute PwdLastSet should be updated with the timestamp of the password reset:
Additionally, the on-prem AD user’s account option flags should not have “User must change password at next logon” flag set:
These two factors would indicate the user’s password is not a temporary password that expires but a permanent one as expected.
Why would “User must change password at next logon” flag be enabled after password writeback?
If instead, the above to factors are not true, then something went wrong with the password writeback operation and the password will be considered temporary\expired. This will mean the end user will have to change their password during the next logon to an on-premise AD joined resource. This is not expected behavior.
The most common reason is that the Azure AD Connect on-premise AD service account (typically MSOL_b38random9b@domain.com does not have sufficient permissions on the domain to perform “Unexpire password” operation
Most default Windows AD domains will have this permission granted to at the root domain level to all “Authenticated Users” and so MSOL service account will have this permission as well :
However, I have seen a number of scenarios where for security reasons this permission might not be granted to all users. If this is the case, you will want to ensure you grant the MSOL service account this permission manually to root domain and all descendant objects:
Once this is applied, you should be able to have the user reset their password via SSPR and the password writeback operation will not set the “User must change password at next logon” flag as it will set the PwdLastSet timestamp succesfully.
Another quick note that has caused some confusion…
If instead of the end user performing SSPR from https://aka.ms/sspr the AAD admin is resetting the user’s password on the user’s behalf from the Azure AD portal -> User Profile -> Reset Password link.
Then it is by design \ expected for the on-premise “User must change password at next logon” flag to be selected during the password writeback operation. This is because admin initiated password reset only sets a temporary password not a permanent one.
On a recent support case we had a customer who was trying to automate Privileged Identity Management (PIM) role assignments for Azure Resources with PowerShell. We could not find any public end to end documentation on the syntax to make this work. After some trial and error we found the following syntax works.
For Azure Resource roles I could not find any end to end public doc examples but after trial and error the below steps were confirmed to work.
NOTE: The additional cmds compared to Azure AD role scenario are to convert ARM subscription IDs and ARM role IDs into their PIM resource IDs. For roleDefinitionID you can also look up built-in role IDs on Azure built-in roles doc if you are using custom roles, you can look these up in Azure Portal -> Subscription blade -> Access Control -> Roles
Occasionally you may be alerted to an existing Azure AD service principal whose client secret is scheduled to expire soon. From the Azure AD portal -> Application Registrations -> App -> Certificates & Secrets blade it is not possible to extend the expiration of an existing secret. You can only create a new one.
This can be a problem because the portal auto-generates the secret to be a random value. So you would have to go and update all your application code\configs to use this new secret value.
Luckily, with Azure PowerShell module you can both create a new secret with the same value as your existing one and set it’s expiration date manually preventing any unnecessary work to update application code\configs.
# Get service principal
$sp = Get-AzADServicePrincipal -DisplayName "MyTestApp"
# View current password Ids and expirations
Get-AzADSpCredential -ObjectId $sp.Id
#choose expiration date
$start = get-date
$end = $start.AddYears(150)
#Set same password as current password
$SecureStringPassword = ConvertTo-SecureString -String "c0[Ndh_@G/j8tB4aqbq66R]P*0MVwB.h" -AsPlainText -Force
New-AzADAppCredential -ApplicationId $sp.ApplicationId -StartDate $start -EndDate $end -Password $SecureStringPassword
# Verify new credential expiration
Get-AzADAppCredential -ApplicationId $sp.ApplicationId
I have seen a few questions regarding if Azure AD Domain Services supports Remote Desktop Services (RDS) licensing services.
These questions mostly are around whether or not Per User license auditing reports are supported as this requires AD user attribute updates when the RD Licensing Server issues a per user CAL to the user. In Azure AD Domain Services user writes are only allowed from Azure AD itself, not within Azure AD Domain Services (where the user objects are read only).
This process IS supported as long as the administrator installing the Remote Desktop Licensing server role on the Windows Server host is a member of the Azure AD group “AAD DC Administrators” when they are installing the Remote Desktop Licensing server role. You can verify membership from within your AAD DS joined workstation with cmd:
Once you have verified membership in “AAD DC Administrators”, after installation of the Remote Desktop Licensing role, you should find that the server’s Windows AD computer object has been added to the “Terminal Server License Servers” security group as shown below:
If this is not the case, verify that the security permissions on the “Terminal server License Servers” group show that the “AAD DC Administrators” group has the effective permission “Write Members” as shown below:
And on a user within AADDC Users OU, view security effective permissions for the Terminal Service License Servers group and verify it has read\write permissions on the following msTS user attributes shown below:
If you do not see this ACL entry for Terminal Server License servers, you should open a support case as this would be unexpected behavior. If the Remote Desktop Licensing Server computer object is not a member of the “Terminal Server License Server” group then you may find the following error in your Event Logs:
Log Name: System
Event ID : 4105
Computer: <computer name>
The Terminal Services license server cannot update the license attributes for user <user name> in the Active Directory Domain <domain name>. Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain <domain name>.
If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Terminal Services Licensing service to track or report the usage of TS Per User CALs.
Win32 error code: 0x80070005
Once computer membership in Terminal Server License Servers group has been confirmed, you should find no issues tracking Per-user CAL issuance in RD Licensing Manager:
Viewing any user’s AD attributes after they were issued a per user CAL should show that the necessary license tracking has been successfully written to the user in Azure AD Domain Services:
A Per-user CAL license report should also successfully list these users:
I hope this clears up any questions around the compatibility
Occasionally we receive support cases from customers performing audits of their Azure AD Audit or Sign in logs and do not know what the service principal \ actor ” Microsoft Approval Management “ is.
After review with Microsoft product engineering teams it was confirmed this is a 1st Party Microsoft Service Principal for the following services and may be logged in customer audit logs during the operation of any of these services in your tenant.
Any of the operations performed by these services such as calculating group memberships, applying group memberships, performing group expirations etc. will be logged in Azure AD audit logs as being performed by “Microsoft Approval Management”. All of the operations performed by these services, are documented in the links above.
You can confirm this service principal is in your AAD tenant with the AzureADPreview PowerShell module and the following cmd
Where you should confirm that the PublisherName = “Microsoft Services” and you may find it listed with the AppID of “65d91a3d-ab74-42e6-8a2f-0add61688c74” or “38049638-cc2c-4cde-abe4-4479d721ed44”
If this service principal is disabled you may experience strange behavior in the Azure AD Portal when trying to manage groups.
One example, if this service principal has been disabled by the AAD Global Administrator any operation on groups in the AAD portal may return an error : “Unable to complete due to service connection error. Please try again later”
If you receive this error, verify that the Microsoft Approval Management enterprise application has not been disabled.
We have received a few cases in AAD Audit Log support topic around AAD audit logs showing a service principal named “Microsoft Substrate Management” has created users in their AAD tenant and they have no idea who this principal is.
UPDATE: If you have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles
Where you should be able to confirm this is a 1st Party principal (PublisherName = Microsoft Services) with AppID = 98db8bd6-0cc0-4e67-9de5-f187f1cd1b41
After investigation, it was determined that the “Microsoft Substrate Management” service principal is a 1st party service principal used by Exchange Online during dual write operations to AAD. When for example a mailbox is created directly in Exchange Online, this service principal may show up in your audit logs as the actor who created the user account the mailbox will be assigned to.
Choose Download Metadata, and save the returned GoogleIDPMetadata.xml locally
Browse to https://portal.azure.com -> Azure AD -> External Identities -> All identity providers -> New SAML/WS-Fed IdP . Choose protocol = SAML, domain name = gSuite domain name, method = parse metadata file. Browse to your GoogleIDPMetadata.xml file and hit parse, then save:
We occasionally get support cases from customers who when browsing to their Azure Portal’s subscription blade see a subscription type with a strange name “Access to Azure Active Directory” and get strange errors like “Unknown” role or “Unauthorized” or “Unable to access data” or “The current subscription does not allow you to perform any actions on Azure resources. Use a different subscription.”
TLDR: These subscriptions do NOT host Azure AD. These are legacy subscriptions that can no longer be managed by customer portal. If causing issues they are safe to delete but can only be deleted via support ticket today. For more info read below details.
History of the Access to Azure Active Directory subscription
The “Access to Azure Active Directory” subscriptions are a legacy subscription type that are no longer used. They were used prior to the current Azure Portal (https://portal.azure.com).
At that time the classic Azure portal (https://manage.windowsazure.com) that was used to manage Azure Active Directory and other Azure resources only allowed access if the user had a Azure subscription associated to their user account. It utilized the classic Azure roles such as “Subscription Admin” \ “Billing Admin” \ and “Co-Administrator” only so you had to have one of these roles in order to login. It did not take into account Azure AD roles like Global Administrator etc.
This caused issues when the Azure AD admin didn’t have an Azure resource subscription necessarily, so these “dummy” subscriptions were created for such access.
Today no such access subscription is required as we now separate AAD RBAC permissions (Global Administrator etc) and Azure Resource subscription RBAC permissions (Owner, Contributor, Reader etc) and do not limit user’s access to https://portal.azure.com.
How to delete the Access to Azure Active Directory subscription
If these subscriptions are causing you problems, or you would just like to cleanup your Azure environment from unneeded subscriptions you can get these subscriptions removed from your account by opening a support case and requesting the subscription be deleted. Unfortunately, as the errors suggest these subscriptions cannot be managed using the current Azure Portal.
These subscriptions do not host any data and removing them will have no impact to your Azure Active Directory tenant, data, users, groups, or other subscriptions.