Перенос нескольких рабочих столов из / etc / passwd в LDAP

Запросы на учебные материалы и учебные пособия не по теме.

Какой последовательности действий следовать, на что обратить внимание, как минимизировать риски потери данных, как минимизировать простои пользователей и т. Д.?

Начните с определения ваших требований и объема. Запишите их и рассмотрите.
Подумайте также о настройке Kerberos в дополнение к LDAP. Возможность единого входа часто будет реальной бизнес-выгодой для ваших конечных пользователей, а также побудит их с большей готовностью мириться с сбоями в процессе миграции. Конечных пользователей обычно не волнуют изменения в целом, и совершенно очевидно, что они не видят немедленной выгоды в том, что воспринимается как эксплуатационные улучшения, приносящие пользу только жизни системных администраторов.
FreeIPA предлагает здесь комплексный подход.

Проведите инвентаризацию существующих файлов passwd и group, а также sudo конфигурации. Не упускайте из виду другие службы, которые в настоящее время защищены именем пользователя / паролем, которые могут выиграть от интеграции с центральным каталогом пользователей (и SSO), например, защищенные каталоги на ваших веб-серверах и т. Д.

Протестируйте свой подход, скрипты и т. Д. Сделайте резервные копии и протестируйте их восстановление. SSSD кажется, способ относительно безболезненно настроить ваши рабочие станции и серверы для интеграции с каталогом (и FreeIPA).

Установка центральных домашних каталогов на рабочих станциях обычно является хорошей идеей, особенно в сочетании с автоматическим монтированием (autofs). То же самое на серверах (также по запросу с auto-fs), кажется, вызывает больше дискуссий. Если вы все же пойдете по этому пути, подумайте долго и хорошо, если вы или ваши пользователи должны быть теми, кто их объединит.

Риск потери данных относительно невелик, но вы регулярно делаете резервные копии и тестируете восстановление, верно?

Предположим, что пользователь roberto присутствует (с разными идентификаторами) на двух машинах. При переносе информации из / etc / passwd с обеих машин в LDAP они «объединяются» в процессе? Если нет, что делать?

Нет, они не объединяются автоматически, поскольку учетные записи пользователей могут иметь только один номер UID, и каждое имя пользователя также должно быть уникальным. Поскольку права собственности на файлы хранятся в файловой системе по номеру UID, отказ от одного UID приведет к потере владельцем прав на эти файлы. Вам нужно будет сменить владельца на оригинального, чтобы соответствовать возможному номеру UID, который вы выберете для дублирующего пользователя, который является тем же самым реальным человеком. например что-то вроде find -owner old-UID -exec chown new-UID '{}' \; дублирование имени пользователя для разных реальных людей приведет к новому имени пользователя для одного из них, или вы оба считаете, что разделяете боль.

То же самое и с основной группой пользователей.

Можно ли выполнить миграцию поэтапно, только для одного пользователя? Это целесообразно?

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

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

Файловый ресурс - гораздо лучшее место для централизованных домашних каталогов, чем блочное устройство, поэтому определенно выбирайте NFS. С помощью NFSv4 было решено множество проблем классической NFS, и в сочетании с Kerberos значительно улучшена безопасность.

Преобразование аутентификации на рабочей станции может происходить одновременно с перемещением в централизованный домашний каталог.

Во-первых, вопросы для учебных пособий и т. Д. не по теме.

Некоторые мысли:

• Вы правы, информация по этому поводу разрозненная, зачастую устаревшая и ненадежная. Например, вы найдете много информации о том, как настроить OpenLDAP с помощью файлов конфигурации, но очень мало информации о cn=config. Я предполагаю, что это результат того факта, что каждая подобная миграция отличается и просто не существует золотого способа продолжить. Невозможно написать учебник по этому поводу, который будет работать везде, иначе вы напишете очень большую книгу.
• Это означает, что вам нужно собрать детали вместе и адаптировать их к вашей ситуации. Нет никакого способа обойти это. Однако вам повезло, поскольку ваша среда кажется очень маленькой и простой, и при необходимости все необходимое можно сделать за один уик-энд.
• Инструменты виртуализации - отличное подспорье в этом, поскольку вы можете легко смоделировать все на своем ноутбуке, не затрагивая никого другого.

У меня есть несколько общих советов, как действовать. Это предполагает пошаговый метод без длительного простоя.

• Создайте список всех пользователей.
• Вручную убедитесь, что у них одинаковый UID и т. Д. Во всех системах. В основном это означает редактирование /etc/passwd и т.д., а затем find и chmod все файлы, принадлежащие пользователю.
• Если у вас есть конфликтующие имена пользователей, это должно быть решено на этом этапе (например, два Боба из отдела продаж и обслуживания клиентов названы bob на своих машинах)
• На этом этапе вы можете добавить всех пользователей с унифицированными UID в базу данных LDAP. Совет от профессионала: с OpenLDAP в Linux вы можете повторно использовать пароль из /etc/shadow если вы добавите {crypt} как префикс типа пароля в LDAP userPassword поле (так вы поворачиваете $1$E.1Saa9d$LcRBQDLfnzR6WF4HmbjpC/ в {crypt}$1$E.1Saa9d$LcRBQDLfnzR6WF4HmbjpC/
• Теперь вы можете настроить свои машины одну за другой для аутентификации по LDAP, и учетные записи пользователей должны по-прежнему работать с тем же паролем (но не забудьте удалить / переименовать локальных пользователей).
• Создайте сервер NFS для домашних каталогов и убедитесь, что он везде установлен (iSCSI имеет другое назначение).
• Скопируйте домашние каталоги пользователей в общий ресурс NFS, переименуйте старые /home к чему-то другому и смонтируйте общий ресурс NFS как /home.

Это может быть более или менее простой процесс, но в зависимости от вашей среды проблемы могут (будут!) Всплывать. Но когда вы делаете что-то по этому пути, вы можете разбираться с ними по отдельности по мере их появления. Нет точки, в которой вы находитесь в ситуации «все или ничего», которая может все остановить. Это очень удобная ситуация для такого проекта.

Если по ходу дела у вас возникнут конкретные вопросы, задавайте новые вопросы здесь.

Что касается системы, к которой вы стремитесь, возможно, стоит пойти на Бесплатный IPA потому что, если в будущем кто-то реализует некоторые блоки Active Directory, их будет довольно легко установить.

Что касается миграции ... Ну, по крайней мере, вы говорите о малом масштабе, так что вариант "запечатлеть конец сети".

Права Sudo, очевидно, жизненно важны, хотя с таким небольшим количеством машин любые acl-вещи должны быть достаточно легкими для обработки.

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