Учетная запись администратора windows vista

Была ли эта статья полезной?

In Windows Vista, there is a difference between accounts with “computer administrator” privileges and the Administrator account. In the Administrator account, the User Account Control is disabled. Also, the Administrator account is present, but hidden and disabled by default.

Please be aware that Vista Beta 2 has a bug that may cause big problems, if a password is created for the Administrator account in Computer Management.

Enabling the Windows Vista Administrator Account

Here are two methods that will teach the user how to enable the Windows Vista Administrator Account.

Method 1

1. Boot the computer to Vista in the computer administrator account, then open administrative tools in the control panel. Double click the computer management item to open it.
2. Authorize user accounts control by clicking the continue button.
   • Double click “local users and groups” to open it.
   • Click the user’s folder.
   • Select the administrator icon.
   • Right click it to open its content menu.
   • Choose properties.
   • Remove the check mark from the “account is disabled” box.
   • Click OK.
   • Restart the computer.
3. Once the computer restarts, open the administrative tools control panel.
4. In the Users area, disable any other enabled accounts with computer administrator privileges.
   • Look for account icons that do not have the red disable mark.
   • Click to place a check mark on these account icons.
5. Open Properties.
   • Click to add a check mark in the box labeled “Account Is Disabled.”
6. Check to see that the Administrator account is enabled.
7. Close Computer Management and restart Windows.
8. When vista reboots, the administrator account will be loaded automatically.

Be advised that this method is for temporary use only, for security reasons. Never leave one’s Administrator account enabled without a password.

Method 2

1. Turn on the computer.
   • As Windows is starting up, when “Starting Windows” comes on the screen, quickly press F8.
   • In a dual boot environment, this can be done easily from the boot menu.
2. When the boot menu is showing:
   • Use the arrow or tab keys to select “Microsoft Windows” (this is the option that runs Windows Vista).
   • Do not press Enter. Instead, press the F8 key and progress to the Safe Mode boot screen.
   • At the Safe Mode boot screen, select the first option, “Safe Mode.”
   • Press Enter.

   It will take a few moments, but Vista will present a login screen that has two options, Administrator and Other User.

3. Click the Administrator icon.

The Windows Vista Administrator account is now enabled.

Starting with Windows Vista, the built-in Windows Administrator account is disabled by default. This account is separate from administrator-level user accounts, although both have the same privileges. Since that’s the case, is it best to ignore the Windows Administrator account?

Well, yes and no. Windows operates fine without it and most people will never really need to use that account. However, it does offer a bit more power and flexibility than a regular user account—at the risk of reduced security.

Let’s take a look at the Windows Administrator account so you can fully understand what it’s for.

What Is the Windows Administrator Account?

In Windows XP and prior versions, every installation of Windows had a special account called Administrator enabled by default. This account has the highest permissions of any profile on the computer, and thus can do anything with elevated administrator privileges without requiring confirmation. It’s akin to the «root» or «superuser» accounts in other operating systems.

The Administrator account posed a security problem in past Windows versions. By default, the password for it was blank. This meant that unless you set a password for the account, anyone with a bit of know-how could log into the Administrator account and gain full access to the system.

Картинка с сайта: www.makeuseof.com

And since the Administrator account has no protections, using it daily is dangerous. If you mistakenly installed malware, there would be nothing to stop it from infecting everything on your computer. This, combined with introducing more flexible account security options, is why Microsoft disabled the Administrator account by default starting in Windows Vista.

The Windows Administrator Account and UAC

In Windows Vista and beyond, every normal user account has to deal with User Account Control (UAC). UAC shows a window with a security prompt whenever you want to perform an action that requires elevated privileges. Such actions include installing a program for all users, editing the Registry, opening a Command Prompt as an admin, and similar.

When prompted by UAC, standard user accounts must enter the credentials for an admin account (username and password) to proceed. On the other hand, administrator-level user accounts only have to click a confirmation button to continue.

Even as an administrator, this can become an annoyance, especially if you have to confirm dozens of UAC prompts every day.

Картинка с сайта: www.makeuseof.com

The Windows Administrator account bypasses all UAC protections, because it has no limitations or boundaries. There are other ways to bypass UAC prompts in Windows without resorting to the built-in Administrator account, but they aren’t particularly convenient (since the feature is built to keep your PC safe).

Should You Use the Windows Administrator Account?

As mentioned, Windows 10 and other modern versions keep the Administrator account disabled by default. However, it’s still there; you must manually enable it before you can start using Administrator in modern versions of Windows.

We don’t recommend this in most circumstances, however. Using the Administrator account can open up several security risks on your system. Not only will malware have free reign if you run it under this account, but you also won’t have a layer of protection from making mistakes.

For example, say you mistype something in the Command Prompt and mistakenly enter a command that would end up deleting a lot of files. You won’t get a warning under the Administrator account—the command will run as entered.

Thus, you should only enable the Administrator account if you know what you’re doing and can accept any potential consequences. It might be necessary for troubleshooting deep system-level issues in some cases, but if you do enable the account, it’s smart to disable the Administrator account again as soon as you’re done with it.

How to Enable or Disable the Windows Administrator Account

Across Windows 10, 8.1, and 7, there are up to three ways to enable (and disable) the Windows Administrator account. They’re all equally effective, but the Command Prompt method is the only one that works in Windows Home versions. It’s also quick, so give that one a try unless you really prefer another.

Once the account is enabled through any method, you can sign into the Windows Administrator account just like you would any other account. Pick it from the account selection screen when you boot into Windows, or click it from the list that appears when you click on your profile picture on the Start menu.

Картинка с сайта: www.makeuseof.com

Method 1: Command Prompt

First, you’ll need to open the Command Prompt (CMD) interface. A normal CMD window does not have administrator privileges, which is required for this task. Thus, you’ll need to run the Command Prompt as an administrator.

This kind of terminal window is called elevated. See our intro to the Command Prompt for more basics.

Elevating the Command Prompt is easy. Open the Start Menu and type cmd into the search bar. When the results show up, right-click on Command Prompt and choose Run as administrator. If a UAC prompt shows up, click Yes.

Картинка с сайта: www.makeuseof.com

Now that the prompt is open, type or copy/paste the following command and press Enter:

        net user administrator /active:yes
    

To disable the Administrator account later, simply swap the yes part for no:

        net user administrator /active:no
    

Method 2: Local Users and Groups

