Странности с nss_ldap, pam_ldap и входом в систему

Начнем с того, что nss_ldap не может установить TLS соединение с сервером, если включено следующее:
tls_checkpeer yes
А вот pam_ldap может без проблем. Причём конфиг у них один на двоих в плане соединения с серваком.
Это, ладно я пока оставил. Но tls_checkpeer нужен, надо будет позже разобраться...

Далее.
Многим известна интересная "фитча":
1. создаем в системе пользователя с UID 1001, задал пароль1
2. создаем пользователя в LDAP с тем же UID, задал пароль2
3. проверяем вход - ходит под обоими паролями.
Выходит, что можно создать в лдапе пользователя с uid=root и uidNumber=0 и "взломать" локального root!

Ну не беда, нас спасает pam_min_uid. Например:
pam_min_uid 1000

...да. Спасает, да не совсем. Вcплывает не менее интересная фитча:
1. То же дублирование пользователей и UID в LDAP и в системе. Пусть UID пользователя = 800.
2. pam_min_uid 1000
3. проверяем вход... И не дает доступа ни для пароля локальной учетки, ни для пароля из LDAP...
Отсюда следует не менее интересный вывод: Если в конфиге зпрещён доступ для root (UID=0), то его дублированная запись в в LDAP автоматические блокирует вход root на комп вообще.

Подскажите, как сделать так, чтобы при совпадении пользователей из passwd и LDAP по именам и UID запретить доступ пользователю из LDAP, но при этом не блокировать пользователя из passwd?
Может это тоже где-то настраивается?

Мои конфиги:

/etc/openldap/slapd.conf

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/openldap.schema
include         /etc/openldap/schema/ppolicy.schema
include         /etc/openldap/schema/dyngroup.schema

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

modulepath      /usr/lib64/openldap/openldap
moduleload    back_hdb.so
moduleload    dynlist.so

access to dn.base=""
        by self write
        by users read
        by anonymous auth
access to dn.base="cn=Subschema" by * read

access to attrs=userPassword
        by self write
        by users read
        by anonymous auth
access to *
        by self write
        by users read
        by anonymous auth

Loglevel 256


TLSCACertificateFile    /etc/ssl/ldap/ca.cert
TLSCertificateFile      /etc/ssl/ldap/ldap.cert
TLSCertificateKeyFile   /etc/ssl/ldap/ldap.key

TLSVerifyClient demand
password-hash {SSHA}

database        hdb
overlay dynlist
dynlist-attrset groupOfURLs labeledURI member

suffix          "dc=local,dc=host"
checkpoint      32      30
rootdn          "cn=rootdn,dc=local,dc=host"
rootpw          {SSHA}...Хеш...
directory       /mnt/gimle/OLDAPData
index   ou,objectClass,uid,uidNumber,gidNumber  eq
index   cn,mail,surname,givenname               eq,subinitial

/etc/ldap.conf

base dc=local,dc=host
uri ldaps://localhost:636/
ldap_version 3

binddn cn=ldap,ou=daemons,dc=local,dc=host
bindpw secret

scope one

timelimit 30
bind_timelimit 30
bind_policy soft
nss_connect_policy persist

pam_filter objectClass=posixAccount
pam_login_attribute uid
pam_member_attribute gid
pam_min_uid 1000
pam_password ssha

nss_base_passwd ou=users,dc=local,dc=host?one
nss_base_shadow ou=users,dc=local,dc=host?one
nss_base_group  ou=groups,dc=local,dc=host?one

ssl on
tls_checkpeer no
tls_cacertfile /root/cert/ca.cert
tls_cert /root/cert/my.ldap.cert
tls_key /root/cert/my.ldap.key

nss_reconnect_tries 4                   # number of times to double the sleep time
nss_reconnect_sleeptime 1               # initial sleep value
nss_reconnect_maxsleeptime 16   # max sleep value to cap at
nss_reconnect_maxconntries 2    # how many tries before sleeping

/etc/nsswitch.conf

passwd:      files ldap
shadow:      files ldap
group:       files ldap

hosts:       files dns
networks:    files dns

services:    db files
protocols:   db files
rpc:         db files
ethers:      db files
netmasks:    files
netgroup:    files
bootparams:  files

automount:   files
aliases:     files

/etc/pam.d/system-auth

auth            required        pam_env.so
auth            sufficient      pam_ssh.so
auth            sufficient      pam_unix.so try_first_pass likeauth nullok
auth            sufficient      pam_ldap.so use_first_pass
auth            required        pam_deny.so

account         required        pam_unix.so
account         [default=bad success=ok user_unknown=ignore]      pam_ldap.so

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password        sufficient      pam_ldap.so use_authtok
password        required        pam_deny.so

session         optional        pam_ssh.so
session         required        pam_limits.so
session         required        pam_env.so
session         required        pam_unix.so
session         optional        pam_permit.so
session         required        pam_mkhomedir.so skel=/etc/skel/ umask=0
session         optional        pam_ldap.so

Жду отзывов, кто сталкивался с такими ситуациями :)

passwd: files

passwd:      files ldap

auth            sufficient      pam_unix.so try_first_pass likeauth nullok
auth            sufficient      pam_ldap.so use_first_pass

Ну да, при этих настройках именно этот эффект и будет, имхо

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

хм...

А вот как мне надо написать, чтобы механизм был не по принципу:
"по любой учетке"
А по принципу:
"если есть локальная учетка, то вход только ей, иначе LDAP"

Я хочу, чтобы LDAP дополнял учётки, а в конкуренции локальные учётки "затирали" лдаповские, чтобы не было возможности "взлома" локальных учёток"

Пока у меня в случае конкуренции получается только либо всем, либо никому...

GOretZ написал(а): Многим

GOretZ написал(а):
Многим известна интересная "фитча":
1. создаем в системе пользователя с UID 1001, задал пароль1
2. создаем пользователя в LDAP с тем же UID, задал пароль2
3. проверяем вход - ходит под обоими паролями.

Дык у тебя же написано:
/etc/nsswitch.conf:

passwd:      files ldap
...

Уберёшь files (тут не всё так просто), будет работать только пароль из LDAP.

GOretZ написал(а):
Выходит, что можно создать в лдапе пользователя с uid=root и uidNumber=0 и "взломать" локального root!

Права на запись в базу пользователей --- далеко не мелочь.

:wq
--
Live free or die

Anarchist

Anarchist написал(а):
Уберёшь files (тут не всё так просто), будет работать только пароль из LDAP.

В том-то и дело, что мне надо дополнять локальные учётки учётками из LDAP, а при конкуренции локальных и LDAP игнорировать учётки из LDAP.

Anarchist написал(а):
Права на запись в базу пользователей --- далеко не мелочь.

Это и К.О. понятно. Но сама возможность такой подмены/блокировки root меня очень не радует.

В том-то и дело, что мне надо

В том-то и дело, что мне надо дополнять локальные учётки учётками из LDAP, а при конкуренции локальных и LDAP игнорировать учётки из LDAP.

Use sssd , Luke

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

.

GOretZ написал(а):
Anarchist написал(а):
Уберёшь files (тут не всё так просто), будет работать только пароль из LDAP.

В том-то и дело, что мне надо дополнять локальные учётки учётками из LDAP, а при конкуренции локальных и LDAP игнорировать учётки из LDAP.

Мне видится, что ты не вполне проникся философией LDAP: он нужен в первую очередь для избавления от нескольких различных конкурирующих баз пользователей.

ЗЫ: Попробуй задать фильтр при обращении к базе LDAP, чтобы возвращались записи с UID > 1000.

:wq
--
Live free or die

Anarchist написал(а): Мне

Anarchist написал(а):
Мне видится, что ты не вполне проникся философией LDAP: он нужен в первую очередь для избавления от нескольких различных конкурирующих баз пользователей.

Ты предлагаешь держать в LDAP вообще ВСЕХ пользователей, включая рута? О_о
А как же основной принцип безопасности "не класть все яйца в одну корзину"?

Я лучше изложу как я вижу эту проблему.
Рассмотрим 2... нет 3 варианта реализации.

