У меня странная ситуация. Мои серверы Win 2016 были разрушены групповыми политиками AD.
IIS 10 начал выдавать ошибку 403 после автоматического обновления групповой политики AD в момент X. Предварительно удаленная сторона без проблем позвонила нам через https с клиентскими сертификатами.
У меня есть резервная копия до момента X и после момента X, но я не могу точно определить параметр, который был изменен AD GP.
У меня есть установочный документ со всеми настройками, необходимыми для настройки нашего веб-сервиса с нуля. Я проверил их все на серверах-жертвах. Ничего не изменилось. На каждом уровне включена анонимная проверка подлинности и Параметры SSL-> Сертификаты клиента-> Принять.
Наши админы клянутся, что ничего не изменили. Журналы IIS ничего не показывают после момента X.
Есть идеи, где посмотреть? Реестр? Метабаза?
В соответствии с журналами трассировки SOAP e2e вызывающему абоненту возвращается точная ошибка:
The HTTP request was forbidden with client authentication scheme 'Anonymous'.[The remote server returned an error: (403) Forbidden.]
Распространенная проблема с групповой политикой и серверами IIS - это когда объект групповой политики переопределяет права пользователя, назначенные локальной политикой безопасности, и учетные записи служб IIS не могут войти в систему. В журнале безопасности Windows должны присутствовать события сбоя входа в систему с идентификатором EventId 4625 для учетных записей служб сервера IIS, если это происходит.
Вы можете быстро проверить любое вмешательство GPO, запустив RSOP.MSC со своего сервера IIS и перейдя в Конфигурация компьютера> Политики> Параметры Windows> Параметры безопасности> Локальные политики> Назначение прав пользователя.
Посмотрите на столбец Source GPO, чтобы определить, какой GPO применяет параметр. Используйте gpedit.msc для просмотра / редактирования настроек, применяемых локальной групповой политикой.
Ты можешь использовать Эта статья для проверки ваших разрешений сервера IIS. Начните с таблицы «Права пользователя Windows, назначаемые локальной политикой безопасности» внизу страницы.
Помните: объекты групповой политики не являются врагами, если они проверяются и применяются контролируемым образом.
Проверить наличие поддельных сертификатов. В моем случае в хранилище сертификатов доверенных корневых центров сертификации был один несамозаверяющий сертификат. Наши администраторы добавили этот выданный государством сертификат ко всему лесу (через групповую политику) без предварительного тестирования.
Я поместил здесь несколько общих рекомендаций по устранению неполадок, чтобы помочь людям решить такие проблемы быстрее, чем за 3 недели, как это было в моем случае.
Если вы не знакомы с групповыми политиками, используйте команду ниже, чтобы получить отчет в удобном для чтения виде (лучше всего просматривается в IE):
GPRESULT /H C:\GPReport.html
Для просмотра более подробной информации используйте RSOP.MSC согласно @twconnell рекомендация. RSOP.MSC показывает эффективный снимок применяемых локальных и групповых политик. Проверить безопасность на Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment. В моем случае я внимательно прочитал этот отличный ТАК ответ и переходил по каждой ссылке там. Затем я проверил права доступа для каждого файла, папки и пула приложений. В этом не было ничего плохого.
Посмотрите логи IIS. Подробностей должно быть больше, чем просто 403 код, предоставленный клиенту. В моем случае было 403 16 код там.
Посмотри на это руководство по устранению неполадок. В моем случае это было так коротко: Client certificate is untrusted or invalid
Мой ЦС сертификата был ЦС компании, предоставленным AD, поэтому я сначала подумал, что может быть проблема со списком отзыва сертификатов (CRL). Лучшее практическое руководство - вот этот. Чтобы понять дальнейшие подробности, прочтите этот, этот и наконец этот монстр. В моем случае проблем с CRL не было, так как я следил этот, этот и этот гиды заранее. Результат:
netsh http show sslcert ipport=0.0.0.0:443
...
Verify Client Certificate Revocation : Disabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Disabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
Negotiate Client Certificate : Enabled
... Для отладки SSL используйте openssl инструмент со стороны клиента (учитывая, что myserver использует общий порт 443 для https):
openssl s_client -connect myserver:443
В моем случае acceptable CAs for client certificates изначально был пуст, поэтому я установил HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\SendTrustedIssuerList Значение DWORD на 1 и перезагруженный сервер согласно этому руководству (внизу). Обратите внимание, что пустой список допустимых центров сертификации для клиентских сертификатов проблема IIS также может возникать из-за огромного списка центров сертификации в соответствии с этот вопрос SF.
Когда у вас есть список acceptable CAs for client certificates в openssl вывод вы можете сравнить с содержимым настроенных хранилищ сертификатов на вашем сервере. В моем случае там был только один сертификат, принадлежащий Trusted Root Certification Authorities. Итак, после нескольких дней расследования, которое привело меня к этому Статья ms-support №2802568. Фактически один неправильно размещенный несамоподписанный сертификат обрекал всю цепочку авторизации.
Цитирование @tylerl
Проверка подлинности клиента SSL - беспорядок. Это хорошо, потому что это абсолютно безопасно, но это ужасно, потому что его сложно настроить и поддерживать. Если у вас нет действительно веской причины, используйте вместо этого аутентификацию с общим ключом (например, "пароль"). Вы сэкономите время и деньги. SSL-аутентификация хороша в тех случаях, когда безопасность значительно превышает затраты.