If you don’t like the Command Prompt, you can enable or disable the Administrator account with a graphical method: the Local Users and Groups window. This is handy for system admins in a business setting, but you’ve probably never dealt with it as a home user. Don’t worry, though—it’s not difficult to understand.

Keep in mind that this only works in Professional (and above) versions of Windows. If you have Windows 10 Home or another Home version, you can’t open this panel. Use the Command Prompt method above instead.

To start, open the Run window by pressing Win + R. In the box that appears, type lusrmgr.msc into the field and click OK or hit Enter. This opens Local Users and Groups.

Inside that window, click Users in the left pane, then right-click on Administrator and select Properties. Under the General tab, you should see a box labeled Account is disabled. Deselect this option, click OK, then close the window.

Картинка с сайта: www.makeuseof.com

Now the Administrator account is ready to use. To disable it later, repeat these steps and check the Account is disabled box again.

Method 3: Local Security Policy

Another approach to enable the Administrator account, if you don’t like the first two for whatever reason, is to use the Local Security Policy editor. It’s the most complicated option of the three, but it’s still straightforward enough.

Like the option mentioned above, this only works in at least Windows Pro. If you have Windows Home, you can’t access this menu.

Start by opening the Run prompt again, using Win + R. Type secpol.msc into the dialog that shows up, which will open the Local Security Policy interface.

Here, expand Local Policies in the left pane, then select Security Options in the hierarchy under it. In the right pane, find Accounts: Administrator account status and double-click it.

This will show a new window. On the Local Security Setting tab, switch to Enabled, then click OK.

Картинка с сайта: www.makeuseof.com

Now the Administrator account is ready to use. To turn it off in the future, just repeat this and choose Disabled instead.

Add a Password to the Windows Administrator Account

Once you’ve enabled the Administrator account, it’s a smart idea to add a password to it. By default, the admin account doesn’t have a password, so anyone with access to your PC could use it to get full control.

With the Admin account open, open the Settings app with Win + I and head to Accounts > Sign-in options. Select Password > Change to add a proper password to the account.

For more convenience, you might wish to change the account’s password using the Command Prompt instead. Once you change it, don’t lose the password. If you ever need the Administrator account in the future, you’ll run into problems if you don’t have the password.

Renaming the Windows Administrator Account

Now that the Administrator account is enabled and secured with a password, there’s one more point to consider. Hackers and malware distributors are always finding new ways to gain access to the Administrator account, since it’s so powerful. With it enabled, you’ll be at greater risk.

To reduce your vulnerable surface, we recommend disabling the Administrator account as soon as you’re done using it. If you feel the need to keep it enabled for long periods of time, though, you can change the account’s name to something that doesn’t stick out as much.

This won’t provide any real protection from attacks designed to exploit the Administrator account. But in case an attack only checks for an account called «Administrator,» or you’re worried about someone with local access noticing it, this can help. You may want to change it just for fun, as well.

To rename the Administrator account, launch an elevated Command Prompt again as above. Then type or copy/paste the following, replacing NewUserName with the name you want to use:

        wmic useraccount where name='Administrator' rename 'NewUserName'
    

The Administrator account will be renamed to whatever you inputted. This method should work on Windows 10, 8.1, and 7. And in case you don’t want to use the Command Prompt, there are graphical renaming methods to use instead.

If you’re on a Professional or above version of Windows, follow the steps in #2 above to open the Local Users and Groups panel. There, right-click on the Administrator entry and choose Rename, which will allow you to type a new name for the account.

On Windows Home, you can rename the Administrator account with another graphical method, as long as you’ve already enabled the account. Open the Run dialog (Win + R) and enter netplwiz. In the list of accounts, double-click on Administrator and you can change the User name there (as well as the Full name if you like).

Картинка с сайта: www.makeuseof.com

Master the Windows Admin Account

Now you know everything there is to understand about the default Administrator account in Windows. And though we’ve said it several times, it’s important to emphasize: unless you absolutely need the Windows Administrator account for a very specific purpose, do not use it.

There’s a reason why Microsoft implemented UAC in every modern version of Windows. It’s more secure, while still offering convenience for most admin tasks. And if you ever forget your admin password in Windows, it’s thankfully possible to recover it.

В. Какие пользователи являются локальными администраторами в Windows Vista?

О. Windows Vista сильно отличается от Windows XP. В XP все локальные учетные записи пользователей, созданные в процессе установки с помощью мастера установки, назначаются локальными администраторами. Они получают много полномочий, поэтому не следует наделять многих пользователей административными правами. В Windows Vista встроенная учетная запись Administrator по умолчанию заблокирована, и только учетная запись первого пользователя, создаваемая при работе мастера установки, получает права администратора. Все остальные учетные записи, созданные с помощью мастера установки, обладают правами обычных пользователей. Учетным записям пользователей можно присвоить административные полномочия в разделе User Accounts в панели управления.

Управление учетными записями пользователей (UAC) — функция Windows Vista, которую часто недооценивают. В моей серии из трех статей в журнале TechNet Magazine, посвященной нововведениям в ядре Windows Vista, которую можно прочесть на веб-узле technetmagazine.com, я не касался UAC, поскольку чувствовал, что эта тема достойна отдельной статьи.

В этой статье мы затронем проблемы, которые решает UAC, а также архитектуру и реализацию ее ключевых технологий. Эти технологии включают пересмотр операций, которые ранее требовали административных прав; облегченную виртуализацию, которая помогает программам правильно работать без административных привилегий; возможность явного запроса программами административных прав и изоляцию административных процессов от неадминистративных, работающих в той же пользовательской системе.

Назначение UAC
 

Функция UAC призвана обеспечить пользователям возможность работать с правами обычного пользователя, не прибегая к административным. Обладая административными правами, пользователь может просматривать и изменять любую часть операционной системы, включая код и данные других пользователей и даже самой Windows®. Без административных прав пользователи не могут случайно (или преднамеренно) изменить системные параметры, вредоносная программа не может изменить параметры системной безопасности или отключить антивирусное программное обеспечение, а пользователи не могут нарушить безопасность важных данных других пользователей на общедоступных компьютерах. Работа с правами обычного пользователя, таким образом, помогает уменьшить количество срочных вызовов службы поддержки в корпоративных средах, смягчить ущерб от вредоносной программы, способствует более четкой работе домашних компьютеров и защищает уязвимые данные на общедоступных.

С помощью UAC предполагалось решить несколько проблем с тем, чтобы работа под учетной записью обычного пользователя стала общепринятой практикой. Во-первых, до Windows Vista™ общепринятой моделью использования Windows была работа с привилегиями администратора. Разработчики программного обеспечения почему-то считали, что их программы должны иметь получать доступ и изменять любой файл, параметр реестра или настройку операционной системы. Даже когда в Windows NT® были введены функции безопасности и разные уровни доступа для административных учетных записей и обычных пользователей, в процессах настройки продолжала широко использоваться встроенная учетная запись “Администратор” или учетная запись, входящая в группу “Администраторы”.

Второй проблемой, которую должна была решить функция UAC, было то, что пользователи иногда нуждаются в административных правах для выполнения таких операций, как установка программного обеспечения, изменение системного времени и открытие портов в брандмауэре.

Решение этих проблем с помощью UAC состоит в том, чтобы большинство приложений запускать с правами обычного пользователя, исключить потребность в частом использовании прав администратора и поощрять разработчиков программного обеспечения создавать приложения, работающие с правами обычного пользователя. UAC достигает этого, реже требуя административных прав, обеспечивая работу более ранних версий приложений с правами обычного пользователя, позволяя обычным пользователями легко получать административные права (когда они в них действительно нуждаются), а администраторам — работать так, как если бы они были обычными пользователями.

Работа с правами обычного пользователя
 

В ходе полной проверки всех административных операций во время разработки Windows Vista было установлено, что многие из них могли бы выполняться обычными пользователями без ущерба для безопасности системы. К примеру, даже корпорации, в которых на настольных системах Windows XP принято использовать учетные записи обычных пользователей, не могли удалить своих мобильных пользователей из группы “Администраторы” по той простой причине, что Windows XP не делает отличий между изменением часового пояса и изменением системного времени. Пользователь переносного компьютера, который хочет настроить локальный часовой пояс так, чтобы в поездках его встречи правильно отображались в календаре, должен иметь привилегию “Изменение системного времени” (внутреннее имя SeSystemTimePrivilege), которая по умолчанию предоставляется только администраторам.

Время обычно используется в протоколах безопасности, таких как Kerberos, но часовой пояс влияет только на способ отображения времени. Поэтому в Windows Vista добавлена новая привилегия, “Изменение часового пояса” (SeTimeZonePrivilege), которая назначена группе “Пользователи” (см. рис. 1). Это позволяет корпоративным пользователям переносных компьютеров работать с учетными записями обычных пользователей.

Картинка с сайта: corem.ru

Рис. 1 Привилегия “Изменение часового пояса”

Windows Vista также позволяет обычным пользователям настраивать параметры WEP-шифрования при подключении к беспроводным сетям, создавать подключения к виртуальной частной сети, изменять параметры управления электропитанием и устанавливать критические обновления Windows. Кроме того, в Windows Vista введены параметры групповой политики, с помощью которых обычные пользователи могут устанавливать драйверы принтера и других устройств, одобренные ИТ-администраторами, и устанавливать элементы управления ActiveX® с одобренных администраторами веб-узлов.

А что же потребительские и бизнес-приложения, которые неправильно работали с учетными записями обычного пользователя? Хотя для работы некоторых программ действительно требуются административные права, многие из них совершенно необоснованно хранят пользовательские данные в областях, общих для всей системы. Корпорация Майкрософт рекомендует, чтобы установщики глобальных приложений, которые должны работать с административными правами, для хранения исполняемых файлов и вспомогательных данных приложений создавали подкаталоги в каталоге %ProgramFiles%, а для параметров приложений — подраздел в разделе реестра HKEY_LOCAL_MACHINESoftware. Приложение может работать с разными учетными записями пользователей и поэтому должно хранить данные пользователей в соответствующих им каталогах %AppData%, а параметры, относящиеся к данному пользователю — в профиле пользователя в разделе реестра HKEY_CURRENT_USERSoftware. Учетные записи обычного пользователя не имеют доступа для записи к каталогу %ProgramFiles% и разделу HKEY_LOCAL_MACHINESoftware. Однако, поскольку большинство систем Windows является однопользовательскими, а большинство пользователей вплоть до Windows Vista были администраторами, то приложения, даже если неправильно сохраняли пользовательские данные и параметры в этих местах, в любом случае работали.

В Windows Vista эти старые приложения могут работать с учетными записями обычного пользователя за счет применения виртуализации файловой системы и пространства имен реестра. Когда приложение изменяет данные в частях файловой системы или реестра, общих для всей системы, и эта операция проходит неудачно из-за отказа в доступе, Windows перенаправляет операцию в область соответствующего пользователя. Когда приложение считывает данные из системно-глобального размещения, Windows сначала проверяет данные в области пользователя и, если их там не находит, разрешает чтение из глобального размещения.

Для целей этой виртуализации Windows Vista обрабатывает процесс как устаревший, если он 32-разрядный (а не 64-разрядный), выполняется не с административными правами и не имеет файла манифеста, указывающего, что он написан для Windows Vista. Любые операции, происходящие из процесса, не подпадающего под это определение, включая доступ к сетевому общему файловому ресурсу, не виртуализуются. Состояние виртуализации процесса хранится в виде флага в его маркере, представляющем собой структуру данных ядра, которая отслеживает контекст безопасности процесса, включая его учетную запись пользователя, членство в группах и привилегии.

Чтобы увидеть состояние виртуализации процесса, можно добавить столбец “Виртуализация” к странице “Процессы” диспетчера задач. На рис. 2 показано, что для большинства компонентов Windows Vista, включая диспетчер окон рабочего стола (Dwm.exe), подсистему клиент-серверной среды выполнения (Csrss.exe) и проводник, виртуализация отключена, поскольку они либо обладают манифестом Windows Vista, либо выполняются с административными правами и, следовательно, не допускают виртуализацию. Для обозревателя Internet Explorer® (iexplore.exe) виртуализация включена, так как он может поддерживать элементы управления ActiveX и сценарии и не должен полагаться на то, что они будут правильно работать с правами обычного пользователя.

Картинка с сайта: corem.ru

Рис. 2 Состояние виртуализации в окне диспетчера задач

