• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

    За 3 месяца вы пройдете путь от начальных навыков работы с SQL-запросами к базам данных до продвинутых техник. Научитесь находить уязвимости связанные с базами данных, и внедрять произвольный SQL-код в уязвимые приложения.

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

    Запись на курс до 25 апреля. Получить промодоступ ...

Как лучше начать использрвание структуры компании

  • Автор темы kilcher
  • Дата начала
K

kilcher

Всем привет!
Хочу спросить вашего совета.
Ранее структура в компании не использовалась(в лотусе). Соответсвенно во всех базах использовались имена из адрессной книги. И все связи,агенты и т.д. построены по этим лотусовским именам.
Хочу безболезненно для системы перейти на имена из структуры(в русском написании). Как бы лучше это организовать?

Может у кого то был такой опыт?
 
A

Akupaka

лучше использовать имена в латинице, а рус имена добавить как альтернативные...

а что имеется в виду под структурой? использование OU в именах?..
в общем, это не простой вопрос, особенно для крупных компаний...
лучше это обсудить с админами - перенести тему в админ-раздел...

ну, а замена имен по двум путям, либо руцями, либо доверить серверу, т.е. включить админ-сервер в ТУД и т.п.
в коде сервер имена не поменяет, только в ТУД, документах и то, в полях типа Names/Auth/Read...
 
L

lionk

Безболезненно не получится :D
немного не понятно как вы работали с сервером и управляли доступом к нему, когда у вас были имена без структуры организации, ну то ладно, и еслть ли у вас общая аднесная книга всех пользователей.

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

есле цель этих переимнований приход к централизации, то дело должно обойтись большой кровью, с отключением всех и полной реорганизацией прав доступа.

самый большой бок переименования пользователей - это потеря документов в которых есть поля Ридров.
(советую перед переименованием очень хорошо подумать как их не потерять)

второй это ACL конкретных баз где пользователи вписаны напрямую (штатных средств попереименовывать вроде нету)

если у вас в базах есть профайлы по именеам пользователя вы их потеряете

быть готовым к глюкам из за захардкоденых имён пользователей

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

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

Akupaka

покомментирую малость :D

Безболезненно не получится
получится, если грамотно подойти :)

немного не понятно как вы работали с сервером и управляли доступом к нему, когда у вас были имена без структуры организации
только шшшш! у нас в конторе около 500 чел и не используются OU... бедные админы...

просто есть функция переименования пользователя
точно-точно! она решит максимальное кол-во задач, только надо предварительно хорошенько изучить ее возможности!
в админе, в People & Groups выбираешь пользователя и тыкаешь в People / Rename. Там три варианта.

по правельному надобыло попереименовывать всех под новую структуру. но это выгодно есле у вас пользователи в одной общей базе и всё очень централезировано
тут не понял что имелось в виду

есле цель этих переимнований приход к централизации, то дело должно обойтись большой кровью, с отключением всех и полной реорганизацией прав доступа.
не ну зачем так пугать человека! наоборот! все пройдет успешно и приведет к улучшению управления!


самый большой бок переименования пользователей - это потеря документов в которых есть поля Ридров.
(советую перед переименованием очень хорошо подумать как их не потерять)
второй это ACL конкретных баз где пользователи вписаны напрямую (штатных средств попереименовывать вроде нету)
если у вас в базах есть профайлы по именеам пользователя вы их потеряете
тут, как я уже говорил, нужно использовать возможности параметра "Administration server" в ТУД!
читай хэлп! в кратце, поможет решить дела с именами в полях Names/Readers/Authors
поэтому, если есть поля, хранящие имена, то возможно есть смысл их преобразовать в Names перед переходом...

чтобы не перестали работать агенты подписаные старой учёткой админа подписать весь дизайн базы от имени сервера
или, как вариант, новой спец. учетной записью, имеющей право на выполнение кода...
хотя в любом случае, я бы рекомендовал не трогать учетку админа вообще, на всякий случай :)

ну и нужно будет переносить личную информацию пользователей(если для них будут созданы новые персон документы) типо адреса почты, паролей интернета, почтовых баз, личных адресных баз.
а не надо будет новых документов персон! при переименовании в старом документе изменится имя, только в серверном names тоже должен быть установлен Admin.server (по-умолчанию он там установлен, но проверить надо)
 
Мы в соцсетях:

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