John Smith,
Именно keepass'ом мы пользовались. Как раз три проблемы:
1) общий доступ - с одной базой без ошибок несколько человек работать не могут, надо экспортировать в индивидуальную, локальную, а потом экспортировать обратно;
2) ограничить права можно только на базу целиком, соответственно пользователю с более широкими правами нужно держать несколько баз открытыми, что в сумме с предыдущим пунктом создаёт критическое неудобство;
3) журналирование действий в нём не предусмотрено.
1password и enpass, насколько я могу судить, обладают теми же недостатками, т.к. не предусмотрен многопользовательский доступ.
На старом сервере крутится другая почтовая служба, не Postfix (рекламировать её название не хочу). Останавливать её до последнего этапа я не могу. Миграцию почтового домена я уже осуществлял, но в прошлые разы не сталкивался с такой проблемой, или просто она прошла незаметно для меня и пользователей.
До последнего этапа A- и MX-записи для переносимого домена domain1 ведут на старый сервер. Но Postfix на новом сервере не запрашивает информацию об этом домене с DNS, т.к. уже видит этот домен у себя "на борту", и обрабатывает письма полученные от или отправленные на domain1 как локальные. И обмен письмами с другими почтовыми доменами на сервере, на который происходит миграция domain1, становится невозможным.
Добавлю, в Windows Server 2012 R2 (в 2016 не проверял ещё) клиентские лицензии активируются через "Диспетчер лицензирования удалённых рабочих столов", для добавления которого необходима роль сервера "Служба удалённых рабочих столов / Лицензирование удалённых рабочих столов". Установить этот компонент можно на отдельной машине (например, на контроллере домена) и использовать этот диспетчер для централизованного лицензирования нескольких терминальных серверов.
Пользовательские сессии можно (и нужно) блокировать (безопасность) и отключать (экономия ресурсов) на основании групповой политики:
/ Конфигурация пользователя / Политики / Административные шаблоны / Компоненты Windows / Службы удалённых рабочих столов / ...
PS:
рекомендую через GPO запретить пользователям сохранять пароль учетной записи в RDP-файле (если не запретить, то такие попытки будут);
если настроена политика принудительной смены пароля по истечению заданного периода, то в настройках терминального сервера (можно через GPO) желательно указать авторизацию на стороне сервера, а не на стороне клиента, чтобы пользователь мог просроченный пароль поменять. Иначе это регулярно-повторяющаяся волна обращений забывчивых пользователей, которые игнорируют напоминания.
Артём, обороняться на Windows XP сейчас тяжело будет, так как не каждый антивирус на ней будет нормально работать. Обновлений нет, и админские права ан разные операции чаще требуются. К этой версии мой комментарий не применим.
Александр +:
Ответственен ли администратор за софт, который был установлен до его трудоустройства? Лицензионное соглашение запрещает установка - новый администратор не устанавливал; запрещает использование - так пользуются все сотрудники, как раз администратору MS Office и Photoshop скорее всего не нужны.
По большей части, я считаю, решение останется за прокурором и судьёй, кому они в конечном счёте вменять преступление будут.
Леонид: Если письма переносились между серверами, а не копировались, а потом были перенесены обратно, то для клиента это новые письма, т.к метка времени другая.
Если иначе, то мой небогатый опыт тут не поможет.
Контакты владельца домена можно узнать через Whois, не обязательно он будет совпадать с контактами указанными на сайте.
ИМХО, лучше соблюдать анонимность: один администратор будет рад, что ему сообщили об уязвимости, второй - благодарен, третий - забьёт на сообщение, а четвёртый - попытается привлечь за неправомерный доступ и свалит на благодетеля какие-нибудь известные проблемы и утечки. Так что есть вероятность получить неприятный разговор с каким-нибудь следователем.
Clooney: одному физическому интерфейсу можно назначить несколько IP-адресов. Принимать и перенаправлять соединение через него система будет нормально.
Одна проблема: работает это только для TCP.
Именно keepass'ом мы пользовались. Как раз три проблемы:
1) общий доступ - с одной базой без ошибок несколько человек работать не могут, надо экспортировать в индивидуальную, локальную, а потом экспортировать обратно;
2) ограничить права можно только на базу целиком, соответственно пользователю с более широкими правами нужно держать несколько баз открытыми, что в сумме с предыдущим пунктом создаёт критическое неудобство;
3) журналирование действий в нём не предусмотрено.
1password и enpass, насколько я могу судить, обладают теми же недостатками, т.к. не предусмотрен многопользовательский доступ.