Как сделать идентификацию в домене

Обновлено: 04.07.2024

Ресурсные записи DNS (или DNS-записи домена) – это записи, которые в системе доменных имен указывают соответствие между именем и служебной информацией.

В этой статье мы остановимся на элементах ресурсных записей, связанных с почтовыми отправлениями: SPF, DKIM, DMARC. И для начала разберемся в том, с какими проблемами могут столкнуться те, кто хочет сделать свою рассылку.

Мое письмо ушло в спам

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

Именно настройка SPF-записи защищает домен от несанкционированного использования. Это не позволяет допустить ситуации, когда от имени вашего домена будут рассылаться мошеннические письма.

Поэтому почтовые службы обращают внимание на SPF-запись, а также DKIM и DMARC, о которых будет рассказано далее.

Обязательно проверьте SPF-запись, если письма, отправленные при помощи функции PHP mail(), попадают в спам.

Как настроить SPF

SPF настраивается как TXT-запись для домена.

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

Более подробно ознакомиться с синтаксисом можно в документации SPF .

Если ваш домен расположен на нашем хостинге (и для него указаны NS-серверы Timeweb), то смело обращайтесь в службу поддержки, наши специалисты помогут вам настроить SPF-запись.

Клиентам с другими NS-серверами необходимо обращаться к держателю NS-серверов.

DKIM (DomainKeys Identified Mail) - это метод e-mail аутентификации, который дает возможность получателю проверить, было ли письмо отправлено с заявленного домена.

Главная задача DKIM - это упростить обнаружение электронных писем с поддельными адресами, когда заявленный адрес не соответствует адресу, с которого было отправлено письмо (один из видов мошеннических писем).

DKIM позволяет значительно облегчить идентификацию законной, правомочной электронной почты.

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

Настройки SPF и DKIM подтверждают, что отправитель письма определен и не является мошенником.

Как настроить DKIM

Если вы используете почту Timeweb, то DKIM-подпись создается автоматически: все необходимые настройки автоматически прописываются в тот момент, когда вы создаете первый почтовый ящик на своем домене.

DMARC

SPF и DKIM – это хорошие и надежные методы аутентификации отправителя, но они имеют свои недостатки, поэтому была разработана открытая спецификация использования DMARC.

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

Как настроить DMARC

Почтовый сервис Timeweb использует только SPF/DKIM. Но DMARС-запись может быть указана для домена, если домен должен быть настроен для стороннего почтового сервиса, использующего эту спецификацию.

Для настройки DMARC нужно добавить доменную запись в DNS-настройки.

Пример самой простой записи, позволяющей включить режим мониторинга (выполнить тест DMARC и сохранить его результат):

В этом случае если проверка на стороне получателя покажет, что домен в заголовке “From” соответствует указанному в доменной записи DMARC, то письмо пройдет проверку и попадет в почтовый ящик адресата.

Полную информацию о синтаксисе DMARC можно найти на официальном сайте .

Общие рекомендации

Если у вас есть какие-нибудь вопросы, задавайте в комментариях, будем рады помочь!

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

Аутентификация: общие принципы

Аутентификация представляет собой один из компонентов любой компьютерной системы управления доступом. Как показано на экране 1, системы управления доступом обеспечивают идентификацию, аутентификацию, авторизацию и отчетность.

Аутентификация или проверка подлинности (authentication). После того как субъект безопасности вводит с клавиатуры или иным способом предоставляет необходимую для идентификации информацию (например, имя пользователя, маркер безопасности), он должен ввести с клавиатуры или представить частную информацию для аутентификации (например, пароль и PIN-код). В Windows субъект безопасности вводит эту информацию на экране регистрации с помощью программ Microsoft Graphical Identification and Authentication DLL (msgina.dll) и Winlogon.exe. Протокол аутентификации и механизм системы кодируют представленную информацию на настольном компьютере и передают запрос аутентификации. Служба аутентификации Windows может быть базой данных SAM или AD. База данных SAM обслуживает локальные процедуры регистрации и регистрацию на контроллерах домена Windows NT 4.0. AD аутентифицирует запросы в Windows 2000 или доменах более поздних версий этой операционной системы. Протокол аутентификации (например, LAN Manager, NT LAN Manager, NTLM, NTLMv2, Kerberos) используется для транспортировки запросов аутентификации и последующих транзакций между экраном регистрации и службой аутентификации. Чуть ниже каждый протокол аутентификации будет рассмотрен отдельно.

