Проблемы с FIRST_SYS_UID - LAST_SYS_UID

[marawu]

Добрый день, подскажите пожалуйста, как решить проблему с uidNumber. Проблема в следующем, начали переключать на серверах ssh на LDAP-аутентификацию. Переключили пару десятков серверов и вот обнаружилась какая проблема: в LDAP uidNumber пользователей начинается с 2 и почти дошел до 2000, и если при установке пакета утилита пытается создать пользователя, то появляться ошибка:

Код: [Выделить]

adduser: No UID/GID pair is available in the range 100-999 (FIRST_SYS_UID - LAST_SYS_UID).

Оперативно поменять uidNumber 1000 пользователям мы не можем (хотя в дальнейшем планируется) и поэтому я хотел бы отфильтровать пользователей в nslcd, благо ssh нужен примерно 100 пользователям. Но тут проблема в другом. Для настройки доступа для каждого сервера делается posixGroup и она не понимает, что такое memberof. И вот я вижу несколько решений и хотелось бы, чтобы подсказали как будет правильней:

1. Не знаю на сколько это рабочая схема, но что если отказаться от posixGroup и перейти на groupOfUniqueNames? Будет ли тогда работать к примеру Allow Groups в sshd_config?

2. Сменить диапазон FIRST_SYS_UID - LAST_SYS_UID. Но это я так понимаю, крайне не рекомендуемое решение?

[egor]

Здраствуйте!

Добрый день, подскажите пожалуйста, как решить проблему с uidNumber. Проблема в следующем, начали переключать на серверах ssh на LDAP-аутентификацию. Переключили пару десятков серверов и вот обнаружилась какая проблема: в LDAP uidNumber пользователей начинается с 2 и почти дошел до 2000, и если при установке пакета утилита пытается создать пользователя, то появляться ошибка:

Код: [Выделить]

adduser: No UID/GID pair is available in the range 100-999 (FIRST_SYS_UID - LAST_SYS_UID).


