none
Подключение было запрещено, так как учетная запись пользователя не имеет прав.... RRS feed

  • Вопрос

  • Коллеги, приветствую!

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

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

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

    Заранее благодарю Вас за помощь!


    • Изменено moskos 25 ноября 2014 г. 13:01 Орфографические ошибки
    25 ноября 2014 г. 13:00

Ответы

  • В разрешения на подключение вас прописали индивидуально. А в политику - кажется, нет...

    Есть одно подозрение: у вас в билете Kerberos застряло устаревшее членство в группах.

    Для проверки можно попробовать подключится к удаленному рабочему столу не по имени сервера, а по его IP ( в этом случае заведомо будет использоваться NTLM и терминальный сервер запросит аутентификацию на КД - а там членство в группах должно быть "свежим").

    PS И всё-таки: предлагаю удостовериться, что на проблемных серверах таки включен аудит неудачных попыток входа: попробуйте, например, подключиться к нему как к файловому серверу с явным указанием своего имени пользователя и заведомо неправильного пароля:

    net use \\имя_сервера /user:домен\логин неправильный_пароль

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


    Слава России!

    • Предложено в качестве ответа Vector BCOModerator 26 ноября 2014 г. 15:15
    • Отменено предложение в качестве ответа moskos 27 ноября 2014 г. 7:28
    • Помечено в качестве ответа moskos 27 ноября 2014 г. 7:28
    • Снята пометка об ответе moskos 28 ноября 2014 г. 9:32
    • Помечено в качестве ответа moskos 28 ноября 2014 г. 10:50
    26 ноября 2014 г. 14:36

Все ответы

  • Это может быть настроено в нескольких местах

    1 - группа Remote Desktop Users - Если пользователя там нет то и доступ вы не получите

    2 - Локальная политика безопасности

        а) Comp.Conf.\Windows Set.\Security Set.\User Rights Ass.\Deny log on through Remote Desktop Services

        б) Comp.Conf.\Windows Set.\Security Set.\User Rights Ass.\Allow log on through Remote Desktop Services

    3 - Групповая политика аналогичная локальной (см. п. 2)

    • Предложено в качестве ответа Josef_123 21 мая 2018 г. 6:44
    25 ноября 2014 г. 13:20
    Модератор
  • А ещё - и в разрешениях для подключения (консоль RD Session Host configuration, вкладка Security  свойств подключения), там должно быть разрешение для подключения, по умолчанию оно есть, кроме администраторов, у группы "Пользователи удалённого рабочего стола".

    PS Поправлено.


    Слава России!


    • Изменено M.V.V. _ 25 ноября 2014 г. 15:40
    25 ноября 2014 г. 13:34
  • Так в том-то и дело, что везде всё прописано и не работает...

    25 ноября 2014 г. 13:34
  • Я ж говорю о том, что не получается зайти всего на пару серверов и 15 и, что я проверил все эти варианты до того, как задать здесь вопрос...
    25 ноября 2014 г. 13:35
  • И с этим тоже всё в порядке))

    25 ноября 2014 г. 13:39
  • Я ж говорю о том, что не получается зайти всего на пару серверов и 15 и, что я проверил все эти варианты до того, как задать здесь вопрос...

    Если есть домен, то доменные политики проверяйте с помощью команды gpresult /h файл.html и просмотра этого файла - тогда увидите все политики и результат их применения (они могут перекрывать локальную).

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


    Слава России!

    25 ноября 2014 г. 13:41

  • Если есть домен, то доменные политики проверяйте с помощью команды gpresult /h файл.html и просмотра этого файла - тогда увидите все политики и результат их применения (они могут перекрывать локальную).

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


    Слава России!

    Аудит включен. Отказов нет никаких. В безопасности появляется три события :

    1. Новому сеансу входа назначены спец. привилегии

    2. Вход с учётной записью выполнен успешно

    3. Выполнен выход учетной записи из системы.


    25 ноября 2014 г. 14:06
  • Какой при этом тип входа в систему? Удаленный рабочий стол - 10.

    Слава России!

    25 ноября 2014 г. 15:41
  • Какой при этом тип входа в систему? Удаленный рабочий стол - 10.


    Хм... Тип входа указан 3, т.е. сетевой. И о чём это может говорить?
    26 ноября 2014 г. 7:24
  • Что при этом у вас тут?

    26 ноября 2014 г. 8:43
    Модератор
  • Покажите, всё-таки до кучи, содержимое вкладки Безопасность подключения  (см. мой самый первый пост в этой теме).

    Слава России!

    26 ноября 2014 г. 9:28
  • Покажите, всё-таки до кучи, содержимое вкладки Безопасность подключения  (см. мой самый первый пост в этой теме).

    Слава России!

    Оно?

    26 ноября 2014 г. 12:15
  • Оно.

    Не вижу там "Пользователей удаленного рабочего стола". Зато есть "Удаленный достпум msk.... - как понимаю, это не стандартная группа? И еще - там человечек с замазанным именем: на него случаем не запрет стоит? И не у него ли войти не получается?


    Слава России!

    26 ноября 2014 г. 13:22
  • Оно.

    Не вижу там "Пользователей удаленного рабочего стола". Зато есть "Удаленный достпум msk.... - как понимаю, это не стандартная группа? И еще - там человечек с замазанным именем: на него случаем не запрет стоит? И не у него ли войти не получается?


    Слава России!

    Да, всё правильно. Группы "Пользователи удаленного рабочего стола" там нет, вместо неё используется нестандартная группа с префиксом msk, пользователь замазанный - это именно я. От безысходности прописали сюда меня явно и стоят все галки на разрешение. Но всё равно это не помогает...
    • Предложено в качестве ответа allgrit 7 мая 2015 г. 16:38
    26 ноября 2014 г. 14:22
  • В разрешения на подключение вас прописали индивидуально. А в политику - кажется, нет...

    Есть одно подозрение: у вас в билете Kerberos застряло устаревшее членство в группах.

    Для проверки можно попробовать подключится к удаленному рабочему столу не по имени сервера, а по его IP ( в этом случае заведомо будет использоваться NTLM и терминальный сервер запросит аутентификацию на КД - а там членство в группах должно быть "свежим").

    PS И всё-таки: предлагаю удостовериться, что на проблемных серверах таки включен аудит неудачных попыток входа: попробуйте, например, подключиться к нему как к файловому серверу с явным указанием своего имени пользователя и заведомо неправильного пароля:

    net use \\имя_сервера /user:домен\логин неправильный_пароль

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


    Слава России!

    • Предложено в качестве ответа Vector BCOModerator 26 ноября 2014 г. 15:15
    • Отменено предложение в качестве ответа moskos 27 ноября 2014 г. 7:28
    • Помечено в качестве ответа moskos 27 ноября 2014 г. 7:28
    • Снята пометка об ответе moskos 28 ноября 2014 г. 9:32
    • Помечено в качестве ответа moskos 28 ноября 2014 г. 10:50
    26 ноября 2014 г. 14:36
  • В разрешения на подключение вас прописали индивидуально. А в политику - кажется, нет...

    Есть одно подозрение: у вас в билете Kerberos застряло устаревшее членство в группах.

    Для проверки можно попробовать подключится к удаленному рабочему столу не по имени сервера, а по его IP ( в этом случае заведомо будет использоваться NTLM и терминальный сервер запросит аутентификацию на КД - а там членство в группах должно быть "свежим").

    PS И всё-таки: предлагаю удостовериться, что на проблемных серверах таки включен аудит неудачных попыток входа: попробуйте, например, подключиться к нему как к файловому серверу с явным указанием своего имени пользователя и заведомо неправильного пароля:

    net use \\имя_сервера /user:домен\логин неправильный_пароль

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


    Слава России!

    Хм... По IP-адресу пустило. В чём может быть проблема?
    26 ноября 2014 г. 15:09
  • Цитата: "у вас в билете Kerberos застряло устаревшее членство в группах".

    Да, я Жук, три пары лапок и фасеточные глаза :))

    26 ноября 2014 г. 15:58
    Модератор
  • Цитата: "у вас в билете Kerberos застряло устаревшее членство в группах".

    Да, я Жук, три пары лапок и фасеточные глаза :))

    Ага. Лечение - командой klist purge . Ну, или подождать - дней за десять билеты в кэше всяко устареют.

    PS Если очистка кэша не поможет, проблема может оказаться глубже: в репликации AD, например.

    В таком раскладе потребуются сведения о топологии AD в вашей организации и проверка репликации между партнёрами (командой repadmin,  например).


    Слава России!

    26 ноября 2014 г. 16:54
  • Цитата: "у вас в билете Kerberos застряло устаревшее членство в группах".


    Да, я Жук, три пары лапок и фасеточные глаза :))

    Ага. Лечение - командой klist purge . Ну, или подождать - дней за десять билеты в кэше всяко устареют.

    PS Если очистка кэша не поможет, проблема может оказаться глубже: в репликации AD, например.

    В таком раскладе потребуются сведения о топологии AD в вашей организации и проверка репликации между партнёрами (командой repadmin,  например).


    Слава России!

    Спасибо всем большое!

    После выполнения команды klist purge всё стало работать нормально.

    27 ноября 2014 г. 7:30
  • Друзья, выручайте!

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

    M.V.V., какую именно информацию необходимо предоставить по топологии сети и выполнению команды repadmin?

    28 ноября 2014 г. 9:35
  • Количество КД и их распределение по сайтам и repadmin /showrepl с каждого.

    А для начала проверьте, что не пускает и при подключении по IP тоже.


    Слава России!

    28 ноября 2014 г. 9:45
  • Друзья, выручайте!

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

    M.V.V., какую именно информацию необходимо предоставить по топологии сети и выполнению команды repadmin?

    Причем на этот сервер не пускает даже по ip.
    28 ноября 2014 г. 9:58
  • Резрешения проверены? Аудит неудачных попыток входа в систему включен? Если нет - включите, если да - что в журнале событий Безопасность?

    Скорее всего, в данном случае дело не в AD, а в самом сервере.


    Слава России!

    28 ноября 2014 г. 10:01
  • Всё заработало, какие-то чудеса...

    28 ноября 2014 г. 10:50
  • Чудес в информационной системе быть не должно.

    Раз пошли чудеса - самое время проверить репликацию всех КД.

    Но для начала загляните в журнал событий системы сервера, где эти чудеса происходили: не было ли там ошибок связи с контроллерами домена.


    Слава России!


    • Изменено M.V.V. _ 28 ноября 2014 г. 11:11
    28 ноября 2014 г. 11:11
  • Чудес в информационной системе быть не должно.

    Раз пошли чудеса - самое время проверить репликацию всех КД.

    Но для начала загляните в журнал событий системы сервера, где эти чудеса происходили: не было ли там ошибок связи с контроллерами домена.


    Слава России!


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

    В журнале системы сервера ошибок связи с КД не обнаружил, тишь да гладь там

    28 ноября 2014 г. 13:43