Гигантское развертывание активного каталога против гигантского Sun LDAP

На работе мы находимся на ранних этапах проекта управления идентификацией. Это все в контексте высшего образования, где у нас есть пара тысяч преподавателей / сотрудников и около двадцати тысяч студентов.

Кто-нибудь использовал сервер Sun LDAP с доменом AD (область Kerberos) для хранения паролей? Кто-нибудь управлял доменом AD с четвертью миллиона записей в нем раньше?

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

Другой вариант состоит в том, чтобы AD был единственным полномочным органом по паролям, а затем у нас должны быть принципалы для всех филиалов (а также для всех старых филиалов) в течение одного или двух десятилетий, чтобы в AD было четверть миллиона объектов, из которых только 20-30k будут доступны с любой частотой.

Будет ли AD взорваться под нагрузкой? Существуют ли другие способы синхронизации паролей между LDAP и AD от Sun? Каков опыт других людей?

Это хорошее место для начала: http://technet.microsoft.com/en-us/library/cc756101(WS.10).aspx .

Этот инструмент довольно устарел (он был создан для Windows 2000 и знает только о процессорах с частотой <1 ГГц), но все же говорит, что 3-4 DC будет более чем достаточно для 500 000 пользователей, из которых 50 000 ежедневно работают. Я не думаю, что у вас должны быть какие-либо проблемы с управлением такой базой данных на современном оборудовании.

Я все время работаю с клиентами более высокого уровня, обсуждая именно тот сценарий, который вы исследуете.

У AD не будет проблем с таким количеством объектов. Я работал над клиентской средой, которая имеет несколько кратных этого.

Многие из клиентов, с которыми я работаю в вашем сценарии, заканчивают тем, что отключали изменение пароля непосредственно через AD и заставляли людей через какой-то портал, который общается с каким-то инструментом, который передает пароль во все системы, которым требуется независимая копия. Это нормально, если не сломается и все не будет синхронизировано. Я также работал со сценарием Curb, и хотя он работает, многие люди не знают, как его запустить или поддержать, поэтому вы, вероятно, напрашиваетесь на проблемы с точки зрения оперативного персонала.

Вы также можете посмотреть на что-то вроде ILM от Microsoft, которое будет записывать изменения паролей в AD и переадресовывать их на другие системы (например, Sun LDAP и т. Д.). Это позволяет людям использовать встроенную функцию смены пароля в AD поверх собственного приложения.

Иметь людей с такими связями, как выпускники, заявка, сообщество и т. Д. - это хорошо. Единственное, о чем я здесь предупреждаю, - помните, что разрешения по умолчанию, такие как «Все» / «Прошедшие проверку», используют гораздо более широкую сеть, поэтому вам нужно ACL-списки с группами, представляющими присоединения, которые представляют реальных пользователей, для которых вы хотите разрешить доступ (например, Active студенты, преподаватели, сотрудники и т. д.). Я также пытаюсь заставить людей регулярно чистить учетные записи для людей, которые являются партнерами приложения.

В общем, я очень стараюсь не иметь параллельных каталогов LDAP. Вообще говоря, это просто пустая трата времени и денег, если две (или более) службы делают одно и то же.

Будет ли AD взорваться под нагрузкой?

Я был разработчиком портала ASP.NET для более 80 онлайн / наземных профессионально-технических училищ, в основном в США, с более чем 250 000 объектов AD и, возможно, с активным использованием учетных записей в области 60 000 ( насколько мне известно ). Я никогда не видел никаких производственных проблем с AD. Имейте в виду, у нас также был второй по величине объект Exchange / AD в мире в то время. AD может выдерживать нагрузку, если правильно спроектирован и настроен для этого. Раньше я скептически относился к AD от Microsoft или к тому, что я привык думать о нем как о M $ LDAP, но он кажется достаточно стабильным и надежным, если он настроен на ваш вариант использования / среду.

Существуют ли другие способы синхронизации паролей между LDAP и AD от Sun?

Я не могу говорить ни о Sun LDAP, ни о синхронизации. Репликация AD (сама по себе) была надежной и своевременной. На думаете мы имели в общей сложности от 4 до 6 серверов AD , и я не могу вспомнить ни одного вопроса.

Вы уже внедряете AD и хотите добавить Sun LDAP или все наоборот? Возможно, было бы лучше придерживаться одного решения (Sun или Microsoft, у меня нет предпочтений), поскольку управление многочисленными учетными записями может стать проблемой. Я часто нахожу, что при создании гибридного решения у меня могут быть или не быть инструменты, чтобы сделать вещи управляемыми. Я ни в коем случае не мастер LDAP / AD, но даже программирование учетных записей AD и использование оснастки AD MMC для поиска учетных записей было довольно утомительным.

Есть взлеты и падения в каждом подходе.

Приятной частью использования Sun LDAP для аутентификации и авторизации приложений является то, что его легко поддерживать в сетях и в DMZ. В университетской среде с большим количеством бункеров это может быть реальным преимуществом, поскольку вы можете установить гибкие стандарты, которые, вероятно, будут фактически соблюдаться ... LDAP легко управляется через брандмауэры, гибок, и у вас есть множество способов Защитите свои приложения от простого связывания LDAP с решениями SSO, такими как Siteminder.

Большим недостатком является то, что вы покупаете много программного обеспечения, и теперь вам нужны люди из Unix / LDAP.

Если вы действительно хотите интеграцию с одним паролем, вы можете использовать мета-каталог, такой как ILM, или инструмент федерации, такой как Ping, чтобы синхронизировать своих пользователей AD с LDAP. Преимущество решения Microsoft заключается в том, что «выпускать» типы MCSE легче, и вы получаете возможность «задыхаться», когда ночью неровно.

Переход к модели AD выполним - AD может масштабироваться настолько высоко. Большая проблема IMO заключается в том, что вам понадобится больше серверов с большим количеством ресурсов, и поддержка центральной AD в DMZ может оказаться менее чем приятным опытом. В моем мире, с философией проектирования сетей и политиками безопасности, с которыми мы имеем дело, предоставление услуг AD за пределами клиентской вычислительной среды является кошмаром.

Если бы я был на вашем месте, учитывая информацию в вашем вопросе, я бы посмотрел на гибридный подход LDAP / AD. Позвольте AD обслуживать 20-30 тыс. Активных пользователей, а остальные 250 тыс. Подключите к системе Sun. Лучший ответ, вероятно, сильно зависит от того, как вы обеспечиваете ...