Rdp ошибка 2825

I have the same NLA Error 2825.
It’s a clean install so don’t know if this scenario worked previous to the update.

mRemoteNG v1.75.7012.16814
Windows 10 1709 OS Build 16299.248

Happy to test an update/fix.
Thanks.

Do you have Use CredSSP enabled for that connection (Protocol section in the config window)?

Hi David

No, CredSSP is off.

CredSSP is enabled on the computers on the domain of today’s client, and I think on the others I manage. (And has been for a long time, predating this problem.) But it’s not enabled in mRemoteNG.

My computer is not a domain member, so CredSSP won’t work even if enabled…but should not cause a problem. It doesn’t bother MSTSC.

Thanks!

…

I would recommend attempting a connection from mRemoteNG with CredSSP turned on. According to the CredSSP protocol specification, the client and sever do not need to be on the same domain for the protocol to work. All it does is provide a TLS connection during authentication and help with selecting an authentication protocol that both hosts support.

I admit it seems odd that this issue cropped up after updating mremoteng though.

Wow, David, you’re absolutely right. It worked.

From an admin’s perspective, CredSSP’s purpose in life is Single Sign-On, so the user doesn’t have to log on to the RD session. For that to work, the RDSH and the client have to be members of the same domain, because the client passes the user’s logon credentials to the RDSH, which then has to have its DC authenticate them. So I would not have thought it needed to be turned on.

In fact, by default, CredSSP is DISABLED on RDSH’s. It requires a registry edit or GPO to enable. That makes it even more surprising that this would make any difference. But maybe what’s disabled on the server is the auth piece and not the protocol piece.

So, problem solved, and I learned something.

Maybe I disabled CredSSP at the same time as I did the upgrade. And then when I did the clean install, it was either off by default or I turned it off. Too many weeks have gone by to know, now.

Thanks!

…

Hi David, I concur this works. I had tried with CredSSP in both states but this was combined with bad credentials so confused the result.

Thanks for your prompt suggestion.
Simon.

Glad to hear that worked for both of you. I learned something as well — had to do a bit of digging to figure out what credssp was really doing for us.

I’ve created issue #885 to look into improving the error message for rdp error 2825.

David, it’s more than an error message problem. NLA and CredSSP are two different things.

I’m a little rusty now, but RDS was my life a few years ago, and I still support a small RDS infrastructure for one of my clients.

NLA is the feature that prompts for credentials on the client instead of using the GINA on the server. It functions whether you’re passing creds from Windows (CredSSP), using stored creds from mRemoteNG, or typing them. MSTSC requests NLA unless otherwise set in a custom RDP file, and if the RDSH accepts (or requires) NLA, is capable of using it. If the RDSH doesn’t accept NLA, MSTSC falls back to using the RDSH’s GINA for authentication.

CredSSP uses NLA to pass credentials from Windows and won’t function without NLA. CredSSP is disabled by default in MSTSC, and if you want to use it, it must be enabled through a custom RDP file. It’s most often used for RemoteApps in order to provide a UX similar to running a program locally. CredSSP falls back to prompting for credentials if Windows credentials don’t work.

I don’t have visibility into what’s happening under the hood. But empirically, it looks like “Use CredSSP” in mRemoteNG is enabling/disabling client-side NLA AND client-side CredSSP. It should only be enabling/disabling CredSSP. To duplicate functionality of MSTSC v6+, there should NEVER be a time when mRemoteNG, can’t authenticate by NLA if the RDSH supports it, regardless of the “Use CredSSP” setting. With “Use CredSSP” turned on, Windows is ALSO trying to log on with local creds, but that’s harmless. If Windows creds fail, NLA will fall back to mRemoteNG creds, and finally, the credential prompt. We shouldn’t HAVE to enable it to use mRemoteNG, but it won’t hurt anything if we do.

HTH

…

The only AxMstsc property we set based on the Use CredSsp value is _rdpClient.AdvancedSettings7.EnableCredSspSupport (RdpProtocol.cs:151). Related documentation page here: https://msdn.microsoft.com/en-us/library/gg130858(v=vs.85).aspx

