Прошедшие проверку windows 10 что это

Время прочтения
2 мин

Просмотры 30K

В целях поддержания надлежащего уровня контроля доступа, важно однозначно понимать, что каждый объект в списке управления доступом (ACL) представляет, в том числе встроенные в ОС Windows.

Существует множество встроенных учетных записей с малопонятными именами и неопределенными описаниями, что может привести к путанице в понимании разницы между ними. Очень частый вопрос: «В чем разница между группами Everyone и Authenticated Users?»

Самое важное

Группа Authenticated Users охватывает всех пользователей, вошедших в систему, используя учетную запись и пароль. Группа Everyone охватывает всех пользователей, вошедших в систему с учетной записью и паролем, а также встроенные, незащищённые паролем учетные записи, такие как Guest и LOCAL_SERVICE.

Больше деталей

Если описанное выше показалась вам упрощённым, то дальше чуть больше деталей.

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

Группа же Everyone включает всех членов группы Authenticated Users, а также гостевую учетную запись Guest и некоторые другие встроенные учетные записи, такие как likeSERVICE, LOCAL_SERVICE, NETWORK_SERVICE и др. Гостевая учётная запись Guest по умолчанию отключена, однако если она активна, то она дает возможность попасть в систему без ввода пароля.

Вопреки распространенному мнению, любой, кто вошел в систему анонимно, т.е. не прошедшие процедуру подтверждения подлинности, не будут включены в группу Everyone. Это имело место ранее, но изменено начиная с Windows 2003 и Windows XP (SP2).

Выводы

Когда дело доходит до распределения разрешений, существует один важный вопрос, на который мы должны быть в состоянии ответить: какие конкретные люди имеют доступ к данному ресурсу?

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

Решение есть. Когда ваш CEO спросит: «Кто имеет доступ к «Зарплатная ведомость.doc»?» вы сможете быстро, уверенно и абсолютно точно дать ответ, вместо предположений после недельных расследований.

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

Напомню, что по умолчанию права на политику имеет группа Authenticated Users (Прошедшие проверку). При использовании фильтра безопасности мы удаляем эту группу и добавляем только тех, для кого эта политика должна отработать.

Функция стандартная, много раз опробованная. Но на сей раз что то пошло не так 🙁

Политика была назначена на правильную область, в фильтре безопасности находились правильные пользователи, но политика упорно не хотела отрабатывать. Не было никаких ошибок и предупреждений, а gpresult и RSOP просто показывали отсутствие политики в списке примененных к пользователю. Как будто ее не было совсем.

Проверив все что можно и что нельзя, я решил удалить политику и создать ее заново. И вот тут, при настройке фильтра безопасности, я обратил внимание на сообщение, появляющееся при удалении группы Authenticated Users.

Как следует из сообщения, для того, чтобы пользовательская политика смогла успешно отработать на компьютере, у компьютера должно быть право чтения на эту политику. А в группу Authenticated Users входят  не только пользователи, но и компьютеры, и при ее удалении компьютер не сможет получить доступ к политике и применить ее.

Это связано с обновлением безопасности MS16-072 от 14 июня 2016 года. Обновление изменяет контекст безопасности, с помощью которого извлекаются политики пользователя. До установки обновления политики извлекаются в контексте безопасности пользователя, после — в контексте компьютера. Это делает невозможным несанкционированное повышение привилегий в том случае, если злоумышленник перехватил трафик между пользовательским компьютером и контроллером домена.

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

Самый простой вариант, это добавить в фильтр группу Domain Computers, что собственно я и сделал. После этого политика успешно применилась.

Какие из этой истории можно сделать выводы? Во первых, при назначении политики на пользователя и использовании фильтров безопасности добавляйте в список группу Domain Computers. Ну и во вторых, не ленитесь читать системные сообщения, в них может быть важная информация. Которая сэкономит вам кучу времени 🙂

kaktusenok

четверг, 16 августа 2012 г.

Специальные группы Windows и их перевод на русский язык

Вот уж не думал, что будет непросто найти перевод группы «Authenticated Users». Но всё-таки получилось! Ниже приведены названия специальных групп (не всех) и их перевод на русский язык (найденные экспериментально).

ВНИМАНИЕ! При поиске по фрагменту названия очень важно соблюдать регистр! Введя «СЕ» найдём группу «СЕТЬ», а вот введя «Сеть» — уже нет. Поэтому данные (по крайней мере по русскому переводу и по возможности на английском языке) приведены в соответствующем регистре.

Знаком * отмечены встроенные группы и идентификаторы. Некоторые группы не стали переводить, а оставили в английском варианте, например, LOCAL SERVICE.

* SYSTEM
* система (Windows 7)
* SYSTEM (Windows Server 2008)

* LOCAL SERVICE
* LOCAL SERVICE (именно так!)

* NETWORK SERVICE
* NETWORK SERVICE (именно так!)

* BATCH
* ПАКЕТНЫЕ ФАЙЛЫ

* REMOTE INTERACTIVE LOGON
* REMOTE INTERACTIVE LOGON (именно так!)

* DIALUP
* УДАЛЕННЫЙ ДОСТУП

* ANONYMOUS LOGON
* АНОНИМНЫЙ ВХОД

* authenticated users
* Прошедшие проверку

* IUSR
* IUSR (именно так!)

* OWNER RIGHTS
* ПРАВА ВЛАДЕЛЬЦА

* CREATOR OWNER
* СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ

* CREATOR GROUP
* ГРУППА-СОЗДАТЕЛЬ

DOMAIN ADMINS
Администраторы домена

DOMAIN USERS
Пользователи домена

DOMAIN GUESTS
Гости домена

Конечно, это не полный список. Полный список будет зависеть от операционной системы, языка, включения в домен и других параметров/условий. Например, сюда не вошли:

* SELF
* Дайджест проверка подлинности
* Данная организация
* Другая организация
* КОНТРОЛЛЕРЫ ДОМЕНА ПРЕДПРИЯТИЯ
* ОГРАНИЧЕННЫЕ
* ПОЛЬЗОВАТЕЛЬ СЕРВЕРА ТЕРМИНАЛОВ
* Проверка подлинности NTLM
* Проверка подлинности SChannel
? PROXY
ACCOUNT OPERATORS
BACKUP OPERATORS
DnsAdmins
DnsUpdateProxy
HelpServicesGroup
PRINT OPERATORS
REPLICATOR
SERVER OPERATORS
TelnetClients
Администраторы DHCP
Администраторы SQL
Администраторы WSUS
Администраторы предприятия
Администраторы схемы
Владельцы-создатели групповой политики
Доступ DCOM службы сертификации
Издатели сертификатов
Компьютеры домена
Компьютеры сервера терминалов
Контроллеры домена
Контроллеры домена — только чтение
Контроллеры домена предприятия — только чтение
Криптографические операторы
Операторы архива
Операторы настройки сети
Операторы печати
Операторы сервера
Операторы учета
Пользователи
Пользователи DCOM
Пользователи DHCP
Пользователи домена
Пользователи журналов производительности
Пользователи системного монитора
Пользователи удаленного рабочего стола
Пред-Windows 2000 доступ
Репликатор
Серверы RAS и IAS
Серверы лицензий сервера терминалов
Сертификат этой организации
Создатели отчетов WSUS

Источник

В чем разница между группами Everyone и Authenticated Users?

В целях поддержания надлежащего уровня контроля доступа, важно однозначно понимать, что каждый объект в списке управления доступом (ACL) представляет, в том числе встроенные в ОС Windows.

Существует множество встроенных учетных записей с малопонятными именами и неопределенными описаниями, что может привести к путанице в понимании разницы между ними. Очень частый вопрос: «В чем разница между группами Everyone и Authenticated Users?»

Самое важное

Группа Authenticated Users охватывает всех пользователей, вошедших в систему, используя учетную запись и пароль. Группа Everyone охватывает всех пользователей, вошедших в систему с учетной записью и паролем, а также встроенные, незащищённые паролем учетные записи, такие как Guest и LOCAL_SERVICE.

Если описанное выше показалась вам упрощённым, то дальше чуть больше деталей.

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

Группа же Everyone включает всех членов группы Authenticated Users, а также гостевую учетную запись Guest и некоторые другие встроенные учетные записи, такие как likeSERVICE, LOCAL_SERVICE, NETWORK_SERVICE и др. Гостевая учётная запись Guest по умолчанию отключена, однако если она активна, то она дает возможность попасть в систему без ввода пароля.

Вопреки распространенному мнению, любой, кто вошел в систему анонимно, т.е. не прошедшие процедуру подтверждения подлинности, не будут включены в группу Everyone. Это имело место ранее, но изменено начиная с Windows 2003 и Windows XP (SP2).

Когда дело доходит до распределения разрешений, существует один важный вопрос, на который мы должны быть в состоянии ответить: какие конкретные люди имеют доступ к данному ресурсу?

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

Решение есть. Когда ваш CEO спросит: «Кто имеет доступ к «Зарплатная ведомость.doc»?» вы сможете быстро, уверенно и абсолютно точно дать ответ, вместо предположений после недельных расследований.

Источник

Права и группы пользователей в Windows

Группы пользователей Windows и их права

Мы уже обсуждали возможности Windows по настройке прав доступа пользователей к определенным объектам. Данными объектами выступали папки или файлы. Соответственно, мы могли дать некоторым пользователям доступ к выбранным объектам, а некоторым запретить. Права доступа к файлам это одно, а вот как настроить права доступа к определенным компонентам и возможностям операционной системы Windows? Как одному пользователю разрешить пользоваться удаленным рабочим столом, а второму запретить изменять настройки сети или времени? Тут уже обычными правами доступа NTFS не обойтись.

Для решения данной проблемы в Windows есть специальные группы пользователей с определенными правами доступа. Самые известные и наиболее используемые группы пользователей Windows — это группы Администраторы, Пользователи и Гости. Права пользователей входящих в данные группы приблизительно понятны, но сегодня я познакомлю Вас с ними поближе. Кроме этого не стоит забывать, что количество групп пользователей колеблется от 10 до 20-25, поэтому Вам будет интересно узнать про основные из них.

Как изменить права доступа пользователя?

В Windows имеется два инструмента, которые позволяют манипулировать содержимым групп пользователей операционной системы Windows. Другими словами, добавить пользователя в определенную группу или, наоборот, выкинуть его оттуда под силу сразу двум инструментам Windows:

1. Консоль Управление компьютером.
2. Редактор локальной групповой политики.

Рассмотрим оба варианта.

Настройка групп пользователей Windows через консоль Управление компьютером

Как добавить пользователя в группу пользователей Windows:

1. Выполните клик правой кнопкой компьютерной мышки по пункту Мой компьютер.
2. В контекстном меню выберите пункт Управление.
3. В открывшемся окне раскройте узел Локальные пользователи и группы.
4. Выберите узел Группы.
5. В центральном окне выберите необходимую группу и откройте ее.
6. В открывшемся окне выберите пункт Добавить.
7. В следующем окне введите имя пользователя Windows, которого Вы хотите добавить в данную группу. При необходимости воспользуйтесь кнопкой Проверить имена.
8. После выбора пользователя или сразу нескольких пользователей, жмите кнопку ОК.

Как удалить пользователя из группы:

1. Проделайте первые 5 пунктов описанные выше.
2. В открывшемся окне выберите нужного пользователя и нажмите кнопку Удалить.
3. Нажмите ОК.

Работа с группами пользователей Windows в Редакторе локальной групповой политики

Как добавить/удалить пользователя в/из группу/группы пользователей WIndows:

1. Через меню Выполнить откройте Редактор локальной групповой политики. Вызываемый файл носит имя gpedit.msc.
2. Перейдите в узел Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Назначение прав пользователей.
3. Выберите необходимую политику(каждая политика подразумевает в себе определенные права доступа).
4. Далее необходимо действовать по аналогии — для добавления пользователя проделайте пункты 6-8, а для удаления 2-3 из соответствующих пунктов настройки через консоль Управление компьютером.

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

Группы пользователей в Windows и их права доступа

А вот и долгожданный список основных групп пользователей Windows:

• Администраторы. Неограниченный доступ.
• Операторы архива. Члены данной группы имеют права создания резервной копии даже тех объектов, к которым не имеют доступа.
• Опытные пользователи. Толку от них немного, так как группа включена только для совместимости с предыдущими версиями
• Пользователи системного монитора. Есть чудесная вещь под названием Системный монитор(perfmon.msc), с помощью которого можно отследить использование различных ресурсов компьютером. А группа дает доступ к данному инструменту.
• Операторы настройки сети. Члены группы могут изменять параметры TCP/IP.
• Пользователи удаленного рабочего стола. Пользователи этой группы смогут входить в систему через удаленный рабочий стол.
• Пользователи журналов производительности. 4-ая группа дает только поверхностный доступ к Системному монитору. Данная группа дает более полные права.
• Пользователи DCOM. Пользователи группы могут манипулировать объектами распределенной модели DCOM.
• Криптографические операторы. Члены данной группы могут выполнять криптографические операции.
• Читатели журнала событий. Думаю объяснять нету смысла, все предельно ясно.

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

Источник

В чем разница между группами Everyone и Authenticated Users?

В целях поддержания надлежащего уровня контроля доступа, важно однозначно понимать, что каждый объект в списке управления доступом (ACL) представляет, в том числе встроенные в ОС Windows.

Существует множество встроенных учетных записей с малопонятными именами и неопределенными описаниями, что может привести к путанице в понимании разницы между ними. Очень частый вопрос: «В чем разница между группами Everyone и Authenticated Users?»

Самое важное

Группа Authenticated Users охватывает всех пользователей, вошедших в систему, используя учетную запись и пароль. Группа Everyone охватывает всех пользователей, вошедших в систему с учетной записью и паролем, а также встроенные, незащищённые паролем учетные записи, такие как Guest и LOCAL_SERVICE.

Если описанное выше показалась вам упрощённым, то дальше чуть больше деталей.

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

Группа же Everyone включает всех членов группы Authenticated Users, а также гостевую учетную запись Guest и некоторые другие встроенные учетные записи, такие как likeSERVICE, LOCAL_SERVICE, NETWORK_SERVICE и др. Гостевая учётная запись Guest по умолчанию отключена, однако если она активна, то она дает возможность попасть в систему без ввода пароля.

Вопреки распространенному мнению, любой, кто вошел в систему анонимно, т.е. не прошедшие процедуру подтверждения подлинности, не будут включены в группу Everyone. Это имело место ранее, но изменено начиная с Windows 2003 и Windows XP (SP2).

Когда дело доходит до распределения разрешений, существует один важный вопрос, на который мы должны быть в состоянии ответить: какие конкретные люди имеют доступ к данному ресурсу?

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

Решение есть. Когда ваш CEO спросит: «Кто имеет доступ к «Зарплатная ведомость.doc»?» вы сможете быстро, уверенно и абсолютно точно дать ответ, вместо предположений после недельных расследований.

Источник

О групповых политиках и невнимательности

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

Напомню, что по умолчанию права на политику имеет группа Authenticated Users (Прошедшие проверку). При использовании фильтра безопасности мы удаляем эту группу и добавляем только тех, для кого эта политика должна отработать.

Функция стандартная, много раз опробованная. Но на сей раз что то пошло не так 🙁

Политика была назначена на правильную область, в фильтре безопасности находились правильные пользователи, но политика упорно не хотела отрабатывать. Не было никаких ошибок и предупреждений, а gpresult и RSOP просто показывали отсутствие политики в списке примененных к пользователю. Как будто ее не было совсем.

Проверив все что можно и что нельзя, я решил удалить политику и создать ее заново. И вот тут, при настройке фильтра безопасности, я обратил внимание на сообщение, появляющееся при удалении группы Authenticated Users.

Как следует из сообщения, для того, чтобы пользовательская политика смогла успешно отработать на компьютере, у компьютера должно быть право чтения на эту политику. А в группу Authenticated Users входят не только пользователи, но и компьютеры, и при ее удалении компьютер не сможет получить доступ к политике и применить ее.

Это связано с обновлением безопасности MS16-072 от 14 июня 2016 года. Обновление изменяет контекст безопасности, с помощью которого извлекаются политики пользователя. До установки обновления политики извлекаются в контексте безопасности пользователя, после — в контексте компьютера. Это делает невозможным несанкционированное повышение привилегий в том случае, если злоумышленник перехватил трафик между пользовательским компьютером и контроллером домена.

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

Самый простой вариант, это добавить в фильтр группу Domain Computers, что собственно я и сделал. После этого политика успешно применилась.

Какие из этой истории можно сделать выводы? Во первых, при назначении политики на пользователя и использовании фильтров безопасности добавляйте в список группу Domain Computers. Ну и во вторых, не ленитесь читать системные сообщения, в них может быть важная информация. Которая сэкономит вам кучу времени 🙂

Источник

Authenticated users в русской windows

Вопрос

Как ее можно добавить? Где она находиться?

Ответы

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

Все ответы

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

меняете ваш домен на название кд (самый верхний пункт в списке)

таки вроде менять не совсем обязательно, ну смотреть надо какой из серваков резолвит имя(вполне может быть ситуация с разноязычными DC)

проще попробовать по русски и по буржуйски

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

Возле названия группы есть маленькая красненькая стрелочка направлена вверх. Это не значит что группа отключена?

жмакаете кнопку Advanced в окне Delegation, потом Add, в поле From this location меняете ваш домен на название кд (самый верхний пункт в списке), жмакаете кнопку Advanced и далее Find now

из списка выбираете Authenticated users и даете права на read и apply

The opinion expressed by me is not an official position of Microsoft

Возле названия группы есть маленькая красненькая стрелочка направлена вверх. Это не значит что группа отключена?

The opinion expressed by me is not an official position of Microsoft

Источник

Authenticated users в русской windows

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами научились отключать защитник Windows 8.1, у каждого была своя причина произвести данное действие. Сегодня я хочу вас научить очень полезной вещи, без которой системный администратор управляющий групповой политикой не сможет активно и гибко ее применять. И речь пойдет про применение фильтров на разных этапах применения групповой политики к компьютерам и пользователям.

Для чего нужен механизм фильтрации GPO

Какую бы вы сложную иерархию Active Directory не создавали у вас рано или поздно появится ситуация, что вам нужно для двух и более объектов находящихся в одном OU иметь разные настройки, а для кого-то вообще запретить применение определенной групповой политики, но перемещать объект нельзя, так как в текущей иерархии он получает все настройки по корпоративному стандарту, и усложнять структуру не представляется возможным.

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

Виды фильтрации групповых политик

Фильтр безопасности GPO

Данный метод метод ограничения применений групповой политикой самый очевидный и используемый. Тут логика простая, что если вы хотите применить групповую политику, только к определенным объектам:

то вы можете их добавить в данный фильтр, после чего нужно удалить группу «Прошедшие проверку (authentication user)«, так как в нее входят все пользователи и компьютеры домена. Давайте это попробуем. Открываем оснастку «Управление групповой политикой». В прошлый раз я создавал политику «Настройка MaxTokenSize» в задачи которой входило изменение размера токена kerberos. Предположим, что я хочу применить ее только в локальной доменной группе MaxTokenSize. Для этого я нажимаю кнопку «Добавить» в области «Фильтры безопасности«, находим ее и нажимаем «Ok».

Теперь нам необходимо удалить группу по умолчанию «Прошедшие проверку«, напоминаю, что в нее входят все компьютеры и пользователи домена.

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

В начале 2016 года я столкнулся с тем, что моя политика не отработала, хотя все фильтры безопасности были настроены правильно. Открыв вывод команды gpresult/ r, я обнаружил статус (Unknown reason).

