This post is part of the overall MS-500 Exam Study Guide. Links to each topic as they are posted can be found here.
Previously in this study guide, we have looked at planning Azure AD Authentication Options such as Pass-Through Authentication, Password Hash Synchronization etc. We have also looked at planning and configuring AD Connect synchronization options. To recap, the authentication options we have available for users are:
- Cloud Managed Passwords (no synchronization)
- Password Hash Sync (with optional Seamless SSO)
- Pass-through Authentication (with optional Seamless SSO)
- Federation (via ADFS or PingFederate)
Each of these options can be enabled via the AD Connect wizards “”User Sign-In” page. AD Connect makes this process very easy for configuration, however, they all add some level of reliance on our on-premises infrastructure. If there is an issue with the local AD Domain Services, AD Connect or ADFS farm, the following steps can be used to modify the authentication options from the cloud and regain user access:
To disable Federation for a domain without access to AD Connect / ADFS, connect to MSOnline PowerShell and run the command: “Set-MsolDomainAuthentication -DomainName FederatedDomain.com -Authentication Managed”. This will convert the domain “FederatedDomain.com” (Replace with your own domain) from federated authentication to managed authentication. If Password Hash Sync is enabled, this will take over, if it’s not enabled, users will have cloud only passwords which you can reset for them from the admin console.
To disable a single Pass-Through Authentication Agent, the following command can be run from the server running the agent:
Import-Module "C:\Program Files\Microsoft Azure AD Connect Authentication Agent\Modules\PassthroughAuthPSModule\PassthroughAuthPSModule.psd1"
Disable-PassthroughAuthentication -Feature PassthroughAuth“
To disable AD Connect completely in the event that you rebuild, decommission or otherwise lose access, the command “Set-MSOLDirSyncEnabled -EnableDirSync $False” can be used in the MSOnline Powershell Module to turn off AD Connect completely from the cloud, converting all objects to cloud managed. This should be a last resort in the event that the on-premises infrastructure is not recoverable as it will disable all synchronization between on-premises and cloud.
Self-Service Password Reset
Another option we’ve seen in the AD Connect configuration is Password Writeback. This option allows the synchronization of password changes to flow from Azure AD to our on-premises infrastructure. While there are a few instances where this can be useful, the biggest benefit we see from this functionality is providing users with Self-Service Password Management.
If we take a common example where a user does not connect to the corporate network for months at a time, this means their password expires in Active Directory and causes problems when they try to access services through ADFS or PTA. There are also problems caused when the user eventually returns to the office or connects VPN.
Traditional solutions would see us providing a process where the user updates their password over VPN, or through our ADFS portal. Password writeback and Self-Service Password reset allows us to benefit from the native security features of Azure AD, like MFA, to give our users a secure, cloud-based, self-service password management utility without very little admin overhead in configuration or maintenance. The password writeback functionality allows this password change to propagate to our on-premises directory, meaning that the user can update their password via SSPR, and this will be written to Active Directory for use with any on-premises authentication also.
Once Password Writeback is enabled, configuration of SSPR is straightforward. We open up our Azure AD portal and navigate to the “Password Reset” section. Here we can see the list of options available to us for configuration.
First we need to configure our scope, keep in mind that an Azure AD Premium license is required for SSPR and on-premises writeback.
When we have selected our group, we can then select the verification options to make available to them during reset. We can also specify if we require one or two verification options for a user to reset their password. For security reasons, I would recommend requiring two options, it’s not a common activity our users should be carrying out so the extra security justifies the additional step.
Next we can configure if we would like to prompt our users to register when they next sign-in. With this enabled users will be brought to the SSPR registration page and asked to fill in the details we required in the previous step. We can also set a time period to ask them to confirm their details, 180 days by default.
Next we have some standard notification settings. We decide if we want users to get a notification when their password is reset via SSPR (I see no reason to ever disable this), and also if all admins should be notified when an admin accounts goes through the SSPR process.
We can add in a custom help link or email address to our SSPR page.
We can then configure our Password Writeback option which we enabled in AD Connect and decide if we can let users unlock a locked account without resetting their password.
We can also easily access a filtered log view showing password reset activity in our tenant.
We’ve gone through pretty much all of the above in detail in previous posts but the authentication process is key to securing our Azure AD / Microsoft 365 identities. Below are some of the other posts which relate to this topic if you would like to recap: