ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Serg Oskin                           2:5020/20      12 Feb 2004  11:26:41
 To : Aleksey Barabanov
 Subject : Re: Вопросы по LDAP
 -------------------------------------------------------------------------------- 
 

 .RFC-X-Complaints-To: news@spider.ncc.macomnet.ru
 .RFC-NNTP-Posting-Date: Thu, 12 Feb 2004 07:26:41 +0000 (UTC)
 .RFC-Cancel-Lock: sha1:J4yr2jPebOlmeWXjBiUFGgv1ONc=
 "AB" == Aleksey Barabanov wrote:
 
  >> >> >> Вот, смотри, кусок из рабочего slapd.conf:
  >> >> >> access to attr=userPassword
  >> >> >> # тут всякие самбы и прочие _несистемные_ приблуды
  >> >> >> by self write
  >> >> >> by anonymous auth
  >> >> >> by * none
  AB> Да, да. Это именно то. Так вот через nss_ldap это не работает. Я
  >> >> правильно AB> понял ? А через pam_ldap должно, если опять же я
  >> >> правильно понял. AB> Hу собственно и сам проверю сегодня-завтра...
  >> >> 
  >> >> Помнишь про баг в nss_ldap? - Он был обнаружен именно на этом сервере,
  >> >> значит через nss_ldap как минимум crond работает... :)
  AB> Для того чтобы быть уверенным что auth идет через LDAP надо того
  AB> пользователя через которого работает крон выкинуть из системных
  >> файлов. А AB> то если "files ldap" , то не факт.
  >> 
  >> Hапример login сначала делает аутентификацию, а уж потом "становится"
  >> нужным юзером. Т.о. раз ему удается сделать auth, значит в этот момент для
  >> LDAP он anonymous (см. кусок конфига). :)
  AB> Я с того и начал, что через nss без указания binddn происходит коннект
  AB> через анонима dn="" и при чтении хеша вся процедура аутентификации
  AB> обламывается. Я не делаю серверов где пользователям позволено играться с
  AB> кроном. Поэтому мне затруднительно проверить что там с ним происходит.
  AB> Поэтому для утверждения, что крон проходит auth как аноним надо просто
  AB> посмотреть лог. В своем логе я все уже нашел и давно. Отсюда и скепсис на
  AB> счет жизненности аклей с анонимус аус. Все объяснимо становится если такая 
  AB> аутентификация идет только через pam и проч, но не через nss. Так как у
  AB> меня именно nss. Если принять, как здесь утверждается, что те кто сразу
  AB> забил на nss и все сделал через памы и саслы прекрасно живут с этими
  AB> аклями, то с вашим кроном какая-то непонятка.
 
 Так я с самого начала говорил, что auth работает через pam_ldap, точнее
 так: всё, что в RH работает через pam у меня работает через pam_ldap
 (поправлен /etc/pam.d/system-auth), а всё, что через nss - nss_ldap.
 
  AB> Хотя все вполне может быть если настраивать ldap как дополнительный
  AB> механизм. И в случае его недоступности ничего не должно ломаться. Тогда при
  AB> невозможности аутентифицироваться через ldap клиент пойдет по
  AB> ортодоксальному пути.
 
  AB> Т.е. из того что крон работает не значит что он сделал auth через ldap.
  AB> Если мы теперь забили на крон и говорим о логине, то именно это _проверено_
  AB> не работает через nss при анонимном клиенте.
 
 Hет, я не говорил о том, что crond сделал auth через ldap, я говорил о том,
 что crond пользуется nss, а в данном случае nss_ldap. А делает он это для
 того, например, чтоб узнать от имени какого юзера выполнять задание. Причём
 это не значит, что "пользователям позволено играться с кроном" (хотя
 непонятно почему им нельзя этого позволять) - например если root'у можно
 "играться с кроном", то при "passwd: ldap files" в любом случае позовётся
 nss_ldap, который захочет сделать reconnect и в результате получит SIGPIPE.
 
 Кстати, когда я искал в гуглях решение этой прблемы я видел, что народ
 сталкивается с подобным и на других программах, с crond только мне повезло.
 
 -- 
         Serg (http://oskin.ru/)
 ~
 ~
 :q!
 --- Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion,
  linux)
  * Origin: Serg at 2:5020/20 (2:5020/20@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор