SQUID удостоверяване (Kerberos и LDAP) въз основа на домейни групи на Active Directory. LDAP протокол

Оставете коментар 6,950

LDAP Lightweight Directory Access Protocol (Lightweight Directory Access Protocol) е мрежов протокол за достъп до указателната услуга X.500, разработена от IETF като олекотена версия на DAP протокола, разработен от ITU-T.

Каталог- специален вид база данни, която съдържа информация в дървовидна структура.

LDAP е сравнително прост протокол, който използва TCP / IP и позволява операции за оторизация (свързване), търсене и сравнение, както и операции за добавяне, модифициране или изтриване на записи. Обикновено LDAP сървърът приема входящи връзки на порт 389, използвайки TCP или UDP портове. За LDAP сесии, капсулирани в SSL сертификати за сайт, поща, обикновено се използва порт 636. Услугата LDAP директория е базирана на клиент/сървър модел. Един или повече LDAP сървъри съдържат данни, които създават дърво с информация за директории (DIT). Клиентът се свързва със сървъра и го пита. Сървърът дава на клиента отговор и/или индикация къде да получи повече информация (обикновено друг LDAP сървър).

LDAP реализации

LDAP е широко използван стандарт за достъп до услуги на директории. От безплатните реализации с отворен код най-известният е OpenLDAP сървърът, от собствените - поддръжката на протокола е налична в Active Directory - услуга за директории от Microsoft, предназначена да централизира управлението на мрежата на Windows, конфигурирането, ускорението и често задаваните въпроси. Други реализации на директорийни услуги, които поддържат LDAP като протокол за достъп: Red Hat Directory Server, Mandriva Directory Server, Novell eDirectory, OpenDS.

Как можете да получите информация?Записът се позовава с уникалното си име, което се състои от действителното име на записа (т.нар. Relative Distinguished Name (RDN), прибавено с имената на записа на предшественика. Например записът, описващ Барбара Дженсън в примера за Интернет по-горе ) именуване, има RDN uid = babs и DN - uid = babs, ou = Хора, dc = пример, dc = com.

Какво е slapd и какво може да направи? slapd(Самостоятелен LDAP демон) е LDAP сървър на директории. Можете да го използвате, за да предоставите свой собствен сървър на директории. Вашият указател може да съдържа всякаква информация, която искате. Можете също да свържете вашата директория към глобалната LDAP услуга за директории или сами да стартирате услугата на директории. Някои функции на slapd: раздел 1.9. като SASL, TLS (или SSL), поддържа Unicode и езикови тагове.

Какво е slurpd и какво може да направи? slurpd(8) е демон, който използва slapd (8) за стартиране на услугата за репликация. Той е отговорен за разпространението на промените, направени в главната база данни slapd, към други бази данни slapd. Slurpd освобождава slapd от необходимостта да се притеснявате, ако други бази данни slapd не работят или са недостъпни, когато се правят промени в основната база данни. Slurpd автоматично опитва отново заявки за актуализиране. Slapd и Slurpd са свързани чрез прост текстов файл, който се използва за записване на промени.

LDAP, и особено OpenLDAP, има редица функции за сигурност, които може да изглеждат малко обезсърчителни на пръв (и втори и трети) поглед. Фигура 15-1 показва голямата картина на проблема, преди да навлезете в подробности. Следващите раздели демонстрират различните методи за достъп и интерфейси към LDAP система и след това описват проблемите със сигурността и наличните техники за управление на риска. Целта на това упражнение е или да се определи набор от политики за сигурност, или да се даде приоритет на изпълнението.

Фигура 15-1. Общата картина на проблемите със сигурността

Всички числа, намерени в описанието по-долу, се отнасят до Фигура 15-1.

Взаимодействие с отдалечени абонати (1):Осигуряването на сигурност при взаимодействие с отдалечени абонати може или не може да бъде проблематичен проблем. При предоставяне на неограничен (анонимен) достъп до неповерителна LDAP информация не се повдигат проблеми със сигурността. Внимание:при тези условия вашият сървър все още се превръща в потенциална цел на DoS / DDoS атаки, като го зарежда със злонамерени LDAP заявки. По този начин дори това на пръв поглед тривиално изпълнение може да изисква внимателно проектиране.

Ако всички взаимодействия с LDAP са гарантирани, че ще се извършват в надеждна мрежа, тогава можете да изберете да работите с прости пароли в ясен текст без допълнителни проблеми със сигурността. Въпреки това, дори в такива случаи, в зависимост от топологията на надеждната мрежа, е доста лесно да се прихване трафик и да се получат или поверителни данни (1-2), или пароли (1-1), изпратени в чист текст.

Когато взаимодействието с LDAP се осъществява през ненадеждни мрежи, разрушителните лица в мрежата незабавно трябва да направят нещо: да бъдат подготвени за прихващания, проследяване, атаки от човек в средата и т.н. NS. ще бъде постоянно явление. Също така имайте предвид, че използването на онлайн OLC конфигурация (cn = config) и функции за наблюдение (cn = монитор) може да доведе до превръщането на LDAP браузърите в общ инструмент за отдалечено администриране и управление на LDAP сървъри. И този трафик, по своята същност, е невероятно поверителен.

Ако се реши, че все пак е необходимо някакво ниво на сигурност, тогава първият въпрос, който възниква в този случай е: трябва ли да защитаваме само пароли (1-1) или трябва да защитим и двете данни (1-2) и пароли (1-1)? В зависимост от отговора на този въпрос ще бъдат определени следващите ни стъпки.

Пароли (1-1):Не бъркайте защитата на паролите по време на предаване по мрежата със защитата им в конфигурационни файлове или в DIT. Дори ако сте защитили всички пароли в конфигурационните файлове или в DIT с помощта на методи за хеширане като (SSHA), когато клиентът изпрати паролата на сървъра за удостоверяване, тя се изпраща в чист текст, хеширана на сървъра и сравнявана с съхранената стойност. По този начин, без да се вземат допълнителни мерки, той може да бъде прихванат (или проследен, в зависимост от предпочитанията ви за такива условия). Забележка:Когато клиент поиска запис, съдържащ, да речем, атрибута потребителска парола, чиято стойност е хеширана, да речем, според алгоритъма (CRYPT), тогава тази парола се изпраща не в ясен текст, а в нейната хеширана форма (тоест в тази, в която се съхранява). Въпреки това, когато достъпът се извършва от името на същия запис, клиентът изпраща паролата (с която се удостоверява) в чист текст и, естествено, ако удостоверяването е било успешно, прехващачът може разумно да предположи, че паролата, изпратена в чист текст, е била правилно...

При изпращане на хеширани пароли в поток от данни, който може да бъде прихванат, те стават уязвими за атаки с речник – след като получи хеширана парола, нападателят изпълнява списъка с пароли (т.нар. речник) през алгоритъма за хеширане, докато намери съвпадение. Използване сол(един или повече байта - в зависимост от реализацията - добавени към паролата преди хеширане и изхвърлени преди сравнение) значително подобрява сигурността на хеширани пароли и освен ако нямате убедителна причина да не го правите, винаги трябва да използвате формата на някакъв алгоритъм за хеширане с сол... Човек също трябва да използва ACLда предоставят достъп до пароли само на определен кръг от оторизирани потребители. Например, ако приемем, че паролите се съхраняват в атрибута потребителска парола, следният ACL ще позволи достъп до този атрибут само за собственика на записа и за конкретна потребителска група (администратор):

# OLC форма (cn = config) olcAccess: to attrs = потребителска парола от само себе си пише от анонимен auth от group.exact = "cn = admin, ou = групи, dc = пример, dc = com" запис от * none # Форматиране slapd. conf достъп до attrs = потребителска парола от само себе си пишете от анонимен auth от group.exact = "cn = admin, ou = групи, dc = пример, dc = com" напишете от * няма

Ако трябва да защитите само пароли, тогава решението може да бъде да използвате SASL с някакъв алгоритъм (например CRAM-MD5), който гарантира диалог за сигурна връзка (използвайки споделена секретна последователност), по време на която паролите никога не се предават в чист текст (). Алтернатива би била използването на TLS / SSL (със или без SASL) или Kerberos 5. В този случай могат да се използват прости механизми за пароли, тъй като цялата комуникация по мрежата е криптирана и следователно не може да бъде прихваната.

Досега обсъждахме само прости проблеми с достъпа до данни. Какво ще кажете за промяна или модифициране на тези данни? OpenLDAP предоставя две опции за одит: наслагване одит журнал(вижте man страницата на slapo-auditlog за повече информация) и наслагването на Accesslog. И двете имат функционалност за регистриране на промените, направени в работещия DIT, а accesslog дори има възможност да регистрира информация за връзки, достъп за четене/търсене и предишното съдържание на записи или атрибути.

Локален достъп (2):Локален достъп означава всички събития, които се случват директно на LDAP сървъра или сървърния клъстер (или чрез защитен отдалечен достъп до сървъра, използвайки например ssh). Най-очевидно, манипулациите с конфигурационни файлове/директории (2-1) и локално изпълнени команди (2-2) попадат в тази категория.

Конфигурационни файлове (2-1):Тук трябва да се вземат предвид два компонента:

Собственици и права:По подразбиране съвременните LDAP системи работят под потребителски/групови акаунти с ограничени привилегии (обикновено ldap: ldap). OpenLDAP се зарежда като root (за отваряне на привилегировани портове) и след това много бързо преминава към работа с нормалните си (ниски) работни привилегии. Когато се използва OLC (cn = config), OpenLDAP изисква съдържанието на конфигурационната директория да има поне 0750 привилегии за акаунта, под който ще работи (обикновено ldap: ldap), но не задава съответните привилегии самостоятелно. Това поведение се различава от работата с конфигурационния файл slapd.conf, на който автоматично се присвояват разрешения 0600.

пароли:Паролите, намерени в директориите slapd.d (при използване на OLC (cn = config)) и в конфигурационния файл (slapd.conf), като olcRootPw / rootpw, се класифицират като особено чувствителни. Най-добре е напълно да премахнете olcRootDn / rootdn и olcRootPw / rootpw, след като DIT стартира и работи. И, разбира се, всички пароли трябва да се съхраняват в хеширана форма, за да се предотврати случайно компрометиране (това трябва да бъде предвидено на ниво политика за сигурност).

Отбори (2-2):В исторически план LDAP се администрираше чрез локален интерфейс, предимно от командния ред. Предполагаше се, че локалният (вътре-сървър) трафик не подлежи на проследяване и следователно дори използването на обикновени пароли в ясен текст се считаше за адекватна мярка за защита за повечето административни услуги. Въпреки това, както беше отбелязано по-горе, увеличаването на конфигурацията по време на изпълнение (OLC, cn = config) и мониторинга (cn = monitor) на реализациите на директория може да означава, че отдалечените LDAP браузъри се превръщат в норма, когато става въпрос за администриране на LDAP системи. В този случай достъпът до тези услуги генерира предаването на изключително важна информация през мрежата, която трябва да бъде защитена с помощта на специални технологии за сигурност на данните, като TLS / SSL.

И накрая, тъй като конфигурацията по време на изпълнение съхранява всички настройки в DIT (cn = config), си струва да обмислите използването на мощния регистър за достъп с наслагване, инструмент за генериране на регистрационни файлове за одитиране на промените, направени в даден DIT.

DIT (3): DIT сигурността се дефинира от модела за защита на LDAP и се налага изключително с olcAccess / достъпът до правата трябва да бъде ограничен възможно най-строго и ACL трябва да се тестват със slapacl след всяка промяна.

Репликация (1-3):Дори ако нормалният клиентски достъп до LDAP системата не изисква сериозни мерки за сигурност, ситуацията може да е различна при репликиране на същия DIT. По време на цикъла на репликация, на някакъв етап, всички данни в DIT (потребителски и оперативни атрибути) ще бъдат прехвърлени по мрежата. Част от тази информация вероятно ще бъде много важна. Репликационната мрежа заслужава отделно внимание. Можете да конфигурирате смесен TLS / SSL и друг сигурен (или дори несигурен) тип връзка към същия сървър (вижте примери за конфигурация за смесен достъп на TLS / SSL и SASL).

Конфигуриране на SASL в OpenLDAP

Ще завършим този раздел много скоро (един ден наистина скоро ™)

Конфигуриране на SASL TLS / SSL в OpenLDAP

Ръководството за администратор на OpenLDAP гласи, че когато използвате TLS с ВЪНШЕН SASL, както клиентът, така и сървърът трябва да имат валиден сертификат X.509. Ако това е вярно, тогава получаваме ненужно сложна конфигурация и нивото на сигурност се повишава леко и поради това в повечето случаи използването му изглежда под въпрос (но има забележителни изключения, като репликация). В момента няма да обсъждаме това подробно.

Конфигуриране на TLS / SSL в OpenLDAP

Преглед

TLS (Transport Level Security) е просто името на IETF стандартизираната версия на Secure Sockets Layer (SSL) от Netscape. На практика няма разлика между SSL (v3) и TLS (v1) и тези термини се считат за синоними в тази документация. TLS / SSL се поддържа от OpenLDAP от версия 2.1.

Обикновено TLS / SSL изисква сертификат X.509 (по-известен като SSL сертификат), който може да бъде закупен от търговски CA или сертифициращ орган (CA) или може да бъде самоподписан сертификат. Тази документация предоставя стъпка по стъпка ръководство за създаване на самоподписани сертификати и предоставя допълнителни бележки относно използването на търговски сертификати, ако е необходимо.

бележки:

cn = конфигурация:ще бъде скоро.

Очакват се връзки само за LDAPS URL:аргумент -h при стартиране на slapd. По подразбиране тази стойност не е посочена, което (обикновено) съответства на -h ldap: ///. Поради изискванията на тази конфигурация, трябва да разрешим само ldaps операции, така че при стартиране на slapd трябва да се използва командата:

Slapd -h ldap: /// -u ldap -g ldap

slapd_flags = "ldaps: ///".

Ако се притеснявате за конфигурацията на защитната стена, LDAPS може да бъде конфигуриран да използва порт 389 (LDAPS е URL схема, която казва да се използва TLS, а не кой порт да се използва). В този случай командата за стартиране ще бъде следната:

Slapd -h ldaps: //: 389 / -u ldap -g ldap # при свързване на ldaps URL адресите трябва да са от вида: ldaps: //ldap.server.name: 389

Директиви за забрана, изискване и сигурност:Изчакването на връзки само на LDAPS порта(ите) налага TLS / SSL за всички връзки. В тази конфигурация на сървъра няма да се приемат други типове връзки. За да принудите потребителите да преминат LDAP удостоверяване, използвайте директивата изискват свързване, и за предотвратяване на анонимни връзки се използва директивата забрани bind_anon... По този начин, за да получите достъп до DIT, всяка връзка трябва да бъде обвързана и връзката не може да бъде анонимна. Ако посочите само директивата сигурност simple_bind = 128, това няма да доведе до необходимото ниво на защита. Тази директива просто казва: ако се извършва просто свързване, тогава трябва да се използва TLS / SSL. Не е необходимо връзката да е необходима. Единствената цел на употреба сигурност simple_bind = 128в тази конфигурация дефинирайте минималната стойност на SSF. Ако не е необходимо, тази директива може да бъде пропусната.
Достъп до rootDSE:Страничен ефект от тази политика е забраната за анонимен достъп до rootDSE, което, както вече беше отбелязано, може да бъде напълно оправдано за защитени сървъри.
ACL директиви:Тази конфигурация не предоставя допълнителни мерки за сигурност, базирани на използването на ACL - сигурността на сървъра е напълно гарантирана от директиви за глобална конфигурация и ограничаване на връзките само на LDAPS портове. ACL може да се използва за установяване на необходимия контрол на достъпа въз основа на потребителски идентификационни данни.

Персонализиране на клиента:От изискването LDAP сървърът да обслужва само TLS връзки, всички клиенти трябва да използват LDAPS URL и да проверяват X.509 сертификата на сървъра при свързване, което изисква достъп до CA (корен) сертификат. Клиентите в нашия контекст се отнасят до помощните програми и инструменти за ldap, както и до LDAP сървърите, изпълняващи услугата за репликация syncrepl. Очевидно, тъй като помощните програми и инструменти ldap са клиенти, те получават своите настройки от файла ldap.conf. Може би по-малко очевидно е, че LDAP сървърите, изпълняващи услугата за репликация, също са TLS клиенти и следователно също получават информация за CA (root) сертификат от ldap.conf. Конфигурация на Ldap.conf:

# копирайте сертификата, генериран в стъпка 1 # на подходящо място в клиентската система # предполага: /certs/ldapscert.pem # добавяне към ldap.conf TLS_CACERT /certs/ldapscert.pem

Конфигурация на LDAP сървъра, изпълняващ репликата:

# slapd.conf # глобална секция ... # Защита - TLS секция # няма настройки # репликирана DIT база данни bdb суфикс "d = example, dc = com" ... # репликация потребителски настройки syncrepl rid = 000 type = RefreshandPersist доставчик = ldaps : //ldap-master.example.com bindmethod = проста база за търсене = "dc = пример, dc = com" retry = "5 3 300 +" attrs = "*, +" binddn = "...." идентификационни данни = . ... ...

бележки:

CA (root) сертификат, използван в примера от потребителя syncrepl(и дефиниран от директивата TLS_CACERT в ldap.conf) е същият, използван като сървърен сертификат от основния доставчик на DIT. Това е следствие от използването на метода с един единствен сертификат, който използвахме за генериране на този сертификат: той функционира незабавно както като сървърен сертификат, така и като CA сертификат. С други методи за генериране на самоподписани сертификати, сертификатът на сървъра и сертификатът на CA могат да бъдат различни и, разбира се, винаги са различни при използване на търговски сертификати.

Ако, както беше обсъдено по-горе, услугата ldaps се обслужва на порт 389 (например за отстраняване на проблеми с блокирането на трафика на защитната стена), тогава дефиницията на syncrepl ще използва разширения URL формат с порта:
Syncrepl ... доставчик = ldaps: //ldap-master.example.com: 389 ...

LDAP сървъри като TLS клиенти:Когато LDAP сървърът действа като потребител на syncrepl репликация, той действа като TLS клиент и следователно трябва да удостовери сертификата на сървъра с CA (корен) сертификат, който е подписал. Тъй като този сървър действа като TLS клиент, той ще използва TLS директивите (и по този начин TLS сертификатните файлове), дефинирани за LDAP клиенти – по-специално, той ще използва директивата TLS_CACERT в ldap.conf. TLS клиентът трябва да генерира съобщение за обмен на ключове, криптирано с публичен ключсървър, който се извлича от сертификата X.509, изпратен от сървъра. Също така TLS клиентът при първоначално установяване на TLS връзка на етапа Клиент Здравейтеизпраща списък с разрешени шифровани пакети, който се контролира от директивата за конфигурация на TLS клиента TLS_CIPHER_SUITE (по подразбиране се изпращат всички възможни шифровани пакети (ВСИЧКИ), което е еквивалентно на командата openssl шифри -v ВСИЧКИ). Поемете дълбоко дъх, преди да прочетете следващото изречение. Ако LDAP сървър, който е потребител на syncrepl репликация и следователно TLS клиент също предоставя достъп до друг DIT (например cn = config) и приеме, че поддръжката на TLS също е необходима за контрол на този достъп, тогава той едновременноще бъде TLS сървър и изисква всички директиви на TLS сървъра, дефинирани по-горе в стъпки 2 и 3.

Конфигуриране на TLS / SSL смесен достъп в OpenLDAP

Ако сте прескочили директно към този раздел, заобикаляйки описанието на нормалната TLS конфигурация, моля, отделете време да се запознаете поне с, а за предпочитане с целия раздел, защото в противен случай можете да се объркате много бързо (въпреки че след като го прочетете, може да получите се обърка още по-бързо). Надяваме се обаче, че ще дойде някакво просветление.

Конфигурация - някой използва TLS, някой не

В този случай се поставя изискването някои потребители да използват TLS, а други – не. Например, политиката може да бъде както следва:

Разрешен анонимен достъп (и незащитена комуникация) до ограничен набор от публични LDAP записи.
Потребителите, които са преминали LDAP удостоверяване (проста връзка с несигурна комуникация), имат разрешен достъп за четене до публични LDAP записи, плюс ограничени права за актуализиране само на записа, притежаван от този потребител.
Потребителите с привилегии да актуализират повече от един от собствените си записи трябва да използват TLS и да се удостоверят (ако приемем, че всички са членове на групата на администраторите).
Всички потребители на репликация трябва да използват TLS / SSL.
TLS / SSL трябва да се използва при отдалечен достъп до cn = config.

Това решение изисква прилагането на ACL и директиви за конфигурация на сървъра, както е показано по-долу:

Генериране на LDAP сървър и CA сертификати:В този момент ще бъде генериран самоподписан сертификат - ако се използва търговски сертификат X.509 (SSL), този процес е ненужен и може да бъде пропуснат изцяло. Използва се прост метод с една команда за генериране на един X.509 сертификат, който може да се използва както за удостоверяване на сървъра, така и за действие като CA (корен) сертификат за клиента. Този метод е документиран подробно (с всички диалози). Последователност от команди:

# създаване на нови директории (по избор) mkdir / certs mkdir / certs / ключове cd / certs # създаване на сървър / CA сертификат и частен ключ без парола # валиден за 10 години с помощта на текущите указания за размера на RSA ключ # RSA се използва като протокол за обмен на ключове openssl req -x509 -nodes -days 3650 -newkey rsa: 2048 -keyout keys / ldapskey.pem -out ldapscert.pem # сертификат може да се използва като сървърен сертификат или CA сертификат # поставете сертификат в: /certs/ldapscert.pem # поставете частния въведете: /certs/keys/ldapskey.pem # задайте разрешенията chown -R ldap: ldap / certs / * chmod 0400 keys / ldapskey.pem

бележки:

За пълно обяснение на опциите за командата openssl вж.

Ключовите файлове обикновено имат парола (парола) за защита на чувствителни данни. Ако сертификат се генерира за сървър, такава парола никога не се използва (генерирането му се потиска от аргумента -nodes).

В зависимост от изискванията за сертификата могат да се използват други методи за генериране на самоподписани сертификати, както е описано.

Добавяне на TLS и ACL директиви към slapd.conf:(вижте края на този раздел за бележки относно cn = config). Необходимите TLS директиви се добавят към раздела за глобални настройки:

# slapd.conf # глобална секция ... # Защита - TLS секция TLSCertificateFile /certs/ldapscert.pem TLSCertificateKeyFile /certs/keys/ldapskey.pem TLSCipherSuite TLSv1 + RSA:! NULL # следната директива е зададена на това по подразбиране, # но ние го включваме тук за яснота TLSerifyClient никога ... # персонализиран DIT база данни bdb суфикс "d = example, dc = com" # без rootdn или rootpw директиви # вижте бележки за осигуряване на rootdn достъп ... # ACL # ACL1 - достъп за консуматор на репликация # (предполага свързване като cn = реплика, dc = пример, dc = com) # на потребителя, използващ TLS, е разрешен достъп за четене до целия DIT # всички останали отиват към ACL2 (прекъсване) достъп до * от dn. exact = "cn = реплика, dc = пример, dc = com" tls_ssf = 128 четене от * прекъсване # ACL2 - достъп до атрибута userpassword # анонимните потребители могат само да удостоверяват # удостоверените потребители могат да променят собствените си пароли роли (self) # членовете на групата на администраторите, използващи TLS, могат да променят пароли за достъп до attrs = userPassword чрез самостоятелно писане от анонимен auth от group.exact "cn = администратори, ou = групи, dc = пример, dc = com" tls_ssf = 128 write # ACL3 # ограничен анонимен достъп само за четене до публичното поддърво # всеки удостоверен потребител може да променя своите # собствени записи (само) в поддървото # членовете на групата на администраторите, използващи TLS, имат достъп за запис до цялото поддърво публичен достъп до dn.subtree = "ou = публичен, dc = пример, dc = com" от group.exact "cn = администратори, ou = групи, dc = пример, dc = com" tls_ssf = 128 запис от само себе си пише от анонимен чете от потребители read # ACL4 # членовете на групата на администраторите, използващи TLS, имат достъп за запис до останалата част от DIT достъпа до * от by group.exact "cn = admins, ou = groups, dc = example, dc = com" tls_ssf = 128 write # последния ACL4 твърде ясен - ако са необходими допълнителни правила, # трябва да се замени с това по-долу, което ще се филтрира от всички # потребители, които не са TLS. В този случай break означава, че ако потребителят използва TLS, # той отива към следващия ACL, в противен случай - обработката спира. # ACL4 достъп до * от group.exact "cn = администратори, ou = групи, dc = пример, dc = com" tls_ssf = 128 прекъсване # ACL5 и т.н. достъп .... # наслагване на доставчик на репликация syncprov # cn = config DIT база данни config rootdn "cn = admin, cn = config" rootpw (SSHA) hfkhfhfldkhlkhh # SSF по-голям или равен на 128 се използва за осигуряване на защитен достъп до cn = config сигурност simple_bind = 128

бележки:

Повече информация за TLSCipherSuite. Използваните параметри изключват използването на NULL шифри (без криптиране). TLSv1 покрива SSLv3. EXPORT шифри разрешени - международни връзки разрешени. Ако проблемите с производителността и натоварването са остри, по-добре е изрично да посочите списък с шифри с приемливи характеристики на производителност и натоварване на системата, отколкото да оставите произволен избор на шифр по време на TLS/SSL преговори.

DSA конфигурация:ще бъде скоро.

cn = конфигурация:ще бъде скоро.

