1

I am setting up 2 Windows8.1 Enterprise workstations on a domain network, one is already joined to the domain, one is not yet joined (stand-alone). I need to browse the workstations' C: drive from another domain-joined workstation: \\ComputerName\ShareName

Both workstations have C:\ shared, with (local) Administrators having full control permission on the share. Both workstations are fresh install, I haven't touched filesystem permissions.

The domain joined workstation I can browse the C: drive (Windows Explorer) just as I would expect (using a Domain Admin account), but the stand-alone workstation won't let me browse it's C: drive files. When I try exploring \\StandAlone\CShare, I get prompted for credentials (as I would expect), I type in the username and password of the local administrator account, but I get the message: Network Error Windows cannot access \\StandAlone\CShare You do not have permission access \\StandAlone\CShare. Contact your network administrator to request access." (Yes, I contacted myself, and requested access, still not fixed).

I have been connecting to network shares since Win3.1 days (1993!). I even tried mapping a drive from the command line, which returns "The command completed successfully.". It lies.

I highly suspect NLA is being stupid, indeed the joined workstation has the "Domain" profile assigned to the NIC, while the stand-alone workstation has the "Public" profile assigned. (Apparently, I can no longer change the profile from Public to Private? Really?!) On the stand-alone workstation, I tried every combination possible under the "Network and Sharing Center > Change advanced sharing settings". I still get the same error.

Any suggestions?

-- EDIT ------------------------

Upon flailing for a solution, I tried adding the actual local-administrative account to the share permissions (not the disabled account "administrator", rather the administrative account created at first sign-in, and included automatically in the local "Administrators" group). Amazingly, I can now browse the files from another workstation!

That changes the question: what kind of incredibly stupid logic makes Win8.1 share permissions IGNORE members of the local Administrators group? Indeed, on the domain-joined workstation, the local Administrators group includes the member "DomainName\Domain Admins", which works correctly.

Why on a domain-joined workstation are the local group members correctly granted permission, but on the stand-alone workstation group members are ignored?

JayRO-GreyBeard
  • 17
  • 1
  • 4

3 Answers3

0

Which local admin credentials are you using? You will need to use the user account on the Domain computer, not the Standalone.

Also, did you explicitly grant it the local administrator access via the permissions setting on the share itself (not NTFS perms, the share perms)? You will need to do that too. If you still cannot access, can you post a screenshot of your shared folder's settings?

Chris Satola
  • 382
  • 2
  • 7
0

EDIT: It's worth noting that the OP pointed out that administrative shares such as C$ are disabled on standalone/workgroup machines. As such the below in italics is my original answer and my updated answer is shown in regular font.

\\StandAlone\CShare is that an actual share? I would expect you to be browsing to \\StandAlone\C$ instead and then putting in StandAlone\createdadminlevellocalaccount as the username and its password. The local administrator account on a Windows 8 workstation will be disabled, so don't try to use StandAlone\administrator as the account to access the C$ share or any other share. Instead create a local account on that standalone workstation and add it to the Administrators group on there. Then use that account's credentials to access that standalone box remotely via the C$ share (or whatever actual share you decide to setup).

UPDATE: OP, based on your own edits and trials, have you tried disabling Simple File Sharing on that workstation? http://answers.vt.edu/kb/entry/2120 and then share out a new share to make sure the appropriate groups/users are included in both the share and NTFS permissions.

TheCleaner
  • 32,627
  • 26
  • 132
  • 191
  • I tweaked the ComputerName & ShareName (for a public posting), consider the answer yes. I prefer to not connect to the administrative shares. Yes using ComputerName\AdminAcct for username. Yes using the administrative account created at first sign-in. – JayRO-GreyBeard Oct 01 '14 at 20:25
  • Just some more info, should anyone stumble on this thread: For security reasons, the built-in administrative shares (c$, admin$, etc.) have been disabled in Windows 8.1 - this has been a favorite attack target. Which is why I have disabling them since the NT4.0 days via GPO. Reference: https://support2.microsoft.com/kb/288164 (And also why I did not post the *actual* ShareName I am using in this thread). – JayRO-GreyBeard Oct 01 '14 at 21:57
  • `"For security reasons, the built-in administrative shares (c$, admin$, etc.) have been disabled in Windows 8.1"` - this is true in a workgroup environment, not so in an AD environment. So yeah, my answer wouldn't quite hold true as a standalone workstation...I wasn't thinking that part through well enough...too used to domain workstations. I'll leave this comment for you to see but then delete my answer as it isn't applicable in your case. – TheCleaner Oct 02 '14 at 14:25
  • 1
    I understand, stand-alone workstations are not typical for me also. I have discovered that the administrative shares on a Win8.1 Ent. machine are indeed created when joined to AD (I'm undecided if I should disable those via GPO for the Win8.1 boxes like I did for 2000/XP, well known attack points make me nervous). I'd recommend leaving your answer posted as our discussion in the comments to your answer may be of help to others (and hopefully someone will mark my answer as the best solution). Thanks again for your contribution!! – JayRO-GreyBeard Oct 02 '14 at 15:37
  • @JayRO-GreyBeard I've updated my answer then...hopefully it will help clarify for others. – TheCleaner Oct 02 '14 at 18:19
  • 1
    To answer the update: no, I did not fiddle with unchecking "Use Sharing Wizard". Frankly, I never use that anyway, I go straight to the "Advanced Sharing" button or faster yet, use the "NET USE" command (skip all the GUI clicks to specify caching and permissions). In hindsight, an interesting test would have been to grant share permission for the local "Users" group - since UAC seemed insistent on ingnoring the Administrators group assignment. --- Now having spent more time on this Win8.1 Ent. setup, there have been other instances where UAC has been a PITA to work-around. – JayRO-GreyBeard Oct 03 '14 at 15:56
0

This seems to be more a work-around than an answer: on a stand-alone Win8.1 Enterprise workstation, an actual user account needs to be added to the share permissions, as Win8.1 seems to ignore what members are in the local Administrators group.

Once the computer is joined to a domain, the user account can be swapped with the local Administrators group in the share permissions, and the share permissions will then work as they have for the last 21 years.

If this is some kind of "feature", I'd love to understand the reason. About 6 hours wasted on this (customer is going to be really ticked).

Props need to go to @c-satola for stating what I found by flailing about. If I can find an explanation for this "new feature" I'll post a follow-up.

--- Follow-up -----------------------------------

The actual solution seems to be: Create new DWORD value at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy, set to 1.

Credit goes to PPC at: http://community.spiceworks.com/topic/451675-windows-8-1-differences-in-accessing-default-c-share-and-other-shares

I was not able to find a reason in MSDN, other than a Windows 2003 Server reference: http://msdn.microsoft.com/en-us/library/aa826699%28v=vs.85%29.aspx If I had to guess, the problem is due to UAC NOT elevating the local administrator acount to "Administrators" when the account is being used "remotely" (as in: from a remote workstation).

JayRO-GreyBeard
  • 17
  • 1
  • 4