Области файловой системы, виртуализуемые для устаревших процессов, — это %ProgramFiles%, %ProgramData% и %SystemRoot%, за исключением некоторых определенных подкаталогов. Однако из виртуализации исключаются все файлы с расширением исполняемого файла, в том числе EXE, BAT, SCR, VBS и другие. В результате программы, которые обновляют себя под учетной записью обычного пользователя, терпят сбой вместо создания частных версий своих исполняемых файлов, которые не видны администратору, запускающему глобальный модуль обновления. Чтобы добавить к списку исключений дополнительные расширения, введите их в следующем разделе реестра и перезагрузите компьютер:

HKEY_LOCAL_MACHINESystemCurrentControlSet ServicesLuafvParametersExcludedExtensionsAdd

Для ввода нескольких расширений следует использовать мультистроковый тип, вводя каждое расширение в отдельной строке без начальной точки.

Изменения, производимые в виртуализованных каталогах устаревшими процессами, перенаправляются в виртуальный корневой каталог пользователя, %LocalAppData%VirtualStore. Например, если виртуализованный процесс, работающий в моей системе, создает файл C:WindowsApplication.ini, фактически создается файл C:UsersMarkrussAppDataLocalVirtualStoreWindowsApplication.ini. Элемент пути Local указывает на тот факт, что если учетная запись имеет перемещаемый профиль, виртуализованные файлы не перемещаются с остальной частью профиля.

Если в проводнике перейти к каталогу, содержащему виртуализованные файлы, на панели инструментов появляется кнопка “Файлы совместимости” (рис. 3). Нажатие этой кнопки открывает соответствующий подкаталог VirtualStore, в котором собраны виртуализованные файлы.

Картинка с сайта: corem.ru

Рис. 3 Кнопка “Файлы совместимости” говорит о наличии где-то рядом виртуализованных файлов

На рис. 4 показано, как драйвер фильтра UAC для виртуализации файлов (%SystemRoot%System32DriversLuafv.sys) реализует виртуализацию файловой системы. Поскольку это драйвер фильтра файловой системы, он видит все операции в файловой системе, но реализует функциональные возможности только для операций из устаревших процессов. Как видно на рисунке, он изменяет путь целевого файла для устаревшего процесса, который создает файл в размещении, общем для всей системы, но не делает этого для процесса приложения Windows Vista, работающего с правами обычного пользователя. Устаревший процесс полагает, что операция прошла успешно, если она фактически создала файл в размещении, полностью доступном пользователю. Но применяемые по умолчанию разрешения для каталога Windows не дают доступа к нему приложению, написанному для Windows Vista.

Рис. 4 Виртуализация файловой системы

Виртуализация реестра реализована несколько иначе, чем виртуализация файловой системы. Виртуализованные разделы реестра включают большую часть ветви HKEY_LOCAL_MACHINESoftware, но есть и многочисленные исключения, например следующие:

HKLMSoftwareMicrosoftWindows HKLMSoftwareMicrosoftWindows NT HKLMSoftwareClasses

Виртуализуются только разделы, которые часто изменяются устаревшими приложениями, но не вызывают проблем совместимости или взаимодействия. Windows перенаправляет операции изменения виртуализуемых разделов устаревшим приложением в виртуальный корневой раздел реестра пользователя в разделе HKEY_ CURRENT_USERSoftwareClassesVirtualStore. Этот раздел расположен в файле %LocalAppData%MicrosoftWindowsUsrClass.dat, в кусте Classes пользователя, который, как и все прочие данные виртуализованных файлов, с перемещаемым профилем пользователя не перемещается.

Вместо хранения фиксированного списка виртуализованных размещений, как это делается для файловой системы, состояние виртуализации раздела хранится в виде флага REG_ KEY_DONT_VIRTUALIZE в самом разделе. С помощью служебной программы Reg.exe можно просмотреть этот флаг, а также два других флага, связанные с виртуализацией, — REG_KEY_ DONT_SILENT_FAIL и REG_KEY_ RECURSE_FLAG (см. рис. 5). Если флаг REG_KEY_DONT_SILENT_FAIL установлен и раздел не виртуализован (установлен флаг REG_KEY_DONT_VIRTUALIZE), устаревшему приложению, которому иначе было бы запрещено выполнять операции с разделом, предоставляется любой уровень доступа к разделу, который имеет пользователь, вместо доступа, затребованного приложением. Флаг REG_KEY_RECURSE_FLAG указывает, наследуют ли новые разделы флаги виртуализации родительского раздела, а не только флаги, применяемые по умолчанию.

Картинка с сайта: corem.ru

Рис. 5 Служебная программа Reg показывает флаги виртуализации

На рис. 6 показано, как виртуализация реестра реализуется диспетчером конфигураций, который управляет реестром в ядре операционной системы, Ntoskrnl.exe. Как и в случае с виртуализацией файловой системы, устаревший процесс, создающий подраздел виртуализованного раздела, перенаправляется в виртуальный корневой раздел реестра пользователя, но процессу Windows Vista будет отказано в доступе применяемыми по умолчанию разрешениями.

Кроме виртуализации файловой системы и реестра, для правильной работы с правами обычного пользователя некоторых приложений требуется дополнительная поддержка. Например, приложение, которое проверяет членство учетной записи, под которой оно работает, в группе “Администраторы”, откажется работать, если учетная запись не входит в эту группу. Поэтому Windows Vista определяет ряд режимов совместимости приложений с тем, чтобы такие приложения всё равно смогли работать. Эти режимы совместимости, обычно применяемые к устаревшим приложениям для операций с обычными правами, показаны на рис. 7.

Рис 7  Общие режимы совместимости для пользователей

Режим совместимости Назначение

ИТ-специалисты в корпорациях могут использовать такие инструменты, как набор средств для обеспечения совместимости приложений (ACT), который можно получить на веб-узле technet.microsoft .com/windowsvista/aa905066.aspx, и служебную программу – анализатор обычного пользователя (SUA) из этого набора или воспользоваться блогом Аарона Маргозиса (Aaron Margosis) LUA Buglight, где можно определить требования для режимов совместимости бизнес-приложений. Режимы совместимости назначаются для приложения с помощью администратора совместимости, также входящего в состав ACT, затем результирующая база данных совместимости (файл SDB) развертывается на настольных системах согласно групповой политике. Следует отметить, что в случае необходимости виртуализация может быть полностью отключена для системы с помощью параметра локальной политики безопасности.

Эффекты виртуализации

