Jul 162020
 

The following are my notes for setting up Azure AD 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. Note that if you only want to invite Gmail.com users you can use 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 up single sign-on (SSO) for SAML applications

  1. Choose Download Metadata, and save the returned GoogleIDPMetadata.xml locally

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

  1. From https://support.google.com/a/answer/6363817?hl=en  follow Step 3. “Set up Google as a SAML identity provider (IdP)” and Browse to https://admin.google.com -> Apps -> SAML Apps -> New App
  1. Filter existing apps by “Microsoft Office 365” and add 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 as follows
     
IDPEmail* Basic Information Primary Email
urn:oasis:names:tc:SAML:2.0:nameid-format:persistent Basic Information Primary Email
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress Basic Information Primary Email
  1. From https://support.google.com/a/answer/6363817?hl=en  follow Step 4. “Enable the Office 365 app” and Choose Edit Service -> Service Status -> ON for everyone
  1. 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 G Suite credentials to redeem invite successfully

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

    example:
image.png
  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

image.png
  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
image.png

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
image.png
image.png
  1. Confirm that Authenticated users have the following default permissions
image.png
  1. Confirm that Everyone has Everyone have the following default permissions (Deny + Allow):
image.png
  1. Confirm that AD DS Connector Account – from section Identify the AD DS Connector Account – have the following default permissions:

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

image.png

Verify Effective Permissions On Test Account

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

image.png
  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)

image.png
  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

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

image.png

Verify Builtin Container Permissions

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

image.png
  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

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

image.png

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 

image.png
  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.

image.png

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.