Is public, anonymous SMB access from Windows even possible anymore?

    • OMV 4.x
    • Is public, anonymous SMB access from Windows even possible anymore?

      Simple requirement: I'd like to be able to access a Samba share from any stock, unmodified Windows 10 machine with NO login and NO password. Years ago this was easy, but Microsoft has made it progressively harder with seemingly every update. Is this even possible these days?

      I have read dozens and dozens of forum posts (here and elsewhere) to no avail. Most are outdated because Microsoft keeps changing things.

      My sense is that this is no longer possible without making local group policy changes to the Windows box (which defeats my purpose; I want anyone with wifi access to be able to easily read (only) these files). But I've never gotten a definitive answer on whether this is the case. Does anyone know?

      If it is possible, can someone point me to a definitive, up-to-date tutorial on it?
    • ras07 wrote:

      Years ago this was easy, but Microsoft has made it progressively harder with seemingly every update
      And we all should be grateful for this since there is a million of SMB shares publicly available on the Internet without any restrictions (and I bet majority of those responsible for these boxes is not even aware): Windows cannot access OPENMEDIAVAULT
    • tkaiser wrote:

      ras07 wrote:

      Years ago this was easy, but Microsoft has made it progressively harder with seemingly every update
      And we all should be grateful for this since there is a million of SMB shares publicly available on the Internet without any restrictions
      I get the problem (really). I suppose one could quibble whether the client is really the best place to address the issue, but that's neither here nor there.

      That said, I do have a specific use case (small number of public, static files, well-protected LAN, highly transient user base, SMB1 banished from the premises) that would make this ability desirable. I'm just looking for a definitive answer on whether it's still possible.
    • ras07 wrote:

      I'm just looking for a definitive answer on whether it's still possible
      Sorry, neither know nor care. All my work is directed at the opposite direction. I personally stopped using Windows 25 years ago, had to deal with it at the job from time to time (but mostly only server stuff) and just recently got involved into Windows client issues again (and have to admit Windows 10 is much much more usable than previous versions!). Main goal is to stop unauthenticated accesses and the most funny part currently is to 'upgrade' an older 'multifunction printer' that is only capable of SMB1 without authentication via an el cheapo NanoPi NEO SBC that fakes being an USB mass storage device and then transmits scans securely via SMB3 to the server.
    • ras07 wrote:

      Simple requirement: I'd like to be able to access a Samba share from any stock, unmodified Windows 10 machine with NO login and NO password. Years ago this was easy, but Microsoft has made it progressively harder with seemingly every update. Is this even possible these days?

      First, there are two exceptions; Win10 Enterprise and Win10 Education editions. These variants are setup for Domain security, out of the box, so a policy change would be needed.
      _____________________________________

      There are two possible modes of login onto a Win10 box. The local logon with a username and password, and the Domain logon with the MS account.

      The local logon is simple (tested):
      On the OMV server end, file permissions should be set to Others, Read and set SMB to "Guests allowed". (For the sake of a bit of extra security, the SMB "Read Only" switch could be toggled on.) In such a case, any credential provided by the work station would be accepted by the server for read only access, and OMV's authentication level is sufficient for Windows 10. Access, from the users perspective, is transparent.

      The Domain login "might" need an extra step (not tested):
      **Before setting up a user in Credential Manager, I'd test access first. A CM user may not be necessary.**
      Set up a user name and password in Credential Manager. (The same username and password used to login to Win10 would make sense, but any username and password would do.)

      ras07 wrote:

      That said, I do have a specific use case (small number of public, static files, well-protected LAN, highly transient user base, SMB1 banished from the premises) that would make this ability desirable. I'm just looking for a definitive answer on whether it's still possible.
      There are many use cases similar to this. As long as you're aware of the risks, it's your call.

      The post was edited 2 times, last by crashtest: edit ().

    • So much confusion spread again...

      support.microsoft.com/en-us/help/4046019/

      Those SKU for larger organizations fortunately disabled unauthenticated accesses at the client side by a policy (to enforce security best practices in organizations).
      This is not related to joining a Domain or not (same goes for Credential Manager). So two Windows 10 SKU disallow guest logons and require an adjusted policy, the other Win10 variants still allow it and even try guest logon as fallback if the authenticated attempt failed

      Windows 'strategy' is to either try the local logon credentials for authentication or those that are stored in Credential Manager for the server in question (if available), then do a fallback to guest logon if allowed. In situations where clients and servers joined the same domain Windows will try to use Kerberos (so not sending any logon credentials at all over the wire but using Kerberos tickets) unless the logon attempt is made in a stupid way (unfortunately some older gentlemen constantly try to propagate using IP addresses instead of names and encourage sabotaging local name resolution while having no idea what a 'domain' really is).

      In OMV you simply increase Samba's Log Level and then watch what happens when a client connects, the above Microsoft KB article explains where/what to look for in Event Viewer.
    • crashtest wrote:

      The Domain login "might" need an extra step (not tested):
      **Before setting up a user in Credential Manager, I'd test access first. A CM user may not be necessary.**
      Set up a user name and password in Credential Manager. (The same username and password used to login to Win10 would make sense, but any username and password would do.)
      What an insane BS.

      1. This is not related to 'Domain' at all! If client and server joined the same Domain Kerberos should be used to avoid transmitting logon credentials at all. This requires network time synchronized and local DNS working (something you constantly try to sabotage with your 'guides')
      2. When Kerberos is not in use Windows tries to authenticate with a username and password against an SMB server. It either uses the logon credentials of the local user (say user 'user1' and password 'pwd1') or if for this server other logon credentials are needed (e.g. 'user2' and 'pwd2') they need to be stored in Credential Manager so Windows knows to authenticate with this combination instead. Therefore 'The same username and password used to login to Win10 would make sense' is utter BS
    • tkaiser wrote:

      So much confusion spread again...

      support.microsoft.com/en-us/help/4046019/
      Did you read it? That bulletin only applies Win10 Enterprise and Education editions. That's clearly stated, both in the bulletin and in the previous post. There's no confusion here. Win10 Enterprise and Education editions are fairly rare, corporations and schools only.

      I just tested the permission settings, with Win10 Pro / local logon, using a username and password unknown to the server. It worked as expected.

      You've already said, "quote";

      tkaiser wrote:

      Sorry, neither know nor care.
      _________________________________________________________________________________________

      The user knows what they want to do and apparently understands the risk. It's the users decision.
    • tkaiser wrote:

      crashtest wrote:

      The Domain login "might" need an extra step (not tested):
      **Before setting up a user in Credential Manager, I'd test access first. A CM user may not be necessary.**
      Set up a user name and password in Credential Manager. (The same username and password used to login to Win10 would make sense, but any username and password would do.)
      What an insane BS.
      The above is not even relevant because, again, I clearly stated that the login with the MS account was not tested. And while it's not technically a "Domain" login, it's domain like in that an MS account and server is involved. It's not local.

      Beyond the above, I'm not getting involved in another Windows discussion with someone who states, up front:

      tkaiser wrote:

      I personally stopped using Windows 25 years ago
      And if I was the user, I wouldn't consider anything posted by someone who blatantly states:

      tkaiser wrote:

      Sorry, neither know nor care.
      Address the user, not me. I'm done in this thread.
      _________________________________________________________________________________

      @ras07 Please accept my regrets for the behavior of the moderator. If you're interested in continuing this discussion, it can be done in a "conversation". That's available in the top menu bar of this web page.
    • crashtest wrote:

      Address the user, not me
      'The user' hopefully now knows where to look at (fallback behavior to guest logon if authenticated logon fails in 'non domain' situations. What you've written below is incorrect as almost always when you try to deal with SMB issues):

      crashtest wrote:

      In such a case, any credential provided by the work station would be accepted by the server for read only access
      Nope, first authenticated try fails and 2nd guest logon (fallback) then might succeed. It's important to understand not only the details but also the basics and I was not talking to @ras07 but to YOU since it's important for you to understand that you're not knowing what you're babbling about. Unfortunately again to no avail. This level of ignorance and arrogance is really epic.

      If you wouldn't refuse to learn it's as easy as increasing Samba's 'Log Level' on the OMV server and to look what's happening. But nope, instead of improving on your knowledge you prefer to agitate users as usual.

      The post was edited 1 time, last by tkaiser ().

    • tkaiser wrote:

      crashtest wrote:

      Address the user, not me
      'The user' hopefully knows where to look at (fallback behavior to guest logon if authenticated logon fails in 'non domain' situations.
      Here we go with another continuation of thread nonsense. Think about it - if the user knew - would they ask the question?

      tkaiser wrote:

      I was not talking to @ras07 but to YOU
      This is the basic problem. If you don't know by now, I'm not interested in your opinions on an operating system that you haven't used in 25 years. A tested solution was provided to a new forum user - after you made a caustic statement of blatant disinterest.

      Here, let's take a look at that again.

      tkaiser wrote:

      ras07 wrote:

      I'm just looking for a definitive answer on whether it's still possible
      Sorry, neither know nor care. /---/
      What I don't understand is, why post in a thread where you had no intention of answering the user's question?
      (Rhetorical question again - no need to answer. I already understand your nature.)

      This thread is now unwatched so feel free to continue with your soliloquy.
      _____________________________________________

      @ras07 Again, please accept my regrets for your thread being hijacked in this manner. You have enough to setup guest access for Win10 Pro and Home editions which will probably be the majority of your transient Win10 user base.