Полноценность абсолютного фильтра на запросе LDAP?
Если все Ваши ресурсы будут на SBS (который - так как это - SBS, я предполагаю, что они), и Ваша скорость соединения не является большой, то перемещение сервера к центру обработки данных не улучшит ситуацию, только сделать это хуже.
Если у Вас нет локального DC, локального файла/печати с репликацией DFS и т.д.?
У нас есть неопределенно подобная установка для многих наших клиентов с e-mail/DC/fileservers в стойках и локальном файловом сервере на месте. Преимущества затем для DR (в случае, если Ваш основной сайт горит), и лучшая производительность для удаленных рабочих. Но - в зависимости от количества штата на месте - Вам действительно нужна достойная строка.
В разделах «Аннотация» и «Предпосылки» RFC четко указано, что эта функция была упущена из виду в LDAP v3. Концепция абсолютных фильтров, по-видимому, является частью X.500 / DAP, и они призваны помочь при запросе записей, специфичных для DSA, которые могут не иметь связанного с ними объектного класса. Хотя это, очевидно, не является специфической функцией производителя, ее реализация оставлена на усмотрение поставщика (например, OpenLDAP, похоже, реализовал ее). Кажется не очень полезным, если используемое программное обеспечение каталога связывает все записи, включая специфичные для DSA, с объектным классом (например, top), что делает фильтр '(objectclass = *)' функционирующим так, как будто это абсолютный фильтр что приводит к "истине". Если программное обеспечение каталога не
Я подозреваю, что это упрощает определенные программные конструкции. Например, если вы создаете выражения фильтра в своем коде следующим образом:
filter_string='(&'
for filter in filters:
filter_string = filter_string + '(' + filter + ')'
filter_string = filter_string + ')'
... тогда в случае, когда у вас нет фильтров, вы заканчиваете (&) , а часть RFC вы выделили, определяет, как это должно себя вести. То же самое верно и для (|) .