Группа авторизации доступа windows что это

Группы — это объекты, являющиеся участниками системы безопасности (security principals) и предназначенные для управления доступом к ресурсам. Каждой группе присваивается уникальный идентификатор безопасности (Security Identifier, SID), который сохраняется в течение всего срока службы.

Условно группы можно разделить по области их действия.

Локальные группы

Локальные группы безопасности создаются на локальном компьютере, и использовать их можно для управления доступом к ресурсам, находящимся только на этом компьютере. Управляются они менеджером учетных записей безопасности (Security Account Manager, SAM).

Локальные группы можно условно разделить на два типа — встроенные (BuiltIn) и дополнительно созданные. Встроенные группы — это группы, имеющиеся в операционной системе по умолчанию, например та же группа Administrators. Ну а дополнительно созданные — группы, созданные вручную, для предоставления доступа к локальным ресурсам, например общим папкам.

Различить эти группы легко можно по SID-у. У встроенных групп SID формата S-1-5-32-XXX, где XXX — число от 500 до 1000. У обычных же формат вида S-1-5-21-XXX-XXX-XXX-YYY, где XXX-XXX-XXX — это 48-битный идентификатор системы, YYY- относительный идентификатор (Relative ID, RID). RID состоит из четырех чисел (от 1000 и больше) и однозначно идентифицирует участника безопасности в локальном домене.

Примечание. SID-ы встроенных групп во всех операционных системах Windows идентичны.

Доменные группы

С локальными группами все более менее понятно, переходим к доменным. Группы безопасности в домене Active Directory разделяются по области применения:

• Локальные в домене (Domain Local);
• Глобальные (Global);
• Универсальные (Universal).

Для наглядности сведем различия между ними в таблицу.

Встроенные доменные группы

И вот теперь плавно переходим к группам, ради которых и задумана эта статья, а именно встроенные группы домена (Builtin Local).

При повышении сервера до контроллера домена локальная база SAM становится недоступной, так же как и оснастка Local Users and Groups, а для входа на сервер используется база данных Active Directory. Это сделано с целью повышения безопасности.

Примечание. Единственный случай, когда для входа на контроллер домена используется SAM — это загрузка в режиме восстановления (Directory Service Restore Mode, DSRM). Это связано с тем, что пароль администратора DSRM хранится локально в базе SAM, а не в Active Directory (что вполне логично).

А  что же происходит с локальными группами на сервере, когда мы делаем его контроллером домена? Сам сервер становится общей базой данных пользователей, групп и других объектов безопасности в домене, а все его локальные пользователи и группы переносятся в базу Active Directory. Пользователи и дополнительно созданные группы попадают в контейнер Users

а встроенные группы — в Builtin.

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

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

Для примера возьмем группу, созданную вручную, и сравним ее со встроенной доменной.

Как видите, у обоих групп SID остался таким же, как был на локальном сервере. И так же, как у локальных групп, встроенные группы домена не содержат в своем SID-е идентификатор домена. По сути встроенные доменные группы дублируют локальные встроенные группы, но на уровне домена. Как я уже говорил, SID встроенных групп во всех операционных системах Windows идентичны, и получается, что на каждом компьютере домена (кроме домен-контроллеров) имеются свои локальные встроенные группы, идентификаторы которых совпадают с идентификаторами встроенных групп домена.

Поэтому использовать их на рабочих станциях и рядовых серверах домена невозможно. Например, вы не сможете добавить добавить доменных BuiltIn\Administrators в список доступа на файловую шару на рядовом сервере домена, ее там просто не будет видно. Область действия доменных Builtin Local групп ограничена системами, на которых локальная база SAM недоступна — то есть контроллерами домена.

Domain Local группы, созданные из обычных локальных групп, такого ограничения не имеют. Их SID содержит компонент с идентификатором домена, поэтому уникальность в сравнении с другими локальными группами домена сохраняется. Что важно — при превращении сервера в первый контроллер домена в новом домене SID этих групп не меняется. Поэтому если создать на сервере локальную группу и выдать ей права например на папку с файлами, то после повышения сервера эта группа станет Domain Local и все её права сохранятся.

Но вернемся к нашим баранам Builtin Local группам и рассмотрим их поподробнее.

Как видите, не смотря на ограниченную область действия встроенные группы домена обладают весьма широкими возможностями. Особенно аккуратно стоит относиться к группе Administrators, которая имеет неограниченные полномочия в рамках всего домена, а в корневом домене леса — и во всем лесу.

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

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

И вдруг оказывается, что некоторые сотрудники техподдержки каким то образом заходят на контроллеры домена и вносят изменения в Active Directory, хотя прав на это у них быть не должно. В группе доменных админов они отсутствуют, делегированных полномочий тоже нет. А права тем не менее есть.

Стали выяснять и оказалось, что политика, которая добавляет пользователей в локальные админы, применена ко всему домену. Отработала она и на контроллерах домена, и поскольку локальных администраторов там нет, добавила техподдержку в доменную Builtin\Administrators. Со всеми вытекающими последствиями.

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

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

Количество просмотров 32K

В целях поддержания надлежащего уровня контроля доступа, важно однозначно понимать, что каждый объект в списке управления доступом (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, которая определяет пользователей, имеющих доступ к тем или иным ресурсам, основана на концепциях разрешений (permission) и пользовательских прав (user right). Разрешения связаны с объектами — например, разрешения для распечатывания файла, создания папки и добавления объекта user в Active Directory (AD). Пользовательские права связаны с системой Windows в целом — например, право пользователя регистрироваться в системе Windows или изменять системные часы.

Права пользователя Windows подразделяются на две категории: привилегии пользователя (user privilege) и права регистрации (logon right). Привилегии пользователя, такие как Change the System Time и Shut down the System, обеспечивают контроль над системными ресурсами и операциями, связанными с системой. Права регистрации задают учетные записи пользователей, которые могут регистрироваться в системе Windows, и способ регистрации учетной записи пользователя в системе. Более подробная информация об учетных записях пользователя и процедуре входа Windows приведена в статье «Все дело в доверии» (http://www.osp.ru/text/302/2599419/). В данной статье рассматривается, как использовать права регистрации в качестве инструмента контроля доступа, даны объяснения различных прав доступа и рекомендации по их применению.

Права регистрации — общая картина

В Windows Server 2003 и Windows XP определены 10 различных прав доступа, с помощью которых можно управлять разными типами попыток локальной и доменной аутентификации пользователей в системах Windows. Права регистрации также охватывают процедуры аутентификации пользователей, в том числе регистрацию в FTP-службе на базе Windows. Например, чтобы обеспечить регистрацию учетной записи пользователя в FTP-службе на базе Windows, необходимо присвоить учетной записи право Log on locally в системе Windows, на которой размещена служба FTP. В Windows 2000 было введено право регистрации «deny». Windows 2003, XP и Windows 2000 Service Pack 2 (SP2) и более поздние версии поддерживают права регистрации для Terminal Services.

В таблице 1 перечислены права регистрации Windows наряду с именами API, соответствующими каждому праву регистрации, и показаны встроенные группы, которые получают права регистрации, назначаемые по умолчанию на контроллере домена (DC), члене-сервере и автономной системе. Имена API — внутренние имена, используемые Windows для обозначения прав регистрации. Иногда их необходимо указывать при использовании инструментов командной строки, о которых будет рассказано ниже, или при просмотре журнала событий Security. Рассмотрим каждое право регистрации немного подробнее:

• Log on locally позволяет пользователям регистрироваться в Windows с помощью комбинации клавиш Ctrl+Alt+Del или из экрана Welcome. В Windows этот метод входа называется локальным или интерактивным. Пользователям Windows 2000 это право необходимо для входа через Terminal Services.
• Access this computer from the network обеспечивает подключение пользователей к компьютеру через сеть. Это право обязаны иметь все пользователи, желающие обратиться к удаленной системе для доступа к файлу, папке, приложению или другому ресурсу. В Windows данный метод регистрации называется сетевым или неинтерактивным входом.
• Log on as a batch job позволяет пользователям регистрироваться для запуска пакета команд. Это право применяется в Windows Task Scheduler и некоторых других службах для регистрации пользователей. Scheduled Tasks автоматически предоставляет это право по мере необходимости — в моменты, когда необходимо запустить запланированное задание.
• Log on as a service позволяет субъекту безопасности регистрироваться в качестве службы. Это право обеспечивает работу служб в системах Windows в фоновом режиме. Учетным записям System и Network Service на автономных системах и серверах, членах доменов, это право предоставляется по умолчанию. Если для запуска службы используется другая специальная запись, то необходимо явно назначить ей это право.
• Allow logon through Terminal Services определяет пользователей, которые могут регистрироваться с помощью Terminal Services или клиента Remote Desktop.
• Deny logon locally запрещает пользователю регистрироваться с клавиатуры или экрана Welcome компьютера. Это право имеет приоритет перед правом Log on locally.
• Deny access to this computer from the network запрещает пользователю подключаться к компьютеру через сеть. Это право имеет приоритет перед правом Access this computer from the network.
• Deny logon as a service запрещает субъекту безопасности регистрироваться в качестве службы для формирования контекста безопасности. Это право имеет приоритет перед правом Log on as a service.
• Deny logon as a batch job запрещает пользователю регистрироваться в роли пакетного файла; оно имеет приоритет перед правом Log on as a batch job.
• Deny logon through Terminal Services запрещает пользователю регистрироваться с помощью Terminal Services или Remote Desktop; это право имеет приоритет перед правом Allow logon through Terminal Services.

Права Deny logon полезны в крупных сетях Windows. Например, если нужно предоставить право Access this computer from the network всем, кроме двух конкретных учетных записей. В этом случае, гораздо проще назначить группе Authenticated Users право Access this computer from the network, а двум отдельным учетным записям — право Deny access to this computer from the network, вместо того, чтобы определять все учетные записи, имеющие доступ, объединяя их в специальную группу, а затем назначать этой группе право Access this computer from the network.

Управление правами регистрации в Windows

Чтобы назначать и управлять правами регистрации в Windows, можно использовать инструмент Local Security Policy (только на автономных системах) или оснастку Group Policy Object консоли Microsoft Management Console (MMC) (для автономных компьютеров и систем, членов доменов). В комплектах ресурсов Windows 2003 и Windows 2000 содержится два инструмента командной строки, которые помогают управлять правами регистрации: NTRights (ntrights.exe) и ShowPriv (showpriv.exe).

К инструменту Local Security Policy можно обратиться из раздела Administrative Tools Панели управления (меню Start, Settings, Control Panel, Administrative Tools, Local Security Policy). В окне Local Security Settings, право регистрации назначается путем расширения контейнеров Security Settings, Local Policies, User Rights Assignment (Экран 1).

Для доступа к оснастке Group Policy Object следует запустить MMC, затем загрузить оснастку. Для управления правами входа на автономных системах следует выбрать Local Computer Group Policy Object (GPO); для управления правами входа на контроллерах домена (DC), нужно выбрать Default Domain Controllers GPO. В оснастке Group Policy Object можно назначить права регистрации, развернув контейнеры Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment (Экран 2).

С помощью утилиты NTRights можно предоставлять и отменять пользовательские права Windows (как права регистрации, так и привилегии) для пользователей и групп на локальном или удаленном компьютере. Например, чтобы предоставить учетной записи ServiceAccount1 право Logon as a service на компьютере MyComputer, следует выполнить следующую команду:

Ntrights +r SeServiceLogonRight
 -u ServiceAccount1 -m MyComputer

Отменить право Access this computer from the network для группы Authenticated Users можно с помощью команды

Ntrights -r SeNetworkLogonRight -u Everyone

С помощью утилиты ShowPriv можно вывести на экран пользователей и группы, которым назначено конкретное пользовательское право только в локальной системе. Например, чтобы отыскать пользователей и группы, которые имеют право регистрации Log on locally в данной системе, следует выполнить команду

Showpriv SeInteractiveLogonRight

Оптимальные процедуры

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

Еще один эффективный прием — назначать пользовательские права доменным, а не локальным учетным записям. С помощью локальной учетной записи пользователь может обойти централизованную политику безопасности, применяемую на уровне домена Windows. Как отмечалось в статье «Все дело в доверии», следует всегда стараться использовать домены Windows, независимо от размера сети.

Кроме того, полезно при любой возможности назначать служебным учетным записям права Deny logon locally, Deny access to this computer from the network и Deny logon through Terminal Services. Всегда следует руководствоваться принципом минимальных достаточных привилегий. В контексте прав регистрации, это значит, что служебной учетной записи нужно назначать только права регистрации, необходимые для работы.

Может оказаться, что стандартные права регистрации, перечисленные в таблице 1, недостаточно строги. Чтобы блокировать назначенные права регистрации, рекомендуется принять следующие меры:

• Отменить право Log on locally для групп Users, Power Users и Guest на серверах, членах доменов.
• Отменить право Access this computer from the network для группы Authenticated Users на отдельных серверах и контроллерах доменов.

Права регистрации и журналы событий

В журнале событий Windows перечислены события аудита регистрации, которые относятся к рассмотренным правам регистрации. Просматривать события аудита полезно при диагностике проблем с аутентификацией Windows. Для генерации событий аудита регистрации, следует активизировать режим Audit account logon events (как успешных, так и неудачных) в политике аудита автономной системы или домена.

Наибольший интерес для администратора представляет поле Logon Type. На Экране 3 показано событие регистрации с ID 540, которое свидетельствует об удачной регистрации. В поле Description можно увидеть поле Logon Type, содержащее значение 3, которое указывает, что успешный вход был произведен с помощью сетевой регистрации. Поле Logon Type содержать значения 2 (интерактивный вход), 3 (сетевой вход) 4 (пакетный вход) или 5 (регистрация службы). Самые часто встречающиеся значения Logon Type — 2 и 3. Logon Type 2 в журналах Event Viewer показывает, что кто-то интерактивно зарегистрировался в системе. Logon Type 3 означает, что кто-то пытался обратиться к ресурсам компьютера по сети. Logon Type 4 показывает, что служба Task Scheduler запускает сценарий или программу в пакетном режиме. Logon Type 5 означает, что была запущена служба Windows от имени конкретной пользовательской учетной записи.

Мощный инструмент управления доступом

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

Экран 1. Использование инструмента Local Security Policy для назначения прав регистрации.

Экран 2. Использование оснастки Group Policy Object для назначения прав регистрации.

Экран 3. Событие аудита для для успешного входа.

Жан де Клерк (jan.declercq@hp.com) — член Security Office компании HP. Специализируется на управлении идентификационными параметрами и безопасности в продуктах Microsoft. Он автор книги Windows Server 2003 Security Infrastructures (издательство Digital Press).

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.

• Аутентификация — происходит от английского слова authentication, которое можно перевести как идентификация или проверка подлинности. Это полностью отражает суть процесса — проверка подлинности пользователя, т.е. мы должны удостовериться, что пользователь, пытающийся получить доступ к системе именно тот, за кого себя выдает.
• Авторизация — перевод слова authorization означает разрешение, т.е. проверка прав доступа к какому-либо объекту. Процесс авторизации может быть применен только к аутентифицированному пользователю, так как перед тем, как проверять права доступа, мы должны выяснить личность объекта, которому мы собираемся предоставить какие-либо права.

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

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

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

Локальная аутентификация

Прежде всего начнем с локальной аутентификации, когда пользователь хочет войти непосредственно на рабочую станцию, не входящую в домен. Что происходит после того, как пользователь ввел свой логин и пароль? Сразу после этого введенные данные передаются подсистеме локальной безопасности (LSA), которая сразу преобразует пароль в хэш, хэширование — это одностороннее криптографическое преобразование, делающее восстановление исходной последовательности невозможным. В открытом виде пароль нигде в системе не хранится и не фигурирует, пользователь — единственный кто его знает.

Затем служба LSA обращается к диспетчеру учетных записей безопасности (SAM) и сообщает ему имя пользователя. Диспетчер обращается в базу SAM и извлекает оттуда хэш пароля указанного пользователя, сгенерированный при создании учетной записи (или в процессе смены пароля).

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

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

LAN Manager (LM)

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

Что в этом плохого? Попробуем разобраться. Прежде всего разберемся, каким образом создается хэш пароля для работы с протоколом LM, не вдаваясь в подробности обратим ваше внимание на основные ограничения:

• Пароль регистронезависимый и приводится к верхнему регистру.
• Длина пароля — 14 символов, более короткие пароли дополняются при создании хэша нулями.
• Пароль делится пополам и для каждой части создается свой хэш по алгоритму DES.

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

А теперь самое интересное, LM-хэш, в целях совместимости, создается при вводе пароля и хранится в системах по Windows XP включительно. Это делает возможной атаку, когда системе целенаправленно присылают LM-запрос и она его обрабатывает. Избежать создания LM-хэша можно изменив политику безопасности или используя пароли длиннее 14 символов. В системах, начиная с Windows Vista и Server 2008, LM-хэш по умолчанию не создается.

NT LAN Manager (NTLM)

Новый протокол аутентификации появился в Windows NT и благополучно, с некоторыми изменениями, дожил до наших дней. А до появления Kerberos в Windows 2000 был единственным протоколом аутентификации в домене NT.

Сегодня протокол NTLM, точнее его более современная версия NTLMv2, применяются для аутентификации компьютеров рабочих групп, в доменных сетях Active Directory по умолчанию применяется Kerberos, однако если одна из сторон не может применить этот протокол, то по согласованию могут быть использованы NTLMv2, NTLM и даже LM.

Принцип работы NTLM имеет много общего с LM и эти протоколы обратно совместимы, но есть и существенные отличия. NT-хэш формируется на основе пароля длиной до 128 символов по алгоритму MD4, пароль регистрозависимый и может содержать не только ACSII символы, но и Unicode, что существенно повышает его стойкость по сравнению с LM.

Как происходит работа по протоколу NTLM? Рассмотрим следующую схему:

Допустим локальный компьютер хочет получить доступ к некоторому файловому ресурсу на другом ПК, который мы будем считать сервером, при этом совсем не обязательно наличие на этом ПК северной ОС или серверных ролей. С точки зрения протокола NTLM клиент это тот, кто обращается, сервер — к кому обращаются.

Чтобы получить доступ к ресурсу клиент направляет серверу запрос с именем пользователя. В ответ сервер передает ему случайное число, называемое запросом сервера. Клиент в свою очередь шифрует данный запрос по алгоритму DES, используя в качестве ключа NT-хэш пароля, однако, несмотря на то, что NT-хэш 128-битный, в силу технических ограничений используется 40 или 56 битный ключ (хеш делится на три части и каждая часть шифрует запрос сервера отдельно).

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

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

В случае получения доступа к третьим ресурсам схема также немного изменяется:

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

Как видим, хэш пароля ни при каких обстоятельствах по сети не передается. Хэш введенного пароля хранит служба LSA, хэши паролей пользователей хранятся либо в локальных хранилищах SAM, либо в хранилищах контроллера домена.

Но несмотря на это, протокол NTLM на сегодняшний день считаться защищенным не может. Слабое шифрование делает возможным достаточно быстро восстановить хэш пароля, а если использовался не только NTLM, а еще и LM-ответ, то и восстановить пароль.

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

NTLMv2

Осознавая, что протокол NTLM не соответствует современным требованиям безопасности, с выходом Windows 2000 Microsoft представила вторую версию протокола NTLMv2, который был серьезно доработан в плане улучшений криптографической стойкости и противодействия распространенным типам атак. Начиная с Windows 7 / Server 2008 R2 использование протоколов NTLM и LM по умолчанию выключено.

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

Как и в NTLM, клиент при обращении к серверу сообщает ему имя пользователя и имя домена, в ответ сервер передает ему случайное число — запрос сервера. В ответ клиент генерирует также случайное число, куда, кроме прочего, добавляется метка времени, которое называется запрос клиента. Наличие метки времени позволяет избежать ситуации, когда атакующий первоначально накапливает перехваченные данные, а потом с их помощью осуществляет атаку.

Запрос сервера объединяется с запросом клиента и от этой последовательности вычисляется HMAC-MD5 хэш. После чего от данного хэша берется еще один HMAC-MD5 хэш, ключом в котором выступает NT-хэш пароля пользователя. Получившийся результат называется NTLMv2-ответом и вместе с запросом клиента пересылается серверу.

Криптостойкость данного алгоритма является актуальной и на сегодняшний день, известно только два случая взлома данного хэша, один из них произведен компанией Symantec в исследовательских целях. Можно с уверенностью сказать, что в настоящий момент нет массовых инструментов для атак на NTLMv2, в отличие от NTLM, взломать который может любой вдумчиво прочитавший инструкцию школьник.

Сервер, получив NTLMv2-ответ и запрос клиента, объединяет последний с запросом сервера и также вычисляет HMAC-MD5 хэш, затем передает его вместе с ответом контроллеру домена. Тот извлекает из хранилища сохраненный хэш пароля пользователя и производит вычисления над HMAC-MD5 хешем запросов сервера и клиента, сравнивая получившийся результат с переданным ему NTLMv2-ответом. В случае совпадения серверу возвращается ответ об успешной аутентификации.

При этом, как вы могли заметить, NTLMv2, также, как и его предшественник, не осуществляет взаимную проверку подлинности, хотя в некоторых материалах в сети это указывается.

Настройки безопасности

Теперь, когда вы имеете представление о работе протоколов аутентификации самое время поговорить о настройках безопасности. NTLMv2 вполне безопасный протокол, но если система настроена неправильно, то злоумышленник может послать NTLM или LM запрос и получить соответствующий ответ, который позволит успешно осуществить атаку.

За выбор протокола аутентификации отвечает локальная или групповая политика. Откроем редактор политик и перейдем в Конфигурация компьютера — Конфигурация Windows — Политики безопасности — Локальные политики — Параметры безопасности, в этом разделе найдем политику Сетевая безопасность: уровень проверки подлинности LAN Manager.

В этом же разделе находится политика Сетевая безопасность: не хранить хэш-значения LAN Manager при следующей смене пароля, которая запрещает создание LM-хэша, по умолчанию активна начиная с Vista / Server 2008.

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

Эти же значения можно задать через реестр, что удобно в сетях уровня рабочей группы, для этого в разделе HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lsa нужно создать параметр DWORD с именем LmCompatibilityLevel, который может принимать значения от 0 до 5. Рассмотрим их подробнее:

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

После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Когда реализованные в Active Directory (AD) средства для работы с протоколом Kerberos дают сбой, выяснить причину неполадки бывает чрезвычайно трудно. 99% времени все работает нормально, так что наши возможности попрактиковаться в диагностике ограничены. Но когда все-таки необходимо решить какую-либо проблему, важно иметь четкое представление о технических особенностях протокола. Одним из самых сложных настраиваемых компонентов технологии Kerberos является концепция делегирования

.

Вкратце делегирование сводится к следующему. Пользователь обращается к тому или иному приложению, а затем это приложение обращается к другой службе от имени (в контексте) данного пользователя. Характерный пример — это веб-сайт, обращающийся к базе данных SQL Server. Можно представить себе ситуацию, когда любое обращение к базе данных выполняется всякий раз в контексте учетной записи той или иной службы. На самом же деле все происходит иначе: каждый запрос к базе данных осуществляется в контексте пользователя, обратившегося к веб-узлу. Дополнительную информацию о работе с протоколом Kerberos в каталоге AD можно найти в статье «Kerberos в Active Directory», опубликованной в Windows IT Pro/RE № 11 за 2010 год. В рамках данной статьи мы будем исходить из того, что, если не указано иное, наш лес AD функционирует под управлением системы Windows Server 2003 или более поздней, а серверы приложений — под управлением системы Server 2003 или более новых версий. В системе Server 2003 в средства Kerberos, реализованные в AD, внесено множество усовершенствований.

Делегирование аутентификации по протоколу Kerberos

Недавно на одной из конференций я выступал с докладом по проблемам делегирования аутентификации по протоколу Kerberos. Я попросил поднять руки тех слушателей, которым хотя бы раз доводилось настраивать процесс делегирования Kerberos. Таких оказалось довольно много. Тогда я попросил опустить руки тех, кому не удалось правильно выполнить настройку с первой же попытки. Поднятыми остались всего две-три руки. К сожалению, документации по вопросам делегирования и ограниченного делегирования существует немного. Между тем настройка делегирования — это жизненно важный компонент многих корпоративных приложений.

Как уже отмечалось, самый типичный пример делегирования сводится к следующему. Пользователь обращается к приложению (обычно речь идет о веб-приложении), которое затем обращается к некоему ресурсу, например к базе данных SQL Server. Чтобы получить соединение с базой данных, приложение должно представить учетные данные. Часто соединение устанавливается с использованием выделенной учетной записи службы с правом чтения и записи всех необходимых данных внутри базы данных, как показано на рисунке 1. После этого приложение становится ответственным за контроль над элементами управления доступом непосредственно к данным, поскольку учетная запись службы имеет доступ ко всем объектам.

Рисунок 1. Обращение к данным с использованием учетной записи службы

Еще одна возможность заключается в том, чтобы управлять данными с помощью реализованных в SQL Server собственных средств управления доступом на уровне пользователя или группы. Элементы управления будут работать эффективно лишь в том случае, если приложение установит соединение в контексте пользователя, обращающегося к приложению, как показано на рисунке 2. Процесс, в ходе которого устанавливается такое соединение, именуется делегированием Kerberos или, чаще, ограниченным делегированием Kerberos.

Чтобы обратиться к системе SQL Server на рисунке 2, веб-сервер должен получить билет службы для службы SQL Server. Этот билет службы должен быть сгенерирован для пользователя, обращающегося к веб-приложению (скажем, для User 1), но не для учетной записи службы веб-сервера. Таким образом, веб-сервер представляет билет службы пользователя User 1, который использовался для доступа к сайту (скажем, www.contoso.com), центру распространения ключей Key Distribution Center (KDC) и запрашивает билет службы системы SQL Server. KDC оценивает настройки делегирования в AD для данного веб-сервера; если имеется разрешение на делегирование полномочий системе SQL Server, KDC принимает представленный билет службы в качестве доказательства того, что полномочия данного пользователя проверены, и возвращает новый билет службы для обращения данного пользователя к системе SQL Server. Этот обмен информацией представлен на рисунке 3.

Рисунок 2. Обращение к данным с использованием делегирования Kerberos

Рисунок 3. Обмен сообщениями при делегировании Kerberos

Пока мы исходили из следующей посылки: делегирование может осуществляться, как показано на рисунке 3, без предварительной настройки в AD, но эта посылка неверна, и вот почему. Если бы любая служба могла просто делегировать проверку подлинности любой другой службе, тогда злоумышленники получили бы возможность обманом заставить какого-либо пользователя пройти проверку подлинности в их службе и имели бы доступ ко всем службам сети, доступным для незадачливого пользователя.

В соответствии с принимаемой по умолчанию настройкой вкладки Delegation, которая доступна в оснастке Active Directory Users and Computers консоли Microsoft Management Console (MMC), система не доверяет пользователю в вопросах, касающихся делегирования. Это означает, что службы, выполняемые в контексте соответствующей учетной записи, не могут делегировать проверку подлинности. В системе Windows 2000 Server имеется настройка Trust this user for delegation to any service (Kerberos only), которую можно увидеть на экране 1. Если эта функция включена, служба может от имени пользователя запросить билет службы для доступа к любой службе сети. Пользоваться рассматриваемой функцией небезопасно, поэтому старайтесь по возможности не применять ее.

Экран 1. Активизация функции ограниченного делегирования

Предпочтительная настройка, представленная на экране 1, предусматривает использование ограниченного делегирования с помощью настройки Trust this user for delegation to specific services only. Эта настройка предписывает учетной записи службы (или компьютера) запрашивать делегирование проверки подлинности только службами, указанными в списке. В рассматриваемом нами случае билеты службы могут запрашиваться только от имени других пользователей для службы SQL Server на Web-сайте sql.contoso.com. Нажав кнопку Add, вы должны отыскать пользователя (то есть учетную запись службы) или компьютер, являющийся хостом службы, для доступа к которой хотите санкционировать делегирование. В данном случае я выбрал учетную запись службы SQL Server. Как показано на экране 2, вы увидите список имен участников служб Service Principal Name (SPN), определенный выделенному пользователю или компьютеру, где вы можете выбрать службы, для доступа к которым будет выполняться аутентификация.

Экран 2. Выбор служб для осуществления делегирования

Смена протокола

Смена протокола — добавленная функция системы AD Kerberos, которую корпорация Microsoft реализовала в версии Windows Server 2003. Пока что при рассмотрении нашего примера в ситуациях, когда возникала необходимость обращения приложения c www.contoso.com к SQL Server в контексте текущего пользователя, веб-сервер предъявлял веб-приложению билет службы для данного пользователя, обеспечивающий получение билета службы системы SQL Server, как показано на рисунке 3. Такой сценарий возможен лишь в том случае, если пользователь удостоверяет свою подлинность сайту по протоколу Kerberos. Если же пользователь выполняет процедуру аутентификации в ходе регистрации на основе форм с применением другого протокола, скажем NTLM, или, может быть, иного механизма, такого как маркер RSA SecurID, веб-приложение не может получить билет службы от имени пользователя, ибо протокол Kerberos в подобной ситуации не используется.

Чтобы задействовать этот сценарий, пользователь может изменить настройки учетной записи службы или учетной записи компьютера для выполнения смены протокола; при этом учетная запись службы или компьютера сможет запросить билет службы для той или иной службы, не получая билет службы от пользователя. Вместо того чтобы представить веб-сайту билет службы для данного пользователя, учетная запись службы представляет собственный билет на получение билета Ticket-Granting Ticket (TGT) и запрашивает билет службы для себя от имени пользователя. На рисунке 4 показан последовательный ряд запросов и ответов Kerberos в момент выполнения смены протокола.

Рисунок 4. Обмен сообщениями при смене протокола

Важно отметить, что вследствие уязвимости смены протокола данная служба доступна лишь в сочетании с ограниченным делегированием Kerberos. Чтобы настроить смену протокола, необходимо в процессе включения функции ограниченного делегирования вместо настройки Use Kerberos only выбрать настройку Use any authentication protocol. Уязвимость данной конфигурации связана с тем, что пользователь предоставляет приложению возможность отрапортовать центру распространения ключей об успешной проверке полномочий пользователя вне зависимости от того, была ли такая проверка выполнена на самом деле. Для ограничения связанного с этим риска необходимо настроить службы, которым приложение может сообщить об успешной проверке подлинности, в виде билета службы.

Чтобы гарантировать успешное выполнение обмена, представленного на рисунке 4, необходимо наряду с указанием настроек учетной записи службы выполнить ряд дополнительных предварительных условий. Во первых, учетная запись службы должна иметь возможность получать данные о членстве в группах пользователя, для которого она пытается получить билет службы. Эта возможность предоставляется через членство в группе AD Windows Authorization Access. Данной группе делегируется доступ с правом чтения к атрибуту AD tokenGroupsGlobalAndUniversal.

Далее для фактического выполнения процедуры делегированной аутентификации учетной записи службы требуются привилегии безопасности Act as Part of the Operating System (SeTcbPrivilege) и Impersonate a Client After Authentication (SeImpersonatePrivilege). Особой уязвимостью отличается привилегия Act as Part of the Operating System; по умолчанию она предоставляется только учетной записи SYSTEM. Если это право будет предоставлено учетной записи службы, выполняющей веб-приложение, и если это приложение будет скомпрометировано, злоумышленник получит полный доступ к серверу. Обычно в приложениях, которые активно используют смену протокола, например в средствах обеспечения процедуры однократной регистрации (SSO), предусмотрена специальная служба, которая выполняется с использованием учетной записи SYSTEM и осуществляет необходимые вызовы по протоколу Kerberos от имени веб-приложения.

Диагностика Kerberos

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

Для мониторинга функционирования Kerberos, а также для диагностики часто используются две утилиты — Klist и Kerbtray. Klist — утилита командной строки, встроенная в Windows. Этот инструмент позволяет видеть все билеты, кэшированные в данный момент для сеанса, а также просматривать билет на получение билета TGT. Чтобы просмотреть кэшированные билеты, достаточно запустить программу klist; для просмотра TGT нужно запустить klist tgt. При необходимости очистки кэшированных билетов (а также TGT) выполните команду klist purge. Очистка билетов дает возможность, не выходя из системы, получить новый TGT с обновленными данными по членству в группах.

Утилита Kerbtray входит в набор ресурсов Microsoft Windows Server 2003 Resource Kit, а также в набор Microsoft Windows 2000 Server Resource Kit. Kerbtray представляет те же данные, что и Klist; однако Kerbtray выполняется в системной панели задач и отображает данные в графическом, а не в текстовом представлении.

При работе с протоколом Kerberos администраторам AD чаще всего приходится сталкиваться с такой проблемой, как дубликаты имен участников служб SPN. Эти имена используются для идентификации служб, которые выполняются в сети. Когда пользователь запрашивает билет службы для доступа к той или иной службе, этот пользователь указывает в запросе SPN службы, к которой хочет обратиться. Далее центр распространения ключей осуществляет поиск учетной записи, которая содержит указанное имя SPN и зашифровывает билет с помощью секрета данной учетной записи. Если же одно и то же имя SPN содержит не одна, а большее число учетных записей, центр распространения ключей не может надлежащим образом зашифровать билет, поскольку имеется более одного секрета, которые могут быть использованы для шифрования билета.

Дубликаты имен SPN часто появляются в ситуациях, когда системы объединяются в одном домене, а затем присоединяются к другому домену леса, оставляя в старом домене «висячую» учетную запись компьютера. Дубликаты могут появляться и в том случае, когда имя SPN вручную вводится в несколько учетных записей пользователей или компьютеров. Когда центр распространения ключей получает запрос на билет службы и находит несколько объектов, содержащих заданное имя SPN, в системный журнал контроллера домена записывается событие, подобное тому, которое представлено на экране 3.

Экран 3. Событие Duplicate SPN

Существует целый ряд различных способов поиска и удаления повторяющихся в лесу имен SPN. В статье Microsoft «Event ID 11 in the System log of domain controllers» (support.microsoft.com/kb/321044) рассматривается несколько методов обработки события, показанного на экране 3.

Огромное значение для обеспечения надлежащего функционирования механизма Kerberos имеет процедура синхронизации времени. Если часы клиента, сервера или центра распространения ключей не синхронизированы, Kerberos не будет функционировать корректно. В соответствии со спецификацией Kerberos для защиты различных сообщений, от которых зависит работа протокола, используются отметки времени; когда часы в сети показывают разное время, билеты ошибочно аннулируются. По умолчанию AD позволяет часам уходить вперед или назад не более чем на пять минут.

Kerberos в значительной степени полагается на службу имен доменов. Имена участников службы задаются в контексте имени службы DNS (например, http/www.contoso.com). Если вы зайдете на сайт www.contoso.com через URL, отличный от www.contoso.com, протокол Kerberos не будет функционировать корректно. В случаях когда требуется обеспечить возможность просмотра приложений с использованием имени их хоста, часто прибегают к такому решению: для имени хоста (скажем, http/www) определяют также имя участника службы (SPN), с тем чтобы пользователям не приходилось вводить полное доменное имя Fully Qualified Domain Name (FQDN) соответствующей службы. Надо отметить, что метод Kerberos неприменим, если доступ к службе осуществляется по IP-адресу. В таких случаях аутентификация обычно проводится по протоколу NTLM.

Когда осуществляется возврат к средствам аутентификации на базе NTLM, приложения, реализующие делегирование Kerberos, но не поддерживающие смену протокола, дают сбой. Иногда NTLM используется не потому, что возникла проблема с использованием протокола Kerberos, а вследствие ошибки в настройке либо сервера, либо браузера. Для диагностики подобных сбоев можно применять, например, бесплатно распространяемую утилиту Fiddler. Ее можно загрузить с сайта www.fiddler2.com.

Немало хлопот доставляет и чрезмерное разрастание маркеров (token bloat). Спецификация Kerberos предусматривает хранение данных о членстве пользователя в группах (наряду с прочими сведениями) в разделе PAC (Privilege Attribute Certificate) предоставленного данному пользователю билета на получение билета, а значит, и в билетах служб. В статье Microsoft «New resolution for problems with Kerberos authentication when users belong to many groups» (support.microsoft.com/kb/327825) рассказывается о том, как осуществляется корректировка параметра реестра Max-TokenSize и как выполняется расчет вклада каждой группы в общий размер маркера. Но надо сказать, что, хотя с помощью корректировки можно на время снять данную проблему, лучше пойти по другому пути — пересмотреть стратегию членства в группах, принятую в вашей организации.

Простые решения

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

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP. Автор книги «Active Directory», ведет блог www.briandesmond.com

Ловушка для хакеров: ложная учетная запись администратора домена

Впроцессе создания домена Active Directory (AD) автоматически формируется учетная запись администратора для этого домена. Эта учетная запись, на которую возлагаются обязанности по управлению всеми объектами в домене — очевидная мишень для злоумышленников. Безопасность домена можно повысить, изменив имя учетной записи администратора и заменив подлинную учетную запись ложной. Сделать это просто.

1. Смените имя учетной записи Administrator домена на какое-нибудь другое, например DOM-ADMIN. Изменение имени не повлияет на разрешения и права, которыми учетная запись наделяется по умолчанию.
2. Создайте неадминистративную учетную запись, назовите ее Administrator и отключите эту ложную учетную запись.
3. Назначьте аудит неудачных событий безопасности для созданной ложной учетной записи.
4. Периодически проверяйте журналы событий в поисках событий, связанных с попытками нарушения защиты. Наиболее вероятные причины этих событий:

• попытки злоумышленников проникнуть в домен (не зная нового имени, они будут использовать стандартное имя Administrator);
• неправильно настроенные приложения; если приложение (например, программа резервного копирования) настроено на использование учетной записи Administrator, то после смены имени в его работе начнутся сбои и будут формироваться события безопасности.

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

Обратите внимание, что каждый член домена, сервер и клиент имеет административную учетную запись, поэтому формирование ложной учетной записи Administrator в домене не защитит серверы и клиентские компьютеры. Этот недостаток можно преодолеть, создав ложные локальные административные учетные записи.

Пол Лемонидис (paul_lemonidis@hotmail.com) — специалист по системам сообщений с 20 летним опытом работы из Tower Hamlets Council в Лондоне. Поддерживает почтовую организацию Exchange Server с 7000 почтовых ящиков

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

Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.

Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.

Установка и настройка сервера с ролью Network Policy Server

Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.

Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).

После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:

1. RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
2. Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
3. Network Polices – правила аутентификации

Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:

• Friendly Name:sw-HP-5400-1
• Address (IP or DNS): 10.10.10.2
• Shared secret (пароль/секретный ключ): пароль можно указать вручную (он должен быть достаточно сложным), либо сгенерировать с помощью специальной кнопки (сгенерированный пароль необходимо скопировать, т.к. в дальнейшем его придется указать на сетевом устройстве).

Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.

Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.

В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.

Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.

Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).

