Материал из Linuxformat.

Содержание 1 OpenLDAP как за­ме­на ActiveDirectory 1.1 Что та­кое OpenLDAP? 1.2 Ус­та­нов­ка и на­строй­ка 1.3 Ре­п­ли­ка­ция 1.4 Сис­те­мы управ­ления 1.5 Итог 1.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).