LDAP
OpenLDAP
Содержание
Установка
sudo -s apt-get installl slapd ldap-utils nmap php5-ldap
Настройка OpenLDAP
nano /etc/ldap/slapd.conf
Найдите в файле конфигурации параметр loglevel и измените его значение следующим образом
loglevel 296
Теперь нам нужно получить hesh нашего пароля к slapd. Несмотря на то что мы уже задали пароль доступа к ldap - сменим его
#slappasswd New
Для нас важна строчка символов, выданная утилитой slappasswd после смены пароля. Скопирейте ее в текстовый редактор и сохраните - она понадобится при дальнейших действиях.
Настроим ldap на нашу доменную зону
nano /etc/ldap/slapd.conf
# The base of your directory in database #1
suffix "dc=ntc, dc=local"
#suffix "dc=example, dc=com"
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn "cn=admin,dc=ntc,dc=local"
rootpw {SSHA}a0D718g9uULdD0u/tbMHA9wRlmgV+OUu
Добавим набор параметров по умолчанию для приложений работающих с LDAP.
nano /etc/ldap/ldap.conf
ldap_version 3 BASE dc=ntc, dc=local URI ldap://192.168.10.25:389
SIZELIMIT 0 TIMELIMIT 0 DEREF never
Создаем базу ldif и импортируем ее в нашь ldap
nano /etc/X11/base.ldif
dn:dc=ntc,dc=local objectClass:dcObject objectClass:organization o:ntc dc:ntc
dn:cn=admin,dc=ntc,dc=local objectClass:organizationalRole cn:admin
Будте внимательны с буквами и пробелами. ldif чувствителен к синтаксису файла.
Импортируем данные в ldap
#ldapadd -x -W -D cn=admin,dc=ntc,dc=local -d /etc/ldap/base.ldif Enter password: XXXXXX ....
И проверим верно ли были внесены данные в базу ldap
#ldapsearch -x
phpLdapAdmin
Загружаем phpldapadmin-1.0.2.zip
Для коректной работы phpmyadmin вам потребуется внести значения параметра dc в конфигурационный файл.
#nano /var/www/phpldapadmin/config/config.php
Замените все dc=exaples,dc=com на ваше имя корневого домена
Для доступа к web интерфейсу управления LDAP нам потребуется сделать символьную ссылку на диреторию с установленным phphldapadmin
#ln -s /usr/share/phpldapadmin /var/www/phpldapadmin
Для доступа используйте
login: cn=admin,dc=ntc,dc=local Password:XXXX
Настройка клиентов
http://www.yolinux.com/TUTORIALS/LDAP_Authentication.html
This will create the file: /etc/ldap.conf
host XXX.XXX.XXX.XXX - IP address of LDAP server base dc=domain,dc=org ssl no pam_password md5
If using older SGI MIPS/IRIX systems in the mix you may have to use "clear" instead of "md5".
File: /etc/nsswitch.conf ..
... passwd files ldap shadow files ldap group files ldap ... ..
[Potential Pitfall]: You may have to reboot in order for LDAP authentication to begin.
[Potential Pitfall]: If using the Sun One LDAP authentication server, note that any entry for the following attributes will result in the requirement that the Linux user change their password each and every time they login. (annoying) Set the following LDAP attributes to blank (not zero): shadowmin shadowmax shadowwarning
[Potential Pitfall]: The user IDs (uid) and group IDs (gid) are cached by the Linux client after authenticating to the LDAP server. If changes are made to the LDAP directory you may have to reboot the client system to pick up the changes. This is also true for NIS authentication.
Note: If using the Linux GUI desktop and mounting Linux home directories to an NFS server you may have to mount with the option "nolock". This will be required if the NFS server does not support rpc.statd or rpc.lockd locking daemons which support NFS file locking services.
File: /etc/fstab
... nfs-server:/export/home /export/home nfs rw,soft,bg,nolock 0 0 ...
Also be sure to copy essential files and directories from /etc/skel/...which enable desktop use.
LDAP Authentication for Windows 2000
Addition:
Authenticate MS/Windows using PGina: http://pgina.xpasystems.com/
Downloads: http://sourceforge.net/project/downloading.php?group_id=53525&use_mirror=kent&filename=pGina-1.8.8.zip&68517626
i.e. download pGina: pGina170a.exe
Run pGina170a.exe to install. Install to C:\pGina and accept defaults.
Download LDAP Auth: Downloads: http://pgina.xpasystems.com/plugins/ldapauth.php Download instaler i.e.: ldapauth12.exe Run to install.
Configure pGina: Select: Start + Programs + pGina + Configuration Tool Pluggin Path: C:\pGina\plugins\ldapauth\ldapauth_plus.dll Accept rest of defaults. Select configure plugin button:
[LDAP configure screenshot] LDAP Server: IP-address-goes-here Port: 389 (default) PrePend: uid= Append: ou=people,dc=megacorp,dc=com Admin User: "cn=AdminManager,dc=megacorp,dc=com" Admin password: *******
The "Admin User" and "Admin Pass" are not required for "Map Mode". A bind using the user login/password will take place if the Admin user/ password are omitted.
Select radio button "Map Mode" then select "OK". (Panel closes) Select Save + Exit (On main config panel) Uses LDAP "Search mode".
Select option "Scramble Passwords on Logout". This forces LDAP authentication for each login. After an initial login, the login/password become resident locally so that subsequent logins are authenticated locally. This option forces a scramble of the password upon logout forcing Windows/pGina to authenticate with the LDAP server and NOT locally.
Optional test: Download plugin_tester.exe from http://pgina.xpasystems.com/plugins/ldapauth.php LDAP_authentication.jpg
Select: Start + PRograms + pGina + Plugin tester Pluggin Path: C:\pGina\plugins\ldapauth\ldapauth_plus.dll Use login and passsword to test.
Reconfigure Windows 2000 not to authenticate against PDC:
- Right click on "My Computer" + System Properties
- Select "Network Identification" tab + "Properties" button.
- Select "Workgroup" radio buton and remove workgroup.
- Reboot and you are ready to login with LDAP authentication.
Note:
Do not use false (which can't be resolved) or a real domain (real or real but fails). pGina recognizes local logins if the login id can not be found in the LDAP directory. pGina does not support "roaming profile". To remove pGina: Start + Control Panel + Add/Remove program + select pGina
Links: SysAdmin: pGina
Способ 2
http://openskateshop.com/index.php?WindowsConfig
pGina Configuration
1. Get pGina components from https://ninja.9star.com/tech/pGina 2. Download Ninestar CA cert to desktop: https://ninja.9star.com/public/ninestar-ca.crt 3. Doubleclick it, click "Install...", click "Place all certificates in the following store" 4. Click "Browse", click "Show physical stores", click "Trusted Root Certificate Authorities", click "Local Computer", click "OK" 5. Click "Finish" "OK" etc. 6. Install PGina... 7. Install logo (from ninja, with the pGina files) in c:\pGina\logo.bmp
1. Configure as such:
Login Window:
* Load logo from c:\pGina\logo.bmp * Set window title: "Ninestar Windows Login" * Set message of the day to: "Welcome to %machine%. Login with your Ninestar email username and password" * Click "Hide plugin info"
Locked Window:
* Make sure ALL checkboxes are checked, including "Do not allow password change" and "Allow administrator to unlock"... do not check "Allow any user to unlock..."
Account Interaction:
* Should be fine by default... check "Keep profile" and "Force login", uncheck all else
Domain Interaction:
* Should be fine by default... all unchecked
Advanced:
* Fine, unchecked all
Profile:
* Groups, set "Power Users;Users"
1. Close Configuration Tool 2. Install LDAPAuth 3. Relaunch pGina configuration tool from "Start"->Programs->pGina menu 4. On Plugin screen, select "Browse", c:\pGina\plugins\ldapauth\ldapauth_plus.dll 5. Click configure button, and set the following:
* Ldap Method: Map Mode * Ldap Server: ldap.lan (to use the local ldap, or ldap.9star.com to use the central server (be careful)) * Use SSL: checked * Port: 636 * Admin user: uid=reader,ou=People,dc=9star,dc=com * Admin password: oakley *this is basically public * Prepend: uid= * Append: ou=People,dc=9star,dc=com
1. Click on "User Configuration" tab
* Admin Groups, add: cn=Admin,ou=Access,dc=9star,dc=com
1. Click on "Password Configuration" tab
* Check "Disable Change Password"
1. Click "OK" to save changes.... it takes a second, don't fret 2. Close pGina configuration tool 3. Launch pGina Plugin Tester tool 4. Load plugin, try logging in 5. If successful, then great! Throw away files you downloaded, and restart the machine.
Samba and LDAP
Samba 3.0 can authenticate using LDAP. Download and compile OpenLDAP (even if you are using Sun ONE or some other LDAP server) and the berkley DB source. These libraries will be required when compiling Samba 3.0 for use with LDAP. Compile Samba with the configure option "--with-ldapsam". (./configure --prefix=/opt/samba --with-ldapsam)
We use pGina for login authentication so that all LDAP security rules are followed. (i.e. password length, duration between changes, reuse of passwords, ...) If MS/Windows authenticating with Samba (which in turn is authenticating with LDAP), then many of the LDAP password rules will not be supported. It is for this reason we use pGina. After SAMBA 3.0.7 was available, many of the rules required and supported in pGina are available using SAMBA and the native MS/Windows login. (i.e. Lockout after 5 failed logins) The login/password is held by the MS/windows OS and will be used when accessing Samba shares. Samba will then authenticate the access to the shared drive using LDAP. This replaces the need for a local Samba password database. (created with smbpasswd) In this configuration we did not use the Samba PDC.
File snippet: smb.conf
... passwd backend = ldapsam: ldap://Ip-address-of-LDAP-server/ ldap admin dn = "cn=sambaadmin, ou=people" ldap suffix = "dc=megacorp,dc=com" ldap user suffix = "ou=people" ...
Note: DNS resolvable names are required for all client and server computers which are part of the Samba domain.
Links: Samba 3.0 LDAP Howto
SGI IRIX/MIPS Authentication and Host Lookup Using LDAP:
IRIX OS releases and LDAP/PAM: IRIX version PAM comments
6.5.21- LDAP support
No PAM support.
6.5.22 LDAP support
Limited PAM support. Many of the utilities and services were not supported by PAM.
6.5.23+ LDAP support
Full PAM support.
IRIX 6.5.21 configuration:
Client configuration file: /var/ns/ldap.conf
; SECURITY security ssl - Options are none or ssl cipher RSA_RC4_40_MD5 domain - An empty domain identifies the local domain ; LDAP server specifications
server XXX.XXX.XXX.XXX - IP address of LDAP server
version 2 - Open LDAP is considered V2 while Sun One considers themselves to be V3
base "dc=sub-Domain,dc=domain,dc=com"
scope subtree - Options are subtree, onelevel or sbase
password-hash {CRYPT}
binddn "cn=AdminManager,dc=sub-Domain,dc=domain,dc=com"
bindpwd secret-password
Note: The "bindpwd" is in clear text and NOT encrypted. When connecting to the server it will use a clear text password. This is required on IRIX 6.5.20. {Potential Pitfall]: If no binddn/bindpwd are supplied in this configuration file, then your whole system is opened up for login without authentication. It may look like you logged in with a password but a correct one will not be required. BEWARE! See "man ldap.conf" for more information. LDAP Server: slapd.conf (Linux: /etc/openldap/slapd.conf) database ldbm
password-hash {CRYPT}
suffix "dc=sub-Domain,dc=domain,dc=com"
rootdn "cn=AdminManager,"dc=sub-Domain,dc=domain,dc=com"
rootpw {CRYPT}yDtKCHnyyDtKC
Notes: Only crypt passwords are allowed in the IRIX implementation. Don't use MD5. Note the associations: Server attribute Client attribute
suffix base rootdn binddn rootpw (crypt) bindpwd (clear text)
Client nsswitch: /etc/nsswitch.conf hosts: ldap files nis dns
passwd: ldap files(compat) [notfound=return] nis
Note:
To reactivate new settings:
[root]# nsadmin flush [root]# nsadmin restart
IRIX 6.5.22+ configuration:
Same as above except that the ldap.conf file location is /etc/ldap.conf and the entries "binddn" and "bindpwd" are not required. The entries in /etc/ldap.conf for IRIX 6.5.22+ resemble those for Linux. Bind is done using anonymous bind.
Sun SOLARIS Authentication and Host Lookup Using LDAP:
Configure with the Sun SOLARIS admin tool: ldapclient
IBM/AIX Authentication and Host Lookup Using LDAP:
System Authentication for AIX (and Linux)
Encryption scheme:
It is important to choose the same encryption scheme across platforms. By default Solaris uses CRYPT (DES: Data Encryption Standard) but allows multiple schemes, Redhat and FreeBSD (V4.2+) use MD5 and Suse uses Blowfish.
Encryption Hash prefix
MD5 $1$ plus 12 character salt followed by encrypted password.
Blowfish (blf) $2$ or $2a$ plus 16 character salt followed by encrypted password.
CRYPT (standard DES) Two character salt at beginning of hash followed by encrypted password. Does NOT start with "$". (No consistent prefix.)
CRYPT (extended DES) Nine character salt at beginning of hash followed by encrypted password. Does NOT start with "$". (No consistent prefix.)
Configuration file where encryprion scheme is set: OS Config file
RedHat Linux /etc/libuser.conf
/etc/pam.d/system-auth
(configured using installation)
FreeBSD /etc/login.conf
/etc/auth.conf
/etc/master.passwd
Solaris /etc/security/policy.conf
See: CRYPT_ALGORITHMS_ALLOW
Multiple encryption schemes allowed concurently.
YoLinux.com LDAP Tutorials:
Deploying OpenLDAP - Directory Installation and configuration (V1.2 and 2.x)
Apache and LDAP authentication
OpenLdap 2.x - SLAPD and LDIF configuration
OpenLdap 1.2 - SLAPD and LDIF configuration
LDAP Authentication and user passwords - Adding password protection to LDAP directory.
(Note: This is authentication for the user to access the LDAP database and not using LDAP to authenticate applications)
OpenLdap 1.2 Group security example - SLAPD and LDIF configuration
Create a new custom object by extending the inetOrgPerson schema
OpenLDAP 2.x Schema Extension to support MS/Outlook, Netscape 4.5+, PAM,.. (GILSE)
LDAP admin support scripts and code snippets
Mapping LDAP inetOrgPerson object attributes to Palm Pilot Desktop CSV exchange file
aWebDap - A simple, flexible web front end supporting multiple domains designed for the non-technical user. My favorite, but hey, I wrote it!!
Настройка клиентских станций на Ubuntu
LDAPClientAuthentication Introduction
This page is intended for anyone who wants to enable an Ubuntu client to authenticate on an existing OpenLDAP server. For more details on the server installation part see OpenLDAPServer.
For authenticating on a Sun Java Enterprise System Directory Server should consult the SunLDAPClientAuthentication page. Installation
Install the following packages: libpam-ldap libnss-ldap nss-updatedb (see InstallingSoftware). Note that you have to enable the universe repositories for this.
libpam-ldap to allows for _authentication_ via LDAP. libnss-ldap allows _session_ information via LDAP. That's why /etc/libnss-ldap.conf /etc/pam_ldap.conf have such similar structures.
During installation, you will be asked the following questions:
*
The address of the LDAP server used. You can also use a fully qualified domain name here. For example: ldap.example.com *
The distinguished name of the search base. For example dc=example,dc=com
*
The LDAP version to use. You usually would choose 3 here. *
If your database requires logging in. You would usually choose no here. *
If you want to make configuration readable/writeable by owner only. A no should be the answer to this. *
A Dialog is displayed explaining it cannot manage nsswitch.conf automatically. Just select OK. *
If you want the local root to be the database admin. You would usually choose yes here. *
Again If your database requires logging in. You would usually choose no here. *
Your root login account. For example: cn=manager,dc=example,dc=com *
Your root password. *
After, a dialog explaining the different encryption methods to specify the encryption method to use before sending your password. exop is usually a good choice.
The above steps might vary a bit depending on the Ubuntu distribution used. When you want to restart the configuration you can use dpkg-reconfigure for both libpam-ldap and libnss-ldap packages.
When finished configuring you will need to double check the data in /etc/libnss-ldap.conf. Especially the 'host' entry which doesn't accept URI. Better is to use the 'uri' entries and comment out the 'host'. Configuration
After the installation of the necessary packages you will need to configure the Name Service and PAM. Name Service
In /etc/nsswitch.conf replace compat with files ldap for both the passwd and group entries so you get something like this:
passwd: files ldap group: files ldap
There is a full example provided in the documentation of libnss-ldap: /usr/share/doc/libnss-ldap/examples/nsswitch.ldap
Now you can test the configuration:
$ getent passwd
or
$ getent group
You should see lines that look like they've come straight out of /etc/passwd. These are the lines 'published' by your LDAP server. If you do, the Name Service (NSS) side of the job is done. If not, check /etc/libnss-ldap.conf for typos.
If your setup requires a password to connect to the LDAP server, don't forget to put that password into /etc/libnss-ldap.secret.
BUG ALERT: Make sure /etc/libnss-ldap.conf has "bind_policy soft". If it's not there, a nasty bug with udev can arise at boot-time.
It's also a good idea to shorten the timeouts there.
Don't use sudo when editing this file or leave it open while testing. If you save with a typo, it could mean that you can't access your server anymore. PAM
Four central files control PAM's use of LDAP: common-account, common-auth, common-password and common-session. They're in /etc/pam.d.
For details, see the pam(7) manpage.
Edit /etc/pam.d/common-account to look like this:
account sufficient pam_ldap.so account required pam_unix.so
Edit /etc/pam.d/common-auth to look like this:
auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure use_first_pass
Edit /etc/pam.d/common-password to look like this:
password sufficient pam_ldap.so password required pam_unix.so nullok obscure min=4 max=8 md5
PAM: Stronger Passwords (Optional)
You might be interested in libpam-cracklib (see InstallingSoftware).
To activate it you'll need to edit /etc/pam.d/common-password:
password required pam_cracklib.so retry=3 minlen=6 difok=3 password sufficient pam_ldap.so use_authtok password required pam_unix.so use_authtok use_first_pass
Edit /etc/pam.d/common-session and add pam_ldap.so, like this:
session optional pam_foreground.so session sufficient pam_ldap.so session required pam_unix.so
PAM: Home directory creation (optional)
Edit the common-session file again:
session required pam_unix.so session required pam_mkhomedir.so skel=/etc/skel/ session optional pam_ldap.so session optional pam_foreground.so
Option: Caching Name Service directories
[(Geert) This needs editing, I can't make it work.] [(Geert) nscd can be used, but didn't work either.]
In order to prevent network slowdown or outage from preventing user name lookup and thus login, use the nss-updatedb package to create a local database of the user names. You first need to populate the database for the first time and then create a scheduled job to update the database at a random time each hour (the random time means that all clients are no hitting the LDAP server simultaneously for updates). Run:
$ sudo nss_updatedb ldap
nss_updatedb is storing the cache in /var/lib/misc/.
Now you need to create a script to update the database randomly.
Create a script called nssupdate.sh in /etc/cron.hourly/ and make it executable. It should contain the following:
#!/bin/bash
LOCK=/var/run/auth-update.cron
[ "$1" != "0" ] && [ -f $LOCK ] && [ -d /proc/"$(cat $LOCK)" ] && exit 0
echo $$ > $LOCK
RANGE=3600
[ "$1" != "" ] && RANGE=$1
SLEEP=$RANDOM
[ "$RANGE" != "0" ] && let "SLEEP %= $RANGE" || SLEEP=0
sleep $SLEEP
go=true
while $go; do
/usr/sbin/nss_updatedb ldap
[ $? -eq 0 ] && go=false
[ "$go" == "true" ] && sleep 10
done
rm $LOCK
exit 0
To make actual use of the cached data you will need to edit /etc/nsswitch.conf like this:
passwd: files ldap [NOTFOUND=return] db group: files ldap [NOTFOUND=return] db
This means:
*
look first in the local files (/etc/passwd and /etc/group) *
if not found, use LDAP *
when LDAP does not have user information, exit and return nothing (this is the [NOTFOUND=return] directive) *
if the LDAP server was not reachable, proceed with using the cached data
https://help.ubuntu.com/community/LDAPClientAuthentication
Дополнительные ссылки
http://linux.mkrovlya.ru/book/export/html/63
Оригинальная статья
http://wiki.ubuntu-forum.de/index.php/OpenLDAP
OpenLDAP
Inhaltsverzeichnis [Verbergen]
1 Allgemeines 2 Installation 3 OpenLDAP konfigurieren 4 phpLDAPadmin 4.1 User in phpLDAPadmin anlegen 4.1.1 OU anlegen 4.1.2 Testperson anlegen 4.2 LDAP im Thunderbird einrichten
[bearbeiten] Allgemeines
OpenLDAP ist ein Verzeichnisdienst wie das ActiveDirectory in der Windows-Server-Welt. OpenLDAP ist dabei frei und kostenfrei erhältlich. An dieser Stelle wird die Konfiguration eines OpenLDAP-Servers für die Verwendung als Adressbuch beschrieben, was aber natürlich lange nicht alles ist, was LDAP kann.
Vorraussetzung für das Tutorial ist, dass Ihr mit nano umgehen könnt und Ubuntu mit Apache2 und PHP5 installiert habt (vorzugsweise Ubuntu 6.06.1 LTS Server).
[bearbeiten]
Installation
Zunächst startet Ihr ein Terminal auf Eurem Server und wechselt in den SuperUser-Modus, damit Ihr nicht dauernd "sudo" vor jedem zweiten Befehl schreiben müsst. sudo -s
Die Quellen in /Etc/apt/sources.list müssen vorab freigeschaltet werden. apt-get install slapd ldap-utils nmap php5-ldap
Das war auch schon die Grundinstallation. Während der Installation von slapd werdet Ihr nach einem Passwort gefragt. Merkt Euch dieses gut! :)
[bearbeiten]
OpenLDAP konfigurieren
Um herauszufinden, ob der Server auch gestartet wurde, benötigt man das eben installierte nmap: nmap localhost | grep ldap
Es sollte nun folgendes angezeigt werden: 389/tcp open ldap
Nun richten wir das Loglevel ein. Der Wert 296 ist für uns ideal, denn dort werden Resultate, Suchfilter und Verbindungsmangement geloggt. nano /etc/ldap/slapd.conf
Sucht (Strg+W) nach dem Stichwort "loglevel" und tragt dort die 296 ein
- Read slapd.conf(5) for possible values
loglevel 296
Nun die Datei speichern (Strg+O).
In der Datei /etc/syslog.conf tragt Ihr nun noch folgendes ein (unten drunter):
- local4.debug /var/log/slapd.log
Als nächstes generieren wir einen SSHA-Schlüssel, den wir gleich brauchen:
- slappasswd
New password: xxxxxx Re-enter new password: xxxxxx {SSHA}4GMPGS/UQTOJ7LdI+iOu7lExQAbpzX6/
Markiert die unterste Zeile und kopiert Euch dies möglichst in die Zwischenablage. (der Key der hier gezeigt wird ist das Passwort: xxxxxx, Euer Key sieht dann ganz anders aus ;))
Nun legen wie die Daten für die Basis des LDAP-Servers fest, indem wir die Datei /etc/ldap/slapd.conf editieren und den Wert "suffix" folgendermaßen verändern:
HINWEIS! Beim Ubuntu-Server sollten hier eigentlich schon die richtigen Angaben drinstehen, sofern diese unter /etc/hostname gesetzt wurden! suffix "dc=meinedomain,dc=local"
Diese Änderungen müssen in der ganzen Datei angepasst werden. Am Ende der Datei fügt Ihr nun die Administrator-Daten ein: rootdn "cn=admin,dc=meinedomain,dc=local" rootpw {SSHA}4GMPGS/UQTOJ7LdI+iOu7lExQAbpzX6/
Anschließend speichert Ihr die Datei (Strg+O) und startet den LDAP-Server neu:
- /etc/init.d/slapd restart
Nun sagen wir den Clients, wo der Server überhaupt ist. Dafür erstellen wir die /etc/ldap/ldap.conf neu mit folgendem Inhalt:
ldap_version 3
URI ldap://192.168.x.x:389
SIZELIMIT 0
TIMELIMIT 0
DEREF never
BASE dc=meinedomain, dc=local
Die URI ist die IP oder Domain Eures Servers! Wenn Ihr einen DNS-Server laufen habt, könnt Ihr hier auch im Stil von "ldap.meinedomain.local" einen Eintrag machen.
Anschließend legen wir die Administrationsdaten an, damit wir uns später auch im Server anmelden können. Erstellt dazu eine Datei namens base.ldif und gebt folgenden Inhalt ein:
- nano base.ldif
Inhalt: dn:dc=meinedomain,dc=local objectClass: dcObject objectClass: organization o: meinedomain dc: meinedomain
dn:cn=admin,dc=meinedomain,dc=local objectClass: organizationalRole cn: admin
Datei speichern (Strg+O).
Nun fügen wir die eben angelegte Datei per ldapadd dem LDAP-Server hinzu:
- ldapadd -x -W -D cn=admin,dc=meinedomain,dc=local -f base.ldif
Enter LDAP Password: xxxxxx adding new entry "dc=meinedomain,dc=local" adding new entry "cn=admin,dc=meinedomain,dc=local"
Es kann sein, dass der Server meldet, dass die Daten schon vorhanden sind, wenn das so ist, könnt Ihr die Meldung ignorieren!
Mit ldapsearch -x können wir die Daten vom Server abfragen:
- ldapsearch -x
- extended LDIF
- LDAPv3
- base <> with scope sub
- filter: (objectclass=*)
- requesting: ALL
- meinedomain.local
dn: dc=meinedomain,dc=local objectClass: dcObject objectClass: organization o: meinedomain dc: meinedomain
- admin, meinedomain.local
dn: cn=admin,dc=meinedomain,dc=local objectClass: organizationalRole cn: admin
- search result
search: 2 result: 0 Success
- numResponses: 3
- numEntries: 2
Die Konfiguration ist damit abgeschlossen. Weiter gehts mit der Installation von phpLDAPadmin! :)
[bearbeiten]
phpLDAPadmin
Das ebenfalls als OpenSource verfügbare Administrationstool phpLDAPadmin kann mit wenigen Handgriffen installiert werden.
- apt-get install phpldapadmin
Anschließend empfiehlt es sich, einen Link zu dem Verzeichnis der Installation zu legen, damit die Administrationsoberfläche bequem erreichbar ist.
- ln -s /usr/share/phpldapadmin /var/www/phpldapadmin
- /etc/init.d/apache2 restart
Nun ist die Administration per http://SERVERADRESSE/phpldapadmin erreichbar.
WICHTIGE INFO ZUM LOGIN: Es hat mich einige graue Haare gekostet bis ich endlich raushatte, wie man sich richtig einloggt, weil es nirgends stand:
Login DN: cn=admin,dc=meinedomain,dc=local Passwort: zuvor vergebenes [bearbeiten] User in phpLDAPadmin anlegen
Ohne jetzt im Detail auf die Funktionsweise eines LDAP-Servers eingehen zu wollen, möchte ich Euch in kurzen Schritten zeigen, wie Ihr einen Testuser anlegen könnt.
Die Grundstruktur ist die Domain, die ist bereits angelegt. Darunter folgt die OU (Organisational Unit), die hier den Namen "people" erhält. Darunter werden erst die eigentlichen User angelegt.
[bearbeiten]
OU anlegen
Klickt rechts im Menü auf:
Anschließend seht Ihr auf der linken Seite ein umfangreiches Menü:
Klickt nun "Organisational Unit" an und auf "Proceed >>".
In der "Container DN" sollte bereits Eure Domain eingetragen sein, wenn nicht, ändert dies entsprechend. Bei Orgisational Unit gebt Ihr "people" ein und klickt auf den anschließend erst klickbaren Button "Proceed >>".
Auf der folgenden Seite bestätigt Ihr das Anlegen der OU mit dem Klick auf "Create Object". [bearbeiten] Testperson anlegen
Klickt nun auf das + vor:
und anschließend auf das aufklappende
Links wählt Ihr nun "Adress Book Entry"
und anschließend wieder auf "Proceed >>" klicken.
Nun tragt Ihr alle Daten ein und klickt anschließen wieder auf "Proceed >>".
Auf der folgenden Seite bestätigt Ihr das Anlegen mit "Create Object".
Das war's! Euer erster User ist angelegt :)
[bearbeiten]
LDAP im Thunderbird einrichten
Um LDAP nun auch sinnvoll zu nutzen, beschreibe ich hier kurz die Einrichtung im Thunderbird 2.x .
Startet Thunderbird und klickt im Menü auf Extras und Einstellungen, anschließend auf das Icon Verfassen und dann auf den Reiter Adressieren.
Wählt LDAP-Verzeichnisdienst aus und klickt auf Bearbeiten...
Klickt auf Hinzufügen
In dem folgenden Fenster gebt Ihr nun dem Kind einen Namen, den Adresse vom Server und ansonsten übernehmt Ihr die Daten die Ihr hier seht (natürlich ist der Domainname zu ändern ;)).
Das war's! Der LDAP-Server ist nun von Thunderbird aus erreichbar. Testen könnt Ihr das, indem Ihr nun mit Ok bestätigt und im Thunderbird selber auf das Icon Adressbuch klickt.
Klickt den Namen Eures Servers an und tippt in das Suchfeld * * ein um alle User zu listen. Wenn Ihr z.B. nach einem Nachnamen sucht, wird dann natürlich nur der User mit dem entsprechenden Nachnamen angezeigt.
Viel Spaß mit Eurem LDAP-Server! :)
Kategorien: Netzwerk | 6.06
Альтернативный способ настройки phpldapadmin
phpLDAPadmin LDAP via web
PhpLDAPadmin (pla) is a software written in PHP for the ammistrazione of serveur LDAP. Currently it supports totally OpenLDAP and partially (single reading) other serveur LDAP like Fedora Directory Serveur, Microsoft Active Directory, Sun Directory Serveur (the writing is experiences them and not head).
PREREQUISITI For the execution pla it demands a web-serveur and PHP with support for extension LDAP. To notice that it is not necessary that pla is installed on the same serveur on which is active LDAP (even if is a frequent solution that can be comfortable).
For how much rigurda PHP, on Debian is necessary to make sure itself to have installed the packages php4 and php4-ldap (on other distributions could be called php and php-ldap). Complimando PHP from sources is necessary to use the option --with-ldap in the configuration.
If the extension php-ldap is not cariata Apache to verify in php.ini that it is present the entry extension=ldap.so and that the directive extension_dir you bring back the directory with the module ldap.so
INSTALLATION Using Debian distributions based it is possible to install pla with the commando: apt-get install phpladpadmin.
The installation from sources is simple since it does not demand no compliazione; it is advised if you want to use the last version and you want to personalize the access from web server.
Pla must be installed in a directory accessible from web, can therefore directly install the rows in /var/www (or /var/www/html) or an other point of the filesystem and to shape Apache opportunely in order to approach to you.
As a result of download delll'ultima the stable version of phpldapadmin-X.X.X.tar.gz (if it is not used pla in production it is possible to decide to use also a development version or quite build every day or the CVS) is possible to scompattare the package with the commando: tar xvfz phpldapadmin-X.X.X.tar.gz
CONFIGURATION Opportune E' to create the configuration rows leaving from the supplied example: cp config.php.example config.php.
Later on it is possible to bring the modifications to the rows config.php as soon as created verifying the presence of the corrected formulations for the access to serveur LDAP
$servers [$i] [“host”] = “localhost”; $servers [$i] [“base”] = “dc=example, dc=tld”;
(To control the configuration of serveur LDAP in the rows sldap.conf that it can be found in /etc/ldap or /etc/openldap/)
An other useful parameter of configuration is:
$servers [$i] [“auth_type”] = “session”;
If used a version of pla recent or you will have to set up the variable one blowfish
$config->custom->session [“blowfish”] = “scrivete_qui_una_stringa”;
If you want to approach with authentication being used a DN, assured you of to set up how much follows in the configuration rows:
// $ldapservers->SetValue ($i, “login”, “attr”, “uid”); $ldapservers->SetValue ($i, “login”, “attr”, “dn”);
ACCESS If Apache is shaped correctly is possible to approach through browser pla, through a link similar to http://localhost/phpldapadmin/
TEMPLATE One of the used feature more than pla is sure the creation of new template objects through that they supply a form for the guided insertion of the attributes.
NOTES Pla is in continuous development, the formulations of the configuration rows could be in the various sintassi from those indicated in relation to the fine-serveur configuration remains however for analogy recognizable.
Infobox data
Tipo Infobox: DESCRIPTION Skill Level: 2 - JUNIOR Author: lotabi Last Modernization: 2005-12-15 21:45: 28 Date of creation: 2005-08-20 11:46: 33 Language: Topic Correlates to you OpenLdap
Installation, configuration and use of OpenLDAP Resources on Internet
Ещё одна статья
nixp.ru -- *nix project Товары на shop.nixp.ru:
Кружка root (черная); Debian GNU/Linux 4.0 r0 для i386 (3DVD).
Навигация:
/tmp/news /tmp/news.gz /bin/soft /bin/soft/vote /bin/soft/review /etc/articles /opt/forum /mnt/links /usr/about
Разное:
— RSS; — rbt; — рассылки; — обои; — события; — анекдоты; — рассказы; — файлы;
FAQs:
— UNIX FAQ; — Linux FAQ; — в форуме; — FAQ сайта
Поиск:
Рассылки nixp.ru: nixp nixpweek nixpsoft Добавить на сайт:
— новость; — ссылку; — программу; — драйвер; — анекдот; — событие;
nixp.ru в IRC:
- nixp в IrcNet
+1773/4882635
nixp.ru — статьи — «Настройка сервера OpenLDAP» (статьи по Linux и UNIX, документация, помощь по установке, настройке ОС, open source)
Статья: «Настройка сервера OpenLDAP» (версия для печати)
Автор: Vsevolod A. Stakhov/CEBKA E-mail: VStakhov tehnopark org
Постоянная ссылка к статье: http://www.nixp.ru/articles/openldap
Вступление. В настоящее время при администрировании крупных сетей часто используется система LDAP. Но документации на русском по ней практически нет, а документация на английском IMHO очень размазана. Данная статья направлена на полное описание механизмов настройки сервера openldap и взаимодействия его с уже существующими сетевыми сервисами. Введение. При администрировании сети на определенном этапе возникает проблема централизованного контроля аутентификации. Это особенно актуально для крупных сетей (100 и более пользователей). Раньше единственным приемлемым выходом в такой ситуации была установка Novell Netware как центрального сервера или службы NIS, если сеть основана на *nix машинах, что бывает довольно редко. У Netware (версии 4 и старше) существует очень грамотный механизм NDS (служба директорий Novell), позволяющий создать единое дерево сети, в котором каждый компонент сети является объектом службы директорий. Причем каждый объект обладает определенными параметрами для его идентификации. Например, объект пользователь имеет свое имя, телефон, отдел, служебное положение, скрипт для входа в систему. Каждый пользователь обладает определенными правами, некоторые из которых наследуются из прав группы, которой данный пользователь принадлежит. При входе в систему каталогов, пользователь получает доступ только к «своим» файлам. При этом сама система каталогов может находиться на нескольких серверах. Конечно, здесь очень много нюансов и очень полезных возможностей, но я перейду сразу же к основной теме: службе директорий, работающей в TCP/IP сетях — LDAP (Lightweight Directory Access Protocol). Фактически LDAP родился из мертворожденного протокола X.500, предназначенного для использования в сетевой модели OSI. Этот протокол был портирован в TCP/IP сети, наряду с протоколом ICMP, но распространение стал получать только в настоящее время. Фактически сейчас буква L в назвнании не что иное, как традиция: сейчас данный протокол является абсолютно полноценным и имеет право на существование. Теория и терминология. Раньше в *nix существовала только одна возможность централизованной аутентификации — службы NIS, работающие через UDP. LDAP построен по объектно-ориентированному принципу и позволяет с легкостью добавлять и изменять объекты при помощи файлов схем. Кроме этого LDAP обладает большими возожностями в плане структурированности и работы с клиентами различных платфором. Множество приложений поддерживают LDAP через PAM, но об этом далее. На основе LDAP легко построить гетерогенные сети, кроме этого, информация об объектах хранится в древовидном виде. Здесь можно сразу же определиться с сокращениями, принятыми в службе директорий: С(ountry) — страна; ST(ate) — имя региона, области или штата; L(ocation) — имя города, поселка, деревни; O(rganization) — имя компании; O(rganizational)U(nit) — раздел компании; Данные объекты дерева являются основополагающими, т.к. являются контейнерами для других объектов и можно осуществлять поиск определенного объекта, например, в данной компании. На основе вышеперичисленных объектов обычно строится дерево каталогов. Самый верхний уровень представляет объект root (и здесь рут!), от него происходят скелетные объекты, внутри которых и заключаются конкретные объекты-листья дерева. Если представить себе дерево, то скелетные объекты-контейнеры будут играть роль веток, а обычные объекты — роль листьев. Вообще древовидная структура имеет множество преимуществ по сравнению с линейной (/etc/passwd), т.к. позволяет точно определить нахождение пользователя или иного объекта. /etc/passwd предоставляет лишь жалкое подобие данной модели — поле GECOS, но, работая с LDAP, просто необходимо указывать полное описание объекта. Для обозначения полного описания (+имени) объекта относительно скелета дерева используется термин DN (distinguished name — назначенное имя, контекст). На этом позвольте завершить описание теории и перейти к практике… Общая настройка сервера slapd. Займемся самым интересным: настройкой сервера. Я использовал OpenLDAP и все нижесказанное относится только к данному пакету LDAP. Для начала необходимо иметь следующие вещи (я предполагаю установку из пакетов, а не из сырцов; установка из сырцов также не должна вызвать затруднений, но у меня оных просто не было): — Библиотеки LDAP; — Сервер LDAP(slapd); — pam_ldap и nss_ldap для аутентификации через LDAP. После чего надо настроить сервер на работу в вашей службе каталогов. Открываем файл конфигурации /etc/[open]ldap/slapd.conf (при установке из исходников /usr/local/etc/openldap). Он содержит приблизительно следующее:
- Примерный файл конфигурации сервера slapd.conf
include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/corba.schema include /usr/share/openldap/schema/inetorgperson.schema include /usr/share/openldap/schema/java.schema include /usr/share/openldap/schema/krb5-kdc.schema include /usr/share/openldap/schema/kerberosobject.schema include /usr/share/openldap/schema/misc.schema include /usr/share/openldap/schema/nis.schema include /usr/share/openldap/schema/openldap.schema
- Включаем базовые определения объектов директорий и дополнительные классы
- объектов, файлы схем
- Включаем файл, описывающий права доступа к БД:
include /etc/openldap/slapd.access.conf
- Стандартные файлы, необходимые для работы демона: файл идентификатора и
- командной строки
pidfile /var/run/ldap/slapd.pid argsfile /var/run/ldap/slapd.args
- Путь к дополнительным модулям сервера
modulepath /usr/lib/openldap
- Описываем параметры соединения через SSL
- Хост для безопасной аутентификации SASL
sasl-host localhost
- Если вы хотите разрешить соединение через TLS то уберите комментарий из
- следующих строк (в данном примере он есть)
- TLSRandFile /dev/random
- TLSCipherSuite HIGH:+SSLv2
- TLSCertificateFile /etc/openldap/ldap.pem
- TLSCertificateKeyFile /etc/openldap/ldap.pem
- Путь к файлу ключа
- TLSCACertificatePath /etc/openldap/
- TLSCACertificateFile /etc/openldap/ldap.pem
- Путь к сертификату хоста
- TLSVerifyClient 0
- Проверка ключа клиента
- Самое главное - описание базы данных LDAP
database ldbm
- Тип базы данных ldbm
suffix "dc=test,dc=ru"
- suffix "o=My Organization Name,c=US"
- Это основной суффикс БД. В определении системы директорий существует так
- называемый корневой объект root. Суффикс определяет этот объект. Вообще
- существует 2 стандарта LDAP имен для скелета дерева: метод для глобальных
- сетей и локальных. Первый имеет подобный вид и описывает URL адрес:
- person.domain.com(cn=person,dc=domain,dc=com), а второй описывает
- организацию(вообще-то этот вид является стандартным) и имеет следующий вид:
- person.organization_unit.organization.country(cn=person,ou=otd1,o=lab,c=RU)
- выбор метода зависит от конкретного назначения LDAP и особого значения не имеет
- В данной статье я использовал интернет-наименования для краткости, но обычно в
- компаниях все же чаще применяется второй способ построения скелета дерева.
rootdn "cn=admin,dc=test,dc=ru"
- rootdn "cn=Manager,o=My Organization Name,c=RU"
- Это поле содержит пароль администратора объекта root(то есть всей БД LDAP).
- Пароль может храниться как в открытом виде (не рекомендуется!), так и в
- зашифрованном виде с указанием алгоритма шифрования ({crypt}, {MD5}, {SSHA},
- {crypt}, {SMD5}, {SHA}) Пароль
- желательно устанавливать программой slappasswd, позволяющей установить нужный
- алгоритм шифрования
rootpw secret
- rootpw {crypt}ijFYNcSNctBYg
- Папка, где хранится база данных LDAP. Эта папка должна существовать до запуска
- LDAP, который иначе не запустится. Папка должна быть доступна для чтения и
- записи только пользователю, под которым работает slapd, и иметь маску доступа
- 700
directory /var/lib/ldap
- Определения первичных и вторичных индексов БД может ускорить поиск по БД
- index objectClass eq
index objectClass,uid,uidNumber,gidNumber eq index cn,mail,surname,givenname eq,subinitial
- Права доступа по умолчанию
access to attr=userPassword by self write by anonymous auth by dn="uid=root,dc=test,dc=ru" write by * none
- Здесь определяется доступ к атрибуту пароль пользователя. Сам пользователь имеет право
- записи, анонимному пользователю предоставляется возможность пройти
- аутентификацию (после этого он представляет уже другой объект и доступа к
- паролям анонимного пользователя не происходит, как можно было бы подумать) а
- пользователь с контекстом
- "uid=root,ou=people,dc=test,dc=ru" имеет право на запись. Другие же
- пользователи доступа к паролю не имеют никакого. Т.е. другими словами никто,
- кроме администратора и самого пользователя не имеют доступа к паролю
access to * by dn="uid=root,dc=test,dc=ru" write by * read
- Доступ к остальным полям базы LDAP - все могут читать атрибуты(кроме пароля,
- так как запрет имеет более высокий приоритет), а пользователь с контекстом
- root может писать все что угодно (а кто ж ему помешает :)
Пример достаточно комментирован, поэтому особенно тут говорить не о чем. Добавлю еще, что в этом файле можно еще указывать дополнительные параметры для взаимодействия нескольких серверов (реплик), в частности основной сервер, вторичные сервера, пароли доступа к ним и т.д. Но это уже другая тема. В основном необходимо сделать 3 вещи: установить суффикс БД и выбрать тип контекста (глобальной сети или организации); указать контекст администратора LDAP; установить пароль администратора LDAP с помощью программы slappasswd. Чтобы установить алгоритм шифрования пароля запускайте программу slappasswd так: slappasswd -h {алгоритм_шифрования}, вместе с символами {}, например, slappasswd -h {crypt} или slappasswd -h {md5}.
Вот и все: сервер может хоть сейчас начинать работать! Но толку пока от него никакого: ведь мы не добавили объектов. Сейчас я расскажу, как создавать базу данных LDAP и проводить аутентификацию через нее.
Создание базы данных.
Для первоначальной настройки неплохо было бы объяснить общий синтаксис файлов для создания базы данных (я обозначаю комментарии символом #, но в реальном файле этих комментариев быть не должно!):
dn: dc=test,dc=ru
- Уникальный контекст имени
objectclass: dcObject
- Класс объекта - контейнерный объект
objectclass: organization
- Тот же самый контекст может представлять собой различные объекты
o: test
- Имя организации
dc: test
- То же самое, но в системе глобальных имен
- ----------------------------------------------------------------------
dn: cn=admin,dc=test,dc=ru
- Контекст администратора
objectclass: organizationalRole
- Класс - должностное лицо
cn: admin
- Имя человека (псевдоним)
- -----------------------------------------------------------------------
dn: ou=users,dc=test,dc=ru
- Контекст группы пользователей
ou: users
- Значение группы
objectclass: top
objectclass: organizationalUnit
- Класс группа
- ------------------------------------------------------------------------
dn: uid=null,ou=users,dc=test,dc=ru
- Контекст конкретного пользователя из /etc/passwd
uid: null
- Его пользовательский псевдоним
cn: Neo
- Реальный псевдоним
objectclass: account
- Класс пользовательский профиль
objectclass: posixAccount
- Класс пользователя POSIX
objectclass: top
objectclass: uidObject
- Самая лучшая оболочка - zsh!
loginshell: /bin/zsh
- Все следующие параметры совпадают с аналогичными в /etc/passwd
uidnumber: 1000
gidnumber: 1000
homedirectory: /home/null
gecos: Neo
userpassword: $1$abcdvPbaLa6vs4ABab1N
Конечно, здесь, думаю, все понятно. Но ведь если у вас система уже настроенная и содержащая порядка 8*10^10 пользователей, то будет немного трудновато все это заново переписывать ;) Поэтому во многих дистрибутивах есть пакет openldap-migration, содержащий набор скриптов для переноса существующих файлов и баз сетевых служб в LDAP. Если его нет, то посмотрите здесь: www.padl.com. Данный пакет представляет из себя набор скриптов на перле, обрабатывающий соответствующие файлы и службы (/etc/passwd(+shadow), /etc/hosts, /etc/profile, /etc/services, NIS-службы). Использование скриптов предельно просто. Вначале надо исправить файл /usr/share/openldap/migration/migrate_common.ph:
- Почтовый домен по умолчанию
$DEFAULT_MAIL_DOMAIN = "test.ru";
- Имя корневого объекта LDAP
$DEFAULT_BASE = "dc=test,dc=ru";
- Хост для приема/передачи почты по умолчанию
$DEFAULT_MAIL_HOST = "mail.test.ru";
- Используем расширенные файлы схем
$EXTENDED_SCHEMA = 1;
Далее выполняем migrate_base.pl > base.ldif для создания структуры базы LDAP. Для добавления данного файла к базе можно использовать следующий синтаксис: ldapadd -x -D «cn=root,dc=test,dc=ru» -W -f base.ldif или же slapadd -f base.ldif для добавления записи в режиме offline. Первый способ лучше, так как позволяет проверить работу LDAP в сети (фактически используются TCP-сокеты). Далее выполняем миграцию того, что нужно перенести в LDAP, например: ./migrate_hosts.pl /etc/hosts hosts.ldif Файл hosts.ldif будет содержать примерно следующее (в файле /etc/hosts было 192.168.1.23 work.test.ru work):
dn: cn=work.test.ru,ou=Hosts,dc=test,dc=ru objectClass: top objectClass: ipHost objectClass: device ipHostNumber: 192.168.1.23 cn: work.test.ru cn: work
Удобно, не так ли? Можно проделать подобное со всем, для чего уже написаны скрипты (можно и самому, в конце концов, написать! Что нам этот перл). Кстати, вот еще о чем я забыл: при переносе /etc/passwd нужно установить переменную окружения ETC_SHADOW: root@ldap # ETC_SHADOW=/etc/shadow ./migrate_passwd.pl /etc/passwd passwd.ldif И еще не забывайте добавлять файлы .ldiff к базе с помощью ldapadd! Если всего этого делать нет желания, то можно применить один из shell-скриптов migrate_all_[on|off]line, которые позволяют перенести все существующие стандартные конфигурационные файлы в LDAP в интерактивном режиме. Ну вот, база создана, надо бы ее проверить. Поищем в ней объекты с заданным атрибутом, пускай помучается:
ldapsearch -LL -H ldap://localhost -b"dc=test,dc=ru" -x "(uid=null)"
- filter: (uid=null)
- requesting: ALL
- null, Users, test, ru
dn: uid=null,ou=Users,dc=test,dc=ru
uid: null
cn: Neo
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: uidObject
loginShell: /bin/zsh
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/null
gecos: Neo
- search result
search: 2
result: 0 Success
- numResponses: 1
- numEntries: 1
Естественно, что в поиске можно использовать регулярные выражения. «Ну и нафиг мы это делали?» — закричат многие и будут неправы. На самом деле, это уже круто: вся инфа о системе хранится в древесном виде в БД. Там ее можно искать, читать, писать, ставить всякие там права. Идея — просто супер! Причем все это хозяйство без проблем достается из сети, реестр виндов отдыхает. Это сказка для любителей Novell и еще один повод перейти на Linux даже в крупных сетях. Извините, оговорился на *nix, так как openldap работает практически на всех *nix-системах, а клиенты есть под любую ось. Ну, а теперь разберемся, как организовать связку с другими программами. Настройка клиентов и аутентификации. Вначале нужно создать специального пользователя, который мог бы читать пароли других пользователей (это, конечно, плоховато для безопасности, но ведь пароль-то можно придумать какой-нибудь зловещий, например, SHA1-хеш от результата crypt над строкой $%YJH&*&*jszZn7867wey8YT6yeuwe%%&^&&* :)) Этот пользователь понадобится в будущем для клиентов LDAP, для выполнения аутентификации (ведь клиентам надо прочитать пароль, чтобы его сравнить с чем-то). Назовем этого пользователя proxy и сделаем следующее: Добавим его в LDAP:
dn: cn=proxy,dc=test,dc=ru cn: prox sn: proxy objectclass: top objectclass: person userPassword: {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
Затем предоставим ему права чтения пароля в sldap.conf:
access to attr=userPassword by self write by anonymous auth by dn="uid=root,dc=test,dc=ru" write by dn="cn=proxy,dc=test,dc=ru" read by * none
Далее настроим наших клиентов в файле /etc/ldap.conf (для *nix-клиентов, для других ОС необходимо смотреть документацию к софту, работающему с LDAP-сервером):
- Сервер LDAP - ip адрес сервера или его
- имя, находящееся в /etc/hosts, или в DNS на удаленном узле
host 127.0.0.1
- Основной суфикс, должен совпадать с суфиксом в slapd.conf
base dc=test,dc=ru
- Это типа root, точнее наш горячо любимый proxy, сделано в целях безопасности
- и не позволяет самому пользователю изменить пароль.
rootbinddn cn=proxy,dc=test,dc=ru scope one
- Это фильтр для поиска пользовательских записей
pam_filter objectclass=posixaccount
- Атрибут, определяющий имя пользователя и его группы для pam модуля
pam_login_attribute uid pam_member_attribute gid pam_template_login_attribute uid
- Тип пароля - шифрование UNIX crypt, кстати, шифрование LDAP и шифрование UNIX
- не совместимы(crypt означает именно шифрование unix)!
pam_password crypt
- Базовые dn для поиска различных объектов, one - это область поиска.
- Данные параметры используются nss.
nss_base_passwd ou=People,dc=test,dc=ru?one nss_base_shadow ou=People,dc=test,dc=ru?one nss_base_group ou=Group,dc=test,dc=ru?one nss_base_hosts ou=Hosts,dc=test,dc=ru?one
После этого вы должны создать файл, содержащий пароль коварного proxy в открытом (!) виде. Ну и, конечно же, запретить чтение/запись всем, кроме root (chmod 0600 chown root:root). В принципе то же самое, что и /etc/shadow. Но беда, что пароль хранится в открытом виде. С другой стороны получение пароля proxy само по себе ничего не дает: нельзя менять пароли, но прочитать их можно (хотя толку мало, если пароли дикие). Но если proxy не может менять пароль, то никто не сможет изменить свой пароль, иначе как вы себе это представляете. Ну, а дальше надо настраивать pam, чтоб он ходил на LDAP-сервер за паролями. Чтобы включить возможность аутентификации приложений через LDAP необходимо установить модуль PAM pam-ldap. После этого можно включить в файлы /etc/pam.d (эти файлы содержат список способов аутентификации для определенных приложений: login, passwd, pop, smtp…) следующие строчки:
auth sufficient /lib/security/pam_ldap.so account sufficient /lib/security/pam_ldap.so password sufficient /lib/security/pam_ldap.so #(эта строчка нужна не везде,
- надо смотреть, в каких файлах она уже есть)
- Особо надо отметить файл system-auth, здесь нужно указать некоторые вещи:
- %PAM-1.0
auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth sufficient /lib/security/pam_ldap.so use_first_pass auth required /lib/security/pam_deny.so
account required /lib/security/pam_unix.so account [default=bad success=ok user_unknown=ignore \ service_err=ignore system_err=ignore] /lib/security/pam_ldap.so
password required /lib/security/pam_cracklib.so retry=3 password sufficient /lib/security/pam_unix.so nullok use_authtok \ md5 shadow password sufficient /lib/security/pam_ldap.so use_authtok password required /lib/security/pam_deny.so
session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_ldap.so
Модуль LDAP является обычно дополнительным компонентом и не является необходимым, и поиск идет вначале в локальных файлах, а потом уж в ldap (так как стоит он после других способов аутентификации). Таким образом, можно добавить аутентификацию через ldap в любой модуль pam, а последний используется множеством приложений для аутентификации клиента. Еще одной интересной возможностью ldap является возможность проверки хоста. Часто нельзя, чтобы любой человек, занесенный в базу ldap мог пользоваться вашим компом (мало ли чего, вдруг это начальник ;). Поэтому можно добавить к учетным записям пользователей хосты, на которые эти пользователи могут логиниться (повторяю: не откуда может поступать запрос, а куда они могут входить, то есть нельзя удаленно пройти аутентификацию на машине X, если это не разрешено). Для этого необходимо добавить к каждой записи пользователя следующие атрибуты:
host: name_of_host1 host: name_of_host2 ... host: name_of_hostn
Для модификации базы данных можно воспользоваться программой ldapmodify: ldapmodify -H ldap://localhost -D «cn=root,dc=test,dc=ru» -x -W -f host-auth.ldif А сам файл host-auth.ldif должен содержать следующее:
dn: uid=user_name,ou=People,dc=test,dc=ru changetype: modify add: host host: name_of_host1 host: name_of_host2 host: name_of_hostn
Придется повторить это для каждого пользователя! Разумнее написать скрипт, но я возложу это на ваши могучие плечи. После этого надо сделать еще изменения в /etc/ldap.conf. В данном файле необходимо указать, что нужно еще смотреть атрибут host: pam_check_host_attr yes Защита LDAP при помощи SSL. Как я уже говорил в LDAP существует возможность защиты данных, передаваемых посети. При этом используется два метода: TLS и SASL. Первый из них не меняет порта, на котором слушает LDAP (336), а просто организует аутентификацию асимметрическим шифрованием, SASL же меняет порт LDAP на ldaps:// и соединение идет по-другому механизму: через туннель SASL. TLS намного проще в настройке, поэтому я расскажу именно о нем. Для начала надо сгенерировать серверную пару ключей асимметрического шифрования. Для этого в Linux удобно воспользоваться единым центром сертификации OpenSSL (об этом я уже писал на страницах 2-го номера): а) создаем rsa ключ длиной 1024 бита и сохраняем его в файле ldap.key: $ openssl genrsa -out ldap.key 1024 б) создаем запрос на сертификацию: $ openssl req -new -config .cfg -key ldap.key -out ldap.csr в) создаем сертификат, которому будем доверять(CACertificate); вначале делаем ключ длиной 2048 бит: $ openssl genrsa -des3 -out ca.key 2048 г) создаем self-signed сертификат сроком действия на год на основе сгенерированного ключа: $ openssl req -new -x509 -days 365 -key ca.key -out ca.cert д) теперь на основе созданного для LDAP ключа и доверенного сертификата создаем сертификат LDAP:
$ openssl x509 -req -in ldap.csr -out ldap.cert -CA ca.cert -CAkey ca.key -CAcreateserial \ -days 365 -extfile .cfg
При этом файл конфигурации .cfg должен содержать следующие расширения:
[ v3_req ] subjectAltName = email:copy basicConstraints = CA:false nsComment = "LDAP server certificate" nsCertType = server
Немного страшновато выглядит, но в ходе всех этих действий создаются два сертификата: доверенный сертификат и подписанный им сертификат сервера. Таким образом, сервер LDAP сможет проверить правильность своего сертификата через доверенный сертификат. Кстати, если у вас уже есть доверенные сертификаты, то можно воспользоваться ими: просто пропустите шаги б) и в) и на шаге г) введите имя своего доверенного сертификата (можно также воспользоваться моим скриптом CA). Итак после всех этих действий перемещаем сертификаты и ключ сервера LDAP (ldap.key) куда-нибудь в /etc/ssl/ldap (принято хранить все ключи и сертификаты, созданные openssl в /etc/ssl) и делаем их доступными для чтения только владельцу: # chmod 0400 /etc/ssl/ldap/* и меняем владельца на ldap: # chown ldap:ldap /etc/ssl/ldap/* Настройка сервера предельно проста: необходимо просто прописать пути к сертификатам и ключам в файле slapd.conf следующим образом:
- Сертификат сервера
TLSCertificateFile /etc/ssl/ldap/ldap.cert
- Ключ сервера
TLSCertificateKeyFile /etc/ssl/ldap/ldap.key
- Доверенный сертификат
TLSCACertificateFile /etc/ssl/ldap/ca.cert
Сервер можно конфигурировать и альтернативным методом — через туннель stunnel или ssh. Обычно применяют stunnel, но для начала опять же генерируют сертификат сервера(при этом сам LDAP не должен быть настроен для поддержки SSL, т.к. stunnel будет заменять встроенные механизмы SSL ldapa). После генерации сертификата делаем следующее: # stunnel -r ldap -d 636 -p /etc/ssl/stunnel/stunnel.pem Записываем эту команду в один из init файлов и добавляем правило iptables для отбрасывния сетевого трафика с порта 389 с целью повышения безопасности (это запрещает доступ по сети к серверу ldap без механизма ssl). Для генерации сертификата в данном случае можно применить скрипт для генерации stunnel сертификатов, который обычно поставляется вместе с stunnel. Можно также применить следующее:
$ openssl req -new -x509 -days 365 -nodes -config stunnel.cnf \ -out stunnel.pem -keyout stunnel.pem $ openssl gendh 512 >> stunnel.pem
для генерации self-signed сертификата и параметров для ключей Дифлемана-Хельмана. На самом деле, через туннель у меня все работало просто на ура, а встроенные механизмы работали несколько странно, хотя я перечитал все маны и руководства, но это не помогло… Теперь перезапускаем slapd и настраиваем клиентов. Для настройки клиентов надо прописать в файле ldap.conf следующие строки:
- Аутентификация через TLS
ssl start_tls
- По умолчанию клиент пытается использовать обычное соединение, закомментировав
- следующую строчку мы ставим жирный крест на его безобразиях
- ssl off
Интеграция. Теперь наш LDAP-сервер работает замечательно(или не работает совсем, что зависит от /dev/hands) и его уже можно использовать в сети, но многие хотели бы заменить старые системы аутентификации на LDAP. Самое время, чтобы рассказать о LDAP и NIS. NIS (что означает службы сетевой информации) широко используется для единого управления паролями в сети. NIS — это более старый и менее защищенный протокол аутентификации. Возможности LDAP IMHO значительно шире и поэтому имеет смысл перенести NIS в LDAP, чтобы использовать возможности последнего и устоявшиеся настройки первого (не вновь же все ручками писать), благо в пакете migrationtools есть скрипты для миграции NIS и NISPLUS:
migrate_all_nisplus_on[off]line.sh migrate_all_nis_on[off]line.sh
Я уже рассказал о методах интеграции существущей системы и LDAP через PAM (встраиваемые модули аутентификации), а сейчас настало время рассказать еще об одном механизме аутентификаци: NSS(дословно выбор службы имен). NSS выбирает, какой тип аутентификации будет использоваться при запросе клиентом определенного файла или механизма (с nss интегрировано множество программ, например, самба). Для настройки NSS используется файл /etc/nsswitch.conf. Его синтаксис предельно прост: имя сервиса (shadow passwd hosts) и далее список параметров (в порядке убывания приоритета), определяющих возможные сетевые службы. Вот, например, файл nssswitch.conf с моей домашней машины:
- Legal entries are:
- nisplus or nis+ Использовать 3-ю версию NIS(NIS+)
- nis or yp Использовать 2-ю версию NIS(YP)
- dns Использовать DNS
- files Использовать локальные файлы
- ldap Использовать LDAP базу
- [NOTFOUND=return] Если не найдена информация, остановить поиск
passwd: files nisplus nis shadow: files nisplus nis group: files nisplus nis
hosts: files nisplus nis dns
networks: files protocols: files services: files
netgroup: nisplus
- -----------------------------------------------------------------------------------
Чтобы использовать ldap просто добавьте в нужные места данный метод. Если вы хотите использовать только ldap, то поставьте после слова "ldap" строчку [NOTFOUND=return], чтобы поиск прекращался при отсутствии элемента в базе LDAP. Например:
- Ищем вначале в локальных файлах, а потом в LDAP
passwd: files ldap shadow: files ldap group: files ldap hosts: files dns ldap
Учтите еще одну особенность: я бы не рекомендовал использовать ldap для оперделения хостов, т.к. он будет пытаться найти имя удаленного клиента в /etc/hosts, а потом начнет перерывать какие-то данные, что вызывает нехилую задержку ~30 секунд (если имени нет в hosts). Так что лучше использовать старый добрый DNS (тем более, записи DNS можно храните в LDAP, но об этом немного позднее). Тем более, что когда я поставил у себя проверку хостов первоначально через LDAP, то повис последний наглухо, т.к. вызывает рекурсивно gethostbyname() для определения своего адреса. Хорошо, nss мы настроили, теперь примемся за самбу. Честно говоря, самба — это IMHO немного кривая софтина (а как же: работает с такими замечательными ОС), но с версии 2.2.6 вопросы, касающиеся LDAP вроде ушли из мейл-листа, что наводит на радужные мечтания (кстати, самба 2.2.6 требует SP3 у Win2k клиентов). Для компиляции сервера с LDAP наберите ./configure --with-ldapsam. Самба имеет возможность указания сервера LDAP и базового dn поиска прямо в smb.conf. Для этого существует несколько опций: — ldap server — основной параметр, определяет адрес ldap сервера. — ldap ssl — параметр указывающий надо ли использовать безопасные методы аутентификации (нужно всегда!). Имеет значение on для работы через SSL(порт 636), start tls для обычной аутентификации через tls(389 порт) и no для посылки данных в открытом виде (также порт 389). — ldap admin dn — параметр, определяющий запись, имеющую права доступа к паролям самбы. — ldap suffix — основной суффикс базы данных LDAP. — ldap filter — фильтр, по которому самба ищет свои объекты, например, ldap filter = «(&(uid=%u)(objectclass=sambaAccount))»: имя пользователя совпадает с логином виндов, а тип объекта — профиль самбы. — ldap port — если ваш сервер LDAP висит на другом порту, чем это назначено по умолчанию (см. параметр ldap ssl), то здесь это можно указать. Приведу простой пример настройки самбы с LDAP:
[global]
- Юзеры должны залогиниться на сервер
security = user
- Естественно шифруем пароли
encrypt passwords = yes
netbios name = Linux workgroup = NET
- Параметры LDAP
- Определяем админовский dn. Пароль к нему должен добавляться
- непосредственно smbpasswd -w. После смены dn админа пароль тоже надо
- сменить!
ldap admin dn = "cn=ntadmin,ou=people,dc=test,dc=ru"
- Определяем сервер LDAP
ldap server = ldap.test.ru
- Заходим на LDAP сервер через TLS
ldap ssl = start tls
- Определяем порт(хотя в данном случае это необязательно)
ldap port = 636
- Определяем суффикс базы данных ldap
ldap suffix = "ou=people,dc=test,dc=ru"
Кроме этого, естественно надо завести админа самбы в LDAP и обеспечить ему соответствующие права доступа в slapd.conf (можно для этой цели использовать рута: это тоже сработает):
- --------------------------------------------
access to attrs=lmPassword,ntPassword by dn="cn=ntadmin,ou=people,dc=test,dc=ru" write by * none
- --------------------------------------------
После настройки администраторской записи в ldap, самба может корректно работать с деревом директорий. При правильной компиляции (с флагом --with-ldapsam) smbpasswd будет добавлять пользователей и машины в каталог LDAP, при этом smbpasswd будет использовать passwd и groups из nsswitch(при правильной настройке nss можно также брать всю инфу из LDAPа, т.к. самба обращается к passwd через nss): добавляем пользователей: # smbpasswd -a добавляем машину(для самбы-контроллера домена): # smbpasswd -m -a $ После этого проверяем результат:
- ldapsearch -ZZ -H localhost -b "o=smb,dc=test,dc=ru" "uid=pc1$"
-- dn: uid=icb$, o=smb, dc=test, dc=ru objectClass: sambaAccount uid: pc1$ pwdLastSet: 0 logonTime: 0 logoffTime: 2147483647 kickoffTime: 2147483647 pwdCanChange: 0 pwdMustChange: 2147483647 displayName: MustdiePC cn: PC1 rid: 2054 primaryGroupID: 1201 lmPassword: 56D989A3C45BBAD3462E8109C329E116 ntPassword: 56D989A3C45BBAD3462E8109C129E116 acctFlags: [W ] --
После этого вы можете изменять информацию профиля пользователя. Например, весьма полезны атрибуты scriptPath(скрипт, выполняющийся при логине клиента), homeDrive(диск домашней директории), profilePath(путь к профилю), pwdMustChange(необходимость смены пароля пользователем). Для изменения базы данных LDAP на лету существует команда ldapmodify, которая, как и команда ldapadd работает с файлами ldiff. Я не буду подробно описывать формат этого файла, а просто приведу пример изменения нужных атрибутов:
dn: uid=001, o=smb, dc=test, dc=ru changetype: modify replace: profilePath profilePath: \\%N\profiles\user1 - replace: scripthPath scripthPath: 001.bat - replace: homeDrive homeDrive: Z: - replace: pwdCanChange pwdCanChange: 0 - replace: pwdMustChange pwdMustChange: 0 - replace: primaryGroupID primaryGroupID: 513 -
Для добавления информации в базу воспользуйтесь командой: $ ldapmodify -H localhost -D "" -W -ZZ -l modification.ldif (Примечание: в руководствах говорится, что надо использовать ключ -f, а не -l, но у меня по-другому не работало, хотя, наверное, я что-то делаю не так). Любителям готовых примеров посоветую сходить на http://www.unav.es/cti/ldap-smb/ldap-smb-2_2-howto.html — отличный пример настройки контроллера домена с LDAP (не буду же я здесь приводить все эти конфиги, а мои собственные исторической ценности не имеют). Напоследок скажу еще об одном приложении, работающем непосредственно с LDAP — это squid. Для него существует модуль, позволяющий выполнить http-аутентификацию, используя базу LDAP. В исходных текстах сквида можно найти модуль, squid_ldap_auth, представляющий собой внешнюю программу, его исходные тексты находится в каталоге auth_modules/LDAP. Скомпилировав ее обычным образом (./configure -> make -> make install) получаем обычный исполняемый файл squid_ldap_auth. После установки модуля добавляем такие строчки в squid.conf:
authenticate_program /usr/squid/libexec/squid/squid_ldap_auth -b dc=test,dc=ru localhost
Вначале указываем путь к исполняемому файлу, затем основной суффикс базы LDAP и ldap сервер (localhost у меня). Далее в squid.conf добавляем права доступа (ACL):
- Заставляем всех аутентифицироваться для доступа к прокси
acl password proxy_auth REQUIRED
- Возможен доступ http всем, кто прошел проверку
http_access allow password
- Остальных шлем погулять ;)
http_access deny all
Теперь о возможности работы с LDAP апача. Apache имеет модуль mod_auth_ldap, который позволяет производить http-аутентификацию через ldap сервер. Здесь я опять же ограничусь только примером типичной настройки аутентификации через ldap:
httpd.conf
- Загружаем модуль аутентификации. Обычно находится в extramodules
LoadModule auth_ldap_module extramodules/auth_ldap.so AddModule auth_ldap.c
- Определения аутентификации через ldap для конкретного каталога
- Это основной контекст для поиска соответствия пользователя и пароля в базе
- LDAP, если данная опция не указана, но используется анонимный доступ(что
- обычно запрещается в целях безопасности).
AuthLDAPBindDN cn=proxy,dc=test,dc=ru
- Пароль для основного контекста
AuthLDAPBindPassword secret
- Включение механизма TLS для доступа к серверу ldap(по умолчанию off)
AuthLDAPStartTLS on
- Основной параметр, который определяет сервер ldap, dn поиска, атрибуты и
- фильтр, по которому выполняется аутентификация:
- ldaps://host:port/basedn?attribute?scope?filter, где
- basedn - базовый dn для поиска(ищется только в данной ветви дерева и ее
- потомках)
- attribute - список атрибутов, разделяемых запятой, по которым
- производится поиск(по умолчанию используется атрибут uid)
- scope - флаг, определяющий тип возвращаемых значений one - ищется первое
- выражение, sub - ищутся все выражения, соответствующие фильтру(принято
- по умолчанию).
- filter - строка, определяющая фильтр поиска элементов ldap, заключается
- в скобки, по умолчанию равна (objectclass=*). Фильтр может содержать
- логические выражения | и & которые должны стоять не между двумя
- скобками, а ПЕРЕД ними. Приведу несколько примеров фильтров:
- (|(cn=admin)(uid=root)) - или cn admin или UID root
- (cn=admin) - только cn = admin
- В данном примере допустимым являются только объекты, принадлежащие basedn
- O=myorg, OU=sysopka
AuthLDAPUrl ldaps://test.ru/O=myorg, OU=sysopka
- Требуем только пользователей, прошедших проверку на ldap сервере
require valid-user
Существует еще несколько опций модуля, но они используются реже, и о них можно почитать в документации. Proftpd имеет схожий модуль auth-ldap, но здесь описывать его я не буду, т.к. настройка модуля ftp-сервера очень похожа на конфигурацию апача. Настройка почтовых серверов также не представляет особой проблемы. Я, например, без проблем настроил postfix и курьер, последний настраивать особенно легко, т.к. работает сразу же после того, как указывается ldap сервер, основной dn и запись администратора и ее пароль в открытом виде для доступа к полям паролей пользователей (опять же можно использовать proxy). Конфигурация postfix несколько сложнее:
main.cf virtual_maps = ldap:ldapvirtual
- Сервер ldap и порт
ldapvirtual_server_host = test.ru ldapvirtual_server_port = 389
- Основной dn для поиска по базе
ldapvirtual_search_base = ou=mail,o=YourOrg,c=nl
- Домен для поиска
ldapvirtual_domain = test.ru
- Атрибут, который должен читать postfix при работе с ldap(по e-mail адресу
- определяется путь).
ldapvirtual_result_attribute = maildrop
- Считываем одну запись из выборки
ldapvirtual_scope = one
- Основной контекст и пароль
ldapvirtual_bind_dn = cn=proxy, dc=test, dc=ru ldapvirtual_bind_pw = secret
Работа sendmail для хранения почтовых алиасов и паролей в ldap также возможна. Для этого используются записи локальных получателей objectClass: inetLocalMailRecipient (в принципе эти записи используются для указания псевдонимов во всех почтовых системах, работающих с LDAP), имеющими примерно такой вид:
dn: uid=user, dc=test, dc=ru objectClass: inetLocalMailRecipient mailLocalAdress: user@test.ru mailRoutingAdress: alex@test.ru uid: user
В данном случае почта перенаправляется с адреса user@test.ru на адрес alex@test.ru. Sendmail я настраивал через препроцессор m4, так что заранее прошу прощения у заядлых любителей sendmail.cf. Для данного случая используется несколько конфигурационных макросов, назначение которых, думаю будет понятно с первого взгляда:
dnl # Включение доставки почты согласно записям ldap FEATURE(`ldap_routing') LDAPROUTE_DOMAIN(`test.ru') dnl # Можно считать аргументами командной строки к ldapsearch dnl # Для получения списка всех опций командной строки, как обычно наберите dnl # ldapsearch --help define(`confLDAP_DEFAULT_SPEC', `-h ldap.test.ru -b dc=test,dc=ru')
И это действительно работает! Реплики. Ну вот, с интеграцией LDAPа разобрались… Пора рассказать о дополнительных возможностях данной системы. Итак, реплики. Реплики — это одна из мощных возможностей системы директорий LDAP. Реплики — это раскопирование базы данных LDAP по нескольким серверам, т.е. фактически само дерево «размазывается» по серверам. Реплика существует между несколькими серверами, один из которых является primary(это похоже на службу DNS, только немного для других целей). В таком случае первичный сервер обрабатывает запросы на запись и на чтение, а вторичные — только на чтение. При модификации данных на главном сервере он заходит на все вторичные и синхронизирует их базы со своей. Для создания реплик необходимо три вещи: а) настройка файлов slapd.conf главного и вторичных серверов; б) первоначальный перенос основной базы с основного сервера на вторичные; в) запуск демона slurpd, который и осуществляет синхронизацию серверов. После осуществления всего этого можно разбивать пользователей на группы и указывать для их клиентов определенный ldap сервер и создать основной сервер, который будет все вторичные синхронизировать(звездообразная схема). При этом любые изменения в базе любого из ldap серверов будут раскопированы на все сервера, включая основной. Вот примерная схема действия реплики при получении запроса от клиента: 1. Вторичный LDAP сервер получает запрос на изменение и говорит клиенту, что надо изменить данные на основном сервере(то есть перенаправляет клиента к главному). 2. Клиент посылает запрос главному серверу, который он обрабатывает. При этом сервер знает, что клиент был к нему перенаправлен(это записывается в лог реплики). 3. slurpd замечает(после происшествия некоторого времени), что данные были обновлены, и осуществляет синхронизацию. 4. Вторичные сервера получают запрос от slurpd главного сервера и, обновив данные у себя, посылают ответ slurpd, этот ответ также может быть записан в лог реплики. Ну все, хватит теории, начинаем настройку. Для начала поправим slapd.conf:
- Это основной сервер!
- Добавим несколько реплик. Каждая директива соответствует одному вторичному
- ldap серверу. Указываем адрес вторичного сервера(host), dn для репликатора,
- метод аутентификации и пароль репликации(пароль для данного dn). В качестве
- репликатора можно использовать рута. Честно говоря, для реплик я бы создал
- туннель через ssh или stunnel
- и присоединялся бы не к удаленному хосту к порту 389, а к локальному на
- назначенный порт (для разных рабов можно сделать несколько туннелей)
replica host=slave1.test.ru:389 binddn="cn=replicator,dc=test,dc=ru" bindmethod=simple credentials=replicator_password
- Следующий раб
replica host=slave2.test.ru:389 binddn="cn=replicator,dc=test,dc=ru" bindmethod=simple credentials=replicator_password
- Записываем данные реплик в лог-файл, это делать необязательно (даже
- нежелательно, т.к. понижает производительность). Эта опция едина для всех
- вторичных серверов
replogfile /var/log/ldap/replica.log
После чего на вторичных серверах вносим еще пару строк в slapd.conf:
- Это вторичный сервер!
- Нельзя использовать директивы replica replogfile. Необходимо создать некий
- updatedn, совпадающий с binddn основного сервера, по которому главный будет
- модифицировать данные.
updatedn="cn=replicator,dc=test,dc=ru"
- Включаем адрес основного сервера ldap, куда будет перенаправляться клиент,
- пытающийся модифицировать данные
updateref master.test.ru:389
- Надо дать необходимые привиллегии репликатору, т.к. ему необходим доступ на
- запись данных
access to * by dn="cn=root,dc=test,dc=ru" write by dn="cn=replicator,dc=test,dc=ru" write by self write
После настройки всех серверов необходимо перекопировать содержимое базы данных LDAP основного сервера на все вторичные сервера, для этого необходимо перенести содержимое DatabaseDir физически(!). После всего этого желательно проиндексировать базу, иначе поиск по ней замедляется: slapindex -f /etc/ldap/slapd.conf -b «dc=test,dc=ru» Затем на главном сервере запускаем slurpd: # slurpd Использование stunnel в данном случае также приемлимо. В этом случае на главном сервере устанавливается клиенты туннеля, которые направлены ко вторичным ldap серверам, но на сервере эти туннели будут висеть на разных портах, и ldap сервер будет соединяться с локальными туннелями, висящими на портах, которые соответствуют рабам ldap:
stunnel -c -d 9636 -r slave1.test.ru:636 stunnel -c -d 10636 -r slave2.test.ru:636
И это все! Если вторичный сервер не сможет пробиться к основному (например, электрик дядя Ваня дерзко перерубил оптоволокно), то клиент, подключенный к вторичному серверу, сможет читать информацию, но изменять ее не сможет. А если в результате боевых действий рухнул винт, то с любого вторичного сервера можно будет восстановить первозданную базу LDAP (какой она была до краха основного сервера). По такой распределенной схеме можно создавать сколь угодно большую сеть, так как основными являются запросы на чтение, и нагружаться будут вторичные сервера. Создание объектов ldap. Файлы схем. LDAP, как уже было сказано, является расширяемой объектно-ориентированной системой, и вы можете добавлять новые классы с новыми атрибутами в базу LDAP. Для этой цели существуют файлы схем. В файле схемы описываются классы и их атрибуты, чтобы подключить схему к LDAP необходимо прописать в файле slapd.conf полный путь к нужной схеме. По умолчанию к LDAP подключены несколько основных схем, существуют также сторонние схемы, например, для самбы или некоторых почтовых серверов. Чтобы эти схемы использовать, в slapd.conf прописывают нечто подобное:
- Включаем схемы по умолчанию командой include
include /usr/share/openldap/schema/core.schema include /usr/share/openldap/schema/cosine.schema include /usr/share/openldap/schema/inetorgperson.schema
- Включаем схему самбы
include /usr/share/openldap/schema/samba.schema
- Включаем свою схему
include /usr/share/openldap/schema/my_cool.schema
Теперь разберемся, как эти схемы создавать. Если вы откроете какую-нибудь схему, то сначала все покажется доволно жутким. Хочу сразу же вас обрадовать: это действительно жутко! Чтобы хоть чего-то объяснить расскажу об OID. OID (уникальный идентификатор объекта) используется LDAP, чтобы не было наложений классов и их атрибутов. OID состоит из числовых значений разделенных точкой и составляющих в целом иерархию OID(для знакомых с протоколом SNMP эта терминология покажется привычной): 1.1 OID данной организации(выбирается любой) 1.1.2 Сами идентификаторы LDAP 1.1.2.1 Атрибуты классов 1.1.2.1.1 Конкретный атрибут(меняем последнюю цифру для каждого атрибута) 1.1.2.2 Сами классы 1.1.2.2.1 Конкретный класс Для получения OID можно зайти на узел www.iana.org (начинается с 1.3.6.1.4). Вообще, как я понял, составление иерархии OID — дело довольно геморройное. Проще всего взять какой-либо OID для атрибутов (обычной базой OID является 1.3.6.1.4) и для классов, а затем просто добавить еще несколько цифр. А вообще, лучше просто посмотреть, как сделано в готовых схемах и не парить мозги(я думаю, что изменить последние пару чисел готового OID не составит труда, а описывать это мне представляется совершенно ненужным). После сочинения OIDов перейдем к добавлению новых атрибутов. Для этой цели используется директива attributetype. Вот как выглядят описания атрибутов в схеме самбы (приведен маленький фрагмент):
attributetype ( 1.2.840.113556.1.4.8 NAME 'userAccountControl' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
attributetype ( 1.2.840.113556.1.4.166 NAME 'groupMembershipSAM' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE )
attributetype ( 1.2.840.113556.1.4.213 NAME 'defaultClassStore' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
Как видно в скобках идет вначале OID атрибута, затем NAME и имя атрибута в кавычках, а затем тип атрибута. Вот тут немного остановлюсь. Видно, что тип атрибута — это также OID(ужас-то какой, но это позволяет добавлять даже свои типы). Стандартно предопределено несколько типов: логический — 1.3.6.1.4.1.1466.115.121.1.7 имя LDAP(DN) — 1.3.6.1.4.1.1466.115.121.1.12 строка формата UTF-8 — 1.3.6.1.4.1.1466.115.121.1.15 строка ASCII — 1.3.6.1.4.1.1466.115.121.1.26 целое — 1.3.6.1.4.1.1466.115.121.1.27 DN и идентификатор пользователя (UID) — 1.3.6.1.4.1.1466.115.121.1.34 строка из чисел — 1.3.6.1.4.1.1466.115.121.1.36 OID — 1.3.6.1.4.1.1466.115.121.1.38 Кроме типа атрибута, можно указывать дополнительные его параметры: DESC — строка (обычный текст), которая описывает данный атрибут; SUP — строка (имя) или OID родительского атрибута (происходит наследование синтаксиса родительского атрибута); EQUALITY — строка (наименование) или OID метода поиска, например, caseIgnoreMatch для поиска данного атрибута без учета регистра; SINGLE-VALUE — просто флаг (после него должен обязательно стоять пробел!), который указывает, что данный атрибут может принимать только единственное значение(по умолчанию можно присваивать атрибуту несколько значений); NO-USER-MODIFICATION — флаг, запрещающий модификацию данного атрибута пользователем (по умолчанию модификация разрешена) При составлении схемы учтите, что после каждой лексемы (включая скобки и флаги) должен идти один пробел. Приведу пример составления атрибута картинки,как пути к jpg файлу:
attributetype ( 1.1.2.1.2 NAME 'pic' DESC 'my jpeg picture' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
И, например, картинки на сайте, представленной в виде URL:
attributetype ( 1.1.2.1.3 NAME 'URLpic' DESC 'URL to picture' SUP pic )
Создание нового класса IMHO несколько проще, приведу пример класса cronEntry из cron.schema:
objectclass ( 1.3.6.1.4.1.7006.1.3.2.1 NAME 'cronEntry' SUP top STRUCTURAL MUST ( cn $ cronCommand $ uid ) MAY ( cronHost $ cronMinute $ cronHour $ cronDay $ cronMonth $ cronDayOfWeek $ owner $ description ) )
Вначале идет OID, имя (не забудьте кавычки), родительский класс (наследуются атрибуты), тип класса [для знакомых с объектно-ориентированной моделью объясняю: ABSTRACT — абстрактный (нельзя делать объекты данного класса, можно только наследовать) и STRUCTURAL — обычный (по умолчанию)]. Далее идут поля атрибутов для класса: MUST — обязательные атрибуты, MAY — необязательные. Список атрибутов заключается в скобки и разделяется по странной прихоти не запятыми, а знаками доллара (очевидно, это намек разработчиков). Думаю, тут можно еще раз напомнить о необходимости пробелов после каждой лексемы (и долларов тоже). Вот видите, создание объектов — не такая уж и тяжелая вещь. Примеров приводить не буду, т.к. класс cronEntry является идеальным объектом для рассмотрения. Честно говоря, я бы все-таки рекоммендовал бы всем, кто собирается создавать новую схему, посмотреть существующие, т.к. во-первых, необходимо убедиться в уникальности OID, а во-вторых, меньше будет ошибок в своей схеме :) В качестве заключения. Я думаю, что если у вас в распоряжении находится крупная сеть, то применение LDAP является идеальным решением централизованного управления аутентификацией на всех уровнях. Использование реплик делает LDAP надежным, а хорошие методы шифрования обеспечивают приличную степень безопасности. Кроме этого LDAP является довольно быстрым механизмом поиска и, что очень важно, хранит все в древовидной базе данных. Для небольших сетей, я думаю, лучше использовать текстовые файлы: просто и сердито, а главное быстрее, чем LDAP. Но в крупных сетях это приведет к тихому ужасу, связанному с конфликтами разных пользователей, машин, серверов. Я сам был свидетелем сетки из ~1000 машин, соединенных банальной сеткой мелкомягких (без доменов!), где NovellNetware использовалась лишь как файл-сервер. LDAP и самба в этом случае снимают большинство этих проблем. Итак, на этот раз все. В следующий раз я расскажу о популярных LDAP-клиентах и серверах, о создании собственных клиентов. Список полезных ссылок: www.tldp.org — LDAP HOWTO и LDAP-implementation HOWTO. www.openldap.org — ldap guide(aka HOWTO, обычно самое новое руководство). www.mandrakesecure.net/en/docs/ldap-auth.php — очень приличная статья Vincent Danena, которая описывает принципы настройки ldap. www.opennet.ru — статья по работе с LDAP на русском языке, но она довольно старая, хотя там немало полезного материала. www.rojkov.spb.ru — пожалуй единственный, но, к сожалению, еще молодой сайт в рунете, содержащий информацию об LDAP. Список документов rfc, посвященных использованию ldap: 1777 LDAP v2. 2251 LDAP v3(используется в текущей версии openldap). 2252 LDAP v3 определения атрибутов. 2253 LDAP v3 использование строк UTF-8 . 2254 Формат строки поиска. 2255 Формат LDAP URL. 2256 Использованные части протокола X.500 в LDAP v3. 2307 Использование LDAP в качестве NIS. Для получения документов rfc я обычно пользуюсь таким алиасом tcsh: alias rfcget 'ncftpget ftp://ftp.isi.edu/in-notes/rfc\!^.txt' К сожалению, в данной статье я упустил из виду некоторые вещи по работе с LDAP, например, работа с SASL, Kerberos, описание програмных компонентов ldap. Постараюсь закрыть эти недостатки в следующих статьях. LDAP — довольно сложная система, поэтому охватить все не удалось :( Надеюсь, что кому-то мои труды пошли на пользу.
Вернуться к списку статей >>
новости новости nixp.ru в формате RSS / программы / статьи / форум / ссылки / о проекте
Идея, создание и поддержка сайта — Дмитрий Шурупов. © nixp.ru 2001—2007.
Полное или частичное использование любых материалов с сайта допустимо только с разрешения авторов. При полном или частичном использовании любых материалов с сайта вы обязаны явным образом указывать наш сайт (http://www.nixp.ru) в качестве источника.