Сразу после аутентификации система собирает идентификаторы SID учетной записи и сведения о членстве в группах в объекте, называемом маркером доступа (access token). Возможно, пользователю придется выйти и вновь зарегистрироваться в системе, чтобы новые разрешения безопасности вступили в силу. Если пользователю нужно получить доступ к объекту (например, файлу, папке, принтеру, разделу реестра), защищенному разрешениями NTFS, то процесс (например, Windows Explorer), выступающий от имени пользователя, предоставляет свой маркер доступа. Каждый объект NTFS располагает списком элементов управления доступом (access control entry, ACE), которые, в сущности, представляют собой знакомые разрешения NTFS (например, Allow Read, Allow Write). Набор элементов ACE, назначенных пользователям и группам, составляет список управления доступом (ACL) данного объекта. Примечательно, что ACL объекта представлен разрешениями безопасности, которые можно просмотреть в Windows Explorer.

Маркер доступа, содержащий учетную запись и группы, с которыми связан пользователь, определяет эффективные разрешения пользователя. Процесс авторизации заключается в разрешении или отказе в доступе к определенному объекту на основе сравнения маркера доступа с ACL объекта. Авторизацию обеспечивает Security Reference Monitor системы Windows (экран 1). В примере, показанном на экране 1, пользователь имеет разрешения Read, Write и Modify. Однако группа Everyone, к которой принадлежит пользователь, не имеет разрешения Modify. Члены других групп располагают разрешениями Read и Modify, но разрешение Deny группы Everyone отменяет разрешение Modify. Объект также располагает списками ACL, которые отказывают в разрешении Full Control группе HR, но пользователь к этой группе не принадлежит. Таким образом, эффективные разрешения пользователя по отношению к объекту на экране 2 — Read и Write.

Отчетность (accounting). Если в Windows режим аудита активизирован, то система сохраняет событие аутентификации в журнале Security, и это последний компонент системы управления доступом — отчетность. Большинство сложных событий начальной регистрации и последующей авторизации происходят за несколько секунд и скрыты от пользователя. Все сложные операции возлагаются на протокол аутентификации.

Задачи протокола

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

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

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

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

Локальная и доменная регистрация

При регистрации пользователя одна из первых задач Windows — определить, относится ли процедура только к локальной машине или к учетной записи домена. Пользователи, регистрирующиеся от имени локальной учетной записи, имеют доступ только к ресурсам своего компьютера и только если информация об учетной записи пользователя содержится в локальной базе данных SAM. Если пользователям нужно обратиться к ресурсам на удаленном компьютере без аутентификации в домене, то их учетные записи должны быть продублированы в локальной базе данных SAM каждого доступного компьютера. Учетные записи в каждом компьютере-участнике должны быть синхронизированы (одинаковые имена регистрации, пароли и сроки действия учетных данных на всех машинах). В противном случае положение значительно усложняется. Трудно обслуживать одноранговые (P2P) сети средних размеров, в которых применяются только локальные процедуры регистрации.

Протоколы аутентификации Windows