Бележки за ACL:
1. ACL1:Този ACL, който също може да бъде поставен в раздела за глобални настройки, е проектиран да изолира на ранен етап от свързването на потребителите на репликация (DN cn = реплика, dc = пример, dc = com трябва да присъства в DIT с подходящите парола). от dn.exact = "cn = реплика, dc = пример, dc = com" tls_ssf = 128 четенесъдържа две условия, които работят (въпреки че не са изрично документирани) и съвпадения за които ще бъдат намерени, ако потребителят успешно се удостовери И използва SSF (TLS) поне 128. За да може потребителят на репликация (и всички останали) за да преминете удостоверяване (или просто да получите достъп до DIT), условието трябва да е налице от * прекъсванеза да отидете до ACL2 и да продължите да анализирате връзката.
  
  ACL2:Позволява на всеки удостоверен потребител да променя паролата си. Предоставя се анонимен достъп за целите на удостоверяване ( авт). Всеки член на групата cn = администратори, ou = групи, dc = пример, dc = com, използвайки TLS за свързване, може да промени всяка парола.
  
  ACL3:В този ред на всеки член на cn = admins, ou = групи, dc = пример, dc = com групата, използваща TLS за свързване, е позволено да пише във всеки атрибут на всеки запис в публичното поддърво на базата данни. На анонимните потребители се дава достъп за четене до поддървото обществено DIT (с изключение на атрибутите на userPassword). На удостоверения потребител е разрешено да променя всяка част от своя запис. И накрая, на удостоверения потребител (свързващ се със или без TLS) е разрешен достъп само за четене до публичното поддърво, с изключение на атрибутите на userPassword (и също с изключение на собствените му записи, чийто контрол на достъпа е посочен в клаузата self).
  
  ACL4:Само членове на групата cn = администратори, ou = групи, dc = пример, dc = com, използващи TLS при свързване, имат право на достъп за запис до всички други части на DIT. На всички останали потребители е отказан всякакъв достъп (неявно условие от * няма).

Изчаква се връзки за LDAPS и LDAP URL:Портовете, на които се очакват връзки, се контролират от аргумента -h при стартиране на slapd. По подразбиране тази стойност не е посочена, което (обикновено) съответства на -h ldap: ///. Съгласно изискванията на тази конфигурация трябва да разрешим и двете операции ldapи ldapsтака че при стартиране на slapd трябва да се използва командата:

Slapd -h "ldap: /// ldaps: ///" -u ldap -g ldap

За да стане това автоматично, трябва да настроите стартиращите скриптове в linux (/etc/rc.d/init.d/slapd), а в BSD /etc/rc.conf трябва да съдържа следния ред: slapd_flags = "ldap: /// ldaps: ///".

Защита на Rootdn достъп:След първоначалното зареждане на DIT, какви функции прави rootdn? Във всички стандартни случаи привилегиите тип rootdnза DIT може да бъде предоставен на всеки конкретен потребител (нека го наречем псевдо суперпотребител) с помощта на ACL и следователно директивата rootdnможе безопасно да се изтрие. В една добре обмислена система за управление можете да предоставите нова псевдо-суперпотребителнеобходимите разрешения, използващи стандартни ACL - всъщност за това са предназначени. Единственият капан на този подход е, че грешка в ACL може да доведе до ограничаване на необходимите разрешения. В най-лошия случай, rootdnможе да бъде временно възстановен и след това да бъде премахнат отново, когато проблемът бъде разрешен. Най-доброто решение за осигуряване на достъп от името на rootdnкъм нормален DIT, ще има изтриване на rootdn... И точката. Както в горната конфигурация.

В случаите, когато rootdnе единственият метод за достъп като cn = config в горния пример, директивата за сигурност simple_bind = 128 се използва за налагане на механизми за сигурност в специфична секция на базата данни.

Проблеми, коментари, предложения, поправки (включително повредени връзки) или има ли нещо за добавяне? Моля, отделете време от натоварения си живот, за да ни пишете, на уеб администратора или на екипа за поддръжка. Ще прекарате остатъка от деня с чувство на удовлетворение.

За някои хора първата среща с LDAP беше при преминаване от домейни на Windows NT към домейни на Active Directory или при работа с Novell NDS / eDirectory. В други случаи поддръжката на LDAP е второстепенна спрямо основната функционалност. Например, много хора се запознаха с LDAP при настройка на пощенски сървъри на Exchange 5.5 или Netscape Messaging, създаване на уеб сайтове с изисквания за удостоверяване, в процеса на работа с Web Proxy и т.н. В резултат на това LDAP директориите започнаха да се възприемат като чисто утилитарен инструмент за решаване на една или повече други специфични задачи. Целта на тази статия е да предостави на читателите по-широко разбиране за приложенията на тази технология и вътрешната структура на LDAP директориите.

LDAP ДИРЕКТОРИИ

LDAP директория е всяко LDAP-съвместимо хранилище на данни. Най-често срещаните директории днес са Microsoft Active Directory, Sun ONE Directory Server (и по-ранни версии на същия продукт, брандирани Netscape и iPlanet) и Novell eDirectory (известен преди като Novell NDS).

В по-общ смисъл, директория обикновено означава съхранение на относително статични данни, тоест такива, които се четат много пъти по-често, отколкото се променят. Основните типове данни, съхранявани в LDAP директории, отговарят на условието да са относително статични. Те включват:

данни, необходими за удостоверяване на потребителя (потребителско име, парола);
данни за потребителски права, потребителски профили и настройки;
адресни данни за лице (телефонен номер, имейл адрес, длъжност);
данни за групи хора (списъци за разпространение на електронна поща, списъци, служители на отдел);
данни за обекти от корпоративната мрежа (компютри, принтери).

Имайте предвид, че в компютърния свят вече съществува една широкомащабна система, която всъщност е директория - това е DNS сървърната система. Съществуващата специализирана DNS технология се е доказала добре и не изисква подобрение (въпреки че Microsoft взе решението да внедри DNS в Windows 2000 Server на базата на Active Directory, тоест по същество базирана на LDAP технология).

ИЗПОЛЗВАНЕ НА LDAP ДИРЕКТОРИ

Повечето LDAP директории могат да бъдат категоризирани в няколко основни групи въз основа на тяхното използване.

Директории на мрежова операционна система (NOS).... Понастоящем най-често срещаният пример за такова използване е изграждането на корпоративна мрежа под Windows, базирана на Microsoft Active Directory или Novell eDirectory.

NOS директориите съдържат информация за всички обекти в мрежата: данни за потребители, потребителски групи, работни станции, сървъри, принтери и т. н. Внедряването на такава директория осигурява централизирано мрежово администриране и управление на удостоверяване и оторизация при достъп до мрежови ресурси. Това ви позволява да избегнете дублирането на счетоводна информация в различни точки от нейното използване. (Трябва да се отбележи, че функционалността на Active Directory и eDirectory не е еднаква - естествено Active Directory е по-добре интегрирана с Windows NT и 2000. И двете решения имат както силни, така и слаби страни и следователно, преди да вземете решение, цял набор от фактори трябва да бъдат внимателно претеглени.)

Удостоверяването на потребителя в мрежи, работещи с различни варианти на UNIX, може да бъде подредено по подобен начин; в този случай се използва PAM модулът и всяка LDAP директория.

Директории за съхранение на данни за потребителите на приложението.Много производители на корпоративен софтуер са избрали да не изобретяват колелото и да изградят своя собствена система за съхранение. Вместо това потребителски пароли, разрешения и профили се поставят в LDAP директории.

Типичен пример за този подход е продуктовата линия Sun ONE, която включва, наред с други неща, сървър за електронна поща, уеб прокси, календарен сървър и уеб сървър. Тези продукти са първоначално проектирани да работят със Sun ONE Directory Server и всички приложения могат да съхраняват потребителски данни в един и същ сървър на директории. По същия начин сървърът за пощенска кутия на Exchange 2000 разчита на Active Directory като хранилище за информация за своите потребители.

LDAP се поддържа от голям брой приложения от по-малки доставчици. Това е особено вярно за уеб технологични продукти като уеб сървъри, портални сървъри и сървъри на приложения.

Указатели като адресни книги на организации.Директорията може да съдържа справочна информация за служителите – имейл адрес, телефонен номер, стаи, длъжност и т.н. Потребителският интерфейс обикновено е имейл клиент като Microsoft Outlook или Netscape Messenger (само за търсене и четене) или специално създаден клиент обикновено достъпни през мрежата. Адресната книга се използва за търсене и преглед на информация, автоматично попълване на имейл адреси и съхраняване на PKI сертификати, необходими за организиране на електронен обмен на поверителна информация.

Външни потребителски директории.Когато създавате уеб приложения, с които работят бизнес партньори или клиенти във вашата организация, трябва да създадете механизъм за удостоверяване; Традиционно за това се използват и LDAP директории.

Важно е да се отбележи, че от гледна точка на управлението на информационната среда, броят на каталозите, формирани в предприятието (и като цяло, броят на хранилищата на потребителски данни) трябва да бъде сведен до минимум. Затова винаги е полезно да се обмислят възможностите за използване на един каталог за различни цели. Например, директорията NOS може да действа като адресна книга, а директорията за конкретно приложение може да бъде предоставена на други приложения. Такъв подход (консолидиране на потребителски данни) се предлага изрично от най-големите производители на каталози и софтуер, който ги използва - на първо място става дума за Microsoft и Sun.

По този начин една и съща LDAP директория е в състояние да изпълнява различни задачи.

LDAP ПРОТОКОЛ

Lightweight Directory Access Protocol (LDAP) е протокол на приложния слой; той поддържа комуникация клиент-сървър и работи през TCP / IP (по подразбиране LDAP използва TCP порт 389). Идеята за LDAP възниква в резултат на експериментиране с ранните имплементации на стандарта X.500 в края на 80-те и началото на 1990-те. (тези реализации се оказаха много сложни и твърде взискателни към изчислителните ресурси от страна на клиента, което доведе до необходимостта от разработване на различен клиентски протокол). Техническите спецификации за новия протокол (RFC 1487 за LDAP версия 2 и RFC 1777 за вече вездесъщия LDAP версия 3) бяха публикувани съответно през 1993 и 1995 г.

LDAP първоначално е бил използван за допълване на основния клиентски протокол X.500, DAP. По този начин информационният модел на LDAP директория е напълно наследен от X.500. В съвременните директории протоколите X.500 или не се поддържат изобщо, или съществуват наравно с LDAP, но информационният модел X.500 все още се прилага - LDAP клиентът просто "не знае" от кого получава информация - от шлюза между LDAP и DAP или от независим LDAP сървър.

LDAP е проектиран да бъде възможно най-прост от самото начало: например, липсва поддръжка за сложни транзакции. Стандартът дефинира девет операции:

четене и търсене - търсене, сравнение;
редактиране - добавяне, изтриване, промяна, преименуване;
установяване и прекъсване на комуникацията - обвързвам, развързвам, изоставям.

Имената на тези операции обикновено говорят сами за себе си и не изискват обяснение. Нека обърнем внимание само на липсата на операцията за четене - нейните функции се изпълняват чрез търсене. (По-долу ще обясним как работи операцията за търсене.)

ХРАНИЛИЩЕ ЗА ДАННИ

Спецификациите на протокола не уточняват в кой формат трябва да се съхраняват самите данни и доставчиците решават този проблем по различни начини. В повечето сървъри на директории трезорите са специално проектирани да вземат предвид относителната статична природа на данните в директорията. Директории, които комбинират поддръжка на X.500 и LDAP, използват формата за съхранение, предписан от X.500. В Oracle Internet Directory и IBM SecureWay данните се съхраняват в системите за управление на релационни бази данни на съответния доставчик (Oracle и DB2). И накрая, системите, за които тази функционалност е второстепенна, могат да действат като LDAP директории, например пощенски сървър на Exchange или среда на Lotus Domino, където данните се представят в "родни" формати.

Имайте предвид, че при изграждане на LDAP директорийна система, базирана на продукти, базирани на СУБД, забележима част от функционалността на това хранилище ще остане неизползвана и може да повлияе негативно на производителността на системата. Ето защо е съвсем логично най-разпространените каталози, базирани не на СУБД, а на специализирани хранилища.

И накрая, продукти като MaXware Virtual Directory (MVD) са „виртуални директории“. MVD работи като шлюз между всеки формат за съхранение на данни (стандартен или нестандартен - идва със собствена API библиотека за работа с нестандартни формати) и LDAP. С MVD почти всяко хранилище може да бъде представено като LDAP директория.

ИНФОРМАЦИОНЕН МОДЕЛ

Данните в LDAP директориите се представят като обекти; информацията за всеки обект се съхранява в набор от атрибути (по-точно под формата на двойки "име на атрибут - стойност на атрибут"). Важна разлика от СУБД е възможността да се присвоят няколко атрибута с общо име на един обект: например обект, описващ потребител, може да съдържа няколко телефонни номера или имейл адреси.

За всяка директория предварително се задава набор от възможни атрибути. Стандартният набор може да бъде променен или разширен, ако е необходимо. Заедно с името на атрибута, неговият синтаксис е фиксиран (низ, число, дата и т.н.) и следователно, за разлика от света на СУБД, името на атрибута почти винаги е непроменено от директория до директория. И така, атрибутът c (държава)навсякъде означава името на страната, л (местност)- селище, ou (организационна единица)- подразделения на организацията, cn (общо име)- комбинация от собствени и фамилни имена и т.н. Атрибутът dc (компонент на домейна), обозначаващ името на сегмента от корпоративната мрежа.

Всеки обект на директория принадлежи към един или повече обектни класове. Обектният клас описва типа на обект и дефинира:

какви атрибути трябва да присъстват за обект от този клас;
какви атрибути могат да присъстват в обект от този клас;
какъв атрибут може да се използва за именуване на обекти от даден клас

Обектните класове образуват своя собствена йерархия на дърво; обект, принадлежащ на обектен клас, автоматично се притежава от всичките му суперкласове (всички класове са подкласове на общия клас Горна част) - този обект е обект на всички ограничения, посочени за подкласовете, както и на ограниченията на неговия собствен клас.

Например обект, принадлежащ на класа човек, трябва да има непразни атрибути cnи сн(фамилия, фамилия) и може да има атрибути телефонен номер, описаниеи някои други. Обект, принадлежащ към подкласа OrganizationalPerson (подклас човек), трябва да отговаря на същите изисквания и може в допълнение да съдържа други атрибути, включително заглавие(позиция) и ou.

Най-често срещаният обектен клас за съхранение на потребителска информация днес е inetOrgPerson(тук инетсе използва като съкращение за Интернет). Това е подклас на класа организационно Лице, той е описан в RFC 2798 (за разлика от класовете човеки организационно Лицекоито са включени в стандарта X.521). Това е така, защото стандартите X.500 са формулирани през 80-те години на миналия век. дори преди повсеместното разпространение на Интернет, а в класовете, описани там, липсва, например, стандартно поле за имейл адрес.

Класовете на каталожни обекти се разделят на основни и спомагателни (спомагателни). Всеки обект трябва да принадлежи към поне един основен клас и може да принадлежи към допълнителен(и) клас(ове). Обикновено атрибутите на последното са специфични за приложението. Например, в случай на присвояване на обект от класа inetOrgPersonкъм допълнителния клас nsmessagingserveruserрекламиран е като потребител на мейл сървъра Sun ONE Messaging; този клас ви позволява да добавите атрибут към обект nsmsgdisallowaccessнеобходими за работа на този сървър. По този начин механизмът на допълнителните класове ви позволява да използвате съществуваща директория като съхранение на данни за потребителите на ново приложение.

Наборът от типове атрибути и обектни класове, дефинирани за дадена директория, се нарича нейна схема. Схемата на всички основни LDAP директории се конфигурира от администратора, въпреки че в момента няма стандартен начин за конфигурирането й, което води до известна степен на несъвместимост: приложение, което се нуждае от LDAP директория за съхраняване на потребителски данни, трябва да има процедури за адаптиране на схемата на директория отделно за всеки (широко използван) сървър на директории.

ИМЕ НА ОБЕКТИТЕ ОТ ДИРЕКТОРА

Обектите на каталога са организирани в йерархична логическа структура - дърво. Неговият корен е празен коренен обект корен; обектите от следващото ниво се наричат суфикси.

На всеки обект се разпределя един атрибут за именуване (относително различимо име, RDN). Пълният идентификатор на обект (Distinguished Name, DN) е низ, получен чрез конкатенация на всички RDN, докато се движите през дървото от този обект към корена (вижте примера по-долу). Имайте предвид, че RDN не трябва да е уникален в цялата директория: за да се гарантира, че DN е уникален, достатъчно е RDN да бъде уникален сред близките обекти (тези, които се намират непосредствено под обекта едно ниво по-високо).

Йерархията налага определени ограничения върху възможността за изтриване на каталожни обекти: обект, под който остават други обекти, не може да бъде изтрит.

ФОРМАТ ЗА ОБМЕН НА ДАННИ

LDAP форматът за обмен на данни (LDIF) е стандартен начин за представяне на данни от директория като текстови файлове. С LDIF информацията може да се чете от директория, да се редактира с обикновен текстов редактор и да се експортира в същата или в друга директория. LDIF файлът може да съдържа данни за произволен брой обекти в директорията.

Като пример, нека да разгледаме LDIF на един обект Sun ONE Directory Server:

dn: uid = vshabat, ou = ICT, o = NIICHAVO

Cn; lang-ru :: 0JLQsNGB0LjQu9C40Lkg0Kj

Nsmsgdisallowaccess: поп http

Предпочитан език: ru

Пощенски хост: mail.niichavo.ru

Опция за доставка по пощата: пощенска кутия

Име; lang-ru :: 0JLQsNGB0LjQu9C

поща: [защитен с имейл]

