Accounts are expired in Azure Active Directory Domain Services (AAD DS) even if the PasswordNeverExpires was set to true RRS feed

  • Question

  • Hi

    Just had the honor to fix our test-environment one more time due to this nasty behavior.

    MySetup: I have several accounts (administrators, service-accounts) in my Azure Active Directory. This Azure Active Directory has Domain Services enabled, so that this accounts can be used in our Virtual Machines, hosted on Azure and Domain Joined to excat this Domain Services. Some of the Accounts are service-accounts (i.e. to query the LDAP) or Administrator-Accounts to access the machines by RDP

    The Issue: After 30 Days if the last password change, every accounts gets disabled in the Domain Services. Login with the accounts still works on all the web portals provided by MS (i.e. portal.office.com, portal.azure.com) but the accounts are disabled in the Domain Services! Services cant start anymore, RPD fails, Windows Integrated Web Logins fails,....

    And yes i have the option "PasswordNeverExpires" enabled for all those accounts. In fact, the expiration is set to 90 days, anyway. Link: https://www.petri.com/reset-azure-active-directory-user-password-set-never-expire 

    This problem is also mentioned here https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/11457978-azure-ad-domain-services-is-forcing-me-to-change-p

    Expected: When enabling this "PasswordNeverExpires" with PowerShell-Modules, this setting should be considered when syncing the users from AAD to the Domain Services environment.

    If not, an administrator is forced to remote login, and change every service-account, every 25 days! Same applies for users. Thats a clear showstopper and I'm actually thinking in migrating to the AWS solution for this. How is it possible to enable a preview feature that lasts 30days only?

    Is there a workaround for that? Seems that I'm not the only one having that issue


    • Edited by emTwoCode Saturday, March 26, 2016 10:13 AM
    Saturday, March 26, 2016 10:12 AM

All replies

  • Hi Michael,

    Thank you for posting in here.
    We are currently researching on this and will keep you posted with the findings.
    We appreciate your patience.


    Sunday, March 27, 2016 8:49 AM
  • We are having the exact same issue.  I have several service accounts that my web sites are running as and every 30 days the passwords are expiring.  The thing is, they are only expiring on the Virtual Machines.  The accounts can still log into Azure or any web based application that uses Azure AD as the authentication mechanism.
    Tuesday, April 5, 2016 5:43 PM
  • Are there any updates on this issue?
    Monday, April 11, 2016 6:39 PM
  • Michael, apologies for the trouble this has caused you. We are aware of this issue. Currently, the 'password never expires' attributes on user objects aren't being reflected in the AAD-DS managed domain. We're working on a fix for this and hope to have it resolved soon.

    One possible workaround for service accounts is that you can create a custom OU and create service accounts within that OU. You can then set the password never expires attribute for this OU.


    Thanks for the patience until we resolve this.

    Tuesday, April 12, 2016 4:52 PM
  • Hi Mahesh

    Thanks your your information about the fix and the interesting documentation. We have been searching for that feature so long. Since this documentation is pretty new, I assume that the feature to create own OU's is also pretty new?

    I think we are going to migrate our AAD Accounts into AAD DS cccounts only, since we need them only in the AAD DS Environment on not to login on Cloud Services.

    But anyway, Account Expiration Dates and Password Never Expires should be synced, even for "normal" accounts.



    Tuesday, April 12, 2016 5:04 PM
  • Yes Michael, the feature is fairly new. I totally agree about your point regarding the password expiry lifetime & password does not expire attributes needing to sync. We are working on fixing that.

    Meanwhile, could you please contact us using the instructions at the link below. We'd like to try to unblock you via a workaround until this is resolved.


    Tuesday, April 12, 2016 8:30 PM
  • Nick, could you please contact us using the instructions at the link below. We'd like to try to unblock you via a workaround until this is resolved.


    Tuesday, April 12, 2016 8:30 PM
  • is there any eta on when this issue is fixed?

    we are having the same issue. 

    Thursday, April 14, 2016 7:56 AM
  • i just followed the create custom OU:

    There is a warning:

    User accounts, groups, service accounts and computer objects that you create under custom OUs will not be available in your Azure AD tenant. In other words, these objects will not show up using the Azure AD Graph API or in the Azure AD UI. These objects will only be available in your Azure AD Domain Services managed domain.

    For me this is a pure workaround. I want to have all users in the so called "Azure AD tenant". Thats the point why i am using Azure AD! A single place to manage the users. I consider this as a workaround for the time until you've fixed the issue.

    i hope this has any priority in your backlog, it is hurting us! and probably every single guy using the AAD.

    Thursday, April 14, 2016 8:21 AM
  • Tobias, if you could please contact us using the instructions at the link below, we can set the password expiry lifetime for your managed domain to match that of Azure AD. We are working on a fix for this. 


    Thursday, April 14, 2016 5:35 PM
  • I am having a very similar problem.  I am using AAD DS and all our user accounts including administrator accounts have been inherited from our Office 365 accounts.  In Office 365 we have specified that passwords should NOT expire.  However it seems that in the Azure VMs environment they are expiring after about 90 days.  I can find no way to adjust this in Domain Services - all greyed out.

    So I think it is a problem with the syncing of settings between Office 365 accounts and AAD DS.

    Is this defect still live?

    Monday, September 19, 2016 11:37 PM
  • Please give us an update on this, this is a critical problem for us as well!

    Friday, February 24, 2017 12:44 PM
  • Any update on this?
    Thursday, May 18, 2017 3:39 PM
  • Hi, it seems not updated even now. Could you tell us something about this problem?
    Tuesday, February 27, 2018 2:15 PM
  • Looking for an update regarding this... thanks. 

    Monday, July 30, 2018 1:10 PM
  • Hello All,

    Quoting from the FAQ page.

    The default password lifetime on an Azure AD Domain Services managed domain is 90 days. This password lifetime is not synchronized with the password lifetime configured in Azure AD. Therefore, you may have a situation where users' passwords expire in your managed domain, but are still valid in Azure AD. In such scenarios, users need to change their password in Azure AD and the new password will synchronize to your managed domain. Additionally, the 'password-does-not-expire' and 'user-must-change-password-at-next-logon' attributes for user accounts are not synchronized to your managed domain.

    Suggest you all to comment on the feedback item and up vote for the feature.

    If this answer was helpful, click “Mark as Answer” and Up-Vote. To provide additional feedback on your forum experience, click here 

    Saturday, August 4, 2018 4:33 PM
  • Hi

    A possible work around is to use this powershell command from a domain joined Azure VM just after creating a Azure AD user to force the account's password to never expire on the Azure AD Domain Services.

    Set-MsolUser -UserPrincipalName username@domain.com -PasswordNeverExpires $true

    Best regards

    Christian Winther Kristensen

    Monday, October 15, 2018 1:59 PM
  • This is due to Azure AD domain services and Azure AD having separate password policies.  You can now changed the Azure AD domain services password policy with FGPP.  Reference https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-password-policy
    • Proposed as answer by Nayuta Ishii Tuesday, October 30, 2018 10:39 AM
    Friday, October 26, 2018 8:31 PM