Как отмечалось выше, в Windows применяется четыре основных протокола аутентификации: LAN Manager, NTLM, NTLMv2 и Kerberos. LAN Manager появился во времена DOS и продолжал использоваться с первыми версиями Windows. NTLM был выпущен вместе с NT. Новшеством пакета обновлений NT Server 4.0 Service Pack 4 (SP4) стал NTLMv2, а Windows 2000 привнесла Kerberos. По умолчанию все компьютеры с Windows 2000 и более новыми операционными системами совместимы со всеми четырьмя протоколами аутентификации. Передавая в эти системы соответствующие команды, другие рабочие станции и серверы могут выбирать протокол для обработки запроса аутентификации. Системы Windows 9x и более поздние с полным набором программных исправлений совместимы с LM, NTLM и NTLMv2. На платформе Microsoft Kerberos может использоваться только клиентами Windows 2000 (или более новыми) при обращениях в домены Windows 2000 (и выше). Компьютер с Windows 2000 или более новой версией операционной системы должен иметь Kerberos и по крайней мере еще один из протоколов аутентификации.

Исследования в области безопасности показали, что более старые протоколы (LM и NTLM) уязвимы в случае прослушивания и атак с разгадыванием пароля.

Поэтому, если возможно, рекомендуется использовать только Kerberos и NTLMv2. Чтобы убедиться в правильности этого совета, следует оценить возможности каждого протокола.

LAN Manager

Компания IBM разработала протокол LAN Manager, применив его в ранних версиях Windows и сетях Windows. Как все протоколы аутентификации Microsoft, LAN Manager генерирует хеш паролей (LM hash), который хранится и используется отправителем и получателем в процессе аутентификации. LAN Manager формирует LM-хеши, изменяя все буквы пароля на верхний регистр, разбивая пароль на две 7-символьные половины, а затем шифруя. В дальнейшем LM-хеш используется в нескольких последовательных операциях, аналогичных процессу запрос—ответ, описанному выше.

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

пароли могут состоять из ограниченной последовательности 128 символов ASCII;
длина пароля не превышает 14 символов;
если пароль содержит менее 14 символов, то отсутствующие символы заменяются легко угадываемой хешированной формой, что позволяет точно определить длину пароля;
перед кэшированием LAN Manager преобразует все буквенные символы пароля в верхний регистр.

Почему LAN Manager до сих пор не вышел из употребления? В целях обратной совместимости он активен по умолчанию во всех компьютерах Windows, в том числе Windows Server 2003. В новейших базах данных аутентификации Windows слабый LM-хеш хранится наряду с более надежными просто на случай, если придется выполнить транзакцию LAN Manager. Если на предприятии не используются другие приложения, требующие аутентификации LAN Manager, то можно (и нужно) LAN Manager отключить.

NTLMv2

Kerberos

Компания Microsoft приняла Kerberos в качестве выбираемого по умолчанию протокола доменной аутентификации для доменов Windows 2000, а затем и AD. Kerberos — открытый стандарт, пригодный для взаимодействия с инородными доменами (называемыми областями — realm — в UNIX и Linux). Каждый DC в доменах AD играет роль сервера распределения (Kerberos Distribution Server, KDC) и может участвовать в процедуре аутентификации. Безопасность повышается благодаря следующим характеристикам Kerberos:

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

Краткое описание работы Kerberos:

После успешной обычной аутентификации компьютер пользователя запрашивает билет безопасности из сервера Kerberos (DC) для будущих запросов аутентификации.
Сервер Kerberos выдает запросчику билет для участия в будущих событиях аутентификации и авторизации без повторного предъявления первоначальных учетных данных аутентификации.
Когда запросчику нужно обратиться к ресурсу сервера-участника, он получает другой билет доступа от сервера Kerberos и предъявляет его серверу ресурса для проверки.
Первоначальные учетные данные аутентификации не передаются по сетевым каналам ни в одном из последующих сеансов аутентификации (до тех пор, пока не истечет срок действия билета, выданного на этапе 2).

Следует обратить внимание, что, хотя принцип работы Kerberos напоминает инфраструктуру с частным открытым ключом (public key infrastructure, PKI), вся информация защищается с использованием симметричных ключей (в отличие от асимметричных ключей, применяемых в большинстве служб аутентификации).

Смарт-карты

