Проблема: пользователь подключается к службе на компьютере, например к веб-сайту IIS или базе данных SQL Server. Сайт или база данных должны получить доступ к сетевым ресурсам, таким как общие файловые ресурсы (наиболее распространенные) или базе данных на другом сервере. В разрешении отказано.
Это связано с тем, что пользователь, под которым работает служба, в первую очередь не имеет сетевых разрешений или, если да, то у него нет прав на доступ к удаленному ресурсу.
Я продолжаю сталкиваться с этой проблемой снова и снова и устал от того, что у меня нет надежного способа ее решения.
Вот некоторые обходные пути, о которых я знаю:
Запуск IIS от имени пользователя домена, созданного пользователем, которому предоставлены высокие разрешения
Если разрешения предоставляются по одному файловому ресурсу за раз, то каждый раз, когда я хочу читать из нового общего ресурса, мне придется просить сетевого администратора добавить его за меня. В конце концов, когда многие веб-сайты будут читать из множества акций, он получит действительно сложно. Если разрешения для пользователя просто открыты для доступа к любым файловым ресурсам в нашем домене, то это кажется ненужной областью безопасности для представления.
Это также относится ко всем сайтам, работающим в IIS, а не только к выбранному сайту или виртуальному каталогу, которому требуется доступ, что является еще одной проблемой области поверхности.
Сделайте то же самое, но используйте пул приложений или индивидуально установите учетные данные.
Необязательно запускать весь экземпляр IIS от имени конкретного пользователя: каждый сайт, приложение и папку можно настроить для работы в определенном пуле приложений или в выбранном вручную наборе учетных данных. Это решает небольшую часть проблемы поверхностной области, но на самом деле не решает другие проблемы, связанные с управлением детализацией разрешений и выполнением этого для многих ресурсов.
По-прежнему используйте учетную запись IUSR, но дайте ей сетевые разрешения и настройте то же имя пользователя на удаленном ресурсе (не пользователь домена, а локальный пользователь)
Здесь тоже есть свои проблемы. Например, я использую общий файловый ресурс, на который у меня есть полные права, но я не могу войти в систему. Поэтому мне нужно найти подходящего администратора и попросить его сделать это за меня. Каждый раз, когда что-то нужно изменить, это еще один запрос к администратору.
Разрешить пользователям IIS подключаться как анонимно, но установить учетную запись, используемую для анонимного доступа, с высокой привилегией
Это даже хуже, чем предоставление полных привилегий IIS IUSR, потому что это означает, что мой веб-сайт вообще не может использовать какие-либо средства защиты.
Подключитесь с помощью Kerberos, затем делегируйте
В принципе это звучит неплохо, но имеет множество проблем. Прежде всего, если вы используете виртуальные веб-сайты, где доменное имя, с которым вы подключаетесь к сайту, не является именем базовой машины (как мы часто делаем), тогда вам необходимо настроить имя участника-службы на веб-сервере, используя Microsoft Утилита SetSPN. Это сложно и явно подвержено ошибкам. Кроме того, вы должны попросить администратора сети / домена изменить политику безопасности как для веб-сервера, так и для учетной записи домена, чтобы они были «доверенными для делегирования». Если вы не все сделаете правильно, то внезапно ваша предполагаемая проверка подлинности Kerberos - это NTLM, и вы можете только олицетворять, а не делегировать, и, следовательно, не выходить на связь по сети как пользователь. Кроме того, этот метод может быть проблематичным, потому что иногда вам нужно, чтобы веб-сайт или база данных имели разрешения, которых нет у подключающегося пользователя.
Создайте службу или приложение COM +, которое извлекает ресурс для веб-сайта.
Службы и пакеты COM + запускаются с собственным набором учетных данных. Работать в качестве пользователя с высокими привилегиями - это нормально, поскольку они могут обеспечивать свою собственную безопасность и отклонять незаконные запросы, передавая контроль разработчику приложения, а не сетевому администратору. Проблемы: я использую пакет COM +, который делает именно это в Windows Server 2000 для доставки высокочувствительных изображений в защищенное веб-приложение. Я попытался переместить веб-сайт на Windows Server 2003, но мне внезапно отказали в разрешении на создание экземпляра объекта COM +, скорее всего, в разрешениях реестра. Я немного поработал и не решил проблему, отчасти потому, что я не хотел давать учетной записи IUSR полные разрешения реестра. Это похоже на такую же плохую практику, как и просто запуск IIS от имени пользователя с высокими привилегиями.
Примечание: это действительно очень просто. На выбранном вами языке программирования вы создаете класс с функцией, которая возвращает экземпляр нужного вам объекта (например, ADODB.Connection), и создаете dll, которую вы регистрируете как объект COM +. В коде на стороне веб-сервера вы создаете экземпляр класса и используете функцию, и поскольку он работает в другом контексте безопасности, вызовы сетевых ресурсов работают.
Сопоставьте буквы дисков с общими папками
Теоретически это могло сработать, но, на мой взгляд, это не совсем хорошая долгосрочная стратегия. Несмотря на то, что сопоставления могут быть созданы с определенными учетными данными, и это могут делать другие, кроме сетевого администратора, это также будет означать, что либо слишком много общих дисков (небольшая степень детализации), либо слишком много разрешений предоставлено для всего файла серверы (большая степень детализации). Кроме того, я не понял, как подключить диск, чтобы IUSR получал диски. Сопоставление диска предназначено для текущего пользователя, я не знаю пароль учетной записи IUSR для входа в систему и создания сопоставлений.
Переместите ресурсы локально на веб-сервер / базу данных
Бывали случаи, когда я делал это, особенно с базами данных Access. База данных иметь жить на файловом ресурсе? Иногда проще всего было переместить базу данных на веб-сервер или на сервер базы данных SQL (чтобы связанный с ней сервер работал). Но я тоже не думаю, что это отличное универсальное решение. И это не сработает, если ресурс - это служба, а не файл.
Перенести службу на конечный веб-сервер / базу данных
Полагаю, я мог бы запустить веб-сервер в своей базе данных SQL Server, чтобы веб-сайт мог подключиться к нему, используя олицетворение, и сделать меня счастливым. Но действительно ли нам нужны случайные дополнительные веб-серверы на наших серверах баз данных, чтобы это было возможно? Нет.
Виртуальные каталоги в IIS
Я знаю, что виртуальные каталоги могут помочь сделать удаленные ресурсы локальными, и это поддерживает использование пользовательских учетных данных для каждого виртуального каталога. Я еще не смог придумать, как это решит проблему для системных вызовов. Пользователи могут напрямую обращаться к общим файловым ресурсам, но это не поможет, скажем, классическим ресурсам доступа кода ASP. Я мог бы использовать URL-адрес вместо пути к файлу для чтения удаленных файлов данных на веб-странице, но это не поможет мне установить соединение с базой данных Access, базой данных SQL-сервера или любым другим ресурсом, который использует соединение. вместо того, чтобы просто читать все байты и работать с ними.
Я бы хотел создать какой-то «служебный туннель». Подумайте о том, как VPN делает удаленные ресурсы похожими на локальные. С более богатым механизмом псевдонимов, возможно, на основе кода, почему даже соединения с базой данных не могут происходить в определенном контексте безопасности? Почему бы не создать специальный компонент Windows, который позволяет вам указать для каждого пользователя, какие ресурсы доступны и какие альтернативные учетные данные используются для подключения? Файловые ресурсы, базы данных, веб-сайты, что угодно. Я почти говорю о специализированном локальном прокси-сервере.
Во всяком случае, вот мой список. Я могу обновить его, если придумаю больше. Есть ли у кого-нибудь идеи для меня?
Моя текущая проблема сегодня заключается в том, что мне снова нужен веб-сайт для подключения к базе данных Access в общей папке. Это снова мы...
Я лично предлагаю пройти аутентификацию и олицетворение .net, используя уникальную учетную запись домена для каждого приложения. Как вы говорите, это узкое место у администратора домена, но если каждое изменение прав доступа должно проходить через администратора, на самом деле это хорошо.
Предположительно, как только общие ресурсы настроены для каждого приложения (часть четко определенного процесса настройки?), Они действительно не будут сильно меняться?
У администратора может быть четко определенный процесс, который включает в себя документацию о предоставлении доступа с авторизацией от руководства. Таким образом, все будет надежно и безопасно и очень удобно для внешнего аудита, если вы работаете в нормативной среде.
Предполагая, что у вас нет требований безопасности для прохождения аутентификации от внешнего интерфейса к внутренним ресурсам, я бы рассмотрел способы получения сетевых ресурсов, к которым это приложение должно получить доступ, под одним корнем безопасности. Что-то вроде общего ресурса DFS может быть идеальным для этого.
Во-вторых, я бы назначил безопасность группе безопасности AD, а не отдельной учетной записи службы или компьютеру.
Оттуда я, вероятно, буду использовать учетные записи служб и имена компьютеров, поскольку они имеют смысл. Например, вы можете просто добавить учетную запись службы сервера базы данных (DOMAIN / MACHINENAME $) в группу, но если у вас есть кластер серверов веб-приложений, вы должны использовать общую учетную запись службы.
Если вы предпочитаете не использовать Kerberos, вы можете олицетворять пользователя при доступе к ресурсу, используя его токен, созданный при их аутентификации с помощью аутентификации на основе форм. При этом должен использоваться сертификат SSL, по крайней мере, во время входа в систему.
Сделайте все эти сетевые / удаленные ресурсы локальными с помощью репликации SQL / доставки журналов и / или синхронизации файлов (Microsoft Sync Framework является вариантом, хотя симпатия cygwin + rsync более привлекательна, IMO).
Конечно, все это зависит от того, как часто меняются данные и / или нужна ли вам двусторонняя синхронизация или просто зеркалирование.