Hi, We have an issue where we want some users to connect via RAS to some non-domain joined PC's. We have confirmed that the actual process of connecting works. On the test PC's we are manually installing the RAS remote PC agent, and all is fine. But on new PC's, and when we need to update the agent, we cannot "push" the agent out to the PC's from the console because the RAS console insists on using the current domain admin username to attempt the push, which the PC is not aware of as it's not a member of the domain. Is there any way to specify a different user for the agent push? e.g. .\localadminuser and the password? Or have the agent push use the existing agent (which I assume runs under the PC's local system account) to do the install? I know there are some third party solutions to remote software installation, but we then need another product and the single-console management solution is rather broken.
In general Parallels RAS is meant for a domain environment. However, when push an agent, if the user credentials do not work, the Parallels RAS Console should be asking for a new set of credentials. (Please note that since you didn't specify which version of Parallels RAS is being used, this might be wrong). You might want to escalate this issue to Parallels support directly.
We've resolved the above and are now getting close - but the final part of the login to the PC is failing. We do have Active Directory DS, which is synced to AzureAD. The user can sign into Parallels RAS just fine using SAML, and we can see that the enrollment server side of things is working as well. When the user tries to connect to the published PC, they are also getting the login screen, but then the login (that's passed through from RAS) fails. Looking at the security event log on the PC, we are seeing an audit failure, and the username being rejected is correct - format is upn@fqdn.com, but the domain is blank. We've tried setting the domain forcibly in RAS to "AzureAD", but it's not being sent by RAS to the Azure Domain Joined PC's. If we manually RDP to the PC, it is possible to sign in as user AzureAD\upn@fqdn.com. I suspect the issue is therefore that RAS isn't using the forced-domain fields for SAML sign-ins, since RAS never gets to see the users password. I could cope if the RDP sign-in just stopped and asked for the password again (not ideal, but OK), but instead the PC just rejects the sign-in about five times and then kicks you out of the RDP session.
(I should add we resolved the agent install issue - being a non-domain joined PC the firewall was blocking the RAS agent install. That's been resolved. Additionally, the AzureAD joined PC has NLA turned off, it's not compatible with AzureAD RDP sign-ins, and we are using RAS 19.2)
