Рішення проблем облікових записів | Windows IT Pro / RE | Видавництво «Відкриті системи»
- Рішення проблем облікових записів Нещодавно в готелі мені знадобилося вивести на друк електронний...
- Мережеві принтери
- Небажані запити UAC на підвищення прав
- UAC як периметр безпеки
- Безпека - не утопія
- Рішення проблем облікових записів
- установка пристроїв
- Мережеві принтери
- Небажані запити UAC на підвищення прав
- UAC як периметр безпеки
- Безпека - не утопія
- Рішення проблем облікових записів
- установка пристроїв
- Мережеві принтери
- Небажані запити UAC на підвищення прав
- UAC як периметр безпеки
- Безпека - не утопія
Рішення проблем облікових записів
Нещодавно в готелі мені знадобилося вивести на друк електронний авіаквиток з Internet Explorer (IE) з ноутбука Windows 7. Власник готелю запропонував мені свій принтер і диск з драйвером, від якого я відмовився, знаючи, що мій ноутбук, підключений до Інтернету, сам знайде потрібний драйвер у службі Windows Update, що він і зробив за лічені секунди. Весь процес, включаючи друк, пройшов без проблем. Що найважливіше, для виконання установки мені не треба було підвищувати повноваження стандартного користувача до прав адміністратора.
установка пристроїв
Параметр реєстру DevicePath в Windows існує давно; він дозволяє адміністратору вказувати надійні джерела, в яких, крім папки% SystemRoot% \ inf за замовчуванням, система шукає потрібний драйвер при підключенні нового пристрою. Починаючи з Windows 7 стандартні користувачі можуть додавати підписані драйвери в локальне сховище драйверів з джерел, зазначених в значенні параметра реєстру DevicePath, або з центру оновлення Windows.
Якщо пакети драйверів зберігаються в мережі, то можна включити в значення параметра реєстру DevicePath відповідний мережевий шлях, щоб система Windows, крім зберігаються в пам'яті комп'ютера драйверів, переглядала і мережеве сховище: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows CurrentVersion \ DevicePath. Включаються шляху повинні відділятися один від одного крапкою з комою:% SystemRoot% \ Inf; \\ servername \ drivers.
У Windows 7 зберігається вимога, згідно з яким драйвери повинні бути підписані чинним сертифікатом, який є довірчим для даного локального комп'ютера. Крім того, 64-розрядні версії Windows передбачають спеціальні вимоги до драйверів режиму ядра, які повинні бути підписані сертифікатом видавця програмного забезпечення з складеного Microsoft списку затверджених засвідчувальних центрів (CA). Ознайомитися зі списком можна за посиланням www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx . Хоча в Windows 7 більшість існуючих пристроїв можуть бути встановлені без адміністративних прав, набір драйверів Windows включає кошти, необхідні для підписання драйверів пристроїв ( www.microsoft.com/whdc/devtools/wdk/wdkpkg.mspx ).
У Windows 7 і Vista існує програма pnputil.exe, яку можна використовувати для реєстрації драйверів в локальному сховищі. Будучи поміщеним в локальне сховище, драйвер вважається довірчим і встановлюється при підключенні користувачем відповідного пристрою. Реєстрація драйверів за допомогою pnputil.exe може бути необов'язковою, але забезпечує безвідмовність взаємодії системи з користувачем при підключенні раніше віддаленого пристрою. Драйвери, вже додані в локальне сховище, можуть бути пронумеровані з використанням pnputil.exe і з зазначенням ключа -e.
Параметри групової політики в Windows 7 і Vista дозволяють вказувати пристрої, які можуть бути встановлені звичайним користувачем, за ідентифікатором GUID. У Windows Server 2008 і пізніших версіях в Computer Configuration \ Policies \ Administrative Templates \ System \ Driver Installation є параметр групової політики «Дозволити користувачам, які не є адміністраторами, встановлювати драйвери для цих класів установки пристроїв». Для стандартних користувачів можливі наступні сценарії установки драйверів пристроїв:
- в Windows вже включений драйвер, що підтримує пристрій, що підключається;
- драйвер пристрою зареєстрований адміністратором в локальному сховищі драйверів за допомогою pnputil.exe або dism.exe;
- драйвер, підписаний з використанням чинного сертифіката і є довірчим для даного локального комп'ютера, є в центрі оновлення Windows або в джерелі, зазначеному в значенні DevicePath системного реєстру (тільки Windows 7);
- є драйвер, підписаний з використанням чинного сертифіката і є довірчим для даного локального комп'ютера, а ідентифікатор GUID відповідного пристрою може бути перелічений параметра політики «Дозволити користувачам, які не є адміністраторами, встановлювати драйвери для цих класів установки пристроїв» (Vista і наступні версії).
Мережеві принтери
Само по собі розгортання і управління принтерами - не дуже важка робота, але введення облікових записів звичайних користувачів на робочих станціях може виявитися складним завданням. Можливість для звичайного користувача встановлювати драйвери для мережевих принтерів породжує проблеми. Одна з переваг використання серверів друку Windows в мережі полягає в тому, що в більшості випадків для установки мережевих принтерів під керуванням Windows Server користувачам не потрібно адміністративних прав. Якщо драйвер принтера, встановлений на сервері друку, є власним драйвером Windows (тобто включений в установку Windows за замовчуванням) або входить в пакет підписаних драйверів принтера, то для його установки права адміністратора не потрібні. Крім того, може бути використана групова політика для розгортання принтерів через консоль управління печаткою без необхідності адміністративних повноважень.
Однак багато організацій бажають уникнути витрат, пов'язаних з використанням сервера друку Windows, тому існують обхідні шляхи забезпечення можливості установки мережевих принтерів стандартними користувачами. Основна проблема при обслуговуванні мережевих принтерів, які не керованих сервером друку Windows, - необхідність налаштування локального порту TCP / IP на кожному клієнті для їх розгортання, що вимагає наявності прав адміністратора.
Для розгортання принтерів TCP / IP для стандартних користувачів можна застосовувати переваги групової політики, проте в цьому випадку при первісному розгортанні потрібна установка принтера на сервері друку Windows для розподілу драйвера. Після установки принтера на всіх потрібних пристроях сервер друку Windows можна вимкнути і направляти завдання друку безпосередньо на пристрій. На практиці використання переваг групової політики для розгортання принтерів TCP / IP для звичайних користувачів має ряд недоліків.
- Необхідність розгортання клієнтських розширень переваг групової політики на комп'ютерах під управлінням інших операційних систем (н Windows 7).
- Якщо використовуються переваги конфігурації комп'ютера для розгортання принтерів TCP / IP - необхідність виключення параметра «Обмеження вказівки і друку» групової політики в Computer Configuration \ Administrative Templates \ Printers, щоб відключити видачу попереджень або запитів на підвищення прав під час установки.
- Уподобання групової політики підтримують розгортання принтерів, тільки якщо обраний процесор друку WinPrint при установці для розгортання на сервері друку Windows. При іншому варіанті вибору даний процесор друку повинен бути вже встановлено на пристроях, де буде розгортатися принтер. WinPrint може не підтримувати розширені функції принтера.
Небажані запити UAC на підвищення прав
Деякі додатки без достатніх підстав вимагають наявності прав адміністратора при запуску. Користувач, який увійшов в систему під стандартним обліковим записом, при запуску такого додатка отримує запит UAC на введення пароля облікового запису адміністратора. Якщо не ввести пароль і відповісти «Ні» на запитання «Дозволити наступній програмі внести зміни на цьому комп'ютері?», Програма не запускається.
На перший погляд може здатися, що є тільки два рішення: запустити додаток з правами адміністратора або вимкнути UAC, причому обидва варіанти небажані. Кожен виконуваний файл в системі може супроводжуватися маніфестом додатки, які представляють собою файл. xml з параметрами, що визначають характер взаємодії додатка з UAC. Зазвичай маніфест додатка впроваджений в виконуваний файл, але іноді він може бути самостійним файлом в каталозі додатки.
Для вирішення проблеми до складу інфраструктури сумісність програми включена оболонка сумісності RunAsInvoker, що дозволяє запускати додаток без повноважень, пов'язаних з процесом створення, і без необхідності підвищення прав. По можливості, проте, переважно змінювати маніфест виконуваного файлу.
Компанія Heaven Tools пропонує програму Resource Tuner ( www.heaventools.com/resource-tuner.htm ), Що дозволяє адміністратору змінювати маніфести додатків, впроваджені в попередньо скомпільовані виконувані файли. Запуск цієї програми і зміна коду. xml надзвичайно прості. Все, що потрібно, - знайти папку Manifest в браузері ресурсів і змінити значення requestedExecutionLevel з requireAdministrator на asInvoker, а потім зберегти зміни в виконуваному файлі. Нижче наведено приклад для тега «security» в файлі маніфесту програми:
При роботі з Visual Studio (VS) можна задіяти файл mt.exe для додавання або зміни маніфесту програми. Це частина пакета засобів розробки Windows SDK.
Якщо зміна маніфесту додатки неможливо, завантажте набір засобів для забезпечення сумісності додатків - Application Compatibility Toolkit (ACT) 5.5, доступний для безкоштовного завантаження з сайту Microsoft, і використовуйте Compatibility Administrator для створення виправлення сумісності за допомогою оболонки RunAsInvoker, а потім розгорніть отриману в результаті базу даних на робочих станціях. Для цього потрібно зробити наступне.
- Увійдіть в систему Windows 7 як адміністратор і встановіть ACT.
- У меню «Пуск» відкрийте папку Application Compatibility Toolkit 5.5 і під заголовком Custom Databases на лівій панелі виберіть New Database і натисніть Ctrl + R.
- Введіть ім'я нової бази даних і натисніть «Введення».
- Натисніть Ctrl + P для створення нового виправлення програми. У діалоговому вікні Create New Application Fix введіть ім'я виправляється програми.
- Натисніть кнопку Browse, знайдіть виконуваний файл, який ви бажаєте виправлення, і натисніть Open. Для продовження клацніть Next.
- На вкладці Compatibility Modes в Operating Systems виберіть None і натисніть Next. На екрані Compatibility Fixes перейдіть меню і виберіть виправлення RunAsInvoker (екран 1).
- На даному етапі можна вибрати пробний запуск Test Run, щоб переконатися в реалізації бажаного ефекту створеного виправлення на додаток. Для продовження натисніть Next.
- В екрані Matching Information можна виконати точне налаштування, регулюючу процес визначення виконуваного файлу оброблювачем сумісності. Ми залишаємо установки за замовчуванням і натискаємо кнопку Finish.
- Клацанням на значку Save у верхній частині вікна адміністратора сумісності (екран 2) зберігаємо базу даних на диск C локального комп'ютера.
- В меню File вибираємо Install і натисканням на OK підтверджуємо установку бази даних. Після цього стає можливим запуск цільового програми без підвищення прав.
Після ґрунтовного тестування виправлення сумісності можна здійснити його поширення. Для цього скористайтеся груповою політикою і пакетним файлом з командою sdbinst.exe.
UAC як периметр безпеки
За заявою Microsoft, UAC - це функція безпеки, а не периметр безпеки. Хоча реєстрація в системі під захищеної обліковим записом адміністратора не забезпечує периметр безпеки, обліковий запис стандартного користувача з включеною службою UAC передбачає певний захист. Конфігурація UAC за замовчуванням передбачає включення так званого підвищення прав всередині сеансу користувача, за типом over-the-shoulder (OTS). Якщо запуск UAC ініційований монтажником додатки або якщо маніфест додатка вимагає запуску виконуваного файлу з правами адміністратора, система видає запит на введення пароля адміністратора для продовження. Цей процес передбачає перехід в безпечний робочий стіл (ізольований від робочого столу користувача сеанс) для виключення втручання шкідливих програм. Захист представляється надійної, чи не так?
Проблема OTS-підвищення прав полягає в тому, що шкідливі програми самі можуть ініціювати безпечний робочий стіл і вкрасти пароль адміністратора, що вводиться нічого не підозрюють користувачем. Тому Microsoft рекомендує вимикати підвищення прав за типом OTS для облікових записів стандартних користувачів в груповій політиці для зниження уразливості в корпоративних середовищах.
Відключення підвищення прав типу OTS означає також відключення можливості клацанням правої кнопки на виконуваному файлі відкривати меню і вибирати пункт «Запуск від імені адміністратора». Технічному персоналу це може здатися недоліком, однак залишається можливість, утримуючи Shift, натиснути правою кнопкою, відкрити меню і вибрати пункт «Запуск від імені іншого користувача».
Альтернатива відключення підвищення прав OTS - включення спеціального поєднання клавіш Secure Attention Sequence (SAS) в настройках групової політики. При цьому перехід в безпечний робочий стіл відбувається не автоматично, а шляхом введення комбінації Ctrl + Alt + Del. Оскільки емуляція спеціального поєднання клавіш виключається, а можливий лише фізичний введення зазначеної комбінації, користувач може бути впевнений, що безпечний робочий стіл - справжній. Включення SAS можна виконати з використанням параметра групової політики «Вимагати достовірний шлях для реєстрації облікового запису» в Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Credential User Interface. Слід, однак, мати на увазі, що SAS представляє незручність, якщо підвищення прав потрібно регулярно.
Безпека - не утопія
Windows 7, як ніколи, полегшує роботу користувача. Однак збільшення числа користувачів, що входять в систему без прав адміністратора, підвищує ймовірність розвитку шкідливих програм, які обирають мішенню такі сеанси. Різні технології, такі як політики обмеженого використання програм Software Restriction Policies, реалізовані в Vista і більш ранніх версіях, і компонент AppLocker, наявний в Windows Server 2008 R2 і в деяких випусках Windows 7, можуть застосовуватися для складання білих списків додатків, що буде мати важливе значення для запобігання впливу шкідливих програм такого типу.
Рассел Сміт ( [email protected] ) - незалежний ІТ-консультант, спеціалізується на управлінні системами
Рішення проблем облікових записів
Нещодавно в готелі мені знадобилося вивести на друк електронний авіаквиток з Internet Explorer (IE) з ноутбука Windows 7. Власник готелю запропонував мені свій принтер і диск з драйвером, від якого я відмовився, знаючи, що мій ноутбук, підключений до Інтернету, сам знайде потрібний драйвер у службі Windows Update, що він і зробив за лічені секунди. Весь процес, включаючи друк, пройшов без проблем. Що найважливіше, для виконання установки мені не треба було підвищувати повноваження стандартного користувача до прав адміністратора.
Перше, що роблять багато системних адміністраторів при підготовці до роботи нового комп'ютера, особливо ноутбука, - це переміщення облікових записів користувачів домену в локальну групу адміністраторів і, що ще гірше, виключення контролю облікових записів користувачів (UAC) в Windows Vista і новіших версіях. Це часто робиться у випадках, аналогічних описаним вище, коли користувачеві необхідно встановити драйвер пристрою або виконати інше завдання адміністративного рівня. Однак зміни в реалізації UAC і моделі безпеки в Windows 7 надають звичайному користувачеві можливість обходитися без прав адміністратора.
установка пристроїв
Параметр реєстру DevicePath в Windows існує давно; він дозволяє адміністратору вказувати надійні джерела, в яких, крім папки% SystemRoot% \ inf за замовчуванням, система шукає потрібний драйвер при підключенні нового пристрою. Починаючи з Windows 7 стандартні користувачі можуть додавати підписані драйвери в локальне сховище драйверів з джерел, зазначених в значенні параметра реєстру DevicePath, або з центру оновлення Windows.
Якщо пакети драйверів зберігаються в мережі, то можна включити в значення параметра реєстру DevicePath відповідний мережевий шлях, щоб система Windows, крім зберігаються в пам'яті комп'ютера драйверів, переглядала і мережеве сховище: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows CurrentVersion \ DevicePath. Включаються шляху повинні відділятися один від одного крапкою з комою:% SystemRoot% \ Inf; \\ servername \ drivers.
У Windows 7 зберігається вимога, згідно з яким драйвери повинні бути підписані чинним сертифікатом, який є довірчим для даного локального комп'ютера. Крім того, 64-розрядні версії Windows передбачають спеціальні вимоги до драйверів режиму ядра, які повинні бути підписані сертифікатом видавця програмного забезпечення з складеного Microsoft списку затверджених засвідчувальних центрів (CA). Ознайомитися зі списком можна за посиланням www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx . Хоча в Windows 7 більшість існуючих пристроїв можуть бути встановлені без адміністративних прав, набір драйверів Windows включає кошти, необхідні для підписання драйверів пристроїв ( www.microsoft.com/whdc/devtools/wdk/wdkpkg.mspx ).
У Windows 7 і Vista існує програма pnputil.exe, яку можна використовувати для реєстрації драйверів в локальному сховищі. Будучи поміщеним в локальне сховище, драйвер вважається довірчим і встановлюється при підключенні користувачем відповідного пристрою. Реєстрація драйверів за допомогою pnputil.exe може бути необов'язковою, але забезпечує безвідмовність взаємодії системи з користувачем при підключенні раніше віддаленого пристрою. Драйвери, вже додані в локальне сховище, можуть бути пронумеровані з використанням pnputil.exe і з зазначенням ключа -e.
Параметри групової політики в Windows 7 і Vista дозволяють вказувати пристрої, які можуть бути встановлені звичайним користувачем, за ідентифікатором GUID. У Windows Server 2008 і пізніших версіях в Computer Configuration \ Policies \ Administrative Templates \ System \ Driver Installation є параметр групової політики «Дозволити користувачам, які не є адміністраторами, встановлювати драйвери для цих класів установки пристроїв». Для стандартних користувачів можливі наступні сценарії установки драйверів пристроїв:
- в Windows вже включений драйвер, що підтримує пристрій, що підключається;
- драйвер пристрою зареєстрований адміністратором в локальному сховищі драйверів за допомогою pnputil.exe або dism.exe;
- драйвер, підписаний з використанням чинного сертифіката і є довірчим для даного локального комп'ютера, є в центрі оновлення Windows або в джерелі, зазначеному в значенні DevicePath системного реєстру (тільки Windows 7);
- є драйвер, підписаний з використанням чинного сертифіката і є довірчим для даного локального комп'ютера, а ідентифікатор GUID відповідного пристрою може бути перелічений параметра політики «Дозволити користувачам, які не є адміністраторами, встановлювати драйвери для цих класів установки пристроїв» (Vista і наступні версії).
Мережеві принтери
Само по собі розгортання і управління принтерами - не дуже важка робота, але введення облікових записів звичайних користувачів на робочих станціях може виявитися складним завданням. Можливість для звичайного користувача встановлювати драйвери для мережевих принтерів породжує проблеми. Одна з переваг використання серверів друку Windows в мережі полягає в тому, що в більшості випадків для установки мережевих принтерів під керуванням Windows Server користувачам не потрібно адміністративних прав. Якщо драйвер принтера, встановлений на сервері друку, є власним драйвером Windows (тобто включений в установку Windows за замовчуванням) або входить в пакет підписаних драйверів принтера, то для його установки права адміністратора не потрібні. Крім того, може бути використана групова політика для розгортання принтерів через консоль управління печаткою без необхідності адміністративних повноважень.
Однак багато організацій бажають уникнути витрат, пов'язаних з використанням сервера друку Windows, тому існують обхідні шляхи забезпечення можливості установки мережевих принтерів стандартними користувачами. Основна проблема при обслуговуванні мережевих принтерів, які не керованих сервером друку Windows, - необхідність налаштування локального порту TCP / IP на кожному клієнті для їх розгортання, що вимагає наявності прав адміністратора.
Для розгортання принтерів TCP / IP для стандартних користувачів можна застосовувати переваги групової політики, проте в цьому випадку при первісному розгортанні потрібна установка принтера на сервері друку Windows для розподілу драйвера. Після установки принтера на всіх потрібних пристроях сервер друку Windows можна вимкнути і направляти завдання друку безпосередньо на пристрій. На практиці використання переваг групової політики для розгортання принтерів TCP / IP для звичайних користувачів має ряд недоліків.
- Необхідність розгортання клієнтських розширень переваг групової політики на комп'ютерах під управлінням інших операційних систем (н Windows 7).
- Якщо використовуються переваги конфігурації комп'ютера для розгортання принтерів TCP / IP - необхідність виключення параметра «Обмеження вказівки і друку» групової політики в Computer Configuration \ Administrative Templates \ Printers, щоб відключити видачу попереджень або запитів на підвищення прав під час установки.
- Уподобання групової політики підтримують розгортання принтерів, тільки якщо обраний процесор друку WinPrint при установці для розгортання на сервері друку Windows. При іншому варіанті вибору даний процесор друку повинен бути вже встановлено на пристроях, де буде розгортатися принтер. WinPrint може не підтримувати розширені функції принтера.
Небажані запити UAC на підвищення прав
Деякі додатки без достатніх підстав вимагають наявності прав адміністратора при запуску. Користувач, який увійшов в систему під стандартним обліковим записом, при запуску такого додатка отримує запит UAC на введення пароля облікового запису адміністратора. Якщо не ввести пароль і відповісти «Ні» на запитання «Дозволити наступній програмі внести зміни на цьому комп'ютері?», Програма не запускається.
На перший погляд може здатися, що є тільки два рішення: запустити додаток з правами адміністратора або вимкнути UAC, причому обидва варіанти небажані. Кожен виконуваний файл в системі може супроводжуватися маніфестом додатки, які представляють собою файл. xml з параметрами, що визначають характер взаємодії додатка з UAC. Зазвичай маніфест додатка впроваджений в виконуваний файл, але іноді він може бути самостійним файлом в каталозі додатки.
Для вирішення проблеми до складу інфраструктури сумісність програми включена оболонка сумісності RunAsInvoker, що дозволяє запускати додаток без повноважень, пов'язаних з процесом створення, і без необхідності підвищення прав. По можливості, проте, переважно змінювати маніфест виконуваного файлу.
Компанія Heaven Tools пропонує програму Resource Tuner ( www.heaventools.com/resource-tuner.htm ), Що дозволяє адміністратору змінювати маніфести додатків, впроваджені в попередньо скомпільовані виконувані файли. Запуск цієї програми і зміна коду. xml надзвичайно прості. Все, що потрібно, - знайти папку Manifest в браузері ресурсів і змінити значення requestedExecutionLevel з requireAdministrator на asInvoker, а потім зберегти зміни в виконуваному файлі. Нижче наведено приклад для тега «security» в файлі маніфесту програми:
При роботі з Visual Studio (VS) можна задіяти файл mt.exe для додавання або зміни маніфесту програми. Це частина пакета засобів розробки Windows SDK.
Якщо зміна маніфесту додатки неможливо, завантажте набір засобів для забезпечення сумісності додатків - Application Compatibility Toolkit (ACT) 5.5, доступний для безкоштовного завантаження з сайту Microsoft, і використовуйте Compatibility Administrator для створення виправлення сумісності за допомогою оболонки RunAsInvoker, а потім розгорніть отриману в результаті базу даних на робочих станціях. Для цього потрібно зробити наступне.
- Увійдіть в систему Windows 7 як адміністратор і встановіть ACT.
- У меню «Пуск» відкрийте папку Application Compatibility Toolkit 5.5 і під заголовком Custom Databases на лівій панелі виберіть New Database і натисніть Ctrl + R.
- Введіть ім'я нової бази даних і натисніть «Введення».
- Натисніть Ctrl + P для створення нового виправлення програми. У діалоговому вікні Create New Application Fix введіть ім'я виправляється програми.
- Натисніть кнопку Browse, знайдіть виконуваний файл, який ви бажаєте виправлення, і натисніть Open. Для продовження клацніть Next.
- На вкладці Compatibility Modes в Operating Systems виберіть None і натисніть Next. На екрані Compatibility Fixes перейдіть меню і виберіть виправлення RunAsInvoker (екран 1).
- На даному етапі можна вибрати пробний запуск Test Run, щоб переконатися в реалізації бажаного ефекту створеного виправлення на додаток. Для продовження натисніть Next.
- В екрані Matching Information можна виконати точне налаштування, регулюючу процес визначення виконуваного файлу оброблювачем сумісності. Ми залишаємо установки за замовчуванням і натискаємо кнопку Finish.
- Клацанням на значку Save у верхній частині вікна адміністратора сумісності (екран 2) зберігаємо базу даних на диск C локального комп'ютера.
- В меню File вибираємо Install і натисканням на OK підтверджуємо установку бази даних. Після цього стає можливим запуск цільового програми без підвищення прав.
Після ґрунтовного тестування виправлення сумісності можна здійснити його поширення. Для цього скористайтеся груповою політикою і пакетним файлом з командою sdbinst.exe.
UAC як периметр безпеки
За заявою Microsoft, UAC - це функція безпеки, а не периметр безпеки. Хоча реєстрація в системі під захищеної обліковим записом адміністратора не забезпечує периметр безпеки, обліковий запис стандартного користувача з включеною службою UAC передбачає певний захист. Конфігурація UAC за замовчуванням передбачає включення так званого підвищення прав всередині сеансу користувача, за типом over-the-shoulder (OTS). Якщо запуск UAC ініційований монтажником додатки або якщо маніфест додатка вимагає запуску виконуваного файлу з правами адміністратора, система видає запит на введення пароля адміністратора для продовження. Цей процес передбачає перехід в безпечний робочий стіл (ізольований від робочого столу користувача сеанс) для виключення втручання шкідливих програм. Захист представляється надійної, чи не так?
Проблема OTS-підвищення прав полягає в тому, що шкідливі програми самі можуть ініціювати безпечний робочий стіл і вкрасти пароль адміністратора, що вводиться нічого не підозрюють користувачем. Тому Microsoft рекомендує вимикати підвищення прав за типом OTS для облікових записів стандартних користувачів в груповій політиці для зниження уразливості в корпоративних середовищах.
Відключення підвищення прав типу OTS означає також відключення можливості клацанням правої кнопки на виконуваному файлі відкривати меню і вибирати пункт «Запуск від імені адміністратора». Технічному персоналу це може здатися недоліком, однак залишається можливість, утримуючи Shift, натиснути правою кнопкою, відкрити меню і вибрати пункт «Запуск від імені іншого користувача».
Альтернатива відключення підвищення прав OTS - включення спеціального поєднання клавіш Secure Attention Sequence (SAS) в настройках групової політики. При цьому перехід в безпечний робочий стіл відбувається не автоматично, а шляхом введення комбінації Ctrl + Alt + Del. Оскільки емуляція спеціального поєднання клавіш виключається, а можливий лише фізичний введення зазначеної комбінації, користувач може бути впевнений, що безпечний робочий стіл - справжній. Включення SAS можна виконати з використанням параметра групової політики «Вимагати достовірний шлях для реєстрації облікового запису» в Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Credential User Interface. Слід, однак, мати на увазі, що SAS представляє незручність, якщо підвищення прав потрібно регулярно.
Безпека - не утопія
Windows 7, як ніколи, полегшує роботу користувача. Однак збільшення числа користувачів, що входять в систему без прав адміністратора, підвищує ймовірність розвитку шкідливих програм, які обирають мішенню такі сеанси. Різні технології, такі як політики обмеженого використання програм Software Restriction Policies, реалізовані в Vista і більш ранніх версіях, і компонент AppLocker, наявний в Windows Server 2008 R2 і в деяких випусках Windows 7, можуть застосовуватися для складання білих списків додатків, що буде мати важливе значення для запобігання впливу шкідливих програм такого типу.
Рассел Сміт ( [email protected] ) - незалежний ІТ-консультант, спеціалізується на управлінні системами
Рішення проблем облікових записів
Нещодавно в готелі мені знадобилося вивести на друк електронний авіаквиток з Internet Explorer (IE) з ноутбука Windows 7. Власник готелю запропонував мені свій принтер і диск з драйвером, від якого я відмовився, знаючи, що мій ноутбук, підключений до Інтернету, сам знайде потрібний драйвер у службі Windows Update, що він і зробив за лічені секунди. Весь процес, включаючи друк, пройшов без проблем. Що найважливіше, для виконання установки мені не треба було підвищувати повноваження стандартного користувача до прав адміністратора.
Перше, що роблять багато системних адміністраторів при підготовці до роботи нового комп'ютера, особливо ноутбука, - це переміщення облікових записів користувачів домену в локальну групу адміністраторів і, що ще гірше, виключення контролю облікових записів користувачів (UAC) в Windows Vista і новіших версіях. Це часто робиться у випадках, аналогічних описаним вище, коли користувачеві необхідно встановити драйвер пристрою або виконати інше завдання адміністративного рівня. Однак зміни в реалізації UAC і моделі безпеки в Windows 7 надають звичайному користувачеві можливість обходитися без прав адміністратора.
установка пристроїв
Параметр реєстру DevicePath в Windows існує давно; він дозволяє адміністратору вказувати надійні джерела, в яких, крім папки% SystemRoot% \ inf за замовчуванням, система шукає потрібний драйвер при підключенні нового пристрою. Починаючи з Windows 7 стандартні користувачі можуть додавати підписані драйвери в локальне сховище драйверів з джерел, зазначених в значенні параметра реєстру DevicePath, або з центру оновлення Windows.
Якщо пакети драйверів зберігаються в мережі, то можна включити в значення параметра реєстру DevicePath відповідний мережевий шлях, щоб система Windows, крім зберігаються в пам'яті комп'ютера драйверів, переглядала і мережеве сховище: HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows CurrentVersion \ DevicePath. Включаються шляху повинні відділятися один від одного крапкою з комою:% SystemRoot% \ Inf; \\ servername \ drivers.
У Windows 7 зберігається вимога, згідно з яким драйвери повинні бути підписані чинним сертифікатом, який є довірчим для даного локального комп'ютера. Крім того, 64-розрядні версії Windows передбачають спеціальні вимоги до драйверів режиму ядра, які повинні бути підписані сертифікатом видавця програмного забезпечення з складеного Microsoft списку затверджених засвідчувальних центрів (CA). Ознайомитися зі списком можна за посиланням www.microsoft.com/whdc/winlogo/drvsign/crosscert.mspx . Хоча в Windows 7 більшість існуючих пристроїв можуть бути встановлені без адміністративних прав, набір драйверів Windows включає кошти, необхідні для підписання драйверів пристроїв ( www.microsoft.com/whdc/devtools/wdk/wdkpkg.mspx ).
У Windows 7 і Vista існує програма pnputil.exe, яку можна використовувати для реєстрації драйверів в локальному сховищі. Будучи поміщеним в локальне сховище, драйвер вважається довірчим і встановлюється при підключенні користувачем відповідного пристрою. Реєстрація драйверів за допомогою pnputil.exe може бути необов'язковою, але забезпечує безвідмовність взаємодії системи з користувачем при підключенні раніше віддаленого пристрою. Драйвери, вже додані в локальне сховище, можуть бути пронумеровані з використанням pnputil.exe і з зазначенням ключа -e.
Параметри групової політики в Windows 7 і Vista дозволяють вказувати пристрої, які можуть бути встановлені звичайним користувачем, за ідентифікатором GUID. У Windows Server 2008 і пізніших версіях в Computer Configuration \ Policies \ Administrative Templates \ System \ Driver Installation є параметр групової політики «Дозволити користувачам, які не є адміністраторами, встановлювати драйвери для цих класів установки пристроїв». Для стандартних користувачів можливі наступні сценарії установки драйверів пристроїв:
- в Windows вже включений драйвер, що підтримує пристрій, що підключається;
- драйвер пристрою зареєстрований адміністратором в локальному сховищі драйверів за допомогою pnputil.exe або dism.exe;
- драйвер, підписаний з використанням чинного сертифіката і є довірчим для даного локального комп'ютера, є в центрі оновлення Windows або в джерелі, зазначеному в значенні DevicePath системного реєстру (тільки Windows 7);
- є драйвер, підписаний з використанням чинного сертифіката і є довірчим для даного локального комп'ютера, а ідентифікатор GUID відповідного пристрою може бути перелічений параметра політики «Дозволити користувачам, які не є адміністраторами, встановлювати драйвери для цих класів установки пристроїв» (Vista і наступні версії).
Мережеві принтери
Само по собі розгортання і управління принтерами - не дуже важка робота, але введення облікових записів звичайних користувачів на робочих станціях може виявитися складним завданням. Можливість для звичайного користувача встановлювати драйвери для мережевих принтерів породжує проблеми. Одна з переваг використання серверів друку Windows в мережі полягає в тому, що в більшості випадків для установки мережевих принтерів під керуванням Windows Server користувачам не потрібно адміністративних прав. Якщо драйвер принтера, встановлений на сервері друку, є власним драйвером Windows (тобто включений в установку Windows за замовчуванням) або входить в пакет підписаних драйверів принтера, то для його установки права адміністратора не потрібні. Крім того, може бути використана групова політика для розгортання принтерів через консоль управління печаткою без необхідності адміністративних повноважень.
Однак багато організацій бажають уникнути витрат, пов'язаних з використанням сервера друку Windows, тому існують обхідні шляхи забезпечення можливості установки мережевих принтерів стандартними користувачами. Основна проблема при обслуговуванні мережевих принтерів, які не керованих сервером друку Windows, - необхідність налаштування локального порту TCP / IP на кожному клієнті для їх розгортання, що вимагає наявності прав адміністратора.
Для розгортання принтерів TCP / IP для стандартних користувачів можна застосовувати переваги групової політики, проте в цьому випадку при первісному розгортанні потрібна установка принтера на сервері друку Windows для розподілу драйвера. Після установки принтера на всіх потрібних пристроях сервер друку Windows можна вимкнути і направляти завдання друку безпосередньо на пристрій. На практиці використання переваг групової політики для розгортання принтерів TCP / IP для звичайних користувачів має ряд недоліків.
- Необхідність розгортання клієнтських розширень переваг групової політики на комп'ютерах під управлінням інших операційних систем (н Windows 7).
- Якщо використовуються переваги конфігурації комп'ютера для розгортання принтерів TCP / IP - необхідність виключення параметра «Обмеження вказівки і друку» групової політики в Computer Configuration \ Administrative Templates \ Printers, щоб відключити видачу попереджень або запитів на підвищення прав під час установки.
- Уподобання групової політики підтримують розгортання принтерів, тільки якщо обраний процесор друку WinPrint при установці для розгортання на сервері друку Windows. При іншому варіанті вибору даний процесор друку повинен бути вже встановлено на пристроях, де буде розгортатися принтер. WinPrint може не підтримувати розширені функції принтера.
Небажані запити UAC на підвищення прав
Деякі додатки без достатніх підстав вимагають наявності прав адміністратора при запуску. Користувач, який увійшов в систему під стандартним обліковим записом, при запуску такого додатка отримує запит UAC на введення пароля облікового запису адміністратора. Якщо не ввести пароль і відповісти «Ні» на запитання «Дозволити наступній програмі внести зміни на цьому комп'ютері?», Програма не запускається.
На перший погляд може здатися, що є тільки два рішення: запустити додаток з правами адміністратора або вимкнути UAC, причому обидва варіанти небажані. Кожен виконуваний файл в системі може супроводжуватися маніфестом додатки, які представляють собою файл. xml з параметрами, що визначають характер взаємодії додатка з UAC. Зазвичай маніфест додатка впроваджений в виконуваний файл, але іноді він може бути самостійним файлом в каталозі додатки.
Для вирішення проблеми до складу інфраструктури сумісність програми включена оболонка сумісності RunAsInvoker, що дозволяє запускати додаток без повноважень, пов'язаних з процесом створення, і без необхідності підвищення прав. По можливості, проте, переважно змінювати маніфест виконуваного файлу.
Компанія Heaven Tools пропонує програму Resource Tuner ( www.heaventools.com/resource-tuner.htm ), Що дозволяє адміністратору змінювати маніфести додатків, впроваджені в попередньо скомпільовані виконувані файли. Запуск цієї програми і зміна коду. xml надзвичайно прості. Все, що потрібно, - знайти папку Manifest в браузері ресурсів і змінити значення requestedExecutionLevel з requireAdministrator на asInvoker, а потім зберегти зміни в виконуваному файлі. Нижче наведено приклад для тега «security» в файлі маніфесту програми:
При роботі з Visual Studio (VS) можна задіяти файл mt.exe для додавання або зміни маніфесту програми. Це частина пакета засобів розробки Windows SDK.
Якщо зміна маніфесту додатки неможливо, завантажте набір засобів для забезпечення сумісності додатків - Application Compatibility Toolkit (ACT) 5.5, доступний для безкоштовного завантаження з сайту Microsoft, і використовуйте Compatibility Administrator для створення виправлення сумісності за допомогою оболонки RunAsInvoker, а потім розгорніть отриману в результаті базу даних на робочих станціях. Для цього потрібно зробити наступне.
- Увійдіть в систему Windows 7 як адміністратор і встановіть ACT.
- У меню «Пуск» відкрийте папку Application Compatibility Toolkit 5.5 і під заголовком Custom Databases на лівій панелі виберіть New Database і натисніть Ctrl + R.
- Введіть ім'я нової бази даних і натисніть «Введення».
- Натисніть Ctrl + P для створення нового виправлення програми. У діалоговому вікні Create New Application Fix введіть ім'я виправляється програми.
- Натисніть кнопку Browse, знайдіть виконуваний файл, який ви бажаєте виправлення, і натисніть Open. Для продовження клацніть Next.
- На вкладці Compatibility Modes в Operating Systems виберіть None і натисніть Next. На екрані Compatibility Fixes перейдіть меню і виберіть виправлення RunAsInvoker (екран 1).
- На даному етапі можна вибрати пробний запуск Test Run, щоб переконатися в реалізації бажаного ефекту створеного виправлення на додаток. Для продовження натисніть Next.
- В екрані Matching Information можна виконати точне налаштування, регулюючу процес визначення виконуваного файлу оброблювачем сумісності. Ми залишаємо установки за замовчуванням і натискаємо кнопку Finish.
- Клацанням на значку Save у верхній частині вікна адміністратора сумісності (екран 2) зберігаємо базу даних на диск C локального комп'ютера.
- В меню File вибираємо Install і натисканням на OK підтверджуємо установку бази даних. Після цього стає можливим запуск цільового програми без підвищення прав.
Після ґрунтовного тестування виправлення сумісності можна здійснити його поширення. Для цього скористайтеся груповою політикою і пакетним файлом з командою sdbinst.exe.
UAC як периметр безпеки
За заявою Microsoft, UAC - це функція безпеки, а не периметр безпеки. Хоча реєстрація в системі під захищеної обліковим записом адміністратора не забезпечує периметр безпеки, обліковий запис стандартного користувача з включеною службою UAC передбачає певний захист. Конфігурація UAC за замовчуванням передбачає включення так званого підвищення прав всередині сеансу користувача, за типом over-the-shoulder (OTS). Якщо запуск UAC ініційований монтажником додатки або якщо маніфест додатка вимагає запуску виконуваного файлу з правами адміністратора, система видає запит на введення пароля адміністратора для продовження. Цей процес передбачає перехід в безпечний робочий стіл (ізольований від робочого столу користувача сеанс) для виключення втручання шкідливих програм. Захист представляється надійної, чи не так?
Проблема OTS-підвищення прав полягає в тому, що шкідливі програми самі можуть ініціювати безпечний робочий стіл і вкрасти пароль адміністратора, що вводиться нічого не підозрюють користувачем. Тому Microsoft рекомендує вимикати підвищення прав за типом OTS для облікових записів стандартних користувачів в груповій політиці для зниження уразливості в корпоративних середовищах.
Відключення підвищення прав типу OTS означає також відключення можливості клацанням правої кнопки на виконуваному файлі відкривати меню і вибирати пункт «Запуск від імені адміністратора». Технічному персоналу це може здатися недоліком, однак залишається можливість, утримуючи Shift, натиснути правою кнопкою, відкрити меню і вибрати пункт «Запуск від імені іншого користувача».
Альтернатива відключення підвищення прав OTS - включення спеціального поєднання клавіш Secure Attention Sequence (SAS) в настройках групової політики. При цьому перехід в безпечний робочий стіл відбувається не автоматично, а шляхом введення комбінації Ctrl + Alt + Del. Оскільки емуляція спеціального поєднання клавіш виключається, а можливий лише фізичний введення зазначеної комбінації, користувач може бути впевнений, що безпечний робочий стіл - справжній. Включення SAS можна виконати з використанням параметра групової політики «Вимагати достовірний шлях для реєстрації облікового запису» в Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Credential User Interface. Слід, однак, мати на увазі, що SAS представляє незручність, якщо підвищення прав потрібно регулярно.
Безпека - не утопія
Windows 7, як ніколи, полегшує роботу користувача. Однак збільшення числа користувачів, що входять в систему без прав адміністратора, підвищує ймовірність розвитку шкідливих програм, які обирають мішенню такі сеанси. Різні технології, такі як політики обмеженого використання програм Software Restriction Policies, реалізовані в Vista і більш ранніх версіях, і компонент AppLocker, наявний в Windows Server 2008 R2 і в деяких випусках Windows 7, можуть застосовуватися для складання білих списків додатків, що буде мати важливе значення для запобігання впливу шкідливих програм такого типу.
Рассел Сміт ( [email protected] ) - незалежний ІТ-консультант, спеціалізується на управлінні системами
Якщо не ввести пароль і відповісти «Ні» на запитання «Дозволити наступній програмі внести зміни на цьому комп'ютері?Захист представляється надійної, чи не так?
Якщо не ввести пароль і відповісти «Ні» на запитання «Дозволити наступній програмі внести зміни на цьому комп'ютері?
Захист представляється надійної, чи не так?
Якщо не ввести пароль і відповісти «Ні» на запитання «Дозволити наступній програмі внести зміни на цьому комп'ютері?
Захист представляється надійної, чи не так?