4

Short Version

You can't add a user named:

MicrosoftAccount\ianboyd@stackoverflow.com

because

  • it's too long (you're only allowed 20 characters)
  • MicrosoftAccount is the "domain name", not the username
  • you're not allowed to have @ in your username

Long Version

When a user creates an account on Windows 10 that is a "Microsoft Account", rather than a "Local Account", and they need to access a network share: what is their username?

I've heard tell, and seen the prompt that asks for your password that it's of the form:

  • MicrosoftAccount\name@example.com

Except on Windows a username can only be 20 characters:

enter image description here

Which means that simply cannot be correct.

For sake of simplicity, lets say i want the user to be able to access shares on a Windows Server 2008 machine.

And of course we are respecting the absolute rule of single sign-on - a user logs into Windows and that account can get them access to everything they are authorized for. (In other words, i will not be creating them another account).

And it's not their e-mail address

The user's username cannot be their e-mail address; because usernames cannot contain @:

enter image description here

Which is odd because in the Security Log on the server, it clearly is:

  • Username: mzuckerberg@facebook.com (no problem with @ sign there)
  • Domain: MicrosoftAccount

enter image description here

Bonus Reading

Ian Boyd
  • 21,642
  • 49
  • 139
  • 184
  • @John Pretend it's 2012, Windows 8 has just arrived and added Microsoft Accounts. How do i add my Microsoft Account to a Windows 7 machine so it can access their shares. – Ian Boyd Mar 09 '22 at 14:34
  • @john But his point is that there is plenty of equipment that still does things the old way and doesn't know anything about Microsoft accounts. Don't focus on that he mentions Server 2008 as an example. You have exactly the same issue if you need to connect to a Samba share on a brand new Linux machine or a NAS. – Tonny Mar 09 '22 at 15:09
  • Ian, your system needs to be domain joined for this to work per "***respecting the absolute rule of single sign-on - a user logs into Windows and that account can get them access to everything they are authorized***. Otherwise it will work like any other system when you are authenticating to something and need an explicit credential to authenticate for access to the resource. You will not get single sign-on experience without some configuration and domain joined machines that you also assign those domain credentials access to the domain SMB server ACLs, etc. – Vomit IT - Chunky Mess Style Mar 09 '22 at 15:31
  • If you want SSO experience and your Windows OS tied via implicit SSO credential to a resource that that SSO credential has access without needing an explicit credential, you will have to meet certain prerequisites and criteria, and then have correlated configuration in your environment. That's not a single simple answer. Otherwise you are free to map a drive, enter in the credential, etc. and work with it that way if the sign in credential is not tied to the SMB resource implicitly and with the SSO criteria and cofigs in place. – Vomit IT - Chunky Mess Style Mar 09 '22 at 15:34
  • @VomitIT-ChunkyMessStyle SSO works fine for me since 1994 and Windows NT 3.1 (i.e. *"local accounts"*) without a domain controller - because a domain controller isn't needed for SSO. The question is how to make Microsoft Accounts work at least as well as Local Accounts. – Ian Boyd Mar 09 '22 at 16:49
  • For the experience SSO requirement you desire where no explicit authentication is needed when signed onto a Windows user account that is not tied to some ACL associated with the SMB share or folder permissions and to seamless and transparently just give you the access, I'm not certain that is possible. If you on-prem is sync'd with Azure AD and you have a tenant and the applicable domain registered, then maybe it 'd work easily. I'll keep tabs on the post, but I have a feeling a solution that'll suffice for SSO will be complex. I like complex issues regardless though, I eat them for breakfast – Vomit IT - Chunky Mess Style Mar 09 '22 at 17:13
  • If the SMB has a way to grant access to the MS account, then it might work. If you sign onto a MS account and that credential has access to the share and associated folder, it'll be SSO. You might have to refer to the technical documentation of the SMB server solution you are working with to see if there is a recommended configuration to make that work first for a starting point. If you are on-prem AD and Azure AD sync'd with Azure AD Connect, then that might be a different story where the MS signed on account and the on-prem AD account are tied together and thus so is the account's access. – Vomit IT - Chunky Mess Style Mar 09 '22 at 17:20

0 Answers0