The only somewhat related value seems to be _rdpClient.AdvancedSettings5.AuthenticationLevel (RdpProtocol.cs:143) which we currently hardcode to 0. Related documentation here: https://msdn.microsoft.com/en-us/library/aa380846(v=vs.85).aspx. Though this seems to be more about authenticating that the server is valid via certs than requesting creds from a client.

I cant find any property that specifically references NLA.

It may be that the AxMstsc library lacks the distinction between CredSSP and NLA.

OK, thanks for the followup, David. That’s interesting. Yes the authentication level does sound like the MSTSC feature where it pops up a security warning if it doesn’t trust the RDSH.

Then, I guess all you can do is change the help text. It does mean that mRemoteNG won’t ever behave like MSTSC does, but that’s on MS.

Thanks!

…

Np @JRVcr, there may be work-arounds for it or something I’m still missing, so I’ll keep this open for a bit. I am doing a bit of work on our RDP components next release so I may take a look at this again

Cool, thanks, David.

I need to also mention that I’m really glad I found mRemoteNG. It provides the functionality of the commercial RD manager I used years ago, can’t recall the name of it any more. Especially the External Tools feature I use almost as much as RDS. But mRemoteNG is available at my favorite price!

I love that it scales the Remote Desktop for my Surface Pro hi-res display automatically. That’s what initially drew me to it. When I got my Surface Pro, I couldn’t see the servers I was working on any more with MSTSC without manually scaling, or RDCMAN which has no scaling at all.

Speaking of scaling…any thought of creating a RemoteApp client instead of using MSTSC.EXE? RemoteApps on hi-res displays have no scaling provisions at all, even manually, and are pretty much unusable. At least against WS2012 RDSH’s. I think I read MS has done better with scaling on WS2016 but don’t have experience with it. (That would also put the CredSSP feature to good use!<g>)

…

@sparerd The afore mentioned Authentication Level property https://msdn.microsoft.com/en-us/library/aa380846(v=vs.85).aspx should in fact be the reference to NLA you are looking for. The equivalent is «authentication level:i:n» for .RDP files (as referenced to here), where «n» can be any of the levels described in https://msdn.microsoft.com/en-us/library/aa380846(v=vs.85).aspx

If you’re hard-coding the value to 0, end-users will not be able to connect to systems set with the «Allow connections only from computers running Remote Desktop with Network Level Authentication» option enabled on the remote system. Unless something changed though, requiring NLA should be off by default in Windows (so it’s not a common need), but it can be enabled locally and/or via GPO.

Thus, _rdpClient.AdvancedSettings5.AuthenticationLevel should be made into a configurable flag with a default of 0 to keep current functionality while allowing end-users to alter the setting when needed.

Thanks for clarifying @guidez. We can get this added as a configurable option with a default of ‘0’ as you’ve suggested. I’ll tentatively add this to the v1.77 release. That release is getting a bit full, but this change is fairly straight forward.

NLA is on by default in WS2012 and later. It is, in fact, a near-universal need for system administrators in my experience.

The MSTSC client GUI doesn’t offer a setting for NLA. It used it if the server requests it and falls back to the servers GINA if it does not. That is how mRemoteNG should work, in my opinion.

Having a flag for this could be a moderately useful diagnostic tool, but something that most users will not want to have to fuss with, any more than they do with MSTSC.

…

@JRVcr Wouldn’t go so far as to say it’s a «near-universal need»: Search for «windows 2012 nla«, and you’ll find most of the links are for requests to turn NLA off on remote end-points.

You are correct though, MSTSC does not provide an option to alter the AuthenticationLevel setting from the GUI itself, but it is a simple tweak in a saved RDP file to alter the setting.

Having a flag for this could be a moderately useful diagnostic tool, but something that most users will not want to have to fuss with, any more than they do with MSTSC.