Начав разбираться, все пришло к тому, что новые обновления Microsoft (KB3159398, KB3163017, KB3163018) закрывал одну нехорошую вещь, которая длилась с 2000 года. Проблема заключалась в том, что злоумышленник мог применять атаку «Человек посередине (Man in the Middle)», тем самым делать подмену ответа от контроллера домена на целевом компьютере, это выливалось в то, что он подделывал политику безопасности, которая давала ему права локального администратора для скомпрометированной учетной записи.

Microsoft долго билась с этой проблемой и пришла к решению поменять порядок считывания политики, теперь это могут делать только компьютеры домена. Раньше политики пользователя считывал пользователь, политики компьютера, компьютер. Установив KB3163622 теперь для считывания GPO используется только компьютер и если он не входит в фильтр безопасности политики, то она не применится (Подробнее можете посмотреть вот тут https://support.microsoft.com/en-us/help/3163622/ms16-072-security-update-for-group-policy-june-14-2016).

Исходя из данной ситуации, чтобы политики успешно применялись Microsoft предложило добавлять одну из групп безопасности в ACL политики «Прошедшие проверку» или «Все компьютеры». Переходим к ACL.

Фильтрация GPO через ACL (Запрет GPO)

И так фильтрацию в фильтре мы сделали, чтобы политика применилась нам необходимо выбрать политику и перейти на вкладку «Делегирование». Тут нам необходимо добавить одну из двух групп «Прошедшие проверку (Authenticated Users)» или «Все компьютеры (Domain Computers)«. Я добавляю первую. Нажимаем кнопку «Добавить» и находим нашу группу.

Уровень прав оставляем «Чтение», этого будет достаточно.

Пробуем проверить применение нашей политики. В качестве испытуемого у меня идет виртуальная машина с Windows 10. После загрузки, я открываю командную строку и смотрю применение политики, для этого пишем команду:

В итоге я вижу, что среди примененных объектов групповой политики, моя «Настройка MaxTokenSize» в списке присутствует.

Если бы пользователь не был членом группы, которая фигурирует с фильтре безопасности, то мы видели бы вот такую картину, что следующие политики GPO не были применены, так как они отфильтрованы по причине отказано (Безопасность). Как видим нет прав на чтение.

Еще вкладку «Делегирования» используют и для запрещения, простой пример вы сделали политику которая для всех пользователей домена применяет корпоративные обои на рабочий стол. Допустим, что вам для администраторов домена или для круга избранных нужно сделать так, чтобы к ним не применялась политика. Вы создаете группу и уже ей запрещаете чтение данной политики, хоть пользователи и будут по прежнему входить в группу «Прошедшие проверку», но прочитать они ее не смогут так как явный запрет для другой группы куда они входят, гораздо сильнее и приоритетнее чем права чтения.

Добавляем группу для которой хотим запретить применение политики, у меня это Forbidden MaxTokenSize.

Далее даем права «Чтение».

Далее нажимаем кнопку «Дополнительно«, у вас откроется окно параметром безопасности. Тут вы выбираете нужную вам группу, для которой вы хотите запретить применение групповой политики и ставите галку «Запретить«. В таком случае данная группа будет получать при попытке считать GPO «Отказано (безопасность)».

Фильтрация GPO по WMI

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

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

Задаем имя WMI фильтра, после чего нажимаем кнопку «Добавить». Откроется окно для составления запроса. Конструкция для Windows 7 будет такая:

Номера для Win32_OperatingSystem

Тип продукта отвечает за назначение компьютера и может иметь 3 значения:

Вот вам пример вывода в PowerShell команды показывающей версию операционной системы:

Сохраняем наш WMI запрос.

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

Теперь если компьютер не соответствует критериям WMI фильтра, то вы увидите в gpresult /r /scope:computer вот такую запись (Отказано фильтр WMI)

Фильтрация через состояние GPO

Еще на вкладке «Сведения» есть такая настройка, как состояние GPO. Она необходима для ускорения обработки политики, путем отключения лишних веток. Например у вас политика исключительно на пользователя и вам смысла нет, чтобы компьютер при загрузке пытался прочитать настройки для компьютера, тратя на это время. В таких случаях отключают данный функционал. Тут есть варианты:

Источник

Проверка подлинности пользователей с помощью проверки подлинности Windows (C#)

Узнайте, как использовать аутентификацию Windows в контексте приложения MVC. Вы узнаете, как включить аутентификацию Windows в файле веб-конфигурации приложения и как настроить аутентификацию с помощью IIS. Наконец, вы узнаете, как использовать атрибут «Authorize» для ограничения доступа к действиям контроллера для определенных пользователей или групп Windows.

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

Использование аутентификации Windows имеет смысл при создании внутреннего веб-сайта компании (сайт интрасети), и вы хотите, чтобы ваши пользователи могли использовать свои стандартные имена пользователей Windows и пароли при доступе к веб-сайту. Если вы создаете веб-сайт с внешним видом на внешний вид (интернет-сайт) рассмотрите возможность использования аутентификации Форм.

Включение аутентификации Windows

При создании нового приложения mVC ASP.NET проверка подлинности Windows по умолчанию не включена. Проверки подлинности форм — это тип проверки подлинности по умолчанию, включенный для приложений MVC. Необходимо включить аутентификацию Windows, изменив веб-конфигурацию приложения MVC (web.config). Найдите проверки подлинности и измените его, чтобы использовать Windows вместо формы аутентификации следующим образом:

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

Во-первых, при разработке приложения MVC используется веб-сервер ASP.NET разработки, включенный в Visual Studio. По умолчанию веб-сервер ASP.NET разработки выполняет все страницы в контексте текущей учетной записи Windows (независимо от учетной записи, которую вы использовали для входа в Windows).

Веб-сервер ASP.NET разработки также поддерживает аутентификацию NTLM. Вы можете включить проверку подлинности NTLM, нажав правой кнопкой назовем название вашего проекта в окне Solution Explorer и выбрав свойства. Затем выберите веб-вкладку и проверьте флажок NTLM (см. рисунок 1).

Для производственного веб-приложения, с другой стороны, вы используете IIS в качестве веб-сервера. IIS поддерживает несколько типов аутентификации, включая:

Более подробный обзор этих различных типов аутентификации см. https://msdn.microsoft.com/library/aa292114(VS.71).aspx

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

Используя информационные службы Интернета, можно включить или отключить различные типы аутентификации. Например, на рисунке 3 показано отключение анонимной аутентификации и включение интегрированной проверки подлинности Windows (NTLM) при использовании IIS 7.0.

Авторизация пользователей и групп Windows

После включения аутентификации Windows можно использовать атрибут «Авторизовать» для управления доступом к контроллерам или действиям контроллера. Этот атрибут может быть применен ко всему контроллеру MVC или определенному действию контроллера.

Например, контроллер Home в листинге 1 предоставляет три действия под названием Index (), CompanySecrets() и StephenSecrets(). Любой человек может вызвать действие Индекса () Однако только члены локальной группы менеджеров Windows могут ссылаться на действия CompanySecrets() Наконец, только пользователь домена Windows по имени Стивен (в домене Редмонд) может вызвать действие StephenSecrets ()

Из-за управления учетными записями пользователей Windows (UAC), при работе с Windows Vista или Windows Server 2008, местная группа администраторов будет вести себя иначе, чем другие группы. Атрибут «Авторизовать» не распознает правильно члена локальной группы администраторов, если вы не измените настройки UAC вашего компьютера.

То, что происходит при попытке вызвать действие контроллера, не будучи правильными разрешениями, зависит от типа включенной аутентификации. По умолчанию при использовании ASP.NET сервера разработки вы просто получаете пустую страницу. Страница подается с 401 Не авторизованным статусом ответа HTTP.

Если, с другой стороны, вы используете IIS с отключенной аутентификацией Anonymous и включенной базовой аутентификацией, то вы продолжаете получать запрос на диалог входа каждый раз, когда вы запрашиваете защищенную страницу (см. рисунок 4).

Источник

Обновлено 10.07.2019

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами научились отключать защитник Windows 8.1, у каждого была своя причина произвести данное действие. Сегодня я хочу вас научить очень полезной вещи, без которой системный администратор управляющий групповой политикой не сможет активно и гибко ее применять. И речь пойдет про применение фильтров на разных этапах применения групповой политики к компьютерам и пользователям.

Для чего нужен механизм фильтрации GPO

Какую бы вы сложную иерархию Active Directory не создавали у вас рано или поздно появится ситуация, что вам нужно для двух и более объектов находящихся в одном OU иметь разные настройки, а для кого-то вообще запретить применение определенной групповой политики, но перемещать объект нельзя, так как в текущей иерархии он получает все настройки по корпоративному стандарту, и усложнять структуру не представляется возможным.

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

Виды фильтрации групповых политик

1. Это фильтр безопасности
2. Это фильтр WMI
3. Это фильтр на вкладке делегирование
4. Это фильтр на вкладке сведения

Фильтр безопасности GPO

Данный метод метод ограничения применений групповой политикой самый очевидный и используемый. Тут логика простая, что если вы хотите применить групповую политику, только к определенным объектам:

• Пользователям
• Компьютерам
• Группам

то вы можете их добавить в данный фильтр, после чего нужно удалить группу «Прошедшие проверку (authentication user)«, так как в нее входят все пользователи и компьютеры домена. Давайте это попробуем. Открываем оснастку «Управление групповой политикой». В прошлый раз я создавал политику «Настройка MaxTokenSize» в задачи которой входило изменение размера токена kerberos. Предположим, что я хочу применить ее только в локальной доменной группе MaxTokenSize. Для этого я нажимаю кнопку «Добавить» в области «Фильтры безопасности«, находим ее и нажимаем «Ok».

Теперь нам необходимо удалить группу по умолчанию «Прошедшие проверку«, напоминаю, что в нее входят все компьютеры и пользователи домена.

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

В начале 2016 года я столкнулся с тем, что моя политика не отработала, хотя все фильтры безопасности были настроены правильно. Открыв вывод команды gpresult/ r, я обнаружил статус (Unknown reason).

Начав разбираться, все пришло к тому, что новые обновления Microsoft (KB3159398, KB3163017, KB3163018) закрывал одну нехорошую вещь, которая длилась с 2000 года. Проблема заключалась в том, что злоумышленник мог применять атаку «Человек посередине (Man in the Middle)», тем самым делать подмену ответа от контроллера домена на целевом компьютере, это выливалось в то, что он подделывал политику безопасности, которая давала ему права локального администратора для скомпрометированной учетной записи.

Microsoft долго билась с этой проблемой и пришла к решению поменять порядок считывания политики, теперь это могут делать только компьютеры домена. Раньше политики пользователя считывал пользователь, политики компьютера, компьютер. Установив KB3163622 теперь для считывания GPO используется только компьютер и если он не входит в фильтр безопасности политики, то она не применится (Подробнее можете посмотреть вот тут https://support.microsoft.com/en-us/help/3163622/ms16-072-security-update-for-group-policy-june-14-2016).

Исходя из данной ситуации, чтобы политики успешно применялись Microsoft предложило добавлять одну из групп безопасности в ACL политики «Прошедшие проверку» или «Все компьютеры». Переходим к ACL.

Фильтрация GPO через ACL (Запрет GPO)

И так фильтрацию в фильтре мы сделали, чтобы политика применилась нам необходимо выбрать политику и перейти на вкладку «Делегирование». Тут нам необходимо добавить одну из двух групп «Прошедшие проверку (Authenticated Users)» или «Все компьютеры (Domain Computers)«. Я добавляю первую. Нажимаем кнопку «Добавить» и находим нашу группу.

Уровень прав оставляем «Чтение», этого будет достаточно.

Пробуем проверить применение нашей политики. В качестве испытуемого у меня идет виртуальная машина с Windows 10. После загрузки, я открываю командную строку и смотрю применение политики, для этого пишем команду:

В итоге я вижу, что среди примененных объектов групповой политики, моя «Настройка MaxTokenSize» в списке присутствует.

Если бы пользователь не был членом группы, которая фигурирует с фильтре безопасности, то мы видели бы вот такую картину, что следующие политики GPO не были применены, так как они отфильтрованы по причине отказано (Безопасность). Как видим нет прав на чтение.

Еще вкладку «Делегирования» используют и для запрещения, простой пример вы сделали политику которая для всех пользователей домена применяет корпоративные обои на рабочий стол. Допустим, что вам для администраторов домена или для круга избранных нужно сделать так, чтобы к ним не применялась политика. Вы создаете группу и уже ей запрещаете чтение данной политики, хоть пользователи и будут по прежнему входить в группу «Прошедшие проверку», но прочитать они ее не смогут так как явный запрет для другой группы куда они входят, гораздо сильнее и приоритетнее чем права чтения.

Добавляем группу для которой хотим запретить применение политики, у меня это Forbidden MaxTokenSize.

Далее даем права «Чтение».

Далее нажимаем кнопку «Дополнительно«, у вас откроется окно параметром безопасности. Тут вы выбираете нужную вам группу, для которой вы хотите запретить применение групповой политики и ставите галку «Запретить«. В таком случае данная группа будет получать при попытке считать GPO «Отказано (безопасность)».

Фильтрация GPO по WMI

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

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

Задаем имя WMI фильтра, после чего нажимаем кнопку «Добавить». Откроется окно для составления запроса. Конструкция для Windows 7 будет такая:

Номера для Win32_OperatingSystem

• Windows Server 2019Windows 10 1809 — 10.0.17763
• Window Server 2016Windows 10 — 10.0
• Window Server 2012 R2Windows 8.1 — 6.3
• Window Server 2012Windows 8 — 6.2
• Window Server 2008 R2Windows 7 — 6.1

Тип продукта отвечает за назначение компьютера и может иметь 3 значения:

• 1 — рабочая станция;
• 2 — контроллер домена;
• 3 — сервер.

Вот вам пример вывода в PowerShell команды показывающей версию операционной системы:

Сохраняем наш WMI запрос.

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

Теперь если компьютер не соответствует критериям WMI фильтра, то вы увидите в gpresult /r /scope:computer вот такую запись (Отказано фильтр WMI)

Фильтрация через состояние GPO

Еще на вкладке «Сведения» есть такая настройка, как состояние GPO. Она необходима для ускорения обработки политики, путем отключения лишних веток. Например у вас политика исключительно на пользователя и вам смысла нет, чтобы компьютер при загрузке пытался прочитать настройки для компьютера, тратя на это время. В таких случаях отключают данный функционал. Тут есть варианты:

• Включено
• Все параметры отключены
• Параметры конфигурации компьютера отключены
• Параметры конфигурации пользователя отключены

На этом у меня все. Мы с вами разобрали все методы и механизмы фильтрации групповых политик, теперь вы готовы к любому сценарию. С вами был Иван Семин .автор и создатель IT портала Pyatilistnik.org.

Файловая система NTFS позволяет настраивать разрешения доступа к отдельным папкам или файлам для отдельных пользователей. Вы вправе настроить доступ к папкам/файлам так, как хотите: закрыть доступ к своим файлам для одних пользователей и открыть доступ другим пользователям. В таком случае, первые смогут работать с Вашими документами, а вторые увидят перед собой окно с сообщением «Отказано в доступе к файлу». Но возможности настройки доступа к папкам/файлам не ограничиваются только тем, могут или не могут пользователи достучаться до Ваших документов. Вы можете конкретизировать разрешения доступа. Так, кто-то из пользователей сможет только прочитать документ, а кто-то сможет и изменить его.

Как открыть или закрыть доступ к файлам или папкам в Windows?

Чтобы настроить права доступа к файлу/папке, необходимо выбрать пункт Свойства в контекстном меню данного файла/папки. В открывшемся окне необходимо перейти во вкладку Безопасность. Далее перед Вами представлено два способа настройки прав доступа.

1. Нажимаем кнопку Изменить. После чего наблюдаем такую картину:
   В данном окне мы можем добавить либо удалить пользователя или целую группу пользователей, для которых мы хотим настроить права доступа к данному объекту. Для этих целей необходимо использовать кнопки Добавить и Удалить. После того как Вы выбрали пользователей, для которых хотите настроить соответствующие права доступа, поочередно выделите их и наделите соответствующими правами на основание различных уровней доступа. Чтобы разрешить или наоборот запретить доступ, необходимо наделить галочкой соответствующие пункты.Чтобы сохранить изменения жмите Применить, после чего ОК.
2. Жмём кнопку Дополнительно. Данное окно предоставляет дополнительные возможности по настройке прав доступа к объекту.
   Функционал, который был представлен в первом пункте, содержится во вкладке Разрешения. С помощью кнопок Добавить и Удалить Вы можете соответственно добавить пользователей в список или удалить их. Чтобы выставить соответствующие разрешения для выбранного пользователя или группы пользователей, необходимо воспользоваться кнопкой Изменить.
   В ниспадающем меню Вы можете выбрать тип разрешения(разрешить или запретить), а в случае с папками, Вы можете выбрать область действия данных правил.Как видите, данное окно предоставляет все те же 7 разрешений доступа к объекту. Но если нажать на кнопку Отображение дополнительных разрешений, то Вы получите целых 14 уровней доступа.

   

   Выбор соответствующих разрешений производится путем добавления галочки напротив соответствующего пункта.

   Вкладка Аудит позволяет настроить документирование различных попыток доступа к файлу/папке. Так, Вы можете получать уведомление каждый раз, когда кто-то успешно или безуспешно открывает папку/файл, когда кто-то меняет название или содержимое документа и так далее. Вы можете вести аудит как успешных, так и безуспешных действий. Для аудита так же можно настроить область его действия. Задокументированные данные можно будет просмотреть в Журнале Событий.

   Вкладка Действующие права доступа покажет права доступа к данному объекту для выбранного пользователя.

Разрешить доступ или запретить доступ?

Перед тем как начать навешивать галочки для каких-либо пользователей, стоит знать следующее: права доступа должны быть настроены явным образом. Это означает то, что для доступа к объекту необходимо получить явное разрешение. А вот чтобы доступа к объекту не было, достаточно вообще не выделять никаких разрешений. Ведь если Вы явным образом не указали разрешение доступа, то пользователь не сможет получить доступ к данному объекту. Поэтому возникает резонный вопрос, почему вообще нужен тип разрешения Запретить? А для этого необходимо знать еще два правила:

1. Тип разрешения Запретить имеет приоритет над типом Разрешить.
2. Итоговые права доступа к объекту для пользователя получаются путем суммирования всех правил доступа к данному объекту.

Если с первым пунктом вопросов не должно быть, то вот второй требует объяснения. Рассмотрим на примере: если к папке papka обычный пользователь user имеет разрешение на чтение и запись, а группа Пользователи имеют разрешение только на чтение папки papka, то итоговые права доступа для пользователя user будут разрешать и чтение, и запись относительно этой папки, что противоречит политике, по которой Пользователи могут только читать данную папку. Именно поэтому и нужен тип разрешения Запретить. Если по одной политике доступ к файлу у пользователя должен быть, а по-другому — нет, то необходимо явным образом запретить доступ к файлу, ведь иначе он у него появится, а это противоречит второй политике.

Именно для того, чтобы облегчить суммирование всех правил доступа к объекту, и существует вкладка Действующие права доступа.

Пользователи, Администраторы, Прошедшие проверку и так далее

Вдобавок ко всему перечисленному, необходимо знать, что все пользователи, независимо от настроенных прав доступа, по умолчанию входят в группу Пользователи. И по умолчанию на все объекты(кроме некоторых объектов операционной системы) пользователи данной группы имеют доступ для чтения и изменения. А вот пользователи из группы Администраторы по умолчанию имеют полный доступ ко всем объектам системы. В группу пользователей Прошедшие проверку входят любые пользователи, которые вошли в систему. Разрешения доступа у них приблизительно равны с правами доступа обычных пользователей.

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

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