Feedback by UserVoice

How can we improve compliance or protect your users better in Office 365?

← Office 365 Security & Compliance

Active Directory AccountExpires attribute does not stop login to Office 365

We discovered a security flaw in Office 365 whereby if you set an account in Active Directory to expired, the user can still login to Office 365.

We believe this is a major security flaw as many customers will believe if the user can no longer log in to the Active Directory domain then they must also not be able to login to Office 365, however this is not the case.

Setting an account with an expiry date should stop the account from logging into Office 365 as well.

677 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Darren Hurst shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

31 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Nick Assar commented  ·   ·  Flag as inappropriate

    It's bad enough that anyone can "Azure AD register" their system for a 90-day loginless experience, but add this issue to that and its a recipe for the worst security implementation ever designed. It's shameful this issue persists for 3+ years with no comments from MS.

  • Dan M commented  ·   ·  Flag as inappropriate

    Consider switching to PTA or running an automation job to set the account as disabled. When you expire accounts, you could also move them into a non-sync'd OU in AD.

  • Anthony L. commented  ·   ·  Flag as inappropriate

    For such a major security flaw it is unacceptable to have a workaround solution. This needs to be resolved at a platform level ASAP.

  • Dylan Skeels commented  ·   ·  Flag as inappropriate

    HUGE security flaw, we use this in our district for various things and to find out it doesn't actually lock users out of 365 is just horrible. Please fix ASAP!

  • C.M.Ramos commented  ·   ·  Flag as inappropriate

    Like the broken HideFromAddressLists attribute sync, this is a fundamental security item that should have been fixed in the builtin Sync Rules for AD Connect. Too many Disprovisioning processes and workflows are built around whether an account is Disabled that should not apply to an Expired Account that may or may not been an innocent lapse in the accounts renewal/extension approval, but the Account should immediately cease to function across all platforms until the Expiration is extended or the account truly Disabled. Please make this fix a priority.

  • Anon I Mouse commented  ·   ·  Flag as inappropriate

    Its August 2020 and this is a major security flaw, plain and simple. And to have it on going since dirsync was first created to syncronize on-prem AD to Azure AD is staggering. MS will say this is mitigated through other security meaures and conditional access rules. That may be true for customers that are able to afford those types of licenses. This is a foundational issue that should not be acceptable at all. Get on the ball, Microsoft - fix this permanently.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Hello, today is July 30, 2020, and this compliance issue still exists. This issue has been open for 1301 DAYS! This can't be that hard to address. It's just another property field that the sync tools need to compare and update. For those of us in regulated industries, this could lead to millions of dollars worth of fines.

  • Clive commented  ·   ·  Flag as inappropriate

    This needs to be addressed so that it does not require tinkering with scripts to solve.

  • Evan Nichols commented  ·   ·  Flag as inappropriate

    I solved this problem with a Sync Rule expression referencing an extensionAttribute we are populating with MIM.
    We're using extensionAttribute5 to mark "Enabled" or "Disabled" based on whether they are disabled or expired.

    IIF(BitAnd([userAccountControl],2)=2,False,IIF(IsPresent([extensionAttribute5]),IIF([extensionAttribute5]="Enabled",True,False),True))

  • Nagappan Veerappan commented  ·   ·  Flag as inappropriate

    https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization#account-expiration
    ==============
    Account expiration

    If your organization uses the accountExpires attribute as part of user account management, this attribute is not synchronized to Azure AD. As a result, an expired Active Directory account in an environment configured for password hash synchronization will still be active in Azure AD. We recommend that if the account is expired, a workflow action should trigger a PowerShell script that disables the user's Azure AD account (use the Set-AzureADUser cmdlet). Conversely, when the account is turned on, the Azure AD instance should be turned on.

    =====================

  • Mark Joseph commented  ·   ·  Flag as inappropriate

    Office 365 Group, Do we have any other alternative on this concern? aside for manually running a script to disable account from local AD? or setup a auto schedule script to disable account?

  • Phillip commented  ·   ·  Flag as inappropriate

    I confirmed this a while back and opened a ticket with Microsoft, who said it was not a flaw or a bug but rather a feature request. Kenneth's recommendation of resetting the user's AD password upon account expiration using a script is a great idea.

  • silvia.bottini@zegna.com commented  ·   ·  Flag as inappropriate

    We need this checck to ensure the correct alignment from Office365 and our applications.
    The users have no evidence why they cannot log in the Company's tools because it seems that office365 trusts their account.

← Previous 1

Office 365 Security & Compliance: Advanced Security Management

Categories

Feedback and Knowledge Base

(thinking…)

Related Sites