Я не могу su, когда LDAP работает

Я думаю, что Вы спрашиваете о том, что это взяло бы, чтобы Вы использовали многочисленные связи к Интернету для обработки отказа.

К счастью, Ваш домен Active Directory и внутренний DNS имеют мало общего с таким сценарием. Microsoft ISA Server исходно не поддерживает использование нескольких интерфейсов глобальной сети одновременно.

Одно решение состояло бы в том, чтобы развернуть "мульти-WAN" или "двойную WAN" маршрутизатор перед сервером ISA. Это устройства, которые выполняют элементарное выравнивание нагрузки и обработку отказа с помощью нескольких Интернет-соединений. Существует множество стандартных цен и наборов функций, таким образом, Вы преуспели бы, чтобы присмотреться к ценам и сравнить обзоры.

Вы никогда не будете заставлять полную пропускную способность обоих Интернет-соединений быть "совместно использованной" для единственного соединения TCP (единственная загрузка, и т.д.) w/o сотрудничество от ISP на другом конце. Потребитель W//полупрофессиональные маршрутизаторы "мульти-WAN", которые лучшее, которое можно надеяться на, - то, что маршрутизатор попытался бы разумно отправить новые исходящие запросы TCP по меньшему-количеству-перегруженному-каналу.

BTW: я видел пару обзоров этих маршрутизаторов Баланса Peplink, просто делающих элементарный поиск. Они являются весьма дорогими, но они, кажется, довольно тверды.


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

Был продукт под названием "RainConnect", который имел и входящую и исходящую возможность обработки отказа и выравнивания нагрузки на Сервере ISA, но продукт был прекращен к моему знанию (когда производитель был приобретен EMC).

2
задан 27 September 2010 в 17:34
2 ответа

Вы уверены, что проверяете локальную аутентификацию сначала, затем бэкенд LDAP?

Проверьте свой/etc/nsswitch.conf

Это должно показать:

пароль: файлы ldap группа: файлы ldap тень: файлы ldap

или возможно также "compat" опция

Править:

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

nscd-i passwd nscd-i группа

2
ответ дан 3 December 2019 в 12:16

Пользователь от LDAP в корректной группе, чтобы сделать su для укоренения?

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

0
ответ дан 3 December 2019 в 12:16
  • 1
    я не использую pam_wheel, таким образом, колесо группы не влияет на это. –  John 27 September 2010 в 14:21
  • 2
    Таким образом, Вы проверили, что у пользователя LDAP есть разрешение к su для укоренения хотя право? Или даже выполненный su вообще? –  dunxd 27 September 2010 в 14:29
  • 3
    Как я могу проверить его? Debian. –  John 27 September 2010 в 15:02
  • 4
    , Смотрящем снова сообщения журнала, su:auth говорит, что mejmo не имеет разрешения к su. Таким образом, почти бесспорно, что необходимо сказать, кто может su где-нибудь. Также необходимо проверить полномочия на su исполняемом файле также на всякий случай - ls -l /bin/su. Но я не думаю, что это - проблема. PAM говорит "нет", поэтому изучите конфигурацию PAM. –  dunxd 27 September 2010 в 15:51
  • 5
    , мне удалось получить его работа. Я должен был включить nscd (я отключаю его в прошлом, потому что он делал большие большие проблемы при отладке), я установил кэш ttl на несколько секунд, и теперь все работает. Я действительно не знаю, почему, но я думаю, что nscd смотрит в passwd файле так или иначе также (за исключением nsswitch). –  John 27 September 2010 в 16:09

Теги

Похожие вопросы