В окне Configure Settings изменим значение атрибута Service-Type на Administrative.

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

И, напоследок, переместим новую политику на первое место в списке политик.

Настройка сетевого оборудования для работы с сервером RADUIS

Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).

aaa authentication console enable radius local

aaa authentication telnet login radius local

aaa authentication telnet enable radius local

aaa authentication ssh login radius local

aaa authentication ssh enable radius local

aaa authentication login privilege-mode

radius-server key YOUR-SECRET-KEY

radius-server host 10.10.10.44 YOUR-SECRET-KEY auth-port 1645 acct-port 1646

radius-server host 10.10.10.44 auth-port 1645

radius-server host 10.10.10.44 acct-port 1646

aaa authentication telnet login radius local

aaa authentication telnet enable radius local

Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!

Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:

Примечание. В зависимости от модели сетевого оборудования Cisco и версии IOS конфигурация может несколько отличаться.

aaa new-model
radius-server host 10.10.10.44 auth-port 1645 acct-port 1646 key YOUR-SECRET-KEY
aaa authentication login default group radius local
aaa authorization exec default group radius local
ip radius source-interface Vlan421
line con 0
line vty 0 4
line vty 5 15

Примечание. В такой конфигурации для аутентификации сначала используется сервер RADIUS, а если он не доступен – локальная учетная запись.

Для Cisco ASA конфигурация будет выглядеть так:

aaa-server RADIUS protocol radius
aaa-server RADIUS host 10.10.10.44 key YOUR-SECRET-KEY
radius-common-pw YOUR-SECRET-KEY
aaa authentication telnet console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL

Contents:

• Basic Access Check
• The Security Descriptor, DACL & SACL
• Integrity Level Check / Mandatory Integrity Control (MIC)
• Privileges
• UAC
• UAC for the RID-500er local Admin
• Disabling UAC For Non-RID-500er Admins
• UAC and Remote Access
• UAC And Pass-the-Hash
• Access Tokens
• Impersonation
• Privilege Escalation With Identification Tokens
• Privilege Escalation By Leaky Tokens

Compared to Linux, the Window’s authorization process is quite complex and quite a few actors and objects are involved in this process. As a result, there a lot of terms and acronyms that must be known in order to understand and follow up on the topic. To get an idea of what is covered in this guide take a look on this overview of terms and acronyms:

Facing this wall of acronyms, i’d say the best to get into this complex environment is to dive right in and cross reference all new terms.
For all of the following (and in general) be aware that there is a Windows Security Glossary that you could use to look up any acronym or term used in the following.

Basic Access Check

Starting with the simplest scenario: You log onto your Windows system and want to open a file. Who decides if you get access and how is this decision made?
As a reference recap how this decision is made on Unix systems. On Unix systems your user has a user- & group-ID and the access target (the file in this scenario) has an associated list of access permissions that could look like this:

-rwxr-xr-- 1 root root 2048 Jun 13 10:00 file.txt

The Unix OS checks these file permissions, figures that everyone got read access rights and grants the logged in Unix user read access. Most of the Unix authorisation decisions can be broken down to this very simple access check.

Now let’s dive into the Windows World:
Let’s start simple: When a user logs into his Windows machine (regardless if that is a local or a domain joined user), an Access Token is created for that user. Precisely that means this access token is created for that user’s logon thread.
When that logged on user tries to open a file, an access request is generated that specifies what the user wants to do with that file (access right). In our case the user simply wants to read a file, which maps to the GENERIC_READ access right. There are a set of different access rights, which at the end of the day are all just bitmasks representing numbers that serve as a global reference to have a clear definition of what the user requests to do. The most important access rights are the Generic Access Rights and the so called Standard Access Rights.
The user’s access request is taken on by a Windows component called the Security Reference Monitor (SRM), which takes on the requested access right along with the user’s Access Token and compares these bits of information against the defined access permissions for the requested file, which are composed in a structure called Security Descriptor.
Important to note here: Each Securable Object, which include files, directories, registry keys and many other things, has a Security Descriptor.

Okay let’s break that down in key »Take aways«::

• Each user logon thread has an access token
  (Read this as: Each user got assigned an access token)
