Журнал LinuxFormat - перейти на главную

LXF142:OpenLDAP

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

OpenLDAP как за­ме­на ActiveDirectory

Сво­бод­ная реа­ли­за­ция го­то­ва за­ме­нить про­прие­тар­ный ана­лог – как ми­ни­мум, во мно­гих ти­пич­ных слу­ча­ях. Ан­д­рей Ан­д­ре­ев обо­зре­ва­ет служ­бы ка­та­ло­гов.

Всем из­вес­тен тот факт, что в опе­ра­ци­он­ных сис­те­мах MS Windows для ор­ганиза­ции цен­тра­ли­зо­ван­но­го хранения и управ­ления ре­сур­са­ми се­ти ис­поль­зу­ет­ся Active Directory (AD), ко­то­рая яв­ля­ет со­бой сред­ст­во ие­рар­хи­че­­ско­­го пред­став­ления ре­сур­сов, при­над­ле­жа­щих неко­то­рой от­дель­но взя­той ор­ганиза­ции, и ин­фор­ма­ции об этих ре­сур­сах. Под этим по­ня­ти­ем мо­гут под­ра­зу­ме­вать­ся ма­те­ри­аль­ные ре­сур­сы, пер­со­нал, се­те­вые ре­сур­сы и т. д. Но, несмот­ря на все на­ра­бот­ки Microsoft (на­при­мер, GPO), AD есть не что иное, как служ­ба ка­та­ло­гов, ра­бо­таю­щих по про­то­ко­лу LDAP (уп­ро­щен­ный про­то­кол DAP). Со­от­вет­ст­вен­но, лю­бая служ­ба ка­та­ло­гов, ра­бо­таю­щая по дан­но­му про­то­ко­лу, мо­жет час­тич­но или пол­но­стью за­менить AD в за­ви­си­мо­сти от хра­ня­щих­ся в ба­зе служ­бы ка­та­ло­гов дан­ных. В ми­ре СПО су­ще­ст­ву­ет несколь­ко действительно стоя­щих реа­ли­за­ций служб ка­та­ло­гов: OpenLDAP, Red Hat Directory Server, Mandriva Directory Server. На Linux дав­но пор­ти­ро­ва­ны мно­гие ком­мер­че­­ские про­дук­ты это­го клас­са – на­при­мер, Novell eDirectory; но наи­бо­лее гиб­кая из них в ис­поль­зо­вании – OpenLDAP. Её мы се­го­дня и рас­смот­рим.

Что та­кое OpenLDAP?

Итак, OpenLDAP – это служ­ба ка­та­ло­гов, ко­то­рая по­зво­ля­ет нам ра­бо­тать с раз­лич­ны­ми се­те­вы­ми ре­сур­са­ми (поль­зо­ва­те­ля­ми, ком­пь­ю­те­ра­ми, прин­те­ра­ми, зо­на­ми DNS, а так­же всем, что необ­хо­ди­мо вам для ра­бо­ты).

Вся ра­бо­та осу­ще­ст­в­ля­ет­ся по про­то­ко­лу LDAP (англ. Lightweight Directory Access Protocol). Это се­те­вой про­то­кол для досту­па к служ­бе ка­та­ло­гов X.500, раз­ра­бо­тан­ный IETF как об­лег­чён­ный ва­ри­ант ITU-T про­то­ко­ла DAP. LDAP – от­но­си­тель­но про­стой про­то­кол, ис­поль­зую­щий TCP/IP и по­зво­ляю­щий про­из­во­дить опе­ра­ции ав­то­ри­за­ции [bind], по­ис­ка [search] и сравнения [compare], а так­же опе­ра­ции до­бав­ления, из­менения или уда­ления за­пи­сей.

Лю­бая запись в ка­та­ло­ге LDAP со­сто­ит из од­но­го или несколь­ких ат­ри­бу­тов и об­ла­да­ет уникаль­ным именем (DN – англ. Distinguished Name). Уникаль­ное имя со­сто­ит из од­но­го или несколь­ких от­но­си­тель­ных уникаль­ных имен, раз­де­лён­ных за­пя­той. От­но­си­тель­ное уникаль­ное имя име­ет вид «Имя­ Ат­ри­бу­та=зна­чение». На од­ном уровне ка­та­ло­га не мо­жет су­ще­ст­во­вать двух за­пи­сей с оди­на­ко­вы­ми от­но­си­тель­ны­ми уникаль­ны­ми име­на­ми. В си­лу та­кой струк­ту­ры уникаль­но­го имени за­пи­си в ка­та­ло­ге мож­но лег­ко пред­ста­вить в ви­де де­ре­ва. Вся ин­фор­ма­ция хранит­ся в ба­зе дан­ных, а доступ к ней осу­ще­ст­в­ля­ет­ся по про­то­ко­лу LDAP.

В OpenLDAP для хранения ин­фор­ма­ции ис­поль­зу­ет­ся ба­за дан­ных Berkeley DB, что на­кла­ды­ва­ет ряд ог­раничений на ко­ли­че­­ст­во за­пи­сей, хранимых на­ми. Эм­пи­ри­че­­ски вы­яв­ле­но, что для 400 – 500 за­пи­сей ба­зы дан­ных Berkeley DB доста­точ­но. Од­на­ко, ес­ли ко­ли­че­­ст­во на­ших за­пи­сей в служ­бе ка­та­ло­гов бо­лее 500, пред­поч­ти­тельней ис­поль­зо­вать ба­зы дан­ных SQL. Как след­ст­вие, мож­но умень­шить вре­мя за­про­са.

Для ра­бо­ты с SQL необ­хо­ди­мо в основ­ном кон­фи­гу­ра­ци­он­ном фай­ле slapd.conf под­клю­чить необ­хо­ди­мый мо­дуль back_sql.la, рас­ком­мен­три­ро­вав его, а так­же путь к мо­ду­лям. По­сле это­го вме­сто ти­па ба­зы дан­ных bdb ука­жи­те sql в па­ра­мет­ре database и под­го­товь­те таб­ли­цы SQL. Под­робнее с этим мож­но по­зна­ко­мить­ся в HowTo http://darold.net/projects/ldap_pg/HOWTO/index.html.

Ус­та­нов­ка и на­строй­ка

Ус­та­нав­ли­вать OpenLDAP мы бу­дем в ди­ст­ри­бу­ти­ве CentOS. Для ус­та­нов­ки вы­пол­ним ко­ман­ду 

# sudo yum install openldap*

Ос­нов­ной кон­фи­гу­ра­ци­он­ный файл на­хо­дит­ся в ка­та­ло­ге /etc/openldap/ и на­зы­ва­ет­ся slapd.conf. Для пер­во­на­чаль­ной на­строй­ки дос­та­точ­но ука­зать зна­че­ния сле­дую­щим па­ра­мет­рам: suffix, rootdn, rootpw.

При­мер: 

include		 /etc/openldap/schema/core.schema
include		 /etc/openldap/schema/cosine.schema
include		 /etc/openldap/schema/inetorgperson.schema
include		 /etc/openldap/schema/nis.schema
allow bind_v2
pidfile		 /var/run/openldap/slapd.pid
argsfile	 /var/run/openldap/slapd.args
# modulepath	 /usr/lib/openldap
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
database	 bdb
suffix		 “dc=lw,dc=lan”
rootdn		 “cn=Manager,dc=lw,dc=lan”
rootpw		 secret
directory	 /var/lib/ldap
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub

Сле­ду­ет от­ме­тить, что в при­ме­ре пред­став­лен не весь кон­фи­гу­ра­ци­он­ный файл, а толь­ко его часть.

За­пус­тим служ­бу ка­та­ло­гов: 

#/etc/init.d/ldap start

Для ра­бо­ты нам не­об­хо­ди­мо за­не­сти в ба­зу OpenLDAP не­об­хо­ди­мую ми­ни­маль­ную ин­фор­ма­цию – на­при­мер, за­пись ад­ми­ни­ст­ра­то­ра ка­та­ло­га. Но предварительно рас­смот­рим струк­ту­ру хра­не­ния за­пи­сей LDAP:

  • Са­мый верх­ний уро­вень («ко­рень» де­ре­ва ): 
dc=lw,cd=lan

Здесь объ­ект клас­са dc – Domain Controller, как это при­ня­то и в AD.

  • Сле­дую­щий уро­вень ou – Organization Unit («ветвь» де­ре­ва, кон­тей­нер­ный объ­ект), в ко­то­рой по умол­ча­нию соз­да­ют­ся объ­ек­ты, пред­став­ляю­щие поль­зо­ва­те­лей: 
ou=People,dc=lw,dc=lan
  • Са­ми поль­зо­ва­те­ли бу­дут пред­став­ле­ны в ви­де объ­ек­тов сле­дую­ще­го ви­да: 
uid=user,ou=People,dc=lw,dc=lan

Струк­ту­ра за­пи­сей пред­став­ля­ет­ся в ви­де де­ре­ва, с корневым эле­мен­том dc=lw,dc=lan. Доступ ко всем вет­кам де­ре­ва име­ет толь­ко ад­минист­ра­тор ка­та­ло­га или поль­зо­ва­тель, на­де­лен­ный со­от­вет­ст­вую­щи­ми пра­ва­ми. На­при­мер, поль­зо­ва­тель user не име­ет прав на про­смотр со­дер­жи­мо­го ка­та­ло­га вы­ше вет­ки ou=People,dc=lw,dc=lan.

Итак, пе­рей­дем к прак­ти­ке и соз­да­дим файл test.ldif. 

