By default, when you create a new Internet Information Services (IIS) website, it’s open to everyone with anonymous access enabled — anyone can access and view the data being hosted by that site. Obviously, this is a security concern for most organizations. Indeed, I’m often asked by clients and colleagues how to lock down an IIS site so only the desired people can access it.
The answer is pretty simple: In order to secure an IIS site, all one needs to do is change the default permissions, enable Windows Authentication for user accounts, and disable Anonymous Authentication in IIS Manager. Here are the steps:
How to secure your IIS site
1.Select your site and click “Authentication”, In the screenshot below, you can see that I have many IIS sites, including one named “Default Web Site”.
2. If you have Windows Authentication installed for IIS, proceed to step 3. If you don’t have Windows Authentication integrated in IIS, add this feature from Server Manager under “Roles / Services” for IIS”EX. IIS Windows Authentication Feature of IIS.
3. Enable the Windows Authentication option for your site:
4. Reconfigure the permissions of the web site. First, we will break inheritance and then we will remove “Users” from having any access:
4.1 Right-click the site select “Edit Permissions”
4.2 Click “Advanced.”
4.3 Click “Change Permissions.”
4.4 Uncheck the box “Include inheritable permissions from this objects parent”. When prompted with a warning, select ADD. This simply copies the existing permissions back without inheritance; this is very important as to not break the website for yourself and the system at large.
4.5 Delete the permission for Users. This will disable the ability for any domain users to simply authenticate to your site to view the reports, while allowing local administrators and members of IIS_IUSRS to log in and view reports. (The set of base permissions can vary from OS to OS.) Also make sure that security principals like “Everyone” and “Authenticated Users” do not have any access.
4.6 Last, you can now use the basic “Edit” button to add Read Only access for select users and groups. In my case, I gave Read access to my reports to Frank. For basic site usage, nothing more then Read access is really needed; don’t give anyone Modify or Full Control access unless there is some special need.
Note that I did this testing on Windows 2008 and Win 7, and I did not need to bounce IIS for any of these configuration changes to start working.
How can Netwrix help?
Netwrix Access Analyzer can help you enhance the security of your Windows infrastructure and minimize the risk of a data breach. It empowers you to:
- Identify vulnerabilities that can be used by attackers to compromise Windows systems and get to your data.
- Enforce security and operational policies through baseline configuration analysis.
- Audit and govern privileged accounts.
- Prove compliance more easily with prebuilt reports and complete system transparency.
FAQ
What is Windows Authentication in IIS?
Windows Authentication in IIS is a secure type of authentication in which user account credentials are hashed before being transmitted over the network.
Is Windows Authentication the same as Active Directory?
No. You can use Windows Authentication even if your server is not a member of an Active Directory domain.
Does IIS Windows Authentication use LDAP?
No. IIS Windows Authentication supports only the Kerberos and NTLM protocols.
Security Researcher at Netwrix and member of the Netwrix Security Research Team. Joe is an expert in Active Directory, Windows, and a wide variety of enterprise software platforms and technologies, Joe researches new security risks, complex attack techniques, and associated mitigations and detections.
Предположим, вы тестируете производительность веб-приложения интрасети из сети с помощью частного агента, и приложение поддерживает проверку подлинности с учетными записями Windows. В этом случае частный агент Dotcom-Monitor и средство сценариев EveryStep можно настроить на использование встроенной проверки подлинности Windows при выполнении тестовых сценариев.
Включение встроенной проверки подлинности Windows позволяет средству создания сценариев EveryStep использовать учетные данные Active Directory пользователя для входа в приложение. Инструмент автоматически передает учетные данные из браузера на веб-сервер, минуя пользовательский интерфейс входа (например, форму входа).
Обратитесь в службу поддержки по поводу пользовательской конфигурации частного агента
Обратите внимание, что по умолчанию Dotcom-Monitor запускает службу частного агента под учетной записью локальной системы для выполнения тестовых сценариев на сервере.
Чтобы использовать проверку подлинности Windows для тестов, необходимо запустить Private Agent под учетной записью с соответствующими правами доступа. Для этого, пожалуйста, свяжитесь с нашей службой поддержки и запросите настройку частного агента. Мы настроим параметры Частного агента специально для вашего случая.
После настройки частного агента для запуска под руководством соответствующего системного пользователя воспользуйтесь рекомендациями из этой статьи, чтобы включить проверку подлинности Windows для внутреннего тестирования производительности веб-сайта с помощью EveryStep Scripting Tool Desktop.
Сначала запустите EveryStep Scripting Tool Desktop под действительной учетной записью Windows с правами доступа к целевому веб-приложению. Для установки инструмента ознакомьтесь с разделом Использование рабочего стола для создания сценариев EveryStep .
В инструменте сценариев EveryStep щелкните значок гаечного ключа в правом верхнем углу окна инструментов и выберите Использовать системные учетные данные на вкладке Chrome (или Edge , если выбран). Примените настройки и перезапустите средство.
Если настройка не установлена, настройте свойства Интернета системы, чтобы добавить целевой домен в список зоны местной интрасети . Для этого запустите inetcpl.cpl из командной строки Windows. Затем на вкладке Безопасность выберите Местная интрасеть и нажмите кнопку Сайты. Перейдите в Дополнительные настройки и добавьте веб-сайт в зону.
По завершении запишите тестовый сценарий, как обычно.
Включение проверки подлинности в «Windows 11»
1. Откройте меню «Пуск» и перейдите в «Параметры» операционной системы «Windows 11».
2. Откройте категорию «Сеть и интернет». Откройте раздел под названием «Ethernet».
3. Справа от параметра «Параметры проверки подлинности» нажмите кнопку «Изменить».
4. Переведите ползунок параметра в положение «Включено» и нажмите кнопку «Сохранить».
5. Перезагрузите устройство. После этого проверка подлинности сети будет включена.
Другие руководства
- Очистка «DNS-кэша» в «Windows»;
- Смена «DNS-сервера» в «Windows»;
- Сброс параметров сети в «Windows»;
- Настройка сервиса «Windscribe»;
- Настройка сервиса «Proton VPN»;
- Настройка сервиса «Cloudflare»;
- Расположение сетевых свойств;
- Отключение брандмауэра системы;
- Отключение сторонних сетей;
- Настройка сервиса «Planet VPN».
Современная проверки подлинности (Modern Authentication) сейчас по умолчанию включена для всех новых тенантов Microsoft 365/ Azure. Это протокол аутентификации более безопасный, чем устаревший Basic Authentication. Во второй половине 2021 года Microsoft планирует полностью запретить использовать Basic Authentication для всех клиентов Microsoft 365. В этой статье мы рассмотрим особенности включения/отключения Modern и Basic Authentication в Microsoft 365.
Содержание:
- Базовая и современная аутентификация
- Поиск приложений Microsoft 365, использующих Basic Authentication
- Как включить Modern Authentication для тенанта Microsoft 365?
- Поддержка Modern Authentication в разных версиях Outlook
Базовая и современная аутентификация
Microsoft сейчас поддерживает следующие виды аутентификации для Office 365:
Поиск приложений Microsoft 365, использующих Basic Authentication
Прежде чем включать современную проверку подлинности и отключать basic authentication, проверьте какие протоколы аутентификации используют ваши пользователи и приложения Microsoft 365.
- Откройте портал управления Azure;
- Перейдите Azure Active Directory -> Sign-in logs;
- Выберите диапазон Last 1 month;
- Добавьте фильтр по полую Client App;
- Выберите для данного фильтра все Legacy Authentication Clients.
Это позволит вам найти пользователей и приложения, которые все еще используют basic аутентификацию. Вам нужно мигрировать найденные приложения на протокол современной аутентификации (в моем случае большинство события были связаны с нативными почтовыми клиентами на смартфонах, их нужно мигрировать на Outlook App).
Подробнее про просмотр логов входов пользователей в Microsoft 365/Azure AD рассказано в этой статье.
Microsoft анонсировала, что будет автоматически отключать Basic Auth для тенантов, где он не используется.
Как включить Modern Authentication для тенанта Microsoft 365?
Вы можете включить современную проверку подлинности через Microsoft 365 Admin Center.
- Перейдите в https://admin.microsoft.com
- Перейдите в Settings -> Org Settings -> Modern authentication
- Включите опцию Turn on modern authentication for Outlook 2013 for Windows and later;
- Сохраните изменения.
Как мы уже упоминали, для новых тенантов Office 365 в Azure по-умолчанию отключена Basic Authentication для всех приложений. В этом случае в этой секции будет отображаться надпись.
Your organization has security defaults enabled, which means modern authentication to Exchange Online is required, and basic authentication connections are blocked. You must turn off security defaults in the Azure portal before you can change any settings here.
Включить поддержку Basic Auth для тенанта можно из портала Azure (Azure Active Directory -> Properties -> Manage Security defaults -> Enable Security defaults =
No
).
Обратите внимание на ряд опций в секции Allow access to basic authentication protocols. Здесь перечислены различные приложения, для которых вы можете разрешить использовать Basic Authentication.
- Outlook client
- Exchange ActiveSync (EAS)
- Autodiscover
- IMAP4
- POP3
- Authenticated SMTP (пример SMTP аутентификации из telnet)
- Exchange Online PowerShell — (для современного модуля Exchange Online PowerShell V2 — EXOv2, базовая аутентификация не поддерживается)
Отключите Basic Auth для всех приложений, для которых она точно не нужна.
Если у вас в тенанте Office 365 настроены политики аутентификации, можно вывести текущие настройки и протоколы, для которых разрешено использование Basic Authentication с помощью PowerShell:
Get-AuthenticationPolicy
В нашем случае у нас всего одна политикиа и BasicAuth запрещена для всех приложений.
AllowBasicAuthActiveSync : False AllowBasicAuthAutodiscover : False AllowBasicAuthImap : False AllowBasicAuthMapi : False AllowBasicAuthOfflineAddressBook : False AllowBasicAuthOutlookService : False AllowBasicAuthPop : False AllowBasicAuthReportingWebServices : False AllowBasicAuthRest : False AllowBasicAuthRpc : False AllowBasicAuthSmtp : False AllowBasicAuthWebServices : False AllowBasicAuthPowershell : False
В целях обеспечения безопасности вы можете создать отдельную политику с разными разрешениями Basic Auth для определенных протоколов и привязать ее к пользователям, которые используют legacy приложения. В данном примере мы разрешим пользователю подключение к Exchange Online через удалённую сессию PowerShell с базовой аутентификацией:
Set-AuthenticationPolicy -Identity "BasicAuthAllowPoSh" -AllowBasicAuthPowershell:$true
Set-User -Identity kbuldogov -AuthenticationPolicy "BasicAuthAllowPoSh"
При этом политика по умолчанию будет блокировать устаревшие протоколы:
New-AuthenticationPolicy -Name "BasicAuthBlock"
Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Legacy Authentication"
Кроме того, обратите внимание что в настройках организации есть еще одна опция OAuth2ClientProfileEnabled, которая определяет включена ли Modern Auth для тенанта:
Get-OrganizationConfig | ft OAuth*
Если OAuth2ClientProfileEnabled = False, значит современная проверка подлинности отключена.
Поддержка Modern Authentication в разных версиях Outlook
Обратите внимание на специфику поддержки современной проверки подлинности в разных версиях Outlook:
- Outlook 2010 и ранее – не поддерживают Modern Auth. Если в настройках тенанта отключена Basic Auth, такие версии Outlook не смогут подключиться к Exchange Online в Microsoft 365;
- Outlook 2013 – для поддержки OAuth нужно установить два параметра в реестре в ветке
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Common\Identity
(
EnableADAL = 1
и
Version = 1
; - Outlook 365, 2019, 2016 – современная аутентификация поддерживается по-умолчанию. Чтобы всегда использовать сначаа Modern Auth, установите параметр
AlwaysUseMSOAuthForAutoDiscover = 1
в ветке
HKEY_CURRENT_USER\Software\Microsoft\Exchange
(если этот параметр не включен, Outlook может постоянно запрашивать пароль для подключения, или может быть другая проблема с пустым окном входа в Outlook/Teams );
Вы можете проверить, что клиент Outlook использует Modern Authentication для подключения к почтовому серверу. Зажмите
Ctrl
и щелкните по значку Outlook в трее. Убедитесь, что в поле Authn указано Bearer*. Это означает, что клиент использует современную аутентификацию.
Работая в среде Windows каждый системный администратор так или иначе сталкивается с системами аутентификации. Но для многих этот механизм представляет собой черный ящик, когда суть происходящих процессов остается неясна. В тоже время от правильной настройки аутентификации напрямую зависит безопасность сети, поэтому важно не только знать способы и протоколы, но и представлять их работу, хотя бы на общем уровне.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
В рамках данного материала мы будем рассматривать сознательно упрощенное представление процедур аутентификации, достаточное для понимания базового принципа работы, впоследствии данные знания могут быть углублены путем изучения специализированной литературы.
Для начала внесем ясность в термины. Многие путают понятия аутентификации и авторизации, хотя это различные процедуры.
- Аутентификация — происходит от английского слова 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. Рассмотрим их подробнее:
| Наименование настройки | Клиентский компьютер | Контроллер домена | Lm Compatibility Level |
|---|---|---|---|
| Отправлять LM- и NTLM-ответы | Клиентские компьютеры используют LM и NTLM аутентификацию, и никогда не используют сеансовую безопасность NTLMv2. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 0 |
| Отправлять LM- и NTLM- использовать сеансовую безопасность NTLMv2 | Клиентские компьютеры используют LM и NTLM аутентификацию, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 1 |
| Отправлять только NTLM-ответ | Клиентские компьютеры используют проверку подлинности NTLMv1, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 2 |
| Отправлять только NTLMv2-ответ | Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена допускают проверку подлинности LM, NTLM и NTLMv2. | 3 |
| Отправлять только NTLMv2-ответ. Отказывать LM. | Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена отказываются принимать аутентификацию LM, и будут принимать только NTLM и NTLMv2. | 4 |
| Отправлять только NTLMv2-ответ. Отказывать LM и NTLM. | Клиентские компьютеры используют проверку подлинности NTLMv2, и используют сеансовую безопасность NTLMv2, если сервер поддерживает ее. | Контроллеры домена отказываются принимать аутентификацию LM и NTLM, и будут принимать только NTLMv2. | 5 |
Внимательный читатель, изучая данную таблицу, обязательно обратит внимание на сеансовую безопасность NTLMv2. Данная возможность, как и вообще все взаимодействие по NTLMv2, довольно плохо документированы, поэтому многие понимают смысл этой возможности неправильно. Но на самом деле все довольно несложно.
После того, как клиент пройдет аутентификацию формируется ключ сеанса, который используется для подтверждения подлинности при дальнейшем взаимодействии. Ключ сеанса NTLM основан только на NT-хэше и будет одинаковым до тех пор, пока клиент не поменяет пароль пользователя. Какие угрозы безопасности это несет пояснять, нам кажется, не надо. Сеансовая безопасность NTLMv2 подразумевает вычисление ключа сеанса с использованием не только NT-хэша, но и запросов сервера и клиента, что делает ключ уникальным и гораздо более стойким к возможным атакам. При этом данная возможность может быть использована совместно с NTLM или LM аутентификацией.
Мы надеемся, что данный материал поможет вам глубже понять процессы аутентификации в системах Windows. В следующей части мы подробно остановимся на устройстве и работе протокола Kerberos.
Онлайн-курс по устройству компьютерных сетей
На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.