• Бесплатный ВЕБИНАР по OSINT с Екатериной Тьюринг: ➡️9 февраля в 19:00 (мск) пройдет урок

    Как безопасно искать информацию в открытых источниках

    🔥 Записаться 🔥

Если Id файл дискредитирован

  • Автор темы Автор темы seoman2
  • Дата начала Дата начала
Еще вопрос.
Если стоит проверка паролей, и в украденом ид сменили пароль, то нельзя войти под оригинальным ид.
Как админу сменить пароль на валидном ид со старым паролем?
 
Так пароль то невалидный, старый!
Как сервер поймет, какой ид украден?
 
Подскажите!
Итог:
В случае утери ид, остается только делать новый ид? И менять в ФИО 1 символ?
 
В итоге остается создавать на сервере новый ид, И в новом имени убрать отчество к примеру...
И на серваке включить "Compare Public Keys Against Those Stored in Address Book".
 
Как поменять ключи на id с архива?
Архив я так понимаю - это папака на винте со всеми id?
 
Как поменять ключи на id с архива?
Архив я так понимаю - это папака на винте со всеми id?

Зачем Вы придумываете себе геморой.

Основной принцип должен быть такой:
1. Пользовательский ID должен быть в единственном экземпляре (кр. п.2).
2. Для разрешения всех вышеуказанных проблем настраивается ID Recovery или ID Vault, и там хранятся актуальные копии ID пользователей.
 
HotDog
не все так просто...
п.2 - особенно рековери - глючит достаточно часто...Vault появился не так давно и тоже не безгрешен...
п.1 - как минимум, могут быть несколько копий id у самого пользователя - ноут, стационарное место, удаленное место и т.д.

обычная практика, когда все операции по регистрации/сертификации отделены от ИТ - базовые копии id хранятся в защищенном месте...
но с включенной и используемой сменой ключей это как бы теряет смысл и да - остается уповать только на п.2 :)
seoman2
Как поменять ключи на id
выше же давали ссылки, в т.ч. и на хелп - там пошагово описан процесс изменения пользовательских ключей, в идеале это делает сам пользователь - создает запрос на смену ключей, админ его подтверждает, пользователь принимает новые ключи...
 
HotDog
не все так просто...

Не спорю с Вами по поводу глючности.

Не буду скрывать, у меня тоже Все ID лежат в одном месте, но я не помню, чтобы мне приходилось брать ID для восстановления учетки оттуда.
Я все время пользовался ID Recovery, сейчас ID Vault, либо забирал ID у пользователя.

По поводу ID на разных клиентских машинах. У нас только руководство так может работать (но они на особом щету). У остальных ID лежат на сетевом диске, который цепляется политикой. Запрещено держать ID в каком-либо другом месте (это еще вопрос безопасности). При этом еще включена проверка Открытых ключей на сервере.
Для доступа к почте с другого места альтернативой всегда был доступ через webmail
 
проверка ключей - это основа безопасности в моем понимании... особенно, когда настраивают юзеру доступ спец суппорта, которые знают первоначальный пароль... а вот смена ключей - достаточно громоздкий процесс...

Политики внутрение по СБ у всех свои :) Но с наворотами вроде крипто-кея вопросы восстановления id или смены ключей вылазят ещё те...
Насчет в одном месте id держать - для вэб-доступа id должен ещё и в ящике быть, а если ВВ или там mNotes используем - ещё где-нибудь отдельно...
 
У вас пользователи подписывают и шифруют почту?
конечно! иначе лотусиная почта теряет 99% смысла :)
документооборот через web
к несчастью, тут шифрование и подпись не реализованы - и в планах IBM нет этого :(
 
Понятно.

У нас СБ запретило шифровать почту... пришлось эту галку закрыть политикой.
Пользовательская почта не считается его личной а принадлежит компании.
 
HotDog
юморное у вас СБ :) всё с точностью до наоборот надо...
в том и смысл секьюрной корпоративной почты - никто, кроме уполномоченных лиц СБ (особенно 3-и лица) не сможет её прочитать просто так... шифруем и почту, и базу, и файловую систему....
понятно, уполномоченные сотрудники СБ, используя опять же id конкретного юзера, могут проводить свои мероприятия в случае необходимости...
 
HotDog
юморное у вас СБ :) всё с точностью до наоборот надо...
в том и смысл секьюрной корпоративной почты - никто, кроме уполномоченных лиц СБ (особенно 3-и лица) не сможет её прочитать просто так... шифруем и почту, и базу, и файловую систему....
понятно, уполномоченные сотрудники СБ, используя опять же id конкретного юзера, могут проводить свои мероприятия в случае необходимости...

:(
Ничего с этим поделать не могу
 
Как поменять ключи на id, если вариант запроса пользователя на смену ключей не работает?
 
seoman2
почему не работает???

мегаадмину поменять просто: переключаешься на id юзера, отправляешь запрос, переключаешься на админа - меняешь ключи, переключаешься на юзера - принимаешь ключи, отдаешь юзеру нормальный id
 
Вот когда юзер послылает запрос (File-Security-User Security. Далее в открывшемся окне Your Identity-Your certificates-Other Actions-Create new public keys.) на смену ключей в Administration Requests ничего не появляется :(
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!