Обектен клас: отгоре

Обектен клас: човек

Обектен клас: организационно лице

Обектен клас: inetorgperson

Обектен клас: mailrecipient

Обектен клас: nsmessagingserveruser

Cn: Василий Шабат

Sn; lang-ru :: 0KjQsNCx0LDRgg ==

Име: Василий

Ou: Администратори

Примерът показва, че:

RDN на обекта - " uid = vshabat»;
Обект DN - " uid = vshabat, ou = ICT, o = NIICHAVO", Тоест има още два обекта над него в дървото (с DN" ou = ICT, o = NIICHAVO" и " о = НИЙЧАВО", съответно);
този обект на директория принадлежи към обектен клас inetOrgPersonи неговите суперкласове, организационно Лице, човеки Горна часткакто и два допълнителни класа получател на пощаи nsmessagingserveruser, т.е. vshabatе потребител на Sun ONE Messaging Server;
стойност на атрибута nsmsgdisallowaccessПоказва, че въпросният потребител няма право на достъп до електронна поща чрез POP и HTTP протоколите;
стойността на атрибута ou не трябва да съвпада с RDN на възходящия обект;
атрибути cn, snи собствено имеимат локализирани версии на руски език. В LDIF файл те се дават след двойни двоеточия, кодирани в base64 (LDAPv3 напълно поддържа UTF8 кодиране)

АУТЕНТИКАЦИЯ И КОНТРОЛ НА ДОСТЪПА ДО ДАННИ ОТ КАТАЛОГА

С простото удостоверяване клиентът трябва или да се обяви за анонимен, или да предостави потребителско DN и парола по време на операцията за свързване ( обвързвам). Информацията за контрол на достъпа, съдържаща се в указателя, ви позволява да определите дали му е предоставено правото да изпълни исканата операция.

Операция обвързвамчесто се използва от други приложения, когато няма непосредствена нужда от работа с каталожни данни. Например, приложение може да поиска потребителско име и парола, да образува от тях заявка до директорията за операция обвързвами проверете изпълнението му. Ако операцията премине без грешки, тогава удостоверяването се счита за успешно. Имайте предвид само, че в повечето случаи, когато удостоверяването се извършва от крайни потребители, подробностите за работата с DN не се виждат: приложението иска потребителско име и парола, след което (свързване към директорията в съответствие със собствените си права) намира DN на обект с конкретно потребителско име и едва след това се опитва да изпълни команда обвързвам.

Удостоверяването може да се извърши по по-сложни (но и по-сигурни) начини, например чрез PKI ключове.

Методите за представяне на информация за контрол на достъпа (ACI) все още не са стандартизирани и се прилагат по различен начин в различните LDAP сървъри.

ТЪРСЕТЕ ДАННИ В КАТАЛОГА

За да извършите операция за търсене ( Търсене) в LDAP директорията клиентът се нуждае от следните параметри:

адрес на сървъра (DNS име или IP адрес);
номер на порта (по подразбиране 389);
LDAP версия (2 или 3, по подразбиране 3). В момента сървърите, които поддържат само версия 2, са рядкост и много клиенти използват версия 3 по подразбиране;
DN на потребителя, парола - за удостоверяване;
Базовото DN дефинира основата на търсенето. Търсенето ще се извършва само в частта от дървото, която се намира под посочения обект;
филтър за търсене, който съдържа смислени изисквания за стойности на атрибути. Атрибутите на низ могат да бъдат проверени спрямо даден низ или за наличието на даден подниз. За числови атрибути е възможно търсене на неравенство. В допълнение, стандартните логически операции (И, ИЛИ, НЕ) също могат да се използват във филтрите;
зона за търсене ( обхват). Възможни опции - поддърво, едноили база... При търсене по поддърво(най-често срещаният; много клиенти задават това по подразбиране) част от дървото се сканира под основния обект. При търсене единразглеждат се само тези обекти, които са непосредствено под основата (тоест едно ниво по-долу). И накрая, когато търсите базаанализира се само самият базов обект (операция Търсенес обхват на търсене базае по-скоро операция за четене, отколкото за търсене, въпреки че записът все още се проверява спрямо филтъра за търсене);
задължителни атрибути. По подразбиране търсенето ще върне атрибутите на всички намерени записи, а персонализирана заявка ще върне стойностите на конкретни атрибути.

Филтърът за търсене може да се състои от изискване за обектен клас. Например филтърът „ обектен клас = inetOrgPerson»Съвпада на всички обекти от този клас в обхвата на търсене.

Имайте предвид, че повечето сървъри осигуряват контрол на достъпа в зависимост от вида на операцията за търсене. Например, администраторът може да зададе условие, така че даден обект да се вижда от конкретен потребител само при търсене. базатоест, когато потребителят търси този конкретен обект.

В примера, показан на фигура 1, филтърът за търсене е съставен като логическа връзка от условия И за заглавието на потребителя и неговото име.

ЗАЯВКИ ЗА ОТПУСКАНЕ, ПОСОКА И РЕЛЕ

Що се отнася до често използваните системи, каталозите имат високи изисквания по отношение на наличността на тяхната услуга. Това означава, че каталожните данни трябва да бъдат поставени на няколко взаимосвързани сървъра, което ще направи възможно изпълнението на:

географски разпръсната система, където сървърите на директории са в непосредствена близост до своите потребители;
устойчива на грешки система, когато данните се дублират на два или повече сървъра и повредата на един от тях не прекъсва каталога;
мащабируема система с висока наличност, която може да издържи на значителни натоварвания поради тяхното разпределение между различни сървъри.

За реализиране на такива системи е необходим механизъм за диференциално репликация на данни между отделните сървъри на директории (само промени в съдържанието на директорията се предават по мрежата). Такива механизми са предвидени във всички общи сървъри на директории, но те все още не са стандартизирани, което означава, че е невъзможно да се организира репликация между сървъри на различни производители без участието на инструменти на трети страни.

Репликацията се предлага в два варианта - с един или повече главни сървъри. Първият метод предвижда, че всеки обект на директория може да бъде променен на един от сървърите; копията му на други сървъри са само за четене. Второто премахва това ограничение. Пълноценна устойчива на грешки система, тоест система, която продължава да обработва заявки за редактиране на данни след отказ на един от сървърите, е възможна само във втория случай. Репликацията с множество главни сървъри се изпълнява в Active Directory, eDirectory и Sun ONE Directory (в последния случай не може да има повече от два главни сървъра). Обърнете внимание, че подобна схема е потенциално опасна: при липса на механизъм за контрол на транзакциите промените, направени на основните сървъри, могат да противоречат помежду си. Подходящият механизъм решава кои промени в крайна сметка ще се осъществят и кои не (и в резултат на това ще бъдат загубени).

За внедряване на устойчиви на грешки и високодостъпни системи са необходими допълнителни инструменти за балансиране на натоварването. Този инструмент може да бъде LDAP прокси сървър, DNS Round Robin или хардуерно решение като Cisco Local Director.

Няколко сървъра могат да бъдат свързани в една система по други начини. Когато се използва реферал, LDAP сървърът съобщава, че клиентът трябва да се свърже с друг LDAP сървър, за да обработи заявката. Пренасочването изисква всички участващи LDAP клиенти да тълкуват правилно препоръката — за съжаление повечето клиенти на пазара не го правят.

От друга страна, заявките за предаване ( верижно свързване) от LDAP клиента не предполага никаква допълнителна функционалност: LDAP сървърите споделят дървото на директориите помежду си и сами препращат заявката от сървър на сървър. LDAP клиентът в този случай дори не "знае", че е използвана заявка за реле. Релейните заявки се изпълняват в сървъри на директории, поддържащи X.500 - Siemens DirX, Critical Path Directory Server, Nexor. Свързаният протокол, DSP, е част от стандарта X.500.

АДМИНИСТРИРАНЕ НА ДАННИ ОТ ДИРЕКТОРА

Всеки сървър на директории идва с интерфейс, който ви позволява както да конфигурирате и управлявате сървъра, така и да администрирате данните от директорията. Проблемът с администрирането на данни обаче не е напълно разрешен от тези инструменти.

Като начало, някои от интерфейсите за работа с данни от директории са просто неудобни, ако имате редовен достъп до тях; например структурата на конкретно дърво на директории може да бъде такава, че са необходими около десет щраквания с мишката, за да се редактира един атрибут за един потребител. Такива интерфейси не предоставят възможност за автоматизиране или опростяване на често изпълнявани задачи.

От друга страна, на пазара няма продукти, които биха позволили напълно да се изоставят административните инструменти на която и да е LDAP директория. Проблемът е, че такъв инструмент трябва да позволява не само редактиране на данни, но и управление на правата за достъп и промените в схемата на директорията, а подобни функции се изпълняват в различни сървъри по различни начини. Напоследък обаче инструменти като Softerra LDAP Administrator и безплатния инструмент за управление на данни в директорията на LDAP Browser придобиха популярност. Работата и на двете е ограничена до управлението на каталожни данни.

Като цяло системните администратори не трябва да управляват данни от директории. Делегирането на администриране, набор от механизми и конвенции, при които потребителите извън ИТ отдела отговарят за въвеждането на данни в директорията, е разумно разделение на отговорностите. Например, общото управление на информацията за персонала е поверено на отдела за човешки ресурси, а някои атрибути, като телефонен номер, могат да бъдат редактирани от самите служители.

И накрая, различни хранилища на потребителски данни могат да бъдат комбинирани в една система от директории - с метадиректории, отговорни за синхронизацията между магазините. Например, използвайки метадиректорията, Active Directory, използван в корпоративната мрежа, може да се комбинира със Sun ONE Directory Server, използван от приложения на Sun ONE като Messaging Server, както и с корпоративната система за отчитане на персонала. В резултат на това съдържанието на каталога се управлява автоматично въз основа на данни от други системи.

Василий Шабат - мениджър на отдела за разработка на решения в Open Technologies. Можете да се свържете с него на:

Указателна информационна база - DIB). Информацията включва името на обект, както и различни атрибути, които характеризират този обект. Тези препоръки се наричат стандарт X.500.

Протоколът за достъп до директория (DAP) е разработен за достъп до обектите на тази разпределена база данни.

LDAP ( Облекчен протокол за достъп до директория) предоставя повечето от възможностите на DAP при значително по-ниски разходи за внедряване. Например, излишните и рядко използвани операции са премахнати. LDAP, за разлика от X.500, използва TCP стека, а не OSI.

Въпреки това, няма съответствие едно към едно между LDAP операции и X.500 DAP операции.

LDAP е протокол, използван за достъп до информация, съхранявана на сървъри, разпределени в мрежа.

Тази информация е данните, съхранявани в атрибутите. Това предполага, че такива данни се четат по-често, отколкото се променят. LDAP се основава на комуникационен модел клиент-сървър.

Общият модел на този протокол е, че сървърът изпълнява операциите, изисквани от клиента. Клиентът изпраща заявка, описваща операцията, която трябва да бъде извършена от сървъра. Сървърът извършва необходимите операции в Директорията. След завършване на операция или множество операции сървърът връща отговор на клиента, съдържащ резултатите или код за грешка.

Имайте предвид, че докато сървърите са длъжни да връщат отговори, когато такива отговори са посочени в протокола, няма изискване за синхронно поведение на клиента или сървъра. Заявки и отговори за множество операции могат да се изпращат между клиент и сървър в произволен ред, но клиентите трябва да получат отговор за всяка своя заявка.

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

Записът се идентифицира с глобално уникално име (Distinguished Name - DN) - подобно на име на домейн в DNS структурата.

Каталогът е специализирана база данни, която може да се използва в ежедневието – телефонен указател, програмен справочник и др. Предполага се, че данните от директорията са доста статични. DNS е класически пример за такава специализирана база данни.

Предимства на LDAP

Основните причини за нарастващата популярност на LDAP са свързани с факта, че:

LDAP има стандартна схема за съхранение, за разлика от релационните бази данни, в която всеки случай дефинира своя собствена схема за съхранение по отношение на таблици и колони и връзки между таблиците. Следователно LDAP не е специфичен за всяка директория и за всяко приложение за управление - няма така наречения "проблем с директория N + 1". Всички LDAP сървъри използват унифицирана схема за съхранение, унифициран начин за именуване на съхранените обекти и унифициран протокол за достъп.
LDAP ви позволява бързо да намерите данните, от които се нуждаете, тъй като е фокусиран повече върху четенето и извличането на информация, отколкото върху нейната промяна.
LDAP не трябва да бъде ограничен до един сървър, възможно е да се организират разпределени системи от няколко сървъра. Могат да се създават връзки между различни LDAP сървъри, така че да можете да търсите няколко LDAP сървъра наведнъж.
Както LDAP протоколът, така и структурата на LDAP директорията са организирани в съответствие със стандартите, така че различни реализации на LDAP на доставчик могат да се използват последователно.

Сравняване на LDAP и база данни

Нека сравним двата най-популярни метода за съхранение на информация днес, релационни бази данни и LDAP сървъри, според следните характеристики:

Съотношение четене-запис- LDAP, за разлика от релационните бази данни, е оптимизиран за четене.
Разширяемост- LDAP схемите са по-лесни за модифициране в движение, отколкото схемите на базата данни.
Разпределение- LDAP данните могат да бъдат разположени на множество сървъри, които могат да бъдат търсени с една команда. В резултат на това можете да създадете оптимално разположени конфигурации на LDAP сървър въз основа на това къде е необходима информацията, като същевременно гарантирате, че цялата информация, съхранявана на всички LDAP сървъри, може да бъде търсена. Това постига по-висока степен на разпространение в сравнение с релационните бази данни.
Репликация- LDAP данните могат да се съхраняват на няколко сървъра, като има възможност за използване на различни методи за синхронизиране на информация.
Приложение за данни- LDAP е предназначен за ефективно използване на съхраняваните в Директорията данни от различни приложения, базите данни са разработени за едно приложение.
Сложност на връзките между обектите- обектите на базата данни имат по-сложни връзки от LDAP записите.
Транзакции- в LDAP транзакциите са по-прости, обикновено се променя един запис, транзакциите в базите данни са по-сложни.
Тип съхранявана информация- LDAP съхранява информация в атрибути.
Метод за именуване- LDAP е йерархична структура от данни. Името на обект е пътят към този обект в йерархичното дърво, подобно на файловите пътеки в обикновените файлови системи.
Схеми- схемите на релационната база данни са напълно дефинирани от разработчика на съответната база данни, LDAP има стандартни схеми, включително основната схема, обща за всяка директория. Това постига по-голяма оперативна съвместимост в сравнение с базите данни.
Стандарти- използването на стандартни схеми за съхранение и стандартен протокол за достъп е предимство на LDAP пред базите данни, тъй като в този случай LDAP клиентите могат да комуникират с всеки LDAP сървър, а клиентите на базата данни могат да взаимодействат само с базата данни, за която са предназначени.
Възможност за връщане назад при неуспешни операции- релационните бази данни имат по-гъвкави възможности за връщане назад, следователно те са по-подходящи за модифициране на информация от LDAP. За динамични обекти възможностите на LDAP може да не са достатъчни.

Принципи за разполагане на LDAP сървъри

Когато разгръщате LDAP сървъри, трябва да изпълните следните задачи:

Решете какво трябва да се съхранява в указателя. Трябва да имате ясно разбиране кои приложения ще работят с данните.
Определете структурата на данните в Каталога и установете техните връзки.
Определете набора от необходими каталожни схеми въз основа на изискванията на приложението.
Дефинирайте пространство от имена.
Определете топологията за разположение на сървъра.
Определете необходимите репликации, като се уверите, че данните са налични навсякъде, където са необходими.
Определете оптималното ниво на сигурност, като вземете предвид специфичните изисквания за сигурност.

Тази статия е написана за компютърно списание преди много време. Тъй като оттогава не са се свързвали с мен за по-нататъшната й съдба, заключавам, че това не е било полезно и го публикувам публично.

Това НЕ е ръководство за инсталиране и внедряване на LDAP. Само преглед за тези, които все още не знаят - какво животно е това ...

Коментарите са добре дошли.

УСЛУГИ НА ДИРЕКТОРИ. какво е и за какво е

И каквото и да казват хората там -
Ще живея, ще мина през звездите,
Ще ги преброя в каталога,
Ще ги препрочета от книгата на нощта.

Мрежите се разрастват. Локалните мрежи не са изключение. Често мрежата, която само вчера свързваше три компютъра, днес се разраства, узрява и обраства с ресурси. Как да не се изгубите в тях? Как да не се объркате в входовете и паролите? Как бързо да намерите необходимата информация? Рано или късно тези въпроси възникват пред почти всеки системен администратор.

Много хора се справят със самостоятелно написани скриптове. Това са истински самураи, тяхната воля е като острието на катана, а прекараното време лесно се компенсира от натрупания опит. Други, усъвършенствани от процеса на прехвърляне на дела и длъжности при смяна на работа или излизане на почивка, използват стандартизирани решения. Името на тези решения е услуги за справочници.

В този преглед ще ви запозная накратко с курса. И така, какво точно представляват услугите за справочници?

Много накратко и много опростено - това е вид база данни, която съхранява информация за потребители, възли и мрежови обекти. Целта на тяхното създаване е да опрости администрацията.

Възниква въпросът: защо да не използвате базата данни? Въпросът е, че има доста значителни разлики между услуга за директории и релационна база данни:

модел за съхранение на информация - йерархична дървовидна структура (база данни има релационна структура);
LDAP е фокусиран върху ускоряването на операцията за четене, докато операцията за запис е с приоритет в базата данни;
данните в LDAP се променят сравнително рядко;
клиентите използват стандартния LDAP протокол, докато протоколът за взаимодействие на базата данни с клиенти не е стандартизиран;
и накрая, услугата за директории обикновено е лесно мащабируема (реплицирана) на множество сървъри.

Услугата за справочници се интегрира лесно с различни услуги, вариращи от уеб сървъри до CMS (система за управление на съдържанието). Погледнете в документацията за приложението, което използвате, което изисква оторизация и потърсете ключовата дума LDAP. Намерих го? Значи това е...

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

Но времето вървеше. Мрежите растяха и узряха. Ставаше все по-очевидно, че са необходими някакви решения. Нещо, което ще улесни и без това трудния живот на системните и мрежовите администратори.

Една от първите реализации на този вид услуга е разработването на Sun Microsystems, първоначално наречена Yellow Pages. Впоследствие, поради законови търкания, името е променено на Мрежова информационна услуга (NIS), под което все още е широко известно (в тесни кръгове).

Разработката се базираше на проста идея – много от конфигурационните файлове за компютри, работещи в мрежата, са напълно еднакви. Така че защо да не накарате компютрите да вземат тези файлове от един сървър. По този начин се спести не само дисково пространство (NIS е разработен отдавна и този фактор беше доста уместен), но и времето, прекарано за синхронизиране на тези файлове.

Трудно беше да го наречем услуга за справочници, но първите стъпки в правилната посока бяха направени.

Тъй като идеята се оказа търсена, CCITT и ISO отидоха по-далеч и разработиха серия от стандарти X.500, които включват следните протоколи: DAP (Directory Access Protocol), DSP (Directory System Protocol), DISP (Directory Information Shadowing Protocol ) и DOP (Протокол за управление на оперативни обвързвания на директории). Впоследствие обаче беше установено, че тези протоколи са твърде сложни и се работи по разработването на заместител. Той стана Lightweight Directory Access Protocol (LDAP), който послужи като основа за много успешни решения.

Историята на най-известните LDAP-базирани продукти датира от 1995 г., когато служители на университета в Мичиган написват първия LDAP сървър - slapd. През 1996 г. Netscape ги нае. През 1999 г. AOL става собственик на Netscape. За да продължи работата по сървърните продукти, беше сключен стратегически съюз със Sun. Нарекоха го iPlanet Alliance. От 1999 до 2001 г. екипът на Netscape Directory Server работи съвместно с екипа на Sun Directory Server, а впоследствие и с разработчиците на Innosoft Directory Server (IDDS). Работата беше извършена както върху Directory Server, така и върху свързани проекти като Meta Directory и Directory Access Router. През октомври 2001 г. iPlanet Alliance се разпадна и членовете му Sun и Netscape започнаха самостоятелно да разработват своите продукти. От 2001 до 2004 г. разработчиците на Netscape Directory Server работиха усилено по този проект. През декември 2004 г. Netscape Directory Server стана собственост на Red Hat.

И така, след като тази история приключи, нека да видим какви услуги за директории са налични и колко са добри.

NIS (въпреки че, строго погледнато, това не е услуга за справочници).

Тази разработка на Sun Microsystems се оказа много упорита и все още се използва днес. Предимствата му са простотата на концепцията и изпълнението. Минус - може да се използва само на UNIX-съвместими операционни системи със съвпадащи конфигурационни файлове. Нека й отдадем почит и да преминем към пълноценни LDAP продукти. В тази статия няма да се спирам на техническите подробности, само ще кажа, че тяхната основна функционалност се различава леко. Разликите започват от нивото на документацията и приложния софтуер, който улеснява администрирането.

Така че нека започнем с отворен код и безплатно. Не са много от тях. Всъщност само две.

Red Hat Directory Server и Fedora Directory Server

Red Hat Directory Server първоначално беше закупен от Netscape Security Solutions като търговски продукт за Red Hat Enterprise Linux, а сега е пуснат от самия Red Hat под името Red Hat Directory Server. В съответствие със своята политика, Red Hat също пуска версия за Fedora Core. Името му е Fedora Directory Server. Red Hat Directory Server работи с Red Hat Enterprise Linux (x86, версии 3 и 4), Solaris 9 (SPARC, както 32-битов, така и 64-битов), HP-UX 11i за HP-9000 и 64-битова линия на HP Integrity сървър. Fedora Directory Server е по-малко придирчив и се съгласява да работи под Fedora Core (x86, версии 3 и 4) и Red Hat Enterprise Linux, както и други версии на Linux - gentoo, debian и т.н. Поддържат се също Solaris, Windows 2000 и HP / UX 11i (pa-risc). Заключение: Страхотен избор за базирани на RedHat дистрибуции. Добре документирано как се сравнява благоприятно с OpenLDAP. Кодът на тези проекти до голяма степен е същият (поради общия предшественик).

OpenLDAP

OpenLDAP е по-нататъшно развитие на оригиналния slapd. Широко разпространени. Използва се на много платформи като Linux, FreeBSD, Windows и MacOS X. Документацията на сайта ще се нарича Spartan. Въпреки това, sapienti sat, и в мрежата има много уроци стъпка по стъпка. Ако по някаква причина не сте доволни от използването на продукт от RedHat, OpenLDAP е отличен избор, изпитан във времето. Функционалността и на двата проекта е почти идентична.

Тук приключват отворените и безплатни LDAP сървъри и започват решенията от корпоративен клас. За съжаление подробностите за техния произход и функционалност са скрити зад блясъка на маркетинговите съобщения за пресата. Затова ще бъда кратък.

Електронна директория на Novell

Първо, няколко думи за лицензионната политика, тъй като тя е доста интересна. Първо, всички продукти са безплатни за университетите. Второ, можете да инсталирате този продукт и да го използвате напълно безплатно (годишен лиценз за 100 000 потребители. Няма техническа поддръжка. Можете да го получите, като поискате пробен ключ веднъж годишно). Трето, можете да го купите. Цена - $2 за лиценз за един потребител без ограничение във времето. Работи под следните операционни системи: Novell Netware, Windows (NT-бранш), Linux (SUSE Enterprise или RedHat), Solaris, AIX, HP-UX. Резюме: решението е всичко в едно - цялата гама от необходими програми се доставя незабавно. Инсталацията и конфигурацията са направени възможно най-удобни. Ниска цена. Страхотна документация. За регистрирани потребители - тези. поддържа. Кръстосана платформа. Минус - затворен източник.

Microsoft ActiveDirectory

Включен с Windows Server 200x. Идеално решение за MS мрежи. Ако планирате да използвате линия от продукти само от MS - струва си да помислите. Ако все пак се използва нещо различно от Windows 200x като сървър, препоръчвам да обърнете голямо внимание на горните продукти. Заключение: Отлична интеграция в системата, висококачествена документация. Недостатъкът е доста високата цена.

Sun Java System Directory Server

В началото на 2000-те, Sun се сля с iPlanet и използвайки своите разработки (в частност iPlanet Directory Server) създаде свой собствен продукт - Sun ONE, по-късно преименуван на Sun Java System Directory Server. Това не е самостоятелен продукт, а само част от Java Enterprise System. Системни изисквания: Solaris 10, Solaris 9, Solaris 8 (само за SPARC), Red Hat Enterprise Linux 2.1 и 3.1, HP-UX 11i, Microsoft Windows 2000, XP (за разработчици), 2003 г. Не се продава отделно от Java Enterprise System. Заключение - ако решите да използвате цялостно решение от Sun, очевидно няма да имате особени проблеми. Инженерите на Sun могат да ви помогнат да го инсталирате и персонализирате според вашите нужди. За пари, разбира се.

IBM Tivoli Directory Server

LDAP решение от IBM. Работи под следните операционни системи: AIX, Solaris, Microsoft Windows 2000, HP-UX, както и Linux за Intel и IBM eServer iSeries, pSeries и zSeries. Цените започват от $10 000. Решението очевидно не е за всеки. Въпреки това си струва да се отбележи документацията, достъпна за всички. Горещо препоръчвам на всеки, който се интересува от LDAP, IBM Red Books Understanding LDAP – Проектиране и внедряване Въпреки че е обхванат основно от IBM Tivoli Directory Server, той съдържа много висококачествен теоретичен материал за това какво представлява LDAP и как е по-добре да се планира вашия каталог.

С това завършвам леко разтегнатото си повествование. Надявам се, че успях да ви заинтригувам. Накрая ще кажа следното. LDAP е следващата стъпка в внедряването на DHCP. Удобството, получено от използването му, надвишава труда, включен при въвеждането му. Ако вашата локална мрежа има повече от 10 компютъра, помислете за LDAP.