Local Account vs Microsoft Account and Shares in Workgroup

[xendrome]

So just some discussion on this, and no lets not get into "HomeGroup" discussion. I want permission level controls over shares/files.

Windows 7 workstation, and Windows 7 "server" for files shares. And setup with a identical username/password on both. Browsing to the server from the workstation, no problems. You just right click the share, and map the drive since the log on credentials are the same.

Now if I install Windows 8 on the workstation, and sign in to a Microsoft Account instead of local (because I think that is required to use the store) how is that going to interact with the Windows 7 "server"?

My obvious thought is, it isn't going to authenticate and either fail with an error or ask for credentials. Obviously I can map the drive with alternate credentials. But this is kind of goofy to have to fight with something to simple.

The best solution would be to allow "local" accounts to also "link" a Microsoft Account to the local login, but I don't think that is possible.

Thoughts guys?

[BajiRav]

couldn't you set share permissions with "Everyone"?

[libertas83]

There are a couple ways that you may be able to do it. Not sure if any of this is changed or easier in Windows 8.

1.) You should be able to add a Windows Credential to your account. Search for Credential in the Control Panel. They may have revamped it a bit in Windows 8 though. If it is still there, all of your online accounts and windows accounts can be stored there.

2.) Look into Linked IDs which links an online account, like Microsoft Account, with a local account.

Windows 8 I'm sure uses that Linked IDs concept, but just takes it further to making it default and more useful. It might be better to create the local account first, then add your ID. Try it out when you get it and report back your results.

couldn't you set share permissions with "Everyone"?

He wants to control permissions at the folder/file level not give it to everyone. However, there are actually 2 sets of permissions for shares, shared permissions and NTFS permissions. Whichever has the most restrictions will be used.

NTFS permissions give you the best control over shared permissions. Usually the best way to set the access is to set share permissions to everyone and then use NTFS permissions to lock down access to the groups/users you want.

The main issue here is not how to do the permissions, but how do you link an online acount to a local account which my comments above describe.

[+BudMan MVC]

"Obviously I can map the drive with alternate credentials. But this is kind of goofy to have to fight with something to simple."

I don't really understand this statement - what do you think your fighting with?

The box doing the shares has permissions set with what it knows its local accounts. To access those you have to auth, where is the fight?

As mentioned you can use alternate creds to auth to that box to access its shares.

I am not seeing the issue?

[Unrealistic]

"Obviously I can map the drive with alternate credentials. But this is kind of goofy to have to fight with something to simple."

I don't really understand this statement - what do you think your fighting with?

The box doing the shares has permissions set with what it knows its local accounts. To access those you have to auth, where is the fight?

As mentioned you can use alternate creds to auth to that box to access its shares.

I am not seeing the issue?

The way I am understanding his question is as long as the username/password are the same on machines, you can just browse to them via \\computername. I've always used this trick myself. I think what he's asking is, by using a Microsoft Account, it is no longer going to pass those credentials, as it will now be using a Windows Live ID.

It might be possible to create a local account first with the same username/password and then convert it to a Microsoft Account later. I would have to test this first to confirm though.

Edit - I downgraded my Microsoft Account to a local account and the shares instantly worked, but when I went back to a Microsoft Account, the credentials were invalid. I attempted to restart the machine just to see and Windows did a BSOD. After it came back, the shares continued to not work. The share is actually no longer working, giving me an error that the resource can't be found. I'm sure I broke a registry entry somewhere by downgrading and re-upgrading (maybe a bug?). I'll probably have to delete this account completely and make a new one now.

If anything, you can still use a local account, but just manually login to your Windows ID for the Store, Skydrive, Messenger, etc. The only thing you won't have access to is the synced settings features.

[xendrome]

The way I am understanding his question is as long as the username/password are the same on machines, you can just browse to them via \\computername. I've always used this trick myself. I think what he's asking is, by using a Microsoft Account, it is no longer going to pass those credentials, as it will now be using a Windows Live ID.

Exactly...

I'll have to test that also, but I don't think it'll work.

[Anthonyd]

My obvious thought is, it isn't going to authenticate and either fail with an error or ask for credentials. Obviously I can map the drive with alternate credentials. But this is kind of goofy to have to fight with something to simple.

What? Everytime you access to a remote network drive, you are using the credential of that remote machine. So just enter your live account when accessing to the Windows 8 machine and it will work like a charm.

[Unrealistic]

Exactly...

I'll have to test that also, but I don't think it'll work.

It didn't. Read my edit.

[xendrome]

What? Everytime you access to a remote network drive, you are using the credential of that remote machine. So just enter your live account when accessing to the Windows 8 machine and it will work like a charm.

Server is Windows 7, it only uses local accounts... Desktop is Windows 8, logged on with a Microsoft account.. Does not compute.

