Деанонимизируем пользователей Windows и получаем учетные данные Microsoft и VPN-аккаунтов


    Если вы не видите эту картинку, то данные вашей учетной записи Windows уже скомпрометированы.

    Введение

    Давным-давно, когда компьютеры были одноядерными и прекрасно работали с 256 МБ RAM, а сети под управлением Windows уже использовались очень широко, ребята из Microsoft подумали, что было бы удобно аутентифицироваться только один раз, при загрузке компьютера, а доступ на внутренние ресурсы происходил бы автоматически, без ввода пароля, и сделали так называемую технологию единого входа (Single Sign-on). Единый вход работает очень просто: когда пользователь пытается получить доступ к какому-либо ресурсу с NTLM-аутентификацией (стандартный способ аутентификации в сетях Windows), ОС сразу передает название домена, имя учетной записи и хеш пароля текущего пользователя, и если под этими данными войти не удалось, показывает диалог ввода имени пользователя и пароля. Шли годы, проблемы с безопасностью реализации технологии единого входа давали о себе знать, одни из которых успешно исправляли, другие исправляли менее успешно, а о третьих почему-то совсем забыли. Так и забыли о проблеме передачи учетных данных для единого входа на SMB-ресурсы (сетевые ресурсы: файлы и папки, принтеры, и т.д.) через интернет, которую можно эксплуатировать во всех современных ОС, включая Windows 10 со всеми последними обновлениями. Об этой особенности работы стека аутентификации вспоминают каждые 1-2 года, последний раз о ней рассказывали на Blackhat US 2015, но Microsoft не спешит что-либо менять.

    Как это работает?

    Как только вы пытаетесь открыть ссылку на SMB-ресурс в стандартном браузере (Internet Explorer, Edge) или любом приложении, работающем через стандартные вызовы API Windows или использующим Internet Explorer в качестве движка для отображения HTML (Outlook, проводник Windows), SMB-ресурс сразу получает данные вашей учетной записи еще до того, как вы увидите диалог ввода имени и пароля. Атакующему достаточно, например, добавить ссылку на картинку с SMB-сервера на страницу сайта, или отправить вам письмо, которое достаточно будет просто открыть, и — бум! — данные вашей учетной записи в руках злоумышленника. До недавнего времени считалось, что ничего особо страшного от того, что кто-то узнает имя вашей учетной записи и хеш пароля домашнего компьютера не произойдет (если это не направленная атака), т.к. в имени зачастую написана ерунда, пароль часто не ставят, а если он и установлен, вряд ли его можно использовать во вред.

    Ситуация кардинально меняется в случае корпоративного компьютера, который введен в домен. Из названия домена обычно несложно понять, к какой организации относится учетная запись, а дальше, в случае успешного подбора пароля, можно попробовать аутентифицироваться на корпоративных ресурсах, доступных из интернета (почта, VPN).
    Но пароль не всегда необходимо подбирать. Если вы наперед знаете какой-то ресурс, куда можно входить с использованием NTLM-аутентификации, вы можете в режиме реального времени, как только клиент подключится к вашему SMB-серверу, проксировать запросы от клиента к удаленному серверу и от сервера к клиенту, и успешно на нем аутентифицируетесь! Если вам повезло, и вы находитесь в одном сегменте сети с администратором домена и знаете IP домен-контроллера, вы без труда им завладеете, что показывал Intercepter еще два года назад:


    Windows 8 и Microsoft Account

    Современные операционные системы от Microsoft тесно интегрированы с интернетом и практически вынуждают вас создавать не локальную учетную запись для входа в систему, а аккаунт Microsoft. Без MS-аккаунта вы не сможете воспользоваться, например, магазином приложений, OneDrive и Cortana, а другое ПО будут постоянно рассказывать вам, как хорошо бы вам жилось с синхронизацией файлов, настроек и почты, если вы его себе зарегистрируете.
    Все ранние серьезные исследования обсуждаемой особенности производились до Windows 8, и даже в презентации с Blackhat учетная запись Microsoft упоминается только вскользь, а зря — при использовании Microsoft Account на компьютерах под управлением Windows 8, 8.1 и 10, ваша ОС передаст на SMB-сервер злоумышленника в интернете данные не вашего локального аккаунта, с которыми почти ничего нельзя сделать, а скомпрометирует прямо-таки вашу учетную запись Microsoft, с которой можно вытворять гораздо более веселые вещи. Таким образом, старую атаку, которая все эти годы представляла угрозу только корпоративному сектору, теперь вполне можно применять и на домашних пользователях.

    Новые подробности

    Во время тестирования передачи учетных данных под разными версиями Windows я обнаружил, что 3 машины с Windows 10, которые были установлены относительно давно, вполне успешно общаются упрощенными реализациями SMB (Responder, Impacket), а компьютер со свежеустановленной ОС почти сразу после подключения разрывает соединение, не успевая передать данные для входа, хотя отлично работает с полноценной Samba. Несколько дней отладки открыли интересную особенность стека учетных записей Windows: если NetBIOS и Workstation-имена SMB-сервера совпадают, то Windows использует текущую учетную запись (локальную или Microsoft) для входа на ресурс, но если имена не совпадают, и вы подключены к VPN с аутентификацией по MSCHAPv2, то ОС отправляет логин и хеш пароля этого VPN-подключения! Я предположил, что данная особенность присуща MSCHAPv2-аутентификации в целом, но нет, с Wi-Fi WPA-Enterprise (PEAP/MSCHAPv2) такой трюк не работает.

    Как это использовать?

    Итак, мы выяснили, что любой, кто попытается открыть какой-то файл или директорию с нашего SMB-сервера из-под Windows, автоматически отправит свои данные либо локального аккаунта, либо аккаунта Microsoft, либо логин и хеш пароля от VPN. Что же мы можем с этим сделать?

    Самый простой способ эксплуатации — просто настроить SMB-сервер и отслеживать, кто же будет пытаться на него войти. Долго ждать не придется, т.к. весь маршрутизируемый диапазон IPv4-адресов постоянно сканируется с целью наживы. Сканеры часто запускаются на Windows-компьютерах, многие их них по умолчанию аутентифицируются с текущей учетной записью. Так мы можем узнать имя компьютера, имя пользователя и хеш пароля машины, с которой нас сканируют. Весело, но малорезультативно, ведь что-то вменяемое в имени пользователя пишут не так уж и часто, MS-аккаунты на сканерах практически не используют, а с локальной учетной записью доступ вряд ли куда-то можно получить. Для сбора хешей проще всего использовать Responder, я добавил в него настройку, чтобы можно было собирать несколько хешей, если таковые имеются, манипулируя NetBIOS-именем (CaptureMultipleCredentials = On в конфигурационном файле).

    Эксплуатация с целью деанонимизации — поинтересней. Учетка будет отправляться со страниц сайта, если жертва использует Internet Explorer, или при клике внутри письма, в случае с Outlook. Почти все веб-интерфейсы почтовых служб фильтруют картинки со схемой file:// при выводе письма (схема file:// является аналогом схемы \\), но не Яндекс, который не считает это своей уязвимостью (что, в общем-то, корректно). Деанонимизация с использованием почты более опасна, т.к. дает связь не только IP-адреса с аккаунтом Windows, но и с почтой.


    В Chrome схема file:// тоже работает, но только из адресной строки, как и в Firefox (но в нем, наоборот, работает только \\, но не file://). Загрузить что-либо с SMB картинкой или при нажатии на ссылку не получится. Так как Chrome и Firefox гораздо популярней Internet Explorer, придется применять социальную инженерию.
    image

    Можно воровать аккаунты себе во благо. Некоторые VPN-провайдеры используют одинаковые логины и пароли как для входа в аккаунт, так и для VPN-аутентификации. Принадлежность аккаунта к тому или иному сервису можно определить по IP-адресу входящего подключения пользователя. А если вам достался Microsoft Account, и вы нашли пароль из хеша, то поздравляю — у вас есть доступ к файлам в облаке OneDrive, почте Outlook, аккаунту Skype, если он привязан к Microsoft-аккаунту, и еще куче всего.


    image

    Разумеется, старые известные атаки вроде SMB Relay тоже продолжают работать.

    Как защититься?

    Не стоит думать, что вы в полной безопасности, если не пользуетесь Internet Explorer и не открываете вручную ссылки со схемой file://. Достаточно установить не слишком надежное приложение, которое попытается загрузить какие-то данные с SMB-сервера через штатные функции Windows API, например, URLDownloadToFile(). Таким образом приложение, у которого нет привилегий на получение пароля вашей учетной записи, украдет его через интернет.

    Если вам не нужен доступ к SMB-ресурсам в интернете, надежнее всего стандартным брандмауэром Windows ограничить доступ к 445, 137 и 139 TCP-порту для всех диапазонов адресов, кроме:
    • 192.168.0.0/16
    • 169.254.0.0/16
    • 172.16.0.0/12
    • 10.0.0.0/8
    • fd00::/8
    • fe80::/10

    Некоторые провайдеры, например Ростелеком, блокируют доступ по этим портам в своих сетях, что довольно мило с их стороны.

    UPD: в комментариях navion и dartraiden подсказывают правильный способ:
    Скрытый текст
    Windows Registry Editor Version 5.00
    
    [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
    "RestrictReceivingNTLMTraffic"=dword:00000002
    "RestrictSendingNTLMTraffic"=dword:00000002

    Заключение

    Я добавил возможность проверить, касается ли вас эта проблема, в WITCH?. Попробуйте открыть ее через Internet Explorer или Edge, и если ваш хеш утекает в интернет, WITCH? попробует подобрать пароль, используя небольшой словарь, и покажет вам его. Если перед заходом подключитесь к VPN, то WITCH? также покажет данные вашего VPN-аккаунта. Если вы читаете эту статью через вышеупомянутые браузеры, то ваш хеш уже у меня :)
    О проблеме известил некоторых VPN-провайдеров, которые либо заблокировали SMB-порты внутри VPN, либо добавили опцию для локальной блокировки в свое ПО.
    Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши. Просто не могут подобрать пароль, хотя он гарантированно есть в словаре. С oclHashcat и Hashcat 3.0, вроде бы, все в порядке. Остается только догадываться, сколько паролей не было взломано из-за этих ошибок…
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 190
    • +3
      Деанонимизируем пользователей Windows. Снова.
      • +3
        Это негуманно! Никто не может быть осуждён деанонимизирован повторно за одно и то же преступление!
      • +1
        У меня не воспроизводится. Для логина используется аккаунт Майкрософт.
        Скрин
        image
        • 0
          А что за провайдер, может, он порт 445 блокирует?
          • 0
            Дом.ru. Насчёт блокировки портов ничего не знаю.
          • 0
            пробовали в другой вкладке открыть file://witch.valdikss.org.ru/?
            у меня на edge сработало
            • +1
              Не работает.
              Скрин
              image
              • 0
                ссылка на файл у меня тоже не открылась, но после этого вкладка с сайтом увидела аккаунт
                • 0
                  Нужно обязательно что-то добавить в URL, например, file://witch.valdikss.org.ru/a
                  • 0
                    Не получается, видимо, провайдер действительно блокирует порт 445.
              • 0
                Подтверждаю, у меня тоже не сработало с аккаунтом MS. Пробовал разные браузеры, с VPN и без. No NTLM hash is leaked.
              • –9
                А в MS зарепортили?
                • +38
                  Им ежегодно сообщают, я не стал.
                • +3
                  Спасибо за статью.
                  Но я не понял одного момента, вроде в IE, в настройках по умолчанию, автоматический логон разрешен только в Intanet zone.
                  Т.е. эта атака подействует если пользователь изменил настройки безопасности?
                  Или я чего-то не понимаю?
                  • +20
                    Эта настройка, внезапно, просто игнорируется в библиотеке inetcplc.dll! Она считывается из реестра, но не обрабатывается.
                    • 0
                      Ух ты!!!
                      Вот за это огромное спасибо!
                      Правда с другой стороной, когда пытаешься развернуть какой-нибудь web сервис, на который доменный пользователь должен автоматом заходить, то приходится его адрес вносить в Trusted Sites. И только тогда пользователь начнет заходить, до этого у него спрашивает авторизацию.

                      Вообщем надо мне этот момент поподробней изучить, видимо.
                      • +7
                        Она не игнорируется, просто не имеет никакого отношения к SMB.
                        • +3
                          И это правильный ответ: настройка относится к прозрачной аутентификации в HTTP, к SMB/CIFS она отношения не имеет.
                    • 0

                      В первый момент возникала мысль: а что, ещё не все провайдеры блокируют 445-ый порт?

                      • 0
                        Билайн не блокирует, пришлось ручками помочь.
                      • +1
                        Брутилка сломалась, довольствуйтесь пока только хешами.
                        • +2
                          Можете использовать https://msleak.perfect-privacy.com/
                          • 0
                            Вроде починил. Очередь небольшая, пока справляемся.
                            • 0
                              Похоже глючит кэширование со стороны сервера при подключении с нескольких машин за NAT. Мне с основной машины сейчас выдаёт логин и хэш узявимой виртуалки.
                              • +1
                                Показываются все хеши с одного IP, пришедшие в течение последних 2 минут.
                            • 0
                              А есть какой-нибудь заведомо рабочий SMB-сервер, чтобы проверить блокировку портов у провайдера?
                              • +1
                                Установите nmap, сделайте
                                nmap -p 445 31.220.5.43

                                Если STATE не open, то, вероятно, провайдер блокирует.
                                • 0
                                  Телнетом подключился, но на 8.1 через IE хэш не утекает.
                                  • 0
                                    А там какая версия SMB используется? У меня не установлена поддержка 1.0 и из-за этого на 8.1 может не работать.
                          • +1
                            Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши. Просто не могут подобрать пароль, хотя он гарантированно есть в словаре. С oclHashcat и Hashcat 3.0, вроде бы, все в порядке. Остается только догадываться, сколько паролей не было взломано из-за этих ошибок…


                            А можно поподробнее?
                          • +3
                            «Для меня оказалось откровением то, что популярные утилиты — Hashcat (-legacy) и John The Ripper (OpenCL-реализация) — неправильно взламывают NTLMv2-хеши»

                            Скорее всего некорректно сформирован хеш для брута, сам на этом попадался в jtr. Но если с этим же хешем иные сборки работают правильно, то дело конечно в самих крякерах.
                            • +2
                              apistoletov@outlook.com::MicrosoftAccount:1122334455667788:9C22646B3139840F7B0F83ED88D0EE5F:01010000000000004013BCA0D0E4D10182D8FAEDA695C1340000000002000A0053004D0042003100320001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D00420031003200080030003000000000000000010000000020000020B3933DD93DA6CA0E16279689BEEB7BD3F8DB084528F396AA0B9899391BCC310A001000000000000000000000000000000000000900200063006900660073002F00330031002E003200320030002E0035002E00340033000000000000000000

                              Пароль — 123123qq. Hashcat-legacy не находит. Сейчас поищу еще без пароля, которые john с --format=ntlmv2-opencl не мог сбрутить.
                              • 0
                                которые john с --format=ntlmv2-opencl не мог сбрутить

                                было бы здорово
                                • +1
                                  valdikss::MicrosoftAccount:1122334455667788:F74ECC1AECC1D113782C823BB330772E:010100000000000039B063751BECD1017BAAF43DFFEEB51D0000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000

                                  Пароль — 123qq

                                  cc: Intercepter
                                  • +1
                                    Странно, у меня все находится.

                                    $ cat ValdikSS_2.dic
                                    123qq

                                    $ cat ValdikSS_2.pass
                                    valdikss::MicrosoftAccount:1122334455667788:F74ECC1AECC1D113782C823BB330772E:010100000000000039B063751BECD1017BAAF43DFFEEB51D0000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000001000000001000007A91E6D78F02D98EB60F535074AB74D9FA5E62D85D40CB60DC5510339F9537450A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000

                                    $ ./john --format=ntlmv2-opencl -w=ValdikSS_2.dic -pot=ValdikSS_2.pot ValdikSS_2.pass
                                    Device 1: Tahiti
                                    Loaded 1 password hash (ntlmv2-opencl, NTLMv2 C/R [MD4 HMAC-MD5 OpenCL])
                                    Press 'q' or Ctrl-C to abort, almost any other key for status
                                    123qq (valdikss)
                                    1g 0:00:00:00 DONE (2016-08-02 09:52) 2.857g/s 5.714p/s 5.714c/s 5.714C/s 123qq
                                    Use the "--show" option to display all of the cracked passwords reliably
                                    Session completed


                                    Есть возможность поподробнее описать ситуацию тут? — https://github.com/magnumripper/JohnTheRipper/issues/2194

                                    • +1
                                      Написал. На git-версии находится, на релизной — нет.
                            • 0
                              проксировать запросы от клиента к удаленному серверу и от сервера к клиенту, и успешно на нем аутентифицируетесь!


                              Правильно ли я понимаю, что это работает только если у клиента разрешен NTLMv1? По умолчанию он запрещен начиная с Win 7, с чем у нас были как-раз проблемы, так как Alfresco очевидно не может поддерживать NTLMv2 pass through authentication :(
                              • +2
                                Нет, работает и с NTLMv2, но только с отключенной SMB Signature.
                                • 0
                                  А по-моему будет работать и с SMB Signing. SMB Signing должно помогать только от релея SMB -> Rogue SMB -> SMB, а от SMB -> Rogue SMB -> HTTP — не должно, по идее. Там же просто SMB-пакеты подписываются NT-хэшем (условно). Но вообще надо пробовать.

                                  В любом случае, находка с MS Account шикарная, вся кривая попытка MS сделать облачный «домен» из обычного трещит по швам :) Полагаю, есть даже шанс что исправят на сей раз. Облако — это у них сейчас святое.
                                  • 0
                                    > вся кривая попытка MS сделать облачный «домен» из обычного трещит по швам :)

                                    Не надо таких глупостей писать, построенные на OAuth «облачные домены» сейчас используются более-менее всеми, и то же самое использует облако MS. Вся проблема в том, что MS, в отличие от остальных провайдеров аутентификации, надо тащить груз обратной совместимости с кучей древнего и/или криво написанного софта, отсюда периодически и всплывают косяки.
                                    • 0
                                      Нет, вся проблема в том что MS встроила облачный аккаунт кривым образом в Windows, и теперь он зачем-то используется для проверки подлинности по SMB, в котором в свою очередь без Кербероса (а его не будет, если это домашний пользователь) без вариантов используется древний NTLM.

                                      MS вместо логичной архитектуры прикрутили облако к Windows всеми костылями, какие были под рукой. Причем в W8 это было бы простительно, но то что в W10 работы над ошибками не случилось — показательно.
                                      • 0
                                        > Нет, вся проблема в том что MS встроила облачный аккаунт кривым образом в Windows

                                        «Кривое» встраивание — это следствие из того, о чем я вам пишу — нужна обратная совместимость. Если юзер залогинен с аккаунтом MS, он, тем не менее, должен всё ещё быть способен работать внутри рабочей или домашней сети, в том числе иногда и с ресурсами, которые не понимают ничего, кроме NTLM.

                                        Я уверен, что вы, как большой гуру в таких делах, всё сделали бы сразу и без ошибок, но, к сожалению, такие идеальные люди, как вы, не проектируют софт и не пишут код. Поэтому периодически появляются такие ошибки. А также случаются всякие нearthbleed, shellshoсk, дырки в аутентфикации различных сервисов, и т.п. :) А мы с этим живем.

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


                                        Тут по соседству в ветке как раз обсуждается PKU2U.
                              • 0

                                No NTLM hash is leaked. Edge.

                                • 0

                                  Провайдер блокирует 445-й порт.

                                • 0
                                  Сначала выдал это:

                                  :1122334455667788:813A2FE0D59A69680908C8E808F49BBF:0101000000000000504BB5280BECD101B87D68927A8E96360000000002000E004E004F004D00410054004300480001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D0042003100320008003000300000000000000000000000002000005377377153B0C0362E732719935BDA82E8614B42CAE0BB1D711EB51514F93B0A0A001000000000000000000000000000000000000900340063006900660073002F00770069007400630068002E00760061006C00640069006B00730073002E006F00720067002E00720075000000000000000000

                                  Потом no hash is leaked

                                  Неужто такой хэш брутится??
                                  • 0
                                    У вас что-то косячит.
                                    Windows 10/Firefox 47. Пишет:

                                    Скрин
                                    image

                                    C Edge то же самое, открытие новой вкладки с file:// не помогает…
                                    • +1
                                      В Firefox и не должно работать, он не поддерживает SMB.
                                      • +1
                                        У вас же прокси, да? С прокси не будет работать.
                                        • +2
                                          Нет, я сижу напрямую с IP, выданного провайдером… Только DNS от DNS.Watch. Никаких прокси и средств анонимизации в системе.
                                          Сервис 2ip выдал верный браузер и систему.

                                          Хочу отметить, что ваш сервис раньше выдавал верные данные, т.к. я видел ваш сайт раньше. Но после последнего накопительного обновления теперь некорректно определяет ни браузер ни систему, тот же IPLEAK выдает верные данные. Не знаю, с чем связано, возможно какие-то недокументированные патчи.
                                          • +1
                                            За что минусуют? Я ниже уточнил, что в Edge также не работает у меня. Пример с Firefox привел в доказательство того, что вне зависимости от браузера неверно определяет систему и текущий браузер. Причём, сижу без каких-либо средств анонимизации.

                                            Не поленился, запустил IE11. Результат вообще огонь:
                                            Заголовок спойлера
                                            image


                                      • +7

                                        Можно без фаервола групповыми политиками:


                                        • Network security: Restrict NTLM: Incoming NTLM traffic.
                                        • Network security: Restrict NTLM: Outgoing NTML traffic to remote servers.
                                        • +1
                                          Класс, работает без домена?
                                        • 0
                                          А можно попроще — как это?
                                          • +1
                                            RTFM
                                            https://technet.microsoft.com/library/jj852213(v=ws.10).aspx
                                            https://technet.microsoft.com/library/jj852167(v=ws.10).aspx
                                            • +3
                                              Вот, за Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options спасибо. А то фиг так поймешь, где оно спрятано.
                                            • +4
                                              • +4
                                                Для владельцев домашних редакций Windows (в которых нет оснастки управления групповой политикой):

                                                Windows Registry Editor Version 5.00

                                                [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
                                                "RestrictReceivingNTLMTraffic"=dword:00000002
                                                "RestrictSendingNTLMTraffic"=dword:00000002
                                                • +4
                                                  Важная ремарка: после этого перестает пускать по RDP.
                                                  Не наступите на мои грабли.
                                                  • 0
                                                    Проверил: пускает. Windows Server 2012R2.
                                                    • 0
                                                      У меня на домашней Windows 10 стало выдавать ошибку:
                                                      An authentication error has occurred.
                                                      The function requested is not supported.

                                                      Подключился через PowerShell, удалил эти значения из реестра — RDP заработал.
                                                      Видимо здесь срабатывает комбинация факторов.

                                                      В любом случае — лучше проверить, чтоб не остаться без рук.
                                                      • 0
                                                        Домашняя — это дома или Windows 10 Home?
                                                        • 0
                                                          Как раз хотел дописать, уточнить. Имел ввиду дома. Редация Pro.
                                                    • 0
                                                      Не пускает при включенном NLA и не запоминает пароли.
                                                      • 0
                                                        Когда как.

                                                        Обращение по RDP к доменному серверу по имени (в том числе с недоменной машины) — не перестаёт, там работает Kerberos.

                                                        Обращение по RDP к недоменному серверу, или к любому по IP — перестанет, надо дополнительно включить политику «NTLM: Добавить удаленные серверы в исключения....»

                                                        Исключения можно добавить вообще для любых серверов, законно требующих NTLM, не только RDP.
                                                        • 0
                                                          Windows 8.1 Проф — перестал запоминать пароль для RDP, после применения локальных политик
                                                          • 0

                                                            Ага, отваливается в том числе и Azure VM RDP, причем жестко


                                                            Сегодня вот отобщался с саппортом который помогал восстановить доступ к машине по RDP. Печально вот так применять реестрик чтобы одну проблему исправить, а вторую, скрытую, добавить.

                                                            • 0
                                                              Именно поэтому надо не тупо копировать найденные на просторах интернета настройки реестра, а сначала понять, что они делают. Там, блин, даже опция предварительного аудита для этого есть. Нет никакой «скрытой проблемы», есть недостаточное понимание вопроса.
                                                              • 0

                                                                А что они делают — вполне понятно. А вот почему такая комбинация приводит к неработоспособным новым RDP ( которые с NLA) — не очень понятно, потому как NTLM это вроде как не очень свежее и очень внутридоменное и локальное, и какого это внутрилокальное влияет на RDP по интернету (куда никакие NTLM вообще ходить не должны ) — не так уж очевидны

                                                                • 0
                                                                  Угу. Сначала «всё понятно, ща я настрою!» А потом «ой, всё сломалось». У тех, кому понятно, настройки срабатывают полностью предсказуемым образом (если, конечно, не натыкаешься на баг).

                                                                  NTLM сам по себе не имеет никакого отношения ни к домену, ни к локальности — это просто встроенный в Windows протокол аутентификации, который изначально был основным, а сейчас по умолчанию используется, когда по какой-то причине недоступен Kerberos (например, при аутентификации на одиноком недоменном хосте). Интернет там или не интернет — разницы никакой.

                                                                  NLA же вообще не влияет на выбор способа аутентификации, а просто позволяет аутентифицировать пользователя до того, как тот установит RDP-сессию, а не после, как было до появления этого механизма.

                                                                  Поэтому надо понимать, что полное отключение NTLM отрубит доступ, в частности, ко всем недоменным ресурсам, для которых используется встроенная аутентификация Windows (если не предпринять каких-то мер, чтобы этого избежать).
                                                                  • 0

                                                                    Ну раз они все такие друг с другом не связанные — почему при выключеном NTLM не пускает на сервер по RDP (сервер не в домене, просто свежая виртуалка в ажуре) пока на сервере включен NLA.
                                                                    Выключаем NLA на сервере при выключенном NTLM на клиенте — все работает снова, включаем NLA и включаем NTLM — все тоже ок.


                                                                    Это клево конечно что МС в документации написали что никто ни на что не влияет, но по полученному фидбеку от инженера МС саппорта — они тоже удивились когда мы вместе докопались до реальной причины.

                                                                    • 0
                                                                      Потому что при выключенном NLA «аутентификация» между клиентом и сервером — не NTLM, а просто plain text, завернутый в RDP (вы устанавливаете RDP-сессию, когда у вас появляется окошко логина — передаете на сервер логин/пароль открытым текстом, а NTLM отрабатывает уже локально на сервере).

                                                                      Саппорт первой линии — это не всезнающие люди. Обычно они более-менее натасканы на решение часто встречающихся проблем, а запрет NTLM на клиенте к таковой не относится.
                                                                      • 0

                                                                        Это была вторая линия, первая обычно там мартышки на телефоне, он лазил по логам… Ну или они сильно проапгрейдили саппорт.
                                                                        Извините но или я не понимаю ваши аргументы или вы не очень четко объясняете, т.к. я все еще не могу понять:
                                                                        при ВКЛЮЧЕННОМ NLA на сервере в облаке ( не доверенный домен, не локальная сеть, не VPN) почему клиентские настройки NTLM влияют на способность подсоединяться по RDP?


                                                                        Пока у меня сложилось впечатление что вы утверждаете что настроки NTLM на клиенте НЕ могут влиять на способность ходить по RDP на сервер с NLA. Но тогда ваши утверждения противоречат моей реальности.

                                                                        • +1
                                                                          Это я непонятно объясняю. :)

                                                                          Когда работает RDP без NLA, там механизма сетевой аутентификации как такового нет. Вы просто открываете RDP-сессию на сервер, и он локально обрабатывает весь ваш ввод. Поэтому NTLM тут не при делах.

                                                                          Что происходит, когда работает NLA?
                                                                          Клиент подключается, сервер просит NLA. А дальше задействуется механизм согласования протокола аутентификации между клиентом и сервером (SPNEGO), который и согласовывает протоколы из доступных на сервере и клиенте. Этот протокол не является частью RDP-клиента, он общесистемный. Именно это я имел в виду, говоря «NLA сам по себе не влияет на выбор протокола». Что система предложит, то и будет использоваться. Проблема в том, что по умолчанию система предлагает либо Kerberos, либо NTLM. То есть при недоступности домена остаётся только NTLM, отсюда и грабли.
                                                                          • 0

                                                                            Теперь понятно, спасибо. Это печалька что при использовании NLA опять надо быть или доменным пользователем или ходить со старым NTLM

                                                                      • 0
                                                                        Так, я немного уточню предыдущие комментарии, вредно отвечать быстро :)). При установлении RDP-сессии без NLA локально работает, конечно, не NTLM. Что касается NLA — замечание о том, что этот механизм не влияет на выбор способа аутентифкации, следует понимать как «при использовании NLA вы можете использовать любой поддерживаемый клиентский SSP, сама по себе технология не диктует выбор какого-то определенного способа аутентификации».
                                                              • 0
                                                                Важная ремарка: после этого перестает пускать по RDP.
                                                                Не наступите на мои грабли.


                                                                Не только RDP, после этого не работают сетевые ресурсы \\COMPUTERNAME
                                                          • +1
                                                            Через реестр:
                                                            Windows Registry Editor Version 5.00

                                                            [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
                                                            "RestrictSendingNTLMTraffic"=dword:00000002
                                                            "RestrictReceivingNTLMTraffic"=dword:00000002

                                                            • 0

                                                              Если наступили на эти грабли и у вас перестал работать RDP к серверам — вот как вычистить эти эээ "настройки безопасности" через PowerShell ( выполнять под админом):


                                                              # these settings are the conflicting configuration on the client
                                                              Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
                                                              Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
                                                              
                                                              # Remove these settings to restore NLA support for RDP and working latest RDP to Azure VMs
                                                              Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
                                                              Remove-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
                                                              
                                                              # Restore these settings to have protection from NTLM hash leak until there will be better ways to prevent the problem
                                                              #Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic" -value 2
                                                              #Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic" -value 2
                                                              
                                                              Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictReceivingNTLMTraffic"
                                                              Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -name "RestrictSendingNTLMTraffic"
                                                            • +1
                                                              Пуск -> Панель управления -> Административное -> Службы -> Модуль поддержки NetBIOS через TCP/IP -> Свойство -> Нажать стоп и сменить тип запуска на «Отключена»
                                                              • 0
                                                                В этом случае ресурсы локальной сети также не работают,
                                                                аналогично этому: https://habrahabr.ru/post/306810/#comment_9729830
                                                                • 0
                                                                  Ну или шашечки или ехать, самый быстрый и простой для рядовых юзеров способ.
                                                            • +1
                                                              Работает, но отвалился сетевой диск в проводнике.
                                                            • –8
                                                              Кстати, у меня Руслан Карманов ответил в комментах.

                                                              "> Итак, мы выяснили, что любой, кто попытается открыть какой-то файл или директорию с нашего SMB-сервера из-под Windows, автоматически отправит свои данные либо локального аккаунта, либо аккаунта Microsoft, либо логин и хеш пароля от VPN. Что же мы можем с этим сделать?

                                                              Ничего, потому что это дефолтное поведение дефолтных настроек NT 6.0.

                                                              Известно это 10 лет, и лечится настройками NTLMv2. EPA, в частности.

                                                              http://www.atraining.ru/lm-ntlm-ntlmv2-armoring/

                                                              Проверено с 5 серверов и домашней машины — ничего оный тест не видит, ничего ему не отправляется.

                                                              Ломать дефолтные настройки винды, которые сделаны для совместимости — удобно и приятно, я понимаю.

                                                              Просто реальность такова, что это не дыра — это личный уровень компетентности автора.

                                                              Примерно поэтому мы курсы дописываем по материалу сами, а не стандартные Microsoft'овские про Next-next-finish читаем. Потому что натаскивание на «как можно быстрее деплоить дефолтные конфиги» приводит к таким вот постам.

                                                              СЕНСАЦИЯ! ВЕНДА ВЗЛОМАНА ПОЛНОСТЬЮ! ПАРОЛЬ МОЖНО ПОДОБРАТЬ ЗА ПОЛСЕКУНДЫ! Ну и так далее. На тему а-ля «по дефолту, оказывается, LM-хэш сохраняется»."
                                                              • +8
                                                                Так, э, никакой сенсации и нет, я знаю, что эта проблема известна еще с 1997. Автор комментария, вероятно, не читал статью.
                                                                • +23
                                                                  Остается один вопрос.
                                                                  Почему поведение винды, по дефолту, практически во всех случаях, это «лечь и раздвинуть ноги»?
                                                                  • +5
                                                                    Потому что выбирались эти настройки в инфантильную эпоху эйфории от прогресса…
                                                                  • 0
                                                                    Можно по подробней, что именно необходимо настроить из этой статьи? Выполнил почти все, что можно выполнить с локальной машины без Active Directory, но хэш все равно утекает:

                                                                    1. Отключил хранение хэшей LAN Manager (было и так включено в политиках)
                                                                    2. Отправка только NTLMv2-ответов с отказом от LM и NTLM
                                                                    3. Требование NTLMv2 при RPC-запросах (на всякий случай)
                                                                    4. EPA: HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA \ DWORD-параметр SuppressExtendedProtection 0 и 3 пробовал
                                                                    5. EPA для SMB: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ LanmanServer \ Parameters \ DWORD-параметр SmbServerNameHardeningLevel 1 и 2 пробовал

                                                                    Ничего из этого не помогло против WITCH. Блокировать полностью NTLM трафик пока не готов, как советуют коллеги выше и ниже
                                                                    • +1
                                                                      Я не вижу, как EPA может спасти от автоматической попытки аутентификации, этот механизм совсем от другого защищает.

                                                                      >Блокировать полностью NTLM трафик пока не готов, как советуют коллеги выше и ниже

                                                                      Не надо сразу блокировать. Надо сначала включить аудит и посмотреть, а куда у вас вообще машина по NTLM ходит.

                                                                      А если вы сами уже точно знаете, куда должна — тогда включаете политику для блокировки и политику для исключений, они там рядышком.
                                                                      • 0
                                                                        можете использовать:
                                                                        Windows Registry Editor Version 5.00

                                                                        [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]
                                                                        "RestrictReceivingNTLMTraffic"=dword:00000002
                                                                        "RestrictSendingNTLMTraffic"=dword:00000002
                                                                        "ClientAllowedNTLMServers"=hex(7):31,00,39,00,32,00,2e,00,31,00,36,00,38,00,2e,\
                                                                        00,2a,00,00,00,00,00

                                                                        это оставляет 192.168.* рабочими
                                                                        • 0
                                                                          Спасибо, помогло! Хэш наружу закрыт, внутри всё проходит.
                                                                          • 0
                                                                            Не работает:
                                                                            Windows не может получить доступ к \\COMPUTERNAME
                                                                            Проверьте правильность написания данного имени. В противном случае возможна проблема с вашей сетью. Для определения и разрешения проблем с сетью щелкните кнопку «Диагностика».


                                                                            Win10 Pro, 192.168.0.0/24
                                                                            • 0
                                                                              к сожалению тут смотрится не айпи, а имя по которому обращаетесь (у меня просто обращение по ip), поэтому тут только добавить все интересующие имена (может даже в таком виде *.office.somedomain) — просто открыть руками реестр и добавить строчки с именами в ClientAllowedNTLMServers
                                                                              ну либо закрывать фаерволом
                                                                              • 0
                                                                                Ок, спасибо. Когда писал ответ что «192.268.*» не работает, поиск в гугле формата «ClientAllowedNTLMServers» был безрезультатный.
                                                                              • 0
                                                                                Подтверждаю, отвалилась Домашняя Группа с цифровой подписью пакетов. Впрочем и без подписи аналогично не работает. Win 7 Ult.
                                                                              • 0
                                                                                Хз, чет не помогло =( Даже с Allow, перестали монтироваться диски через cifs на ubuntu… Стираешь ключи, все работает… Ставишь, диски не монтируются.
                                                                          • 0
                                                                            Что-то вообще никак не работает. Ни один из тройки браузеров хэш не показал и все трое отказались переходить на «file://» ссылку. Настройки в десятке все стандартные, в качестве юзера используется учетка МС. Никаких VPN, обычный interz
                                                                            • +1
                                                                              Под Хромом и под Edge результаты разные (причем противоположно — по версии браузера и ОС) но Edge действительно сдал WindowsID и хеш. Мощная технология!
                                                                              • 0
                                                                                Есть мнение, что локально это блокируется отвязкой CIFS от VPN-интерфейсов использующихся для анонимизации. Если VPN корпоративный, то галку оставить, но блокировать на корп периметре — как для внутренней сети, так и для VPN-клиентов. Что вроде очевидно.

                                                                                При этом, блокировать tcp/445 — маловато будет.
                                                                                Занимался давно, могу наврать, но:
                                                                                1) CIFS умеет работать как по tcp, так и по udp. Соответственно надо фильтровать и udp/445
                                                                                2) SMB, со всей своей утечкой хешей, бывает (был?) и через NBT. А это уже tcp/139.


                                                                                • 0
                                                                                  Есть мнение, что локально это блокируется отвязкой CIFS от VPN-интерфейсов использующихся для анонимизации.
                                                                                  Не работает, я проверил. С OpenVPN работает, т.к. он устанавливает свой драйвер сетевого интерфейса, а вот на VPN-подключениях Windows не работает.

                                                                                  NetBIOS через TCP по умолчанию отключили в каком-то недавнем обновлении.
                                                                                  • 0
                                                                                    О как. А какая винда? На XP проверял когда-то — вообще SMB трафика не было при отвязанном MS-клиенте.
                                                                                    Через DNS правда текло. Но лечилось.

                                                                                    Кстати, через WebDAV еще фильтрацию CIFS обрйти можно.
                                                                                    • 0
                                                                                      Пробовал Windows 7 и 10. Думаю, через WebDAV не будет посылаться хеш в интернет, но нужно попробовать.
                                                                                • +1

                                                                                  В следующей статье:


                                                                                  Шокирующие новости! Аккаунт ValdikSS на Хабре взломали, сервер использовался для взлома аккаунтов всех посетителей Хабрахабра!

                                                                                  • +1
                                                                                    Спасибо! Вы открыли мне глаза на безопасность моего VPN. Сижу в тихом шоке. На Edge через L2TP показало все что нужно.
                                                                                    • +1
                                                                                      Что я у себя сломал?
                                                                                      Ужасающая истина

                                                                                      • +1
                                                                                        Это нормально, так и должно быть.
                                                                                        • +1
                                                                                          А почему хеш не утекает? Опечален.
                                                                                          • +1
                                                                                            Попробуйте это.
                                                                                            • 0
                                                                                              C виртуалки на убунте порт открыт.
                                                                                              • +1
                                                                                                Попробуйте на этот IP зайти, что ли.
                                                                                                file://31.220.5.43/a
                                                                                                • 0
                                                                                                  Тоже самое.
                                                                                                  Ах да, я забыл, что у меня на ограниченной учётной записи нет пароля, а из под админа запускать не хочу, боюсь.
                                                                                                  Виноват.
                                                                                                  • +1
                                                                                                    DcFan?
                                                                                                    • 0
                                                                                                      ?
                                                                                                      • +1
                                                                                                        Некий DcFan кто-то зашел прямо перед вашим комментарием, я и подумал, что это вы.
                                                                                                        • +11
                                                                                                          Вы меня сейчас дважды деанонимизировали.
                                                                                      • 0
                                                                                        Необходимо еще NetBios закрывать. TCP и UDP 137-139 и 445
                                                                                        • +1
                                                                                          NetBIOS через TCP отключили по умолчанию, насколько мне известно, пару месяцев назад.
                                                                                          • 0
                                                                                            Для теста виртуалка с Win10 со всеми обновлениями со стандартными настройками. Пока TCP 137-139 не закрыл — хэш утекал.
                                                                                            А если дома не один комп — лучше перестраховаться, тем более, что NetBios в Интернет не нужен
                                                                                            • 0
                                                                                              Win7 об этом ничего не знает. Так что alfutur прав — TCP137,139,445 UDP138.
                                                                                              • +1
                                                                                                Добавил в статью, спасибо.
                                                                                          • 0
                                                                                            А с VPN всегда передаёт реквизиты или только с установленной по-умолчанию галкой?
                                                                                            Include Windows logon domain


                                                                                            С отрицанием история забавная — на каждом мероприятии у MS рассказывают про более продвинутую атаку на Kerberos, а этой как бы не существует, хотя даже в STIG нет рекомендаций по фильтрации NTLM.
                                                                                              • 0
                                                                                                Стало интересно, спасает ли от данной уязвимости антивирус (у меня установлен Avast Internet Security). Это же вроде как и есть сетевая угроза. Оказалось, что нет. Открыл ссылку в edge и сразу пошел менять пароль на аккаунт.
                                                                                                • 0
                                                                                                  От данной уязвимости не защитил даже DrWeb Security Space, что уж говорить про Аваст, у которого защита в разы ниже.
                                                                                                  • 0
                                                                                                    У меня оставался ровно месяц до окончании лицензии Avast. Я решил его снести и протестировать с Kaspersky. Дефолтно он от данной уязвимости не спасает. Помогает активация расширения «Kaspersky Protection» в Chrome + установка режима блокировки запросов сбора данных.

                                                                                                    P.S. Думаю, надо дополнить, что Avast IS у меня работал в параноидальном режиме.
                                                                                                    • 0
                                                                                                      Я был не прав.

                                                                                                      В Chrome увидеть данные учетной записи можно только после посещения данной ссылки через Edge/IE.

                                                                                                      Вывод — в данном случае Avast IS и Kaspersky IS одинаково бесполезны.
                                                                                                  • 0
                                                                                                    Так это не уязвимость, и не баг — это фича! © Microsoft
                                                                                                    ))))
                                                                                                  • +1
                                                                                                    Можете код дать сайта, который используется для теста.
                                                                                                  • 0

                                                                                                    Я думал они уже давно NTLM выпилили, он уже довольно давно считается устаревшим и небезопасным. Вместо него предлагаяется использовать Kerberos.


                                                                                                    А то что настройка игнорируется, вообще "порадовало" — вот это настоящий epic fail!


                                                                                                    @ValdikSS, спасибо, читать как всегда очень интересно и познавательно.

                                                                                                    • +1
                                                                                                      Простите, но как вы себе представляете применение Kerberos для аутентификации на компьютере, не входящем в домен?

                                                                                                      Собственно, вся безопасность Kerberos достигается за счет наличия отдельного доверенного сервера (KDC), который проверяет учетные данные пользователей и, в случае их корректности, предоставляет билеты на доступ к сервисам. И понятно, что если два компьютера не входят в один и тот же домен, то KDC которому могли бы доверять оба этих компьютера, просто напросто не существует.

                                                                                                      В общем, Kerberos далеко не панацея и наличие NTLM вполне оправдано, на мой взгляд. Хотя, конечно, с описанным в статье поведением бороться надо. Например, по умолчанию активировав запрет на доступ к удаленным SMB-серверам
                                                                                                      • 0

                                                                                                        Благодарю за развернутый ответ! Я просто не думал что NTLM сейчас где-то может использоваться без нормального контроллера домена.
                                                                                                        Ведь в этом случае вам придется вручную настраивать учетные записи на компьютерах и синхронизировать пароли между клиентом и сервером, иначе NTLM не заработает.


                                                                                                        Насколько мне известно на данный момент для построения сетей без контроллера домена, у Microsoft есть новая фишка, называется она "Домашняя группа". Там используется протокол PKU2U, который, если не ошибаюсь, и использует Kerberos для аутентификации пользователей.

                                                                                                        • 0
                                                                                                          Понятно, что без домена для более или менее крупной организации не обойтись. Но для малого офиса или дома NTML вполне себе вариант.

                                                                                                          Да, я в курсе про домашнюю группу, но пользоваться ей, лично мне, было не удобно — слишком много магии. Нигде нет нормального описания как это работает и что делать, когда что-то сломалось. Проще уж одинаковых учеток насоздавать.

                                                                                                          Про PKU2U я правда не знал, и нормального описания этого протокола пока не нашел. Буду благодарен за полезные ссылки на эту тему.
                                                                                                          • 0
                                                                                                            https://tools.ietf.org/html/draft-zhu-pku2u-09
                                                                                                            • 0
                                                                                                              Не совсем то, что я имел в виду. Хотелось почитать что-нибудь написанное экспертами для не экспертов, ну да ладно.

                                                                                                              Сразу хочу сказать, что для досконального изучения документа у меня не хватает ни времени, ни мотивации, ни компетентности. Тем не менее после прочтения некоторые, возможно ошибочные, выводы я сделал.

                                                                                                              Во-первых, в документе нигде не говорится про парольную аутентификацию, везде описывается применение сертификатов. Не, PKI — это конечно замечательно, но для SOHO, на мой взгляд, это overkill, а у крупных предприятий для этого есть домен и Kerberos.

                                                                                                              Во-вторых, даже если возможность парольной аутентификации есть, то преимуществ перед NTMLv2 я, в данном случае, не вижу, поскольку в качестве KDC предлагается использовать потенциально передоверенного участника взаимодействия, играющего роль сервера. Т.е., в контексте данной статьи, PKU2U не помог бы никак. Все равно на сервер злоумышленника ValdikSS передалась бы некоторая производная от пароля. А имея эту производную и зная алгоритм её получения, можно подобрать пароль атакой по словарю или брутфорсом (ну или обломиться, если пароль достаточно сложный).
                                                                                                              • 0
                                                                                                                Все равно на сервер злоумышленника ValdikSS передалась бы некоторая производная от пароля. А имея эту производную и зная алгоритм её получения, можно подобрать пароль атакой по словарю или брутфорсом


                                                                                                                Вы только что повергли в прах всю современную криптографию. :)
                                                                                                                • 0
                                                                                                                  А в чем я не прав? По вашему алгоритм аутентификации без проверки подлинности сервера может быть устойчив против атаки по словарю? Каким образом? Я не иронизирую, к слову, правда интересно.

                                                                                                                  В том же Kerberos клиент передает, на начальном этапе, на сервер текущее время зашифрованное симметричным алгоритмом, используя в качестве ключа хеш от пароля. Бери и подбирай.
                                                                                                                  • 0
                                                                                                                    Вы раздел Introduction в документе, который я вам дал, прочитали? Третий абзац?

                                                                                                                    Для начала вам надо компьютер ручками добавить в «домашнюю группу» (или автоматически — в случае использования PKI), после чего используется механизм PKINIT для преаутентификации.
                                                                                                                    • +1
                                                                                                                      Прочитал, но видимо невнимательно. И в этом абзаце есть такая фраза: «PKU2U can be used without a PKI by pre-sharing certificates and/or pre-associating name/certificate bindings». Т.е. получается документ парольную аутентификацию не определяет в принципе. А именно она меня интересует, коли уж мы рассматриваем в этой ветке PKU2U, как замену NTLM. Ну да, в 7-ом разделе говорится о том, что «implementers may provide methods for user interaction related to credential selection and acquisition (e.g., name and password/PIN prompts)», но как-то это не очень помогает.

                                                                                                                      При использовании сертификатов у меня вопросов к протоколу нет — всё логично. Но я не могу понять, как он работает без сертификатов и работает ли вообще. Что происходит при добавлении в домашнюю группу по паролю? Создается новый сертификат? Кто выступает в роли центра сертификации? Почему ему доверяют другие участники группы?

                                                                                                                      Если вы в теме, напишите, пожалуйста, развернутый комментарий или даже статью. Думаю, многим полезно будет — информации по протоколу и технической информации по домашней группе кот наплакал.
                                                                                                                      • 0
                                                                                                                        Без сертификатов оно не работает. Каждая станция генерит свой сертификат, при создании группы её члены должны обменяться сертификатами, после чего уже спокойно аутентифицируют друг друга. Случайный компьютер в группу сам не добавится — пароль нужен. Такая вот одноранговая PKI, где все сертификаты — корневые, и все члены друг другу доверяют.

                                                                                                                        На статью у меня материала нет, но исследовать, как оно на самом деле в текущей реализации функционирует — мысль интересная. :)
                                                                                                                        • 0
                                                                                                                          Спасибо. В целом да, протокол довольно интересный. Особенно, перспективным мне кажется его применение совместно с онлайн-аккаунтами Microsoft. Т.е. сертификаты генерируются и хранятся на серверах Microsoft, и могут быть запрошены для проверки подлинности пользователя.

                                                                                                                          В принципе, в Windows 10 есть возможность дать доступ пользователю к компьютеру по имени его (пользователя) учетной записи Microsoft. Думаю, при этом используется механизм схожий с описанным выше. Но будет ли при этом доступ по SMB, я пока не проверял.

                                                                                                                          Но вообще на замену NTLM PKU2U не тянет, хотя бы потому, что все сценарии использования NTLM он не покрывает.
                                                                                                          • 0
                                                                                                            и куда девать эту домашнюю группу дома, связывая 2 виндовых лаптопа, одну самбу на линуксе и один nas на непонятно чем (скорее всего какой-то линукс)?
                                                                                                            • 0

                                                                                                              Согласен, свободных реализаций к сожалению пока нет. Но для таких вот случаев я бы сделал галочку в венде как с клиентом Telnet.
                                                                                                              Если вы Ъ-админ, вы конечно можете поднять свой контроллер домена на nas, но этот вариант к сожалению не всем подходит...

                                                                                                              • 0
                                                                                                                ну тут вопрос не в том, что я как Ъ-админ могу сделать. У меня и порты закрыть проблемы нет. Тут скорее просто ответ на «не думал что NTLM сейчас где-то может использоваться». Простых NAS-ов сейчас как собак нерезаных (и очень мало кто из них не только свой домен могут держать, они не все в существующий умеют входить). И люди ими активно пользуются. И хотят, чтоб оно работало «искаропки». Поэтому любые лишние галочки — это будет уже большое no-no.

                                                                                                                Как по мне, единственное рабочее решение — это таки провайдерам перекрывать порты. Причем вплоть до на уровне закона. Кому таки очень надо через Интернет ползать на SMB-ресурсы пускай городит VPN. И это по-любому правильнее.
                                                                                                                • +1

                                                                                                                  Как по мне это решение совсем неправильное. Провайдера совсем не должно беспокоить какие порты у меня открыты и для чего. Максимум, как опция у провайдера (у билайна такая есть).
                                                                                                                  Правильное решение это если Microsoft выпустят патч который разрешает использование NTLM по умолчанию только для локальных подключений.

                                                                                                                  • 0
                                                                                                                    тоже вариант. геморно для контор у которых сервера не в «локальной» сети. особенно если в конторе разрешается и активно используется политика работы «гостевых» компов. У меня так, например. Каждому юзеру, пришедшему со своим лаптопом объяснять почему он не может зайти на корпоративный сервер — это много лишней головной боли. Но тут можно сказать, что нечего плакаться, работа такая.
                                                                                                                    • 0

                                                                                                                      Почему не смогут? — смогут, просто им свой логин и пароль нужно будет ввести вручную при первом подключении, там и галочка есть "сохранить пароль" и "подключаться автоматически"
                                                                                                                      Вот уж не поверю что вы на своем сервере создаете такие же учетки как у пользователя на лаптопе, только ради того что бы автоматический вход работал...

                                                                                                                      • 0
                                                                                                                        или я чего-то не понимаю, или запрет NTLM-аутентификации полностью запретит логон. Это не запрет «автоматической посылки имени и пароля залогинившегося юзера», это запрет аутентификации вообще.
                                                                                                                        Вот патч, который таки запретит посылку имени и пароля автоматом — это да, решило-бы проблему.

                                                                                                                        P.S. я не создаю на сервере учетки, совпадающие с юзеровскими учетками на их домашних лаптопах. А вот они таки да, создают локальные аккаунты, совпадающие с их рабочим аккаутом, дабы иметь прозрачный доступ к ресурсам. Но это действительно, уже совсем другая проблема.
                                                                                                                  • 0
                                                                                                                    Отличным решением было бы официально выпустить Windows 10 Paranoid Edition…