Skip to main content
  • EN

For well know reasons myself and many here recommend to - if possible - deploy VBR and especially it’s repos outside of the Windows domain.

Certain issues come as a downside with doing that:

Maintaining multiple local admin logins, remote-UAC (LocalAccountTokenFilterPolicy), firewall behavior outside of domain networks etc. being some of those.

Recently I stumbled upon a situation were we could not establish a connection from a non-domain-joined VBR server to a newly deployed non-domain-joined Windows 2019 repo server. Other older proxies/repos to the same VBR were available and functioning.

From the VBR server the admin$ share of the to-be-connected new repo was not accessible (“invalid login”).

VBR also stated “invalid login” during Windows server onboarding. But from another (domain joined) Windows system in the same (direct, non-routed) network, the repo’s admin$ share was well available with the same user/pw.

Of course no Windows firewall whatsoever was active.

Very strange.

Has anyone seen something alike already? I would welcome more ideas to troubleshoot. Case is open, but I assume it’s basically a Windows issue as the admin$ share is already not accessible.

Thanks,

Michael

Have not seen this one before as we tend to domain join our Veeam servers due to administrative management (this will change with v12).  Best of luck finding a solution.

I hope it wasn’t something simple like Windows Firewall?  That gets me when I do non-domain memberships. So much so that I committed to memory turning it off (netsh advfirewall set allprofiles state off).

Is it in a hardened environment? And what does the security eventlog of the target server say during the failed logins?

Great post @Michael Melter. I also implement always VBR in a workgroup, also in a separate VLAN segmentation. I also need to implement the setting for LocalAccountTokenFilterPolicy. Do not forget to reboot the server afterwards. As @Rick Vanover already mentioned, mostly something to do with the Windows Firewall.

Another thing that could be the cause is the notation of the local account. Normally use only the name of the account (without .\). Did you try the built-in local administrator account already?

As expected and always welcome, we found the reason. 😎

LAN managers auth level was restricted due to some hardening applied to Windows. Not clear right now, if via Windows update or actively by the customers policies.

HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel on VBR was set to 1.

→ Network security LAN Manager authentication level (Windows 10) | Microsoft Learn

Once set back to 5, it works as expected. Repos also had 5 (which is default for non-domain-joined systems).

Thanks all for contributing.

 

You’re a hero @Michael Melter !

Just the same day I was analyzing a problem, where the Veeam service user got locked when a accessing it’s proxy. It was rather weired and everything else looked ok. Then I remembered you’re post, checked the registry and bingo; LmCompatibilityLevel was set to “0”. 🤓

I’m also not sure why this would be set to 0 while everything else was at 5. Is this just a coincidence?

Comment


Terms & Conditions