Non-localized User and Group Names

[FLeven]

It should be mentioned to use an English based 'OsLanguage' OS, because the security groups are not localized in the install script.

For PowerShell Cmdlets the groups can be translated and icacls.exe can work with SID's directly.

Will I run into more problems when continuing with a non English OS, after fixing the group names ?

[GeoSimos]

This is a very interesting observation, will discuss it with the team as it is a valid scenario, however, for the time being we support only English based WIM files.

[FLeven]

I made two changes to the code, in one place you can use a SID instead of the name, in another place this was not possible and I had to replace a name with language "dependent" variable. I will test this soon with the new version. To get started, a comment would be enough to point users to the line were they will have to do changes. This would save some time and frustration.

[DeploymentBunny]

I made two changes to the code, in one place you can use a SID instead of the name, in another place this was not possible and I had to replace a name with language "dependent" variable. I will test this soon with the new version. To get started, a comment would be enough to point users to the line were they will have to do changes. This would save some time and frustration.

Hi, can you tell us in what script the issue is, not sure if we are talking about the installer or in some other script?

[FLeven]

455-461 install-psd.ps1 for example.

[DeploymentBunny]

Thank you! /m

From: Felix Leven @.> Sent: Sunday, 13 November 2022 09:30 To: FriendsOfMDT/PSD @.> Cc: Mikael Nystrom @.>; Assign @.> Subject: Re: [FriendsOfMDT/PSD] Non-localized User and Group Names (#50)

455-461 install-psd.ps1 for example.

— Reply to this email directly, view it on GitHubhttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFriendsOfMDT%2FPSD%2Fissues%2F50%23issuecomment-1312670521&data=05%7C01%7C%7C84fbebdd2dda416fdc3a08dac5514e56%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638039250249435674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=N1eRuzUG7QXOlr0oxuyQUdwf3EICPXfsNg3Kr0BBjt8%3D&reserved=0, or unsubscribehttps://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADZWWO2KIDOZTRXCYOTC2VTWICRJ5ANCNFSM445XW4XA&data=05%7C01%7C%7C84fbebdd2dda416fdc3a08dac5514e56%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638039250249435674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=KJ%2FQTAKvMQY468SteNhKRMYGkiWJKiHflOKBgefaNIA%3D&reserved=0. You are receiving this because you were assigned.Message ID: @.**@.>>

[GeoSimos]

Very nice, the code will be modified to use SIDs instead of their friendly names for the icacls part, however for the Grant-SMBShare it is not possible to use SIDs. I will do the changes and test, and will try to find a way around for the powershell cmdlets. Do the Grant-SMBShare and New-SMBShare create a problem also in non English-US setups?

[FLeven]

Sure, they do, the account name does not exist on the OS.

[FLeven]

You could get the localized account name of everyone by running:

get-acl C:\Users\ | select AccessToString

and

get-acl 'C:\Program Files\' | select AccessToString

for the creator owner ....

[GeoSimos]

Hi FLeven, The get-acl cmdlet returns the access control entries (ACE) in the ACL, it is practical for other actions, however, to have a true multilanguage solution we have to achieve this without over-coding in the solution. So, after researching a bit the solution would be:

1. Have a list of the well-known SIDs used in Windows and in the solution, we don't need every each one of them.
2. Select a number of languages used and have a mapping between the well-known SIDs and their names or derive the localized name by using the SID only.
3. Use the SID where possible instead of the Username string.

Unfortunately, Grant-SMBShare doesn't support SIDs for the ACEs but expects String names, the same applies to New-SMBShare too.

Please bear with us as we're progressing on this matter, it is a good thing to cover that because we are working on the new installer solution, and it will be good to have this functionality also.

[baardhermansen]

You could get the localized account name of everyone by running:

get-acl C:\Users\ | select AccessToString

and

get-acl 'C:\Program Files\' | select AccessToString

for the creator owner ....

Surely it must be better to use Get-LocalUser | Select-Object -ExpandProperty Name to get the localized names, no?

Picture showing a test i did on a Spanish base version of Windows 10.

[GeoSimos]

You could get the localized account name of everyone by running: get-acl C:\Users\ | select AccessToString and get-acl 'C:\Program Files\' | select AccessToString for the creator owner ....

Surely it must be better to use Get-LocalUser | Select-Object -ExpandProperty Name to get the localized names, no?

Picture showing a test i did on a Spanish base version of Windows 10.

Yes! The Get-LocalUser worked fine for the scenario and is the best candidate to create a dynamic solution, this is what I was checking a couple of days ago. Thank you @baardhermansen!

[baardhermansen]

Regarding localization of line 460 of Install-PSD.ps1, you could get the localized access name of the SMB share by running (Get-SmbShareAccess -Name $psDeploymentShare).AccountName

I don't have a server to test on for the moment, so i don't see the CREATOR OWNER on the folder rights. I wonder if that right shows up in the above command? If so, then it should be treated as an array. Just a thought.

[GeoSimos]

There are also techniques to derive the localized account name by using .Net methods in PowerShell, this is an example https://shellgeek.com/convert-sid-to-username-in-powershell-and-cmd/.

[baardhermansen]

There are also techniques to derive the localized account name by using .Net methods in PowerShell, this is an example https://shellgeek.com/convert-sid-to-username-in-powershell-and-cmd/.

Yeah, just that in your example one have to know the SID beforehand. Not an issue if you do as you mentioned earlier, keep a list of well-known SIDs.

[GeoSimos]

For special accounts and groups, you can't use the Get-LocalUser cmdlet, thus you need to find another way to retrieve their details. The list of well-known SIDs exists -and gets updated- since the beginning of Windows NT, so this is not a "hit in the dark" matter. Here is the list if you're interested: https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids. Moreover, the example above can be used for the opposite scenario of Username or Group Name to SID because the System.Security.Principal .Net Framework namespace contains all the needed info, you just have to modify the example, here is some reference about it https://learn.microsoft.com/en-us/dotnet/api/system.security.principal?view=netframework-4.8.