Yes I know I can map the drives with other credentials, but looking to see if I am missing something built in....

It didn't. Read my edit.

Thanks for testing sorry it broke your load... do a system restore?

[Anthonyd]

Server is Windows 7, it only uses local accounts... Desktop is Windows 8, logged on with a Microsoft account.. Does not compute.

Yes I know I can map the drives with other credentials, but looking to see if I am missing something built in....

Then log in with your Windows 7 account when accessing to the shared drive.

The built in feature is homegroup that you don't want to use for some random reasons.

/thread.

[Unrealistic]

Thanks for testing sorry it broke your load... do a system restore?

I'm still testing in VMware so no biggie. I created a Snapshot before I did it anyway, so I just reverted to that.

Then log in with your Windows 7 account when accessing to the shared drive.

The built in feature is homegroup that you don't want to use for some random reasons.

/thread.

You certainly like to reply a lot even when you don't understand the issue. I create SMB shares on my Apple servers and I also have an Active Directory with shares as well. I just found out that all of those shares don't automatically login either (which is expected since the credentials aren't the same). Yes, you can manually mount them, but that is far from ideal. Homegroup is exactly what it is, a home feature. Now what?

[Anthonyd]

You certainly like to reply a lot even when you don't understand the issue. I create SMB shares on my Apple servers and I also have an Active Directory with shares as well. I just found out that all of those shares don't automatically login either (which is expected since the credentials aren't the same). Yes, you can manually mount them, but that is far from ideal. Homegroup is exactly what it is, a home feature. Now what?

He isn't using SMB. You can't compare.

[trek]

If you have AD, just join the win8 client to the domain and use domain creds? (I really don't like the implementation of the Live ID for local login either...)

[Unrealistic]

He isn't using SMB. You can't compare.

SMB is the backbone of Windows sharing......

If you have AD, just join the win8 client to the domain and use domain creds? (I really don't like the implementation of the Live ID for local login either...)

Well right, but then you can't use the live services sync. I know I'm talking about a different thing, but it's still an issue.

[Anthonyd]

SMB is the backbone of Windows sharing......

My bad, I read "samba" :/ But still, he isn't using AD/Apple shares/domain accounts, don't compare.

[Unrealistic]

Alright, so while I don't like the solution for my personal issue, I think this should solve your issues.

It's very simple and I overlooked it on the first try. Create a Microsoft Account on Win8 and browse to the machine you want to access via \\computername.

Authenticate and check the remember password option. You should be set from then on out.

[jakem1]

Well right, but then you can't use the live services sync. I know I'm talking about a different thing, but it's still an issue.

I agree. It's a small issue but it's still an issue and it would have been nice if MS had given us the option to create local/AD accounts and link them to an MS account for syncing.

[xendrome]

Yeah that was my work around also, and to the other poster HomeGroup isn't good for permissions at a user level.

I wonder if when you join the system to a domain, does it remove the ability to convert to a "Microsoft Account"

[Anthonyd]

I agree. It's a small issue but it's still an issue and it would have been nice if MS had given us the option to create local/AD accounts and link them to an MS account for syncing.

You can link your domain account (AD) with an MS account, and you can also block that with a GPO.

[+BudMan MVC]

I still don't see what the issue is here?

There is not much difference between you logging in locally with billy and Password1 so it matches up with remote machine billy Password1 and accessing the share, via saving credentials to send billy Password1 when your logged in with [email protected]

Its not like your local account was sync'd in any way to the remote machines shares\account - if you changed the password on your machines local billy account, you would of failed to auth. So either you would have to had changed the account info on the remote machine or saved credentials.

It's not some other account logged into you local machine would have access to shares that billy does.

I don't see anything really different here other than saving credentials once vs them being what you logged in with. The method of access is still the same to the remote share - your authing with billy Password1. Be it thats what you logged in with, or what you saved as auth for that remote machine.

[jakem1]

You can link your domain account (AD) with an MS account, and you can also block that with a GPO.

Ah, I didn't know that. Thanks.

So if you can do this to an AD account why can't you do it with a local account?

[Anthonyd]

Ah, I didn't know that. Thanks.

So if you can do this to an AD account why can't you do it with a local account?

What would be the benefits from doing that with a normal local account?

[jakem1]

What would be the benefits from doing that with a normal local account?

Compatibility with Windows Home Server.

[Anthonyd]

Compatibility with Windows Home Server.

Care to detail it?

Because WHS is a dead product and I don't see how it's related to the discussion :p

[xendrome]

Care to detail it?

Because WHS is a dead product and I don't see how it's related to the discussion :p

WHS 2011 is end of life in 2016, and is still being sold on systems today. So just because MS isn't making a successor to it, doesn't instantly mean it is dead.