- #NLA DISABLE REMOTE DOMAIN UPDATE#
- #NLA DISABLE REMOTE DOMAIN PASSWORD#
- #NLA DISABLE REMOTE DOMAIN WINDOWS#
#NLA DISABLE REMOTE DOMAIN PASSWORD#
You can either expire the passwords for all users in the tenant who need to use Azure AD DS, which forces a password change on next sign-in, or instruct them to manually change their passwords." This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD. "For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials." For security reasons, Azure AD also doesn't store any password credentials in clear-text form.
Azure AD doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Azure AD DS for your tenant. " To authenticate users on the managed domain, Azure AD DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. It seems there is a password hash sync issue in that scenario. The user accounts were created before AADDS was deployed, and the admin accounts was created after the deployment. Sorry for the long post, if anyone have the possibility to shed some light on this I will be forever just found my mistake.
I am just a bit worried that I'll end up with the same mess all over again. Since the rest of our Azure deployment do not depend on AADDS, I am tempted to destroy the whole thing and start over. I have tried searching for an answer but everything I find is related to on-prem RDS deployments where the attempted solutions do not apply to WVD - simply because we do not have access to the backend infrastructure. On every hostpool I deploy I have the exact same problem - accounts with admin rights logs right in and standard accounts get this error message.
I have added several hostpools and fooled around with how I add user accounts to each hostpool but the results are the same. I have destroyed the hostpool and rebuilt.
#NLA DISABLE REMOTE DOMAIN WINDOWS#
Normally this is easily fixed (System Properties - Remote tab), but the good old fix do not apply on Windows Virtual Desktop. The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA. Cloud-only user accounts.ĭeployed a host pool and the management available from GitHub - and it all looks very good - no red crosses anywhere.Īdded user accounts to appgroups both using PowerShell and the management portal without noticing any difference - it looks good when I run the Get-RdsAppGroupUser commands as it lists accounts generated both ways.Īccounts that are member of the AAD DC Administrators logs in to the VDI perfectly, but "normal" user accounts get an error message that look like a flashback from RDS-deployments: We deployed Azure AD Domain Services to be able to set up Windows Virtual Desktop. I found a reboot will help, depending on the OS of the Server.Hi guys, hope you have some tips for me. Server\WinStations\RDP-Tcp” /f /v SecurityLayer /t REG_DWORD /d 0Īfter you can try to RDP into the server. PASSWORD reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Psexec \\VMNAME -u VMNAME\ADMIN_ACCOUNT -p VMNAME\ADMIN_ACCOUNT – The username of a localĪdministrator on the machine on which you want to disable NLA (SERVER_NAME\admin) \\VMNAME – The name of the machine on which you want to disable
#NLA DISABLE REMOTE DOMAIN UPDATE#
Then you need to run the code below, to update the registry keys with the right When this occasion occurs, I always use one of my favorite Remote computer, you can disable NLA by using the options on the Remote tab of Requires Network Level Authentication (NLA), but your Windows domain controllerĬannot be contacted to perform NLA. “The remote computer that you are trying to connect to When he tried to access his Azure VM throughĪn RDP session, he got the following message: Today, I received an email from a colleague, saying that heĬould RDP into his Azure VM after he rebooted the machine through the OS
0 kommentar(er)
