Unable to Complete Due to Service Connection Error Please Try Again Later

The error "User does not have access Microsoft.Subscription/aliases/read over telescopic providers/Microsoft.Subscription/aliases/X " can exist fixed using these steps:

1. Get-go determine who the user or principal trying to read Microsoft.Subscription/aliases is.
2. Next every bit an Azure Ad Global Ambassador run Azure Resource Elevation process ( https://docs.microsoft.com/en-us/azure/office-based-admission-command/elevate-access-global-admin#azure-portal) then you have "User Access Administrator" permissions at the "/" scope
3. Finally, using Azure PowerShell or Azure CLI cmds, add the user or master referenced in the mistake to the Reader function at the root "/" scope equally shown beneath.

# Azure PowerShell Example: New-AzRoleAssignment -ObjectId 1bc23456-2456-4a8a-8b9a-c327f407d41e -Scope / -RoleDefinitionName "Reader"              

# Azure CLI Case: az role assignment create --function Reader --assignee 1bc23456-2456-4a8a-8b9a-c327f407d41e --scope /              

Note: In the above example "1bc23456-2456-4a8a-8b9a-c327f407d41e" is the Azure Advertising Object ID of the user or service master who received the error. Find this value with Become-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 beneath steps.

Note:
These steps must be followed by a user who has a valid Guest\External account access to your Azure Advert B2C tenant. Meaning, y'all can use the Azure Portal'south directory switcher to switch between your standard Azure AD tenant and login to your Azure AD B2C tenant. This user should also take authoritative permissions in the Azure AD B2C tenant.

Steps

1. Commencement from your standard Azure AD tenant, open a new support case via Azure Portal's back up blade at https://aka.ms/azuresupportrequest
2. Chose the following options
   • Issue Type = Technical
   • Subscription = <Select the Azure Billing Subscription for your Azure Advertisement B2C tenant>
   • Service = All Services
   • Service Type = Azure Active Directory Business To Consumer (B2C)

Case:

3. On the next bract, be certain to fill up out the post-obit options:
   • Which B2C tenant is the problem occurring in? = Fill out the b2ctenant.onmicrosoft.com or tenant ID of your B2C TENANT
   • Advanced diagnostic information = Yes , so Azure support engineer has permissions for the life of the support case to access your B2C tenant diagnostic logs.

Example:

4. At this indicate you tin can submit the case, and and so share your case # with your Azure Advertizement B2C support engineer so they can utilize it to review B2C diagnostic logs.

If you lot have password writeback enabled and a user performs self service password reset (SSPR), the user's new countersign should be written back to on-premise Advertising as a non-expired password. That is, after the password is written dorsum to on-premise attribute PwdLastSet should be updated with the timestamp of the countersign reset:

PwdLastSet aspect containing timestamp.

Additionally, the on-prem Advert user's account choice flags should non accept "User must change password at side by side logon" flag set:

User must alter password at next logon flag not set.

These two factors would point the user's password is non a temporary password that expires merely a permanent one every bit expected.

Why would "User must change password at next logon" flag be enabled subsequently password writeback?

If instead, the above to factors are non truthful, then something went incorrect with the password writeback operation and the password will be considered temporary\expired. This volition mean the end user will have to modify their password during the next logon to an on-premise Advertisement joined resource. This is not expected beliefs.

No PwdLasetSet aspect divers, indicating temporary\expired password

User must modify password at next logon flag is set

The most common reason is that the Azure Ad Connect on-premise AD service business relationship (typically MSOL_b38random9b@domain.com does not have sufficient permissions on the domain to perform "Unexpire countersign" functioning

About default Windows AD domains will accept this permission granted to at the root domain level to all "Authenticated Users" and so MSOL service account will have this permission as well :

Unexpire countersign permission for Authenticated Users at domain root

However, I have seen a number of scenarios where for security reasons this permission might non exist granted to all users. If this is the case, you volition desire to ensure you lot grant the MSOL service account this permission manually to root domain and all descendant objects:

Manually add Unexpire password permission for MSOL service account at root domain level and all descendant objects

Once this is applied, yous should be able to have the user reset their countersign via SSPR and the password writeback functioning volition non set the "User must modify password at next logon" flag every bit it will gear up the PwdLastSet timestamp succesfully.

Note if there are any other permission related errors, follow the Enable password writeback to on-premises \ Configure account permission for Azure Advertisement Connect public doc for all of the permissions required.

Another quick annotation 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.

Admin initiated password reset

Then it is past design \ expected for the on-premise "User must alter password at next logon" flag to be selected during the password writeback operation. This is because admin initiated countersign reset only sets a temporary countersign not a permanent one.

This fact is explained in https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-users-reset-password-azure-portal#to-reset-a-password just is also mentioned in the Azure AD portal'southward dialog during the reset password functioning

On a contempo support case we had a customer who was trying to automate Privileged Identity Direction (PIM) office assignments for Azure Resources with PowerShell. We could not find any public stop to terminate documentation on the syntax to brand this work. Subsequently some trial and fault nosotros institute the following syntax works.

Notation: PIM can assign both Azure AD roles and Azure resource roles then both scenarios are shown beneath. Additionally, make sure you lot accept the latest version of AzureADPreview module installed.

Assigning Azure AD roles

For this scenario there is a public doc explaining the syntax which can be found at PowerShell for Azure Ad roles in Privileged Identity Management . For roleDefinitionID you lot can too look these IDs up on Azure Advertizement built-in roles doc

PowerShell code case:

### Azure Advertisement PIM Example Connect-AzureAD  $tenantID = "91ceb514-5ead-468c-a6ae-048e103d57f0" $roleDisplayName = "Global Administrator" $roleDefinitionID = (Get-AzureADMSRoleDefinition -Filter "DisplayName eq '$roleDisplayName'").Id $targetuserID = (Go-AzureADUser -ObjectId User.Name@jasonfritts.me).ObjectId  # Supervene upon user ID  $schedule = New-Object Microsoft.Open.MSGraph.Model.AzureADMSPrivilegedSchedule $schedule.Type = "Once" $schedule.StartDateTime = (Get-Appointment).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ") $schedule.EndDateTime =  ((Become-Date).AddDays(1)).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")  # Create temporary eligible role consignment Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'aadRoles' -ResourceId $tenantID -RoleDefinitionId $roleDefinitionID -SubjectId $targetuserID -Blazon 'adminAdd' -AssignmentState 'Eligible' -schedule $schedule -reason "testing"  # Create temporary active function consignment Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'aadRoles' -ResourceId $tenantID -RoleDefinitionId $roleDefinitionID -SubjectId $targetuserID -Blazon 'adminAdd' -AssignmentState 'Active' -schedule $schedule -reason "testing"              

Assigning Azure Resources Roles

For Azure Resource roles I could non find any end to end public doc examples but after trial and fault 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 office IDs into their PIM resource IDs. For roleDefinitionID you can also wait upward built-in role IDs on Azure built-in roles doc if you are using custom roles, you can wait these upwards in Azure Portal -> Subscription bract -> Access Control -> Roles

PowerShell code example:

## Azure Resources PIM Example Connect-AzureAD  $subscriptionID = "ed6a63cc-c71c-4bfa-8bf7-c1510b559c72" $roleDefinitionID = "b24988ac-6180-42a0-ab88-20f7382dd24c" #Congenital-in Contributor Role Definition ID example $targetuserID = (Go-AzureADUser -ObjectId User.Name@jasonfritts.me).ObjectId  # Replace user ID   # Convert IDs to PIM IDs $SubscriptionPIMID = (Go-AzureADMSPrivilegedResource -ProviderId 'AzureResources' -Filter "ExternalId eq '/subscriptions/$subscriptionID'").Id $RoleDefinitionPIMID = (Get-AzureADMSPrivilegedRoleDefinition -ProviderId 'AzureResources' -Filter "ExternalId eq '/subscriptions/$subscriptionID/providers/Microsoft.Authorization/roleDefinitions/$roleDefinitionID'" -ResourceId $subscriptionPIMID).Id   $schedule = New-Object Microsoft.Open.MSGraph.Model.AzureADMSPrivilegedSchedule $schedule.Type = "In one case" $schedule.StartDateTime = (Become-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ") $schedule.EndDateTime =  ((Get-Date).AddDays(1)).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")  # Create temporary eligible role assignment Open up-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'AzureResources' -ResourceId $SubscriptionPIMID -RoleDefinitionId $RoleDefinitionPIMID -SubjectId $targetuserID -Blazon 'adminAdd' -AssignmentState 'Eligible' -schedule $schedule -reason "testing"  # Create temporary active role consignment Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'AzureResources' -ResourceId $SubscriptionPIMID -RoleDefinitionId $RoleDefinitionPIMID -SubjectId $targetuserID -Blazon 'adminAdd' -AssignmentState 'Active' -schedule $schedule -reason "testing"              

Occasionally yous may be alerted to an existing Azure Advertising service principal whose client secret is scheduled to expire shortly. From the Azure Advertisement portal -> Application Registrations -> App -> Certificates & Secrets blade it is not possible to extend the expiration of an existing secret. You can but create a new ane.

This tin can be a trouble considering the portal auto-generates the cloak-and-dagger to be a random value. Then you would take to become and update all your awarding lawmaking\configs to use this new hole-and-corner value.

Luckily, with Azure PowerShell module you tin can both create a new secret with the same value as your existing one and fix it'south expiration appointment manually preventing any unnecessary work to update awarding code\configs.

Example Script:

# Go service principal $sp = Get-AzADServicePrincipal -DisplayName "MyTestApp"  # View current password Ids and expirations Get-AzADSpCredential -ObjectId $sp.Id  #choose expiration appointment $starting time = get-date $cease = $get-go.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 $get-go -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 generally are around whether or not Per User license auditing reports are supported as this requires AD user attribute updates when the RD Licensing Server bug a per user CAL to the user. In Azure Advertisement Domain Services user writes are but allowed from Azure Advertising itself, not within Azure Advertizement Domain Services (where the user objects are read simply).

This process IS supported as long as the ambassador installing the Remote Desktop Licensing server role on the Windows Server host is a member of the Azure Advertizement grouping "AAD DC Administrators" when they are installing the Remote Desktop Licensing server role. Yous tin can verify membership from inside your AAD DS joined workstation with cmd:

whoami /groups

Once you accept verified membership in "AAD DC Administrators", after installation of the Remote Desktop Licensing role, you should find that the server's Windows Advertising computer object has been added to the "Terminal Server License Servers" security group as shown below:

If this is not the instance, verify that the security permissions on the "Final server License Servers" group show that the "AAD DC Administrators" group has the constructive permission "Write Members" every bit shown below:

And on a user within AADDC Users OU, view security effective permissions for the Final Service License Servers group and verify it has read\write permissions on the following msTS user attributes shown beneath:

If you do not come across this ACL entry for Final Server License servers, y'all should open a support case every bit this would be unexpected behavior. If the Remote Desktop Licensing Server estimator object is not a fellow member of the "Terminal Server License Server" group then you may discover the following error in your Event Logs:

              Log Name: Organisation Source: Microsoft-Windows-TerminalServices-Licensing Event ID : 4105 Level: Warning User: N/A Computer: <reckoner proper name> Description: 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 Last Server License Servers group in Active Directory domain <domain proper name>. If the license server is installed on a domain controller, the Network Service account also needs to exist a member of the Terminal Server License Servers grouping. If the license server is installed on a domain controller, after you take added the appropriate accounts to the Final Server License Servers grouping, y'all must restart the Terminal Services Licensing service to rail or report the usage of TS Per User CALs. Win32 error code: 0x80070005            

Once computer membership in Final Server License Servers group has been confirmed, you lot should find no issues tracking Per-user CAL issuance in RD Licensing Manager:

Viewing whatever user's Advertisement attributes after they were issued a per user CAL should evidence that the necessary license tracking has been successfully written to the user in Azure Advertisement Domain Services:

A Per-user CAL license report should as well successfully list these users:

I promise this clears upward whatever questions around the compatibility

Occasionally we receive back up cases from customers performing audits of their Azure Advertising Audit or Sign in logs and do not know what the service chief \ player " Microsoft Approval Direction " is.

After review with Microsoft product technology teams information technology was confirmed this is a 1st Political party Microsoft Service Chief for the following services and may be logged in customer inspect logs during the functioning of whatever of these services in your tenant.

1. Dynamic Groups
2. Self Service Group Management
3. O365 Grouping Expiration policy

Any of the operations performed by these services such as calculating group memberships, applying grouping memberships, performing group expirations etc.  volition be logged in Azure AD audit logs as being performed by "Microsoft Blessing Direction".  All of the operations performed by these services, are documented in the links above.

You tin confirm this service principal is in your AAD tenant with the AzureADPreview PowerShell module and the following cmd

              Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Approving Direction'" | fl *            

Where you should ostend that the PublisherName = "Microsoft Services" and y'all may find information technology listed with the AppID of "65d91a3d-ab74-42e6-8a2f-0add61688c74" or "38049638-cc2c-4cde-abe4-4479d721ed44"

UPDATE:

If this service chief is disabled you may experience strange behavior in the Azure Advertizing Portal when trying to manage groups.

One example, if this service master 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 connectedness fault. Delight endeavour again later"

Portal error : Unable to complete due to service connection error. Delight try again later.

If you lot receive this error, verify that the Microsoft Approval Management enterprise application has non been disabled.

1. Go to AAD -> Enterprise Apps blade : Enterprise applications – Microsoft Azure
2. And so browse to All applications Set filters to Application blazon = All Applications, Status = Any, Application Visibility = Whatever In search box blazon the appID 65d91a3d-ab74-42e6-8a2f-0add61688c74

three. Open this app's properties Choose Enabled for users to sign in = Yes Hit Salvage

4. Then retry their group operation which failed

NOTE: You may likewise want to bank check for app ID 38049638-cc2c-4cde-abe4-4479d721ed44 to verify information technology is enabled besides.

We have received a few cases in AAD Inspect Log support topic around AAD audit logs showing a service principal named "Microsoft Substrate Management" has created users in their AAD tenant and they take no idea who this principal is.

UPDATE:
If y'all have other unknown principals showing up in your AAD logs and you would like to verify they are Microsoft 1st party principals please apply the Feedback sections of the below articles

Unknown Actors in AAD Inspect Reports
Verify showtime-political party Microsoft applications in sign-in reports

You tin observe this service principal in your tenant using AzureADPreview Powershell module and the post-obit cmd:

              Become-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Substrate Direction'" | fl *            

Where you should be able to confirm this is a 1st Party principal (PublisherName = Microsoft Services) with AppID = 98db8bd6-0cc0-4e67-9de5-f187f1cd1b41

The following are my notes for setting up Azure Advertisement B2B Direct Federation with a GSuite domain. The official documentation can be referenced at https://docs.microsoft.com/en-the states/azure/active-directory/b2b/direct-federation. Note that if you only desire to invite Gmail.com users you tin can apply Google Federation steps instead https://docs.microsoft.com/en-us/azure/active-directory/b2b/google-federation

Steps to configure AAD B2B Direct Federation with GSuite Domain

1. Login to https://admin.google.com -> Security -> Set upward single sign-on (SSO) for SAML applications

2. Choose Download Metadata, and relieve the returned GoogleIDPMetadata.xml locally

3. Browse to https://portal.azure.com -> Azure Advertising -> 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 hitting parse, then save:

4. From https://support.google.com/a/answer/6363817?hl=en  follow Step iii. "Gear up upwards Google as a SAML identity provider (IdP)" and Scan to https://admin.google.com -> Apps -> SAML Apps -> New App

1. Filter existing apps past "Microsoft Office 365" and add together the app
2. Download Metadata locally to .XML file
3. Save
4. Browse back to apps and choose "Microsoft Office 365"
5. Edit Attribute Mapping to be equally follows

5. From https://support.google.com/a/answer/6363817?hl=en  follow Step four. "Enable the Part 365 app" and Choose Edit Service -> Service Condition -> ON for everyone

6. Lastly Invite the Guest GSuite domain User from Azure AD
   1. Now From Azure AD portal -> Invite New User -> Invite a user from G Suite domain
   2. G Suite user gets invite email, and clicks redemption link and signs in with One thousand Suite credentials to redeem invite successfully

Lastly, you can manually configure GSuite Direct Federation using Azure AD Preview PowerShell module and instance script below (note your GSuite metadata will be different)

Connect-AzureAD  $federationSettings = New-Object Microsoft.Open up.AzureAD.Model.DomainFederationSettings $federationSettings.PassiveLogOnUri ="https://accounts.google.com/o/saml2/idp?idpid=C01ypkxdy" $federationSettings.ActiveLogOnUri = "https://accounts.google.com/o/saml2/idp?idpid=C01ypkxdy" $federationSettings.LogOffUri = "https://accounts.google.com/o/saml2/idp?idpid=C01ypkxdy" $federationSettings.IssuerUri = "https://accounts.google.com/o/saml2?idpid=C01ypkxdy" $federationSettings.SigningCertificate= "MIIDdDCC_EXAMPLECERT_lMlRYzq4"  $federationSettings.PreferredAuthenticationProtocol="Samlp" $domainName = "jfritts.xyz"  New-AzureADExternalDomainFederation -ExternalDomainName $domainName  -FederationSettings $federationSettings              

We occasionally get support cases from customers who when browsing to their Azure Portal's subscription bract meet a subscription blazon with a strange name "Access to Azure Active Directory" and go foreign errors similar "Unknown" office or "Unauthorized" or "Unable to access data" or "The current subscription does not let you to perform whatever actions on Azure resources. Use a different subscription."

TLDR: These subscriptions do NOT host Azure Advert. These are legacy subscriptions that tin no longer be managed past customer portal. If causing issues they are safety to delete but tin only be deleted via support ticket today. For more info read below details.

Examples:

Access to Azure Active Directory Subscription case

Access to Azure Active Directory subscription errors examples

History of the Access to Azure Active Directory subscription

The "Access to Azure Active Directory" subscriptions are a legacy subscription blazon 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" just so you had to have one of these roles in order to login. Information technology did not take into business relationship Azure AD roles similar Global Ambassador etc.

This caused issues when the Azure Advertizement admin didn't have an Azure resource subscription necessarily, so these "dummy" subscriptions were created for such admission.

You tin can read this weblog mail service for a fleck more than history if you are interested:  https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Azure-Advertising-Mailbag-Azure-Subscriptions-and-Azure-Advert/ba-p/249661 which describes the need for these subscriptions and how admins would get one assigned to them when needed.

Today no such admission subscription is required equally we now split AAD RBAC permissions (Global Administrator etc) and Azure Resources subscription RBAC permissions (Owner, Contributor, Reader etc) and do not limit user's admission to https://portal.azure.com.

How to delete the Access to Azure Active Directory subscription

If these subscriptions are causing you bug, or you would just similar to cleanup your Azure environment from unneeded subscriptions you lot can get these subscriptions removed from your account by opening a support example and requesting the subscription be deleted. Unfortunately, every bit the errors suggest these subscriptions cannot be managed using the current Azure Portal.

These subscriptions exercise not host whatever data and removing them will have no impact to your Azure Active Directory tenant, data, users, groups, or other subscriptions.

Promise this helps someone!

cadysoccus1970.blogspot.com

Source: https://www.jasonfritts.me/

Share this post