Windows: "Tailscale backend error: failed to look up user from userid: lookupUserPrimaryGroup: should be domain account type, not 5"

[oselz]

Report from a user on windows trying 1.14.3 but getting this error message:

There is no option to log in, the error is raised immediately upon executing the Tailscale client. Uninstall/reinstall/restart do not fix it.

A forum report from 2018 shows the same issue: https://forum.tailscale.com/t/backend-error-failed-to-look-up-user-from-userid/474

I have checked the domain account of the affected user, and a Primary Group is set correctly for the user at the domain level, but I cannot confirm what it looks like on the actual device.

The actual error message is generated here: https://github.com/golang/go/blob/30faf968b1f348e944db3bde24c13462125007b1/src/os/user/lookup_windows.go#L238

There was a similar bug in #869, with a workaround applied in #871 but as the exact error is different the workaround is not being applied in this case. If the domain information is not important perhaps the workaround could be extended to cover this case as well?

[DentonGentry]

From https://golang.org/src/syscall/security_windows.go, type 5 appears to be SidTypeWellKnownGroup

https://docs.microsoft.com/en-us/windows/win32/api/winnt/ne-winnt-sid_name_use says that SidTypeWellKnownGroup means, "A SID for a well-known group."
Thanks, Microsoft.

Other searches imply that SidTypeWellKnownGroup is used for groups like "Everyone"

[oselz]

The Primary Group in this case is 'Domain Users' (the default).

[DentonGentry]

https://github.com/golang/go/blob/30faf968b1f348e944db3bde24c13462125007b1/src/os/user/lookup_windows.go#L238 is just returning a fmt.Errorf() string, not something we can check with Is().

I think it would be fine to handle this as another ("unknown-user-" + uid) workaround, but I think we'd have to look at the text of the error message to trigger that workaround.

[oselz]

Reading the comment in the go source immediately below the error message point indicates this is possibly an upstream bug?

There is code to cover this exact case, but I'm unsure how it can actually be reached as the comparison to SidTypeDomain will always fail. It should probably be t != syscall.SidTypeDomain || t!= syscall.SidTypeWellKnownGroup instead.

[oselz]

If anyone else is having this issue - the user informed me they found a temporary workaround assuming you have local pc administrator access:

• create a new local user account on the computer
• set up Tailscale from that new account
• return to the domain account and Tailscale will now start (despite the error).

Note I have not confirmed whether this works as described.

[dblohm7]

Filed upstream: golang/go#49509

[bradfitz]

@dblohm7, we can also send a fix to upstream and then cherry-pick it into our Go tree. (No need to be bound by the Go release cycle)

[freezscholte]

Also having the same bug here only the difference is domain user type 1 and not 5. It worked perfectly fine until this morning

[freezscholte]

Oke created the local admin account and started tailscale.exe with runas as the new local admin then it works in the AzureAD profile

[freezscholte]

Also when using the tailscale ping command I get the same error

[freezscholte]

Update: I looked back when it broke and this was when I added another local admin for some testing purpose. When I removed this local admin completely and rebooted the laptop my Tailscale started working again in my normal AzureAD profile. Also one detail if you look at the output of "whoami" it says "Contoso\user" and the new local admin name was just "contoso". Maybe when looking up the SID/Account name something in the Go code gets fuzzy and then gives an error since there is a correlation in the names.

[DentonGentry]

https://github.com/MicrosoftDocs/azure-docs/issues/38048 mentions this issue in Tailscale, and says:
"This a known gap, that we're reviewing. Even though you have migrated the user from AD to Azure AD, the onprem SamAccountName is still intact on the user object, among other on-prem AD attributes. As a result, Azure AD picks those details and shows domain/user instead of AzureAD/user. This attribute cannot be modified or cleared through Graph APIs at this point, so there's no way to change the behavior"

[DentonGentry]

Internal discussion: "I have a PR against the standard library for #2894"

I don't immediately have a link to that PR but will edit this comment later if I find it.

[oselz]

Can confirm that as of the newly released Windows client version 1.34.0 the original error no longer occurs.

Thank you.