1. На каждом ПК своя БД пользователей passwd. Без LDAP, NIS+ и т.п. Мда...
Безопасноть:
+ Взлом пользователя даст несанкционированный доступ только к одному или небольшой группе ПК (в случае если этот пользователь работает на нескольких ПК), не затронув остальных участников сети.
+ Жёсткое ограничение доступа пользователей к ПК наличием/отсутствием учётки.
- мониторинг очен сложен, и между взломом пользователя и обнаружением взлома может пройти немало времени.
Надёжность:
+ Состояние каждого ПК изолировано от состояния всех остальных ПК и серверов.
Пользователи:
- возможное наличие отдельных логинов/паролей для каждого сервиса сети и постоянные аутентификации для получения доступа к сервисам.
администрирование
- для суровых Челябинских одминов :) Ну очень сложное, учитывая, что нужно будет отслеживать нумерацию UID на каждом ПК.

2. ВСЕ пользователи включая root в LDAP. "passwd/shadow/group ldap" вместо "passwd/shadow/group files" Мде...
Безопасность:
+ Мониторинг сети не сложен, разграничение прав доступа пользователей централизовано.
- Взлом ЛДАП = взлом ВСЕЙ сети.
Надёжность:
- Состояние каждого ПК полностью зависит от состояния LDAP сервера. Упал LDAP сервак - ПК не грузятся, работа встала.
Пользователи:
+ унифицированный доступ к сервисам через один логин пароль, возможность единовременной аутентификации при входе в систему.
администрирование
+ Как говорится "система на кончиках пальцев".

3. Две взаимодополняющие БД пользователей. Для системных учёток, рута и аварийных пользовательских - локальная, для пользовательских - LDAP.
Безопасность:
+ Мониторинг сети не сложен, разграничение прав доступа пользователей централизовано.
+ Взлом ЛДАП = взлом LDAP. Централизованного доступа к ПК от имени рута это не даст.
- конкурирующие учётки требуют особого внимания и осторожности из-за неоднозначного выбора пользователя.
Надёжность:
+ Состояние каждого ПК не зависит от состояния LDAP сервера. Упал LDAP сервак - отвал пользователей. На этот случай имеются аварийные локальные пользовательские учётки. Включая учётки для сервисов.
Пользователи:
+ унифицированный доступ к сервисам через один логин пароль, возможность единовременной аутентификации при входе в систему.
администрирование:
+ Не на много сложнее предыдущего варианта.

Вот я и решил пойти по 3-му варианту, и теперь хочу разрешать споры между passwd и LDAP в пользу passwd.
Пока у меня получилось "демократичное решение" - либо обоим, либо никому.
Здесь и таится опасность, потому как взлом ЛДАП и через создания учётки с uid 0 в нём может привести как к взлому ВСЕЙ сети ("обоим"), так и невозможности администрирования ПК при работающем LDAP ("никому").

Собственно вопрос как раз в том, как разрешить конфликты между passwd и LDAP в пользу passwd? :)
Так же приветствуются добавления положительных и отрицательных пунктов в выше изложенные варианты организации БД пользователей.

Anarchist написал(а):
ЗЫ: Попробуй задать фильтр при обращении к базе LDAP, чтобы возвращались записи с UID > 1000.

О, спс. По-пробуем этот workaround.

GOretZ написал(а): Ты

GOretZ написал(а):
Ты предлагаешь держать в LDAP вообще ВСЕХ пользователей, включая рута? О_о
А как же основной принцип безопасности "не класть все яйца в одну корзину"?

Разверни то как ты понимаешь этот принцип :)

GOretZ написал(а):
1. На каждом ПК своя БД пользователей passwd. Без LDAP, NIS+ и т.п. Мда...
Безопасноть:
+ Взлом пользователя даст несанкционированный доступ только к одному или небольшой группе ПК (в случае если этот пользователь работает на нескольких ПК), не затронув остальных участников сети.
+ Жёсткое ограничение доступа пользователей к ПК наличием/отсутствием учётки.
- мониторинг очен сложен, и между взломом пользователя и обнаружением взлома может пройти немало времени.
Надёжность:
+ Состояние каждого ПК изолировано от состояния всех остальных ПК и серверов.
Пользователи:
- возможное наличие отдельных логинов/паролей для каждого сервиса сети и постоянные аутентификации для получения доступа к сервисам.
администрирование
- для суровых Челябинских одминов :) Ну очень сложное, учитывая, что нужно будет отслеживать нумерацию UID на каждом ПК.

Работоспособность ряда модулей <> работоспособности системы в целом.
На согласовании данных в базах пользователей огребёшь столько...

GOretZ написал(а):
2. ВСЕ пользователи включая root в LDAP. "passwd/shadow/group ldap" вместо "passwd/shadow/group files" Мде...
Безопасность:
+ Мониторинг сети не сложен, разграничение прав доступа пользователей централизовано.
- Взлом ЛДАП = взлом ВСЕЙ сети.

Расскажи мне как ты будешь ломать внутренний LDAP ограниченного доступа (не предусматривающий возможности подключения пользователей)? :)

GOretZ написал(а):
Надёжность:
- Состояние каждого ПК полностью зависит от состояния LDAP сервера. Упал LDAP сервак - ПК не грузятся, работа встала.

А если, сюрприз!, LDAP не единичен, а в виде pool'а из [например] 4 серверов?.. :)

GOretZ написал(а):
администрирование
+ Как говорится "система на кончиках пальцев".

Не понял.

:wq
--
Live free or die

Anarchist написал(а): GOretZ

Anarchist написал(а):
GOretZ написал(а):
Ты предлагаешь держать в LDAP вообще ВСЕХ пользователей, включая рута? О_о
А как же основной принцип безопасности "не класть все яйца в одну корзину"?

Разверни то как ты понимаешь этот принцип :)

Ну так, что получивший доступ к root в LDAP тут же получает root-доступ к любому ПК в сети.

Anarchist написал(а):
GOretZ написал(а):
1. На каждом ПК своя БД пользователей passwd. Без LDAP, NIS+ и т.п. Мда...

Работоспособность ряда модулей <> работоспособности системы в целом.
На согласовании данных в базах пользователей огребёшь столько...

Потому я этот вариант сразу отбросил.

Anarchist написал(а):
GOretZ написал(а):
2. ВСЕ пользователи включая root в LDAP. "passwd/shadow/group ldap" вместо "passwd/shadow/group files" Мде...

Расскажи мне как ты будешь ломать внутренний LDAP ограниченного доступа (не предусматривающий возможности подключения пользователей)? :)

Мало того, еще и через TLS ;-)
Я не профессиональный взломщик, но вероятность ещё не обнаруженных и не закрытых эксплойтов и дыр есть всегда.
Поэтому я считаю, что нельзя хранить суперпользователя и учётки служб в LDAP - потому как это интимные части ОС :)
Я тут вижу, что такая унификация снимает дополнительную "линию обороны"

Anarchist написал(а):
А если, сюрприз!, LDAP не единичен, а в виде pool'а из [например] 4 серверов?.. :)

Ах, ну да :)
Просто в моём конкретно случае есть возможность поднять только один LDAP сервак :)
и в этом случае его падение очень чревато...

Anarchist написал(а):
GOretZ написал(а):
администрирование
+ Как говорится "система на кончиках пальцев".

Не понял.

Ну есть такое выражение-калька с английского, которое подразумевает очень простое и удобно управление ;)

иметь 1 лдап сервер для сети

иметь 1 лдап сервер для сети - смерти подобно

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

.

slepnoga написал(а):
иметь 1 лдап сервер для сети - смерти подобно

А в терминах нагрузки? :)

Сколько достаточно?

:wq
--
Live free or die

Anarchist

Anarchist написал(а):
slepnoga написал(а):
иметь 1 лдап сервер для сети - смерти подобно

А в терминах нагрузки? :)

Сколько достаточно?

и с нулевой я без 2-х не готов

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

А не иметь его для сети более

А не иметь его для сети более 30 компов - анальный мазохизм ;)

Как ни странно, АД очень часто ставят в гордом одиночистве, и ничего ;)

Как ни странно, АД очень

Как ни странно, АД очень часто ставят в гордом одиночистве, и ничего ;)