Надежность паролей и других методов аутентификации на основе одного параметра быстро снижается. Электронная коммерция проникает в повседневную жизнь и возрастает как число способов кражи личных данных (спам, мошенничество с URL), так и вероятность злоупотреблений паролями. Многие специалисты считают, что аутентификация с двумя параметрами — в форме смарт-карт, USB-устройств или других криптографических устройств — в будущем станет обычным явлением для транзакций в Internet. Разработчики Microsoft встраивают в свои решения функции для работы с цифровыми сертификатами и смарт-картами. Для использования смарт-карт необходимо установить службу Certificate Services и распространить сертификаты смарт-карт. Конечно, нужны также физические смарт-карты, устройства считывания и программное обеспечение поставщика. Затем при необходимости пользователи могут вставлять свои смарт-карты в локальные устройства чтения для доступа к компьютеру Windows. При грамотном использовании смарт-карты могут существенно повысить надежность аутентификации.

Защита протокола аутентификации

В некоторых статьях ошибочно утверждается, что взломать механизм аутентификации Microsoft по-прежнему просто. В действительности из 20 существующих инструментов взлома пароля только два работают с NTLMv2 и лишь один — с Kerberos. Но, предприняв несколько простых шагов, можно отвести и эту угрозу. Для предотвращения попыток разгадывания и сброса пароля нужно принять следующие меры (большинство параметров можно настроить локально или с помощью Group Policy).

Обязанности пользователей

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

410013204813773

Задумался недавно над возможностью присоединять компьютеры к домену, используя для этого командую строку. Уточню, речь идёт об обыкновенных рабочих станциях с ОС WinXP. Временами они "отваливаются" от домена, поэтому ещё хотелось бы уметь делать в командной строке то же что делается мастером сетевой идентификации посредством графического интерфейса. Т. е. заходим telnetом на проблемную машину и работаем там не тревожа пользователя, без всяких RDP или удалённых помощников.

Поэтому буду благодарен тем, кто знает как это делать и поделится опытом.

Настройка аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах

Не работает аутентификация операционной системы (windows) через IIS при использовании тонкого клиента или веб-клиента.

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

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

Решение проблемы

На сервере 1С включить технологический журнал, используя следующую настройку:

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

Открыть технологический журнал рабочего процесса и найти событие EXCP со следующим описанием: "Идентификация пользователя не выполнена
Неправильное имя или пароль пользователя"

Обратите внимание на предшествующее ему событие CONN и значение свойства DstUserName2 - именно в таком виде пользователь должен быть указан в свойствах пользователя информационной базы.

Заменить значение свойства "Пользователь" пользователя информационной базы согласно следующему формату "\\" + [Имя пользователя из свойства DstUserName2 без скобок].

Проверить работоспособность аутентификации средствами операционной системы, войдя в информационную базу, используя веб-клиент.

Расположение веб-сервера IIS и рабочих серверов 1С на разных машинах

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

При возникновении такой ситуации необходимо проверить следующие настройки:

1) Убедиться, что процессы сервера 1С запущены от имени доменной учетной записи, входящей в группу Domain Users.

2) Убедиться, что веб-сервер IIS настроен корректно.

В публикации информационной базы найти настройки аутентификации

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

Пул приложений публикации не нуждается в настройках, в нем можно оставить все по умолчанию.

После изменения настроек перезапустить веб-сервер с помощью команды iisreset в командной строке.

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

Для этого откройте оснастку Active Directory Users and Computers (dsa.msc), в компьютерах найдите веб-сервер, перейдите в его свойства и на вкладке Делегирование установить значение "Доверять компьютеру делегирование любых служб (только Kerberos)" и нажать применить.

4) Убедиться, что на клиенте в свойствах обозревателя разрешена встроенная проверка подлинности Windows.

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

Важно: аутентификации Windows при расположении веб-сервера IIS и рабочих серверов на разных машинах в тонком клиенте работает, начиная с версии 8.3.10.2620 (для тестирования).

Читайте также: