Vista Administrator: activating

[rodney]

Vista as it ships does not have the Administrator account enabled
or active. This is a regular pain (as in PITA) when trying to get
administrative task done. Because the Vista Administrator account is
not actually active (it's disabled) some things don't work so well.

Here are the steps to active the Administrator account on Vista.
The steps are convoluted because that the way MS makes it.
Logon as a user that is in the Administrators group to do this.

1) You need to make a change in the registry. But you need to run
as Administrator to do it. A bit of a catch-22, eh?! From the Start
Menu find the "Command Prompt" and right click on it. From the popup
menu select "Run as Administrator". A Command window should start.
If a Windows security windows opens select to allow this action.

2) From the Command window run the "regedit" program.

3) Go to the key HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/WinLogon.
Now add (from the Edit menu) a new key (yes, a "key", not a DWORD). Name this
new key "SpecialAccounts".

4) In HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/WinLogon/SpecialAccounts
create a key named "UserList".

5) In HKLM/SOFTWARE/Microsoft/Windows NT/CurrentVersion/WinLogon/SpecialAccounts/UserList
create a new DWORD entry (not a "key" this time). Name this entry "Administrator" and
set the value to "1" (value/digit one).

6) You can now exit from regedit.

7) Now the Administrator account will appear with the other user accounts. But it
won't be active yet. It will still be disabled. You need to enable it. From the
Control Panel select Administrative Tools and then select Computer Management.
The Computer Management panel will appear. Select "Users and Groups" followed
by "Users". Double-click on the "Administrator" account. Make the box with
"Account is disabled" be clear (no check mark). Click "OK" to save this.

8) You should now set the password for Administrator. Right click the entry
for the Administrator account and select "Set Password..." from the pop-up
menu. Follow the directions.

Your done.

You don't want to run the "User Accounts" link in the Control Panel. It'll
just frustrate you because it is "dumbed down" and doesn't have the choices
needed for real changes.

If you want, you can get the Computer Management to start from a Command Prompt.
Start a fresh Command window and run "compmgmt.msc /s".

More pains to overcome:
To set a fixed IP address it a confusing maze to find the right GUI. This
is another failure of the Vista organization and interface. I'm writing
this because I've just about blown a gasket after installing Vista for the
fourth time and it's still coming across as a muddled organization designed
to hide key controls. Is this deliberate incompetence?
Anyway... Control Panel -> Network and Sharing Center -> Manage Network.
Now you get an actual list of the devices on your machine that you can
change. Open properties on a device. This opens the "Local Area Connections
Properties". Make your settings as needed.

To join a domain: Control Panel -> System -> Advanced system settings gives
you the Systems Properties menu. Now it's the usual change actions.

To change screen setting: Control Panel -> Personalization -> Display Settings
"Personalization" is grossly vague when I'm look to change the display or monitor
settings.

[breiter]

In Windows 2000, XP, 2003 there is a group policy setting for enabling and disabling the built-in administrator account.

/Computer Configuration/Windows Settings/Security Settings/Secuiryt Options/Accounts: Administrator Account Status: enabled -or- disabled

I haven't tooled around with Vista yet for want of free time but maybe they just changed the default from enabled to disabled? Managing the setting with gpedit sounds easier than the manual rigmarole if it would work.

[jerker_back]

I agree it's a pain - don't know if it's a useful pain or not yet though.
There is an other way:
* Disable the User Account Control (UAC) => your account IS really Administrator.
However, I didn't do that - tried to manage as intended by design (see Paul Thurrott's Vista site)
But at first encounter, as a Windows user, you really hate UAC
* Start the shell with "Run as Administrator" - this works somehow

The problem I found most annoying is that SUA installs with the local Admin (normally disabled account) and all rights exclusivly to him and the local Admin group. If you have a domain account (regardless of level), you have no rights at all (inforced by UAC). The only solution is the change ownership to yourself and add your domain group. That is really PITA if you understand what it takes to do that. All this could be an installation issue though (I started the install with "Run as Administrator").