dn: dc=lw,dc=lan //ко­рень ка­та­ло­га, suffix, наш до­мен
dc: lw
objectClass: top
objectClass: dcObject
objectClass: organization
o: test
dn: cn=Manager,dc=lw,dc=lan	 // ад­ми­ни­ст­ра­тор ка­та­ло­га;
	 // ес­ли рас­смат­ри­вать objectClass: top
	 // от­но­си­тель­но фай­ла slapd.conf, это rootdn
objectClass: organizationalRole
cn: Manager
dn: ou=people,dc=lw,dc=lan 	 // вет­ка people ( в AD вет­ка 	
			 // на­зы­ва­ет­ся Users)
ou: people
objectClass: top
objectClass: organizationalUnit
dn: uid=user,ou=people,dc=lw,dc=lan //наш пер­вый поль­зо­ва­тель
uid: user
cn: User
objectClass: account
objectClass: posixAccount
objectClass: top
uidnumber: 1001
gidnumber: 1001
homedirectory: /home/user
gecos: User
userpassword: 123456

На пер­вый взгляд здесь не всё так про­сто. Од­на­ко всё го­раз­до лег­че, чем ка­жет­ся. dn ука­зы­ва­ет на на­ча­ло но­вой вет­ки в на­шем де­ре­ве струк­ту­ры ка­та­ло­га, а даль­ше идет опи­сание объ­ект­ных клас­сов и ат­ри­бу­тов за­пи­си.

Где взять объ­ект­ные клас­сы и со­от­вет­ст­вую­щие ат­ри­бу­ты? Для это­го су­ще­ст­ву­ют спе­ци­аль­ные фай­лы-схе­мы с рас­ши­рением *.schema, ко­то­рые рас­по­ло­же­ны в ка­та­ло­ге /etc/openldap/schema/. Рас­смот­рим часть та­кой схе­мы, поскольку там мно­го ин­те­рес­ной ин­фор­ма­ции.

Взять, к при­ме­ру, файл /etc/openldap/schema/core.schema: 

attributetype ( 2.5.4.10 NAME ( 'o' 'organizationName' )
	 DESC 'RFC2256: organization this object belongs to'
	 SUP name )
…
objectclass ( 2.5.6.4 NAME 'organization'
	 DESC 'RFC2256: an organization'
	 SUP top STRUCTURAL
	 MUST o
	 MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
		 x121Address $ registeredAddress $ destinationIndicator $
		 preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
		 telephoneNumber $ internationaliSDNNumber $
		 facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $
		 postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )
…

Для рас­смот­рения мы взя­ли толь­ко один ат­ри­бут и один класс, со­дер­жа­щий этот ат­ри­бут. Опи­сание ат­ри­бу­тов на­чи­на­ет­ся с за­ре­зер­ви­ро­ван­но­го сло­ва attributetype. Да­лее в круг­лых скоб­ках идут ука­зания па­ра­мет­ров, обя­за­тель­ных и нет: OID (Object Identifier), имя ат­ри­бу­та NAME, ком­мен­та­рий DESC и SUP (за­ви­си­мо­сти от дру­гих ат­ри­бу­тов). Опи­сание ат­ри­бу­тов всегда пи­шут вы­ше опи­сания клас­сов. За­тем идет опи­сание клас­са, где ис­поль­зу­ет­ся этот ат­ри­бут.

Опи­сание клас­сов на­чи­на­ет­ся с за­ре­зер­ви­ро­ван­но­го сло­ва objectclass, а да­лее в круг­лых скоб­ках OID, имя клас­са NAME, ком­мен­та­рий, SUP, обя­за­тель­ный ат­ри­бут со зна­чением MUST, необя­за­тель­ные ат­ри­бу­ты MAY.

Где взять OID для на­пи­сания сво­их схем? Есть два ре­шения это­го во­про­са:

  • За­ре­зер­ви­ро­вать за сво­ей ор­ганиза­ци­ей оп­ре­де­лен­ный OID в со­от­вет­ст­вую­щих учреждениях.
  • Ис­поль­зо­вать спе­ци­аль­ный диа­па­зон зна­чений со­глас­но офи­ци­аль­ной до­ку­мен­та­ции (http://www.openldap.org/doc/admin24/schema.html).

Соз­да­в свою соб­ст­вен­ную схе­му, в фай­ле slapd.conf, в раз­де­ле include, необ­хо­ди­мо под­клю­чить свою схе­му по ана­ло­гии со стан­дарт­ны­ми и пе­ре­за­пустить служ­бу ка­та­ло­гов.

Что­бы до­ба­вить на­шу запись в ка­та­лог, не­об­хо­ди­мо вы­пол­нить ко­ман­ду ldapadd: 

# ldapadd -x -D “cn=Manager,dc=lw,dc=lan” -w secret -f test.ldif

А для про­смот­ра со­дер­жи­мо­го ка­та­ло­га мож­но вос­поль­зо­вать­ся ко­ман­дой ldapsearch: 

# ldapseach -x -D “cn=Manager,dc=lw,dc=lan” -W -b “dc=lw,dc=lan”

Как вид­но из при­ме­ра, бы­ли вы­бра­ны suffix dc=lw,dc=lan, где lan – со­кра­щение от ука­зания ти­па се­ти (под­ра­зу­ме­ва­лось локаль­ная сеть), а lw – со­кра­щение от LinuxWizard (один из немно­гих раз­ра­бот­чи­ков се­те­вых ре­шений на ба­зе тех­но­ло­гии служ­бы ка­та­ло­гов в России). Rootdn cn=Manager,dc=lw,dc=lan, а rootpw secret – па­роль ад­минист­ра­то­ра ка­та­ло­га.

По­ми­мо команд ldapsearch и ldapadd, есть еще ldapmodify (из­менение дан­ных ка­та­ло­га) и ldapdelete (уда­ление за­пи­сей).

Бо­лее де­таль­ное опи­сание всех команд мож­но по­смот­реть в до­ку­мен­та­ции на сай­те http://www.openldap.org/doc. От­ме­тим, что для всех команд на­до ука­зать, кем под­клю­чать­ся (в на­шем слу­чае –Manager’ом) и ку­да под­клю­чать­ся, точнее, в ка­кую вет­ку де­ре­ва ка­та­ло­га (-b "dc=lw,dc=lan", а мо­жет быть, "ou=people,dc=lw,dc=lan", ес­ли у поль­зо­ва­теля нет прав досту­па к бо­лее верхним вет­кам).

Что­бы ваш па­роль, ука­зан­ный в яв­ном ви­де, никто не уви­дел «из-за пле­ча», на эк­ране монито­ра за­ме­ня­ем па­ра­метр команд «-w secret» на «-W» и вво­дим па­роль при за­про­се.

Об­ра­тите внимание на то, что ко­ман­дой ldapsearch мож­но про­смот­реть со­дер­жи­мое не толь­ко служ­бы ка­та­ло­гов OpenLDAP, но и RHDS по­доб­ных служб ка­та­ло­гов, а так­же MS Active Directory. Так как в MS не всё как у лю­дей, па­ра­мет­ры ви­до­из­ме­не­ны, но смысл их тот же. При­ве­дем при­мер про­смот­ра со­дер­жи­мо­го AD: 

#ldapsearch -x -D Administrator@example.com -w password -b ‘’dc=example,dc=com’’ -h host

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

При­ве­ден­ные ша­ги хо­ро­ши для тех слу­ча­ев, когда необ­хо­ди­мо на­стро­ить все с ну­ля. Что же де­лать, когда су­ще­ст­ву­ет уже на­стро­ен­ная и ра­бо­таю­щая служ­ба ка­та­ло­гов? Для это­го име­ют­ся спе­ци­аль­ные скрип­ты для ми­гра­ции дан­ных. Су­ще­ст­ву­ют как стан­дарт­ные скрип­ты, так и сто­ронние. Стан­дарт­ные скрип­ты рас­по­ло­же­ны в ка­та­ло­ге /usr/share/openldap/migration/, а сто­ронние вхо­дят в со­став Windows to Linux Migration Toolkit (http://sourceforge.net/projects/w2lmt/files/w2lmt/w2lmt-0.3.1/w2lmt-0.3.1.tar.gz/download). Скрип­ты w2lmt очень по­лез­ны для ми­гра­ции с Active Directory.

В со­став w2lmt вхо­дят скрип­ты, на­пи­сан­ные на Perl, и фай­лы настройки для скрип­тов. Ос­нов­ные скрип­ты – это w2lmt-migrate-dns и w2lmt-migrate-smbauth. Они пред­на­зна­че­ны для пе­ре­но­са ин­фор­ма­ции DNS и па­ра­мет­ров ау­тен­ти­фи­ка­ции со­от­вет­ст­вен­но. Для ра­бо­ты нам по­на­до­бят­ся samba3 и smbldap-tools.

Ука­зав свои на­стро­ек сер­ве­ра AD в фай­лах настройки migrate-smbauth.conf и migrate-dns.conf, мож­но за­пус­кать скрип­ты: 

#./ w2lmt-migrate-dns -f migrate-dns.conf
#./ w2lmt-migrate-smbauth -f migrate-smbauth.conf

Под­робнее ис­поль­зо­вание скрип­тов w2lmt опи­са­но в книге Дэ­ви­да Ал­ле­на «Пе­ре­ход с Windows на Linux» и в ста­тье «За­ме­на Microsoft AD на OpenLDAP+Samba3» (http://linux.mkrovlya.ru/book/за­ме­на-microsoft-ad-на-openldapsamba3).

По­ми­мо яв­ной ми­гра­ции, есть воз­мож­ность соз­дания про­кси­ро­вания AD, мап­пин­га ат­ри­бу­тов. Т. е. все необ­хо­ди­мые служ­бы мож­но на­стро­ить на ра­бо­ту с OpenLDAP, а он, в свою оче­редь, бу­дет об­ра­щать­ся (пе­ре­на­прав­лять за­прос) к AD. Это ис­поль­зу­ет­ся в тех слу­ча­ях, когда без AD со­всем не обой­тись.

Ре­п­ли­ка­ция

OpenLDAP име­ет раз­лич­ные кон­фи­гу­ра­ции для соз­дания ре­п­ли­ки. Ранее, до вер­сии 2.4, су­ще­ст­во­вал ме­ханизм, по­зво­ляющий «глав­но­му» [master] сер­ве­ру по­лу­чать об­нов­ления служ­бы ка­та­ло­гов с раз­лич­ных дру­гих кли­ен­тов, а «вто­ро­сте­пен­ные» [slave] сер­ве­ра по­лу­ча­ли об­нов­ления толь­ко с «глав­но­го», ука­зан­но­го в кон­фи­гу­ра­ции. Струк­ту­ра ре­п­ли­ка­ции бы­ла стро­го оп­ре­де­ле­на, и лю­бая ба­за дан­ных мог­ла вы­пол­нять толь­ко од­ну роль: или master, или slave. На­чи­ная с вер­сии 2.4, OpenLDAP под­дер­жи­ва­ет раз­лич­ные то­по­ло­гии ре­п­ли­ка­ции. Вме­сто по­ня­тий master-сер­вер и slave-сер­вер ис­поль­зу­ют­ся «про­вай­дер» [provider] и «по­тре­би­тель» [consumer]. «Про­вай­дер» ре­п­ли­ци­ру­ет об­нов­ления ка­та­ло­га «по­тре­би­те­лю», а «по­тре­би­тель» по­лу­ча­ет об­нов­ления от «про­вай­де­ра». В от­ли­чие от стро­го оп­ре­де­лен­ных ро­лей master/slave, ро­ли provider/consumer не яв­ля­ют­ся стро­го оп­ре­де­лен­ны­ми. Об­нов­ления ре­п­ли­ка­ции, по­лу­чен­ные одним «по­тре­би­те­лем», мо­гут быть от­прав­ле­ны дру­го­му сер­ве­ру, та­ким об­ра­зом, «по­тре­би­тель» дей­ст­ву­ет од­но­вре­мен­но как «про­вай­дер». В ро­ли «по­тре­би­те­ля» мо­жет быть не толь­ко сер­вер LDAP, но и кли­ент LDAP.

Под­робнее об ис­поль­зо­вании и на­строй­ке раз­лич­ных то­по­ло­ги­ях ре­п­ли­ка­ции мож­но оз­на­ко­мить­ся в офи­ци­аль­ной до­ку­мен­та­ции (http://www.openldap.org/doc/admin24/replication.html), а мы для при­ме­ра рас­смот­рим syncrepl – это ме­ханизм ре­п­ли­ка­ции со сто­ро­ны «по­тре­би­те­ля». Кон­фи­гу­ра­ция syncrepl оп­ре­де­ля­ет­ся в фай­ле slapd.conf на «сер­ве­ре-по­тре­би­те­ле». На­чаль­ная ре­п­ли­ка­ция мо­жет быть вы­полнена за­пуском ме­ханиз­ма syncrepl без син­хрониза­ции cookie или за­груз­кой фай­ла LDIF, соз­дан­но­го как ре­зерв­ное ко­пи­ро­вание «про­вай­де­ра». Syncrepl ав­то­ма­ти­че­­ски син­хронизи­рует «по­тре­би­тель­скую» ко­пию с те­ку­щим со­дер­жи­мым «про­вай­де­ра», по­зво­ляя не оста­нав­ли­вать «про­вай­дер», во из­бе­жания несо­гла­со­ван­но­сти ко­пий. На сто­ро­не «про­вай­де­ра» в slapd.conf, ос­нов­ной кон­фи­гу­ра­ци­он­ный файл OpenLDAP, до­бав­ля­ем стро­ки 

database bdb
suffix dc=lw,dc=lan
rootdn dc=lw,dc=lan
directory /var/ldap/db
index entryCSN,entryUUID eq
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

Syncprov-checkpoint от­ве­ча­ет за тес­ти­ро­вание кон­троль­ных то­чек по­сле опе­ра­ции за­пи­си. 100 – это ко­ли­че­­ст­во опе­ра­ций, 10 – это ми­ну­ты. Syncprov-sessionlog от­ве­ча­ет за ве­дение ло­га, и па­ра­метр 100 – это раз­мер ло­га. На сто­ро­не «по­тре­би­те­ля» ос­нов­ной кон­фи­гу­ра­ци­он­ный файл slapd.conf вы­гля­дит так: 

database hdb
suffix dc=lw,dc=lan
rootdn dc=lw,dc=lan
directory /var/ldap/db
index objectclass,entryCSN,entryUUID eq
syncrepl rid=123
provider=ldap://provider.lw.lan:389
type=refreshOnly
interval=01:00:00:00
searchbase=”dc=lan,dc=lw”
filter=”(objectClass=organizationalPerson)”
scope=sub
attrs=”cn,sn,ou,telephoneNumber,title,l”
schemachecking=off
bindmethod=simple
binddn=”cn=syncuser,dc=lw,dc=lan”
credentials=secret

В этом при­ме­ре «по­тре­би­тель» бу­дет под­клю­чать­ся к «про­вай­де­ру» по пор­ту 389 для вы­полнения за­про­са син­хрониза­ции один разв день. Он бу­дет свя­зы­вать­ся [bind] как cn=syncuser,dc=lw,dc=lan с ис­поль­зо­ванием про­стой ау­тен­ти­фи­ка­ции по па­ро­лю «secret».

Управ­ление досту­пом cn=syncuser,dc=lw,dc=lan долж­но быть уста­нов­ле­но на про­вай­де­ре. Для за­пуска син­хрониза­ции не надо пе­ре­за­гру­жать «про­вай­де­ра» – доста­точ­но за­пустить «по­тре­би­те­ля».

Сис­те­мы управ­ления

Ад­минист­ри­ро­вание служ­бы ка­та­ло­гов OpenLDAP – доста­точ­но слож­ная за­да­ча для че­ло­ве­ка, толь­ко что по­зна­ко­мив­ше­го­ся с ней. Для уп­ро­щения за­дач ад­минист­ри­ро­вания су­ще­ст­ву­ют раз­лич­ные сис­те­мы управ­ления, на­при­мер, Ebox, GOsa, Webmin, phpLDAPadmin и дру­гие. Их основ­ная за­да­ча – из­ба­вить вас от пря­мо­го об­ра­щения к ат­ри­бу­там и объ­ект­ным клас­сам. Со­гла­си­тесь, так го­раз­до про­ще!

Все сис­те­мы управ­ления мож­но раз­де­лить на три ка­те­го­рии:

  • Низ­ко­уровневые сред­ст­ва ре­дак­ти­ро­вания дан­ных
  • Сис­те­мы управ­ления, ин­тег­ри­ро­ван­ные в служ­бу ка­та­ло­гов
  • Сис­те­мы управ­ления с гра­фи­че­­ским ин­тер­фей­сом

Рас­смот­рим их под­робнее. К низ­ко­уровневы­ем сред­ст­вам ре­дак­ти­ро­вания дан­ных от­но­сят­ся WebMin, phpLDAPadmin, Lume. Осо­бен­ность дан­ных средств за­клю­ча­ет­ся в том, что у вас нет ог­раничений в управ­лении служ­бой ка­та­ло­гов, но вы опять же на­пря­мую свя­за­ны с ат­ри­бу­та­ми и объ­ект­ны­ми клас­са­ми. Ин­тег­ри­ро­ван­ные сис­те­мы управ­ления от­но­сят­ся к Red Hat Directory Server и по­доб­ных ему (Centos DS, 389 DS). Здесь су­ще­ст­ву­ют две реа­ли­за­ции сис­те­мы управ­ления: web-ин­тер­фейс и кли­ент-сер­вер­ная реа­ли­за­ция на Java. Как пра­ви­ло, ин­тег­ри­ро­ван­ные сис­те­мы управ­ления да­ют ма­ло воз­мож­но­стей и неудоб­ны в ­поль­зо­вании для тех, кто не привык к служ­бе ка­та­ло­гов. Гра­фи­че­­ские сис­те­мы по­зво­ля­ют на­гляд­но ви­зуа­ли­зи­ро­вать объ­ек­ты, на­хо­дя­щие­ся в LDAP-ка­та­ло­ге, и из­бав­ля­ют вас от по­ис­ка необ­хо­ди­мых ат­ри­бу­тов и объ­ект­ных клас­сов при соз­дании за­пи­сей. Ча­ще все­го гра­фи­че­­ская сис­те­ма управ­ления пред­став­ля­ет со­бой не что иное, как web-ин­тер­фейс к служ­бе ка­та­ло­га.

В хо­де ана­ли­за раз­лич­ных су­ще­ст­вую­щих гра­фи­че­­ских сис­тем управ­ления мож­но от­дель­но вы­де­лить GOsa (рис. 1). Эта гра­фи­че­­ская сис­те­ма управ­ления про­ста в ис­поль­зо­вании и на­строй­ке. Вы­бор сис­те­мы управ­ления осно­вы­вал­ся по та­ким кри­те­ри­ям, как

  • кон­троль досту­па в ин­тернет (DHCP, DNS, Squid);
  • управ­ление поч­то­вым сер­ве­ром и се­те­вым фильт­ром;
  • под­держ­ка пла­ги­нов и те­ле­фонии;
  • тон­кий кли­ент (FAI);
  • Posix- и Kolab-ак­ка­унт.

По­ми­мо GOsa, су­ще­ст­ву­ет еще ряд раз­лич­ных сис­тем управ­ления, на­при­мер, Ebox (рис.2). Важ­но от­ме­тить, что ото­бра­жение объ­ек­тов в GOsa про­ис­хо­дит толь­ко в том слу­чае, ес­ли в их опи­сании при­сут­ст­ву­ет ка­кой-ли­бо из спе­ци­аль­ных клас­сов, за­ре­ги­ст­ри­ро­ван­ных в схе­мах GOsa. Та­кой под­ход по­зво­ля­ет ис­поль­зо­вать дру­гие про­ек­ты, ра­бо­таю­щие с LDAP-ка­та­ло­гом, без су­ще­ст­вен­ной их мо­ди­фи­ка­ции. Со­от­вет­ст­вен­но, ес­ли планиру­ет­ся ис­поль­зо­вать ба­зу LDAP толь­ко для ад­минист­ри­ро­вания поль­зо­ва­тель­ских учет­ных за­пи­сей в локаль­ной се­ти и для ин­те­гра­ции с Samba, то луч­ше­го сред­ст­ва ад­минист­ри­ро­вания про­сто не най­ти. Из рис. 3 вид­но, что знание ат­ри­бу­тов и объ­ект­ных клас­сов необя­за­тель­но для соз­дания ка­кой-ли­бо за­пи­си.

Для ра­бо­ты GOsa в ди­ст­ри­бу­ти­ве CentOS необ­хо­ди­мо об­но­вить PHP до вер­сии 5.2. Это мож­но сде­лать, до­ба­вив ре­по­зи­то­рий ius. Для уста­нов­ки и на­строй­ки служ­бы ка­та­ло­гов OpenLDAP и сис­те­мы управ­ления GOsa мож­но восполь­зо­вать­ся скрип­том gosa.sh, ко­то­рый вы най­де­те на дис­ке. Что же имен­но де­ла­ет наш скрипт?

Для на­ча­ла соз­да­ет­ся файл ius.repo, ко­то­рый нам по­на­до­бит­ся при об­нов­лении PHP. По­ми­мо PHP, необ­хо­ди­мо уста­но­вить perl-LDAP, perl-Crypt-SmbHash, httpd и, как са­мо со­бой ра­зу­мею­щее­ся, служ­бу ка­та­ло­гов OpenLDAP. По­сле че­го сме­ло мож­но уста­но­вить сис­те­му управ­ления GOsa. Скрипт ска­чи­ва­ет и уста­нав­ли­ва­ет 3 па­ке­та: gosa-2.6.9‑1.noarch.rpm, gosa-schema-2.6.9‑1.noarch.rpm, gosa-help-en-2.6.9‑1.noarch.rpm. Так как в стан­дарт­ном па­ке­те gosa-schema-2.6.9‑1.noarch.rpm нет схе­мы gosa-custom.schema, ко­то­рая со­дер­жит по­лез­ные ат­ри­бу­ты и клас­сы, соз­да­дим его са­ми.

По­сле уста­нов­ки необ­хо­ди­мых па­ке­тов мож­но при­сту­пать к на­строй­ке OpenLDAP. Для это­го за­пи­шем в файл slapd.conf па­ра­мет­ры: suffix, rootdn, rootpw, а так­же необ­хо­ди­мые ин­дек­сы для GOsa. Те­перь поч­ти всё го­то­во; оста­лось за­дать па­ра­мет­ры PHP для сис­те­мы управ­ления GOsa, от­ре­дак­ти­ровав файл php.ini. Для ра­бо­то­спо­соб­но­сти все­го, что мы де­ла­ли, за­пуска­ем служ­бу ldap и служ­бу httpd. Фи­наль­ный штрих – от­кры­ва­ем Mozilla Firefox, в ад­рес­ной стро­ке вво­дим http://localhost/gosa и за­да­ем необ­хо­ди­мые па­ра­мет­ры «кон­фи­гу­ра­то­ру» GOsa. По­ми­мо ис­поль­зо­ван­ных здесь трех па­ке­тов GOsa, су­ще­ст­ву­ет немало пла­ги­нов для хранения дан­ных DNS, Samba, Squid и т. д. Все они доступ­ны по ад­ре­су http://oss.gonicus.de/pub/gosa/, где мож­но ска­чать ис­ходники или па­ке­ты для RedHat-ди­ст­ри­бу­ти­вов и для Debian-ди­ст­ри­бу­ти­вов.

Итог

В ито­ге мы име­ем служ­бу ка­та­ло­гов с гра­фи­че­­ской сис­те­мой управ­ления, по­зво­ляю­щую хранить всю необ­хо­ди­мую ин­фор­ма­цию о ре­сур­сах се­ти. Имен­но это и яв­ля­ет­ся основ­ной за­да­чей лю­бой служ­бы ка­та­ло­гов. Дан­ное ре­шение на те­ку­щем эта­пе не смо­жет за­менить AD, т. к. для это­го необ­хо­ди­мо на­стро­ить служ­бы ау­тен­ти­фи­ка­ции (PAM), фай­ло­во­го сер­ве­ра (Samba), поч­то­во­го сер­ве­ра (Postfix и Dovecot), про­кси-сер­ве­ра (Squid) и т. д. Дан­ный этап на­строй­ки бу­дет рас­смот­рен в сле­дую­щей ста­тье – «Служ­бы, ко­то­рые мо­гут ау­тен­ти­фи­ци­ро­вать­ся по LDAP».

Плю­сы:

  • От­кры­тость ре­шения и рас­ши­рен­ный функ­цио­нал.
  • Воз­мож­ность пол­ной или час­тич­ной за­ме­ны AD, а сле­до­ва­тель­но, воз­мож­ность пря­мой эко­но­мии в руб­лях.

Ми­ну­сы:

  • Глав­ный и един­ст­вен­ный – от­сут­ст­вие груп­по­вых по­ли­тик.

Дан­ной про­бле­ма­ти­кой ныне занима­ет­ся ка­фед­ра от­кры­тых ин­фор­ма­ци­он­ных тех­но­ло­гий и ин­фор­ма­ти­ки Пе­тер­бург­ского го­сунивер­си­те­та аэро­косми­че­­ско­­го при­бо­ро­строения, где ве­дут­ся раз­ра­бот­ки соз­дания ана­ло­га груп­по­вых по­ли­тик на ОС GNU/Linux и дру­гих ре­ше­ний на ба­зе СПО и служ­бы ка­та­ло­гов.

Служ­ба ка­та­ло­гов: Как это ра­бо­та­ет?

Для бо­лее яс­но­го понимания, что же та­кое служ­ба ка­та­ло­гов, мож­но при­вес­ти сравнение служ­бы ка­та­ло­гов OpenLDAP с те­ле­фон­ным или ад­рес­ным спра­вочника­ми (в анг­лоя­зыч­ном ва­ри­ан­те – ка­та­ло­га­ми, directory). Ес­ли вам по­на­до­би­лось най­ти те­ле­фон Ива­на Ива­но­ви­ча Ива­но­ва, то, от­крыв те­ле­фон­ный спра­вочник на странице N, вы най­дё­те ис­ко­мое. Но вот неза­да­ча! Пред­ставь­те, что на од­ной странице со­всем ря­дом ока­за­лось сра­зу два, а мо­жет, и три Ива­на Ива­но­ви­ча Ива­но­вых! Что же де­лать? Как оп­ре­де­лить­ся с тем, кто нам ну­жен?

Имен­но для та­кой си­туа­ции и вво­дит­ся по­ня­тие уникаль­но­го имени – distinguished name (dn). Distinguished name до­слов­но пе­ре­во­дит­ся как от­ли­чи­тель­ное имя; со­от­вет­ст­вен­но, его на­зна­чение – от­ли­чать од­ну запись от дру­гих за­пи­сей. Лю­бая служ­ба ка­та­ло­гов стро­ит­ся на уникаль­ных име­нах ре­сур­сов се­ти и опи­сании их свойств. Пре­иму­ще­ст­во служ­бы ка­та­ло­гов в том, что мы мо­жем за­пи­сы­вать не толь­ко фа­ми­лию че­ло­ве­ка (на­звание ком­пании, ор­ганиза­ции) и его те­ле­фон, а всё, что по­­же­­ла­­ем! Для соз­дания за­пи­си о ком­пании доста­точ­но ука­зать уникаль­ное имя и ис­поль­зо­вать объ­ект­ный класс (objectClass) organization с вы­бран­ны­ми в нем ат­ри­бу­та­ми (attribytetype).

За­пись в те­ле­фон­ном спра­воч­ни­ке: 

Organization Name: Acme Services
Street Address: 123 West First Street
City: Chicago
State: Illinois
Postal Code: 60616-1234
Country: USA
Phone Number: +1 773 555 8943
Phone Number: +1 800 555 9834

За­пись в служ­бе ка­та­ло­гов: 

dn: o=Acme Services, l=Chicago, st=Illinois, c=US
o: Acme Services
postalAddress: 123 West First Street
l: Chicago
st: Illinois
postalCode: 60616-1234
c: US
telephoneNumber: +1 773 555 8943
telephoneNumber: +1 800 555 9834
objectclass: organization

Итак, мы соз­да­ли уникаль­ную запись об ор­ганиза­ции с ин­фор­ма­цией из те­ле­фон­но­го спра­вочника. Это и есть осно­ва служ­бы ка­та­ло­гов – уникаль­ные име­на (DN), опи­сан­ные с помощью клас­сов (objectClass) и ат­ри­бу­тов (attributetype).

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF142:OpenLDAP&oldid=14079»
Персональные инструменты
купить
подписаться
Яндекс.Метрика