The point of the flag is to just move away from the currently hardcoded variant and give end-users the option to alter it when needed. If we’re just talking about truly imitating native MSTSC/.RDP file functionality, I’d concur that the default value for _rdpClient.AdvancedSettings5.AuthenticationLevel should be 2, but perhaps on a later release?

The hardcoded variant has been 0 for who knows how long, and introducing it as both a configurable option and altering the current hardcoded/default value in one go might make some heads spin.

edit

To clarify, changing the value from 0 to 2 will potentially cause an additional prompt on the end-users side of things, so while it’s the «native» MSTSC experience, it’s not native to the mRemoteNG experience.

0: No authentication of the server.
2: Attempt authentication of the server. If authentication fails, the user will be prompted with the option to cancel the connection or to proceed without server authentication.

Really Microsoft should have added a fourth option… «3»: Attempt auth, if auth fails, continue automatically. But Microsoft did… well it did what Microsoft does.

@guidez You make a good point about the default value. Retaining the ‘0’ default value provides an easy transition for users who are not affected by this issue. We don’t want to ‘break’ existing functionality unless we have a good reason.

For users who will always want NLA, they can set the default connection info property to ‘2’. Newly created connections will have NLA turned on.

The largest issue will come for users who need NLA turned on for many connections. Because we do not yet support mass editing of connections, users will have to do a find & replace of the XML file or edit each individual connection in the app. Though this would be an issue with whichever default value we chose.

Another downside is that users who do still need NLA will receive that somewhat unhelpful error message. We can mitigate this drawback by improving the error message. Best practice is to (1) inform the user what went wrong and (2) include several suggestions for how to fix it or how to troubleshoot further. Currently this error message (and most of our error messages actually..) lacks that 2nd part.

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

Assignees

Labels

I have the same NLA Error 2825.
It’s a clean install so don’t know if this scenario worked previous to the update.

mRemoteNG v1.75.7012.16814
Windows 10 1709 OS Build 16299.248

Happy to test an update/fix.
Thanks.

Do you have Use CredSSP enabled for that connection (Protocol section in the config window)?

Hi David

No, CredSSP is off.

CredSSP is enabled on the computers on the domain of today’s client, and I think on the others I manage. (And has been for a long time, predating this problem.) But it’s not enabled in mRemoteNG.

My computer is not a domain member, so CredSSP won’t work even if enabled…but should not cause a problem. It doesn’t bother MSTSC.

Thanks!

…

I would recommend attempting a connection from mRemoteNG with CredSSP turned on. According to the CredSSP protocol specification, the client and sever do not need to be on the same domain for the protocol to work. All it does is provide a TLS connection during authentication and help with selecting an authentication protocol that both hosts support.

I admit it seems odd that this issue cropped up after updating mremoteng though.

Wow, David, you’re absolutely right. It worked.

From an admin’s perspective, CredSSP’s purpose in life is Single Sign-On, so the user doesn’t have to log on to the RD session. For that to work, the RDSH and the client have to be members of the same domain, because the client passes the user’s logon credentials to the RDSH, which then has to have its DC authenticate them. So I would not have thought it needed to be turned on.

In fact, by default, CredSSP is DISABLED on RDSH’s. It requires a registry edit or GPO to enable. That makes it even more surprising that this would make any difference. But maybe what’s disabled on the server is the auth piece and not the protocol piece.

So, problem solved, and I learned something.

Maybe I disabled CredSSP at the same time as I did the upgrade. And then when I did the clean install, it was either off by default or I turned it off. Too many weeks have gone by to know, now.

Thanks!

…

Hi David, I concur this works. I had tried with CredSSP in both states but this was combined with bad credentials so confused the result.

Thanks for your prompt suggestion.
Simon.

Glad to hear that worked for both of you. I learned something as well — had to do a bit of digging to figure out what credssp was really doing for us.

I’ve created issue #885 to look into improving the error message for rdp error 2825.

David, it’s more than an error message problem. NLA and CredSSP are two different things.

I’m a little rusty now, but RDS was my life a few years ago, and I still support a small RDS infrastructure for one of my clients.

NLA is the feature that prompts for credentials on the client instead of using the GINA on the server. It functions whether you’re passing creds from Windows (CredSSP), using stored creds from mRemoteNG, or typing them. MSTSC requests NLA unless otherwise set in a custom RDP file, and if the RDSH accepts (or requires) NLA, is capable of using it. If the RDSH doesn’t accept NLA, MSTSC falls back to using the RDSH’s GINA for authentication.

CredSSP uses NLA to pass credentials from Windows and won’t function without NLA. CredSSP is disabled by default in MSTSC, and if you want to use it, it must be enabled through a custom RDP file. It’s most often used for RemoteApps in order to provide a UX similar to running a program locally. CredSSP falls back to prompting for credentials if Windows credentials don’t work.

I don’t have visibility into what’s happening under the hood. But empirically, it looks like “Use CredSSP” in mRemoteNG is enabling/disabling client-side NLA AND client-side CredSSP. It should only be enabling/disabling CredSSP. To duplicate functionality of MSTSC v6+, there should NEVER be a time when mRemoteNG, can’t authenticate by NLA if the RDSH supports it, regardless of the “Use CredSSP” setting. With “Use CredSSP” turned on, Windows is ALSO trying to log on with local creds, but that’s harmless. If Windows creds fail, NLA will fall back to mRemoteNG creds, and finally, the credential prompt. We shouldn’t HAVE to enable it to use mRemoteNG, but it won’t hurt anything if we do.

HTH

…

The only AxMstsc property we set based on the Use CredSsp value is _rdpClient.AdvancedSettings7.EnableCredSspSupport (RdpProtocol.cs:151). Related documentation page here: https://msdn.microsoft.com/en-us/library/gg130858(v=vs.85).aspx

The only somewhat related value seems to be _rdpClient.AdvancedSettings5.AuthenticationLevel (RdpProtocol.cs:143) which we currently hardcode to 0. Related documentation here: https://msdn.microsoft.com/en-us/library/aa380846(v=vs.85).aspx. Though this seems to be more about authenticating that the server is valid via certs than requesting creds from a client.

I cant find any property that specifically references NLA.

It may be that the AxMstsc library lacks the distinction between CredSSP and NLA.

OK, thanks for the followup, David. That’s interesting. Yes the authentication level does sound like the MSTSC feature where it pops up a security warning if it doesn’t trust the RDSH.

Then, I guess all you can do is change the help text. It does mean that mRemoteNG won’t ever behave like MSTSC does, but that’s on MS.

Thanks!

…

Np @JRVcr, there may be work-arounds for it or something I’m still missing, so I’ll keep this open for a bit. I am doing a bit of work on our RDP components next release so I may take a look at this again

Cool, thanks, David.

I need to also mention that I’m really glad I found mRemoteNG. It provides the functionality of the commercial RD manager I used years ago, can’t recall the name of it any more. Especially the External Tools feature I use almost as much as RDS. But mRemoteNG is available at my favorite price!

I love that it scales the Remote Desktop for my Surface Pro hi-res display automatically. That’s what initially drew me to it. When I got my Surface Pro, I couldn’t see the servers I was working on any more with MSTSC without manually scaling, or RDCMAN which has no scaling at all.

Speaking of scaling…any thought of creating a RemoteApp client instead of using MSTSC.EXE? RemoteApps on hi-res displays have no scaling provisions at all, even manually, and are pretty much unusable. At least against WS2012 RDSH’s. I think I read MS has done better with scaling on WS2016 but don’t have experience with it. (That would also put the CredSSP feature to good use!<g>)

…

@sparerd The afore mentioned Authentication Level property https://msdn.microsoft.com/en-us/library/aa380846(v=vs.85).aspx should in fact be the reference to NLA you are looking for. The equivalent is «authentication level:i:n» for .RDP files (as referenced to here), where «n» can be any of the levels described in https://msdn.microsoft.com/en-us/library/aa380846(v=vs.85).aspx