[g_jake]

See http://www.techexams.net/blogs/jdmurray/...s-password

Here you don't have to mess with editing the registry.

[djet]

I wonder why should one enable the (intentionally) disabled built-in Administrator account. Everything works (at least for me) with my own admin account. And it's bad for security having more enabled accounts than neccessary.

[breiter]

For example, you want your day-to-day login to *NOT* be a member of Administrators. Maybe you want to do that because UAC is a speed bump, not a really solid security boundary. UAC is actually just training wheels to teach users how to live as a non-admin, without actually taking the access tokens away.

Mark Russinovich: http://blogs.technet.com/markrussinovich...38372.aspx

As you experiment you’ll find that your actions are limited, but there are some design boundaries that you should be aware of. First, with the exception of processes and threads, the wall doesn’t block reads. That means that your low-IL command prompt or Protected Mode IE can read objects that your account (the standard-user version if you’re a member of the administrator’s group) can. This potentially includes a user’s documents and registry keys.

Even the ability of a process at low IL to manipulate objects of a higher IL isn’t necessarily prevented. Since processes running at different integrities are sharing the same desktop they share the same “session”. Each user logon results in a new session in which the processes of the user execute. The session also defines a local namespace through which the user’s processes can communicate via shared objects like synchronization objects and shared memory. That means that a process with a low IL could create a shared memory object (called a section or memory-mapped file) that it knows a higher IL process will open, and store data in the memory that causes the elevated process to execute arbitrary code if the elevated process doesn’t properly validate the data. That kind of escape, called a squatting attack, is sophisticated, requires the user to execute processes in a specific order and requires knowledge of the internal operation of an application that is susceptible to manipulation through shared objects.

However, let’s be clear that no matter how difficult to pull off, the mere possibility of such a breach of a sandbox wall implies that ILs, in and of themselves, do not define security boundaries. What’s a security boundary? It’s a wall through which code and data can’t pass without the authorization of a security policy. User accounts running in separate sessions are separated by a Windows security boundary, for example. One user should not be able to read or modify the data of another user, nor be able to cause other users to execute code, without the permission of the other user. If for some reason it was possible to bypass security policy, it would mean that there was a security bug in Windows (or third-party code that allows it).

It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard. Further, as Jim Allchin pointed out in his blog post Security Features vs Convenience, Vista makes tradeoffs between security and convenience, and both UAC and Protected Mode IE have design choices that required paths to be opened in the IL wall for application compatibility and ease of use.

Also, you might want to use daemons that have to start as the built-in administrator, like sshd.

[chotto.bhoot]

Hope primary action should go like this.
http://microsoft-solution.blogspot.com/

If still it does not work for somebody then please follow Rodney's advice.It is useful.I just wonder if this blog can help few normal user.Thanks to this kind of forums.

[yjo]

All the command line instructions above give the impression that re-enabling Administrator is an option buried away out of view. The disabled Administrator account was just where I expected it in the Local Users and Groups mmc plugin (right-click My Computer -> Manage). The user account can then be re-enabled and a password set more easily if you're not a frequent user of the command line equivalents.

[pissedvistaguy4000]

7) Now the Administrator account will appear with the other user accounts. But it
won't be active yet. It will still be disabled. You need to enable it. From the
Control Panel select Administrative Tools and then select Computer Management.
The Computer Management panel will appear. Select "Users and Groups" followed
by "Users". Double-click on the "Administrator" account. Make the box with
"Account is disabled" be clear (no check mark). Click "OK" to save this.

i cant find the users and groups thing...where is it supposed to be exactly? shared folders? reliability/performance? plz help

[rodney]

> i cant find the users and groups thing...where is it supposed to be exactly?

It depends if you are running Active Directory (AD) or on a standalone machine.
A expect the latter given your questions. So you want to start the program
"Computer Management". You can usually find it under the Control Panel.
Start the Control Panel and then open the Administrative Tools icon.
Then select Computer Management. Should be clear after that.