Состояние виртуализации процесса можно изменить, выбрав “Виртуализация” в контекстном меню, которое появляется, если щелкнуть процесс правой кнопкой мыши в окне диспетчера задач. На рис. А показано поведение командной строки при изменении ее состояния виртуализации. Командная строка запускается с отключенной виртуализацией, поскольку обладает манифестом Windows Vista. Поскольку она работает с правами обычного пользователя, создать файл в каталоге Windows ей не удается, но после виртуализации с помощью диспетчера задач файл, вроде бы, успешно создается. После возвращения отключенного состояния виртуализации командной строки она не сможет найти файл, который на самом деле находится в виртуальном хранилище пользователя.

Картинка с сайта: corem.ru

Рис. А Изменение состояния виртуализации

Режим одобрения администратором
 

Даже если пользователи запускают только программы, совместимые с правами обычного пользователя, некоторые операции все равно требуют административных прав. Подавляющее большинство установок программного обеспечения требует административных прав для создания каталогов и параметров реестра в размещениях, общих для всей системы, или для установки драйверов устройств либо служб. Изменение глобальных системных параметров Windows и приложений также требует административных прав, как, например, функция родительского контроля в Windows Vista. Большую часть этих операций можно было бы выполнить путем переключения на отдельную учетную запись администратора, но неудобство такой процедуры вероятнее всего приведет к тому, что большинство пользователей будет выполнять свои ежедневные задачи, так и оставшись в административной учетной записи.

В связи с этим Windows Vista содержит расширенные функциональные возможности “запуска от имени”, чтобы обычные пользователи могли комфортно запускать процессы с административными правами. Эти возможности нужны для того, чтобы у приложений был способ определения операций, для которых система может по мере необходимости получать административные права от имени приложения. На этом моменте я кратко остановлюсь ниже.

Далее, чтобы пользователи, действующие как системные администраторы, могли работать с правами обычного пользователя, не вводя имена пользователей и пароли каждый раз, когда им нужно обратиться к административным правам, в Windows Vista введен режим одобрения администратором (Admin Approval Mode, AAM). Эта функция создает для пользователя два набора учетных данных для входа в систему: один с правами обычного пользователя, а другой с административными. Так как каждый пользователь в системе Windows Vista или является обычным пользователем, или работает в основном как обычный пользователь в AAM, разработчики должны рассчитывать на то, что все пользователи Windows — это обычные пользователи, в результате чего будет больше программ, работающих с правами обычного пользователя без виртуализации или режима совместимости.

Предоставление процессу административных прав называется повышением прав. Если эта процедура выполняется под учетной записью обычного пользователя, она называется повышением “через плечо” (Over the Shoulder, OTS), поскольку требует ввода учетных данных для учетной записи, которая является членом группы администраторов. Это похоже на ситуацию, когда “из-за спины” обычного пользователя что-то печатает другой пользователь. Повышение, выполняемое пользователем AAM, называется повышением по согласию, поскольку пользователь просто должен одобрить присвоение его административных прав.

Windows Vista считает пользователя администратором, если он является членом любой из групп административного типа, перечисленных на рис. 8.

Рис 8  Административные группы

Встроенная группа “Администраторы”

Многие из перечисленных групп используются только в системах – участниках доменов и непосредственно не дают пользователям локальных административных прав, но позволяют им изменять параметры всего домена. Если пользователь является членом любой из этих групп, но не фактической группы администраторов, то, вместо повышений согласия, он обращается к своим административным правам через OTS-повышения.

Когда пользователь, принадлежащий одной из перечисленных групп, входит в систему, Windows Vista создает маркер, представляющий версию административного идентификатора этого пользователя, но с правами обычного пользователя. Новый маркер лишается всех привилегий, назначенных пользователю, кроме привилегий, перечисленных на рис. 9, которые являются применяемыми по умолчанию привилегиями обычного пользователя.

Рис 9  Привилегии обычного пользователя

Понятное название Внутреннее имя

Кроме того, все группы административного типа отмечаются в новом маркере флагом USE_FOR_DENY_ONLY. На рис. 10 в окне программы Sysinternals Process Explorer (средство управления процессами, которое можно загрузить на веб-узле microsoft .com/technet/sysinternals) слева показано членство в группах и привилегии процесса, работающего с административными правами, а справа — без административных прав. (Для предотвращения неосторожного использования модель безопасности Windows требует, чтобы перед использованием привилегия со снятым флагом была включена.)

Картинка с сайта: corem.ru

Рис. 10 Маркеры администратора AAM и обычного пользователя

Группа с флагом “только для запрещения” может использоваться только для запрещения пользовательского доступа к ресурсу, но никогда не разрешает доступ. Тем самым закрывается брешь в системе безопасности, которая может возникнуть в случае полного удаления группы. Например, у файла есть список управления доступом (ACL), который запрещает любой доступ для группы “Администраторы”, но предоставляет некоторый доступ другой группе, к которой относится пользователь. Если группа администраторов отсутствует в маркере, этот пользователь получит доступ к файлу, поскольку версия его идентификатора со стандартными правами имеет больше прав доступа, чем административная.

Автономные системы, которыми обычно являются домашние компьютеры, и системы, входящие в состав доменов, обрабатывают AAM-доступ со стороны удаленных пользователей по-разному, поскольку доменные компьютеры в своих разрешениях доступа к ресурсам могут использовать доменные административные группы. Когда пользователь обращается к общедоступному файловому ресурсу на автономном компьютере, Windows запрашивает удостоверение удаленного пользователя с правами обычного пользователя, но на системах, объединенных в домен, Windows соблюдает все членства пользователя в группах домена, запрашивая административный идентификатор пользователя.

Удобное получение административных прав
 

Определить потребность в административных правах системы и приложений можно множеством способов. Один из них — команда контекстного меню и ярлык “Запуск от имени администратора” в пользовательском интерфейсе проводника. Эти элементы содержат цветной значок щита, который должен быть добавлен ко всем кнопкам или пунктам меню, выбор которых приводит к повышению прав. При выборе элемента “Запуск от имени администратора” проводник вызывает API-функцию ShellExecute с командой “runas”.

Подавляющее большинство программ установки требует административных прав, поэтому загрузчик образов, который инициирует запуск исполняемого файла, содержит код обнаружения установщиков для выявления устаревших версий установщиков. Часть алгоритмов используемой загрузчиком эвристики довольно проста: он ищет слова “setup”, “install” или “update” в имени файла образа или внутренней информации о версии. Более сложные алгоритмы включают просмотр в исполняемом файле последовательностей байтов, обычно применяемых сторонними разработчиками в служебных программах – установочных оболочках.

