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:
Verify user’s password is not blocked by on-prem password policy
From on-prem domain controller, check the default password policy using cmd Get-ADDefaultDomainPasswordPolicy
If you have a minimum password age (MinPasswordAge) and have recently changed the password within that window of time, you’re not able to change the password again until it reaches the specified age in your domain.
For testing purposes, the minimum age should be set to 0.
If you have password history requirements (PasswordHistoryCount) enabled, then you must select a password that has not been used in the last N times, where N is the password history setting. If you do select a password that has been used in the last N times, then you see a failure in this case.
For testing purposes, the password history should be set to 0.If you have password complexity requirements (ComplexityEnabled) , all of them are enforced when the user attempts to change or reset a password.
Check a particular user’s password age with cmd :
net user username /domain
NOTE the output for User may change password, Password last set timestamp, and Password changeable timestamp
If the above domain password policies are conflicting, recommend customer update domain default password policy to our recommended config for testing SSPR which is to have MinPasswordAge=0
Identify the AD DS Connector Account (aka the MSOL account)
Go to AAD Connect server > Synchronization Service Manager > Connectors > select AD Connector > Properties > Connect to Active Directory Forest
Alternatively in PowerShell on AD Connect Server run the following cmdletsImport-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1 Get-ADSyncADConnectorAccount
Verify Required Permissions
Open the properties for the root of the domain > Security Tab > Advanced
Expand the window and sort the ACLs by Principal
Confirm that Authenticated users have the following default permissions
Confirm that Everyone has Everyone have the following default permissions (Deny + Allow):
Confirm that Pre-Windows 2000 Compatible Access and SELF looks as the following default permissions:
Verify Effective Permissions On Test Account
Locate a testing user account in AD and open Properties:
Go to Security > Advanced and confirm that “Disable inheritance” is present (i.e. AD object is inheriting permissions, if greyed out it means inheritance has already been disabled so this account is not inheriting the permissions that are required)
Confirm if AADConnect Server is not receiving any Group Policy that is overwriting the “Impersonate a client after authentication” setting:
Start a command prompt with Run As Administrator
run: gpresult /H gpresult_AADC.htm
Repeat the same step on the domain controller
Start a command prompt with Run As Administrator
run: gpresult /H gpresult_DC.htm
Check on both Group Policy reports from above – AADConnect server and DC(s) – that the policy called Network access: Restrict clients allowed to make remote calls to SAM under “Policies\Windows Settings\Security Settings\Local Policies\Security Options\Other” is not blocking SAMR (Password Reset) Protocol:NOTE: in case of doubt, temporarily disabled that group policy/ policy setting and test password reset again.
Check Service Bus Connectivity
For issues where password writeback can’t be enabled, or the customer facing SSPR error indicates a service connection problem to on-prem you should verify connectivity to the required service bus endpoints.
Is this only a temporary service bus connectivity issue? If so the steps for Disable and Re-Enable Password Writeback will generally correct any service bus connectivity issues. Otherwise, continue to the following steps.
If needed, you can Enable Schannel Event Logging to capture TLS\SSL protocol (no reboot necessary)a. Start -> Run -> Cmd (open as admin)reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v "EventLogging" /t REG_DWORD /d 7 /f
NOTE: once finished testing\capturing event logs, run the following to disable logging:
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL" /v "EventLogging"
c. Reproduce issue with disabling\re-enabling password writeback via powershell cmd example: Remove-ADSyncAADPasswordResetConfiguration -Connector "tenant.onmicrosoft.com - AAD"
Set-ADSyncAADPasswordResetConfiguration -Connector "tenant.onmicrosoft.com - AAD" -Enable $true
d. Review Windows Event Log -> System Log -> Event ID 36880 (Source=Schannel) for any errors\warnings around TLS client handshake failures
Additional Data Collection
For any escalations\investigations capture the following data for review
Open the Registry Editor and navigate to the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
Enable Internal logging by entering 5 as the value of the following DWords: “8 Directory Access” “16 LDAP Interface Events”
Event Logs After Reproducing Error
Repro the issue and steps taken and capture the following:
The time stamp when the error occurred, including the time zone (or the date/time in UTC)
A screenshot of the error
Application + System events of AADConnect serverPlease don’t filter anything but avoid saving the whole event viewer log. The easiest way is to:a. Right-click event’s folder and select “Filter Current Log…”b. In the Logged time frame pick “Last hour” or “Last “c. Right-click event’s folder again and select “Save Filtered Log File As…”d. If all you need is one error event then please don’t take a screenshot! Right-click the event and Copy > Copy Details as Text. This way you’re including the full event data in a text format and the exact time stamp in UTC
Capture the Security Event Log from the Domain Controller. You might not know which exact DC server responded to the SSPR request so you can try to lookup in the DC’s Security events with CTRL + F (Find) the SamAccountName of the target user or the SamAccountName of the admin doing the operation