Jul 162020

Verify user’s password is not blocked by on-prem password policy

  1. From on-prem domain controller, check the default password policy using cmd Get-ADDefaultDomainPasswordPolicy

  1. 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.
  2. For testing purposes, the minimum age should be set to 0.
  3. 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.
  4. 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.
  5. Check a particular user’s password age with cmd :

    net user username /domain

  1. NOTE the output for User may change password, Password last set timestamp, and Password changeable timestamp
  2. 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)

  1. Go to AAD Connect server > Synchronization Service Manager > Connectors > select AD Connector > Properties > Connect to Active Directory Forest

  1. 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

  1. Open the properties for the root of the domain > Security Tab > Advanced
  2. Expand the window and sort the ACLs by Principal
  1. Confirm that Authenticated users have the following default permissions
  1. Confirm that Everyone has Everyone have the following default permissions (Deny + Allow):
  1. Confirm that AD DS Connector Account – from section Identify the AD DS Connector Account – have the following default permissions:

  1. Confirm that Pre-Windows 2000 Compatible Access and SELF looks as the following default permissions:


Verify Effective Permissions On Test Account

  1. Locate a testing user account in AD and open Properties:

  1. 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)

  1. Go to Effective Access tab > Select a user > pick the AD DS Connector Account – from section Identify the AD DS Connector Account)) – and click View Effective Access

  1. Confirm if the AD DS Connector Account – from section Identify the AD DS Connector Account)) – has permissions over this test user account


Verify Builtin Container Permissions

  1. Open the properties of the Windows AD “Builtin Container” -> Security
  1. Check if the AD DS Connector Account – from section Identify the AD DS Connector Account)) – has access permissions as follows

  1. Open the properties of the Administrators group and check if the AD DS Connector Account – from section Identify the AD DS Connector Account)) – has access permissions as follows

  1. Check is “Authenticated Users” is a members of the group “Pre-Windows 2000 Compatible Access”


Check Security and Group Policies

  1. Check in the Local Security Policy (Start -> Secpol.msc) that “Security Settings\Local Policies\User Rights Assignment\Impersonate a client after authentication” is currently enabled and including the default values:By default, this setting is Administrators, Local Service, Network Service, and Service on domain controllers and stand-alone servers. From: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/impersonate-a-client-after-authentication 

  1. Confirm if AADConnect Server is not receiving any Group Policy that is overwriting the “Impersonate a client after authentication” setting:
    1. Start a command prompt with Run As Administrator
    2. run: gpresult /H gpresult_AADC.htm
  2. Repeat the same step on the domain controller
    1. Start a command prompt with Run As Administrator
    2. run: gpresult /H gpresult_DC.htm
  3. 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.

  1. 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.
  2. In a browser on the machine running AADConnect, verify what it is able to get to / what is displayed when opening https://ssprdedicatedsbprodscu.servicebus.windows.net/  or https://ssprdedicatedsbprodncu.servicebus.windows.net 
  3. Does the following PowerShell command successfully connect?Test-NetConnection -ComputerName ssprdedicatedsbprodscu.servicebus.windows.net -Port 443 Test-NetConnection -ComputerName ssprdedicatedsbprodncu.servicebus.windows.net -Port 443
  4. Can they connect to the IP addresses listed at https://techcommunity.microsoft.com/t5/service-bus-blog/azure-wcf-relay-dns-support/ba-p/370775  over port 443?
  5. Does their AAD Connect server, support TLS 1.2 and the required ciphers?Verify AD Connect supports TLS1.2 and PowerShell Script to Enable Supported Ciphers for TLS1.2 
  6. 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

Enable LDAP verbose logging

On the Domain Controller used by the ADConnect box, enable Active Directory Diagnostics event logging: https://support.microsoft.com/en-us/help/314980/how-to-configure-active-directory-and-lds-diagnostic-event-logging 

  1. Open the Registry Editor and navigate to the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics
  2. 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:

  1. The time stamp when the error occurred, including the time zone (or the date/time in UTC)
  2. A screenshot of the error
  3. 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
  4. 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
  5. Capture the Directory Service event logs.