Подлинность сети не проверена домен windows 7: Сеть подлинность не проверена windows 7 | Операцинные системы

04.06.1974 alexxlab

Содержание

Сеть подлинность не проверена windows 7 | Операцинные системы

пятница, 1 апреля г.

win 7, ad, проблема с подлинностью клиентской машины

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

Доброго всем времени суток. В общем, все произошло хуже чем могло быть и нужна помощь. Имелся КД (AD, DNS, DHCP, RRAS) и несколько специфичных программ. Данный КД умер (временно или даже совсем). С бэкапами было как обычно — их нет, но имеется резервый КД с AD полугодовалой давности

(т.к. благодаря ответственному лицу, он был выключен и не реплицировался почти полгода).

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

Наспех сделано следующее: поднят DHCP, захватил все 5 ролей fsmo, RRAS. Но есть кучи проблем:

1) Как вообще лучше действовать, за что хвататься?

2) Все компьютеры (рабочие станции), похоже, потеряли доверие (не открывают свои расшаренные папки) (в win 7 подкл. по сети — подлинность не проверена, nltest /sc_renew и netdom reset — писали ошибку 5 и невозможно выполнить операцию, т.к. нет доверия между рабочей станцией и основным КД. Ничего лучше вывода / ввода в домен не придумал — что делать?

3) Стоило ли захватывать fsmo?

4) В DHCP появляются bad_address. Как лечить?

5) Если появится (починят) старый — что делать? (Поставить его, а с нового снести AD и поставить заново?).

К сожалению, матчасть слабовата и опыта мало. Помогите мудрыми советами.

Active Directory без проблем

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

Трудности с оборудованием

В общем, все домены AD весьма устойчивы к аппаратным неполадкам, которые приводят к отказу одного контроллера домена (DC). Конечно, это утверждение верно, только если в каждом домене развернуто более одного DC и выполняется постоянный мониторинг репликации изменений между контроллерами доменов. Таким образом, если один DC по какой-то причине выходит из строя, клиенты, проходящие проверку подлинности в домене, найдут в сети другой DC через DNS. При нормальной работе проблем не возникает, даже если контроллеры домена с какой-либо специализированной ролью Flexible Single-Master Operation (FSMO) выходят из строя на несколько часов или даже дней. Для нормальной работы AD не требуется, чтобы все контроллеры домена FSMO были доступны в любое время. Очевидно, необязательно обновлять схему или в массовом порядке создавать новые объекты в домене при отказе конкретных контроллеров домена FSMO. Но обычные операции, такие как изменение пользователями паролей или добавление администратором нового объекта в домен, будут выполняться по-прежнему. Это одно из главных достоинств AD и модели репликации с несколькими владельцами.

Но иногда причиной проблемы является не аппаратный отказ DC. Порой неполадки начинаются лишь после ремонта оборудования и перезагрузки DC — особенно если DC является эмулятором основного контроллера домена (PDC). По умолчанию все DC в домене AD синхронизируют время с эмулятором PDC соответствующего домена. Компьютеры и серверы в домене синхронизируют время с контроллером домена, используемым ими для проверки подлинности (обычно это DC в их сайте AD). Для проверки подлинности Kerberos все клиенты и контроллеры домена должны быть синхронизированы. Клиенты и серверы Windows 2000 Server и более поздних версий в домене AD используют Kerberos по умолчанию. В случае слишком большой разницы во времени между клиентом и сервером, на котором расположен нужный ресурс, такой как общая папка, проверка подлинности на сервере ресурса завершается неудачей. По умолчанию приемлемое рассогласование по времени в лесу AD — пять минут. Поэтому, даже если пользователь или компьютер успешно проходит проверку подлинности в домене, попытка доступа к серверу может завершиться неудачей из-за разницы во времени.

Какое отношение это имеет к аппаратному отказу DC в домене, возможно, даже основного DC? Очень простое: если в процессе ремонта оборудования была заменена системная плата сервера, обычно заменяется и встроенный в нее таймер. Маловероятно, чтобы время системного таймера новой платы совпадало со временем остального леса AD. Если после этого просто перезагрузить PDC, когда он подключен к сети, то другие контроллеры домена синхронизируют время с PDC, обнаружив, что он вновь присутствует в сети. В результате может появиться рассогласование времени на различных компьютерах, недопустимое для Kerberos. Хотя PDC может быть настроен на репликацию с внешним источником времени, в сеть внесена временная ошибка, которая вызовет неполадки, например невозможность серверов Microsoft Exchange Server использовать глобальные каталоги (GC) в своих сайтах для преобразований LDAP или пользователям не удастся получить доступ к общим каталогам. Может оказаться, что положение не нормализуется в течение нескольких часов или дней и даже потребуется ручное вмешательство.

Решение здесь простое: если нужно заменить системную плату DC, особенно вышедшего из строя DC, на котором размещена роль FSMO эмулятора PDC, удалите сетевой кабель перед перезагрузкой DC. После успешной перезагрузки DC (для которой может потребоваться больше времени, чем обычно, так как DC не сможет найти другие контроллеры домена для репликации), необходимо зарегистрироваться локально и установить время на DC. Затем можно вновь подключить сетевой кабель. Другой вариант: если PDC отвечает, можно временно перенести роль PDC на другой контроллер домена и выполнить обратный перенос после замены системной платы. Эти методы предотвращают проблемы временной синхронизации, которые в свою очередь нарушают процесс проверки подлинности в сети.

Проверка подлинности между лесами

Большинство администраторов AD смутно представляют, как клиенты используют DNS для обнаружения контроллеров домена в собственном лесу или домена в своей сети. Поэтому, прежде чем рассмотреть процесс между различными лесами AD и сетями, познакомимся с процедурой обнаружения DC внутри домена AD.

Клиент Windows 2000 или более поздней версии, который никогда ранее не проходил проверку подлинности в домене AD, направляет запрос DNS, чтобы получить сведения о любом DC, ответственном за собственный домен. При этом клиент запрашивает с сервера DNS список всех контроллеров домена, которые зарегистрировали типовую запись локатора DC (которая по умолчанию включает все контроллеры домена в домене AD). Чтобы извлечь эти записи, клиент сначала запрашивает типовые записи службы LDAP в зоне _msdcs иерархии DNS. Для домена AD с именем MyCompany.net типовые записи находятся в следующей иерархии DNS: _ldap._tcp.dc._msdcs.MyCompany.net.

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

Предположим, что клиент находится в офисе филиала домена AD MyCompany.net и имя сайта AD — BranchSite. Клиент запрашивает DNS о записях службы Kerberos, зарегистрированных для данного сайта. Эти записи находятся в следующей иерархии DNS: _kerberos._tcp .BranchSite._sites.dc._msdcs.MyCompany.net. На экране 1 также показана иерархия в оснастке DNS консоли управления Microsoft Management Console (MMC).

Затем сервер DNS возвращает сведения только о контроллерах домена, ответственных за сайт клиента, а клиент, в свою очередь, обращается к ним для проверки подлинности в домене. К счастью, клиент хранит в реестре информацию о последнем сайте AD, к которому он принадлежал, и сразу использует эту информацию в следующий раз при необходимости обнаружить DC. Имя сайта AD, записанное клиентом, находится в разделе реестра HKEY_LOCAL_MACHINESYSTEMCurrent ControlSetServicesNetlogonParameters DynamicSiteName.

Даже после того, как пользователь пройдет проверку в собственном домене, требуется сделать несколько дополнительных шагов, чтобы обеспечить доступ к ресурсам через границы доменов в лесу со многими доменами. Часто процесс обнаружения DC повторяется при обращении пользователя к ресурсам в другом домене леса. Хотя все домены в лесу доверяют друг другу, билет Kerberos на право получения билетов Ticket Granting Ticket (TGT), извлеченный клиентом из собственного DC при регистрации, действителен только для запроса билета службы, который, в свою очередь, предоставляет доступ к ресурсам в собственном домене клиента. Когда пользователь обращается к ресурсу в другом домене того же леса (например, к серверу файлов), клиент вновь сначала запрашивает DNS, чтобы найти DC домена файл-сервера и запросить билет TGT, действительный в этом домене. Удобно, что клиент немедленно находит нужный DC. Поскольку клиенту известно, в каком сайте он находится, он использует запрос DNS для конкретного сайта (аналогичный описанному выше) для поиска DC другого домена.

Одна из причин высокой эффективности этого процесса в лесу без обращений к типовым записям локатора DC другого домена заключается в том, что все домены одного леса реплицируют и используют один раздел конфигурации AD. В этом разделе также содержится информация о сайте и подсети, поэтому контроллеры из любых доменов леса правильно регистрируют записи локатора для соответствующих сайтов AD. Если сайт AD не располагает контроллером домена или не имеет DC для каждого домена леса, то механизм AutoSiteCoverage гарантирует, что ближайший DC зарегистрирует запись локатора в DNS. То есть в пределах своего леса клиент всегда может найти DC для конкретного сайта в любом домене лесе. Клиенту не приходится использовать типовые записи локатора DC, которые могут направить клиента для проверки подлинности на контроллер домена в другом полушарии. Но следует помнить, что процесс подразумевает доступность DC конкретного сайта в противном случае клиент использует типовые записи локатора DC, что может привести к замедлению проверки подлинности и обработки объектов групповой политики (GPO).

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

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

Аналогично описанному процессу обнаружения DC между доменами, при обращении к ресурсу в доверенном лесе клиент запрашивает серверы DNS доверенного леса о подходящих контроллерах домена для проверки подлинности. Важно уяснить, что клиент вновь запрашивает в DNS записи службы Kerberos для конкретного сайта. Для этого клиент объединяет имя сайта из собственного домена MyCompany.net с именем домена доверенного леса OtherCompany.net и таким образом запрашивает следующую иерархию DNS: _kerberos._tcp.BranchSite._sites.dc._ msdcs.OtherCompany.net. Если такого сайта AD не существует в доверенном лесе (весьма вероятно для леса, спроектированного другой группой разработчиков), то запрос DNS заканчивается неудачей и клиент должен запросить типовые записи локатора DC. Затем подлинность клиента может быть проверена контроллерами домена доверенного леса. Этот способ явно не идеален и замедляет доступ к данным и приложениям между лесами.

Чтобы предотвратить эту проблему, достаточно создать в обоих лесах сайты AD с одинаковыми именами. Эти новые сайты можно рассматривать как теневые сайты доверенного леса. Нет необходимости добавлять к этим сайтам новые IP-подсети, и теневые сайты могут не содержать настоящих контроллеров домена. Создайте выделенное соединение сайта между каждым теневым сайтом для MyCompany и ближайшим настоящим сайтом OtherCompany . Убедитесь, что к этому соединению сайта не присоединено никаких других сайтов, а сами теневые сайты не присоединены ни к каким другим связям сайтов. Такой подход гарантирует, что нужный DC леса OtherCompany.net добавит необходимые записи типа SRV к соответствующему теневому сайту через AutoSiteCoverage. Теневые сайты обеспечивают использование клиентами верных и ближайших контроллеров домена для проверки подлинности при обращении к ресурсам в доверенном лесу.

Удобная модель с наименьшими привилегиями

По мере того как компании предъявляют более строгие требования к информационной безопасности, администраторы AD начали использовать по крайней мере две учетные записи с различными правами: одну для регистрации на клиентских системах и выполнения повседневных задач (у этой учетной записи нет никаких административных прав в AD) и другую — с достаточными правами в AD для таких административных задач, как управление пользователями и группами. Работать с несколькими учетными записями неудобно даже при обращении к различным функциям операционной системы, например щелкая правой кнопкой мыши на оснастке Directory Users and Computers консоли MMC и выбирая Run для запуска команды из административной учетной записи. Хотя этот метод приемлем, досадно, что диалоговое окно Run, используемое для ввода административных учетных данных, никогда не помнит моей учетной записи для AD. Приходится вводить ее каждый раз, когда нужно расширить свои права.

Хорошее решение проблемы — развернуть централизованный сервер терминалов, на котором установлены все необходимые административные инструменты. Администраторы AD могут подключиться к серверу терминалов, пройти проверку подлинности с административной учетной записью и выполнить необходимые административные задачи в сеансе сервера терминалов. Нет необходимости использовать Run as, и можно даже разместить на настольном компьютере файлы RDP с нужным именем учетной записи. Конечно, не следует хранить пароль административной учетной записи в RDP-файлах. С помощью центрального сервера терминалов администраторы могут подключаться и выполнять свои обязанности с любого клиента — пакет инструментов Windows Server Administration Tools Pack (adminpak.msi) не обязательно устанавливать локально на клиенте. Однако инфраструктура многих предприятий слишком мала, чтобы устанавливать сервер терминалов исключительно для административных целей могут существовать и другие причины для запуска инструментов управления AD с локального компьютера.

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

Например, мою обычную учетную запись пользователя (непривилегированную) можно назвать GUIDOG, а административную учетную запись — ADM.GUIDOG. Чтобы несколько администраторов могли использовать один ярлык на разных компьютерах, необходимо развернуть различные переменные среды в созданном ярлыке, для чего следует поместить соответствующую переменную среды между двумя символами процентов. Ниже приведен образец команды для ярлыка, который используется для запуска оснастки Active Directory Users and Computers с административной учетной записью, и запроса, привязанного к конкретному DC в моем домене:

%windir%system32 unas /env /

user:%userdomain%adm.%username%

mmc %windir%system32dsa.msc /

server=w2k8core01

При создании ярлыка для этой команды можно создать предупреждение и напомнить самому себе, что выполняется переход на учетную запись с расширенными правами, применяя для этой цели цветные обозначения в самом ярлыке в командной строке можно настроить цвета фона и шрифта ярлыка. На экране 2 показано окно, которое выводится при двойном щелчке на ярлыке пользователя GUIDOG. Красный цвет фона командной строки предупреждает, что готовится расширение прав. Поскольку команда Run as в ярлыке соответственно расширена %userdomain% ADM.%username%, мне более не приходится вводить имя учетной записи. Вместо этого появляется приглашение для ввода пароля учетной записи CORPADM.GUIDOG.

Ярлыки Windows являются настоящими файлами (с расширением .lnk), поэтому их можно скопировать в соответствующий общий раздел, доступный любому администратору леса AD. И если другой пользователь, например JOER, также имеет административную учетную запись с тем же соглашением об именовании, он может использовать такой же ярлык для запуска оснастки Active Directory Users and Computers и пройдет проверку подлинности как CORPADM.JOER.

64-разрядные версии Windows

В настоящее время наблюдается мощная тенденция перехода к 64-разрядным версиям Windows, особенно для приложений, которые выигрывают от расширенного пространства памяти 64-разрядной операционной системы. AD — одно из таких приложений. Если база данных AD не умещается в рамках, налагаемых на память 32-разрядными версиями Windows Server (см. таблицу), то перевод контроллеров домена в 64-разрядную среду Windows на оборудовании с достаточной физической памятью существенно увеличивает производительность AD, а также производительность зависимых от AD прикладных программ (например, Exchange).

В данной статье не обсуждается подробно, при каких условиях выгодно применять 64-разрядную версию Windows на контроллерах домена. Как правило, при объединении 32- и 64-разрядных DC в лесу AD (например, Windows Server 2003 x64) проблем не возникает. Для 64-разрядной среды не требуется специальных расширений схемы, а репликация между 32- и 64-разрядными контроллерами домена проходит успешно. Конечно, необходимы подходящие версии драйверов, антивирусные программы и агенты мониторинга, совместимые с 64-разрядной Windows. Правда, могут перестать функционировать некоторые инструменты управления Microsoft для AD. Самые важные из них — инструмент AD Replication Monitor (Replmon), консоль управления групповой политикой Group Policy Management Console (GPMC) и сервер экспорта паролей Password Export Server (PES) инструмента миграции Active Directory Migration Tool (ADMT). Большинство 32-разрядных приложений работает без проблем с 64-разрядной операционной системой Windows благодаря 64-разрядному режиму совместимости Windows-on-Windows (WoW64). Replmon, GPMC и ADMT PES — исключения из этого правила, так как у них есть другие зависимости, которые нельзя обеспечить с помощью WoW64. Replmon и GPMC безупречно функционируют на 32-разрядном сервере, члене домена и, таким образом, могут быть задействованы в 64-разрядном лесе AD и дистанционно подключаться к 64-разрядным контроллерам домена. ADMT PES необходимо установить на DC, поэтому нужно выделить 32-разрядный DC для этой службы или дождаться следующей версии ADMT, выпустить которую планируется вместе с Windows Server 2008. В ее состав войдет 64-разрядная служба PES.

Предупрежден —значит вооружен

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

Гвидо Грилленмейер ([email protected] ) — главный специалист по технологиям в подразделении Advanced Technology Group компании Hewlett-Packard. MVP по Microsoft Directory Services и Microsoft Certified Architect

SC пможет восстановить сервер

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

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

Во вторник было запланировано применение программных исправлений на серверах в центре обработки данных. Исправления удобнее применять через дистанционное соединение, поэтому примерно в 21.00 Фрэнк зарегистрировался в системе и применил исправления ко всем серверам, в том числе к контроллеру домена (DC) с ролью Global Catalog (GC).

После перезагрузки все серверы ответили на команду ping. Но при попытке посмотреть электронную почту Microsoft Office Outlook не смог найти сервер Exchange. Администратор попытался зарегистрироваться на DC, но получил сообщение о недоступности RPC-сервера: The system cannot log you on due to the following error: The RPC server is unavailable. Все средства графического интерфейса оказались неэффективными: получить доступ к роли GC не удавалось. Без этой роли на контроллере домена Active Directory функционирование Exchange невозможно.

Фрэнк пытался выяснить, что произошло с сервером, и вспомнил об оснастке консоли Microsoft Management Console (MMC), с помощью которой можно читать журналы другого сервера. Поэтому он зарегистрировался на сервере, члене домена, и попытался запустить оснастку, но так и не смог обратиться к DC. Фрэнк оказался на острове без возможности добраться до материка DC и не мог получить никакой информации из компьютера, чтобы решить проблему.

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

Спасительный инструмент SC

Случайно ему попалась на глаза статья об инструменте командной строки, SC (sc.exe), который можно использовать для управления службами на локальном или удаленном компьютере. Это была статья Универсальный диспетчер служб Service Controller (Windows IT Pro/RE, март 2007 г.). Читая статью, Фрэнк понял, что этот инструмент и поможет ему выйти из затруднения.

Он вновь зарегистрировался на сервере, члене домена, и ввел команду SC в командном окне, чтобы определить синтаксис, который имел вид:

sc server [command] [service name] option1 option2

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

sc 192.168.10.10 query

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

sc 192.168.10.10 query RPC

Команда вернула сообщение об ошибке: [SC] EnumQueryServices Status:OpenService FAILED 1060: The specified service does not exist as an installed service.

Из этого сообщения об ошибке Фрэнк сделал вывод, что команда SC не распознала отображаемое имя службы RPC (то есть RPC), поэтому он повторил команду со служебным именем RPC, rpcss. На этот раз результаты команды показали, что служба RPC функционирует, хотя ошибка при входе указывала, что служба недоступна. Фрэнк был в недоумении. Продолжая изучать результаты запроса, он заметил параметр State. Значение State, равное 4, свидетельствует о том, что служба функционирует.

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

У него не было доступа к services.msc, чтобы запустить или остановить службу Netlogon, но был инструмент SC. Поэтому Фрэнк остановил службу Netlogon с помощью команды

sc 192.168.10.10 stop netlogon

Затем он направил запрос, чтобы посмотреть результат выполнения предыдущей команды:

sc 192.168.10.10 query netlogon

Теперь значение State для Netlogon было 2, то есть служба не работала. Затем он запустил Netlogon с помощью команды

sc 192.168.10.10 start netlogon

Чтобы узнать результаты этой команды, он вновь направил запрос к Netlogon и увидел, что служба функционирует! Затем Фрэнк запустил службу на всех компьютерах сети с помощью инструмента командной строки SC.

Теперь он мог зарегистрироваться на DC все службы сервера GC были активны и электронная почта работала. Фрэнку удалось выбраться с острова Командной строки и подняться на борт корабля Графический интерфейс . Вывод: иметь под рукой правильно подобранный инструментарий — все равно что плавать в море со спасательным жилетом. Он может не потребоваться, но очень пригодится, если налетит шторм.

Курт Спанбург ([email protected] ) — консультант, работает в компании Solutions Consulting Group, имеет звание MVP по Microsoft Dynamics CRM

Источники: http://sydano.blogspot.com//04/win-7-ad.html, http://forum.oszone.net/thread-266671.html, http://www.osp.ru/win2000/2008/03/5045150/

Комментариев пока нет!

Вас может заинтересовать

Сетевое подключение подлинность не проверена. Восстанавливаем доверительные отношения в домене

Бывает такая ситуация, что компьютер не может пройти проверку подлинности в домене. Вот несколько примеров:

После переустановки ОС на рабочей станции машина не может пройти проверку подлинности даже с использованием того же имени компьютера. Поскольку в процессе новой установки ОС генерируется SID-идентификатор и компьютер не знает пароль учетной записи объекта компьютера в домене, он не принадлежит к домену и не может пройти проверку подлинности в домене.
Компьютер полностью восстановлен из резервной копии и не может пройти проверку подлинности. Возможно, после архивации объект компьютера изменил свой пароль в домене. Компьютеры изменяют свои пароли каждые 30 дней, а структура Active Directory помнит текущий и предыдущий пароль. Если была восстановлена резервная копия компьютера с давно устаревшим паролем, компьютер не сможет пройти проверку подлинности.
Секрет LSA компьютера давно не синхронизировался с паролем, известным домену. Т.е. компьютер не забыл пароль — просто этот пароль не соответствует реальному паролю в домене. В таком случае компьютер не может пройти проверку подлинности и безопасный канал не будет создан.

Основные признаки возможных неполадок учетной записи компьютера:

Сообщения при входе в домен указывают, что компьютеру не удалось установить связь с контроллером домена, отсутствует учетная запись компьютера, введен неправильный пароль учетной записи компьютера или потеряно доверие (безопасная связь) между компьютером и доменом.
Сообщения или события в журнале событий, указывающие аналогичные ошибки или предполагающие неполадки паролей, доверительных отношений, безопасных каналов либо связи с доменом или контроллером домена. Одна из таких ошибок — отказ проверки подлинности с кодом ошибки 3210 в журнале событий компьютера.
Учетная запись компьютера в Active Directory отсутствует.

Как лечить?

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

Поэтому необходимо сделать так :

Открыть оснастку Active Directory, выбрать «Пользователи и компьютеры», щелкнуть объект компьютера правой кнопкой мыши и применить команду «Переустановить учетную запись». После этого компьютер следует заново присоединить к домену и перезагрузиться.

C помощью учетной записи, относящейся к локальной группе «Администраторы»:

netdom reset Имя_машины /domain Имя_домена /Usero Имя_пользователя /Passwordo {Пароль | *}

На компьютере, где утрачены доверительные отношения:

nltest /server:Имя_сервера /sc_reset:ДОМЕН\Контроллер_домена

. Windows XP

1 . Запустим редактор реестра, (Пуск — Выполнить — regedit — Enter)

Как очистить следы от удаленных программ в реестре Вы можете узнать
2. Дальше находим раздел реестра
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\WgaLogon

3. После этого удаляем весь раздел WgaLogon (сомневающиеся могут предварительно сделать копию этого раздела)
4. Делаем перезагрузку системы
После перезагрузки сообщение о проверке подлинности исчезнет

. Windows 7

Что касается по Windows 7 , убираем с помощью программы RemoveWAT21
1. Скачайте данную программу с Deposit или Letitbit
2. Убираете старую активацию
3. Активируете заново
4. И убираете навсегда проверку на подлинность
Подробная инструкция описана в самой программе, вся операция происходит буквально в три клика.

Как избавиться от сообщения о нелицензионном Windows

Обновление (KB971033 ) проверяет подлинность для компонентов активации и проверки, входящих в состав технологий активации Windows для системы Windows 7 .
Правой кнопкой мыши нажимаем на значок: Компьютер — Свойства .
Выбираем Центр обновления Windows — Установленные обновления .
Находим, среди установленных обновлений (Обновление для Microsoft Windows KB971033 ), выделяем и удаляем его.
Чтобы, Windows больше не слетела с активации делаем обновление (KB971033) скрытым . Правой кнопкой мыши нажимаем на значок: Компьютер — Свойства . Выбираем Центр обновления Windows — Важные обновления . Находим (KB971033) и делаем его скрытым, нажав на него правой кнопкой мышки. Больше оно не будет приходить от Microsoft.

Поэтому не устанавливайте эти обновления..
Например, если у Вас пиратская версия то: KB905474 , KB2882822, KB2859537, KB2862330, KB2864058, KB2872339,
Если установите KB971033 — он найдет кряк и будет выдавать сообщение, что «Вы стали жертвой поддельного ПО».
KB2859537 — в Windows XP может заблокировать запуск всех exe — файлов , кроме тех, что
лежат в папке Windows . Удаление обновления исправляет проблему.
Как получать обновления для Windows XP, читайте
Как из Windows XP Home Edition сделать Windows XP Professional Edition , читайте
Вот коротко,о том как убрать это окно.

Чёрный властелин 14 января 2013 в 17:27

В сети с парком в 150 машин после обновление операционной системы до MS Windows 7 стала постоянно наблюдаться проблема со входом пользователя в систему. В один прекрасный день пользователь включив компьютер обнаруживал, что войти в систему он не может, при этом видит ошеломляющее по своей информативности сообщение:
«Не удалось установить доверительные отношения между этой рабочей станцией и основным доменом»

Решение тут одно. Вывести машину из домена и ввести обратно. Когда в день эта ситуация стала повторятся больше одного раза, да и просто надоело, задумался о профилактике. И вот тут интернет промолчал. После некоторого времени уныния, а уныние, как известно — грех, было решено копать. В результате пыток раскопок, была получена причина 99% случаев (и я подозреваю что оставшийся 1% просто не признался в той же самой причине). Причина — это служба восстановления при загрузке, которая включается при некорректном завершении работы. На первом же экране диалога служба спрашивает пользователя восстанавливать систему или нет. В случае положительного ответа система откатывается до более раннего состояния и, возможно, бьется sid машины. Как бы то ни было, домен пускать к себе пользователей с такой машину после такой операции не станет. Надеяться на пользователя в таком вопросе бесполезно. Можно просить его отказываться, в случае возникновения такой ситуации, но пользователь с очень большой вероятностью нажмет кнопку «восстановить» а потом разведет руками, мол бес попутал. В общем надо пакетно отключить службу восстановления при загрузке на n-машинах.

Локально решение выглядит, как консольная команда:

Reagentc.exe /disable

Для сети потребуется утилита PsExec из пакета Microsoft Sysinternals PsTools, описание утилиты и сам пакет лежат

Psexec.exe кладем в одну папку с нашим командным файлом (назовем его broff.cmd)
внутри broff.cmd пишем:

::Получаем список компьютеров в сети, чистим от мусора и кладем в net.lst net.exe view /domain:megafon >>net.tmp for /f «tokens=1,2 delims= » %%i in (net.tmp) do (Echo %%i>>net1.tmp) for /f «tokens=1,2 delims=\» %%i in (net1.tmp) do (Echo %%i>>net.lst) DEL *.TMP::Проходимся по списку и отключаем boot recovery for /f «tokens=1,2 delims= » %%F in (net.lst) do (start psexec \\%%F reagentc.exe /disable)

Вот и все. Пользователь больше нам не враг.

Теги: Доверительные отношения, DC, ИТ, администрирование сетей, сети, развертывание

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

Как проявляется проблема: пользователь пытается авторизоваться на рабочей станции или сервере под своей учетной запись и после ввода пароля появляется ошибка:

Не удалось восстановить доверительные отношения между рабочей станцией и доменом

Или такая:

The security database on the server does not have a computer account for this workstation trust relationship

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

Пароль компьютера в домене AD

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

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

Совет . Максимальный срок жизни пароля может быть настроен с помощью политики Domain member : Maximum machine account password age , которая находится в разделе: Computer Configuration-> Windows Settings-> Security Settings-> Local Policies-> Security Options . Срок действия пароля компьютера может быть от 0 до 999 (по умолчанию 30 дней).

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

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

«Классический» способ восстановить доверительные отношения в этом случае::

Сбросить пароль локального администратора
Вывести ПК из домена и включить его в рабочую группу
Перезагрузится
С помощью оснастки – сбросить учёту компьютера в домене (Reset Account)
Повторно включить ПК в домен
Еще раз перезагрузиться

Этот метод самый простой, но слишком топорный и требует как минимум двух перезагрузок и 10-30 минут времени. Кроме того, могут возникнуть проблемы с использованием старых локальных профилей пользователей.

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

Утилита Netdom

Утилита Netdom включена в состав Windows Server начиная с 2008 версии, а на ПК пользователей может быть установлена из RSAT (Remote Server Administration Tools). Чтобы восстанвить доверительные отношения, нужно войти в систему под локальным администратором (набрав “.\Administrator” на экране входа в систему) и выполнить такую команду:

Netdom resetpwd /Server:DomainController /UserD:Administrator /PasswordD:Password

Server – имя любого доступного контроллера домена
UserD – имя пользователя с правами администратора домена или Full control на OU с учетной записью компьютера
PasswordD – пароль пользователя

Netdom resetpwd /Server:sam-dc01 /UserD:aapetrov /PasswordD:[email protected]@w0rd

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

Командлет Reset-ComputerMachinePassword