• A required action, e.g. to open a file, is expressed in an Access Right, e.g. GENERIC_READ
• Each Securable Object has a Security Descriptor, which defines who can do what with that object.
• The Security Reference Monitor (SRM) is the software component in charge to evaluate if a certain process should be granted access to the requested object for the requested access right.

Now that the basic concept of access checks in the Windows world has been introduced, let’s dig deeper into the individual components.

The Security Descriptor, DACL & SACL

This section will bring light on the Owner- and the DACL-Check shown in the figure above.

The most basic part here is the Owner and Group field, which are expressed by a Secure Identifier (SID). In the Windows world a SID is just a unique string to identify a security principal, e.g. a user, a group, etc. The SID consists of three blocks:

• The first part — always beginning with an ‘S’ — describes the group, e.g. Domain Everyone (S-1-1-0), Anonymous (S-1-5-7), Authenticated Users (S-1-5-11), which can be looked up in the register for Well-known SIDs.
• The second part is a unique domain ID (also present in each default WORKGROUP) (S-1-5-21), e.g. S-1-5-21-2884053423-3431565070-78458365-….
• The last part is called the relative ID (RID), which describes a user group inside a security group, e.g. the group of builtin Administrator group (S-1-5-32—544) or the builtin Guests group (S-1-5-32—546) or the famous default Admin account — by me often referred to as RID-500 Admin — (S-1-5-21-2884053423-3431565070-78458365—500). Note how the first two groups are in the same security group (S-1-5-32-…), while the RID-500 admin is in the domain security group.

Okay now back to our example from above: The Owner is set to the SID of S-1-5-21-…..-1001, which is the unique value for my current user and the group is set to the SID of S-1-5-21-…-513, which is the domain users group.
You can look up these SIDs in the register for Well-known SIDs

Apart from the owner and group of the explorer.exe process, the above shown Security Descriptor also contains two lists, the Discretionary Access Control List (DACL) and the System Access Control List (SACL):
The DACL is a list controlled by the owner of the Security Descriptor, that specifies the access particular users or groups can have on the object.
The SACL is a list controlled by system administrators, which holds two types of control entries:

• The SACL holds the MANDATORY_INTEGRITY_LABEL (more on this later); and
• The SACL holds control entries used for the generation of audit messages (which we ignore for now)

For the SACL just keep in mind that the MANDATORY_INTEGRITY_LABEL is stored in here (we ignore the rest for now…).
The DACL is the important control list used for the authorization process. Review the screenshot above and see that the presented DACL actually contains three Access Control Entries (ACEs). For each of the three ACEs the following important fields are set:

• SID: The SID defines the Security Principal (a user or group) to which the ACE applies.
  S-1-5-21-…..-1001 references to one specific domain user.
  S-1-5-18 references the local System account.
• Mask: The access mask is a numeric value, which resembles a combination (addition) of multiple Access Rights, e.g. GENERIC_READ. The access mask is a data structure described in the Microsoft Docs here.
• AceType: The AceType defines whether access should be allowed or denied for the given security principal (SID) and based on the given access mask.
  In the example above three ACEs with AceType ACCESS_ALLOWED_ACE_TYPE are given, which means that if the Security Reference Monitor (SCM) finds a matching access mask for the requesting user in any of these ACEs access will be granted.

For this part the important »Take away«: is:
The SCM will review the Security Descriptor of the requested object and iterate over each ACE in the Security Descriptor’s DACL and check whether the requesting user — identified by it’s SID and requested access right (e.g. GENERIC_READ) match with an Access Mask inside of an ACE. If a match is found the AceType of that ACE will determine if access is granted or denied.

A side note on empty DACLs:
If a DACL of a Security Descriptor is set to NULL, aka the Security Descriptor has no DACL, than full access is granted to everyone.
If the DACL of a Security Descriptor is empty, aka a DACL exists, but does not contain any ACEs than no access is granted to that object.

The last bit of information that is missing is the identity of the requesting user. The SRM gets the identity of the requesting user from the given user access token. Insights of how this token looks like will be given later, for now it’s just important to know that this token contains the SID of the requesting user, as well as the SID of the user’s groups.

Okay and now let’s put in the full picture for the SeAccessCheck:
After the Integrity Level-Check (IL-Check), which will be described in the following section, the Security Reference Monitor (SRM) queries the Security Descriptor of the requested object for the following information:

• Who is the owner of the requested object?
  → If the requesting user is the owner of the requested object: Grant Access
• If the requesting user is not the owner, iterate over all ACEs in the DACL of the Security Descriptor and determine:
  – Does the ACE apply for the requesting user by comparing the ACE SID to the user SID and his/her group SIDs ?
  – Does the access mask contain the requested access right, e.g. does the access mask contain the GENERIC_READ access right ?
  – Does the access type is set to allow access or is it set to deny access?
• If any ACCESS_DENIED_ACE_TYPE matches the user and requested access right: Deny Access
• If no ACCESS_DENIED_ACE_TYPE but a ACCESS_ALLOWED_ACE_TYPE matches the user and requested access right: Grant Access

Next to the Owner and DACL checks there is only one element missing to understand the SeAccessCheck, which is the Integrity Level Check (IL-Check). So let’s dive into that.

Integrity Level Check / Mandatory Integrity Control (MIC)

This section will bring light on the Integrity Level Check shown in the figure above.

The Integrity Level check is meant to enforce another Windows control layer, called Mandatory Integrity Control (MIC).

Mandatory Integrity Control (MIC) provides a mechanism for controlling access to securable objects. This mechanism is in addition to discretionary access control and evaluates access before access checks against an object’s discretionary access control list (DACL) are evaluated.
Source: Mandatory Integrity Control

The first question that should arise in your head now is:
Why the f** do we need MIC? We got DACL checks, which are basically the same checks that are done in Unix systems – shouldn’t that be enough?*

