What's in a name? (once more)

by Michael S. Kaplan, published on 2006/12/01 04:08 -08:00, original URI: http://blogs.msdn.com/michkap/archive/2006/12/01/1183198.aspx


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)


# Pavanaja U B on Friday, December 01, 2006 7:29 AM:

>not all of Microsoft's employees who are involved with software development understand about localizability

Agreed. In fact, the statement should be "not all of Microsoft's employees who are involved with software development understand the importance of localizability". A case in point is the set of new technologies that comprise .NET 3.0. I am talking about WPF, which as of now does not support complex script rendering. The new flagship graphics suite Expression from Microsoft is based on WPF. Naturally that also does not support Indic (complex script). I wish I were wrong here.

-Pavanaja

# Michael S. Kaplan on Friday, December 01, 2006 7:36 AM:

Actually, I believe you are mistaken on that point. Avalon (WPF) supports complex scripts and even complex OpenType features more fully than anything else in managed or unmanaged code that is currently available.....

# Markus Freericks on Friday, December 01, 2006 12:23 PM:

I still don't understand why it is necessary to translate such internal account names at all. To me (as a german-speaking user), the name "NT-AUTORITÄT" is in no way "better" or "easier to understand" than "NT AUTHORITY" -- it doesn't _mean_ anything; it is just a piece of techno-gibberish.

# Peter on Friday, December 01, 2006 1:47 PM:

IMHO, you're dead wrong.  One common reason for a simple table is so that us poor devs can actually have a fighting chance to figure out what's different between different systems.  This table (combined with some hint as to how the table was generated) goes a long way to making our software actually work.

# Michael S. Kaplan on Friday, December 01, 2006 5:05 PM:

Since the table:

1) provided no such hints

2) did not even mention the rename issue

3) did not hint that there were more

I disagree with the premise of the argument you are making, Peter.

A fuller example with a code sample that explained ALL the issues, I would support. What they provide now is incomplete, unhelpful, and misleading...

# Luke on Saturday, December 02, 2006 2:57 AM:

This post has me thinking about some code I have written that calls CreateService. Most of the services I create end up with an NT AUTHORITY\Network Service start identity. I have been passing the string NT AUTHORITY\Network Service based on documentation available at:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createservice.asp

and

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/networkservice_account.asp

Which seems to indicate that NT AUTHORITY\Network Service is not ever localized. My question is - should I be using a SID (S-1-5-20

) instead?

# Dean Harding on Saturday, December 02, 2006 3:47 AM:

According to MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/localservice_account.asp):

"The name of the account in all locales is NT AUTHORITY\LOCALSERVICE"

It says the same thing about Network Service as well (here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/networkservice_account.asp)

And again about LocalSystem (here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/localsystem_account.asp)

So who is right?

# Michael S. Kaplan on Saturday, December 02, 2006 4:11 AM:

Well, "NT AUTHORITY" is often localized , even if account names are not. So it seems like it would make sense to always use the SIDs....

# Michael S. Kaplan on Saturday, December 02, 2006 3:34 PM:

I may agree with Markus that "NT-AUTORITÄT" is no better or worse than "NT AUTHORITY" but that presumes that everyone is comfortable with English here. To which I guess I'd raise two objections:

1) Not everyone wants to see English -- some look at it is an American company that is insensitive to their language;

2) Not everyone even understands English;

The common phrase people like to use is about "the next million users" and the most obvious source of that pool of people who would either buy Windows or buy something else may have as their only blocking factor the fact that they really don't know English at all.

So although I agree with the sentiment that Markus raised and that both "NT-AUTORITÄT" and "NT AUTHORITY" both look like arbitrary symbols that have no real meaning, thus translatation takes meaningless and turns it into translated meaningless, I can't ignore that translated meaningless acutally DOES mean something to some people -- it means the effort is being made.

Which to some people means everything. :-)

# Dean Harding on Saturday, December 02, 2006 8:50 PM:

> So it seems like it would make sense to always use the SIDs

Can you confirm whether that's actually true, though? Because the CreateService documentation is pretty clear that you can use hard-coded strings, which is what I've been doing. If it is true, then perhaps we to amend the documentation?

# Michael S. Kaplan on Sunday, December 03, 2006 12:49 AM:

Well, the Books Online article is telling the truth about the fact that some of these service names are localized, and you cannot use MUI to test out whether this is the case, since they are not localized in the MUI version when it is installed atop English as this post indicates.

But perhaps in the localized versions where this is an issue either (1) the code is smart enough to accept both names, or (2) the localized names are just for display within the UI but would never be used in code, or (3) the CreateService et. al. docs are wrong.

And then mix with this the fact that (4) in Vista every version of Windows is in its on way an MUI version which may change the lay of the land here entirely....

Then, consider the fact that (5) the results may be different across different versions.

Finally, (6) the rename issue masy still be an issue here.

Given all of these issues, it seems until the whole issue is clarified that one should either:

a) be willing to test all of these scenarios in localized versions of NT4, Win2000, Winxp, and Vista, or

b) one should use the SIDs for self-defensive purposes.

But I agree that the docs are very unclear about this issue and should be clarified to avoid the confusion. I will stand by my advice as the guaranteed way to avoid problems in light of unclear documentation, but I much prefer to push things as pure best practices rather than scare tactics/fear of the unknown....


referenced by

2008/06/11 You almost want a cease-and-desist order put out about the docs

2008/05/06 By some accounts, the names can be changed

go to newer or older post, or back to index or month or day