Командлет появился в PowerShell 3.0, и в отличии от утилиты Netdom, уже имеется в системе, начиная с Windows 8 / Windows Server 2012. На Windows 7, Server 2008 и Server 2008 R2 его можно установить вручную (http://www.microsoft.com/en-us/download/details.aspx?id=34595), также требуется наличие Net Framework 4.0 или выше.

Также нужно войти в систему под локальной учетной записью администратора, открыть консоль PowerShell и выполнить команду:

Reset-ComputerMachinePassword -Server DomainController -Credential Domain\Admin

Server – имя контроллера домена
Credential – имя пользователя с правами администратора домена (или правами на OU с ПК)

Reset-ComputerMachinePassword -Server sam-dc01 -Credential corp\aapetrov

В открывшемся окне безопасности нужно указать пароль пользователя.

Совет . Эту же операцию можно выполнить с помощью другого командлета Powershell Test-ComputerSecureChannel:

Test-ComputerSecureChannel -Repair -Credential corp\aapetrov

Проверить наличие безопасного канала между ПК и DC можно командой:

nltest /sc_verify:corp.adatum.com

Следующие строки подтверждают, что доверительные отношения были успешно восстановлены:

Trusted DC Connection Status Status = 0 0x0 NERR_Success

Trust Verification Status = 0 0x0 NERR_Success

Как вы видите, восстановить доверительные отношения в домене довольно просто.

Active Directory без проблем | Windows IT Pro/RE

Трудности с оборудованием

Проверка подлинности между лесами

Одна из причин высокой эффективности этого процесса в лесу без обращений к типовым записям локатора DC другого домена заключается в том, что все домены одного леса реплицируют и используют один раздел конфигурации AD. В этом разделе также содержится информация о сайте и подсети, поэтому контроллеры из любых доменов леса правильно регистрируют записи локатора для соответствующих сайтов AD. Если сайт AD не располагает контроллером домена или не имеет DC для каждого домена леса, то механизм AutoSiteCoverage гарантирует, что ближайший DC зарегистрирует запись локатора в DNS. То есть в пределах своего леса клиент всегда может найти DC для конкретного сайта в любом домене лесе. Клиенту не приходится использовать типовые записи локатора DC, которые могут направить клиента для проверки подлинности на контроллер домена в другом полушарии. Но следует помнить, что процесс подразумевает доступность DC конкретного сайта; в противном случае клиент использует типовые записи локатора DC, что может привести к замедлению проверки подлинности и обработки объектов групповой политики (GPO).

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

Чтобы предотвратить эту проблему, достаточно создать в обоих лесах сайты AD с одинаковыми именами. Эти новые сайты можно рассматривать как «теневые» сайты доверенного леса. Нет необходимости добавлять к этим сайтам новые IP-подсети, и «теневые» сайты могут не содержать настоящих контроллеров домена. Создайте выделенное соединение сайта между каждым «теневым сайтом для MyCompany» и ближайшим «настоящим сайтом OtherCompany». Убедитесь, что к этому соединению сайта не присоединено никаких других сайтов, а сами теневые сайты не присоединены ни к каким другим связям сайтов. Такой подход гарантирует, что нужный DC леса OtherCompany.net добавит необходимые записи типа SRV к соответствующему теневому сайту через AutoSiteCoverage. Теневые сайты обеспечивают использование клиентами верных и ближайших контроллеров домена для проверки подлинности при обращении к ресурсам в доверенном лесу.

Удобная модель с наименьшими привилегиями

Хорошее решение проблемы — развернуть централизованный сервер терминалов, на котором установлены все необходимые административные инструменты. Администраторы AD могут подключиться к серверу терминалов, пройти проверку подлинности с административной учетной записью и выполнить необходимые административные задачи в сеансе сервера терминалов. Нет необходимости использовать Run as, и можно даже разместить на настольном компьютере файлы RDP с нужным именем учетной записи. Конечно, не следует хранить пароль административной учетной записи в RDP-файлах. С помощью центрального сервера терминалов администраторы могут подключаться и выполнять свои обязанности с любого клиента — пакет инструментов Windows Server Administration Tools Pack (adminpak.msi) не обязательно устанавливать локально на клиенте. Однако инфраструктура многих предприятий слишком мала, чтобы устанавливать сервер терминалов исключительно для административных целей; могут существовать и другие причины для запуска инструментов управления AD с локального компьютера.

%windir%system32 unas /env /
   user:%userdomain%adm.%username%
   «mmc %windir%system32dsa.msc /
   server=w2k8core01»

При создании ярлыка для этой команды можно создать предупреждение и напомнить самому себе, что выполняется переход на учетную запись с расширенными правами, применяя для этой цели цветные обозначения в самом ярлыке; в командной строке можно настроить цвета фона и шрифта ярлыка. На экране 2 показано окно, которое выводится при двойном щелчке на ярлыке пользователя GUIDOG. Красный цвет фона командной строки предупреждает, что готовится расширение прав. Поскольку команда Run as в ярлыке соответственно расширена %userdomain% ADM.%username%, мне более не приходится вводить имя учетной записи. Вместо этого появляется приглашение для ввода пароля учетной записи CORPADM.GUIDOG.

64-разрядные версии Windows

Предупрежден —значит вооружен

SC пможет восстановить сервер

Потеря RPC-сервера

Фрэнк пытался выяснить, что произошло с сервером, и вспомнил об оснастке консоли Microsoft Management Console (MMC), с помощью которой можно читать журналы другого сервера. Поэтому он зарегистрировался на сервере, члене домена, и попытался запустить оснастку, но так и не смог обратиться к DC. Фрэнк оказался на «острове» без возможности добраться до «материка» DC и не мог получить никакой информации из компьютера, чтобы решить проблему.

Спасительный инструмент SC

Случайно ему попалась на глаза статья об инструменте командной строки, SC (sc.exe), который можно использовать для управления службами на локальном или удаленном компьютере. Это была статья «Универсальный диспетчер служб Service Controller» (Windows IT Pro/RE, март 2007 г.). Читая статью, Фрэнк понял, что этот инструмент и поможет ему выйти из затруднения.

sc [command] [service name] …

sc 192.168.10.10 query

sc 192.168.10.10 query RPC

Команда вернула сообщение об ошибке: [SC] EnumQueryServices Status:OpenService FAILED 1060: The specified service does not exist as an installed service.

Определение причин

sc 192.168.10.10 stop netlogon

Затем он направил запрос, чтобы посмотреть результат выполнения предыдущей команды:

sc 192.168.10.10 query netlogon

Теперь значение State для Netlogon было 2, то есть служба не работала. Затем он запустил Netlogon с помощью команды

sc 192.168.10.10 start netlogon

Теперь он мог зарегистрироваться на DC; все службы сервера GC были активны и электронная почта работала. Фрэнку удалось выбраться с «острова Командной строки» и подняться на борт корабля «Графический интерфейс». Вывод: иметь под рукой правильно подобранный инструментарий — все равно что плавать в море со спасательным жилетом. Он может не потребоваться, но очень пригодится, если налетит шторм.

Поделитесь материалом с коллегами и друзьями

Проверка подлинности сети для удаленного компьютера Windows

Задайте вопрос Быстрый доступ

Archived Forums > Администрирование Windows Vista

Вопрос
Столкнулся в сети с проблемой: на половине компьютеров в центре управления сетями рядом с названием подключения по локальной сети выводится сообщение «подлинность не проверена». Что это значит? На что влияет? И как лечится?
24 апреля 2008 г. 10:30

Ответы

- Изменено14 января 2010 г. 13:44edit
- Помечено в качестве ответа1 июля 2010 г. 8:29
14 января 2010 г. 13:36
С тем же самым и я столкнулся. Причем, из всего домена это происходит только на двух компьютерах. На обоих Windows 7. Домен работает в режиме 2008 R2. На одном из компьютеров проблема решается завершением Касперского, переподключением сети и можно снова включать Касперского. На втором — выключил брандмауэр и проблема исчезла. Касперского на втором компьютере нет. Настройки брандмауэра выдаются политикой. Настройки антивируса выдаются админкитом тоже всем одинаковые. В общем — мистика. Пробовал отключить в Касперском сетевой экран — не помогает. Может кто подскажет, какие файлы попробовать добавить в доверенную зону или какие порты попробовать открыть? Кстати, из домена пробовал выводить (туда-сюда) — помогает до перезагрузки.
===============
С Касперским я сам сглупил — забыл добавить в исключения «%WINDIR%system32svchost.exe». После добавления его в «Защита -> Доверенная зона» сеть нормально заработала. Прошу прощения, что сразу не отписался.
- Предложено в качестве ответа11 июня 2010 г. 5:18
- Помечено в качестве ответа1 июля 2010 г. 8:30
18 мая 2010 г. 7:42
У меня такая надпись появлялась при подключении по VPN, из VPN во внутреннюю у меня был разрешен только DNS, после того как добавил LDAP (TCP) протокол, от VPN-клиентов к контроллеру домена, надпись исчезла.
Смотри что блокирует LDAP.
- Помечено в качестве ответа1 июля 2010 г. 8:30
18 июня 2010 г. 17:33

Все ответы

4 мая 2008 г. 6:24
на сервере какая версия ОС установлена? Какая версия Висты? На Висту установлен SP1?
У меня такое сообщение появляется когда на сервере отключена сетевая проверка подлинности, только не в центре управления сетями, а панели RDP сверху экрана (В настройках удаленного рабочего стола выставлено — разрешать подключения от компьютеров с любой версией удаленного рабочего стола. Server 2008 + Vista SP1) либо удаленное подключение осуществляется от компьютера не включенного в домен.
Когда в настройках удаленного рабочего стола проставлено разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности, в панели RDP сообщение меняется на Подлинность проверена с помощью Kerberos.
4 мая 2008 г. 10:50
На сервере — Win2003 R2 SP2, Vista без SP1.
Проблема связана с антивирусом NOD32 v3. При отсутствии нода сообщение о проверке подлинности не звозникает. Обратились за поддержкой в ESET.
7 мая 2008 г. 4:10

у меня windows 2003 sp2 r2 и vista sp1

nod32 v3 стоит — только раньше то такого не было .. или это как то связанно с обновлением сигнатур ?

7 мая 2008 г. 10:56</li>

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

Условия задачи теже, но не установле Mobile Device Center. Просто НОД в3 и обычный комп, с виду ничем особенным не выделяется.

п.с. Как хоть это сообщение в англ. винде выглядит ни кто не знает? чтобы погуглить по буржуйнету.

25 ноября 2008 г. 9:29</li>

В английской версии сообщение выглядит как Not Verified… больше ничего не нарыл.

Неужели ни кто не с сталкивался с подобным? Какой вообще компонент висты за это дело отвечает?

5 декабря 2008 г. 11:31</li>

Изменено14 января 2010 г. 13:44edit
Помечено в качестве ответа1 июля 2010 г. 8:29

14 января 2010 г. 13:36</li>

С тем же самым и я столкнулся. Причем, из всего домена это происходит только на двух компьютерах. На обоих Windows 7. Домен работает в режиме 2008 R2. На одном из компьютеров проблема решается завершением Касперского, переподключением сети и можно снова включать Касперского. На втором — выключил брандмауэр и проблема исчезла. Касперского на втором компьютере нет. Настройки брандмауэра выдаются политикой. Настройки антивируса выдаются админкитом тоже всем одинаковые. В общем — мистика. Пробовал отключить в Касперском сетевой экран — не помогает. Может кто подскажет, какие файлы попробовать добавить в доверенную зону или какие порты попробовать открыть? Кстати, из домена пробовал выводить (туда-сюда) — помогает до перезагрузки.

===============

С Касперским я сам сглупил — забыл добавить в исключения «%WINDIR%system32svchost.exe». После добавления его в «Защита -> Доверенная зона» сеть нормально заработала. Прошу прощения, что сразу не отписался.

Предложено в качестве ответа11 июня 2010 г. 5:18
Помечено в качестве ответа1 июля 2010 г. 8:30

18 мая 2010 г. 7:42</li>

У меня такая надпись появлялась при подключении по VPN, из VPN во внутреннюю у меня был разрешен только DNS, после того как добавил LDAP (TCP) протокол, от VPN-клиентов к контроллеру домена, надпись исчезла.

Смотри что блокирует LDAP.

Помечено в качестве ответа1 июля 2010 г. 8:30

18 июня 2010 г. 17:33</li>Мне удаления антивирусов и вывод-ввод в домен не помогали. Помогло изменение шифрования (в настройках общего доступа к файлам в центре управления сетями) с 128 бит на 56, и обратно. У меня Windows 7 домен Windows 2008R2. Проблема появилась только на моём компьютере, внезапно.

Предложено в качестве ответа21 июня 2011 г. 9:26

21 июня 2011 г. 9:19</li>Помогло удаление драйвера сети и последующая переустановка. Выводввод в домен как предыдущий шаг не помог. Антивирус microsoft security essentials; Firewall стандартный от Windows 7.20 августа 2012 г. 7:08</li>В сетевой карте указать явно ip адрес DNS , попробуйте

windows server 2008R2 standart AD+DNS+DHCP , клиенты W7 pro

8 октября 2012 г. 4:42</li>еще один вариант решения проблемы, который подошел в моем случае — отключить IPv6 в настройках сетевого адаптера25 октября 2019 г. 7:52</li>

Одной из главных проблем при использовании беспроводной Wi-Fi сети является несанкционированный доступ к ней сторонних пользователей. Часто злоумышленники подключаются к чужому вай-фаю, защищенному слишком легким паролем или вовсе не имеющему такового. Наличие дополнительных соединений уменьшает пропускную способность канала для каждого клиента, в результате чего обладатель роутера ощущает резкое падение скорости интернета. Возникает резонный вопрос: «Как узнать, кто подключен к моему Wi-Fi и как заблокировать незваных гостей?»

Признаки сторонних подключений к Wi-Fi сети

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

Как посмотреть подключенные устройства в «админке» Wi-Fi роутера

Чтобы проверить, кто «сидит» на вашем Wi-Fi, необходимо зайти в настройки роутера. В качестве примера возьмем маршрутизатор TP-Link TL-WR841N, о конфигурировании которого мы говорили в отдельной статье. Итак, для перехода в web-интерфейс роутера в любом браузере вбиваем в адресную строку IP-адрес 192.168.0.1. Далее в появившемся окне вводим имя пользователя и пароль (по умолчанию admin и admin).

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

После прохождения авторизации попадаем в интерфейс административной зоны роутера. В случае с нашим TP-Link TL-WR841N в меню выбираем раздел Беспроводной режим – Статистика беспроводного режима (Wireless – Wireless statistics). Смотрим, кто в текущий момент подключен к вашей Wi-Fi сети.

Для определения посторонних устройств деактивируйте модуль вай-фай у всех своих подключенных девайсов (планшеты, ноутбуки, смартфоны). Если после таких действий список опустеет, то чужих в сети нет. В противном случае имеет место несанкционированное подключение. Заблокировать доступ к Wi-Fi лишних устройств можно здесь же, нажав на кнопку «Запретить».

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

Более детальную информацию по всем подключенным к вашему Wi-Fi роутеру устройствам, в том числе проводным, можно увидеть во вкладке «Список клиентов DHCP» (DHCP Clients List) раздела DHCP. Некоторые модели маршрутизаторов предусматривают возможность устанавливать блокировку сторонних подключений именно через настройки DHCP.

Использование для мониторинга Wi-Fi сторонних приложений

Установить факт несанкционированного использования беспроводной сети позволяют различного рода утилиты. Одна из самых популярных – Wireless Network Watcher. Найти и скачать данную программу не составит труда. После запуска приложение сканирует сеть и показывает, кто подключен к Wi-Fi роутеру.

В списке отображаются IP, MAC-адреса, имена и производители устройств. Ваш роутер и компьютер имеют специальное обозначение в колонке «Device Information» – их сразу исключаем из числа посторонних. Остальные строки требуют проверки. Вычислить «чужаков» можно с помощью отключения «своих» устройств (они сразу же пропадут из списка программы) или путем сопоставления MAC-адресов.

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

Среди плюсов утилит, и конкретно программы Wireless Network Watcher, выделим возможность фонового мониторинга всех подключающихся девайсов. Кликнем по пункту меню «Настройки» (Options), а затем поставим галочки рядом с опциями «Фоновое сканирование» (Background Scan) и «Звук при обнаружении нового устройства» (Beep On New Device).

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

Читайте также:Как узнать пароль от вай-фай через настройки сети компьютераКак раздавать Wi-Fi с ноутбука, работающего под управлением Windows 7/10

Как обезопасить свою беспроводную сеть

Первым делом необходимо изменить заводской пароль для доступа к административной панели Wi-Fi роутера. Применительно к маршрутизаторам TP-Link это производится в разделе «Системные инструменты» (System Tools) – подраздел «Пароль» (Password).

Для повышения уровня безопасности можно также прописать конкретные MAC-адреса, которым будет разрешено изменять настройки роутера. Чтобы ввести это ограничение, зайдите в Безопасность – Локальное управление. На открывшейся вкладке установите переключатель в положение «Только указанные в списке компьютеры могут производить администрирование» и задайте необходимые MAC-адреса.

Еще одним обязательным пунктом является установка пароля непосредственно для самой сети Wi-Fi. Делается это на вкладке «Защита беспроводного режима» (Wireless Security) в разделе «Беспроводной режим» (Wireless). Пароль должен быть достаточно длинным и сложным, чтобы было трудно его подобрать. Способ шифрования лучше выбрать WPA/WPA2.

Ну и чтобы уж на все 100% защититься от посягательств неопределенных пользователей, следует жестко задать список доверенных MAC-адресов. Что-то подобное мы уже делали, когда хотели запретить подозрительные адреса. Теперь же будем, наоборот, разрешать, но только фиксированные. Пройдем по пути Беспроводной режим – Фильтрация MAC-адресов (Wireless – Wireless MAC Filtering) и выберем положение переключателя «Разрешить доступ станциям, указанным во включенных записях». Чуть ниже добавим разрешенные адреса. Теперь только им будет дозволено получать доступ к нашему вай-фаю.

Надеемся, что после прочтения данной статьи вы сможете установить полный контроль над домашней беспроводной сетью, и вопрос «Как посмотреть, кто подключен к моему Wi-Fi» станет уже не таким актуальным.

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

Что такое аутентификация

Это система защиты беспроводных сетей, которая не позволяет посторонним подключаться к вашей группе. На сегодняшний день существует несколько типов аутентификации. Выбрать наиболее подходящий вариант можно в настройках роутера или точки доступа, которая используется для создания домашней сети. Как правило, в наше время используется тип шифрования (аутентификация) WPA-PSKWPA2-PSK2 mixed.

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

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

Другими словами, аутентификация – это проверка подлинности. Это очень важный момент, так как радиус действия одной точки доступа достаточно велик и без такой проверки любой желающий сможет подключиться к сети, в том числе и любители «Халявы», а также злоумышленники. По этому также важно знать, как ограничить доступ к беспроводной сети.

Почему возникает ошибка аутентификации WiFi: Видео

Почему появляется ошибка проверки подлинности и как ее устранить

Как уже говорилось выше, если при подключении к WiFi сети система пишет «Ошибка аутентификации», то в первую очередь стоит проверить правильно написания ключевой фразы, а также включен ли Caps Lock. Если вы забыли свой пароль, то его можно проверить в настройках роутера. Но для этого вам придется подключиться к нему при помощи кабеля.

Рассмотрим, как узнать пароль на примере роутера D-LinkDir-615. После подключения к устройству откройте любимый браузер и в адресной строке пропишите IP маршрутизатора. Узнать его можно в инструкции или на корпусе самого устройства (внимательно осмотрите его со всех сторон).

Как легко узнать IP адрес WiFi роутера: Видео

Также узнать IP роутера можно при помощи командной строки. Нажмите комбинацию клавиш Windows+R, пропишите CMD и нажмите «Enter». В появившемся окне напишите команду ipconfig. Найдите строку «Основной шлюз» – это и есть нужный нам адрес.

Пропишите его в адресной строке браузера и нажмите «Enter». Дальше система попросит ввести логин и пароль. Пишем admin, admin соответственно.

Теперь внизу экрана найдите и нажмите кнопку «Расширенные настройки». Появится несколько дополнительных окон. Нас интересует раздел под названием «WiFi». В нем нужно найти настройки безопасности. Именно здесь вы можете выбрать тип аутентификации (шифрования) и изменить пароль.

Подключение к WiFi роутеру в Windows 8: Видео

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

Также следует проверить канал, на котором работает роутер. Для этого возвращаемся в начальное меню. В разделе WiFi нажимаем «Основные настройки» и находим строку «Канал». Рекомендуется устанавливать значение «Автоматически».

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

Проверка ОС при ошибке аутентификации

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

Выбираете «Свойства» и открываете «Диспетчер устройств». Также можно одновременно нажать две клавиши – Windows+R, в появившемся окне написать mmc devmgmt.msc и нажать «Enter». В появившемся окне нас интересует «Сетевые адаптеры». Открываем ветку и смотрим, есть ли в списке ваш WiFi модуль. Как правило, в названии имеет Wireless Network Adapter. Если устройство помечено восклицательным знаком, то драйвера работают неправильно.

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

Как переустановить драйвер WiFi в Windows 8: Видео

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

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

Используемые источники:

https://social.technet.microsoft.com/forums/ru-ru/239b4086-b872-448b-977a-64a674fb2e13/10871086107610831080108510851086108910901100-10851077
https://viarum.ru/kak-uznat-kto-podklyuchen-k-wi-fi/
http://bezprovodoff.com/wi-fi/problemi/oshibka-autentifikacii-pri-podklyuchenii-k-wifi.html

Включение HTTPS на вашем веб-сервере—ArcGIS Enterprise

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

HTTPS позволяет защитить имена, пароли и другую важную информацию от дешифровки в канале связи между ArcGIS Web Adaptor и сервером. При использовании HTTPS подключение к веб-страницам и ресурсам осуществляется по протоколу HTTPS, а не HTTP.

Для работы через HTTPS необходимо получить сертификат и связать его с веб-сайтом, на котором установлен ArcGIS Web Adaptor. Каждый веб-сервер имеет собственную процедуру загрузки сертификата и его привязки к веб-сайту.

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

Создайте сертификат сервера

Для создания HTTPS-соединения между ArcGIS Web Adaptor и сервером, веб-серверу требуется сертификат сервера. Сертификат – это цифровой файл, содержащий информацию об удостоверении веб-сервера. Он также содержит метод шифрования, который используется при создании защищенного канала между веб-сервером и ArcGIS Server. Сертификат должен создаваться владельцем веб-сайта и иметь цифровую подпись. Существует три типа сертификатов, подписанные центром сертификации (CA), домена и самозаверенный, которые описываются ниже.

Сертификаты, подписанные центром сертификации (CA)

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

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

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

Сертификаты домена

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

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

Создание доменного сертификата и включение HTTPS

Для успешного завершения работы мастера настройки ArcGIS Enterprise необходимо, чтобы на компьютере, на котором установлено базовое развёртывание, был включён протокол HTTPS в IIS.

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

URL-адрес веб-адаптера https://mymachine.mydomain.com/server не доступен. Убедитесь, что для веб-сервера включена поддержка HTTPS. Инструкции по включению HTTPS см. в разделе справки Введение в ArcGIS Enterprise > ArcGIS Enterprise Builder > Планирование базового развертывания.

В большинстве случаев ваш IT-администратор даст вам сертификаты и привяжет их к HTTPS порту 443.

В 2017 году Chrome начал работать только с доверенными сертификатами с параметром Subject Alternative Name (SAN), которые не может быть настроен, если сертификат был создан в приложении IIS Manager.

Если вы используете IIS, и вам необходимо создать сертификат домена, см. Создать сертификат домена, где можно воспользоваться скриптом для запуска на вашем компьютере, который создаст соответствующий сертификат и встроит его в HTTPS порт 443.

Самозаверенные сертификаты

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

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

Создание самозаверенного сертификата в IIS

В Manager IIS выполните следующие шаги, чтобы создать самозаверенный сертификат:

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

Последний шаг – связать самозаверенный сертификат с HTTPS-портом 443. Для дополнительных инструкций см. Связь сертификата с веб-сайтом.

Привязка сертификата к веб-сайту

Если вы получили сертификат, которые не привязан к веб-сайту ArcGIS Web Adaptor, вам необходимо сделать это до того, как продолжить. Привязка означает процесс настройки сертификата для использования порта 443 на веб-сайте.

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

Привязка сертификата к порту 443 в IIS

В Manager IIS выполните следующие шаги, чтобы связать сертификат с HTTPS-портом 443:

Выберите ваш сайт в дереве каталога и на панели Действия щелкните Связи.
- Если порт 443 отсутствует в списке Связи, щелкните Добавить. В ниспадающем списке Тип выберите https. Оставьте порт 443.
- Если порт 443 имеется в списке, выберите его и щелкните Редактировать.
В ниспадающем списке сертификата выберите имя вашего сертификата и щелкните OK.

Проверка вашего сайта

После привязки сертификата и веб-сайта, вы можете настроить Web Adaptor на работу с сервером. Вам понадобится открыть страницу настройки ArcGIS Web Adaptor с использованием URL по протоколу HTTPS, например, https://webadaptorhost.domain.com/webadaptorname/webadaptor.

После настройки Web Adaptor следует проверить, что HTTPS работает правильно, сделав HTTPS-запрос к ArcGIS Server Manager, например, https://webadaptorhost.domain.com/webadaptorname/manager.

Отзыв по этому разделу?

Нужен другой контроллер домена

У меня есть два контроллера домена (Windows 2003) на одном сайте, где находится большая часть отдела, который я поддерживаю. Есть еще одно здание (в другом месте), где также находится мой отдел, но у них нет DC.

Вероятно, это классический вопрос о том, стоит ли устанавливать дополнительный DC, когда компания распределена по нескольким сайтам.

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

Я получаю разные ошибки на клиентов. Некоторые из них :

Netlogon, 5719 , Этому компьютеру не удалось настроить безопасный сеанс с контроллером домена в домене domain.com из-за следующего: в настоящее время нет серверов входа, доступных для обслуживания запроса входа. Это может привести к проблемам с аутентификацией. Убедитесь, что этот компьютер подключен к сети. Если проблема не устранена, обратитесь к администратору домена.

GroupPolicy, 1055, Обработка групповой политики не удалась. Windows не может разрешить имя компьютера. Это может быть вызвано одной из следующих причин: a) Ошибка разрешения имени на текущем контроллере домена. б) Задержка репликации Active Directory (учетная запись, созданная на другом контроллере домена, не реплицирована на текущий контроллер домена).

На серверах я получаю эти ошибки:

Netlogon, 5722, Настройка сеанса с компьютера SOMEPCNAME не прошла проверку подлинности. Имена учетных записей, на которые есть ссылка в базе данных безопасности, — SOMEPCNAME $. Произошла следующая ошибка: доступ запрещен.

* (эта ошибка повторяется для одного и того же компьютера. Возможно, нужно просто добавить это в домен.) *

Репликация NTDS, 1864, Это состояние репликации для следующего раздела каталога на локальном контроллере домена. Раздел каталога: CN = схема, CN = конфигурация, DC = домен, DC = com

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

Мне интересно, если мы должны установить другой DC или попробовать что-то еще. Наши клиенты работают в основном с Windows 7, но есть также клиенты с XP и Vista.

Полоса пропускания между компьютерами на разных сайтах составляет 37,4 Мбит (только что проверено с помощью этой утилиты iperf).

Любая помощь приветствуется.

Получив приглашение войти, используя встроенную проверку подлинности windows

У меня есть приложение .NET 3.5, работающее под управлением IIS 7 на сервере Windows 2003, и я не могу получить встроенную аутентификацию windows, работающую должным образом, поскольку я продолжаю получать запрос на вход в систему. Я установил аутентификацию Windows включенной в IIS со всеми другими типами безопасности отключенными, и мое приложение web.config аутентификация/авторизация файла настроена как:

<system.web>
    <compilation debug="true" strict="false" explicit="true" targetFramework="3.5" />
    <authenticationmode="Windows"/>
    <authorization>
    <deny users = "?" />
    </authorization>
</system.web>

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

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

Чтобы устранить эту проблему дальше, я включил анонимную аутентификацию в IIS и изменил свой файл web.config, к которому я сразу же подключился, а затем добавил ответ.Напишите (System.Security.Principal.WindowsIdentifity.getcurrent().user.name.toString()), чтобы попытаться увидеть, какой пользователь используется при аутентификации. Результат, который я получаю, — это IIS APPPOOL\myapp, который, очевидно, является пулом приложений IIS для моего приложения.

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

Спасибо.

Дополнительное Примечание после дальнейшего устранения неполадок:

Просто заметил, что когда вход в систему завершается неудачей и снова отображается приглашение входа в систему Windows, оно показывает имя пользователя, которое пыталось войти в систему как «SERVERNAME»\»USERNAME», что привело меня к мысли, что оно пытается проверить пользователя на сервере. домен. Чтобы подтвердить это, я создал локальную учетную запись пользователя непосредственно на сервере приложений с тем же именем пользователя и паролем, что и пользователь сетевого домена, и попытался войти снова. В результате я снова получил приглашение войти в систему, но когда я ввел имя пользователя и пароль на этот раз, я смог успешно войти в систему. Сетевой пользователь и сервер приложений находятся в одном домене, поэтому на самом деле не уверен, почему аутентификация IIS указывает на локальные учетные записи сервера приложений, а не на учетные записи домена. Я понимаю, что на данный момент это вопрос IIS, поэтому публикую его и на forums.iis.net, но ценю любые советы, которые кто-то, возможно, с тех пор устранял эту проблему в течение нескольких дней.

asp.net iis-7 windows-authentication
Поделиться Источник Casey 23 марта 2011 в 08:08
1 ответ

90

У меня есть сервер Windows 2008, над которым я работаю, поэтому мой ответ не полностью совпадает с тем, что есть у OP на сервере Windows 2003.
Вот что я сделал (записав это здесь, чтобы я мог найти это позже).
У меня была такая же проблема:
В моем файле Web.config у меня был этот раздел:
<system.web> <authentication mode="Windows" /> <authorization> <allow users="*" /> <deny users="?" /> </authorization> </system.web>
В разделе IIS все эти проблемы, по-видимому, решаются под значком аутентификации .
Разрешения на редактирование: Убедитесь, что у вашей учетной записи ASP.NET есть разрешение. Мой изначально не был добавлен.
Теперь перейдем к функциям аутентификации :
Включите анонимную аутентификацию с помощью IUSR :
Включите проверку подлинности Windows , затем щелкните правой кнопкой мыши, чтобы задать поставщиков .
NTLM должно быть FIRST!
Затем проверьте это в разделе Дополнительные настройки. .. расширенная защита — Принять и включить Kernel-аутентификация в режиме CHECKED:
Сделав это, я вернулся к своему веб-приложению, щелкнул ссылку «Обзор» и вошел в систему без необходимости снова вводить свои учетные данные.
Я надеюсь, что это окажется полезным для многих из вас, и я надеюсь, что это будет полезно и для меня позже.
Поделиться jp2code 07 января 2015 в 20:32

54

Только ради блага других людей. Если ошибка имеет значение 401.1 Unauthorized , а код ошибки соответствует 0xc000006d, то на самом деле вы сталкиваетесь с защитой «feature», которая блокирует запросы к FQDN или пользовательским заголовкам хоста, которые не соответствуют имени вашей локальной машины:
Следуйте этой статье поддержки, чтобы устранить проблему:
https://webconnection.west-wind.com/docs/_4gi0ql5jb.htm (оригинал, ныне несуществующий: http://support.microsoft.com/kb/896861 )
Из статьи поддержки, чтобы убедиться, что она не потеряется:
Обходной путь-это взлом реестра, который отключает эту политику явно.
Чтобы выполнить это конфигурация вручную найдите этот ключ в реестре на сервере:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
и отредактируйте или добавьте новый ключ:
DisableLoopbackCheck (DWORD)
then sent the value to 1 to disable the loopback check (local authentication works), or to 0 (local authentication is not allowed).
Or more easily you can use Powershell:
New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword
Это похоже на недавние сборки Windows 10 (1803 и более поздние?) также требуется этот параметр конфигурации для локальной аутентификации.
Это заняло у меня некоторое время, потому что комментарии всех остальных здесь не помогли мне. Я нашел эту статью, и она исправила ее!
Поделиться kamranicus 28 октября 2013 в 18:04

26

У меня была аналогичная проблема, из-за которой я хотел защитить только определенную часть своего веб-сайта. Все работало хорошо, за исключением IE. У меня включена как анонимная, так и Windows аутентификация. Для анонимного идентификатора устанавливается идентификатор пула приложений. Проблема заключалась в аутентификации Windows. После некоторого копания я запустил fiddler и обнаружил, что он использует Kerberos в качестве поставщика (на самом деле он настроен на согласование по умолчанию). Я переключил его на NTLM, и это все исправило. HTH
Дауди
Поделиться Daudi 11 апреля 2011 в 18:22
Windows Инициализации Проверки Подлинности ASP.net
В проекте ASP.net WebForms мы в настоящее время используем проверку подлинности форм, но клиент хочет использовать вместо этого проверку подлинности Windows. Поэтому я изменил web.config, чтобы использовать аутентификацию Windows. Однако приложение нуждается в некотором пользовательском вводе и…
Что Касается Проверки Подлинности .Net Windows
У меня есть веб-приложение, которое настроено на использование аутентификации windows. Этим пользуются люди по всему штату. Эти пользователи не входят в наш AD и проходят аутентификацию в базе данных, когда пытаются войти в систему. После успешного входа в систему ресурсы, к которым пользователь…

19

Добавьте разрешение [Пользователи домена] в свою веб-безопасность.
Щелкните правой кнопкой мыши на вашем сайте в IIS в папке Сайты
Нажмите кнопку Изменить разрешения…
Выберите вкладку Безопасность
В разделе Группа или имена пользователей нажмите кнопку Изменить…
Во всплывающем окне Разрешения под именами групп или пользователей нажмите кнопку Добавить…
Введите [Пользователи домена] в поле имена объектов для выбора текстовой области и нажмите OK, чтобы применить изменение
Нажмите кнопку OK, чтобы закрыть всплывающее окно Разрешений
Нажмите OK, чтобы закрыть всплывающее окно Свойств и применить новые настройки
Поделиться Harry 30 ноября 2012 в 00:59

11

Не создавайте ошибок на своем сервере, меняя все. Если у вас есть приглашение windows для входа в систему при использовании проверки подлинности Windows в 2008 R2, просто перейдите в Providers и переместите UP NTLM для каждого приложения. Когда Negotiate является первым в списке, проверка подлинности Windows может перестать работать для конкретного приложения в 2008 R2, и вам может быть предложено ввести имя пользователя и пароль, чем никогда не будет работать. Это иногда происходит, когда вы обновили свое приложение. Просто убедитесь, что NTLM стоит первым в списке, и вы никогда больше не увидите эту проблему.
Поделиться Slo 04 июля 2013 в 19:15

10

Если у вашего URL есть точки в доменном имени, IE будет относиться к нему как к интернет-адресу, а не к локальному. У вас есть по крайней мере два варианта:
Получите псевдоним для использования в URL для замены server.domain. Например, myapp.
Выполните следующие действия на своем компьютере.
Перейдите на сайт и отмените диалоговое окно входа в систему. Пусть это произойдет:
В настройках IE:
Поделиться Bob Horn 05 октября 2016 в 13:48

6

Это исправило все для меня.
Мой сервер и клиентский ПК Windows 7 и находятся в одном домене
в iis7.5-enable проверка подлинности windows для вашей Интрасети(отключите все другие проверки подлинности.. также нет необходимости упоминать аутентификацию windows в файле web.config
затем перейдите на клиент PC .. IE8 или 9 — Инструменты-интернет Options-Security-Local Intranet-Sites-advanced-Add вашего сайта(снимите «require server verfi…» ticketmark..no нужно
IE8 или 9 — Инструменты-Интернет Options-Security-Local Интрасеть-Пользовательский level-userauthentication-logon-select автоматический вход в систему с текущим именем пользователя и паролем
сохраните это settings..you.. Больше никаких запросов на имя пользователя и пароль.
Убедитесь , что, поскольку ваш клиентский компьютер является частью домена, у вас должен быть GPO для этих настроек,.. orelse этот параметр вернется, когда пользователь войдет в windows в следующий раз
Поделиться Jose Arun 21 октября 2012 в 16:21

5

WindowsIdentity.GetCurrent правильно: вы должны получить пользователя APPPOOL. Это связано с тем, что процесс ASP.NET, выполняющий ваш код, является текущим идентификатором. Если вы хотите, чтобы он вернул пользователю идентификатор сайта, вам нужно будет добавить следующую строку в свой web.config:
<identity impersonate="true" />
Это приводит к тому, что процесс принимает личность пользователя, запрашивающего страницу. Все действия будут выполняться от их имени, поэтому любые попытки чтения папок в сети или доступа к ресурсам базы данных и тому подобное будут означать, что текущему пользователю потребуются разрешения на эти действия. Вы можете прочитать больше о олицетворении здесь . Обратите внимание, что в зависимости от того, как настроена топология веб-сервера/сервера баз данных, при включенном олицетворении могут возникнуть проблемы с делегированием.
Но ваша первоначальная проблема заключается в том, что, похоже, личность не может быть определена, и вы получаете всплывающее окно входа в систему. Я отмечу, что вам не нужен блок <deny> , если вы отключили анонимную аутентификацию в IIS. Мы никогда не включаем его (за исключением специальных блоков <location> и т. Д.), Поэтому я бы сказал, что вы можете попробовать удалить его и повторить попытку. Хотя все остальное звучит правильно.
Вы не указали, какой пользователь запускает пул приложений в IIS. Это пользовательская учетная запись или учетная запись по умолчанию? Если это пользовательская учетная запись, является ли она учетной записью домена или локальной учетной записью на веб-сервере? Пользовательские учетные записи иногда могут потребовать еще нескольких шагов, таких как регистрация SPN. Кроме того, может возникнуть проблема с пользовательской учетной записью, не имеющей разрешения в AD для разрешения учетной записи входящего пользователя.
Вы также можете проверить журналы IIS, чтобы узнать, какой ответ возвращается. Скорее всего, это будет 401, но после него должен быть дополнительный номер, например 401.2 или что-то в этом роде. Это под-число иногда может помочь определить основную проблему. В этой статье KB перечислены пять.
Поделиться Sean Hanley 28 ноября 2011 в 18:13

4

Может быть связано с браузером. Если вы используете IE, вы можете перейти в Дополнительные настройки и проверить, что «Enable Windows Integrated Authentication» checkbox проверено.
Поделиться Dante 23 марта 2011 в 09:37

4

В моем случае настройки авторизации были настроены неправильно.
Я должен был
откройте Правила авторизации .NET в менеджере IIS
и удалите правило Запрета
Поделиться johnecon 10 февраля 2015 в 14:05

4

В нашей Интрасети проблема была решена на стороне клиента путем настройки параметров безопасности, как показано здесь. Любой из флажков справа работал на нас.
Поделиться mosheb 29 июля 2015 в 15:23

2

Я только что решил аналогичную проблему с приложением ASP.Net.
Симптомы: Я мог бы войти в свое приложение, используя локального пользователя, но не пользователя домена, даже если машина была правильно присоединена к домену (как вы говорите в своем дополнительном примечании). В средстве просмотра событий безопасности произошло событие с ID=4625 «Domain sid inconsistent».
Решение: Я нашел решение здесь . Проблема заключалась в том, что мои тестовые машины клонировали виртуальные машины (Windows Server 2008 R2; один контроллер домена и один веб-сервер). У обоих была одна и та же машина SID, что, по-видимому, вызвало проблемы. Вот что я сделал:
Удалите веб — сервер из домена.
Запустите c:\Windows\System32\Sysprep\Sysprep.exe в VM.
Перезагрузите VM.
Присоедините веб — сервер к домену.
В процессе вы теряете некоторые настройки (пользовательские настройки, статический IP, воссоздание самозаверяющего сертификата), но теперь, когда я их воссоздал, все работает правильно.
Поделиться Matthieu 17 января 2012 в 17:29

2

У меня тоже была такая же проблема. Перепробовал большинство вещей, найденных на этом и других форумах.
Наконец-то добился успеха, сделав немного собственного RnD.
Я вошел в настройки IIS, а затем в параметры разрешения моего веб-сайта добавил группу пользователей домена Организации.
Теперь, когда всем пользователям моего домена был предоставлен доступ к этому веб-сайту, я не столкнулся с этой проблемой.
Надеюсь, это поможет
Поделиться Saurabh 19 сентября 2013 в 11:21

2

Я попробовал описанные выше трюки с конфигурацией IIS и взломом реестра с обратной связью, а также пересмотрел и воссоздал разрешения пула приложений и дюжину других вещей, но все равно не смог избавиться от цикла аутентификации, запущенного на моей рабочей станции разработки с помощью IIS Express или IIS 7.5, из локального или удаленного сеанса просмотра. Я получил четыре ответа о состоянии 401.2 и пустую страницу. Точно такой же сайт, развернутый на моем промежуточном сервере IIS 8.5, работает безупречно.
Наконец, я заметил, что markup в теле ответа, которое было оставлено пустым браузером, содержало страницу по умолчанию для успешного входа в систему. Я определил, что пользовательская обработка ошибок для ASP.NET и HTTP для ошибки 401 предотвращает/вмешивается в аутентификацию Windows на моей рабочей станции, но не на промежуточном сервере. Я провел несколько часов, возясь с этим, но как только я удалил пользовательскую обработку только для ошибки 401, рабочая станция вернулась в нормальное состояние. Я представляю это как еще один способ выстрелить в собственную ногу.
Поделиться Mike M 09 мая 2017 в 20:45

1

Вы пробовали войти в систему с префиксом домена, например DOMAIN\Username? IIS 6 по умолчанию используется хост-компьютер в качестве домена по умолчанию, поэтому указание домена при входе в систему может решить проблему.
Поделиться chalemic 28 ноября 2011 в 17:39

0

Windows проверка подлинности в IIS7.0 или IIS7.5 не работает с kerberos (поставщик=Согласование) когда идентификатор пула приложений равен ApplicationPoolIdentity Необходимо использовать сетевую службу или другую встроенную учетную запись. Другая возможность состоит в том, чтобы использовать NTLM, чтобы заставить Windows Authenticatio работать (в Windows аутентификации, провайдеры, ставят NTLM сверху или удаляют согласование)
крис ван де виджвер
Поделиться Chris van de vijver 14 ноября 2013 в 16:05

0

У меня была та же проблема, потому что пользователь (идентификатор), который я использовал в пуле приложений, не соответствовал группе IIS_IUSRS. Добавил пользователя в группу и все работает
Поделиться user3731689 10 июля 2014 в 15:24

0

В моем случае решением было (в дополнение к предложенным выше корректировкам) перезапустить my/users’ локальный компьютер разработки / IIS (хост-сервер). Мой пользователь только что был добавлен в недавно созданную группу безопасности AD, и политика не применялась к учетной записи пользователя AD, пока я не вышел из системы/не перезагрузил компьютер.
Надеюсь, это кому-нибудь поможет.
Поделиться ukie 04 февраля 2016 в 22:11

0

Я столкнулся с той же проблемой с запросом учетных данных, и сделал быстрый поиск, и ничто в Интернете не исправило бы это. Потребовалось некоторое время, чтобы найти проблему, глупую.
В IIS -> Предварительная настройка -> Учетные данные физического пути (пусто)
Как только я добавлю машину ID (domain/user), которая имеет доступ к VM/server,, запрос пароля прекратится.
Надеюсь, это поможет
Поделиться kao 14 ноября 2016 в 03:39

0

У меня была эта проблема на .net core 2, и после просмотра большинства предложений отсюда кажется, что мы пропустили настройку на web.config
<aspNetCore processPath="dotnet" arguments=".\app.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />
Правильная настройка была forwardWindowsAuthToken=»true» , что сейчас кажется очевидным, но когда существует так много ситуаций для одной и той же проблемы, ее труднее определить
Edit: я также нашел полезной следующую статью Msdn, в которой рассматривается устранение неполадок.
Поделиться eugen 22 ноября 2017 в 10:10

-1

У меня возникла та же проблема, и она была решена путем изменения идентификатора пула приложений пула приложений, в котором работает веб-приложение, на NetworkService
Поделиться Syed 25 ноября 2016 в 17:16
Похожие вопросы:

Незначительный запрос о проверке подлинности windows с использованием C# и пользовательских ролей
У меня есть visual studio, установленный на моей локальной машине, и проект MVC присутствует для сервера разработки. Я должен использовать проверку подлинности windows, чтобы увидеть, если…

Настройка IIS с помощью Powershell-включить проверку подлинности форм
Мой IIS выглядит так: Sites -> Default Web Site -> MyWebApp Тогда возникает вопрос: Как включить проверку подлинности форм на MyWebApp? Я хочу изменить или отредактировать анонимный доступ,…

Windows аутентификация не работает в IIS 7.5
У меня возникли проблемы с получением аутентификации windows для работы на IIS 7.5. Приложение представляет собой внутренний сайт, построенный в asp.net MVC 3. Пул приложений использует…

Веб-Служба Проверки Подлинности Windows
Я добавил веб-службу к существующему приложению интрасети asp.net. Цель состоит в том, чтобы предоставить функциональные возможности другим приложениям интрасети в том же домене. Приложение…

Проверка подлинности Windows Active Directory для пользователей интрасети и проверка подлинности форм для пользователей Интернета
Как реализовать проверку подлинности Windows Active Directory для пользователей интрасети и проверку подлинности форм для пользователей интернета, я нашел много примеров в интернете, объясняющих…

Windows Инициализации Проверки Подлинности ASP.net
В проекте ASP.net WebForms мы в настоящее время используем проверку подлинности форм, но клиент хочет использовать вместо этого проверку подлинности Windows. Поэтому я изменил web.config, чтобы…

Что Касается Проверки Подлинности .Net Windows
У меня есть веб-приложение, которое настроено на использование аутентификации windows. Этим пользуются люди по всему штату. Эти пользователи не входят в наш AD и проходят аутентификацию в базе…

Как отключить встроенную аутентификацию windows в Chrome
Я использовал, чтобы быть в состоянии отключить встроенную проверку подлинности windows путем обновления параметров в IE. В последнее время это больше не работает. Что-то изменилось в последних…

Встроенная проверка подлинности Windows в Microsoft Edge
Я пытаюсь реализовать интегрированную аутентификацию Windows на Edge, но она всегда запрашивает у меня учетные данные, в то время как интегрированная аутентификация Windows работает для IE, Chrome и…

Обычная проверка подлинности вместо AAD (Azure Active Directory) проверка подлинности
мое приложение Microsoft Teams должно получить доступ к веб-службе REST, использующей базовую проверку подлинности. учебники, похоже, только показывают, как это сделать для аутентификации с помощью…
Устранение ошибок, возникающих при присоединении компьютеров под управлением Windows к домену — Windows Server
12.04.2020
8 минут на чтение
В этой статье
В этой статье описывается несколько распространенных сообщений об ошибках, которые могут возникнуть при присоединении клиентских компьютеров под управлением Windows к домену. В этой статье также представлены рекомендации по устранению этих ошибок.
Применимо к: Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 4341920
Где найти файл Netsetup.log
Клиенты Windows регистрируют сведения об операциях присоединения к домену в файле% windir% \ debug \ Netsetup.log.
Сообщения об ошибках сети и их решения
Ошибка 1
Попытка разрешить DNS-имя контроллера домена в присоединяемом домене не удалась. Убедитесь, что этот клиент настроен для доступа к DNS-серверу, который может разрешать DNS-имена в целевом домене.
Разрешение
При вводе имени домена убедитесь, что вы вводите имя системы доменных имен (DNS), а не имя базовой сетевой системы ввода-вывода (NetBIOS). Например, если DNS-имя целевого домена — contoso.com , убедитесь, что вы ввели contoso.com вместо имени домена NetBIOS «contoso».
Кроме того, убедитесь, что компьютер может подключиться к DNS-серверу, на котором размещена зона DNS целевого домена, или может разрешать DNS-имена в этом домене.Убедитесь, что на этом клиенте настроен правильный DNS-сервер в качестве предпочтительного DNS-сервера и что у клиента есть возможность подключения к этому серверу. Чтобы убедиться в этом, вы можете запустить одну из следующих команд:
nltest / dsgetdc: <доменное имя netbios> / force
nltest / dsgetdc: <доменное имя DNS> / force
Ошибка 2
Попытка разрешить DNS-имя контроллера домена в присоединяемом домене не удалась. Убедитесь, что этот клиент настроен для доступа к DNS-серверу, который может разрешать DNS-имена в целевом домене.
Разрешение
При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.
Кроме того, убедитесь, что компьютер может подключиться к DNS-серверу, на котором размещена зона DNS целевого домена, или может разрешать DNS-имена в этом домене. Убедитесь, что на этом клиенте настроен правильный DNS-сервер в качестве предпочтительного DNS-сервера и что у клиента есть возможность подключения к этому серверу. Чтобы убедиться в этом, вы можете запустить одну из следующих команд:
nltest / dsgetdc: <доменное имя netbios> / force
nltest / dsgetdc: <доменное имя DNS> / force
Ошибка 3
Произведена попытка операции с несуществующим сетевым подключением.
Разрешение
При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS. Кроме того, перезагрузите компьютер, прежде чем пытаться присоединить компьютер к домену.
Ошибка 4
Множественные подключения к серверу или общему ресурсу одним и тем же пользователем с использованием более одного имени пользователя не разрешены. Отключите все предыдущие подключения к серверу или общему ресурсу и повторите попытку.
Разрешение
Перезагрузите компьютер, который вы пытаетесь присоединить к домену, чтобы убедиться, что нет скрытых подключений ни к одному из серверов домена.
При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.
Ошибка 5
Имя сети не может быть найдено.
Разрешение
Убедитесь, что компьютер может подключиться к DNS-серверу, на котором размещена зона DNS целевого домена, или может разрешать DNS-имена в этом домене. Убедитесь, что на этом клиенте настроен правильный DNS-сервер в качестве предпочтительного DNS-сервера и что у клиента есть возможность подключения к этому серверу.Чтобы убедиться в этом, вы можете запустить одну из следующих команд:
nltest / dsgetdc: <доменное имя netbios> / force
nltest / dsgetdc: <доменное имя DNS> / force
При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.
Кроме того, вы можете обновить драйвер сетевого адаптера.
Ошибка 6
В данный момент невозможно установить больше подключений к этому удаленному компьютеру, потому что уже установлено столько подключений, сколько компьютер может принять.
Разрешение
Перед присоединением компьютера к домену убедитесь, что вы очистили все подключенные подключения к любым дискам.
Перезагрузите компьютер, который вы пытаетесь присоединить к домену, чтобы убедиться, что нет скрытых подключений ни к одному из серверов домена.
При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.
Ошибка может быть временной. Попробуйте позже. Если проблема не устранена, проверьте состояние контроллера домена, к которому подключается клиент (активные подключения, сетевое подключение и т. Д.).Вы можете перезапустить контроллер домена, если проблема не исчезнет.
Ошибка 7
Недопустимый формат указанного сетевого имени.
Разрешение
Убедитесь, что компьютер может подключиться к DNS-серверу, на котором размещена зона DNS целевого домена, или может разрешать DNS-имена в этом домене. Убедитесь, что на этом клиенте настроен правильный DNS-сервер в качестве предпочтительного DNS-сервера и что у клиента есть возможность подключения к этому серверу. Чтобы убедиться в этом, вы можете запустить одну из следующих команд:
nltest / dsgetdc: <доменное имя netbios> / force
nltest / dsgetdc: <доменное имя DNS> / force
При вводе имени домена убедитесь, что вы вводите имя DNS, а не имя NetBIOS.Убедитесь, что для сетевого адаптера клиентского компьютера установлены самые последние версии драйверов. Проверьте возможность подключения между присоединяемым клиентом и целевым контроллером домена через требуемые порты и протоколы. Отключите функцию разгрузки TCP Chimney и разгрузку IP.
Ошибка 8
Служба каталогов исчерпала пул относительных идентификаторов.
Разрешение
Убедитесь, что контроллер домена, на котором размещен хозяин операций с относительным идентификатором (RID), находится в сети и работает.Дополнительные сведения см. В разделе Событие с кодом 16650: не удалось инициализировать распределитель идентификатора учетной записи в Windows Server.
Примечание
Вы можете использовать команду netdom query fsmo , чтобы определить, какой DC имеет роль RID Master.
Убедитесь, что Active Directory реплицируется между всеми контроллерами домена. Вы можете использовать следующую команду для обнаружения любых ошибок:
repadmin / replsummary / bysrc / bydest / sort: delta
Ошибка 9
Удаленный вызов процедуры завершился неудачно и не был выполнен.
Разрешение
Убедитесь, что у вас установлены самые последние версии драйверов для сетевого адаптера клиентского компьютера. Проверьте возможность подключения между присоединяемым клиентом и целевым контроллером домена через требуемые порты и протоколы. Отключите функцию разгрузки TCP Chimney и разгрузку IP.
Эта проблема также может быть вызвана одним из следующих условий:
Сетевое устройство (маршрутизатор, брандмауэр или устройство VPN) блокирует подключение через порты и протоколы, которые используются протоколом MSRPC.
Сетевое устройство (маршрутизатор, брандмауэр или устройство VPN) отклоняет сетевые пакеты между клиентом, к которому подключается, и контроллером домена.
Ошибка 10
Не удалось изменить DNS-имя первичного домена этого компьютера на «». Имя останется «.». Указанный сервер не может выполнить операцию.
Разрешение
Эта ошибка возникает при использовании пользовательского интерфейса присоединения к домену для присоединения компьютера рабочей группы Windows 7 или Windows Server 2008 R2 к домену Active Directory путем указания целевого домена DNS.Чтобы исправить эту ошибку, см. Раздел 2018583 При присоединении к домену Windows 7 или Windows Server 2008 R2 отображается ошибка «Изменение DNS-имени основного домена этого компьютера на« сбой …. ».
Сообщения об ошибках аутентификации и их решения
Ошибка 1
Вы превысили максимальное количество учетных записей компьютеров, которые вы можете создать в этом домене.
Разрешение
Убедитесь, что у вас есть разрешения на добавление компьютеров в домен и что вы не превысили квоту, установленную администратором домена.
Чтобы присоединить компьютер к домену, учетной записи пользователя должны быть предоставлены права Создать объект компьютера в Active Directory.
Примечание
По умолчанию пользователь без прав администратора может присоединить максимум 10 компьютеров к домену Active Directory.
Ошибка 2
Ошибка входа в систему: неверное имя целевой учетной записи.
Разрешение
Убедитесь, что контроллеры домена (DC) зарегистрированы с использованием правильных IP-адресов на DNS-сервере, и что их имена участников-служб (SPN) правильно зарегистрированы в их учетных записях Active Directory.
Ошибка 3
Ошибка входа в систему: пользователю не предоставлен запрошенный тип входа в систему на этом компьютере.
Разрешение
Убедитесь, что у вас есть разрешения на добавление компьютеров в домен. Чтобы присоединить компьютер к домену, учетной записи пользователя должно быть предоставлено разрешение Создать объект компьютера в Active Directory.
Кроме того, убедитесь, что указанной учетной записи пользователя разрешен локальный вход на клиентский компьютер.Для этого настройте параметр Разрешить локальный вход в систему в групповой политике в разделе Конфигурация компьютера> Параметры Windows> Параметры безопасности> Локальные политики> Назначение прав пользователя .
Ошибка 4
Ошибка входа в систему: неизвестное имя пользователя или неверный пароль.
Разрешение
Убедитесь, что вы используете правильную комбинацию имени пользователя и пароля существующей учетной записи пользователя Active Directory, когда вам будет предложено ввести учетные данные для добавления компьютера в домен.
Ошибка 5
Не было выполнено сопоставление между именами учетных записей и идентификаторами безопасности.
Разрешение
Эта ошибка, вероятно, является временной ошибкой, которая регистрируется, когда присоединение к домену выполняет поиск в целевом домене, чтобы определить, была ли уже создана соответствующая учетная запись компьютера или операция присоединения должна динамически создавать учетную запись компьютера в целевом домене.
Ошибка 6
Недостаточно памяти для выполнения этой операции.
Разрешение
Эта ошибка может возникать, если размер маркера Kerberos превышает максимальный размер по умолчанию. В этой ситуации необходимо увеличить размер токена Kerberos компьютера, который вы пытаетесь присоединить к домену. Дополнительные сведения см. В следующих статьях базы знаний:
935744 Сообщение об ошибке «Недостаточно памяти для выполнения этой операции» при использовании контроллера домена для присоединения компьютера к домену
327825 Проблемы с проверкой подлинности Kerberos, когда пользователь принадлежит много групп
Ошибка 7
Учетная запись не авторизована для входа с этой станции.
Разрешение
Эта проблема связана с несоответствием параметров подписи SMB между клиентским компьютером и контроллером домена, с которым связываются для операции присоединения к домену. Просмотрите следующую документацию для дальнейшего изучения текущих и рекомендуемых значений в вашей среде:
281648 Сообщение об ошибке: Учетная запись не авторизована для входа с этой станции 823659 Проблемы с клиентом, сервисом и программой могут возникнуть, если вы измените настройки безопасности и назначения прав пользователей
Ошибка 8
Учетная запись, указанная для этой службы, отличается от учетной записи, указанной для других служб, работающих в том же процессе.
Разрешение
Убедитесь, что на контроллере домена, через который вы пытаетесь присоединиться к домену, запущена служба времени Windows.
Устранение неполадок при проверке подлинности | Документы Microsoft
07.08.2020
10 минут на чтение
В этой статье
Применимо к: Windows Server 2022, Windows Server 2019, Windows Server 2016
В этом разделе содержится информация об устранении неполадок, связанных с проблемами, которые могут возникнуть у пользователей при попытке подключиться к DirectAccess с использованием проверки подлинности OTP.События, связанные с DirectAccerss OTP, регистрируются на клиентском компьютере в средстве просмотра событий в разделе Журналы приложений и служб / Microsoft / Windows / OtpCredentialProvider . Убедитесь, что этот журнал включен при устранении неполадок с DirectAccess OTP.
Не удалось получить доступ к ЦС, который выдает сертификаты OTP
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента).Не удалось подать заявку на сертификат OTP для пользователя на сервере CA , запрос не удался, возможные причины сбоя: имя сервера CA не может быть разрешено, сервер CA недоступен через первый туннель DirectAccess или невозможно установить соединение с сервером CA.
Причина
Пользователь предоставил действительный одноразовый пароль, и сервер DirectAccess подписал запрос сертификата; однако клиентский компьютер не может связаться с центром сертификации, который выдает сертификаты OTP, чтобы завершить процесс регистрации.
Раствор
На сервере DirectAccess выполните следующие команды Windows PowerShell:
Получите список настроенных центров сертификации, выдающих OTP, и проверьте значение «CAServer»: Get-DAOtpAuthentication
Убедитесь, что центры сертификации настроены как серверы управления: Get-DAMgmtServer -Type All
Убедитесь, что на клиентском компьютере установлен туннель инфраструктуры: в консоли брандмауэра Windows с расширенной безопасностью разверните Мониторинг / сопоставления безопасности , щелкните Основной режим и убедитесь, что сопоставления безопасности IPsec отображаются с правильным удаленным адреса для вашей конфигурации DirectAccess.
Проблемы с подключением к серверу DirectAccess
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента)
Одна из следующих ошибок:
Невозможно установить соединение с сервером удаленного доступа с использованием базового пути и порта .Код ошибки: .
Учетные данные пользователя не могут быть отправлены на сервер удаленного доступа с использованием базового пути и порта . Код ошибки: .
Не был получен ответ от сервера удаленного доступа с использованием базового пути и порта .Код ошибки: .
Причина
Клиентский компьютер не может получить доступ к серверу DirectAccess через Интернет из-за проблем с сетью или из-за неправильно настроенного сервера IIS на сервере DirectAccess.
Раствор
Убедитесь, что подключение к Интернету на клиентском компьютере работает, а также убедитесь, что служба DirectAccess работает и доступна через Интернет.
Не удалось подать заявку на получение сертификата входа в DirectAccess OTP
Сценарий .Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента). Не удалось подать заявку на сертификат от CA . Запрос не был подписан сертификатом подписи OTP должным образом, или у пользователя нет разрешения на регистрацию.
Причина
Одноразовый пароль, предоставленный пользователем, был правильным, но выдающий центр сертификации (ЦС) отказался выдать сертификат входа в систему OTP.Запрос сертификата может быть неправильно подписан с помощью правильного EKU (политика приложения центра регистрации OTP), или у пользователя нет разрешения «Enroll» в шаблоне DA OTP.
Раствор
Убедитесь, что пользователи DirectAccess OTP имеют разрешение на регистрацию для сертификата входа в систему DirectAccess OTP и что правильная «Политика приложения» включена в шаблон подписи центра регистрации DA OTP. Также убедитесь, что сертификат центра регистрации DirectAccess на сервере удаленного доступа действителен.См. 3.2 Планирование шаблона сертификата OTP и 3.3 Планирование сертификата центра регистрации.
Отсутствует или недействителен сертификат учетной записи компьютера
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента). Аутентификация OTP не может быть завершена, поскольку сертификат компьютера, необходимый для OTP, не может быть найден в хранилище сертификатов локального компьютера.
Причина
Для аутентификации DirectAccess OTP требуется сертификат клиентского компьютера для установления SSL-соединения с сервером DirectAccess; однако сертификат клиентского компьютера не найден или недействителен, например, если срок действия сертификата истек.
Раствор
Убедитесь, что сертификат компьютера существует и действителен:
На клиентском компьютере в консоли сертификатов MMC для учетной записи локального компьютера откройте Personal / Certificates .
Убедитесь, что выдан сертификат, соответствующий имени компьютера, и дважды щелкните сертификат.
В диалоговом окне Сертификат на вкладке Путь к сертификату в разделе Статус сертификата убедитесь, что там написано «Этот сертификат в порядке».
Если действительный сертификат не найден, удалите недействительный сертификат (если он существует) и повторно подайте заявку на сертификат компьютера, запустив gpupdate / Force из командной строки с повышенными привилегиями или перезапустив клиентский компьютер.
Отсутствует ЦС, который выдает сертификаты OTP
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента). OTP-аутентификация не может быть завершена, потому что DA-сервер не вернул адрес выдающего CA.
Причина
Либо нет настроенных центров сертификации, выдающих сертификаты OTP, либо все настроенные центры сертификации, которые выдают сертификаты OTP, не отвечают.
Раствор
Используйте следующую команду, чтобы получить список центров сертификации, которые выдают сертификаты OTP (имя центра сертификации отображается в CAServer): Get-DAOtpAuthentication .
Если не настроены центры сертификации:
Используйте команду Set-DAOtpAuthentication или консоль управления удаленным доступом, чтобы настроить центры сертификации, которые выдают сертификат входа OTP DirectAccess.
Примените новую конфигурацию и заставьте клиентов обновить параметры GPO DirectAccess, запустив gpupdate / Force из командной строки с повышенными привилегиями или перезапустив клиентский компьютер.
Если настроены центры сертификации, убедитесь, что они подключены к сети и отвечают на запросы на регистрацию.
Неверно настроенный адрес сервера DirectAccess
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента). OTP-аутентификация не может быть завершена должным образом. Невозможно определить имя или адрес сервера удаленного доступа.Код ошибки: . Параметры DirectAccess должны быть проверены администратором сервера.
Причина
Адрес сервера DirectAccess настроен неправильно.
Раствор
Проверьте настроенный адрес сервера DirectAccess с помощью Get-DirectAccess и исправьте адрес, если он настроен неправильно.
Убедитесь, что на клиентском компьютере развернуты последние настройки, запустив gpupdate / force из командной строки с повышенными привилегиями или перезапустив клиентский компьютер.
Не удалось создать запрос сертификата входа в систему с помощью OTP
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента). Запрос сертификата для аутентификации OTP не может быть инициализирован. Либо не удается сгенерировать закрытый ключ, либо пользователь не может получить доступ к шаблону сертификата на контроллере домена.
Причина
Есть две возможные причины этой ошибки:
Раствор
Проверьте настройки разрешений в шаблоне входа OTP и убедитесь, что все пользователи, подготовленные для DirectAccess OTP, имеют разрешение «Чтение».
Убедитесь, что контроллер домена настроен как сервер управления и что клиентский компьютер может подключиться к контроллеру домена через туннель инфраструктуры. См. 3.2 Планирование шаблона сертификата OTP.
Нет связи с контроллером домена
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента).Невозможно установить соединение с контроллером домена для аутентификации OTP. Код ошибки: .
Причина
Есть две возможные причины этой ошибки:
Раствор
Убедитесь, что контроллер домена настроен как сервер управления, выполнив следующую команду из командной строки PowerShell: Get-DAMgmtServer -Type All .
Убедитесь, что клиентский компьютер может подключиться к контроллеру домена через туннель инфраструктуры.
Провайдеру OTP требуется запрос / ответ
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента). OTP-аутентификация с сервером удаленного доступа () для пользователя () требовала запроса от пользователя.
Причина
Используемый поставщик OTP требует, чтобы пользователь предоставил дополнительные учетные данные в форме обмена запросами / ответами RADIUS, которые не поддерживаются Windows Server 2012 DirectAccess OTP.
Раствор
Настройте поставщика OTP так, чтобы он не требовал запроса / ответа ни при каких обстоятельствах.
Используется неправильный шаблон входа в систему OTP
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента). Шаблон ЦС, из которого пользователь запросил сертификат, не настроен для выдачи сертификатов OTP.
Причина
Шаблон входа OTP DirectAccess был заменен, и клиентский компьютер пытается пройти аутентификацию с использованием более старого шаблона.
Раствор
Убедитесь, что на клиентском компьютере используется последняя конфигурация OTP, выполнив одно из следующих действий:
Принудительно обновите групповую политику, выполнив следующую команду из командной строки с повышенными привилегиями: gpupdate / Force .
Перезагрузите клиентский компьютер.
Отсутствует сертификат подписи OTP
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента).Сертификат подписи OTP не может быть найден. Запрос на регистрацию сертификата OTP не может быть подписан.
Причина
Сертификат подписи OTP DirectAccess не может быть найден на сервере удаленного доступа; следовательно, запрос сертификата пользователя не может быть подписан сервером удаленного доступа. Либо отсутствует сертификат подписи, либо срок действия сертификата подписи истек, и он не был продлен.
Раствор
Выполните эти действия на сервере удаленного доступа.
Проверьте настроенное имя шаблона сертификата подписи OTP, запустив командлет PowerShell Get-DAOtpAuthentication и проверьте значение SigningCertificateTemplateName .
Используйте оснастку MMC «Сертификаты», чтобы убедиться, что на компьютере существует действительный сертификат, зарегистрированный из этого шаблона.
Если такого сертификата не существует, удалите сертификат с истекшим сроком действия (если он существует) и подайте заявку на получение нового сертификата на основе этого шаблона.
Чтобы создать шаблон сертификата подписи OTP, см. 3.3 Планирование сертификата центра регистрации.
Отсутствует или неверно UPN / DN для пользователя
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (журнал событий клиента)
Одна из следующих ошибок:
Пользователь не может быть аутентифицирован с помощью OTP. Убедитесь, что имя участника-пользователя определено для имени пользователя в Active Directory.Код ошибки: .
Пользователь не может быть аутентифицирован с помощью OTP. Убедитесь, что DN определено для имени пользователя в Active Directory. Код ошибки: .
Получена ошибка (журнал событий сервера)
Имя пользователя, указанное для аутентификации OTP, не существует.
Причина
Пользователь не имеет атрибутов основного имени пользователя (UPN) или отличительного имени (DN), должным образом установленных в учетной записи пользователя, эти свойства необходимы для правильного функционирования DirectAccess OTP.
Раствор
Используйте консоль «Active Directory — пользователи и компьютеры» на контроллере домена, чтобы убедиться, что оба этих атрибута правильно установлены для аутентифицирующего пользователя.
Сертификат OTP не является доверенным для входа в систему
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Причина
ЦС, выдающий сертификаты OTP, отсутствует в корпоративном хранилище NTAuth; поэтому зарегистрированные сертификаты нельзя использовать для входа в систему.Это может происходить в средах с несколькими доменами и несколькими лесами, где междоменное доверие CA не установлено.
Раствор
Убедитесь, что сертификат корня иерархии CA, который выдает сертификаты OTP, установлен в корпоративном хранилище сертификатов NTAuth домена, в котором пользователь пытается пройти аутентификацию.
Windows не может проверить учетные данные пользователя
Сценарий . Пользователь не может пройти аутентификацию с помощью OTP с ошибкой: «Аутентификация не удалась из-за внутренней ошибки»
Получена ошибка (клиентский компьютер).Что-то пошло не так, пока Windows проверяла ваши учетные данные. Повторите попытку или обратитесь за помощью к администратору.
Причина
Протокол проверки подлинности Kerberos не работает, если сертификат входа OTP DirectAccess не включает CRL. Сертификат входа в DirectAccess OTP не включает CRL, потому что:
Шаблон входа DirectAccess OTP был настроен с параметром Не включать информацию об отзыве в выданные сертификаты .
CA настроен не публиковать CRL.
Решение
Чтобы подтвердить причину этой ошибки, в консоли управления удаленным доступом в Шаг 2 Сервер удаленного доступа щелкните Изменить , а затем в мастере настройки сервера удаленного доступа щелкните Шаблоны сертификатов OTP . Запишите шаблон сертификата, используемый для регистрации сертификатов, выданных для проверки подлинности OTP.Откройте консоль центра сертификации, на левой панели щелкните Шаблоны сертификатов , дважды щелкните сертификат входа в систему OTP, чтобы просмотреть свойства шаблона сертификата.
Чтобы решить эту проблему, настройте сертификат для сертификата входа в систему OTP и не устанавливайте флажок Не включать информацию об отзыве в выданные сертификаты на вкладке Сервер диалогового окна свойств шаблона.
На сервере ЦС откройте MMC центра сертификации, щелкните правой кнопкой мыши выдающий ЦС и выберите Свойства .На вкладке Extensions убедитесь, что публикация CRL настроена правильно.
Сообщения «Обнаружена проблема проверки сертификата» и «Невозможно гарантировать подлинность домена, к которому установлено зашифрованное соединение» при попытке открыть веб-сайт
Выпуск
При открытии веб-сайта появляется предупреждающее сообщение о том, что «Обнаружена проблема проверки сертификата » или что «Подлинность домена, к которому установлено зашифрованное соединение, не может быть гарантирована».
Причина
Сайт может быть небезопасным. Существует вероятность того, что злоумышленники могут украсть данные вашей учетной записи и другую личную информацию. Мы не рекомендуем посещать такие сайты.
Для получения подробной информации о том, что может вызвать появление этого сообщения, см. Раздел ниже.
Если предупреждение появляется не для веб-сайтов, а для приложений, установленных на вашем компьютере, это означает, что настройки сканирования зашифрованных соединений по умолчанию были изменены. Чтобы решить эту проблему, восстановите настройки по умолчанию.
Решение
Если вы уверены, что сайт безопасен (например, если это официальная страница вашего банка) и не хотите, чтобы приложение проверяло его в будущем и отображало предупреждения:
Добавьте веб-сайт, на котором отображается предупреждение, в список исключений. См. Инструкции ниже.
Или отключите сканирование зашифрованных соединений. См. Инструкции ниже.
Не рекомендуется полностью отключать проверку защищенных соединений, так как это снизит уровень защиты вашего компьютера.
Если веб-сайт не входит в число тех, которые вы посещаете регулярно, вы можете разрешить его открытие для текущего сеанса. В следующий раз вы снова увидите предупреждение. См. Руководство о том, как разрешить открытие веб-сайта один раз ниже.
Если уведомление появляется на веб-сайте, которым вы не часто пользуетесь, вы можете разрешить открытие его один раз. См. Инструкции ниже.
Если вы не уверены, что веб-сайт безопасен, вы можете проверить его с помощью OpenTip, прежде чем продолжить.
Руководство по интеграции Windows Red Hat Enterprise Linux 7
Глава 3.Использование области
realmd для подключения к домену Active Directory
Система realmd обеспечивает ясный и простой способ обнаружения доменов идентификации и присоединения к ним для достижения прямой интеграции доменов. Он настраивает базовые системные службы Linux, такие как SSSD или Winbind, для подключения к домену.
Глава 2, Использование Active Directory в качестве поставщика удостоверений для SSSD описывает, как использовать демон служб безопасности системы (SSSD) в локальной системе и Active Directory в качестве внутреннего поставщика удостоверений.Обеспечение правильной настройки системы для этого может быть сложной задачей: существует ряд различных параметров конфигурации для каждого возможного поставщика удостоверений и для самого SSSD. Кроме того, вся информация о домене должна быть доступна заранее, а затем должным образом отформатирована в конфигурации SSSD, чтобы SSSD мог интегрировать локальную систему с AD.
Система realmd упрощает эту конфигурацию. Он может выполнять поиск с обнаружением, чтобы определить доступные домены AD и Identity Management, а затем присоединить систему к домену, а также настроить необходимые клиентские службы, используемые для подключения к данному домену идентификации и управления доступом пользователей.Кроме того, поскольку SSSD в качестве базовой службы поддерживает несколько доменов, область realmd также может обнаруживать и поддерживать несколько доменов.
3.1. Поддерживаемые типы доменов и клиенты
Система realmd поддерживает следующие типы доменов:
Следующие клиенты домена поддерживаются realmd :
3.2. Предпосылки для использования области

Чтобы использовать систему realmd , установите пакет realmd.
# yum install realmd
Кроме того, убедитесь, что установлены пакеты oddjob, oddjob-mkhomedir, sssd и adcli. Эти пакеты необходимы для управления системой с помощью области realmd .
Система realmd имеет две основные задачи:
Центральная утилита в области называется областью . Большинство команд realm требуют, чтобы пользователь указал действие, которое должна выполнить утилита, и объект, например домен или учетную запись пользователя, для которого нужно выполнить действие:
область команда аргументы
Например:
царство присоединиться к объявлению.example.com разрешение области имя_пользователя
Таблица 3.1. Команды realmd
Команда Описание
Команды Realm
обнаружение поиска для поиска в сети.
присоединиться Добавить систему в указанный домен.
оставить Удалить систему из указанного домена.
list Список всех настроенных доменов для системы или всех обнаруженных и настроенных доменов.
Команды входа в систему
разрешение Разрешить доступ для определенных пользователей или для всех пользователей в настроенном домене для доступа к локальной системе.
deny Ограничить доступ для определенных пользователей или для всех пользователей в настроенном домене для доступа к локальной системе.
Для получения дополнительной информации о командах realm см. Справочную страницу realm (8).
3.4. Обнаружение идентификационных доменов и присоединение к ним
Команда realm discover возвращает полную конфигурацию домена и список пакетов, которые должны быть установлены для регистрации системы в домене.
Команда realm join затем настраивает локальный компьютер для использования с указанным доменом, настраивая как локальные системные службы, так и записи в идентификационном домене.Процесс, выполняемый объединением областей , включает следующие шаги:
Запуск поискового сканирования для указанного домена.
Автоматическая установка пакетов, необходимых для присоединения системы к домену.
Сюда входят пакеты заданий SSSD и домашнего каталога PAM. Обратите внимание, что для автоматической установки пакетов требуется запуск пакета PackageKit .
Если PackageKit отключен, система предложит вам указать отсутствующие пакеты, и вам потребуется установить их вручную с помощью утилиты yum .
Присоединение к домену путем создания записи учетной записи для системы в каталоге.
Создание файла /etc/krb5.keytab host keytab.
Настройка домена в SSSD и перезапуск службы.
Включение пользователей домена для системных служб в конфигурации PAM и файле /etc/nsswitch.conf .
Обнаружение доменов
При запуске без каких-либо параметров команда realm discover отображает информацию о домене DNS по умолчанию, который является доменом, назначенным через протокол динамической конфигурации хоста (DHCP):
# realm discover объявление.example.com тип: kerberos имя-области: AD.EXAMPLE.COM доменное имя: ad.example.com настроено: нет серверное программное обеспечение: активный каталог клиентское программное обеспечение: sssd требуемый-пакет: oddjob требуемый-пакет: oddjob-mkhomedir требуемый пакет: sssd обязательный-пакет: adcli требуемый-пакет: samba-common
Также возможно запустить обнаружение для определенного домена. Для этого запустите realm discover и добавьте имя домена, который вы хотите обнаружить:
# realm discover ad.example.com
Затем система realmd будет использовать поиск DNS SRV для автоматического поиска контроллеров домена в этом домене.
Для команды realm discover требуется, чтобы был запущен NetworkManager; в частности, это зависит от интерфейса D-Bus NetworkManager. Если ваша система не использует NetworkManager, всегда указывайте имя домена в команде обнаружения области .
Система realmd может обнаруживать домены Active Directory и Identity Management.Если в вашей среде существуют оба домена, вы можете ограничить результаты обнаружения определенным типом сервера, используя параметр --server-software . Например:
# обнаружение области --server-software = активный каталог
Один из атрибутов, возвращаемых при обнаружении, - login-policy , который показывает, разрешено ли пользователям домена входить в систему, как только соединение будет завершено. Если вход в систему не разрешен по умолчанию, вы можете разрешить его вручную с помощью команды realm allow .Для получения дополнительной информации см. Раздел 3.7, «Управление разрешениями на вход для пользователей домена». Для получения дополнительной информации о команде realm discover см. Справочную страницу realm (8). Присоединение к домену Обратите внимание, что для доменов Active Directory необходимо использовать уникальные имена компьютеров. И имя компьютера NetBIOS, и его имя хоста DNS должны быть однозначно определены и соответствовать друг другу. Чтобы присоединить систему к домену идентификации, используйте команду realm join и укажите имя домена: # realm присоединиться к объявлению.example.com realm: присоединился к домену ad.example.com По умолчанию присоединение выполняется от имени администратора домена. Для AD учетная запись администратора называется Администратор ; для IdM он называется admin . Для подключения от имени другого пользователя используйте опцию -U : # realm join ad.example.com -U пользователь Команда сначала пытается подключиться без учетных данных, но при необходимости запрашивает пароль. Если Kerberos правильно настроен в системе Linux, присоединение также может быть выполнено с помощью билета Kerberos для аутентификации. Чтобы выбрать участника Kerberos, используйте параметр -U . # kinit пользователь # realm join ad.example.com -U пользователь Команда realm join принимает несколько других параметров конфигурации. Для получения дополнительной информации о команде realm join см. Справочную страницу realm (8). Пример 3.1. Пример процедуры регистрации системы в домене Запустите команду realm discover , чтобы отобразить информацию о домене. # realm discover ad.example.com ad.example.com тип: kerberos имя-области: AD.EXAMPLE.COM доменное имя: ad.example.com настроено: нет серверное программное обеспечение: активный каталог клиентское программное обеспечение: sssd Запустите команду realm join и передайте ей доменное имя.Укажите пароль администратора, если система запрашивает его. # realm join ad.example.com Пароль для администратора: пароль Обратите внимание, что при обнаружении домена или присоединении к нему realmd проверяет запись DNS SRV: Запись создается по умолчанию при настройке AD, что позволяет обнаруживать ее при обнаружении службы. Тестирование конфигурации системы после присоединения к домену Чтобы проверить, была ли система успешно зарегистрирована в домене, убедитесь, что вы можете войти в систему как пользователь из домена и что информация о пользователе отображается правильно: Запустите команду id user @ domain_name , чтобы отобразить информацию о пользователе из домена. # id user @ ad.example.com uid = 1348601103 ([email protected]) gid = 1348600513 (domain [email protected]) groups = 1348600513 (domain [email protected]) Используя утилиту ssh , войдите в систему как тот же пользователь. # ssh -l пользователь @ ad.example.com linux-client.ad.example.com пароль пользователя @ ad.example.com @ linux-client.ad.example.com: Создание домашнего каталога для user @ ad.example.com. Убедитесь, что утилита pwd распечатывает домашний каталог пользователя. $ pwd /home/ad.example.com/user Убедитесь, что утилита id печатает ту же информацию, что и команда id user @ domain_name из первого шага. $ id uid = 1348601103 ([email protected]) gid = 1348600513 (domain [email protected]) groups = 1348600513 (domain group @ ad.example.com) context = неограниченный_u: неограниченный_r: неограниченный_т: s0-s0: c0.c1023 Утилита kinit также полезна при проверке успешности присоединения к домену. Обратите внимание, что для использования утилиты должен быть установлен пакет krb5-workstation. 3.5. Удаление системы из идентификационного домена Чтобы удалить систему из идентификационного домена, используйте команду realm leave . Команда удаляет конфигурацию домена из SSSD и локальной системы. # realm leave ad.example.com По умолчанию удаление выполняется от имени администратора по умолчанию. Для AD учетная запись администратора называется Администратор ; для IdM он называется admin . Если для присоединения к домену использовался другой пользователь, может потребоваться выполнить удаление от имени этого пользователя. Чтобы указать другого пользователя, используйте опцию -U : # realm leave ad.example.com -U ' AD.ПРИМЕР.COM \ user ' Команда сначала пытается подключиться без учетных данных, но при необходимости запрашивает пароль. Обратите внимание, что когда клиент покидает домен, учетная запись компьютера не удаляется из каталога; удаляется только конфигурация локального клиента. Если вы хотите удалить учетную запись компьютера, выполните команду с указанным параметром --remove . Для получения дополнительной информации о команде realm leave см. Справочную страницу realm (8). Команда realm list перечисляет каждый настроенный домен для системы, а также полную информацию и конфигурацию по умолчанию для этого домена. Это та же информация, что возвращается командой realm discovery , только для домена, который уже находится в конфигурации системы. # список областей --all --name-only ad.example.com Наиболее заметные параметры, принятые в списке областей : - все Параметр --all перечисляет все обнаруженные домены, как настроенные, так и ненастроенные. - только имя Параметр --name-only ограничивает результаты только доменными именами и не отображает детали конфигурации домена. Для получения дополнительной информации о команде realm list см. Справочную страницу realm (8). 3,7. Управление разрешениями на вход для пользователей домена По умолчанию применяется контроль доступа на стороне домена , что означает, что политики входа в систему для пользователей домена определены в самом домене.Это поведение по умолчанию можно переопределить, чтобы использовать управление доступом на стороне клиента . При управлении доступом на стороне клиента разрешение на вход определяется только локальными политиками. Если в домене применяется управление доступом на стороне клиента, вы можете использовать систему realmd для настройки основных правил разрешения или запрета доступа для пользователей из этого домена. Обратите внимание, что эти правила доступа разрешают или запрещают доступ ко всем службам в системе. Более конкретные правила доступа должны быть установлены на конкретном системном ресурсе или в домене. Чтобы установить правила доступа, используйте следующие две команды: запретить царство Команда realm deny просто запрещает доступ всем пользователям в домене. Используйте эту команду с опцией --all . разрешение на владение Команду realm allow можно использовать для: предоставить доступ всем пользователям с помощью параметра --all , например: $ разрешение на владение - все предоставить доступ указанным пользователям, например: $ realm allow user @ example.com $ realm permission ' AD.EXAMPLE.COM \ user ' запретить доступ указанным пользователям с помощью параметра -x , например: $ разрешение области -x ' AD.EXAMPLE.COM \ user ' Обратите внимание, что разрешение доступа в настоящее время работает только для пользователей в основных доменах, но не для пользователей в доверенных доменах. Это связано с тем, что хотя учетные записи пользователей должны содержать доменное имя, SSSD в настоящее время не может предоставить realmd информацию о доступных дочерних доменах. Безопаснее разрешать доступ только специально выбранным пользователям или группам, чем запрещать доступ некоторым, но разрешать доступ всем остальным. Поэтому не рекомендуется разрешать доступ всем по умолчанию, а запрещать его только определенным пользователям с разрешением области -x . Вместо этого Red Hat рекомендует поддерживать политику запрета доступа по умолчанию для всех пользователей и предоставлять доступ только избранным пользователям с использованием разрешения области . Для получения дополнительной информации о командах realm deny и realm allow см. Справочную страницу realm (8). 3.8. Изменение конфигурации пользователя по умолчанию Система realmd поддерживает изменение домашнего каталога пользователя по умолчанию и атрибутов POSIX оболочки. Например, это может потребоваться, когда некоторые атрибуты POSIX не установлены в учетных записях пользователей Windows или когда эти атрибуты отличаются от атрибутов POSIX других пользователей в локальной системе. Чтобы переопределить домашний каталог по умолчанию и атрибуты POSIX оболочки, укажите следующие параметры в разделе [пользователи] в файле / etc / realmd.conf файл: default-home Параметр default-home устанавливает шаблон для создания домашнего каталога для учетных записей, для которых не задан домашний каталог. Общий формат - / home /% d /% u , где % d - это имя домена, а % u - имя пользователя. стандартная оболочка Параметр default-shell определяет оболочку пользователя по умолчанию.Он принимает любую поддерживаемую системную оболочку. Например: [пользователи] по умолчанию-дом = / home /% u по умолчанию-оболочка = / bin / bash Для получения дополнительной информации о параметрах см. Справочную страницу realmd.conf (5). 3.9. Дополнительная конфигурация для записи домена Active Directory Пользовательские настройки для каждого отдельного домена можно определить в файле /etc/realmd.conf . У каждого домена может быть свой собственный раздел конфигурации; название раздела должно совпадать с доменным именем.Например: [ad.example.com] атрибут = значение атрибут = значение Чтобы изменить конфигурацию домена, отредактируйте соответствующий раздел в /etc/realmd.conf . В следующем примере отключается сопоставление идентификаторов для домена ad.example.com , задается принципал хоста и добавляется система в указанное поддерево: [ad.example.com] computer-ou = ou = компьютеры Linux, DC = домен, DC = example, DC = com пользователь-принципал = хост / Linux-клиент @ AD.ПРИМЕР.COM automatic-id-mapping = no # realm join --computer-ou = "ou = Linux Computers, dc = domain, dc = com" --automatic-id-mapping = no --user -principal = host/[email protected] В таблице 3.2, «Параметры конфигурации области» перечислены наиболее важные параметры, которые можно установить в разделе домена по умолчанию в /etc/realmd.conf . Для получения полной информации о доступных параметрах конфигурации см. Realmd.conf (5) справочную страницу. Таблица 3.2. Параметры конфигурации области Параметр Описание computer-ou Задает расположение каталога для добавления учетных записей компьютеров в домен. Это может быть полное DN или RDN относительно корневой записи. Поддерево уже должно существовать. пользователь-участник Устанавливает значение атрибута userPrincipalName учетной записи компьютера для указанного принципала Kerberos. автоматическое сопоставление идентификаторов Устанавливает, следует ли включить сопоставление динамических идентификаторов или отключить сопоставление и использовать атрибуты POSIX, настроенные в Active Directory. Блог цифровой криминалистической экспертизы и реагирования на инциденты SANS | Защита учетных записей привилегированных доменов: углубленная сетевая аутентификация [Примечание автора: это 5 ^-й из серии, состоящей из нескольких частей, посвященной теме «Защита учетных записей привилегированного домена».Моя основная цель - помочь специалистам по реагированию на инциденты защитить свои привилегированные учетные записи при взаимодействии с включенными хостами, хотя я также считаю, что эта информация будет полезна всем, кто занимается администрированием и защитой среды Windows.] Чтобы совпасть с моей недавней веб-трансляцией SANS по защите учетных записей привилегированных доменов, я решил, что пора приступить к работе и опубликовать свои выводы по сетевой аутентификации. Итак, начнем! Чтобы подвести итог этому путешествию, я начал с обсуждения того, как защитить хэши паролей Windows.Затем я немного отвлекся, чтобы поближе познакомиться с хешем LM и, в частности, с тем фактом, что он хранится в памяти, даже если вы реализовали все функции защиты Microsoft, чтобы отключить его. Затем было обсуждение относительно нового открытия в мире InfoSec - того факта, что наши пароли хранятся в памяти в форме, которая может быть легко выгружена в открытый текст. В моей последней статье обсуждались токены доступа и то, как они могут в некоторых случаях позволить злоумышленнику выдать себя за вас в сети.В этой статье я расскажу о сетевой аутентификации в домене Windows. Протоколы сетевой аутентификации Microsoft Назначение протокола сетевой аутентификации - предоставить метод аутентификации пользователя или компьютера в удаленном хранилище учетных данных. В идеале протокол должен обеспечивать надежную криптографию для защиты аутентифицирующих учетных данных от воздействия атак перехвата и воспроизведения. Многие протоколы удаленной аутентификации основаны на механизме запроса-ответа, когда клиент делает запрос к серверу, сервер выдает запрос, а клиент отвечает на этот запрос на основе секрета, известного как клиенту, так и серверу.Это базовая архитектура для устаревших протоколов сетевой аутентификации Microsoft. Другие протоколы сетевой аутентификации используют доверенную стороннюю систему, которая является архитектурой текущего основного протокола аутентификации Microsoft, Kerberos. Давайте кратко рассмотрим собственные протоколы сетевой аутентификации Microsoft: LM (Lan Manager) Запрос-ответ Представленный в конце 80-х вместе с OS / 2, это был основной протокол удаленной аутентификации для версий Windows до Windows NT.Ответ (отклик), который клиент предоставляет на запрос сервера, генерируется из слабого хэша LM. Запрос-ответ NTLM Впервые появившись в Windows NT, основное отличие состоит во включении второго ответа, использующего хэш NT. Если пароль учетной записи поддерживает хеш LM, ответ NTLM от клиента будет включать 2 ответа: ответ на основе хеша LM и другой на основе хеша NT. Если пароль является надежным паролем, который нарушает алгоритм хеширования LM, будет предоставлен только ответ, основанный на хеш-коде NT. Запрос-ответ NTLMv2 В Windows NT 4.0 SP4 был введен ряд улучшений безопасности, в первую очередь взаимная проверка подлинности. Вы также можете увидеть обсуждение LMv2 с NTLMv2. LMv2 - это фактически тот же протокол, что и NTLMv2, за исключением того, что он использует усеченный клиентский запрос для лучшей поддержки «сквозной» доменной аутентификации на устаревших клиентах (я вскоре расскажу о «сквозной» аутентификации). Главный вывод заключается в том, что и LMv2, и NTLMv2 используют только NT-хэш для вычисления ответа серверу, и оба они реализуют взаимную аутентификацию. Kerberos Представленная в Windows 2000, эта система на основе билетов берет свое начало в Массачусетском технологическом институте. Для завершения аутентификации требуется NT-хэш. Вскоре еще много чего можно сказать о Kerberos. Прекрасным единственным источником по этим протоколам является книга Крисофера Хертеля « Реализация CIFS: Общая файловая система Интернета ». Книга доступна бесплатно в Интернете, а в главе «Аутентификация» вы найдете очень подробное обсуждение всех этих протоколов. Все версии Windows, до Windows 8 включительно, поддерживают все предыдущие унаследованные протоколы сетевой аутентификации. Конечно, есть некоторые проблемы со старыми протоколами, которые привели к разработке новых протоколов. Давайте посмотрим на некоторые из этих проблем и то, как Microsoft решила их? И почему нам нужно их опасаться. Проблема 1: Отсутствие взаимной аутентификации Основная проблема с первой версией протоколов запрос-ответ LM и NTLM заключается в том, что единственный объект, который проходит проверку подлинности, - это клиент.Это означает, что при использовании этих протоколов вполне возможно раскрыть конфиденциальную информацию аутентификации мошенническому серверу. Вот как работает процесс запрос-ответ LMv1 / NTLMv1 (обратите внимание, что для простоты на этой диаграмме изображен клиент, аутентифицирующийся на сервере, используя локальную учетную запись на сервере, а не учетную запись домена? Я буду обсуждать «сквозной» домен. аутентификация в ближайшее время): Клиенту необходимо подключиться к серверу, поэтому для аутентификации на сервере выполняется запрос на вход в систему. Сервер говорит: "Конечно, нет проблем, просто ответьте на этот вызов, основываясь на хеш-коде вашего пароля". У клиента есть хэш пароля (хэш LM для запроса-ответа LM, а также хеш NT для запроса-ответа NTLM), поэтому он вычисляет ответ на запрос на основе хешей пароля. Когда это законный сервер, сервер вычисляет ответ так же, как и клиент, поскольку он также знает правильные хэши (для локальной учетной записи). Он сравнивает свой ответ с ответом клиента, и, если они совпадают, клиент успешно прошел аутентификацию. Однако, когда сервер является мошенническим, он получил конфиденциальную информацию для этой учетной записи. У него нет необработанного хэша пароля, который использовался для вычисления ответа, но теперь у него есть вся информация, необходимая для угадывания хэша пароля - у него есть запрос, который он выдал, и правильный ответ от клиента. На практике, вместо того, чтобы вслепую угадывать хэши паролей, наиболее плодотворная атака заключается в том, что злоумышленник запускает статический запрос, для которого он уже предварительно рассчитал множество возможных хэшей (и соответствующих паролей) для этого запроса.Другими словами, злонамеренный сервер может выдать статический вызов, и злоумышленник может использовать предварительно вычисленную радужную таблицу, чтобы определить хэш пароля (и пароль), которые привели к правильному ответу. Для статического 8-байтового запроса 1122334455667788 доступны бесплатные радужные таблицы LM запрос-ответ, и такие инструменты, как модуль smb_sniffer от Metasploit, а также Cain и Abel будут использовать этот запрос по умолчанию. Чтобы увидеть эту атаку в действии, ознакомьтесь с этой отличной статьей Тима Медина.Тим настраивает поддельные службы SMB и HTTP с помощью Metasploit, и как только жертва отвечает на статический вызов, Тим показывает, как взломать ее, чтобы получить пароль. Microsoft решила эту проблему, представив NTLMv2 и LMv2, которые представляют собой небольшую вариацию, определяющую более короткую задачу клиента в целях обратной совместимости. В обновленных версиях проблема устранена путем включения клиентского запроса на обеспечение взаимной аутентификации. Вот как это работает: Шаги 1 и 2 такие же, как и раньше.Однако на шаге 3 клиент возвращает серверу ответ, основанный на запросе сервера И запросе, предоставленном клиентом. Если сервер является легитимным, он может легко проверить ответ, используя хэш, его запрос и запрос клиента. С другой стороны, если сервер является мошенническим и не знает хэш пароля для вычисления ответа, он больше не может использовать предварительно вычисленную атаку по радужной таблице, потому что в форме запроса клиента вводится случайность.Злоумышленник по-прежнему может использовать атаку грубой силы против вызовов и ответов, но уже невозможно предварительно вычислить эти предположения с помощью атаки по радужной таблице. Как я вскоре расскажу, Kerberos - лучший вариант для сетевой аутентификации, но бывают случаи, когда он не работает, и Windows возвращается к протоколу на основе LM / NTLM. В таких ситуациях мы хотим убедиться, что используем NTLMv2 для обеспечения безопасности взаимной аутентификации.В разделе «Рекомендации » в конце этой статьи обсуждается, как принудительно использовать NTLMv2. Проблема 2: Отражающие и ретрансляционные атаки Эти две атаки очень умны. Отражательная атака решена, но связанная с ней ретрансляционная атака по-прежнему вызывает у нас озабоченность. Давайте сначала посмотрим на отражающую атаку: Я не буду рассказывать вам шаги, но, чтобы резюмировать эту атаку, мошеннический сервер эффективно переворачивает таблицы на клиенте и вынуждает клиента непреднамеренно предоставить ответ аутентификации мошенническому серверу, который позволяет ему подключиться обратно к клиентская машина. Эта конкретная проблема была решена с помощью исправления Microsoft MS08-068. Патч не позволяет клиенту SMB отвечать на запросы, которые недавно были выданы его собственной службой сервера SMB. Это хорошо работает в данном конкретном случае использования. Однако это оказывается частным решением более общей проблемы, как демонстрирует Relay Attack. Атака ретрансляции по-прежнему кооптирует клиента для ответа на вызов, но на этот раз несанкционированный сервер передает ответ машине 3 ^rd, чтобы получить доступ, как показано здесь: Инструменты ретрансляции существуют уже давно, в том числе SmbRelay3 и модуль smb_relay от Metasploit .Эти инструменты очень эффективны, но поддерживают только NTLMv1. Последний модуль Metasploit от Rich Lundeen обеспечивает ретрансляцию NTLM для NTLMv2. Другой новый инструмент под названием ZackAttack от Зака Фазеля тоже делает это. В предыдущей Reflective Attack исправление было для клиента, чтобы убедиться, что он не отвечает ни на какие проблемы, которые он недавно выдал из своей собственной серверной службы. К сожалению, это решение не поможет нам в решении этой проблемы, поскольку для всех клиентов в определенном домене невозможно отслеживать проблемы друг друга. Так в чем же исправление? Что ж, многие люди утверждают, что исправление - это подписывание SMB. Я не согласен по крайней мере по паре причин. Я не хочу увязать эту часть статьи с кучей посторонних деталей, поэтому я добавлю несколько комментариев в конце статьи в виде сносок к этому разделу. На данный момент достаточно сказать, что одна из основных причин, по которой подписывание SMB не является решением, связана с тем, что есть другие службы, помимо SMB, которые используют аутентификацию LM / NTLM, которую невозможно защитить даже с помощью подписи SMB. если он отлично сработал для защиты обмена аутентификацией для SMB (а это не так). Наиболее полной защитой от релейной атаки является функция, называемая «Расширенная защита для аутентификации» (EPA). Вкратце, EPA обеспечивает для аутентификации NTLMv2 следующее: EPA встраивает имя участника-службы целевой службы с хэшем целостности , подписанным учетными данными учетной записи в запросе на вход. (Имя участника службы - это имя, по которому клиент однозначно идентифицирует экземпляр службы на определенном узле.) Расширенная защита работает, потому что только контроллеры домена и машины, на которых пользователь вводит пароль напрямую, могут вычислять / проверять хэш целостности. Следовательно, новые запросы не могут быть созданы мошенническим сервером, поскольку он не может подписать новый запрос. Неверный сервер также не может пересылать (ретранслировать) запрос, отправленный ему, потому что хост 3 ^rd распознал бы, что запрос имел имя принципа службы назначения мошеннического сервера, а не самого себя. В этой статье описывается, как включить EPA для SMB, в этой статье для IIS и в этой статье для SQL Server. Эта функция защищает уровень аутентификации. Очень надежная реализация для SMB будет включать в себя подписание как EPA, так и SMB, предотвращая пересылку учетных данных (EPA), а также изменение трафика SMB (подписывание SMB). Сложная часть эффективной реализации EPA (или подписания SMB в этом отношении) состоит в том, что она должна требоваться во всем домене, чтобы быть действительно эффективной. Если это необязательно, злоумышленник может просто создать запрос, который сообщает серверу, что он не поддерживает более безопасные настройки.Еще одна сложность заключается в том, что EPA реализуется для каждой службы, поэтому нет единого переключателя, который бы все это «просто работало». Тем не менее, EPA - лучшее комплексное решение для защиты аутентификации NTLMv2 от ретрансляционной атаки. Большая проблема: плохой дизайн Что делает протоколы LM / NTLM вызов-ответ такой сложной для защиты в доменной среде, так это то, что они используют сквозную аутентификацию. Это позволяет мошенническому серверу быть «посредником» при аутентификационном обмене, как показано здесь: Как видно из этой диаграммы, в среде домена сервер отправляет запрос клиенту, а затем получает ответ.Как только это произойдет, законный сервер упакует запрос и ответ и отправит его контроллеру домена для проверки, поскольку контроллер домена имеет хэши паролей и может вычислить ответ для проверки. Проблема в том, что ответ по-прежнему является конфиденциальным, и когда сервер скомпрометирован, учетные данные домена подвергаются риску из-за раскрытия ответа. Итак, какое решение является лучшим? Избегайте протоколов LM / NTLM и используйте вместо них Kerberos! Большое исправление: Kerberos приходит на помощь С Kerberos больше нет сквозной аутентификации.Теперь у нас есть доверенная сторонняя архитектура, в которой аутентификация происходит напрямую между клиентом и хранилищем аутентификации (DC). После успешной аутентификации клиенту выдается билет, который затем представляет его серверу для доступа. Звучит здорово! Мы должны просто использовать Kerberos и полностью отключить протоколы LM / NTLM, вам не кажется? Что ж, к сожалению, вы вряд ли сможете полностью исключить NTLM в своей среде. Следующие ситуации по-прежнему требуют NTLM, как указано в Википедии: Клиент аутентифицируется на сервере, используя IP-адрес. Клиент аутентифицируется на сервере, который принадлежит другому лесу Active Directory, который имеет устаревшее доверие NTLM вместо транзитивного доверия между лесами. Клиент аутентифицируется на сервере, который не принадлежит домену. Если брандмауэр в противном случае ограничивал бы порты, требуемые Kerberos (а их довольно много) Первый из них является реальной проблемой в большинстве сред. Существует ряд ситуаций, когда вы можете захотеть использовать определенный IP-адрес при подключении к хосту.Например, если записи DNS не были обновлены должным образом, вам может потребоваться связаться с хостом по IP. Другой распространенный сценарий - использование сценариев или инструментов, которые охватывают весь диапазон IP-сети. Согласно Джесперу Йоханссону в работе Защитите свою сеть Windows от периметра до данных , причина того, что Windows возвращается к NTLM при использовании IP-адреса, заключается в том, что «Kerberos основан на именах хостов. Поскольку Windows DNS не создает зоны обратного просмотра с помощью по умолчанию протокол не может полагаться на способ преобразования IP-адресов в имена хостов.Следовательно, в этой ситуации он всегда возвращается к NTLM или NTLMv2 ". Тем не менее, мы хотим принудительно использовать Kerberos, когда это возможно. Это особенно актуально для наших рабочих станций с ИК-подсветкой. К счастью, в Windows 7 и Server 2008 R2 у нас есть возможность сделать это с помощью политики. Вот пример политики, которая запрещает исходящую аутентификацию NTLM для всех серверов, с настроенным исключением 192.168.6.12: Возможность исключить определенные доверенные IP-адреса на вашей рабочей станции IR, например, прокси-сервер, является очень полезной функцией.Обратите внимание, что для регулировки уровня блокировки и аудита NTLM доступно несколько параметров. Хорошим ресурсом для изучения этой функции является статья Microsoft TechNet «Блокировка NTLM и вы: методологии анализа и аудита приложений в Windows 7». Вот результат некоторых тестов, демонстрирующих функцию блокировки NTLM: И вот запись журнала событий из заблокированной попытки NTLM на 192.168.6.11 (находится в средстве просмотра событий в разделе Журналы приложений и служб> Microsoft> Windows> NTLM): В моем тестировании с PsExec , NET USE и WMIC , 2 из 3 будут использовать Kerberos по умолчанию.Я не уверен, почему, но я обнаружил, что WMIC требует некоторой поддержки для использования Kerberos. К счастью, есть переключатель, хотя и уродливый, но болезненный, чтобы заставить WMIC использовать Kerberos вместо NTLM. Это / АВТОРИТЕТ: "kerberos: домен \ компьютер". Вот он в действии? Обратите внимание, что первая попытка не удалась, потому что ограничение NTLM заблокировало ее: Я сказал вам, что это уродливо? Но, по крайней мере, это работает! Если вам интересно, вот простой пакетный сценарий, который вы можете использовать в качестве ярлыка, чтобы вам не приходилось вводить все это каждый раз: SET / P PCNAME = Имя хоста для запроса: SET / P PCDOMAIN = Домен хоста: SET / P WMICCMD = Команда WMIC для запуска: wmic / node: "% PCNAME%" / AUTHORITY: "kerberos:% PCDOMAIN% \% PCNAME%"% WMICCMD% Назовите его с помощью ".bat "И убедитесь, что командный файл (и любой другой подобный ему) доступен для редактирования только вашей привилегированной учетной записью. В противном случае непривилегированный пользователь может добавить к нему гнусные команды без вашего ведома, а затем, когда вы запустите его со своей привилегированной учетной записью, плохо что-то случится. Рекомендации по надежной сетевой аутентификации Прежде всего, убедитесь, что вы используете Windows 7 в качестве рабочей станции IR, и включите функцию блокировки аутентификации NTLM, где это возможно. Одна из распространенных ситуаций IR, когда это вызовет проблемы, - это когда вам нужно пройти аутентификацию по IP-адресу, потому что имя хоста не зарегистрировано в DNS.В этом случае вы можете обманом заставить свою рабочую станцию использовать Kerberos, временно добавив запись в файл «hosts» (Windows \ System32 \ drivers \ etc \ hosts) для системы, к которой необходимо подключиться. Затем удалите его, когда закончите. В ситуациях, когда вы должны использовать NTLM, обязательно включите NTLMv2 в локальной политике безопасности (secpol.msc), установив «Сетевая безопасность: уровень проверки подлинности LAN Manager» на «Отправлять только ответ NTLMv2 / отказываться от LM и NTLM», как показано здесь: Если вам необходимо еще больше понизить настройки, убедитесь, что вы используете пароль длиной более 14 символов (что вам все равно следует сделать).Это предотвратит хранение хэша LM, и поэтому худшее, что вы можете сделать, - это NTLMv1, а не LMv1. Кроме того, наличие такого длинного пароля затрудняет использование Rainbow Table или атаки методом перебора на ваш запрос / ответ NTLMv1 (я не знаю каких-либо Rainbow Tables, доступных в настоящее время для NTLMv1? Хотя это не означает, что APT не нет их). Если ни NTLMv1, ни NTLMv2 не работают, вы действительно должны учитывать тот факт, что это может быть атака на более раннюю версию. С подозрением относитесь к любым хостам, требующим аутентификации с помощью LM запрос-ответ. Наконец, помните, что протоколы запрос-ответ LM / NTLM уязвимы для релейной атаки, независимо от хэша или надежности пароля. Хотя подписывание SMB полезно, рассмотрите возможность внедрения расширенной защиты для проверки подлинности для более полной защиты. Учитывая, что существует несколько ситуаций, ограничивающих использование Kerberos, вполне возможно, что включение EPA в вашей среде стоит потраченного времени и усилий. На этом пока все, кроме некоторых длинных сносок о подписании SMB.Хотя это было то, что я считал последней «важной» частью головоломки для защиты учетных записей привилегированных доменов, безусловно, есть дополнительные идеи и проблемы, которые следует рассмотреть, поэтому я вернусь к более подробной информации по этому вопросу в ближайшие недели. Спасибо за прочтение! Сноски по подписи SMB Как упоминалось выше, некоторые считают подписание SMB решением для ретрансляционной атаки. Я не думаю, что этого достаточно по нескольким причинам: Он защищает только службы SMB. В реализации Microsoft есть недостаток, который может позволить злоумышленнику эффективно обойти подписывание SMB при определенных обстоятельствах. Первая проблема довольно проста. В идеальной реализации подписи SMB подписывание SMB защищает от ретрансляции ответа на третий SMB-сервер жертвы, заставляя сообщения SMB подписываться с помощью сеансового ключа, созданного из хэша пароля учетной записи. Неверный сервер не может сгенерировать сеансовый ключ, потому что у него нет хэша пароля, поэтому он не может отправлять сообщения SMB на третий сервер, требующий подписи SMB.Однако это защищает только службу SMB. Если бы был доступен инструмент, который позволял бы несанкционированному серверу SMB ретранслировать аутентификацию NTLM не-SMB-сервису, например HTTP-серверу, требующему аутентификации NTLM, функция подписи SMB не обеспечивала бы защиты. Существует ряд инструментов, реализующих NTLM-ретрансляцию для служб, не относящихся к SMB. Курт Груцмахер написал инструмент под названием Squirtle , который позволяет ретранслировать обмен NTLM-аутентификацией веб-клиента на сервер SMB, который не сработает, если требуется подпись SMB.Однако его код является открытым исходным кодом, и нет причин, по которым его нельзя изменить, чтобы разрешить подключенному SMB-клиенту ретранслировать на службы, не относящиеся к SMB, такие как HTTP-сервер (например, SharePoint или OWA) или другие службы, не относящиеся к SMB. например Exchange (MAPI / MSRPC) или MS SQL (встроенная проверка подлинности Windows). Последний модуль Metasploit от Rich Lundeen предоставляет возможности, аналогичные Squirtle , но с некоторыми дополнительными функциями, включая возможность ретрансляции NTLMv2. Еще один новый инструмент под названием ZackAttack обещает еще большую функциональность и гибкость.Таким образом, даже если подписывание SMB работает так, как рекламируется, все еще существует ряд ситуаций, когда наши учетные данные будут подвергаться риску для ретрансляции NTLM. Моя вторая проблема с подписью SMB заключается в том, что при определенных обстоятельствах она не работает так, как заявлено. Существует ограничение, реализованное Microsoft, которое может допускать повышение привилегий для SMB-сервера жертвы в ретрансляционной атаке даже с принудительной подписью. Как описано на странице 2 этой статьи Juniper о последствиях подписания SMB и ускорения WAN, ключ сеанса, который используется для защиты SMB-обмена данными между клиентом и сервером, может не потребоваться повторно, если другой пользователь недавно установил соединение между клиентом и сервером.В частности, в нем говорится: «Самый первый реальный вход в систему устанавливает ключ MAC для потока CIFS [CIFS = реализация Microsoft SMB]. Когда пользователь выходит из системы и снова входит в систему с другими именами пользователей, этот поток CIFS клиент / сервер будет подписан ключом MAC, который был ранее вычислен ". Juniper использует это в своих интересах, предлагая клиенту создать «виртуального пользователя» в домене, который WAN-ускоритель может использовать для установления соединения с сервером перед легитимным клиентом, чтобы получить сеансовый ключ для подписи.Затем он может обмениваться подписанными сообщениями SMB, не зная реальных учетных данных пользователя (что было бы необходимо, если бы клиенту / серверу SMB пришлось воссоздавать сеансовый ключ). Итак, как это разрешить повышение привилегий? Если злоумышленник контролирует систему с непривилегированным пользователем домена, он может играть роль «виртуального пользователя» в решении Juniper. Сначала он может установить SMB-соединение с SMB-сервером жертвы с непривилегированным пользователем, чтобы получить сеансовый ключ.Затем он может дождаться, пока привилегированный пользователь установит SMB-соединение со скомпрометированным хостом, после чего злоумышленник может переслать запрос / ответ и использовать уже установленный сеансовый ключ для подписи. Теперь у злоумышленника есть SMB-соединение с сервером жертвы как привилегированный пользователь домена! Возможно, злоумышленнику надумано пойти на такое (если не станет доступен инструмент, облегчающий эту задачу), но, безусловно, возможно, пока Microsoft не решит эту проблему. Теперь, со всем этим сказанным, я определенно не хочу подразумевать, что подписывание SMB бесполезно.Если этого требуют серверы и клиенты, это, безусловно, поднимет планку, помогая защитить ваши SMB-коммуникации в большинстве случаев и во всех случаях, если Microsoft устранит лазейку, используемую Juniper. Так что, если у вас есть это принудительное применение в вашей среде, конечно, не отключайте его, но посмотрите на Расширенную защиту для аутентификации, чтобы получить более полное решение проблемы ретрансляции NTLM. Майк Пилкингтон - старший аналитик по информационной безопасности и специалист по реагированию на инциденты в компании из списка Fortune 500 в Хьюстоне, штат Техас, а также наставником и инструктором SANS.Майк будет преподавать FOR408: Компьютерные криминалистические исследования - подробные сведения о Windows в Рестоне, штат Вирджиния, 12-17 ноября 2012 года. активный каталог - проверка подлинности Kerberos для рабочих станций не в домене как системы (ноутбуки), не входящие в домен, могут получить доступ к одним и тем же сетевым ресурсам, используя только имя пользователя и пароль пользователя активного каталога? Это зависит от того, какие «сетевые ресурсы» задействованы. На подключенном к домену компьютере с Windows, в который вы вошли, задействованы как минимум два клиентских удостоверения Kerberos: вы, пользователь @ DOMAIN компьютер, рабочая станция $ @ DOMAIN Существует также host / workstation @ DOMAIN, но обычно это идентификация службы, запущенной на хосте, к которой осуществляется доступ из другого места.Если привилегированный процесс на хосте хочет что-то сделать - скажем, добавить свое имя в DNS с помощью динамического DNS с аутентификацией Kerberos - он будет использовать для этого свою личность, рабочую станцию $ @ DOMAIN. Однако, если вы в сеансе входа в систему сами обращаетесь к какому-либо ресурсу - скажем, к общему сетевому ресурсу CIFS или аутентифицированному URL-адресу HTTP - тогда идентификатор клиента - это , ваше основное имя , user @ DOMAIN (учетные данные для которого получаются автоматически для вас. используя пароль, который вы ввели для входа в систему). Судя по вашему вопросу, вам кажется, что здесь задействована какая-то комбинация; это не так, они отдельные. Вот почему нет проблем с использованием Kerberos для доступа к ресурсам Windows с других платформ. Вы также можете ввести «kinit user» в поле Linux, ввести свой пароль, чтобы получить учетные данные Kerberos (TGT) от контроллера домена, а затем использовать Firefox для доступа к веб-странице с проверкой подлинности Kerberos в IIS. Протоколы для всего этого стандартные, и вам не нужно ничего, кроме ваших учетных данных. В предыдущем ответе утверждалось, что в этом случае требуется NTLM; это ложь (хотя, конечно, это может быть использовано).Однако, когда вы получаете доступ к какому-либо ресурсу с компьютера, не являющегося доменом, и вам предлагается ввести ваше имя пользователя и пароль, вы не обязательно знаете, какой метод аутентификации фактически используется. Он может использовать Kerberos. Он также может просто вернуться к механизму на основе пароля, при котором он отправляет ваше имя пользователя и пароль на сервер для проверки, а затем кеширует ваш пароль, чтобы вам не приходилось повторно вводить его. Многие протоколы допускают и то, и другое через схемы абстракции, такие как SASL. Вам нужно будет посмотреть на провод, чтобы увидеть, что происходит. Windows-Ручная настройка - Службы информационных технологий Ручная настройка для Windows Конфигурации Windows 10, 8 / 8.1 и 7 очень похожи. Скриншоты взяты из Windows 10. Вам потребуются права администратора на вашем ПК с Windows, чтобы для включения протокола 802.1x. Проверить проводную службу AutoConfig Услуги по запуску.msc. Windows 10: введите services.msc в поле поиска. Windows 8 / 8.1: переместите указатель мыши в правый верхний угол, пока не появится панель Charms Bar. из. Выберите Приложения из списка и введите services.msc в поле поиска. Windows 7: нажмите Пуск (кнопка Windows) и введите services.msc в поле поиска. Прокрутите вниз до пункта Автонастройка проводной сети> щелкните правой кнопкой мыши и выберите «Свойства». На вкладке «Общие» в разделе «Тип запуска» выберите «Автоматически». Щелкните Пуск> Применить> ОК. Настройка подключения Ethernet / локальной сети для 802.1x Запустить просмотр сетевых подключений. Windows 10: введите просмотр сетевых подключений в поле поиска. Windows 8 / 8.1: переместите указатель мыши в правый верхний угол, пока не появится панель Charms Bar. из. Выберите «Приложения» из списка и введите «Просмотр сетевых подключений» в поле поиска. Windows 7: нажмите Пуск (кнопка Windows) и введите в поиске просмотреть сетевые подключения. коробка. Щелкните правой кнопкой мыши соответствующее сетевое подключение (Ethernet или подключение по локальной сети) и выберите Свойства. В диалоговом окне свойств Ethernet выберите вкладку «Проверка подлинности» и установите флажок «Включить». Аутентификация IEEE 802.1x ». В раскрывающемся списке "Выберите метод сетевой аутентификации" выберите Microsoft Protected EAP (PEAP). Установите флажок "Запомнить мои учетные данные для этого подключения". каждый раз, когда я вхожу в систему »и« Откат для несанкционированного доступа к сети ». Щелкните «Настройки». В диалоговом окне «Свойства защищенного EAP» установите флажок «Проверить подлинность сервера с помощью проверка сертификата ', прокрутите вниз и проверьте сертификат Entrust Trusted Root Certification. Власти, как показано. Если ваш дисплей отличается, выберите все сертификаты Entrust. параметры. В уведомлениях выберите «Не просить пользователя авторизовать новые серверы или доверенные центры сертификации». падать. Нажмите «Настроить». Снимите флажок Автоматически использовать мое имя и пароль для входа в Windows (и домен, если есть). Дважды нажмите «ОК». Вернитесь в диалоговое окно «Свойства Ethernet» и нажмите «Дополнительные настройки». В диалоговом окне «Дополнительные параметры» установите флажок «Указать режим проверки подлинности». Выбрать пользователя или проверка подлинности компьютера в раскрывающемся списке и нажмите ОК. Дважды нажмите «ОК». No related posts.

Подлинность сети не проверена домен windows 7: Сеть подлинность не проверена windows 7 | Операцинные системы

Сеть подлинность не проверена windows 7 | Операцинные системы

пятница, 1 апреля г.

win 7, ad, проблема с подлинностью клиентской машины

Active Directory без проблем

Вас может заинтересовать

Сетевое подключение подлинность не проверена. Восстанавливаем доверительные отношения в домене

Пароль компьютера в домене AD

Утилита Netdom

Командлет Reset-ComputerMachinePassword

Active Directory без проблем | Windows IT Pro/RE

Проверка подлинности сети для удаленного компьютера Windows

Вопрос

Ответы

Все ответы

Признаки сторонних подключений к Wi-Fi сети

Как посмотреть подключенные устройства в «админке» Wi-Fi роутера

Использование для мониторинга Wi-Fi сторонних приложений

Как обезопасить свою беспроводную сеть

Что такое аутентификация

Почему возникает ошибка аутентификации WiFi: Видео

Почему появляется ошибка проверки подлинности и как ее устранить

Как легко узнать IP адрес WiFi роутера: Видео

Подключение к WiFi роутеру в Windows 8: Видео

Проверка ОС при ошибке аутентификации

Как переустановить драйвер WiFi в Windows 8: Видео

Включение HTTPS на вашем веб-сервере—ArcGIS Enterprise

Создайте сертификат сервера

Сертификаты, подписанные центром сертификации (CA)

Сертификаты домена

Создание доменного сертификата и включение HTTPS

Самозаверенные сертификаты

Создание самозаверенного сертификата в IIS

Привязка сертификата к веб-сайту

Привязка сертификата к порту 443 в IIS

Проверка вашего сайта

Нужен другой контроллер домена

Получив приглашение войти, используя встроенную проверку подлинности windows

1 ответ

Похожие вопросы:

Устранение ошибок, возникающих при присоединении компьютеров под управлением Windows к домену — Windows Server

В этой статье

Где найти файл Netsetup.log

Сообщения об ошибках сети и их решения

Ошибка 1

Разрешение

Ошибка 2

Разрешение

Ошибка 3

Разрешение

Ошибка 4

Разрешение

Ошибка 5

Разрешение

Ошибка 6

Разрешение

Ошибка 7

Разрешение

Ошибка 8

Разрешение

Ошибка 9

Разрешение

Ошибка 10

Разрешение

Сообщения об ошибках аутентификации и их решения

Ошибка 1

Разрешение

Ошибка 2

Разрешение

Ошибка 3

Разрешение

Ошибка 4

Разрешение

Ошибка 5

Разрешение

Ошибка 6

Разрешение

Ошибка 7

Разрешение

Ошибка 8

`3.4. Обнаружение идентификационных доменов и присоединение к ним`

`Обнаружение доменов`

`Добавить комментарий Отменить ответ`