Azure Error Detail: Unable to Complete Due to Service Connection Error

To grant an Azure Advertizing B2C support engineer proper consent to your Azure Advertizing B2C tenant diagnostic logs, please follow the below steps.

Note:
These steps must exist followed past a user who has a valid Guest\External account access to your Azure Advert B2C tenant. Significant, you lot can use the Azure Portal'due south directory switcher to switch between your standard Azure AD tenant and login to your Azure AD B2C tenant. This user should likewise take administrative permissions in the Azure Ad B2C tenant.

Steps

1. Starting time from your standard Azure Advertizing tenant, open up a new back up case via Azure Portal'due south back up bract at https://aka.ms/azuresupportrequest
2. Chose the following options
   • Issue Type = Technical
   • Subscription = <Select the Azure Billing Subscription for your Azure Advertizement B2C tenant>
   • Service = All Services
   • Service Blazon = Azure Agile Directory Business To Consumer (B2C)

Example:

3. On the side by side bract, be sure to make full out the following options:
   • Which B2C tenant is the problem occurring in? = Fill out the b2ctenant.onmicrosoft.com or tenant ID of your B2C TENANT
   • Advanced diagnostic data = Yep , so Azure support engineer has permissions for the life of the support instance to access your B2C tenant diagnostic logs.

Example:

4. At this signal yous can submit the case, and then share your case # with your Azure Advert B2C support engineer then they tin can utilize information technology to review B2C diagnostic logs.

If y'all take countersign 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 countersign reset:

PwdLastSet attribute containing timestamp.

Additionally, the on-prem AD user'due south account option flags should not have "User must alter countersign at next logon" flag ready:

User must change password at next logon flag non prepare.

These two factors would signal the user's countersign is not a temporary countersign that expires merely a permanent one as expected.

Why would "User must change password at side by side logon" flag be enabled after countersign writeback?

If instead, the above to factors are not truthful, then something went wrong with the password writeback operation and the password will exist considered temporary\expired. This volition mean the terminate user will have to change their password during the adjacent logon to an on-premise AD joined resource. This is not expected behavior.

No PwdLasetSet attribute divers, indicating temporary\expired password

User must alter password at next logon flag is fix

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" performance

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

Unexpire password permission for Authenticated Users at domain root

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

Manually add Unexpire countersign 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 password via SSPR and the countersign writeback operation will not set the "User must change countersign at next logon" flag as it will fix the PwdLastSet timestamp succesfully.

Note if at that place are whatever other permission related errors, follow the Enable password writeback to on-bounds \ Configure account permission for Azure AD Connect public doc for all of the permissions required.

Some other quick note that has caused some confusion…

If instead of the stop user performing SSPR from https://aka.ms/sspr the AAD admin is resetting the user'due south countersign on the user'due south behalf from the Azure Advertizement portal -> User Profile -> Reset Password link.

Admin initiated password reset

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

This fact is explained in https://docs.microsoft.com/en-united states/azure/active-directory/fundamentals/active-directory-users-reset-password-azure-portal#to-reset-a-password but is also mentioned in the Azure Advert portal's dialog during the reset countersign performance

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 non find any public stop to end documentation on the syntax to brand this work. After some trial and error we found the post-obit syntax works.

NOTE: PIM can assign both Azure Advertizing roles and Azure resources roles and then both scenarios are shown beneath. Additionally, make certain y'all accept the latest version of AzureADPreview module installed.

Assigning Azure AD roles

For this scenario there is a public doc explaining the syntax which tin can be plant at PowerShell for Azure AD roles in Privileged Identity Management . For roleDefinitionID you tin can likewise look these IDs up on Azure AD built-in roles dr.

PowerShell code case:

### Azure AD PIM Example Connect-AzureAD  $tenantID = "91ceb514-5ead-468c-a6ae-048e103d57f0" $roleDisplayName = "Global Administrator" $roleDefinitionID = (Get-AzureADMSRoleDefinition -Filter "DisplayName eq '$roleDisplayName'").Id $targetuserID = (Get-AzureADUser -ObjectId User.Name@jasonfritts.me).ObjectId  # Replace user ID  $schedule = New-Object Microsoft.Open.MSGraph.Model.AzureADMSPrivilegedSchedule $schedule.Blazon = "Once" $schedule.StartDateTime = (Get-Appointment).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 function consignment Open-AzureADMSPrivilegedRoleAssignmentRequest -ProviderId 'aadRoles' -ResourceId $tenantID -RoleDefinitionId $roleDefinitionID -SubjectId $targetuserID -Type 'adminAdd' -AssignmentState 'Eligible' -schedule $schedule -reason "testing"  # Create temporary active role assignment Open up-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 terminate to stop public doc examples but after trial and error the below steps were confirmed to work.

