Closed adrian-keith closed 2 years ago
@lXbalanque We apologize that you did not have a good experience however we will be happy to help you further on this. We will investigate on this and will provide your an explanation . If needed we will help you with alternate options and surely make sure that your project does not suffer. Please allow us 2-3 hours and we will try to provide you more information on this.
@lXbalanque , I am still testing few scenarios, will update you with my findings. Thanks
@lXbalanque , We Apologize for the inconvenience caused however we are happy to help you on this issue.
Yes, “NTLM Password Synchronization” must be enabled for synchronized user accounts to use NTLM authentication in the managed domain. In additional to that user account must be part of “synchronization scope” and either user must reset/change password using self-service (or) administrator reset user’s password by sharing temporary password so that user can setup new password for their account.
This process basically synchronizes user’s password hash to managed domain (AADDS) and without this password hash AADDS fail to validate user’s authentication.
User change password self-service:
Admin Reset Password user's password:
To answer your questions:
How long does it take to synchronize password hash? It happened very fast which hardly took ~2-3 minutes to updated password hash of the user when I tested in my lab.
How can I tell if the password hashes have been generated? Are there any PowerShell commands I can run to check if a hash has been properly created? For this, you need to have RSAT (Remote Server Administration Tools) installed on VM which has joined to AADDS managed domain and login with account which is member of “AAD DC Administrator group”.
UI Way to verify: Launch “Active Directory Users and Computers” wizard (dsa.msc) , expand domain name, and click on “AADDC Users” OU and find respective user then go to “Attribute Editor” as shown below:
Note: If you don’t see Attribute Editor then make sure “Advanced features” is enabled under view option:
If you see pwdLastSet as (never) which represent user never change their password since enabled AADDS service by this way we can verify if new password updated or not.
PowerShell Way using Active Directory module:
Open PowerShell and execute following cmdlet Get-ADUser <username> -Properties pwdLastSet, PasswordLastset
, this would list out PasswordLastSet for given user. In this example you could see timestamp which indicate Password hash been updated in that particular timestamp.
In case if you see pwdLastSet timestamp doesn't match with user’s password reset time window then new password hash probably not synchronized yet.
However, if see match in timestamp between AADDS and Azure AD for given user but still facing login issue then here are some possible causes that I could think of in our scenario:
Scenario
Possibly, Non-working user account might have locked out in AADDS managed domain, you can verify this by going to user properties as shown below. To unlock user account, find the user object in the dsa.msc snap-in, open its properties, go to the Account tab, check the option “Unlock account. This account is currently locked out on this Active Directory Domain Controller” and press OK.
A user account in an Azure AD DS managed domain is locked out when a defined threshold for unsuccessful sign-in attempts has been met. By default, if there are 5 bad password attempts in 2 minutes, the account is locked out for 30 minutes.
To know more, refer what is account lockout in AADDS.
So when you use Bastion for connecting to remote connections, please be aware of these behavior:
Bastion Way connecting error for lockout as well for unauthorized remote login:
RDP Way connecting: (Message of when account locked out)
RDP Way connecting: (Message of when the user not added to RDS local group in VM)
So please make sure , if user account is not locked out and user account is part of Remote desktop user in local group as shown below:
If none of these isolate the issue, then please let me know so that we can setup meeting and take it offline. Thanks
@lXbalanque , I just wanted to check in and see if you had any other questions or if you were able to resolve this issue? We will now close this issue. If there are further questions regarding this matter, please tag me in a comment. I will reopen it and we will gladly continue the discussion.
I'm having a lot of difficulty getting this working correctly, and quite frankly its become frustrating. I've submitted tickets with Azure support but even with severity level A selected, the time to hear back from someone is absurdly long.
We are all in on Azure. It is all cloud, no on-premise environment. Azure AD DS was set up, then users were created in Azure Active Directory. Initially, I had problems getting VMs to join the domain as I could not use my global admin credentials. I later discovered that during AAD DS setup, we disabled NTLM Password Synchronization. After enabling this and resetting my GA account's password one more time, I was finally able to successfully join VMs to the domain, and then, I was able to log in with the account via Azure Bastion.
Now comes the painful part. I set up two new accounts for developers who will be working for us. I logged in, performed the initial password reset as required after first logon. Tried to log into the VM via the Bastion host but it didn't work. I reset the password again just to make sure and its now been over an hour and I still can't log into the VM via the Bastion. I am using the UPN format (username@domain.com) but nothing ever works. I can't see what I'm missing if I was previously able to reset the password for my account and another test and successfully log into the VM.
This section does not appear to be fully detailed.
For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. The account isn't synchronized from Azure AD to Azure AD DS until the password is changed. Either expire the passwords for all cloud users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct cloud users to manually change their passwords. For this tutorial, let's manually change a user password. Before a user can reset their password, the Azure AD tenant must be configured for self-service password reset. To change the password for a cloud-only user, the user must complete the following steps: Go to the Azure AD Access Panel page at https://myapps.microsoft.com. In the top-right corner, select your name, then choose Profile from the drop-down menu. Select profile On the Profile page, select Change password. On the Change password page, enter your existing (old) password, then enter and confirm a new password. Select Submit. It takes a few minutes after you've changed your password for the new password to be usable in Azure AD DS and to successfully sign in to computers joined to the managed domain.
How long is "a few minutes? How can I tell if the password hashes have been generated? Are there any powershell commands I can run to check if a hash has been properly created? I can't log in with new accounts I'm creating and its making it difficult to push this project forward. Thanks.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.