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

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

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

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

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

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

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

AD взорвался бы при загрузке?

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

Там другие пути состоят в том, чтобы сохранить пароли между LDAP Sun и AD синхронизируемыми?

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

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

Существуют взлеты и падения к каждому подходу.

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

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

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

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

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