Идея давать рядовым пользователям идентификаторы меньше 1000 действительно была так себе =( .

Оперативно поменять uidNumber 1000 пользователям мы не можем (хотя в дальнейшем планируется) и поэтому я хотел бы отфильтровать пользователей в nslcd, благо ssh нужен примерно 100 пользователям. Но тут проблема в другом. Для настройки доступа для каждого сервера делается posixGroup и она не понимает, что такое memberof. И вот я вижу несколько решений и хотелось бы, чтобы подсказали как будет правильней:

Прочитал этот абзац несколько раз, и так и не понял, что Вы хотите предпринять. При чём тут posixGroup и memberof? Если Вам нужна временная группа для пользователей ssh, что мешает создать ещё одну posixGroup-группу?

1. Не знаю на сколько это рабочая схема, но что если отказаться от posixGroup и перейти на groupOfUniqueNames? Будет ли тогда работать к примеру Allow Groups в sshd_config?

Скорее всего sshd берёт сведения по группам не из LDAP напрямую, а через системный вызов getent group, так что какие группы будет распознавать и выдавать в ответ на вызов nslcd, такие и будет видеть sshd.

2. Сменить диапазон FIRST_SYS_UID - LAST_SYS_UID. Но это я так понимаю, крайне не рекомендуемое решение?

Плохая идея, даже хуже, чем давать пользователям "системные" идентификаторы. Пользователям-то вы их поменяете рано или поздно, а как потом uid-ы программ собираетесь менять?

Егор

[marawu]

Здраствуйте!

Добрый день, подскажите пожалуйста, как решить проблему с uidNumber. Проблема в следующем, начали переключать на серверах ssh на LDAP-аутентификацию. Переключили пару десятков серверов и вот обнаружилась какая проблема: в LDAP uidNumber пользователей начинается с 2 и почти дошел до 2000, и если при установке пакета утилита пытается создать пользователя, то появляться ошибка:

Код: [Выделить]

adduser: No UID/GID pair is available in the range 100-999 (FIRST_SYS_UID - LAST_SYS_UID).


Идея давать рядовым пользователям идентификаторы меньше 1000 действительно была так себе =( .

Это было сделано до меня, и те люди уже давно не работают

Оперативно поменять uidNumber 1000 пользователям мы не можем (хотя в дальнейшем планируется) и поэтому я хотел бы отфильтровать пользователей в nslcd, благо ssh нужен примерно 100 пользователям. Но тут проблема в другом. Для настройки доступа для каждого сервера делается posixGroup и она не понимает, что такое memberof. И вот я вижу несколько решений и хотелось бы, чтобы подсказали как будет правильней:

Прочитал этот абзац несколько раз, и так и не понял, что Вы хотите предпринять. При чём тут posixGroup и memberof? Если Вам нужна временная группа для пользователей ssh, что мешает создать ещё одну posixGroup-группу?

Для каждого сервера есть PosixGroup и я хотел отсортировать с её помощью людей в nslcd, что свести к минимуму количество людей с uid меньше 1000. Но насколько я понял, это сделать не получиться, так как memberOf и PosixGroup не работают вместе

1. Не знаю на сколько это рабочая схема, но что если отказаться от posixGroup и перейти на groupOfUniqueNames? Будет ли тогда работать к примеру Allow Groups в sshd_config?

Скорее всего sshd берёт сведения по группам не из LDAP напрямую, а через системный вызов getent group, так что какие группы будет распознавать и выдавать в ответ на вызов nslcd, такие и будет видеть sshd.

2. Сменить диапазон FIRST_SYS_UID - LAST_SYS_UID. Но это я так понимаю, крайне не рекомендуемое решение?

Плохая идея, даже хуже, чем давать пользователям "системные" идентификаторы. Пользователям-то вы их поменяете рано или поздно, а как потом uid-ы программ собираетесь менять?

Егор

Вообщем отправил задачу разрабам, так как у нас много сервисов завязаны на LDAP. Попытались просто сменить uidNumber у одного пользователя и полетела связка Jira с сайтом. Так что думаю, приодеться ждать сначала, пока разрабы найдут как исправить косяки с сервисами, а потом менять всем uid

[egor]

Я попробовал поэкспериментировать с nslcd на предмет их работы с groupOfNames. Каталог:

Код: [Выделить]

dn: dc=mycompany,dc=ru
objectClass: organization
objectClass: dcObject
dc: mycompany
o: My Company

dn: ou=People,dc=mycompany,dc=ru
objectClass: organizationalUnit
ou: People

dn: uid=ivanov,ou=People,dc=mycompany,dc=ru
objectClass: inetOrgPerson
objectClass: posixAccount
uid: ivanov
cn: Ivan Ivanov
sn: Ivanov
userPassword: 123
uidNumber: 1001
gidNumber: 1001
homeDirectory: /home/ivanov
loginShell: /bin/bash

dn: ou=Groups,dc=mycompany,dc=ru
objectClass: organizationalUnit
ou: People
ou: Groups

dn: cn=LDAP_group,ou=Groups,dc=mycompany,dc=ru
objectClass: groupOfNames
objectClass: extensibleObject
cn: LDAP_group
gidNumber: 1001
member: uid=ivanov,ou=People,dc=mycompany,dc=ru
В записи группы класс extensibleObject  нужен для поддержки атрибута gitNumber.

Настройки nslcd:

Код: [Выделить]

uid nslcd
gid nslcd
uri ldap://127.1:9000
base dc=mycompany,dc=ru
filter group (objectClass=groupOfNames)

Получаем:

Код: [Выделить]

# id ivanov
uid=1001(ivanov) gid=1001(LDAP_group) группы=1001(LDAP_group)
# getent passwd ivanov
ivanov:*:1001:1001:Ivan Ivanov:/home/ivanov:/bin/bash
# getent group LDAP_group
LDAP_group:*:1001:ivanov
Всё нормально определяется.

Егор

[marawu]

Я возможно неправильно выражаюсь. Так конечно будет работать (он так у меня и работает). Меня интересует фильтр в nslcd, что-то вроде:

Код: [Выделить]

filter passwd (&(objectclass=inetOrgPerson)(|(memberof=cn=ITS.dept,ou=Groups,dc=example,dc=com)(memberof=cn=gcc.Admin,ou=Groups,dc=example,dc=com))(!(memberof=cn=Deleted.dept,ou=Groups,dc=example,dc=com)))

и при таком фильтре я при выполнении getent passwd получаю список из 20-30 пользователей, а не из 1500 тысяч. Проблема в том, что к примеру ITS.dept это PosixGroup и насколько я понял наложение memberof там не работает. 

[egor]

Здравствуйте!

Я хотел сказать следующее:
- сейчас у Вас есть группы на классе posixGroup, которые распознаёт nslcd, но с наложением memberof такие группы не работают.
- nslcd, кроме posixGroup, умеет работать с группами на классе groupOfName (что я и продемонстрировал в прошлом посте).
- наложение memberof умеет работать с классом groupOfNames и атрибутом member.
- если Вы вместо групп на posixGroup заведёте группы на groupOfNames и настроите наложение memberof, то получите и нормальное отображение LDAP-групп через системные вызовы типа getent group, и сможете настраивать интересующие Вас фильтры.

Динамически отобразить группы posixGroup в группы groupOfNames штатными средствами OpenLDAP не получится, но можно придумать "костыль" с самописным прокси на back-shell, как я показывал здесь, но не знаю, будут ли такие группы работать с memberof. Лучше не мучиться и перезавести группы нормальным способом.

Егор.

[marawu]

Правильно ли я понимаю, что groupOfName не будет работать в sudoers? sudo-ldap мы пока не готовы использовать. Идея была в том, что для каждого сервера создаётся PosixGroup с именем сервера и добавляется в ssdh_config и sudoers (это всё делается ansible'ом автоматически), таким образом предоставляя доступ только нужным учетным записям. Как только мы начали настройку на боевых серверах, появилась проблем с установкой ПО, так как все системные uid были заняты 

Меня смущает, что при выполнении команды groups я вижу только PosixGroup, в которые добавлена учетная запись. Возможно ли это из-за этого, что у нас используется groupOfUniqueNames вместо groupOfNames? Хотя насколько я понял, разница не принципиальна

ЗЫ. Я обязательно это всё протестирую (был в отпуске 3 недели), но возможно вы уже имеете опыт и сэкономите мне время 

[egor]

Возможно, я неясно выражаю свои мысли. Дело в том, что sudoers, sshd и все остальные программы не обращаются к каталогу напрямую ( у них, просто напросто, нет таких механизмов, нужны специальные патчи, либо посредники типа sudo-ldap). Все программы используют библиотеку nss через вызовы getent. nss получает информацию о пользователях, группах, протоколах, службах и т.п. и отдаёт её тому, кто сделал вызов (назовём его заказчиком) в стандартизированной форме. nss может черпать сведения о группах из разных источников: системных файлов, БД, каталога LDAP, системы NIS и т.п., всё зависит от наличия соответствующих библиотек доступа к источникам и настроек (/etc/nsswitch.conf). Заказчику же всё равно, откуда пришла информация о группах, главное, что он её получает в стандартизированном виде (группа есть), либо не получает (то есть такой группы для него не существует). Вот и вся нехитрая стратегия.

В Вашем случае для заказчика (sudoers) информация будет черпаться из каталога с помощью библиотек nss, обращающихся к демону nslcd. То есть, то, что nslcd будет считать группами (по своим настройкам), то и будет группами для sudoers.

Конечно, nslcd ничего сам додумывать не будет: то что Вы укажите ему в настройках, то он и будет считать группами. Если в настройках в фильтрах фигурируют groupOfNames, а в каталоге находятся группы groupOfUniqueNames, никаких групп nslcd не найдёт и для sudoers их не будет существовать.

Настраивайте внимательно и обязательно всё тестируйте -- я люблю запускать slapd в debug-режиме (с опцией -d 256) и смотреть, что происходит в каталоге во время моих запросов -- обычно просветление приходит быстро.

Егор