All it does is allow YOU to choose to connect to a share that you know (and set up), which happens to not ask for credentials. There is absolutely nothing to be exploited here on a private LAN. The reason they disallowed this is for business LANs where you can’t rule out a bad actor and where accountability is necessary.
Microsoft’s own help pages provide the information for how to allow it.
well, first and foremost: this is just and inconvience and neither the source of my problem, nor related to the solution. If roon decides to keep this practice of usecured shares it just means roon rocks or hardware devices need to be put to an isolated subnet within your home network.
There is a friendly red warning box that explains the risks to any installation in any scenario.
The wording is:
As a result, the recommendation is to enable guest logons only in specific situations where required. Windows disables insecure guest logons by default. We recommend that you don’t enable insecure guest logons.
No product should force you to this. If you do this to access an unsecured ROCK share, you should instantly undo it once you are done.
The important thing about security is to think it through and be precise. If you leave it enabled, the ONLY risk is if you later use it to connect to an untrusted share from the same computer. If you think you will do that, feel free to disable it again. If you have untrusted shares on your private LAN, you have bigger problems.
That is exactly my point: ROCK/Nucleus are untrusted shares on my private network.
Given that you do not want to make modifications to the configuration of the ROCK/Nucleus image yourself:
What I am asking for: Roon can fix this most easily and provide a documented/ controlled/ supported way how this should be handled by users who wish to secure their systems.
Btw, having an http only and unsecured configuration page is also no longer desirable. There should be at least an optional way to secure the sytem.
This is only a problem if you have untrusted users on your private network who will place malware on the share. Like I said, you have bigger problems in this case. Normally, a share on your own private LAN is trusted by definition.
It’s not going to cause a CVE or anything.
(By the way, even draconian Apple allows anonymous access to shares by default)
FYI, Roon OS 3.0 is currently in Early Access testing, which will fix the annoying issue of having to change the Windows configuration to allow anonymous access by requiring a username/password for the Roon OS share:
Of course, this does nothing for protection against untrusted users on your private LAN.
On a home network it is fine. If you are concerned that someone is capable of tampering or eavesdropping from within your home network, you have far more serious security issues to address.
Since Roon users include those with minimal IT skills through to IT professionals, Roon has to considert he lowest common denominator when producing a turnkey solution, i.e., Nucleus and ROCK. If a subscriber wants simplicity, this comes with compromises. If you don’t like them, the alternatives is to use Roon Server with your chosen OS, i.e., Linux, macOS, and Windows. Then, you are at liberty to add whatever security measures you feel are necessary.