Можно ли хранить информацию строки подключения к базе данных в Active Directory?

Question

Допустим, у вас есть много приложений в вашей среде, все из которых хранят свои строки подключения к SQL Server в веб-конфигурации. Возможно ли, чтобы приложение получало эти строки подключения из Active Directory?

Мы перемещаем некоторые серверы баз данных и хотели бы, чтобы их считывали из центрального расположения. Active Directory была предложена в качестве одной из возможностей, но мы не знали, возможно ли это.

Теоретически это позволило бы нам постепенно изменить наши приложения для использования AD для чтения строк подключения, а затем, когда мы перемещаем наши серверы баз данных, сделать одно изменение в AD для обновления всех приложений.

Возможно ли это? Может быть, у вас есть лучшее предложение. Спасибо!

Answer 1

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

Я не говорю, что хранить его в Active Directory - лучший вариант, но я полагаю, что вы сможете сделать это без проблем.

Answer 2

«LDAP должен быть для справочной информации»

Что это значит? Информация о конфигурации является идеальным кандидатом для хранения в Dit - она ​​интенсивно читается, защищена, реплицируется и легко доступна. Большая часть того, что хранится в Active Directory, является «информацией о конфигурации».

Answer 3

У нас был дизайн, чтобы сделать это. Наша архитектура допускает несколько серверов, каждый с несколькими базами данных. Мы использовали Active Directory для управления атрибутами пользователей, включая базы данных, к которым у них был доступ.

В то время это казалось логичным замыслом, так как мы должны были либо делать это, либо иметь «основную» базу данных для управления. При использовании Active Directory у нас больше не было единой точки отказа.

Понятия не имею, как получилось, я покинул эту компанию.

Answer 4

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

лучше всего подойдет пользовательский объект или даже атрибут расширения для существующего объекта.

Расширение схемы AD

Answer 5

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

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

Например, вы можете использовать Spring или Spring.NET, но есть множество DI-фреймворков, которые будут работать.

ОБНОВЛЕНИЕ: Вы также можете просто создать таблицу базы данных, которая содержит эту информацию, и все приложения могут читать из базы данных, чтобы получить всю информацию о своей конфигурации.

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