If you’re hard-coding the value to 0, end-users will not be able to connect to systems set with the «Allow connections only from computers running Remote Desktop with Network Level Authentication» option enabled on the remote system. Unless something changed though, requiring NLA should be off by default in Windows (so it’s not a common need), but it can be enabled locally and/or via GPO.

Thus, _rdpClient.AdvancedSettings5.AuthenticationLevel should be made into a configurable flag with a default of 0 to keep current functionality while allowing end-users to alter the setting when needed.

Thanks for clarifying @guidez. We can get this added as a configurable option with a default of ‘0’ as you’ve suggested. I’ll tentatively add this to the v1.77 release. That release is getting a bit full, but this change is fairly straight forward.

NLA is on by default in WS2012 and later. It is, in fact, a near-universal need for system administrators in my experience.

The MSTSC client GUI doesn’t offer a setting for NLA. It used it if the server requests it and falls back to the servers GINA if it does not. That is how mRemoteNG should work, in my opinion.

Having a flag for this could be a moderately useful diagnostic tool, but something that most users will not want to have to fuss with, any more than they do with MSTSC.

…

@JRVcr Wouldn’t go so far as to say it’s a «near-universal need»: Search for «windows 2012 nla«, and you’ll find most of the links are for requests to turn NLA off on remote end-points.

You are correct though, MSTSC does not provide an option to alter the AuthenticationLevel setting from the GUI itself, but it is a simple tweak in a saved RDP file to alter the setting.

Having a flag for this could be a moderately useful diagnostic tool, but something that most users will not want to have to fuss with, any more than they do with MSTSC.

The point of the flag is to just move away from the currently hardcoded variant and give end-users the option to alter it when needed. If we’re just talking about truly imitating native MSTSC/.RDP file functionality, I’d concur that the default value for _rdpClient.AdvancedSettings5.AuthenticationLevel should be 2, but perhaps on a later release?

The hardcoded variant has been 0 for who knows how long, and introducing it as both a configurable option and altering the current hardcoded/default value in one go might make some heads spin.

edit

To clarify, changing the value from 0 to 2 will potentially cause an additional prompt on the end-users side of things, so while it’s the «native» MSTSC experience, it’s not native to the mRemoteNG experience.

0: No authentication of the server.
2: Attempt authentication of the server. If authentication fails, the user will be prompted with the option to cancel the connection or to proceed without server authentication.

Really Microsoft should have added a fourth option… «3»: Attempt auth, if auth fails, continue automatically. But Microsoft did… well it did what Microsoft does.

@guidez You make a good point about the default value. Retaining the ‘0’ default value provides an easy transition for users who are not affected by this issue. We don’t want to ‘break’ existing functionality unless we have a good reason.

For users who will always want NLA, they can set the default connection info property to ‘2’. Newly created connections will have NLA turned on.

The largest issue will come for users who need NLA turned on for many connections. Because we do not yet support mass editing of connections, users will have to do a find & replace of the XML file or edit each individual connection in the app. Though this would be an issue with whichever default value we chose.

Another downside is that users who do still need NLA will receive that somewhat unhelpful error message. We can mitigate this drawback by improving the error message. Best practice is to (1) inform the user what went wrong and (2) include several suggestions for how to fix it or how to troubleshoot further. Currently this error message (and most of our error messages actually..) lacks that 2nd part.

Recently Changed Pages:

View All Pages

View All Tags

LinkedIn

WIKI Disclaimer:
As with most other things on the Internet, the content on this wiki is not supported. It was contributed by me and is published “as is”. It has worked for me, and might work for you.

Also note that any view or statement expressed anywhere on this site are strictly mine and not the opinions or views of my employer.

Pages with comments

View All Comments

Fix: Error 2825 when using mRemote RDP sessions

You could leave a comment if you were logged in.

fixmremote2825.txt

· Last modified: 2021/09/24 00:24 (external edit)