Windows 8.1 Administrative Shares

[TanMan]

OK. I'm stumped. Doesn't happen often, but here I am.

 

I have a bunch of computers in the house for me and the family, and I'm the administrator on most of them. I have 4 desktops that I use to share stuff for everyone to use, and no servers, so everything is Workgroup access. I have several RAID arrays hung off some of the machines to access to shared stuff. I have the same user ID and password on all the machines.

 

I just updated one of the desktops to Windows 8.1 by adding a new SSD and installing Windows 8.1 onto it. After setting the Networking and Sharing settings to allow sharing (like I did with Windows 7), I was still unable to access the administrative shares, although I can access things that I share manually.

 

I found that adding the registry QWORD LocalAccountTokenFilterPolicy under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System enabled me to see the administrative shares (the DWORD value didn't help under x64 Windows 8.1), but I was now prompted for a valid user ID and password. But since my user ID and password are the same on both machines, this should work. So something else was going on.

 

According to this:

 

https://4sysops.com/archives/access-denied-to-administrative-admin-shares-in-windows-8/

 

setting the local security poicy for "User Account Control: Run all administrators in Admin Approval Mode" to disabled should fix this. It did. But now the Windows Store won't open saying that UAC is disabled.

 

How do I reenable the administrative shares on Windows 8.1 and allow access using my common administrative user without disabling the Windows Store? Anyone have any idea?

Edited March 23, 2015 by TanMan

[Tripredacus]

But since my user ID and password are the same on both machines, this should work.

I would consider them partially the same, or fairly similar. An account is more than just what its name is. Personally, I handle workgroup sharing in one of two ways:

1. On the host, add the ComputerName\Account of the client to a User Group. That group then is what is assigned share permissions. Using a group allows you to add multiple remote accounts into it without having to revisit permissions per user.

2. On the host, create a local useraccount for a client to use to log into a share.

[TanMan]

An account is more than just what its name is.

 

I do understand that. And I understand how Windows passes authentication tokens, and how using the same user ID and password to connect to multiple workgroup computers is just a hack. But it's a hack that's worked since the LAN Manager days. I understand that Microsoft disabled administrative shares by default, but there's no reason that there should be NO WAY for me to re-enable administrative shares without side effects.

 

Re regular, non-administrative shares, as I said, I have no problems making shares and accessing them. This is how the rest of the family accesses content. But I personally use the administrative shares because (1) I don't have to create another share every time I add a disk, and (2) it's just easier because it's automatic.

 

I can't believe M$ is going to force me to install a server and a domain just in order to get administrative shares with no side effects.

Edited March 23, 2015 by TanMan

[osRe]

Microsoft's sharing implementation always sucked. I'm still waiting for a 3rd party alternative, with full integration.

Edited March 23, 2015 by shae

[NoelC]

 

How do I reenable the administrative shares on Windows 8.1 and allow access using my common administrative user without disabling the Windows Store? Anyone have any idea?

 

 

It doesn't require disabling UAC.  I think you may have done something wrong.  I have it working here, no problem.  On a VM running Win 8.1 x64 Enterprise I have enabled the LocalAccountTokenFilterPolicy as shown below, and now I can access shares on it using such names as C$...

 

 

 

-Noel

[NoelC]

You may want to disable "Homegroup" networking.

 

-Noel

[TanMan]

@NoelC, thanks for the response. Yes, I do have Homegroup disabled. And I could see the network shares after I added the LocalAccountTokenFilterPolicy key, like I've been doing since Vista. However, when I tried to connect to an administrative share, I was denied access and depending on how I connected, i was sometimes prompted for a different user ID and password, none of which worked. It only started working after I changed the UAC security policy.

 

FYI, the way I'm set up is my user is the only administrator on all the machines. Everyone else is a user. They access shares that I set up for accessing their network resources, but I use the admin shares to gain full access to all the drives when I need it.

 

On this machine I'm using Windows 8.1 Pro, and there's no server in the network, so my user is a local administrator on all the machines. It looks like perhaps you have a domain set up, and that perhaps you're using a network administrator account. Do you?

[NoelC]

No domain here, just workgroup networking.

 

Likewise, one admin user which account I use on all my systems.  Networking is as seamless as it's supposed to be.

 

I don't remember what else I might have done to achieve this.  I'll think on it.

 

-Noel

[TanMan]

@NoelC, Thanks very much for helping. Based on your assertion, I decided to turn UAC back on, just to prove you wrong. I also changed LocalAccountTokenFilterPolicy back to a DWORD, like I tried originally. But after rebooting, lo and behold, I was still able to see, and connect to, the administrative shares. So all I have in place now is the registry hack for LocalAccountTokenFilterPolicy, and it's working!

 

I have NO IDEA why it didn't work initially. As I said, I've been doing this same thing since Vista! But as it's working as it should now, I'm just chalking it up to the system admin ghosts playing with me again.

 

Again, thank you for your assistance. I wouldn't have tried this again if not for your insistence that it should work.

[NoelC]

Glad to hear you got it going.  Sometimes things take a few reboots.  But I've done what you've done when investigating things - given up a little too quickly.

 

By the way, I've noticed folks sometimes assume that on a 64 bit system registry entries need to be promoted from DWORD to QWORD.  That's virtually never the case (and I suggest you treat with great skepticism any online lore that says otherwise).

 

If you've programmed software that does registry access you know that 32 bit and 64 bit software pretty much all use the same registry keys/values.  Some are duplicated into a separate part of the registry intended to separate 32 and 64 bit executables.  But even then, if it's a DWORD for 32 bit applications, it's virtually always a DWORD for 64 bit applications.  It's notable that while pointers are 64 bit in 64 bit software, the natural size of the int is still 32 bits.

 

-Noel