12-18-2019 09:41 AM
12-18-2019 09:41 AM
Hi guys, hope you have some tips for me..
We deployed Azure AD Domain Services to be able to set up Windows Virtual Desktop. Cloud-only user accounts.
Deployed a host pool and the management available from GitHub - and it all looks very good - no red crosses anywhere.
Added 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.
Accounts 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:
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..............
Normally this is easily fixed (System Properties - Remote tab), but the good old fix do not apply on Windows Virtual Desktop. I have destroyed the hostpool and rebuilt. I have added several hostpools and fooled around with how I add user accounts to each hostpool but the results are the same. 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 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.
Since the rest of our Azure deployment do not depend on AADDS, I am tempted to destroy the whole thing and start over. I am just a bit worried that I'll end up with the same mess all over again.
Sorry for the long post, if anyone have the possibility to shed some light on this I will be forever grateful.
12-18-2019 04:56 PMSolution
@HenrikBryne : Can you run Diagnostics to get the exact error message for the user? Similar to this: https://docs.microsoft.com/en-us/azure/virtual-desktop/diagnostics-role-service#filter-diagnostic-ac...
But please run
$activities = Get-RdsDiagnosticActivities -TenantName <tenantName> -ActivityType Connection -Outcome Failure -Detailed
You can then expand $activities to see individual items. If you look at a specific item, you can then expand the Errors property to see the detailed error that might indicate why the connections are failing.
12-18-2019 07:22 PM - edited 12-18-2019 07:25 PM
My user is same issue. give me follow this topic.
- the issue is occur when use remote desktop application but not occur when use on browser
12-18-2019 11:55 PM
@christianmontoya I just found my mistake..
The user accounts were created before AADDS was deployed, and the admin accounts was created after the deployment. It seems there is a password hash sync issue in that scenario. Text from the docs:
"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. 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. For security reasons, Azure AD also doesn't store any password credentials in clear-text form. Therefore, Azure AD can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials."
"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. 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."
So the answer to all my trouble was right there. Reset the password (and re-login to PC with updated password) was all it took for this deployment to work perfectly.
I thank you guys for your answers, appreciate it.