Чтобы определить, нуждается ли целевой исполняемый файл в правах администратора, загрузчик образов также вызывает библиотеку совместимости приложений (appcompat). Библиотека обращается к базе данных совместимости приложений, чтобы определить, связаны ли с исполняемым файлом флаги совместимости RequireAdministrator или RunAsInvoker.

Самый общий способ запросить для исполняемого файла административные права — добавить в его файл манифеста приложения тег requestedElevationLevel. Манифесты — это XML-файлы, содержащие дополнительные сведения об образе. Они были введены в Windows XP как способ определения зависимостей для параллельно используемых библиотек DLL и сборок Microsoft .NET Framework. Наличие в манифесте элемента trustInfo (он показан ниже во фрагменте дампа Firewallsettings.exe) означает, что исполняемый файл был написан для Windows Vista и содержит элемент requestedElevationLevel. Атрибут level этого элемента может иметь одно из трех значений: asInvoker, highestAvailable и requireAdministrator.

Исполняемые файлы, не требующие административных прав, например Notepad.exe, имеют значение атрибута asInvoker. В некоторых исполняемых файлах заложено допущение, что администраторы всегда хотят получить максимальный доступ. Поэтому в них используется значение highestAvailable. Пользователю, запускающему исполняемый файл с этим значением, предлагается повысить права, только если он работает в режиме AAM или рассматривается как администратор согласно определенным ранее правилам и в связи с этим должен повысить права для обращения к своим административным привилегиям. Примерами приложений, для которых используется значение highestAvailable, могут служить программы Regedit.exe, Mmc.exe и Eventvwr.exe. Наконец, значение requireAdministrator всегда инициирует запрос повышения и используется всеми исполняемыми файлами, которым не удастся выполнить свои действия без административных прав.

В приложениях со специальными возможностями атрибуту uiAccess задается значение «true» для управления окном ввода в процессах с повышенными правами. Кроме того, для обеспечения этих возможностей они должны быть подписаны и находиться в одном из нескольких безопасных размещений, включая %SystemRoot% и %ProgramFiles%.

Значения, задаваемые исполняемым файлом, можно легко определить, просмотрев его манифест с помощью служебной программы Sysinternals Sigcheck, например:

sigcheck –m

При запуске образа, который запрашивает административные права, службе сведений о приложении (известна также как AIS, находится в %SystemRoot%System32Appinfo.dll), которая работает в процессе Service Host (%SystemRoot%System32Svchost.exe), предписывается запустить программу Consent.exe (%SystemRoot%System32Consent.exe). Программа Consent создает снимок экрана, применяет к нему эффект затемнения, переключается на рабочий стол, доступный только системной учетной записи, устанавливает затемненный снимок в качестве фона и открывает диалоговое окно повышения прав, содержащее сведения об исполняемом файле. Вывод на отдельном рабочем столе предотвращает изменение этого диалогового окна любой вредоносной программой, работающей под учетной записью пользователя.

Картинка с сайта: corem.ru

Рис. 11 Диалоговые окна OTS-повышения

Если образ является компонентом Windows, подписанным цифровой подписью корпорации Майкрософт, и находится в системном каталоге Windows, то, как показано вверху на рис. 11, в верхней части диалогового окна добавляется синяя полоса. Серая полоса (среднее диалоговое окно) обозначает образы, подписанные цифровой подписью, отличной от подписи корпорации Майкрософт, а оранжевая полоса (нижнее диалоговое окно) предназначена для неподписанных образов. Для образов, подписанных цифровой подписью, в диалоговом окне повышения показывается значок образа, описание и издатель, а для неподписанных образов — только общий значок, имя файла и примечание “Издатель неизвестен”. Это усложняет для вредоносных программ имитацию подлинного программного обеспечения. Кнопка “Сведения” внизу диалогового окна раскрывается, показывая командную строку, которая будет передана исполняемому файлу при его запуске. Диалоговое окно программы Consent для режима AAM, показанное на Figure 12, подобно окну для OTS-повышения, но вместо запроса на ввод учетных данных администратора там имеются кнопки “Далее” и “Отмена”.

Картинка с сайта: corem.ru

Рис. 12 Диалоговое окно AAM-повышения

Если пользователь отклоняет повышение прав, Windows возвращает процессу, инициировавшему запуск, ошибку “Отказано в доступе”. Если пользователь соглашается на повышение, введя учетные данные администратора или нажав кнопку “Далее”, служба AIS вызывает функцию CreateProcessAsUser для запуска процесса с необходимым административным идентификатором. Хотя технически родителем процесса с повышенными правами является служба AIS, она использует новую поддержку со стороны функции CreateProcessAsUser, которая устанавливает запускаемому процессу в качестве кода родительского процесса код процесса, который изначально его запустил (см. рис. 13). Именно поэтому процессы с повышенными правами не изображаются как потомки процесса Service Hosting службы AIS в таких средствах, как обозреватель процессов, которые показывают деревья процессов.

Рис. 13 Поток повышения прав

Даже при том, что диалоговые окна повышения выводятся на отдельном безопасном рабочем столе, по умолчанию пользователи не имеют никакого способа проверить тот факт, что они видят подлинное диалоговое окно, а не окно, открытое вредоносной программой. Для AAM это не проблема, поскольку вредоносная программа со своим фальшивым диалоговым окном Consent не может получить административных прав. Однако эта программа может дождаться ОТС-повышения обычного пользователя, перехватить его и использовать троянское диалоговое окно для захвата учетных данных администратора. С этими учетными данными вредоносная программа может получить доступ к учетной записи администратора и инфицировать ее.

В связи с этим в корпоративных средах ОТС-повышения должны быть строго запрещены. Чтобы отключить ОТС-повышения (и уменьшить количество вызовов службы поддержки), запустите редактор локальных политик безопасности (Secpol.msc) и для параметра “Управление учетными записями пользователей: поведение запроса на повышение прав для обычных пользователей” выберите значение Automaticallydenyelevationrequests.

Пользователи домашних компьютеров, которые сами отвечают за свою безопасность, должны настроить ОТС-повышения таким образом, чтобы для их применения необходимо было ввести специальное сочетание клавиш (SAS), которое вредоносная программа не сможет перехватить или имитировать. Чтобы настроить SAS, нужно запустить редактор групповых политик (Gpedit.msc), перейти к разделу “Конфигурация компьютера” – “Административные шаблоны” – “Компоненты Windows” – “Интерфейс пользователя для учетных данных” и включить параметр “Требовать достоверный путь для входа в учетную запись”. После этого обратиться к диалоговому окну повышения можно будет, нажав сочетание клавиш CTRL+ALT+DELETE.

Изоляция процессов с повышенными правами
 

Windows Vista устанавливает ограждение вокруг процессов с повышенными правами, чтобы защитить их от вредоносной программы, работающей на том же компьютере с правами обычного пользователя. Без такого барьера вредоносная программа может управлять административным приложением, отправляя ему фальшивый синтезированный ввод мышью и оконный ввод через оконные сообщения. Стандартная модель безопасности Windows не даст вредоносной программе, работающей в процессе с правами обычного пользователя, работать от имени другого пользователя в процессе с повышенными правами. Однако она не может запретить вредоносной программе, работающей под версией обычных прав административного пользователя, запуск процессов пользователя с повышенными правами, внедрение в них кода и запуск потоков его выполнения.

Защита Windows Vista против оконных сообщений называется изоляцией привилегий интерфейса пользователя (UIPI). Он основан на новом механизме целостности Windows, который Windows Vista использует также как ограждение вокруг процессов с повышенными правами. В этой новой модели безопасности все процессы и объекты имеют уровни целостности, а политика целостности объекта может ограничить доступ, который иначе был бы предоставлен процессу моделью безопасности Windows “Управление доступом на уровне пользователей” (DAC).

Уровни целостности (IL) представлены идентификаторами безопасности (SID), которые представляют также пользователей и группы, уровень которых закодирован в относительном идентификаторе (RID) идентификатора SID. На рис. 14 показаны отображаемое имя, SID и шестнадцатеричная версия RID идентификатора SID для четырех основных IL.

Рис 14  Основные уровни целостности

Название SID RID

В шестнадцатеричных числах видны промежутки размером 0x1000 между каждым уровнем, что допускает создание промежуточных уровней для использования приложениями со специальными возможностями интерфейса пользователя и будущего развития.

На рис. 15 перечислены политики IL объектов и типы доступа, которые они ограничивают, и их соответствие общим типам доступа, определенным для объекта.

Рис 15  Политики уровней целостности

Политика Результат действия

Например, политика “Нет записи” предотвращает получение процессом с более низким IL любого доступа, представляемого типом GENERIC_WRITE. По умолчанию для большинства объектов, включая файлы и параметры реестра, применяется политика “Нет записи”, которая запрещает процессу доступ для записи к объектам, имеющим более высокий IL, даже если список управления доступом на уровне пользователей (DACL) объекта предоставляет пользователю такой доступ. Другая политика применяется только к объектам-потокам и объектам-процессам. Эта политика, “Нет записи” плюс “Нет чтения”, запрещает процессу с более низким IL встраивать код и считывать данные — например пароли — из процесса, имеющего более высокий IL.

Windows назначает каждому процессу IL, помещая его в маркер вместе с кодами SID групп, к которым относится пользователь, выполняющий процесс. На рис. 16 показаны примеры процессов, которым назначены разные IL.

Рис 16  Примеры назначения процессам уровней целостности

Уровень целостности Примеры процессов

Процессы обычно наследуют IL своего родителя, но процесс может также запустить процесс с другим IL, как это делает служба AIS, когда запускает процесс с повышенными правами. Уровни целостности процесса можно просмотреть с помощью встроенной служебной программы Whoami, указав параметр /all, или с помощью программ Process Explorer или AccessChk (обе от Sysinternals). Обозреватель процессов может отображать коды IL процесса наряду со столбцом “Уровень целостности”.

Каждый защищаемый объект обладает IL, который может быть явным или неявным. Процессы, потоки и маркеры всегда имеют явно назначенный IL, который обычно совпадает с IL, сохраненным в маркере соответствующего процесса. Большинство объектов не имеет явного IL, поэтому к ним по умолчанию применяется средний (Medium) уровень целостности. Уровень IL, отличный от среднего, имеют только объекты, создаваемые процессом, работающим с низким (Low) IL. Такие объекты также имеют низкий IL. Просмотреть IL файлов можно с помощью встроенного средства iCacls (%SystemRoot%System32iCacls.exe), а IL файлов, параметров реестра, служб и процессов — с помощью служебной программы Sysinternals AccessChk. Нарис. 17 показано, что IL каталога, к которому должен иметь доступ обозреватель Internet Explorer в защищенном режиме — Low.

Картинка с сайта: corem.ru

Рис. 17 IL каталога “Избранное” пользователя в окне программы AccessChk

Если у объекта есть явный IL, он хранится в записи управления доступом (ACE) нового типа, представленного в Windows Vista, — Label ACE, в списке управления системным доступом (SACL) дескриптора безопасности объекта (см. рис. 18). SID в ACE соответствует IL объекта, а с помощью флагов ACE кодируется политика целостности объекта. До Windows Vista в SACL хранились только ACE-записи аудита, которые требуют привилегии “Управление аудитом и журналом безопасности” (SeSecurityPrivilege), но для чтения записей типа Label ACE необходим только доступ “Разрешение на чтение” (READ_CONTROL). Чтобы процесс мог изменить IL объекта, он должен иметь доступ “Смена владельца” (WRITE_OWNER) к объекту и IL, равный или более высокий, чем у объекта. При этом процесс может установить IL, только равный его собственному IL или ниже. Новая привилегия “Изменение метки объекта” (SeRelabelPrivilege) дает процессу возможность изменить IL любого объекта, к которому процесс имеет доступ, и даже установить IL выше собственного IL процесса. Однако по умолчанию эта привилегия не назначается никакой учетной записи.

Картинка с сайта: corem.ru

Рис. 18 Запись Label ACE объекта

Когда процесс пытается открыть объект, то перед тем как функция ядра SeAccessCheck выполнит стандартную проверку DACL Windows, происходит проверка целостности. Согласно применяемым по умолчанию политикам целостности, процесс может открыть объект для записи только если выполняются два условия: его IL равен или выше, чем IL объекта, и DACL предоставляет процессу необходимые типы доступа. Например, процесс с низким IL не сможет открыть процесс со средним IL для записи, даже если DACL предоставляет процессу такое право.

Применяемая по умолчанию политика целостности позволяет процессам открыть любой объект — за исключением объектов-процессов и объектов-потоков — для чтения, если DACL объекта предоставляет им такой доступ. Это означает, что процесс, работающий с низким IL, может открыть любые файлы, доступные для учетной записи пользователя, под которой он работает. С помощью IL-уровней обозреватель Internet Explorer защищенного режима предотвращает блокировку изменения параметров учетной записи пользователя вредоносной программой, но не может помешать ей читать документы пользователя.

Объекты-процессы и объекты-потоки — исключения, поскольку их политика целостности содержит также компонент “Нет чтения”. Это означает, что IL процесса должен быть равен или выше, чем IL процесса или потока, который данному процессу необходимо открыть, а DACL должен предоставить ему доступ требуемых типов. На рис. 19 предполагается, что DACL-списки разрешают необходимый доступ. Здесь показаны варианты доступа процессов, работающих со средним и низким IL, к другим процессам и объектам.

Рис. 19 Доступ к объектам и процессам

Подсистема сообщений Windows также использует уровни целостности для реализации UIPI, препятствуя отправлению процессом всех сообщений, кроме нескольких информационных оконных сообщений, в окна, принадлежащие процессу с более высоким IL. Это позволяет предотвратить ввод в окна процессов с повышенными правами процессами обычных пользователей и разрушение процесса с повышенными правами отправкой ему неправильно сформированных сообщений, вызывающих переполнение внутреннего буфера. Процессы могут разрешать прохождение дополнительных сообщений сквозь защиту, вызывая API-функцию ChangeWindowMessageFilter. UIPI-изоляция также блокирует доступ к окнам процессов с более высоким IL с тем, чтобы, например, процесс обычного пользователя не мог захватить нажатия клавиш пользователем в административных приложениях.

Повышения прав и рубежи безопасности
 

Важно понимать, что повышения прав UAC — это дополнительные удобства, а не новые рубежи безопасности. Рубеж безопасности — когда некоторая политика безопасности диктует, что может проходить через некоторую границу, а что не может. Учетные записи пользователей — это пример рубежей безопасности в Windows, поскольку один пользователь не может обратиться к данным, принадлежащим другому пользователю, не имея на то разрешения пользователя-владельца.

Поскольку повышения прав не устанавливают рубежей безопасности, нет никакой гарантии, что вредоносная программа, работающая в системе с правами обычного пользователя, не сможет нарушить безопасность процесса с повышенными правами и получить административные права. Например, в диалоговых окнах повышения только определяется исполняемый файл, права которого будут повышены; в них ничего не говорится о том, что этот файл будет делать при выполнении. Исполняемый файл может обрабатывать аргументы командной строки, загружать DLL-библиотеки, открывать файлы данных и взаимодействовать с другими процессами. Любая из этих операций потенциально может позволить вредоносной программе нарушить безопасность процесса с повышенными правами и, таким образом, получить административные права.

Игра в песочнице с низким IL

Internet Explorer защищенного режима работает с низким IL, чтобы создать барьер против вредоносных программ, которые могут инфицировать его процесс. Это препятствует изменению вредоносной программой параметров учетной записи пользователя и установке ею себя в размещениях автозапуска. Поиграть в этой песочнице, запуская произвольные процессы с низким IL, можно с помощью служебной программы PsExec от Sysinternals с ключом -l. На рис. Б показано, что командная строка с низким IL не может создать файл во временном каталоге пользователя, которому присвоен средний IL, но может это сделать во временном каталоге обозревателя Internet Explorer, который имеет низкий IL.

Картинка с сайта: corem.ru

Рис. Б Командная строка может создавать файлы только в размещении с таким же IL

Процессы ААМ с повышенными правами особенно восприимчивы к нарушениям безопасности, поскольку они работают под той же учетной записью пользователя, что и ААМ-процессы пользователя со стандартными правами, и совместно используют профиль пользователя. Многие приложения считывают параметры и загружают расширения, зарегистрированные в профиле пользователя, создавая возможности для повышения прав вредоносной программы. Например, при работе в общих управляющих диалоговых окнах загружаются расширения оболочки, настроенные в разделе пользователя в реестре (в ветви HKEY_CURRENT_USER). Вредоносная программа может добавить себя в качестве расширения и затем загрузиться в любой процесс с повышенными правами, который использует эти диалоговые окна.

Очевидно, из-за их общедоступного состояния под угрозу могут быть поставлены даже процессы, повышенные от учетных записей обычного пользователя. Все процессы, работающие в сеансе входа в систему, совместно используют внутреннее пространство имен, в котором Windows хранит такие объекты, как события, мьютексы, семафоры и общую память. Если вредоносная программа знает, что процесс с повышенными правами при запуске будет пытаться открыть и прочитать определенный объект общей памяти, она может создать объект, содержимое которого вызовет переполнение буфера, и затем ввести код в процесс с повышенными правами. Этот тип атаки относительно сложен, но в случае его реализации OTS-повышения перестают быть рубежом безопасности.

Практический результат введения повышений — удобство для пользователей, которые, по умолчанию работая с правами обычного пользователя, получают доступ к административным правам. Пользователям, которые хотят иметь гарантии безопасности, придется несколько поступиться этим удобством. Выполняя ежедневные задачи как обычные пользователи, с помощью функции быстрого переключения пользователей (FUS) они могут переходить на выделенную учетную запись администратора для выполнения административных операций. С другой стороны, пользователи, склонные пожертвовать безопасностью в пользу удобства, могут отключить UAC в системе в диалоговом окне “Учетные записи пользователя” панели управления. Но следует помнить, что при этом также отключается защищенный режим для Internet Explorer.

Заключение
 

Работа в качестве обычного пользователя обеспечивает многочисленные преимущества, включая защиту системы от случайного или преднамеренного повреждения и защиту от несанкционированного доступа данных и целостности пользователей, совместно использующих систему. Результатом различных изменений и применения технологий UAC будут радикальные перемены в модели использования Windows. С приходом Windows Vista пользователи Windows впервые могут выполнять большинство ежедневных задач и запускать большинство программ, используя права обычного пользователя, а многие корпорации теперь смогут шире развертывать учетные записи обычных пользователей.