Або: "Це річ? І як би я перевірив, чи це було?"

У середовищі без контролера домену під час доступу до спільного доступу до вікна Windows Server 2008 R2, із віддаленого комп’ютера без відповідного облікового запису користувача на сервері (та підключення, набравши \\SERVERNAME\ShareNameв меню "Пуск"), на даний момент я спостерігаю таке поведінку у налаштуваннях "Захищений паролем обмін" (Розширені настройки спільного доступу):

Коли «захищений паролем спільне використання» включається на всі спроби з'єднання невдачу після того, як до 30 секунд:

Помилка входу: користувачеві не надано запитуваного типу входу на цьому комп’ютері.

Якщо вимкнено "Обмін захищеним паролем" , підключення до анонімно доступних акцій дозволено, тоді як акції з обмеженим дозволом не вдається:

Ви не маєте дозволу на доступ до \ SERVERNAME \ ShareName. Зверніться до свого мережевого адміністратора, щоб подати запит на доступ.

Це здається очікуваною поведінкою. Мені потрібно мати певні акції , доступні анонімним вхід в системі, так що я повинен був змінити цю настройку за умовчанням для відключення .

ЗАРАЗ, тут є третя справа. ( whaaaaat? )

При спробі підключитися до загального ресурсу , немодифікована цю установку (тобто, він встановлений на на , але ви ніколи не клацнули), з'єднання поводиться схоже на на вищеописаному випадку в тому , що вона займає до 30 секунд , щоб показати відповідь, але потім відображається діалогове вікно аутентифікації :

У мене була така думка після того, як я кілька днів бив головою об стіну, і просто тиражував це на сервері без наявних спільних ресурсів: Створіть спільну роботу, прочитайте діалог, спробуйте підключитися та дістати діалог, змінити налаштування, успішно підключитися, змінити налаштування повернутись та отримати інше повідомлення про помилку. (Протестовано все це на свіжих клієнтських системах, щоб не було ризику кешування.)

Ще раз зазначу: я контролював клієнтські системи. Здається, це повністю пов'язано з сервером.

Отже, мені зрозуміло, що зміна налаштування "Обмін паролем захищена паролем" - це зміна не однієї речі (ключ реєстру? Я рідний для Mac) за лаштунками, і що за замовчуванням система, яку постачає система, НЕ всі збігаються з налаштуванням, відображеним на панелі управління (або сама панель керування порушена, і вона повинна змінювати більше речей).

Тож питання: це це за конструкцією, чи це помилка? І в будь-якому випадку, що таке "прихована установка", яка змінюється або залишається незмінною? Як можна було б відстежити це? У мене закінчуються свіжі сервери для тестування. :-(

Це справді викликало мій інтерес. Мені вдалося повторити ваші висновки в моїй лабораторії з тією ж схемою результатів, що ви описали. Я використовував Procmon, щоб спробувати побачити, які зміни внесені, і майже не відмовився, поки не побачив наступного:

Це показує, що lsass.exe (Local Security Authority) пише в місцевий SAM і вносить зміни до вбудованого облікового запису гостей (добре відомий RID 501). Звичайно, коли я повторно перевіряв ваш сценарій під час перегляду статусу гостьового облікового запису, я бачу, що його ввімкнено, коли функція "Захищений паролем" відключена. Однак, коли "Обмін захищеним паролем" буде ввімкнено, обліковий запис гостя знову не буде вимкнено. Відключення гостьового акаунта вручну відновлює початкову функціональність: мені пропонується отримати облікові дані (тобто ваш третій випадок).

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

О, і до ваших оригінальних питань (це за дизайном чи це помилка?), Я не маю найменшої ідеї ...

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

Для того, щоб запросити діалогове вікно автентифікації, просто видаліть облікові дані, що відносяться до цієї спільної частини, в Менеджері облікових даних.

Якщо ви встановите прапорець "Запам'ятати мої облікові дані", це зазвичай зберігається під керуючим диспетчером даних, і якщо цей пароль був невірним, ви побачите помилку помилки входу.

Можливо, вам це не допоможе, але, якщо це відбувається - у мене часто виникають дзвінки, через які мої користувачі не можуть отримати доступ до спільного доступу (їх старий пароль кешується Windows), і я маю це робити:

чисте використання * / D