Set an AzureAD account to expire on a specified date
Just like in active directory allow accounts to be set to expire on a specified date. Our company policy is to set network accounts for non-employees (consultants, contractors, temporary employees, interns) to expire at a certain interval after they are created. We want the same functionality within Office 365.
Thank for letting us know this is important to you. This is something we are considering, but there is no timeline yet. We would love to hear more about the specific scenarios that this is needed for, so keep providing info.
Rob McCann commented
Request logged in Sep 2016, response in Aug 2020 - only 4 years to respond...
Use case for this is simple - making sure an account is disabled without needing to use Identify Protection to run a report to disable the account or rely on a third party solution to do this for you.
This is a no brainer. Can't believe it is not an option in AAD.
3rd party, partner and contractor access.
Tom Craven commented
Yes, we normally set contractors to expire at the end of their engagement.
Need this feature to automate deletion of Test Accounts that are required for a short amount of time.
Contractor and temporary account management.
Expired accounts synced from AD should be automatically disabled from AzureAD as well.
BK Rogers commented
We have contractors , however the business does not always let us know when the contract has ended. By setting an expiration date we are able to periodically force the business to re-authorized access.
Specific scenario's would be exact account management. People departing the company at some point in time, when it's known, would be great to have it exactly set.
Is there a way to have it look at HR Connector (in Insider Risk Management) as well?
there people can upload a resignation date and departing date. that would be great to have it linked to expiry of the account in O365
Ashleigh Green commented
Limited time access for guest accounts, limited time based access for third parties including partner and contractors. Setting expiry dates as part of offboarding.
We rely on AD account expiration to ensure that temporary / contracted employees and third party accounts are disabled or reviewed periodically. We need AAD to support this feature too or we can never get out of hybrid AD mode and have to rely on custom powershell scripts to maintain the same functionality.
Simply put - there are many use cases where you need to set an account to expire at a set date in the future and today Azure AD doesn't support that at all.
Contractors or Temporary employees that we need to give a corporate account to for x days, weeks, months and we want them to auto expire at specified time.
Alberto Farías commented
In our case we provide financial information service. The clients are external users of the AAD, so it is very attractive to define an access expiration period based on the time without access to the system.
Need the ability to expire GUEST ACCOUNTS after X days of inactivity. So many use cases where different areas of our org partner with external participants in SharePoint and Teams but no reliable way to clear out stale accounts
I am super happy to hear that this is now under review. We manage access to resources based on the user HR contract terms, which is currently managed by on-prem AD using the start and end-date of the account. We are not able to move fully to Azure AD without this capability. Basically, services are denied automatically when the user account expires or goes after the account end-date. When you have a lot of staff turnaround, this becomes support important and the only to manage access to resources.
We are multinational org with offices around the world, when hiring a field staff member as contractors there is an end of contract date, without an account expiration it becomes a huge burden on IT to ensure those accounts properly terminated, this is not to mention temp, intern, and short term staff. I would love to hear if MS have other working options to ensure account mgmt is implemented properly in accordance with standard security protocols that we all need to follow (hopefully) to be compliant?
Saying that this is disappointing would be an understatement. Now in my company we have 90% of staff cloud only based in AzureAD and managing leavers ( people leaving ) is a nightmare. At the moment I'm managing it by adding an extension-attribute to the user and check every day ( Azure automation ) if a user has that attribute, check if the date in the attribute is already passed and block the user in case it it. It works but it's not the best..
Thomas G commented
This is something that has been available for decades in Windows server AD. The ability to set an expiration date for an account is essential for me as a security professional. Without this, we have no way to set end dates in advance. This again may lead to accounts not being blocked because people forget, or they are busy.
Matthias Peplow (S&F Family) commented
we have Azure Active Directory Sync with our on premise AD set up. Our current joiner/leaver processes depend on the expiry date of an account. We had some serious issues becaus people with expired AD accounts were still able to access their Microsoft365 services. There should be feature parity for compliance related AD attributes.
Gregory Barille commented
I'll give you an exemple from my compagny. We do manage schools and we have around 100k permanent users ( teachers and students ). That's people we have offical information on and can provision automatically.
Unfortunately the reality is that in each shcools we have people that we don't have informations on, cooks, nurses, someone external coming from time to time to do some work that needs an account as we use it to authenticate the Wifi for exemple. We need to set an expiration date to avoid a security risk. As we don't have way to know when they will come and go from the school it's the only way to minimize risks. That's one reason why we wouldn't be able to get rid of our on-premise active directory and we still need to be using an hybrid system.
Please can this be looked into, we want to move to Azure cloud only, but this is quite a drawback from a security perspective