Так как его подлинность проверена не полностью
Nav view search
Навигация
Искать
Не сохраняются пароли при подключении по RDP
При подключении к терминальному серверу Microsoft Server 2016 на клиентских компьютерах с операционными системами Windows 7/8/10 не получается запомнить пароль. После нажатия галочки “разрешить мне сохранять личные данные” он должен сохраняться, но при повторном соединении появляется следующая надпись:
«Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера, так как его подлинность проверена не полностью. Введите новые учетные данные.»
Чтобы решить проблему запустим редактор локальной групповой политики gpedit.msc на компьютере с которого будем подключатся к терминальному серверу.
Включаем политику и добавляем серверы при подключении к которым требуется сохранять пароль.
TERMSRV/COMPUTER1 — сохранять учетные данные для подключения к COMPUTER1;
TERMSRV/*.example.local — сохранять данные для всех компьютеров в домене example.local;
TERMSRV/* — всегда сохранять учетные данные.
Важное замечание: параметр TERMSRV должен быть написан заглавными буквами!
Закрываем редактор групповой политики и применяем политику: gpupdate /force
Так как его подлинность проверена не полностью
Этот форум закрыт. Спасибо за участие!
Лучший отвечающий
Вопрос
Имеется домен на 2008 р2. Имеются «семерки» члены домена. Имеется проблема следующего характера.
Если подключаться к ЛЮБОЙ машине по имени с сохранением учетных данных локально (Чтобы пароль не вводить) все ок (то есть мклиент в домене хост тоже).
Если-же подключаться по айпи, или же по имени но не к члену домена то выдает фигу со словами: системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера «тест.тест.ком» так как его подлинность проверена не полностью. Введите новые учетные данные. Попытка входа неудачная. Причем если подключаться к этому же хосту, но с машинке не участвующем в домене, все ок. Предполагаю что проблема зарыта все таки в политиках. я обрыл довольно много и не раз. В основном административные шаблоны\ служба удал. раб. столов. Но не помогает. Помогите плиз с проблемой.
Ответы
Если компьютер находится в домене, при подключении к удаленному компьютеру сохранение учетных данных по умолчанию запрещено. Однако это поведение можно изменить.
Для выполнения этих действий необходимо войти в систему с правами администратора.
Системный администратор запретил использовать сохраненные. Разрешаем сохранение учетных данных при подключении по RDP
При подключении к удаленному рабочему столу по RDP есть возможность сохранить учетные данные, чтобы не вводить их каждый раз. Но есть одна тонкость. Так если подключаться с компьютера, находящегося в домене, к компьютеру в рабочей группе, то использовать сохраненные данные не удастся, а будет выдано сообщение примерно такого содержания:
«Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера, так как его подлинность проверена не полностью. Введите новые учетные данные.»
Дело в том, что сохранение учетных данных при подключении к удаленному компьютеру запрещено доменными политиками по умолчанию. Однако такое положение вещей можно изменить.
Включаем политику, затем жмем на кнопку Показать, чтобы добавить в список серверы, к которым собираемся подключаться.
Заполнять список можно несколькими способами. Например:
TERMSRV/удаленный_пк — разрешаем сохранять учетные данные для одного конкретного компьютера;
TERMSRV/*.contoso.com — разрешаем сохранять данные для всех компьютеров в домене contoso.com;
TERMSRV/* — разрешаем сохранять данные для всех компьютеров без исключения.
Внимание: используйте в TERMSRV заглавные буквы, как в примере. Если указан конкретный компьютер, то значение удаленный_пк должно полностью совпадать с именем, введенным в поле «Компьютер» удаленного рабочего стола.
И еще. Используя локальные групповые политики мы разрешаем сохранять учетные данные только на одном конкретном компьютере. Для нескольких компьютеров будет лучше создать в домене отдельное OU и привязать к нему соответствующую доменную политику.
В предыдущих статьях, посвященных локальным политикам безопасности, вы узнали о принципах работы политик учетных записей и политик аудита. Владея приобретенными знаниями, вы можете значительно обезопасить учетные данные ваших пользователей и отслеживать попытки несанкционированного доступа. Стоит учесть, что пользователи не владеют достаточной базой знаний по обеспечению безопасности и даже у обычного пользователя может быть достаточно привилегий для нанесения ущерба своей системе и даже компьютерам в вашей интрасети. Избежать подобных проблем помогают локальные политики безопасности назначения прав пользователя, о чем, собственно, и пойдет речь в данной статье. При помощи политик назначения прав пользователя вы можете сами определить, для каких пользователей или групп пользователей будут предоставлены различные права и привилегии. Оперируя данными политиками, вы можете не волноваться за то, что пользователи будут выполнять действия, которые им делать не положено. Для назначения прав доступны 44 политики безопасности, о применении которых далее пойдет речь.
Политики назначения прав пользователей
Как говорилось выше, для назначения прав пользователей существует 44 политики безопасности. Далее вы сможете ознакомиться с восемнадцатью политиками безопасности, которые отвечают за назначение различных прав для пользователей или групп вашей организации.
Применение политик назначение прав пользователей
В этом примере я расскажу, как можно назначить права для одной из групп вашей организации на контроллере домена. Выполните следующие действия:
Заключение
В данной статье мы продолжили изучение политик безопасности, а именно, узнали о политиках назначения прав пользователей. При помощи политик назначения прав пользователя вы можете сами определить, для каких пользователей или групп пользователей будут предоставлены различные права и привилегии. Подробно описаны 18 из 44 политик безопасности. На приведенном в статье примере вы также узнали о том, как можно применить данные политики в организации. В следующей статье вы узнаете политиках, управляющих журналами событий.
На сегодняшний день в сети существует сотни, а возможно, даже тысячи учетных записей администратора. Имеете ли вы контроль над всеми этим учетными записями, и знаете ли вы, что они могут делать?
Для чего необходимо контролировать учетные записи администраторов?
Если вы являетесь администратором сети Windows, а таких большинство, то ваше пристальное внимание должно быть направлено на корпоративный Active Directory enterprise. Со всеми этими заботами относительно безопасности контроллеров домена, серверов, служб, приложений и подключением к Internet, остается совсем мало времени на то, чтобы убедиться, что ваши учетные записи администраторов контролируются правильно.
Причин, по которым необходимо контролировать эти учетные записи, огромное множество. Во-первых, в больших или средних сетях потенциально может существовать тысячи таких учетных записей, поэтому велика вероятность того, что эти учетные записи могут выйти из под контроля. Во-вторых, большинство компаний разрешают обычным пользователям иметь доступ к учетной записи локального администратора, что может стать причиной беды. В-третьих, с оригинальной учетной записью администратора необходимо обращаться бережно, поэтом ограничение привилегий является превосходной мерой предосторожности.
Сколько у вас учетных записей администратора?
Чтобы ответить на этот вопрос, необходимо сделать некоторые вычисление (как сказал бы Jethro Bodine). Т.к. каждый компьютер с операционной системой Windows имеет учетную запись локального администратора, то мы начнем отсюда. Эти компьютеры включают Windows NT, 2000, XP и Vista. Убедитесь, что вы включили все компьютеры клиентов, которые используются администраторами, разработчиками, сотрудниками и даже находятся в серверной комнате или на прикладных устройствах. Если у вас есть киоски, тестовые компьютеры, централизованные рабочие станции и т.п., то всех также необходимо включить в наш расчет. Не нужно пока считать учетные записи пользователей, т.к. количество устройств, может не соответствовать количеству пользователей.
Теперь вам нужно учесть количество серверов, которые у вас есть. В этот список пока еще не нужно включать контроллеры домена. Из всех ваших серверов вам необходимо выделить сервера, которые выполняют следующие задачи: хранение данных, сервер для печати, сервер приложений, почтовый сервер, офисный сервер и т.п. У каждого из этих серверов имеется локальная SAM, и поэтому есть учетная запись локального администратора. Эта учетная запись может использоваться не очень часто, но это может быть еще более важной причиной, по которой необходимо контролировать ее права.
И наконец, вы должны рассмотреть контроллеры домена. Здесь у вас есть очень важная учетная запись администратора – это учетная запись, которая контролирует Active Directory. Эта учетная запись администратора не только контролирует Active Directory, но также управляет корневым доменом, также как и учетная запись корпоративного администратора. Если у вас более одного домена, то у вас должна быть одна учетная запись администратора для каждого домена. Соответствующая учетная запись администратора имеет силу лишь в том домене, в котором она размещается, но все равно это очень важная учетная запись.
Ограничение прав на вход
Существует не так много возможностей по физическому ограничению привилегий на вход для этих учетных записей администратора. Однако, эти учетные записи не должны использоваться ежедневно. Поэтому необходимо предпринять некоторые меры для ограничения их использования. Очевидный выбор заключается в том, чтобы ограничить количество пользователей, которые знают пароли для этих учетных записей. Для учетных записей администратора, связанных с Active Directory, неплохо было бы разработать процесс для назначения паролей, когда ни один пользователь не знает целый пароль. Это можно легко сделать в том случае, когда два различных администратора вводят часть пароля, а затем документирует эту часть. Если эта учетная запись когда-нибудь понадобиться, то необходимо получить обе части пароля. Другой вариант заключается в том, чтобы использовать программу для автоматического формирования пароля, которая позволяет сформировать сложный пароль.
Ограничение доступа к учетной записи локального администратора
Вне зависимости от того, разрешаете ли вы обычным пользователям иметь доступ к их рабочей станции или нет, вы должны ограничить их доступ к учетной записи локального администратора. Два простых способа для этого заключаются в изменении имени учетной записи локального администратора и частого изменения пароля для нее. Существует объекты политики группы для каждого из этих параметров. Первый параметр находится в Computer Configuration|Windows Settings|Security Settings|Local Policies|Security Options, как показано на рисунке 1. Политика, которую необходимо настроить называется Accounts: Rename Administrator Account.
Рисунок 1: Политика для изменения имения учетной записи локального администратора
Вторая политика, которую вам необходимо настроить, является частью нового комплекта настроек политик (suite of policy settings), который появится в 2007. Эта политика является часть комплекта под названием PolicyMaker suite, и располагается в Computer Configuration|Windows Settings|Control Panel|Local Users and Groups, как показано на рисунке 2.
Рисунок 2: Политика для сброса пароля для учетной записи локального администратора Administrator accounts
Примечание: Эта политика не запрещает обычному пользователю от постоянного контроля на этой учетной записью, т.к. единственный способ сделать это, заключается в удалении обычного пользователя из группы администраторов.
Ограничение доступа к сети
Как все знают (но не все помнят), учетная запись администратора не должна использоваться на повседневной основе. По этой причине, нет необходимости настраивать сеть так, чтобы разрешать доступ в сеть под этой учетной записью. Один хороший способ по ограничению прав для этой учетной записи заключается в том, чтобы запретить учетной записи администратора доступ к серверам и контроллерам домена в сети. Это легко можно сделать с помощью настройки GPO. Эта настройка GPO находится Computer Configuration|Windows Settings|Security Settings|Local Policies|User Rights Assignment, как показано на рисунке 3. Политика, которую вы должны настроить называется Deny Access to this Computer from the Network (запретить доступ к этому компьютеру из сети).
Рисунок 3: Политика для запрета администратору доступа к компьютеру из сети
Другие настройки
Вы также можете ограничить доступ для учетной записи администратора внутри корпорации. Другие примеры, где вы можете ограничить доступ:
Эти настройки лишь ограничат область влияния учетной записи администратора над компьютерами в сети. Эти настройки не запрещают пользователю с правами администратора настраивать этот доступ. В этом случае вы должны настроить аудит для конфигурации учетной записи администратора, а также проверять, когда эта учетная запись использовалась для входа и использовании пользовательских прав. И снова эти настройки можно выполнить с помощью GPO. Вы можете найти эти настройки в Computer Configuration|Windows Settings|Security Settings|Local Policies|Audit Policy, как показано на рисунке 4.
Рисунок 4: Политика для настройки аудита по управлению и использованию учетной записи
Резюме
Учетная запись администратора – это самая важная учетная запись, которая существует в мире операционной системе Windows operating system. Эта учетная запись настолько мощная, что не следует ей пользоваться до тех пор, пока не возникнет реальная необходимость, такая как экстренное восстановление или начальная настройка. Для того чтобы ограничить область влияния этой учетной записи, можно сделать дополнительные настройки для защиты учетной записи и доступа к ней. Политики группы – это механизм, который используется для распределения этих уменьшенных прав между всеми компьютерами, для которых необходимо ограничить права администратора. После этих настроек будет контролироваться не только работа учетной записи администратора, но и также можно будет обнаруживать попытки взлома вашей сети с помощью этой учетной записью.
Сам себе сисадмин
Заметки системного администратора.
среда, 20 ноября 2013 г.
Не сохраняет пароль при подключении к удаленному рабочему столу (RDP)
При подключении к терминальному серверу появляется запрос на внесение учётных данных для подключения. Однако при установке галочки сохранения пароля, парольвсё равно запрашивается и появляется ошибка-предупреждение
Недопустимые учетные данные
Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера CompName, так как его подлинность проверена не полностью. Введите новые учетные данные.
Для решения данной проблемы необходимо перейти в групповые политики локального компьютера.
Конфигурация компьютера > Административные шаблоны > Система > Передача учетных данных и выбрать пункт “Разрешить делегирование сохраненных учетных данных с проверкой подлинности сервера только NTLM”.
Включить указанную политику и добавить список компьютеров при подключении к которым повторно не запрашивать пароль для подключения.
Далее может потребоваться обновление политики безопасности командой gpupdate /force.
Так как его подлинность проверена не полностью
Профиль | Отправить PM | Цитировать
Есть клиенты на windows 7 в домене, им нужно настроить сохранение пароля в RDP при подключении к Windows server 2012 standart, который находится вне домена.
Подключение работает, при входе после нажатия галочки «разрешить мне сохранять личные данные» должен сохраняться пароль для дальнейших подключений. Но в последующих подключениях снова требует пароль и пишет ошибку: «Системный администратор запретил использовать сохраненные учетные данные для входа в систему удаленного компьютера «pcname», так как его подлинность проверена не полностью. Введите учетные данные».
На клиентах, которые не в домене, а водной рабочей группе с сервером такой проблемы нет.
