На работе мы находимся на ранних этапах проекта управления идентификацией. Это все в контексте высшего образования, где у нас есть пара тысяч преподавателей / сотрудников и около двадцати тысяч студентов.
Кто-нибудь использовал сервер Sun LDAP с доменом AD (область kerberos) для хранения паролей? Кто-нибудь раньше запускал домен AD с четвертью миллиона записей в нем?
Один из возможных вариантов управления идентификацией - направить активный персонал в AD, а еще одну копию пароля / идентификационной информации - в LDAP. Нам нужно было бы иметь центральное место для изменения паролей, если бы мы сделали это так, чтобы при изменении пароля AD (или ldap) изменение синхронизировалось с другим (или им было разрешено расходиться)
Другой вариант - сделать AD единственным органом управления паролями, а затем у нас должны быть руководители для всех аффилированных лиц (а также всех старых аффилированных лиц) на десятилетие или два, чтобы у нас могло быть четверть миллиона сущностей в AD, из которых только 20-30k будут доступны с любой частотой.
Взорвался бы AD под нагрузкой? Есть ли другие способы синхронизировать пароли между Sun LDAP и AD? Что переживают другие люди?
Я постоянно работаю с клиентами с высшим образованием, обсуждая именно тот сценарий, который вы исследуете.
У AD не будет проблем с таким количеством объектов. Я работал с клиентскими средами, у которых есть несколько вариантов.
Многие клиенты, с которыми я работаю в вашем сценарии, в конечном итоге отключают смену пароля изначально через AD и заставляют людей проходить через какой-то портал, который взаимодействует с каким-то инструментом, который вводит пароль во все системы, которым требуется независимая копия. Это нормально, если он не сломается и все не синхронизируется. Я также работал со сценарием Curb, и хотя он работает, многие люди не знают, как запускать или поддерживать, поэтому вы, вероятно, просите проблемы с точки зрения оперативного персонала.
Вы также можете посмотреть что-то вроде ILM от Microsoft, которое будет фиксировать изменения паролей в AD и позволять вам перенаправлять их в другие системы (например, Sun LDAP и т. Д.). Это позволяет людям использовать встроенные функции смены пароля в AD вместо собственного приложения.
Хорошо, если у вас будут люди с такими связями, как выпускники, приложение, сообщество и т. Д. Единственное, о чем я предупреждаю людей, - это помнить о том, что разрешения по умолчанию, такие как Все / Прошедшие проверку пользователей, распространяют гораздо более широкую сеть, поэтому вам нужно делать ACL-элементы с группами, которые представляют принадлежность, которая представляет фактических пользователей, которым вы хотите разрешить доступ (например, Активные студенты, преподаватели, сотрудники и т. д.). Я также стараюсь убедить людей регулярно очищать учетные записи людей, которые являются партнерами по приложениям.
В общем, я очень стараюсь не иметь параллельных каталогов LDAP. Вообще говоря, это просто пустая трата времени и денег, когда две (или более) службы делают одно и то же.
Это хорошее место для старта: http://technet.microsoft.com/en-us/library/cc756101(WS.10).aspx.
Этот инструмент довольно устарел (он был создан для Windows 2000 и знает только о процессорах с частотой менее 1 ГГц), но все же говорит, что 3-4 DC будет более чем достаточно для 500 000 пользователей, из которых 50 000 активны ежедневно. Я не думаю, что у вас должны возникнуть проблемы с управлением такой базой данных на сегодняшнем оборудовании.
Взорвался бы AD под нагрузкой?
Я был разработчиком портала ASP.NET для более чем 80 онлайн / наземных профессиональных школ, в основном в США, с более чем 250 000 объектов AD и, вероятно, с активный использование аккаунта в зоне 60к (насколько мне известно). Я никогда не видел производственных проблем с AD. Имейте в виду, что в то время у нас был второй по величине объект Exchange / AD в мире. AD может выдерживать нагрузку, если правильно спроектирован и настроен для этого. Раньше я скептически относился к AD Microsoft или, как я привык думать о нем, как о M $ LDAP, но он кажется довольно стабильным и надежным, если настроен для вашего варианта использования / среды.
Есть ли другие способы синхронизировать пароли между Sun LDAP и AD?
Я не могу говорить ни за 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. Лучший ответ, вероятно, во многом зависит от того, как вы обеспечиваете ...