Чтобы ответить на ваш конкретный технический вопрос - у вас не может быть единого ресурса, который разрешает как анонимный доступ, так и аутентификацию на основе Windows. Однако у вас может быть главная страница, которая разрешает анонимный доступ, и страница в подпапке, защищенная аутентификацией Windows, и обе эти страницы могут совместно использовать одну и ту же область применения CF. Использование этого базового устройства будет обязательным.
Что касается базовой проблемы, которую вы пытаетесь решить, мы недавно потратили некоторое время на возможность смешивания подхода аутентификации Windows с существующими логинами на основе веб-форм, как вы описали. Это на самом деле довольно сложно, поскольку идеальная ситуация позволила бы всем пользователям получать доступ к одному и тому же базовому URL-адресу, который они всегда использовали, и автоматически входить в систему тихо и автоматически, когда этот параметр был доступен, но также не беспокоиться о входе в систему через браузер. подскажите, когда проверка подлинности Windows недоступна. Из того, что мы определили, этот идеал не вполне возможен (из-за некоторых ограничений в протоколе HTTP всегда появляется приглашение для входа при доступе к защищенному ресурсу). Тем не менее, мы нашли несколько вариантов, которые могут быть достаточно близки к идеалу, чтобы быть полезными и заслуживающими внимания:
1) У вас может быть специальный URL, предназначенный для пользователей, которые хотели бы иметь эту функцию автоматического входа в систему; например, что-то вроде https://baseUrl/autologin/. Пользователи домена могут добавить этот URL-адрес с компьютеров, находящихся в домене, и использовать эту закладку для доступа к сайту. Если кто-то, кроме пользователя домена на компьютере домена, перейдет по этому URL-адресу, он предложит войти в систему с помощью диалогового окна входа в систему на основе браузера. Пользователи, не являющиеся доменами, не смогут перейти из этого диалогового окна, но пользователи домена смогут. Все пользователи (доменные или нет) могут также войти через обычный экран входа на основе форм, который обычно доступен. Если вы выбрали эту опцию, вы также можете добавить ссылку на домашнюю страницу для пользователей в «autologin», которая приведет их к этому URL, что, конечно, будет работать только для пользователей в домене.
2) Вы можете попытаться определить определенные сегменты сети в вашей среде, из которых очень высока вероятность того, что пользователи, запрашивающие эти веб-сайты, будут делать это на компьютере доверенного домена. Вы можете структурировать приложение таким образом, чтобы попытаться автоматически войти в систему этих пользователей, когда они приходят из этих идентифицированных сетей. В случае, если есть запрос от этих сетей, который не является доверенным, худшее, что может случиться, - это то, что пользователю неожиданно будет предложено ввести имя пользователя и пароль на основе браузера. Если они получат это приглашение, они могут либо проигнорировать его, нажав на кнопку отмены и перейти на обычную страницу входа, либо ввести свои учетные данные домена и войти в систему (в этом случае это может произойти из-за того, что рабочий стол не настроен). правильно по какой-то причине - в противном случае он бы вошел в систему). Этот метод обнаружения на основе сети может быть реализован с помощью модуля перезаписи URL для IIS.