Странности с 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
Ну да, при этих настройках именно этот эффект и будет, имхо
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 написал(а): Многим
Дык у тебя же написано:
/etc/nsswitch.conf
:Уберёшь files (тут не всё так просто), будет работать только пароль из LDAP.
Права на запись в базу пользователей --- далеко не мелочь.
:wq
--
Live free or die
Anarchist
В том-то и дело, что мне надо дополнять локальные учётки учётками из LDAP, а при конкуренции локальных и LDAP игнорировать учётки из LDAP.
Это и К.О. понятно. Но сама возможность такой подмены/блокировки root меня очень не радует.
В том-то и дело, что мне надо
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 ;)
.
Мне видится, что ты не вполне проникся философией LDAP: он нужен в первую очередь для избавления от нескольких различных конкурирующих баз пользователей.
ЗЫ: Попробуй задать фильтр при обращении к базе LDAP, чтобы возвращались записи с UID > 1000.
:wq
--
Live free or die
Anarchist написал(а): Мне
Ты предлагаешь держать в 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? :)
Так же приветствуются добавления положительных и отрицательных пунктов в выше изложенные варианты организации БД пользователей.
О, спс. По-пробуем этот workaround.
GOretZ написал(а): Ты
Разверни то как ты понимаешь этот принцип :)
Работоспособность ряда модулей <> работоспособности системы в целом.
На согласовании данных в базах пользователей огребёшь столько...
Расскажи мне как ты будешь ломать внутренний LDAP ограниченного доступа (не предусматривающий возможности подключения пользователей)? :)
А если, сюрприз!, LDAP не единичен, а в виде pool'а из [например] 4 серверов?.. :)
Не понял.
:wq
--
Live free or die
Anarchist написал(а): GOretZ
Ну так, что получивший доступ к root в LDAP тут же получает root-доступ к любому ПК в сети.
Потому я этот вариант сразу отбросил.
Мало того, еще и через TLS ;-)
Я не профессиональный взломщик, но вероятность ещё не обнаруженных и не закрытых эксплойтов и дыр есть всегда.
Поэтому я считаю, что нельзя хранить суперпользователя и учётки служб в LDAP - потому как это интимные части ОС :)
Я тут вижу, что такая унификация снимает дополнительную "линию обороны"
Ах, ну да :)
Просто в моём конкретно случае есть возможность поднять только один LDAP сервак :)
и в этом случае его падение очень чревато...
Ну есть такое выражение-калька с английского, которое подразумевает очень простое и удобно управление ;)
иметь 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 ;)
.
А в терминах нагрузки? :)
Сколько достаточно?
:wq
--
Live free or die
Anarchist
и с нулевой я без 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
Прощаем :)
Но чем оффтопик разводить...
Лучше бы про
389
рассказал.:wq
--
Live free or die
Лучше бы про 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 должна быть разумно ограничена в правах, и всё.
Ну ты дал маху :)
Уж не хочешь ли сказать, что нахождение рута в LDAP даёт какое-то преимущество при физическом доступе? :))))))
На заметку ;)
1. от физического доступа ни одно программное решение защитить не может.
2. Защита от физического доступа посторонних к ПК — это уже задача охраны и самого работника, за кем закреплён ПК, а не программных средств.
3. Имея LiveCD или USB-flash и физический доступ к ПК злоумышленнику уже ничего взламывать не надо, потому как UID у root всегда 0. И загрузившись с LiveCD или USB-flash злаумышленник уже имеет полный доступ к системе ;)
Так что по-прошу не мешать бегемотов с носорогами :)
GOretZ написал(а): Уж не
Да, т.к. для смены/хищения пароля рута (а это даёт возможность пакостничать на других раб.станциях, в масштабах всей сети) нужен доступ к серверу 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 написал(а): Рут
Пока не поздно, надо толкнуть им идею :)
Задорого.
ЗЫ: Правильная настройка
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 написал(а): если
Именно. sudo остаётся, да и LiveCD возможен (правда, у меня был PXE), но никакого локального входа рутом без пароля из LDAP.