Addressing Gaps Between Active Directory and Microsoft 365 Security

Things you may encounter when integrating Active Directory and Microsoft 365 security

Below are some of the key things you may encounter when integrating Active Directory and Microsoft 365 security.

Problem: Users are not receiving password notifications

In Active Directory, by default, domain members are required to change their password every 30-days, and they will receive a bold notification informing them that their password is about to expire. This period can be extended, or you can disable password changes completely. However, users who only connect to Microsoft 365 will never be prompted to change their passwords. In this scenario, they may find themselves locked out of their on-premise AD account, yet still able to login to Microsoft 365. Obviously, this is not what we want. So why does this happen and what can be done about it?

Solution: Create a PowerShell script to notify users via email

As it stands, perhaps the most practical solution to this problem is to create a PowerShell script that periodically checks for Active Directory passwords that are about to expire, and then automatically notifies the user via email, prompting them to change their password. You can also periodically resend the email until the user changes their password. If they fail to change their password, they will be locked out of their Microsoft 365 account, and will have to use the Self Service Password Reset functionality, to get back in.

Problem: Password policy changes are not synced properly

Both on-premise Active Directory and Microsoft 365 enforce password policies in different ways. Organizations who use the Azure AD Connect “password hash” synchronization sign-in method to accomplish hybrid identity, will experience a similar problem to the one above. A user’s on-premise Active Directory password may expire, yet they can continue to logon into their Microsoft 365 environment, forever. The reason for this is that when using Azure AD Connect, passwords are set to “never expire” to ensure that each user only has one password – the on-premise password.

Solution: Enable the EnforceCloudPasswordPolicyForPasswordSyncedUsers feature

Microsoft has provided a solution to this problem, which requires using PowerShell to enable the EnforceCloudPasswordPolicyForPasswordSyncedUsers feature. This feature will ensure that any password policy changes in your on-prem AD are synced to Microsoft 365. If you’re wondering why this feature isn’t enabled by default, it’s more than likely because it wasn’t really an issue before COVID-19. The pandemic forced a large number of employees to work from home, which meant they were no longer accessing the network via the on-premise Active Directory login form. This in turn meant that a larger number of employees were no longer receiving password policy notifications from AD, which is when organizations began to notice the problem. We will no doubt see this feature enabled by default in the near future.

Problem: Expired accounts are not recognized

Accounts in Active Directory can be Disabled, Expired, or Locked. A user cannot login to a Microsoft 365 account that has been disabled or locked in Active Directory; however, Microsoft 365 does not know when a user account in Active Directory has expired. Perhaps the user account that expired was set up for a temporary worker, or perhaps it was because the account owner’s password expired. Whatever the reason, the user will still be able to access their Microsoft 365 account.

Solution: Run a script to either set the expired account to disabled, or move expired accounts to a separate OU

Firstly, since we know that Microsoft 365 recognizes accounts that are Disabled, to address the problem we can run a PowerShell script that automatically sets the expired account to disabled in Active Directory. A second option would be to run a script that automatically moves any expired accounts to an Organizational Unit that is not synced to Microsoft 365. In both scenarios, the user(s) will no longer be able to login into their Microsoft 365 account. The script could also perform certain clean-up operations, such as disabling expired email accounts, deleting or achieving data, removing the Microsoft 365 license from the account, or any other relevant tasks.

If you’d like to see how the Lepide Data Security Platform can help you improve AD and Microsoft 365 security, schedule a demo with one of our engineers or start your free trial today.