The answer to this question is: Yes the DACL checks are the core of the authorization checks and the vast majority of all access request will be granted or denied based on the DACL checks. MIC is just another layer added by Microsoft in Windows Vista alongside with User Access Control (UAC) to get more fine grained control and to prevent compromised processes from accessing sensitive resources.
This is a very abstract answer to a simple question, but the following introduction to MIC and UAC will hopefully shed some more light on this.

Each Securable Object got a MANDATORY_INTEGRITY_LABEL set in it’s SACL. This label assigns one of four possible Integrity Levels (IL) to the object (as defined in Windows Integrity Mechanism Design):

• Low (SECURITY_MANDATORY_LOW_RID 0x00001000)
• Medium (SECURITY_MANDATORY_MEDIUM_RID 0x00002000)
• High (SECURITY_MANDATORY_HIGH_RID 0X00003000)
• System (SECURITY_MANDATORY_SYSTEM_RID 0x00004000)

These Integrity Levels label the degree of ‘security protection’ that has been assigned to a Securable Object.
»By default all objects are assigned with a Medium Integrity Label.

As an example refer back to the previous screenshot of the Security Descriptor, notice that the Security Descriptor of this object (the explorer.exe process) got the following MANDATORY_INTEGRITY_LABEL: SID: S-1-16-8192
A quick look up to the Well-known SIDs Register reveals that this SID describes the ‘Medium Mandatory Level’ (default for all objects).

»Take away«:
The whole story of integrity labels is to prevent lower level integrity processes from accessing higher level integrity objects.

Another example: When starting the Internet Explorer, a low Integrity Level IE process will be spawned (see screenshot below). This low level IE process is the process that is used by the user for surfing the internet.
If this process is compromised, e.g. by exploiting an IE/Flash/etc. vulnerability, the process would not be able to access a user’s documents, because these were created with the default medium Integrity Level label (and the IE process is running with low integrity).

This is the point where the Integrity Levels checks should begin to make sense. Imagine the compromised IE scenario without MIC. The IE process has been launched by the logged in user and therefore is owned by the logged in user. The DACL-check would therefore grant the compromised IE process access to the user’s resources.
By enforcing an IL-Check, access to user resources is denied to the compromised IE process.

So am I saying that access is generally denied when a process with a lower Integrity Level tries to access a resource with a higher Integrity Level? Of course not – why should it be that simple…

During the Integrity Level check, the SRM compares the Integrity Level of the requesting process with the Integrity Level of the requested object and decides to go to the DACL check or denies access based on the Integrity Level Policy defined for that object.
The Integrity Level Policy of an object is based on the following three defined states (as defined in the SYSTEM_MANDATORY_LABEL_ACE Structure):

• SYSTEM_MANDATORY_LABEL_NO_WRITE_UP ( 0x1 )
• SYSTEM_MANDATORY_LABEL_NO_READ_UP ( 0x2 )
• SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP ( 0x4 )

Once again refer back to the Security Descriptor of the running explorer.exe given in the previous section. Notice that the Access Mask of the SACL ACE SYSTEM_MANDATORY_LABEL_ACE_TYPE is set to 0x00000003, meaning that this integrity policy denies READ and WRITE access attempts from processes with a lower Integrity Level than Medium, which is the integrity level of that object.

Privileges

The best way to introduce Privileges is with the official MSDN explanation:

A privilege is the right of an account, such as a user or group account, to perform various system-related operations on the local computer, such as shutting down the system, loading device drivers, or changing the system time. Privileges differ from access rights in two ways:

• Privileges control access to system resources and system-related tasks, whereas access rights control access to securable objects.
• A system administrator assigns privileges to user and group accounts, whereas the system grants or denies access to a securable object based on the access rights granted in the ACEs in the object’s DACL.

Each system has an account database that stores the privileges held by user and group accounts. When a user logs on, the system produces an access token that contains a list of the user’s privileges, including those granted to the user or to groups to which the user belongs. Note that the privileges apply only to the local computer; A domain account can have different privileges on different computers.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/aa379306(v=vs.85).aspx

To enumerate what privileges your user has, simply run the following command and find the list of privileges at the end of the outputted result

C:> whoami /all

Notice how the privileges expand once you run that command in a cmd started with “Run as administrator”:

To cross check or look up the privileges you got you can use the following MSDN resource:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspx

UAC

The sole purpose of User Access Control (UAC) is to have more fine-grained control over administrative execution and to prevent administrative users to use their admin execution rights when it’s not needed.

Recall from the introduction that by logging into your Windows computer your logon thread is assigned a user access token and all child processes launched by that user will inherit this token. For non-admin users this is a Medium Integrity token with your default privileges.
Prior to Windows Vista admin users got a high integrity token with all administrative privileges and each child processes launched would inherit this token. This meant that all processes spawned by an admin user would run with high privileges even if the process would not need those high privileges (e.g. the explorer.exe started by an admin would run with a high integrity token and full admin privileges without needing those privileges). UAC was introduced to fix this.

»Note: All of the following explanations assume that UAC is enabled and the administrative user we’re talking about is not the local RID-500er administrator (we get to that special case afterwards)

Since UAC was introduced in Windows Vista, when an admin logs in two access tokens are created:

• A Full Admin Token, also often referred to as ‘Non-filtered Token’ or ‘Full Token’, with high Integrity Level (IL) and all administrative privileges
• A filtered admin token, also often referred to as ‘Standard Token’ or ‘Restriced Token’, with medium integrity level (IL) and reduced privileges

These two tokens are linked together in the kernel, so that an executing thread could access both tokens if needed.
Now if an admin user logs into his account and launches cmd.exe this process will be spawned using the filtered, medium integrity token (remember: UAC is enabled and the user is not the RID-500 administrator). Thereby high access privileges are not given to processes that do not need those.
But in case the administrator user needs to run a process with full admin privileges he can ask the operating system to elevate this processes privileges with his full admin token, this is the ‘Run as administrator’-button. This will cause the prominent ‘consent’ prompt to pop up (C:WindowsSystem32consent.exe) as shown in the screenshot below:

By accepting this consent prompt, the system will create the elevated process (in this case cmd.exe) with full admin privileges, as it can be seen in the screenshot below:

The cmd.exe process (note that conhost.exe is the child processes created by cmd.exe) launched by the administrator without elevating is shown on the left and the elevated cmd.exe by hitting ‘Run as administrator’ is shown on the right.
Also compare the Integrity Levels and Privileges of these processes to determine which is which.

UAC for the RID-500er local Admin

All of the explanations above are only true for local or domain administrators that are not the RID-500er local admin. Each installation of Windows comes with a local Administrator account (which is disabled by default), that can be identified by the Relative Identifier (RID) of 500 (SID: S-1-5-21-DomainID—500).

The Story for the RID-500 local admin is that this account is not enrolled in UAC by default.
That means that if you log in to your Windows computer with the RID-500er local admin account you will be assigned a high privileged full access token right away (and don’t get a ‘filtered’ medium integrity token). If you run cmd.exe (or anything else) with the RID-500 local admin, even without specifying ‘Run as administrator’, then the cmd.exe will spawn with full administrative privileges and a high Integrity Level (because your only got a full token that the cmd.exe process can inherit). If you hit ‘Run as administrator’ with your RID-500er local admin there will be no consent prompt.

The RID-500er admin is by default not enrolled in UAC, but can be enrolled by setting the following registry key to ‘1’:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemFilterAdministratorToken

As shown in the following screenshot the FilterAdminstratorToken has been set to ‘1’ in this instance, which enrolls the RID-500er Admin in UAC (and thereby all of the rules mentioned previously would also apply for this user).

Disabling UAC For Non-RID-500er Admins

So by default the RID-500er Admin is not enrolled in UAC, but all other admins (meaning local or domain users that are in the administrative group) are enrolled in UAC.
Now as the RID-500er admin user can be enrolled in UAC, also the Non-RID-500er admins can be dis-enrolled from UAC, by setting the LocalAccountTokenFilterPolicy to ‘1’.

HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemLocalAccountTokenFilterPolicy

This registry key is not set by default, so if this key is missing all non RID-500er accounts are enrolled in UAC:

UAC and Remote Access

All of the above is true for local access, meaning your user locally logs into the computer and executes processes. Now for remote access there is another addition to the story.

The short version: For remote access (e.g. via wmic) domain administrators are given a full high integrity access token, but local Non-RID-500er admins will only be given a medium integrity restricted token.

Terming it the Microsoft way:

1) Remote Access for Local Admins (Non-RID-500er):
Source: https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows

When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection … they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks. If the user wants to administer the workstation with a Security Account Manager (SAM) account, the user must interactively log on to the computer that is to be administered with Remote Assistance or Remote Desktop.

2) Remote Access for Domain Admins:
Source: https://support.microsoft.com/en-us/help/951016/description-of-user-account-control-and-remote-restrictions-in-windows

When a user with a domain user account logs on to a Windows Vista computer remotely, and the user is a member of the Administrators group, the domain user will run with a full administrator access token on the remote computer and UAC is disabled for the user on the remote computer for that session.

» This addition to UAC applies for remote administrative access, this does not affect Remote Desktop connections (which are considered as local logon).

UAC And Pass-the-Hash

Now comes the kicker.. Let’s face the following question:

Q: The following accounts try to establish a remote connection to a computer with default settings via a pth-attack (pass-the-hash) (using psexec or wmic).
Who will be able to establish a successful remote connection and why?

• a) The Local ‘Administrator’ — SID: S-1-5-21DomainID-500
• b) The Local user ‘LocalAdm’ who is member of the local Administrators Group (SID: S-1-5-32-544)
• c) The domain user ‘LabFrank’ who is a standard domain user without administrative privileges
• d) The domain user ‘LabBob’ who is a member of the domain Administrators group

Be aware that remote access requires to launch high privileges processes and consider that there is no way to remotely elevate privileges.

——– SPOILER / ANSWER ——–

Answer: a) & d) are correct

If you’re still interested i also recommend a read over harmj0y’s blog post on Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/

Bonus Kicker: As mentioned before, the UAC remote rules do not apply for remote desktop connections. Therefore, if your user is part of the remote desktop user group you could also go for pass-the-hash via remote desktop, as described here: https://www.kali.org/penetration-testing/passing-hash-remote-desktop/

Access Tokens

So far when talking about basic access checks or UAC, user ‘access tokens’ were introduced. This access tokens hold information about the current user and the user’s groups and are for example used by the Security Reference Monitor (SRM) to determine who is requesting access.

These tokens are of major relevance for the access check and also play a role for certain privilege escalation attacks. Therefore it’s worth getting a closer look at access tokens.

So to start with there are only two kinds of token:

• Primary Tokens, which are assigned to processes; and
• Impersonation Tokens that are assigned to threads

Two kinds of tokens, that’s it. ‘Filtered tokens’, ‘Restricted Tokens’, ‘Full Tokens’, ‘Admin Tokens’, or in general ‘Access Tokens’, are just names given to describe the token, but all of these are Impersonation Tokens.
Both, primary and impersonation tokens, consist of the following major fields:

• User SID: the SID of the user (impersonation token) or the SID of the user that created the process (Primary token)
• Group SIDs: Group SIDs of the corresponding user (User SID)
• Logon SID: Identifies the current logon session
• Privileges: List of Privileges the User (impersonation token or process has)
• Primary Group SID: identifies the primary group of the impersonated user (impersonation token), e.g. ‘Domain Users’
• Default DACL: The default DACL that the system uses when a user creates a securable object without specifying a security descriptor (comparable to Linux umask)
• Type: Information if token is primary or impersonation
• Impersonation Level: The degree (level) of allowed impersonation.
• Integrity Level: SID of integrity level
• …

In the right window a list of processes is shown. The token of one of the high integrity cmd.exe processes was opened and is shown in the left window. Notice that the token type is primary (because it’s a process) and the Integrity Level (IL) is set to High (because the cmd.exe process was started as elevated process by an admin).
Keep in mind that each process has a token assigned to it and this token is always a primary token.

Now let’s move to threads. Remember from the introduction that a user is assigned with a token once the user logs in and more precisely that means that the user’s logon thread is assigned with an impersonation token. A process can only have a primary token, but a thread can have an impersonation token as well as a primary token, in which case the impersonation token will always take primary over the primary token.
(… yep I know. Microsoft just sucks when it comes to naming things)

An example of an impersonation token is given below:

Notice that the token type now says ‘Impersonation’ and that now also the field ‘Impersonation Level’ is set to ‘Impersonation’. The impersonation level is an important field that influences if a token can be impersonated (more on this in the next section).

So far so good. The key take away here is that there are only two types of tokens for processes and threads.

Impersonation

The process of impersonation is quite important and frequently used in the Windows authorization process. To understand why impersonation is used we first must take a step back:

• a) Not every impersonation token can be used to carry out actions
• b) You need special privileges to be able to ‘impersonate’ a token (which technically means duplicate a token)

The first obstacle is that not every token is actually ‘valuable’. What that means is that each impersonation token got an attribute called Impersonation Level, that can have one of the following values:

• Anonymous Level — the server can impersonate the client, but the token does not contain any information about the client. Anonymous level is only supported for inter process communication (e.g. for named pipes). All other transports silently promote this to ‘Identification Level’
• Identification Level — This is the default. The server can obtain the identity of the client in order to do ACL checks. You can use that token to read information about the impersonated user or check the resources ACL, but you can’t actually access that resource (read/write/execute)
• Impersonate Level — The server can impersonate the security context of the client in order to access local resources. If the server is local, it can access local and network resources. If the server is remote it can only access resources on the same machine as the server.
• Delegate Level — The most powerful impersonation level. The server can impersonate the security context of the client to access local or remote resources.

So what you want is an Impersonation or Delegation Level impersonation token to be able to actually do anything (a little more on this in the next section).

The second obstacle in your way is that you need special privileges in order to be able to duplicate (impersonate) another token. That special privilege is TOKEN_DUPLICATE (as specified in Access Rights for Access-Token Objects).
The plot twist here is that if you do not hold this privilege, your request to duplicate a token is not denied, you still get a duplicated token, but one with a lower Impersonation Level.
The flow of duplicating/impersonating another token is shown below:

So at the end of the day you either hold the TOKEN_DUPLICATE privilege (or compromised a process that holds this) or you end up with an Identification Level token, which is supposedly of no use to an attacker because you can’t carry out any action with that.

At this point we’re almost done with tokens. The following sections are meant to get you into the mind-set of privilege escalation attacks based on tokens…

Privilege Escalation With Identification Tokens

The previous section describes that it is pretty easy to obtain an identification token.
To once more underline the fact that this is true, I activated the local administrator account on my windows machine and used Forshaw’s Token Viewer tool, to impersonate the Administrators Impersonation token (for more details check out His 2015 BlackHat Talk):

I ran this tool with a standard non admin user, and still got access to the Administrators token. It feels odd, but based on the access check for duplicate tokens that was presented in the previous section, this is all as it should be.
Notice that I only gained an Identification Impersonation Token.
There should be not much that I can do with that token, especially not carry out administrative tasks or access protected resources…

… unless of course some programmers forget to check the Impersonation Level of the token that is presented for authorization checks. James Forshaw found that this happened for some windows components, which resulted in CVE-2015-0002 as shown for example in this PoC.

I highly recommend to review James 2015 BlackHat Talk to understand the full impact and application of this vulnerability, but the basic story for this was that a certain Windows component made an access check to verify if the presented impersonation token belongs to an Administrator, but the component only checked the Impersonation type and the associated groups and totally ignored the impersonation level, which resulted in access for any user that could present a high integrity identification token with administrative groups… Amazing finding!

Privilege Escalation By Leaky Tokens

Another privilege escalation vulnerability that Forshaw found is what he termed ‘Leaky Tokens’. The basic idea of this kind of vulnerability is as follows:

Kernel code can access any kind of token to read and manipulate it. So what if you found a Windows kernel component that just gives out tokens, that it had accessed, back to the user ?!
It sounds a bit too obvious that this is flawed, but Forshaw found that an undocumented win32k system call existed that passed a previously used token right back to the user.

This flaw exited in the kernel code for the Windows clipboard (used for copy+paste). So once an administrator copied something (e.g. say text from an editor), any user could call the undocumented function NtUserGetClipboardToken and get back the previously used admin access token.

This was raised by Forshaw in CVE-2015-0087.