Not all of Microsoft's customers who are involved with software development understand about localizability.

This is something for which they should be held blameless, since not all of Microsoft's employees who are involved with software development understand about localizability. :-)

I was reminded of both of these things the other day when the following customer question happened to pass my field of vision:

I would appreciate if you could get us local names of the "NT AUTHORITY\System" account for all different language Windows Oss. The following article lists some of them but the list probably is not full.

We just need the entire list. We use an API to get the localized name but would like to have a work around if the API call fails.

Thank you very much,
Vladimir

Setting Up Windows Service Accounts

Ok, so obviously one can point to blog posts like Administrator vs. Administrateur, et. al. and such, and one can talk about using well-known SIDs and the LookupaccountSID function and so forth.

In fact this is what some people did.

But clearly we are fighting an uphill battle when topics in SQL Server 2005 Books Online provide tables like this one:

Language Name for Local Service Name for Network Service Name for Local System Name for Admin Group

English

Simplified Chinese

Traditional Chinese

Korean

Japanese

NT AUTHORITY\LOCAL SERVICE

NT AUTHORITY\NETWORK SERVICE

NT AUTHORITY\SYSTEM

BUILTIN\Administrators

German

NT-AUTORITÄT\LOKALER DIENST

NT-AUTORITÄT\NETZWERKDIENST

NT-AUTORITÄT\SYSTEM

VORDEFINIERT\Administratoren

French

AUTORITE NT\SERVICE LOCAL

AUTORITE NT\SERVICE RÉSEAU

AUTORITE NT\SYSTEM

BUILTIN\Administrateurs

Italian

NT AUTHORITY\SERVIZIO LOCALE

NT AUTHORITY\SERVIZIO DI RETE

NT AUTHORITY\SYSTEM

BUILTIN\Administrators

Spanish

NT AUTHORITY\SERVICIO LOC

NT AUTHORITY\SERVICIO DE RED

NT AUTHORITY\SYSTEM

BUILTIN\Administradores

Russian

NT AUTHORITY\LOCAL SERVICE

NT AUTHORITY\NETWORK SERVICE

NT AUTHORITY\SYSTEM

BUILTIN\Администраторы

Now this is not evil in and of itself, but it really describes nothing of what is underneath these names.

And most importantly, it says nothing of the all-important issue regarding the fact that these account names can be changed, and often are changed for security reasons.

In the end, any dependence on a list like this is a recipe for trouble. And including it in the form that they did is just a bad idea.

The argument for wanting the list is that they want it in case the Win32 API function fails. But how far is using an account name going to get a person if the Win32 API security related functions are failing?

The solution is described in KB 157234 (How to deal with localized and renamed user and group names), with a title that underscores the importance of the issue (though personally I would have put the word "localized" second since some people might skip it without reading the whole title if they figure it does not apply to them!).

But the answer to the question in the title (What's in a name?) is really both everything and nothing....

SQL Server Books Online needs to do better with this sort of thing. I think it is great when PSS picks up the slack and covers an issue well, because it is their job to do that when product groups screw up. But in an ideal world, we don't make them work as hard as we tend ro do, if you know what I mean. :-)

 

This post brought to you by А (U+0410, CYRILLIC CAPITAL LETTER A)