Azure AD Domain Services does not allow the user to unlock a domain account

Brian Campbell 36 Reputation points
2020-01-20T16:36:18.023+00:00

As per title, Azure AD Domain Services does not allow Domain Administrators to unlock user accounts. The user has to wait for 30 minute timeout to occur before the account unlocks. Please can we, the Administrator, please be allowed this most basic of AD Administration powers before the users gather with fire and pitchfork demanding our blood?

Microsoft Entra

5 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Shashi Shailaj 7,581 Reputation points Microsoft Employee
    2020-01-20T19:48:09.073+00:00

    Hello Brian ,

    We apologize for the inconvenience. At this point there the default password policy can not be changed within the AAD Domain services environment. We would request you to upvote the feedback item related to this . The feedback site is periodically reviewed by the product engineering and the votes on a feature help them prioritize the requests better.

    You can achieve smaller lockout times by using Fine grained password policy. As a workaround you can create a custom password policy and apply on the objects in AADDC users container in AAD domain Services environment. We understand this is not the solution you are looking for but at the moment this is the best workaround that can be used . We hope that this feature gets implemented in the product .

    Hope this helps. In case the information provided in the post helped please do mark it as answer. In case of any further queries, please do let us know and we will be happy to help.

    Thank you.

    0 comments
  2. Sergey K 1 Reputation point
    2021-03-18T18:40:34.957+00:00

    So bottom line, if you are using Azure AD Domain Service you can not unlock a user in AD?

  3. Simon Burbery 546 Reputation points
    2021-12-15T02:56:08.177+00:00

    The current funcationality is fine unless you have a very special use case - most scenarios requiring Active Directory in Azure should not involve exposing the service to the internet, so you can safely set the accounts to unlock after 1 minute. Then you don't need the ability to manually unlock an account. Azure Virtual Desktop as an example (which is awesome for publishing those legacy apps), you sign in to the AVD serivce using Azure AD first (with MFA etc), then enter the AD creds as you connect to the application or desktop. The AADDS environment is protected from any outside attack.

    Run the Admin Center, click on System then Password settings container. Create a new policy with the same settings as the default, but change 'Reset failed logon attempts after' to 1 minute, and 'account will be locked out for' to 1 minute, then set the precedence to 1 so it overrides the default policy.
    157685-image.png

    157696-image.png

    0 comments
  4. DSF 1 Reputation point
    2021-12-15T21:37:57.1+00:00

    I also don't understand why this is unable for Admins to do. the functionality is obviosity there because a user can do it via SSPR but an admin cant do such a basic function? Some users refuse to use SSPR and want IT to unlock them we should have the ability to do so via AzureAD. In our environment our users never unlock automatically because of regulations we are under so it must be unlocked via the user doing it in SSPR or they call IT and we unlock them. Having this is such a basic thing I don't understand why we cannot do it.

  5. Gustavo Puente 1 Reputation point
    2023-01-30T15:38:23.0366667+00:00

    @Simon Burbery Your replies are completely unhelpful, there are tons of reasons that people may be using AADDS, this "legacy" option is there for a reason.

    Have you even used it? if not, you shouldn't be commenting.

    Reason why people still use it:

    1. Because you don't wan't to host an AD domain yourself
    2. Because you like AD
    3. Because AADDS is an out of the box ready AD
    4. Because you don't like MDM or are not rewady to work witj intune or any other MDM tool
    5. Because you like GPOs
    6. Because you have remote workers that need to authenticate via VPN to AADDS
    7. Because you have "legacy" applications (like Bitbucket DC, Jenkins, GLPI, etc ,etc) that use LDAPs to authenticate
    8. And most important of all, because you decided to have a serverless AD domain, and didn't research enough when doing it. (Because in the information page of the service doesn't specify some of the limitations). And now you have hundreds of people in the service, and changing the infrastructure and network design is not an option. Reasons an account can get blocked and you need to unlock it (regardless of the policies):
    9. A user (or even a bot attack) locked and account via LDAPs
    10. A user forgot the password and locked the account in his windows device
    11. A "wrongly" published RDP access got under attack.

    The only issues I have had with AADDS (non of them specified in the AADDS information website).

    1. Azure AD users are loctaed in the "ADDS Users" OU, these users can't be moved from OU so when applying GPOs, you have to manually exclude administrators via GPO Security Filtering and Delegation
    2. Domain functional level: when I first set it up, it was on Server 2012R2, Microsoft has recently updated to Server 2016 (Not a big issue, and Microsoft is upgrading it so, that's cool)
    3. You can't expand AD schema (For example if you need custom attributes)
    4. You can't unlock accounts (the main topic of this post) This was true, and apparently Microsoft listened to it's costumers and now it is possible to unlock users.

    So, wrapping up.

    • If you don't "understand the regulations" (as stated on your first reply) you shouldn't be replying.
    • Your statement "most scenarios requiring Active Directory in Azure should not involve exposing the service to the internet" is not true.
    • Your statement "Then you don't need the ability to manually unlock an account" Is BS, and administrator should always be able to lock/unlock an account.
    • Your statement "I would suggest you are using the service in an unintended way" you know nothing about that person, network design, user schema design, policies, etc.
    • Your statement "Out of date" I don't think in anyway AD is an out of date system, and it will be probably maintained for many many years yet.
    • Your statement "I shudder at the thought of the AADDS team spending any amount of time to provide this feature!" - They did provide the feature
    • Your statement "but I question why anyone would require this functionality - what is it you are doing that requires this? If you do require it, then I would suggest you have chosen the wrong solution." BS in so many levels, this solution is perfect and very useful in many scenarios.
    • Your statement "Do you have on-premises AD and sync it to Azure AD? If so, your on-premises AD is the master of identity," Obviously not, he wouldn't be asking.
    • This types of questions are made to get helpful answers not to get criticized, on what you are doing wrong.

    I just read a meme, that perfectly applies to these responses.

    "Every time I have a programming question that I need help with, I post the question on Reddit and then log in with another account and get a ridiculously wrong answer. People don't like to help others, but LOVE to correct others. It works 100% of the time."