Дано: Ошибка «Не удалось восстановить доверительные отношения между рабочей станцией и доменом» или «База данных диспетчера учетных записей на сервере не содержит записи для регистрации компьютера через доверительные отношения с этой рабочей станцией». Необходимо восстановить доверительные отношения между рабочей станцией и контроллером домена без повторного ввода ПК в домен.
Решение 1: Мы уже рассматривали 2 варианта решения данной проблемы при помощи утилиты netdom и патча Fix306348 в этой статье: https://saradmin.ru/?p=1130.
Решение 2: «В лоб»
«Сбросить» пароль локального администратора
«Выгнать» ПК из домена и включить его в рабочую группу
С помощью оснастки Active Directory Users and Computers «сбросить» учётную запись компьютера в домене
Повторно «вогнать» ПК в домен
Как видите, это долго, нудно и требуется несколько ребутов.
Решение 3: С использованием утилиты NotDom
В PowerShell Netdom resetpwd /Server:DС-01 /UserD:Admin /PasswordD:*
где DC-01— имя контроллера домена, Admin — реквизиты учетной записи пользователя с правами администратора домена. Пароль в данном случае вводится после ввода команды непечатаемыми символами. Если хотите ввести пароль сразу в командную строку (вот только зачем?), впишите его вместо *.
Решение 4: С использованием PowerShell
Заходим на проблемный комп под учеткой локального администратора («выгонять» комп из домена не нужно), открываем консоль PowerShell и пишем там: Reset-ComputerMachinePassword -Server DC-01 -Credential Domain\Admin
где DC-01— имя контроллера домена, Domain\Admin — реквизиты учетной записи пользователя с правами администратора домена.
В открывшемся окне указываем пароль этой учетной записи.
И не забывайте, что PowerShell нужно запускать с правами администратора.
Ребёнок понял, что можно не просить нас ввести пароль от учётки на компе с Ubuntu, а просто войти в гостевой режим. Да, в нём не сохраняются файлы в профиле, но доступ в Интернет открыт и можно без спроса играться в онлайн-игрушки. В связи с этим у нас возник вопрос: как отключить гостевой сеанс в Ubuntu?
Для Ubuntu 14 в конец файла конфигуации /etc/lightdm/lightdm.conf нужно было добавить строчку allow-guest=false и убрать таким образом гостевой заход. Но в Ubuntu 16.04 этого файла уже нет, поэтому в директории /etc/lightdm/lightdm.conf.d нам нужно создать отдельный конфигурационный файл, в который и добавить этот самый параметр в раздел [SeatDefaults]. Что мы и делаем в консоли:
sudo mkdir /etc/lightdm/lightdm.conf.d
sudo sh -c 'printf "[SeatDefaults]\nallow-guest=false\n" > /etc/lightdm/lightdm.conf.d/50-no-guest.conf'
Перезагружаем комп и радуемся отсутствию гостевого захода.
Если вдруг, по какой-то причине, нужно будет включить гостевой сеанс в Ubuntu, просто удаляем созданный конфиг: sudo rm /etc/lightdm/lightdm.conf.d/50-no-guest.conf
M$ в последнее время хочет всё больше денег, с учётом роста курса доллара проблема усугубляется ещё больше, а файловый режим работы базы 1С в 2015 году уже не так хорош как раньше. Поэтому появилась задача перевода файловой базы на PostgreSQl. В настройке есть пара нюансов, про них и расскажу.
Будем считать, что свежая версия Ubuntu Server (на сегодняшний день последняя стабильная LTS-версия 14.04.3 LTS) уже скачана и проставлена, поэтому перейдем к установке и настройке PostgreSQL.
Настроим параметры ядра, отвечающие за выделяемую системе память.
Параметр SHMMAX — это максимум памяти, выделяемой в одном запросе в байтах. Я для PQSQL выделил виртуалку с 10ГБ оперативки, поэтому установлю размер в 8ГБ: kernel.shmmax = 8589934592.
Параметр kernel.shmall – Общее количество доступной разделяемой памяти в страницах. Рассчитывается как shmmax/PAGE_SIZE. Как правило, размер страницы в системе — 4096 байт, уточнить можно запросом в консоли getconf PAGE_SIZE.
Поэтому kernel.shmall = 8589934592/4096 или kernel.shmall = 2097152
Итак, дано:
Старый DHCP-сервер SERVER1 со списком зарезервированных IP-адресов, который требуется вывести из эксплуатации.
Новый сервер SERVER2, на котором нужно поднять DHCP-сервер со всеми резервированиями.
Про построчный импорт данных о резервировании мы уже говорили, теперь поговорим про то, как перенести все записи.
На сервере SERVER1 запускаем консоль и пишем там netsh dhcp server SERVER1.DOMAIN.LOCAL dump > c:\dhcpdump.txt
Затем открываем файл c:\dhcpdump.txt в блокноте и заменяем (Ctrl+H) SERVER1 на SERVER2 в блоке
Если на DHCP-сервере SERVER2 уже настроены все параметры сервера, оставляем в файле только этот блок и сохраняем его. Если нет, можно оставить и другие опции (параметры сервера, параметры области и сама область, привязка к сетевым адаптерам, фильтры и т.д.).
Файл хорошо структурирован и понятен, так что сложностей точно не возникнет.
Затем на сервере SERVER2 пишем в консоли
netsh exec dhcpdump.txt
и радуемся, что не пришлось заводить это всё вручную.
Да, и раз уж мы занялись конфигами DHCP, вот команда для бэкапа и восстановления всей базы:
Бэкап netsh dhcp server SERVER1.DOMAIN.LOCAL export c:\dhcpdb all
Восстановление netsh dhcp server SERVER1.DOMAIN.LOCAL import c:\dhcpdb all
В связи с тем, что dyndns.org испортился и начал хотеть денег за свои услуги, пришлось таки озаботиться этим вопросом, изучить матчасть..
В общем-то, динамические апдейты в DNS реализованы уже много лет назад, но как обычно, есть некоторые тонкости. Под катом краткое руководство для тех, кому интересно.
Подразумевается, что у вас уже есть собственный домен, собственный первичный DNS-сервер для этого домена (BIND), и клиент под юниксом/линуксом. Вероятно, на роутере, работающем под openwrt/dd-wrt, такой метод тоже сработает с небольшими поправками, но я лично не пробовал.
Итак..
1. На клиенте генерируем секретный ключ (на самом деле, генерировать его можно где угодно, но поскольку он нужен на клиенте, то удобнее прямо там): dnssec-keygen -a hmac-sha256 -b 128 -n HOST -r /dev/urandom dyndns