как ни странно, но я готов восстановить с нуля базу AD за 15 минут если это одиночный домен, или минут за 30 - если лес. ( т.е 1,5 часа с переустановкой системы -если предположить самое страшное и серваки сгорели/их залило/их просто своровали)
Нормативы опенлдапа мне к сожалению не известны

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga

slepnoga написал(а):
Нормативы опенлдапа мне к сожалению не известны

Прощаем :)

Но чем оффтопик разводить...
Лучше бы про 389 рассказал.

:wq
--
Live free or die

Лучше бы про 389

Лучше бы про 389 рассказал.

Давно ли ты синкался ? :) в дереве же уже - берите, изучайте - гвайды на сайте производителя вполне вменяемы, народу в irc навалом и отвечают :).
Вполне вероятно, что найдете там что нибудь интересное

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Ну развели тут тему. Рут

Ну развели тут тему.
Рут должен быть в LDAP, и должен быть отключен на раб.станциях. Т.к. при физическом доступе всё ломается просто запуском с LiveCD или USB-flash. "Дрожать" над паролями рута на компах глупо.
Учётка, под которой pam и nss лезут в LDAP должна быть разумно ограничена в правах, и всё.

Ну ты дал маху :)

prof-alex написал(а):
Ну развели тут тему.
Рут должен быть в LDAP, и должен быть отключен на раб.станциях. Т.к. при физическом доступе всё ломается просто запуском с LiveCD или USB-flash. "Дрожать" над паролями рута на компах глупо.
Учётка, под которой pam и nss лезут в LDAP должна быть разумно ограничена в правах, и всё.

Уж не хочешь ли сказать, что нахождение рута в LDAP даёт какое-то преимущество при физическом доступе? :))))))

На заметку ;)
1. от физического доступа ни одно программное решение защитить не может.
2. Защита от физического доступа посторонних к ПК — это уже задача охраны и самого работника, за кем закреплён ПК, а не программных средств.
3. Имея LiveCD или USB-flash и физический доступ к ПК злоумышленнику уже ничего взламывать не надо, потому как UID у root всегда 0. И загрузившись с LiveCD или USB-flash злаумышленник уже имеет полный доступ к системе ;)

Так что по-прошу не мешать бегемотов с носорогами :)

GOretZ написал(а): Уж не

GOretZ написал(а):
Уж не хочешь ли сказать, что нахождение рута в LDAP даёт какое-то преимущество при физическом доступе?

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

GOretZ написал(а):
На заметку ;)
1. от физического доступа ни одно программное решение защитить не может.

Спасибо! Я и так знаю, что вода мокрая...

Рут должен быть в LDAP, и

Рут должен быть в LDAP, и должен быть отключен на раб.станциях

мдя, до такого даже мелкомягкие не додумались - чинить систему, если что, ты тоже будешь с лайвика ?

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

slepnoga написал(а): Рут

slepnoga написал(а):
Рут должен быть в LDAP, и должен быть отключен на раб.станциях

мдя, до такого даже мелкомягкие не додумались - чинить систему, если что, ты тоже будешь с лайвика ?

Пока не поздно, надо толкнуть им идею :)
Задорого.

ЗЫ: Правильная настройка sudo Решит проблему.

:wq
--
Live free or die

не знаю для кого как - а для

не знаю для кого как - а для меня отключенный - значит получить его права вкупе с шеллом невозможно.
если имелся ввиду отключенный вход - то я только за :)

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

Это запросто :)

При моих настройках существование дублированной записи root в LDAP автоматически полностью блокирует вход под root на любом ПК в сети, где этот LDAP задействован %))))

я как то всегда думал. что

я как то всегда думал. что root@localhost и

- совершенно разные юзера.
И я точно уверен, что root/wks20.myfirma.com@MYFIRMA.COM и root/myfirma.com@MYFIRMA.COM - совсем разные создания

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

В том-то и дело, что юзера

В том-то и дело, что юзера разные, а UID один ;)
И либо пускает обоих, либо ни одного :)

slepnoga написал(а): если

slepnoga написал(а):
если имелся ввиду отключенный вход - то я только за :)

Именно. sudo остаётся, да и LiveCD возможен (правда, у меня был PXE), но никакого локального входа рутом без пароля из LDAP.

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".