none
Windows server and "MS Remote desktop 10" in MacOS RRS feed

  • Вопрос

  • Добрыйдень.

    У меня есть вопрос по rdp.

    Если подключаться к Windows Server  по rdp на машине под MacOS программой “MS Remote Desktop  10“ то   не работает  условие , которое можно настроить в настройках пользователя   -  “Учётная запись>Рабочие станции для входа в систему”.

    На машине под MacOS с программой “MS Remote Desktop  10“ подключится можно всегда,  не взирая на все эти условия,  это настройка не действительна.  Но если подключатся  с PC под системой Windows – эта функция работает.

    С такой работой уровень безопасности сходит на нет!

    В логах Windows сервера любую  машину   MacOS  с  “MS Remote Desktop  10“  сервер определяет как “anydevice.anywhere“ и разрешает вход.

    Если это ошибка то исправьте её или подскажите, что надо сделать, чтобы это условие работало полноценно на сервере .

    Раньше этой проблемы не было!

    Спасибо.

    21 февраля 2019 г. 9:48

Все ответы


  • Если это ошибка то исправьте её или подскажите, что надо сделать, чтобы это условие работало полноценно на сервере .

    Раньше этой проблемы не было

    если проблемы раньше небыло, то смотрите что поменялось

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


    The opinion expressed by me is not an official position of Microsoft

    21 февраля 2019 г. 12:27
    Модератор
  • Microsoft меня отправил на это форум, вот я задал здесь свой вопрос.

    В системе ничего не менялось, только апдейты от microsoft. Менялась версия ms rdp для mac.

    Пробовали на разных серверных  системах 2012 и 2016, совершенно в разных доменах - результат одинаковый. Может эта проблема самого начала была, просто теперь новая версия rdp для mac использует этот косяк....     

    21 февраля 2019 г. 12:43
  • согласен, вроде бы косяк. но rdp протокол "с раньше небыло" неск. раз обновлялся. посмотрите, нет ли новой версии вашей проги? если да - очевидно - обновить.

    >> С такой работой уровень безопасности сходит на нет!

    но, на Ms Srv вы же сможете явно задать юзеров, кто на RDP претендует (где-то Управление\Юзеры\Группы\Пользователи RDP).

    Не давайте такому бяке доступ :)

    ++ Вот еще, рекомендую почитать, надеюсь тревоги утешит ваши

    https://www.atraining.ru/windows-rdp-tuning/

    или еще погуглить на счет последних изменений в rdp

    ++ Не забывайте про локальные политики (после изм.рибут) - gpedit.msc

    первая ссылка https://vikt0r.blogspot.com/2011/07/rdp-gpo.html , еще ищите

    там куча параметров, впадлу скрины делать, но думаю вам будет достаточно

    ++ для тестов убедитесь что фаэры на обоих выкл, и на шлюзе + если в домене на DC тоже

    (! основное)

    ++ рабочие станции для входа в систему - сначала откл.

    проверяйте. работает? все проверки только после синхронизации AD и на лок. серверах gpupdate /force с рибут.

    тогда добавляете туда dns: локальные имена серверов, полные, и их ИП. а также (если домен - важно) аналогично для DC - тоже самое для контроллеров (в dns надеюсь есть имена серверов). ибо товарищ. при входе на них для авторизации не попадет :) если не поможет - в hosts для всех серверов (в т.ч. DC) все возможные короткие и длинные имена dns всех уч.rdp после рибут.

    ++ пример записей в оснастке "Р.станции для вх.в систему"

    // контроллеры домена

    dc00.my.local
    dc01.my.local
    dc00.my
    dc01.my
    dc00
    dc01
    // шлюз
    10.10.1.1 // если шлюз с авторизацией, то и его
    // ip dc
    10.10.1.2 // dc00
    10.10.1.3 // dc01
    // сервера, куда ломится чел с rdp
    rdp00.my.local
    rdp01.my.local
    rdp00.my
    rdp01.my
    rdp00
    rdp01
    // ip rdp
    10.10.1.20 // rdp00
    10.10.1.21 // rdp01

    но для начала проверьте без этого (подключения на все ПК). 
    перед всеми тестами - принуд.синхронизация AD (чтобы не ждать >10 мин/обычно) и Gpo локальных, желательно с рибутом.
    если работает - то вариант выше + копайте настройки dns домена в gpo\ad (суффиксы и проч).

    или на Mac пропишите в аналог hosts полные имена серверов. + надеюсь у него днс внутр.? :)

    + при создании rdp сессии лучше юзать стд msts с полным dns локальным именем сервера. При этом в свойствах сетевухи (и сервера и клиента) один из dns должен указывать на основной (обычно доменный - dns сервер) где эта запись резолвится. Ну в cmd ping <полное имя> теор.должно отвечать или telnet <полное имя> 3389 (если клиент стоит - нет, рекомендую поставить). Но можно и ИП обойтись, смотря как сеть настроена.

    + ну, так просто, напоминаю, что через GPO или лок.пол. таким юзерам локальный вход (везде или с исключением на нужные) надо запретить. мысли вслух или чтобы ответ был полным.

    • Изменено GuSoft 27 февраля 2019 г. 21:50
    27 февраля 2019 г. 20:32
  • Добрый день.

    Почему условие работает с машинами на Windows???  Что за кастрированные условия?...   Где логика?

    Такая же ситуация и в настройках Брандмауэра Firewall Windows, если создаю защищённое   правило для порт rdp и указываю у каких машин(имена) есть доступ,  для Windows машин всё ок!, правило работает,  но любая машина macOs ms rdp 10 свободно подключается не взирая на все защищённые правила по имени компьютера!!! Имя Маковоских машин  нигде в домене нет, и никогда не были прописано и всё равно доступ разрешён!!!

    Как я уже говорил,  при подключение по rdp, в логах сервера при первых шагах авторизации любую маковкую машину  сетевое имя  сервер определяет  как anydevice.anywhere и вход разрешает минуя все правила связанные с именем этой машины пользователя.

    Раньше всё было ок, сетевое имя определялось  правильно и правила работали!.....

    Кто знает, может с пользователями тоже такие косяки есть?!...  Тогда вообще  решето…..

    Спасибо.

    28 февраля 2019 г. 11:34
  • В политике нюансы,  конечно, могут быть, но где логика. Если я прописал условие, выполняться должно только это условие, других значений в условии больше нет,  это   логический фильтр.  Если разрешён доступ к серверу только с  машин, с конкретными  именами, только их сервер должен допускать  и точка.  Если на первых шагах авторизации имя подключаемого компа сервер не может определить, он должен блокировать такое подключение,  в данном случае сервер разрешает вход, причём подставляет он или rdp клиент всегда определённое имя, может быть это какой то специфический атрибут  с полным доступом, не знаю….

    28 февраля 2019 г. 23:08
  • Мне кажется что все работает как надо. Указанный выше список содержит рабочие станций на которые может интерактивно заходить доменный пользователь, как локально так и удаленно.

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

    https://blogs.technet.microsoft.com/leesteve/2017/06/26/allowing-rdp-access-to-only-certain-ips/

    Что до "логики", то расскажите как вы это проверяли. Я подозреваю что ограничение действует не на заход на удаленный компьютер по RDP, a на заход на ПК локально. Чтоб проверить попробуйте зайти с ПК не в домене или под локальной (не доменной) учетной записью. 



    This posting is provided "AS IS" with no warranties, and confers no rights.

    1 марта 2019 г. 1:41
  • Вы меня просто не слышите.  Объясняю ещё раз. С любыми клиентскими машинами с Windows, в домене  или нет, пофиг,   правило работает   и сейчас и раньше. Работает так:   Например, мне нужно чтобы к одному доменному серверу,  по данному пользователю могли подключаться определённые рабочие машины, причём машины и доменные и не доменные.  Прописываем(на картинке выше ) нужный сервер,  а также сетевые имена машин которым должен быть разрешён доступ,  всё правило работает!  Раньше всё работало с разными машинами и  с разными ос,  сейчас работает только с ос  Windows. Такая же ситуация с защищёнными правилами в firewall Windows.  Там вообще можно добавлять только доменные компы  и всё равно не прописанный  macOS  ms rdp 10 такую защиту проходит!!!....   

    1 марта 2019 г. 8:10
  • Для ясности добавлю. Подключаться  к серверу по RDP.

    1 марта 2019 г. 8:44
  • Вы меня просто не слышите.  Объясняю ещё раз. С любыми клиентскими машинами с Windows, в домене  или нет, пофиг,   правило работает   и сейчас и раньше. Работает так:   Например, мне нужно чтобы к одному доменному серверу,  по данному пользователю могли подключаться определённые рабочие машины, причём машины и доменные и не доменные.  Прописываем(на картинке выше ) нужный сервер,  а также сетевые имена машин которым должен быть разрешён доступ,  всё правило работает!  Раньше всё работало с разными машинами и  с разными ос,  сейчас работает только с ос  Windows. Такая же ситуация с защищёнными правилами в firewall Windows.  Там вообще можно добавлять только доменные компы  и всё равно не прописанный  macOS  ms rdp 10 такую защиту проходит!!!....   

    Ну давайте думать... Вы утверждайте что все это якобы работает даже с машинами не в домене, так? Если так, то что помешает "злодею" назвать такую машину "PC1" или даже "Server1"? Очевидно, ничто не помешает. Иными словами, данный способ вообще работать не может, не так ли? И никакой "защиты" на деле и быть не может.

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

    Реально ограничение доступа с ПК (любого, не только RDP) куда сложнее чем прописывание его имени. Типично требуется что то вроде клиентских сертификатов выданных центром сертификации, именно они подтверждают подлинность ПК, а не имя ПК которое кто угодно может изменить.

    В любом случае, если вы считайте что это все же должно работать, то можете обратится в платную поддержку заплатив за инцидент. Если это реально должно работать и не работает из за ошибки в ПО Microsoft, то оплату вам вернут.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    1 марта 2019 г. 16:58
  • Любое правило, которое задаёт, какой то, определённый уровень безопасности важно, и должно работать корректно в своём уровне. Да, данное правило  это не панацея безопасности, но факт то, что система сервера ведёт себя очень странно! Такая же ситуация с firewall Windows в режиме защищённые соединения. Если есть такой косяк в данных случаях, где гарантия, что система сертификатной проверкой работает корректно?!

    Надо обращаться наверно в Microsoft, но всё равно всем спасибо.

    1 марта 2019 г. 19:36
  • H.

    1/ А принимающий сервер - терминальный? Если да, то как развернут - как Быстрый доступ (шаблон) или Руками?

    2/ Какие настройки стоят у прин. сервера в свойства ПК\доп\свойства\уд.доступ?

    3/ есть ли изменения в лок.gpedit.msc (для пк и юзеря в адм. шаблонах\ком.вин\службы у.р.с)

    Отдельно на

    >> не прописанный  macOS  ms rdp 10 такую защиту проходит 

    - надеюсь маки не в домене? можно добавить в терм сервер (если?) в политику сетевую - подкл. только с доменых пк

    = вариант более тяжелый и опасный - поднять шифрование в домене + сертификаты

    - выдать\или через gpo всем доменным пк - автовыдачу серт на пк (или руками) - на dc развернуть CA\CA2

    - в gpo домена включить политику фаэров, с включением шифрования, и IPsec, на основе серт. (можно и без них на кодовом слове - но с маками лучше серт - и ваш пк с мак должен серт получить будет) - тогда к домену сможет подкл. "не только лишь все" :) а 1. имеющие серт, 2. явно прописаные в gpo firew в доверенные узлы.

    ++ перед внедрением последнего варианта бэкап всего

    ++ не делайте на рабочей среде, опт. тест серв. ферма - основное (создайте 2-3 сервера и там эксп.)

    ++ иметь ввиду, что если ошибетесь с правилами, сеть на срв накроется сразу, оптимально оставить доп. доступ - VMware\ilo\rdp\ssl - и даже этого может не хватить

    ++ после внесения изменений учитывайте время репликации

    ++ для начала используйте самые простые схемы IPsec (а также удостоверьтесь что в лок.gpo\gpo домена они разрешены)

    ++ немного старых ссылок, новее не искал, если надо далее сами

    http://winpcbox.blogspot.com/2012/07/windows-server-2008r2-1-ipsec.html

    http://faqman.ru/bezopasnost-v-os-windows/ustanovka-servera-ipsec-server-i-izolyacii-domena-s-pomoshhyu-gruppovoj-politiki-windows-server-2008-group-policy-chast-1.html

    ни или поиском. Это ГАРАНТИРОВАННО ваш bad pc отрубит + еще всех остальных, явно не разрешенных. но это потребует и знаний от вас

    (!) использовать осторожно - любая ошибка может положить ваш домен\сеть

    • Изменено GuSoft 1 марта 2019 г. 21:26
    1 марта 2019 г. 20:54
  • GuSoft, спасибо за советы, приму к сведению, буду думать.
    Хотел бы у вас спросить, откуда берётся имя “anydevice.anywhere“?  Почему в логах система, при авторизации определяет любой маковский комп именно так, но после подключения система уже видит имя правильно.  Виндовскую машину, система определяет сразу  правильно, реальное сетевое имя. Раньше, всё было ок, при авторизации определяло правильно -  реальное  сетевое имя мака и все правила работали.   Меня это и смущает больше всего... Почему в системе сами изменились какие то закономерности?  В системе ничего не менялось, только ms update и на маки  была поставлен новая версия ms rdp 10.

    1 марта 2019 г. 23:02
  • GuSoft, спасибо за советы, приму к сведению, буду думать.
    Хотел бы у вас спросить, откуда берётся имя “anydevice.anywhere“?  Почему в логах система, при авторизации определяет любой маковский комп именно так, но после подключения система уже видит имя правильно.  Виндовскую машину, система определяет сразу  правильно, реальное сетевое имя. Раньше, всё было ок, при авторизации определяло правильно -  реальное  сетевое имя мака и все правила работали.   Меня это и смущает больше всего... Почему в системе сами изменились какие то закономерности?  В системе ничего не менялось, только ms update и на маки  была поставлен новая версия ms rdp 10.

    Во первых, вы уверены что что то действительно поменялось? Вы когда то проверяли что Мак с неверным именем действительно отбрасывался или же просто добавили Мак и проверили что с него есть доступ?

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

    Изменения происходят всегда, это процесс. Например, в области работы с NetBIOS были очень серьезные изменения, в частности запрет небезопасной версии SMB v1. Возможно, он использовался для определения имени ПК, а теперь больше не работает и система просто пишет "неизвестное имя" в логах.

    И я так думаю что "раньше" не было "ок". Подход который вы использовали (кстати, почему?) просто создавал ложное ощущение безопасности, но на деле никакой защиты не давал так как проверку можно было элементарно обойти. Что собственно и произошло. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    1 марта 2019 г. 23:52
  • Я хочу понять, почему в данных случаях эти правила не работают как надо, почему они работают на пк с виндой по своей логике, а с другими системами нет.

    Тест такой, есть мак с ms rdp 10 со своим именем пк,  создаю пользователя, прописываю правила в пользователе и в firwall сервера как я описывал выше, но указываю другое имя пк, но этот мак всё равно подключается по рдп. В логах сервер указывает имя никому не принадлежащее в системе, как будто это кой то атрибут со своими прописанными правилами.

    2 марта 2019 г. 9:43