Повторяю: я контролировал клиентские системы. Похоже, это полностью связано с сервером.

Повторяю: я контролировал клиентские системы. Похоже, это полностью связано с сервером.

Или: «Это что-то? И как мне это проверить?»

В средебез контроллера доменапри доступе к общему ресурсу на компьютере с Windows Server 2008 R2,с удаленного компьютерабез соответствующей учетной записи пользователя на сервере, (и подключение путем ввода \\SERVERNAME\ShareNameиз меню «Пуск») В настоящее время я наблюдаю следующее поведение в зависимости от настройки «Общий доступ с парольной защитой» (Расширенные параметры общего доступа):

Когда включен «Общий доступ с парольной защитой»на, все попытки подключения завершаются неудачей в течение 30 секунд с:

Ошибка входа: пользователю не предоставлен запрошенный тип входа на этом компьютере.

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

У вас нет разрешения на доступ к \SERVERNAME\ShareName. Обратитесь к администратору сети, чтобы запросить доступ.

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

ОДНАКО,здесь есть и третий случай.(чтоооооо?)

Если вы попытаетесь подключиться к общему ресурсубез изменения этой настройки(то есть, он установлен нанано вы никогда не нажимали на нее), соединение ведет себя аналогичнонавышеприведенный случай, в котором для отображения ответа требуется до 30 секунд,но затем он отображает диалоговое окно аутентификации:

Поделиться диалогом аутентификации

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

Повторяю: я контролировал клиентские системы. Похоже, это полностью связано с сервером.

Итак, мне ясно, что изменение настройки «Защищенный паролем общий доступ» меняет не только один параметр (ключ реестра? Я работаю на Mac), и что настройки по умолчанию, с которыми поставляется система, НЕ все совпадают с настройками, отраженными в панели управления (или сама панель управления неисправна и должна менять больше параметров).

Итак, вопрос: это так задумано или это ошибка? И в любом случае, какая «скрытая настройка» изменяется или остается неизменной? Как это отследить? У меня заканчиваются свежие серверы для тестирования. :-(

решение1

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

гостевая учетная запись procmon изменена

Это показывает, что lsass.exe (Local Security Authority) пишет в локальный SAM и вносит изменения во встроенную учетную запись гостя (известный RID 501). Конечно, когда я повторно протестировал ваш сценарий, наблюдая за статусом учетной записи гостя, я увидел, что она включена, когда «Общий доступ с парольной защитой» отключен. Однако, когда «Общий доступ с парольной защитой» снова включен, учетная запись гостя не отключена снова. Ручное отключение учетной записи гостя восстанавливает исходную функциональность: мне предлагается ввести учетные данные (т. е. ваш третий случай).

Я не уверен, почему это так себя ведет. Честно говоря, я даже никогда не переключал настройку "Защищенный паролем общий доступ" до сегодняшнего дня (или даже не замечал ее, если на то пошло). Надеюсь, это поможет вашему проекту. Если кто-то еще заинтересован в дальнейшем изучении, было бы интересно узнать, присутствует ли это поведение все еще на Server 2012/2012 R2...

О, и что касается вашего изначального вопроса (так задумано или это ошибка?), то я не имею ни малейшего представления...

решение2

Если я правильно понял ваш вопрос, то учетные данные общих ресурсов сохраняются в диспетчере учетных данных в панели управления.

Чтобы открыть диалоговое окно аутентификации, просто удалите учетные данные, относящиеся к этому общему ресурсу, в диспетчере учетных данных.

Если вы отметите «Запомнить мои учетные данные», они обычно сохраняются в диспетчере учетных данных, и если этот пароль был неверным, вы увидите ошибку входа в систему.

решение3

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

чистое использование * /D

Связанный контент