Notation: The boosted cmds compared to Azure AD role scenario are to catechumen ARM subscription IDs and ARM office IDs into their PIM resource IDs. For roleDefinitionID you tin also look upward built-in role IDs on Azure congenital-in roles doc if yous are using custom roles, you tin look these up in Azure Portal -> Subscription blade -> Access Control -> Roles

PowerShell code instance:

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

Occasionally you lot may be alerted to an existing Azure Ad service principal whose client clandestine is scheduled to elapse soon. From the Azure Advertizing 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 trouble because the portal auto-generates the hush-hush to be a random value. So you would have to go and update all your application lawmaking\configs to use this new secret value.

Luckily, with Azure PowerShell module yous can both create a new secret with the same value as your existing one and set it'southward expiration date manually preventing whatever unnecessary piece of work to update application code\configs.

Instance Script:

# Get service primary $sp = Become-AzADServicePrincipal -DisplayName "MyTestApp"  # View electric current password Ids and expirations Get-AzADSpCredential -ObjectId $sp.Id  #choose expiration date $start = go-appointment $finish = $showtime.AddYears(150)  #Set same password as current password $SecureStringPassword = ConvertTo-SecureString -Cord "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 Become-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 aspect updates when the RD Licensing Server issues a per user CAL to the user. In Azure Advertisement Domain Services user writes are but allowed from Azure AD itself, non within Azure Advertizement Domain Services (where the user objects are read merely).

This procedure IS supported every bit long as the administrator installing the Remote Desktop Licensing server role on the Windows Server host is a fellow member of the Azure AD grouping "AAD DC Administrators" when they are installing the Remote Desktop Licensing server part. You tin can verify membership from within your AAD DS joined workstation with cmd:

whoami /groups

One time you take verified membership in "AAD DC Administrators", later installation of the Remote Desktop Licensing role, you should find that the server's Windows AD calculator 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 testify 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 constructive permissions for the Terminal Service License Servers group and verify information technology has read\write permissions on the following msTS user attributes shown below:

If you do not run across this ACL entry for Last Server License servers, you lot should open a support case equally this would exist unexpected behavior. If the Remote Desktop Licensing Server computer object is non a member of the "Terminal Server License Server" group then you may discover the following error in your Effect Logs:

              Log Name: System Source: Microsoft-Windows-TerminalServices-Licensing Consequence ID : 4105 Level: Warning User: North/A Computer: <computer proper name> Description: The Last Services license server cannot update the license attributes for user <user proper 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 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, afterwards yous have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Final Services Licensing service to rail or report the usage of TS Per User CALs. Win32 mistake lawmaking: 0x80070005            

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

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 promise this clears up whatsoever questions around the compatibility

Occasionally nosotros 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 Approving Direction " is.

After review with Microsoft product technology teams it was confirmed this is a 1st Party Microsoft Service Principal for the following services and may exist logged in customer audit logs during the functioning of whatsoever of these services in your tenant.

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

Any of the operations performed past these services such as calculating group memberships, applying group memberships, performing group expirations etc.  will be logged in Azure Advertizement audit logs as being performed past "Microsoft Approval Management".  All of the operations performed by these services, are documented in the links higher up.

You can confirm this service chief is in your AAD tenant with the AzureADPreview PowerShell module and the post-obit cmd

              Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Approval Management'" | fl *            

Where you should confirm that the PublisherName = "Microsoft Services" and you may notice it listed with the AppID of "65d91a3d-ab74-42e6-8a2f-0add61688c74" or "38049638-cc2c-4cde-abe4-4479d721ed44"

UPDATE:

If this service principal is disabled y'all may feel foreign beliefs in the Azure AD Portal when trying to manage groups.

One case, if this service principal has been disabled by the AAD Global Administrator whatever operation on groups in the AAD portal may return an error : "Unable to consummate due to service connection fault. Delight endeavor once again afterwards"

Portal error : Unable to consummate due to service connection error. Please try again later.

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

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

iii. Open this app'southward properties Choose Enabled for users to sign in = Aye Hit Save

4. Then retry their group operation which failed

Note: You lot may also want to check for app ID 38049638-cc2c-4cde-abe4-4479d721ed44 to verify it is enabled as well.

Nosotros 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 take no idea who this principal is.

UPDATE:
If you have other unknown principals showing upwardly in your AAD logs and you would like to verify they are Microsoft 1st party principals please use the Feedback sections of the beneath articles

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

You can find this service principal in your tenant using AzureADPreview Powershell module and the following cmd:

              Get-AzureADServicePrincipal -Filter "DisplayName eq 'Microsoft Substrate Management'" | fl *            

Where yous should exist able to confirm this is a 1st Political 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-us/azure/active-directory/b2b/direct-federation. Annotation that if you simply desire to invite Gmail.com users you can utilize Google Federation steps instead https://docs.microsoft.com/en-us/azure/active-directory/b2b/google-federation

Steps to configure AAD B2B Straight Federation with GSuite Domain

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

2. Cull Download Metadata, and save the returned GoogleIDPMetadata.xml locally

3. 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 striking parse, then save:

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

1. Filter existing apps by "Microsoft Function 365" and add the app
2. Download Metadata locally to .XML file
3. Salve
4. Browse back to apps and choose "Microsoft Office 365"
5. Edit Attribute Mapping to be every bit follows

5. From https://support.google.com/a/respond/6363817?hl=en  follow Pace 4. "Enable the Function 365 app" and Cull Edit Service -> Service Status -> ON for everyone

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

Lastly, yous tin manually configure GSuite Direct Federation using Azure AD Preview PowerShell module and example script beneath (notation your GSuite metadata will exist different)

Connect-AzureAD  $federationSettings = New-Object Microsoft.Open.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 blade run into a subscription type with a strange proper noun "Admission to Azure Active Directory" and go strange errors like "Unknown" role or "Unauthorized" or "Unable to admission data" or "The current subscription does not allow you to perform any deportment on Azure resources. Apply a unlike subscription."

TLDR: These subscriptions do Not host Azure Advertising. These are legacy subscriptions that can no longer be managed past customer portal. If causing issues they are prophylactic to delete but can only exist deleted via back up ticket today. For more info read beneath details.

Examples:

Admission to Azure Active Directory Subscription example

Access to Azure Active Directory subscription errors examples

History of the Admission 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 electric 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" but so y'all had to take 1 of these roles in guild to login. It did not take into account Azure Advertizement roles similar Global Administrator etc.

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

Y'all tin can read this blog post for a flake more history if you are interested:  https://techcommunity.microsoft.com/t5/Enterprise-Mobility-Security/Azure-Ad-Mailbag-Azure-Subscriptions-and-Azure-Advertizement/ba-p/249661 which describes the need for these subscriptions and how admins would become one assigned to them when needed.

Today no such access subscription is required every bit nosotros now divide AAD RBAC permissions (Global Administrator etc) and Azure Resource subscription RBAC permissions (Owner, Contributor, Reader etc) and do non 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 issues, or yous would but like to cleanup your Azure environs from unneeded subscriptions you tin get these subscriptions removed from your account past opening a support instance and requesting the subscription be deleted. Unfortunately, as the errors suggest these subscriptions cannot be managed using the electric current Azure Portal.

These subscriptions practise not host any data and removing them will take no impact to your Azure Active Directory tenant, data, users, groups, or other subscriptions.

Hope this helps someone!

I recently received a support case where the customer was concerned that a bad actor "fim_password_service@back up.onmicrosoft.com" was performing SSPR \ Password Reset operations on their Azure AD user'south without dominance.

UPDATE:
If you have other unknown principals showing upwardly in your AAD logs and yous would like to verify they are Microsoft 1st party principals please use the Feedback sections of the below articles

Unknown Actors in AAD Inspect Reports
Verify starting time-party Microsoft applications in sign-in reports

When checking the Azure AD Audit Logs, they found entries similar to the beneath screenshot:

fim_password_service@back up.onmicrosoft.com AAD audit log entries

This is concerning as the client has no account in their AAD tenant with the UPN fim_password_service@back up.onmicrosoft.com.

We performed a reproduction of a standard SSPR operation performed by a known user, and confirmed that these logs appeared and are to be expected.

A successful SSPR functioning will offset show the user who performed SSPR performing verification steps, submitting a new password, so the fim_password_service@support.onmirosoft.com service account resetting the user'southward countersign as seen in the below example:

Reproduction of a successful SSPR by user testsspr@jasonfritts.me

If you expand your audit log search for all operations with the target business relationship specified, you will see that the user who really initiated the SSPR action is as well audited.

We constitute information technology odd that this service account was performing the bodily password reset and so there was an escalation opened with our engineering team to review. They confirmed the same, that this is to be expected.

" fim_password_service@support.onmicrosoft.com is an internal account used to indicate countersign reset is done in App context versus App + User context. "

This ways that every bit the user doesnt know their countersign, the reset operation can't exist completed in the context of the SSPR app + User, so in certain scenarios such as SSPR, AAD operations are performed in the App context but and thus are audited equally the actor being the internal account fim_password_service@support.onmicrosoft.com. There are also other diverse AAD scenarios that may be audited similar this every bit well such as sure MFA registration operations.

The engineering team acknowledged that this can be confusing to customers and they are working on publicly documenting this account to prevent future support cases in the future. I'll be sure to update with a link when that occurs.

Hope this answers someone's questions in the meantime!

smithlailme.blogspot.com

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

Share this post