spread the dot jenett.radio.randomizer - click to visit a random Radio weblog - for information, contact randomizer@coolstop.com

Cox Crow

Asking the Stupid Questions Since 1971
 Thursday, August 14, 2003

Scotty! I need more POWER!

We've lost power here, and have switched to the diesel generator. It is very important that we deliver the mail and connect your phone calls, even if you can't go on-line because you don't have a generator. The communications infrastructure is an essential service.

CNN reports that a transformer at 14th Steet in Manhattan is afire.

UPDATE: non-critical systems at this datacenter are going off-line.

4:54:44 PM # Google It!

When is a thing not the same thing as itself?

When it is a pronoun used by Microsoft, apparently.

When you specify a user account, you can refer to an account on the local host in one of two ways

  1. NAMEOFSYSTEM\nameOfAccount
  2. .\nameOfAccount

That dot (.) is a pronoun meaning "the name of the system on which I'm typing this string." That way I don't have to type so much. It should then be stored in wherever as the SID of the account in question.

To take a specific example, a service, which is a process that runs without an interactive logon, generally runs under the LocalSystem account. But it can be configured to use any account, either in the trusted domains or in the local host's Security Accounts Manager (SAM) database. Whichever account is chosen must be granted the privilege to log on as a service. Normally, an administrator will open the Services control panel, select the Log On tab, then browse the SAM to pick a user. This user is then granted the appropriate privilege, which you can see if you open the Local Security Policy MMC.

When you pick a user from the local SAM, it is added as .\nameOfAccount. You can type in the name of the host if you want. In either case it is stored in the Registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NameOfService as the string value .\nameOfAccount. The Service Control Manager (SCM) will then use this account to logon.

If the account has not already been granted the logon as a service privilege, then the control panel will grant it. If you didn't type the hostname, then the account .\nameOfAccount will be granted the privilege. If you did, then NAMEOFSYSTEM\nameOfAccount will be granted the privilege.

Pop Quiz: What SID should be stored in the Local Security Policy?

When the account .\nameOfAccount is granted the privilege, things break. It displays as NAMEOFSYSTEM\nameOfAccount, but the privilege isn't really available for use. Instead there's an error:

Event Type:	Error
Event Source:	Service Control Manager
Event Category:	None
Event ID:	7013
Date:		8/14/2003
Time:		2:42:48 PM
User:		N/A
Computer:	NAMEOFSYSTEM
Description:
Logon attempt with current password failed with the following error: 
Logon failure: the user has not been granted the requested logon type at this computer.
Event Type:	Failure Audit
Event Source:	Security
Event Category:	Logon/Logoff 
Event ID:	534
Date:		8/14/2003
Time:		2:42:48 PM
User:		NT AUTHORITYSYSTEM
Computer:	NAMEOFSYSTEM
Description:
Logon Failure:
 	Reason:	The user has not been granted the requested
 		logon type at this machine
 	User Name:	nameOfAccount
 	Domain:		NAMEOFSYSTEM
 	Logon Type:	5
 	Logon Process:	SCMgr   
 	Authentication Package:	MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 	Workstation Name:	NAMEOFSYSTEM

One of the post-SP3 hotfixes changed this. I applied too many at once to know which.

Empirically, neither survives a reboot. I haven't tested this on enough hosts to confirm that it is a general problem. The workaround is to run services as LocalSystem or domain accounts.

3:39:21 PM # Google It!
categories: System Administration

Kicking the Habit

Would you be able to work as effectively if your company did not have Internet access?

9:07:00 AM # Google It!
categories: Security