Központilag történő hitelesítés az OpenLDAP használatával
Ez az útmutató bemutatja az LDAP alapjait, és megmutatja az olvasóknak, hogy miként kell beállítani az OpenLDAP-ot a számítógépek csoportja közötti hitelesítés céljából.
Az aktuális állapot nem eredményez működő konfigurációt. A részletekért tekintse meg a Talk:Centralized_authentication_using_OpenLDAP megbeszélést. A munka folyamatban van.
Az OpenLDAP használatának megkezdése
Mi az LDAP?
Az LDAP (Lightweight Directory Access Protocol) jelentése: könnyűsúlyú könyvtári hozzáférési protokoll. Az X.500 alapján az elsődleges funkcióinak nagy részét magában foglalja, de hiányzik az ezoterikus funkciók, amelyek az X.500 -at tartalmazzák. Most akkor mi ez az X.500, és miért létezik az LDAP?
Az X.500 egy modell az OSI koncepciójában létező könyvtári szolgáltatások (Directory Services) számára. Névtér-definíciókat, valamint a könyvtár lekérdezéséhez, és frissítéséhez szükséges protokollokat tartalmazza. Az x.500 modell sok esetben túlzásnak bizonyult. Az LDAP az X.500 modellhez hasonlóan adat/névtér-modellt biztosít a könyvtárhoz és egy protokollhoz. Az LDAP modellt azonban úgy tervezték, hogy az közvetlenül a TCP/IP stack-en keresztül fusson. Tekintsen az LDAP modellre úgy mint ha az az X.500 modell egy karcsúbb, könnyebben használhatóbb verziója lenne.
Mi a könyvtár?
A könyvtár egy specializált adatbázis, amit gyakori lekérdezésekhez, de ritka frissítésekhez terveztek. Az általános adatbázisoktól eltérően a könyvtárnak nincs tranzakciós támogatása, és nincs visszavonható funkciója sem. A könyvtárak könnyen replikálhatóak a rendelkezésre állás és a megbízhatóság növelése érdekében. Amikor a könyvtárakat replikálják, akkor az ideiglenes inkonzisztenciák megengedettek, amíg végül szinkronizálódnak.
Hogyan épül fel az információ?
A könyvtáron belüli összes információ hierarchikusan van felépítve. Még ennél is hierarchikusabb az adatok beírása a könyvtárba. A könyvtárnak tudnia kell, hogyan kell ezeket az adatokat egy fában tárolnia. Vessen egy pillantást egy kitalált cégre és egy internet-szerű fára:
dc: org
|
dc: genfic ## (Szervezet, "Organisation")
/ \
ou: People servers ## (Szervezeti egységek, "Organisational Units")
/ \ ..
uid: .. John ## (OU-specifikus adat, "OU-specific data")
Mivel az adatokat nem a példában látott ASCII-rajz szerűen adják be az adatbázisba, ezért egy ilyen képzeletbeli fát, húgy építenek el, hogy minden csomópontját meghatározzák a valóságban. A képzeletbeli fa csomópontjainak a megnevezéséhez az LDAP egy előre meghatározott elnevezési sémát használ. A legtöbb LDAP-disztribúció (beleértve az OpenLDAP-ot is) már sok előre meghatározott (és általános jóváhagyott) sémát tartalmaz, úgy mint például az inetOrgPerson, vagy egy gyakran használt sémát a felhasználók meghatározására, amelyeket az UNIX/Linux számítógépek használhatnak, amelyeket posixAccount néven említenek. Megjegyzés: Vannak grafikus felhasználói felülettel (GUI-val) rendelkező web alapú eszközök is az LDAP könnyebb kezelése érdekében: Tekintse meg a Munka az OpenLDAP-al című leírást a nem teljes értékű lista tanulmányozásának az érdekében.
Az érdeklődő felhasználókat arra ösztönözzük, hogy olvassák el az OpenLDAP rendszergazdai útmutatóját.
Mire használható?
Az LDAP különféle dolgokhoz használható. Ez a dokumentum a központosított felhasználói menedzsmentre összpontosít, és az összes felhasználói fiókot egyetlen LDAP helyen tartja (ami nem azt jelenti, hogy egyetlen szerveren helyezkedik el, az LDAP támogatja a magas rendelkezésre állást és a redundanciát), mégis más célokat lehet elérni az LDAP segítségével is.
- Nyilvános kulcsú infrastruktúra.
- Megosztott naptár.
- Megosztott címjegyzék.
- Tárhely a DHCP, DNS, stb. számára.
- Rendszerosztályú konfigurációs direktívák (több szerverkonfiguráció nyomon követése).
- Központi hitelesítés (PosixAccount).
- Stb...
Az OpenLDAP szerver beállítása
Közös megjegyzések
A genfic.org nevű domén egy példa ebben az útmutatóban. A domént az olvasók számára át lehet átnevezni. Győződjön meg arról, hogy a felső csomópont egy hivatalos legfelső szintű tartománynéz (.net, .com, .cc, .be, stb.). Mivel az LDAP nem biztosít titkosítást az adat transzfer során, ezért szükségesek a TLS szerver-tanúsítványok létrehozása. Általános gyakorlat, hogy összekapcsoljuk a DNS szervert, a CN tanúsítványt, és az LDAP CN-t. Ebben a példában a szerver az ldap.genfic.org doménen lesz elérhető, kizárólag az ldaps:// (protokoll) által. A szerver tanúsítvány pontosan erre a gazdagépre lesz vonatkoztatva, tehát CN=ldap.genfic.org. A TLS-hez tekintse meg a Tanúsítványokat és a Certificates/Become your own CA leírást.
USE flags for net-nds/openldap LDAP suite of application and development tools
+berkdb
|
Add support for sys-libs/db (Berkeley DB for MySQL) |
+cleartext
|
Enable use of cleartext passwords |
+syslog
|
Enable support for syslog |
argon2
|
Enable password hashing algorithm from app-crypt/argon2 |
autoca
|
Automatic Certificate Authority overlay |
crypt
|
Add support for encryption -- using mcrypt or gpg where applicable |
cxx
|
Build support for C++ (bindings, extra libraries, code generation, ...) |
debug
|
Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces |
experimental
|
Enable experimental backend options |
gnutls
|
Prefer net-libs/gnutls as SSL/TLS provider (ineffective with USE=-ssl) |
iodbc
|
Add support for iODBC library |
ipv6
|
Add support for IP version 6 |
kerberos
|
Add kerberos support |
kinit
|
Enable support for kerberos init |
minimal
|
Build libraries & userspace tools only. Does not install any server code |
odbc
|
Enable ODBC and SQL backend options |
overlays
|
Enable contributed OpenLDAP overlays |
pbkdf2
|
Enable support for pbkdf2 passwords |
perl
|
Add optional support/bindings for the Perl language |
samba
|
Add support for SAMBA (Windows File and Printer sharing) |
sasl
|
Add support for the Simple Authentication and Security Layer |
selinux
|
!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur |
sha2
|
Enable support for pw-sha2 password hashes |
smbkrb5passwd
|
Enable overlay for syncing ldap, unix and lanman passwords |
ssl
|
Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security) |
static-libs
|
Build static versions of dynamic libraries as well |
systemd
|
Enable use of systemd-specific libraries and features like socket activation or session tracking |
tcpd
|
Add support for TCP wrappers |
test
|
Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) |
Először hozzuk létre, majd telepítsük az emerge parancs segítségével az OpenLDAP programcsomagot. Tehát győződjünk meg az USE jelölőzászlók állapotáról, syslog
beállítása, valamint a -minimal
beállítása (mínusz előjellel, tehát kikapcsolva). Majd jöhet a telepítés:
root #
emerge --ask net-nds/openldap
Az OpenLDAP két hitelesítési mechanizmust támogat:
- Standard felhasználói-jelszó (LDAP kifejezések szerint az user az binddn-t jelent) SIMPLE-nek nevezve.
- A hitelesítési kérések proxy-n keresztül az SASL-nek (Simple Authentication and Security Layer, tekintse meg a RFC4422 leírást).
Noha az OpenLDAP alapértelmezetten a SASL használatára van beállítva, ennek a cikknek a kezdeti verziója csak jelszó-alapú hitelesítést használt. Az OLC kiegészítőnek a használatától már ez a cikk elkezd a legegyszerűbb SASL mechanizmusról beszélni, amit EXTERNAL -nak nevez, amely a rendszer hitelesítésére támaszkodik. Ez csak a gazdagépre korlátozódik, amelyen a fut a szerver.
Az OpenLDAP-nak van egy fő felhasználója, a "rootdn" (Root Distinguished Name), amelyet az bele van "hardkódolva" az alkalmazásba. A klasszikus Unix root felhasználóval ellentétben a rootdn felhasználónak továbbra is a megfelelő jogosultságokkal kell rendelnie. A rootdn felhasználó csak a konfiguráció összefüggésében használható, és a könyvtárhoz tartozó definíciókban használható. Ebben az esetben a felhasználó hitelesítheti magát a rootdn felhasználóként, akár a konfigurációval használt jelszóval, akár a fa (könyvtár-alapú) jelszavával.
A felhasználói jelszavak (függetlenül attól, hogy rootdn vagy más felhasználók) ellenőrzési célokra egyszerű szöveges formában vagy hash formában is tárolhatók. Több különböző hash algoritmus áll rendelkezésre, de a gyenge algoritmusok (például az MD5) használata nem ajánlott. Az SHA titkosítást a cikk írásának pillanatában kriptográfiailag biztonságosnak tekintik.
Az alábbi paranccsal egy hash értéket hoz létre egy adott jelszóhoz. Ennek a parancsnak az eredménye használható a slapd.conf konfigurációs fájlban, illetve ugyan ez a hash érték a felhasználóhoz tartozó belső könyvtár meghatározásához is felhasználható:
root #
slappasswd
New password: my-password Re-enter new password: my-password {SSHA}EzP6I82DZRnW+ou6lyiXHGxSpSOw2XO4
A régmúltban alkalmazott konfigurációs eljárás (flat slapd.conf konfigurációs fájl)
2021-től kezdve nem használják ezt a módszert. Ne használja ön se ezt a módszert! Az se nem jó megoldás, hogy ha az OpenLDAP eszközökkel átalakítja az LDIF-et. Nem megfelelően fog átfordulni.
Most szerkessze az LDAP szerver konfigurációját az /etc/openldap/slapd.conf fájlban. A bemutatott slapd.conf fájl az eredeti OpenLDAP forrásból származik. Az alábbiakban egy minta konfigurációs fájl látható, ami használható a dolgok elindításához.
/etc/openldap/slapd.conf
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
## ## ServerID used in case of replication
serverID 0
loglevel 0
## ## Certificate/SSL Section
TLSCipherSuite normal
TLSCACertificateFile /etc/openldap/ssl/ldap.crt
TLSCertificateFile /etc/openldap/ssl/ldap.pem
TLSCertificateKeyFile /etc/openldap/ssl/ldap.key
TLSVerifyClient never
## ## Access Controls
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
by self write
by users read
by anonymous read
## ## Database definition
database mdb
suffix "dc=genfic,dc=org"
checkpoint 32 30
maxsize 10485760
#Note: It is important to set this to as large a value as possible,
#(relative to anticipated growth of the actual data over time)
#since growing the size later may not be practical when the system is under heavy load.
rootdn "cn=Manager,dc=genfic,dc=org"
## ## rootpwd generated earlier via slappasswd command
rootpw "{SSHA}EzP6I82DZRnW+ou6lyiXHGxSpSOw2XO4"
directory "/var/lib/openldap-data"
index objectClass eq
## ## Synchronisation (pull from other LDAP server)
syncrepl rid=001
provider=ldap://ldap2.genfic.org
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=genfic,dc=org"
attrs="*,+"
bindmethod="simple"
binddn="cn=ldapreader,dc=genfic,dc=org"
credentials="ldapsyncpass"
index entryCSN eq
index entryUUID eq
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10
Ne feledje el hogy, a második csomópontnak a rid másmilyen értékét kell használnia, és a megfelelő címet kell használni az ldapuri szolgáltatóban.
A konfigurációs fájl részletesebb elemzéséhez tekintse meg az OpenLDAP rendszergazdáknak szánt útmutatóját az upstream projekt dokumentációs oldalán, bár elég lehet az man 5 slapd.conf elolvasása is.
Ha nem indul el, akkor az első lépés a konfigurációs fájl ellenőrzése:
user $
slaptest -v -d 1 -f /etc/openldap/slapd.conf
Változtassa meg a hibakeresési szintet további információkért (fent a -d 1
jelöli). Ha minden jól megy, akkor megjelenik a konfigurációs fájl teszteléséne sikeres. Ha hiba van, akkor a slaptest felsorolja a slapd.conf fájlban lévő hibás sornak a sorszámát.
Alapértelmezés szerint a slapd a local4 rendszernaplóhoz írja a naplóeseményeket.
Vegye figyelembe, hogy a 2.4.23-as verzió óta az OpenLDAP alapértelmezése végül a hagyományos egyszerű konfigurációs fájlokról (slapd.conf) az OLC -re (OnLineConfiguration, a
cn=config
szerkezetén keresztül is ismert) alapértelmezésre váltott. Az OLC használatának egyik előnye, hogy a dinamikus backend (cn=config
) nem igényli a szerver újraindítását a konfiguráció frissítése után. A meglévő felhasználók áttérhetnek az új konfigurációs módszerre, ha meghívják a slaptest parancsot a -f
és a -F
beállított opcióival. Hagyományosan az OLC-t az ldif backend-ben (amelyek az emberi olvashatóság előnyeit megtartják) az /etc/openldap/slapd.d könyvtárban tárolják. A Gentoo-ban még nem kell konvertálni a konfigurációt, de a jelenleg dokumentált megközelítés támogatása a jövőben el lesz távolítva.Migráció a slapd.conf használatáról az OLC formátum használatára
A következő szakasz teljesen használhatatlan, és hamarosan javulni fog. A következő szakasz helyett kövesse a tisztességes alapvető LDIF-alapú beállítási útmutatót. Az olcGlobal beállítást objectClass: moduleList, back_mdb.so vagy back_bdb.la, az USE objectClass beállítástól függően: olcSchemaConfig, nis.ldif és az ilyen fához tartozó adatbázis konfigurációjától függően, beleértve olvasói szerep, a névtelen olvasmányok megtagadása és így tovább, létrehoz egy alap DN/ objectclass=organization-et, olyan eszközök nélkül, mint például a phpldapadmin, egyáltalán nem fog működni a beállítási szervezeteknél, hogy tovább csoportosítsák az objectClass -ot, észszerű szubstruktúrát, a csoportos importálást releváns Gentoo csoportokkal, pl. A wheel, audio, usb, asztali felhasználók meglehetősen korlátozottak lesznek egy eszközhasználat, akár csak ideiglenesen, hogy még egy vagy két felhasználót hozzanak létre.
Az OpenLDAP szerver konfigurációjának megváltoztatásához legalább write
(vagy normál esetben manage
) hozzáférést kell megadni a cn=config
-hoz.
Az alábbi példa bemutatja, hogyan adhatunk felügyeleti hozzáférést az OLC-hoz (cn=config adatbázis) a rendszer-adminisztrátoroknak (root felhasználónak) a megfelelő sorok hozzáadásával a slapd.conf fájl végéhez:
/etc/openldap/slapd.conf
Granting root Linux account manage rights to cn=configdatabase config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
Then, invoke the slaptest utility with the -f
and -F
options to convert the slapd.conf file into a configuration directory (slapd.d).
root #
mkdir /etc/openldap/slapd.d
root #
slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
root #
chown -R ldap /etc/openldap/slapd.d
Running this command will transfer and translate the configuration. After that you are expected to update the configuration using specially prepared ldif files. And only if you aren't enough familiar with them, you can first edit slapd.conf and after that re-translate the slapd.conf into slapd.d/. Don't forget to check the directory's permissions.
For more instructions read the in-line comments of the generated files.
The below line will enable the slapd.d/ configuration method.
/etc/conf.d/slapd
OPTS="-F /etc/openldap/slapd.d -h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"
Finally, create the /var/lib/openldap-data structure:
root #
mkdir -p /var/lib/openldap-data
root #
chown -R ldap:ldap /var/lib/openldap-data
root #
chmod -R 0700 /var/lib/openldap-data
Initial setup with OLC
An initial configuration is shipped as a standard LDAP database dump, available as slapd.ldif or config.ldif.
To include additional schemas, flat schema files should be converted into ldif format. Custom scheme must also be converted into ldif format. See openldap.ldif for more detailed description.
{{{1}}}
This initial configuration can be loaded (and only loaded, unlike ordinary LDAP databases) by the slapadd utility:
root #
slapadd -d -1 -F /etc/openldap/slapd.d -n 0 -l /etc/openldap/config.ldif
When using a root account, be sure to correct ownership of the files created by root, as described below in migrate section.
The default configuration does not provide permissions to change the server's configuration to anybody.
For the right to change the configuration database, proper permissions must be provided. The next example shows how these privileges are granted to the root system user:
config-access.ldif
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
A további részletekért tekintse meg a man 5 slapd-config súgót.
This database configuration must be added between
dn: olcDatabase=frontend,cn=config
and dn: olcDatabase=mdb,cn=config
, because each part requires the previous to exist and creates a default one if not.When using OLC, never manually edit the configuration files. The directory files can be used to check the consistency of the configuration through:
root #
slaptest -v -d 1 -F /etc/openldap/slapd.d
A könyvtár karbantartása
Indítsa el a slapd
programot most, miután a konfigurációs lépések befejeződtek:
root #
service slapd start
A legtöbb felhasználó azt is szeretné, ha az OpenLDAP szolgáltatás automatikusan elindulna:
root #
rc-update add slapd
most már lehetséges a címtárszerver használata a felhasználók hitelesítésére az apache/proftpd/qmail/samba fájlban.
The directory server can be managed with tools such as net-nds/phpldapadmin, app-admin/diradm and net-nds/jxplorer from the Gentoo ebuild repository, or app-misc/ldapexplorertool from the poly-c overlay available through eselect repository.
Server management with OLC
One of the benefits of using OLC-style configuration is that the LDAP server does not require a restart to apply configuration changes.
Some examples of updates on the OLC-style configuration are mentioned below.
For instance, to change the location of the OLC configuration directory (needed after switching from a config file to config directory style):
fix-configs.ldif
dn: cn=config
changetype: modify
delete: olcConfigFile
dn: cn=config
changetype: modify
replace: olcConfigDir
olcConfigDir: /etc/openldap/slapd.d
To change the log level used by the OpenLDAP instance:
loglevel.ldif
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats stats2 sync
In order to apply the changes, run the following command:
root #
ldapmodify -Y EXTERNAL -H ldapi:/// -f loglevel.ldif
SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config"
On restart, the init script performs a check of the updated configuration. The ldapmodify command used above blocks only fatal errors. To get info about non-fatal errors using OLC:
root #
slaptest -F /etc/openldap/slapd.d
58b7d4c2 olcThreads: value #0: warning, threads=64 larger than twice the default (2*16=32); YMMV. config file testing succeeded
OpenLDAP naplózása
Az OpenLDAP számos naplóeseményt hoz létre, amelyek értelmezése nem feltétlenül egyértelmű, de a hibakereséshez szükségesek.
Mivel az OpenLDAP alapértelmezés szerint a naplóeseményeket a rendszernaplóba írja, ezért célszerű a rendszernaplózót újra beállítani, hogy az OpenLDAP naplóeseményeket egy dedikált naplófájlba irányítsa bele.
It is advisable to use the stats stats2
log level in OpenLDAP standalone server and stats stats2 sync
in OpenLDAP cluster. In such case query results logs session-related information such as the following:
root #
grep conn=1 /var/log/slapd.log
Mar 9 12:26:47 ldap1 slapd[95182]: conn=1 fd=14 ACCEPT from IP=192.168.100.9:55655 (IP=192.168.1.1:389) Mar 9 12:26:47 ldap1 slapd[95182]: conn=1 op=0 BIND dn="" method=128 Mar 9 12:26:47 ldap1 slapd[95182]: conn=1 op=0 RESULT tag=97 err=0 text= Mar 9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SRCH base="ou=People,dc=genfic,dc=org" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=1001))" Mar 9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass shadowLastChange shadowMax shadowExpire Mar 9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 ENTRY dn="uid=larry,ou=People,dc=genfic,dc=org" Mar 9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
A szervernaplóban a err=49
hibák a leggyakoribbak:
/var/log/slapd.log
Aug 10 12:47:27 ldap-2 slapd[32920]: conn=1004 op=0 RESULT tag=97 err=49 text=
Ami azt jelenti, hogy «érvénytelenek a hitelesítő adatok» (azaz rossz a jelszó).
Valamint a err=32
hiba:
/var/log/slapd.log
Aug 10 14:15:35 ldap-2 slapd[32966]: conn=1085 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
Ami azt jelenti, hogy «Nincs ilyen objektum». Általában ez a hiba akkor jelenik meg, ha a binddn (felhasználó) nem rendelkezik jogosultságokkal a kért objektumhoz. Tehát vagy megpróbált valamit rosszul csinálni, vagy hiba van a beállított ACL-ben.
Access management (ACL-ek)
The authorizations and access control mechanism used in OpenLDAP is described in the slapd.access manual page. Its base syntax is as follows:
access to <what> [ by <who> [ <access> ] [ <control> ] ]+
Az alábbi táblázat az OpenLDAP-ban lévő hozzáférési szinteket mutatja:
Access level | Privileges | Description |
---|---|---|
none | 0 | no access |
disclose | d | needed for information disclosure on error |
auth | dx | needed to authenticate (bind) |
compare | cdx | needed to compare |
search | scdx | needed to apply search filters |
read | rscdx | needed to read search results |
write | wrscdx | needed to modify/rename |
manage | mwrscdx | needed to manage |
A jogosultságok beállításaival kapcsolatos pontos részletekért tekintse meg a kézikönyvet és a hivatalos OpenLDAP dokumentációt.
Ne feledje, hogy a rootdn felhasználó mindent tud olvasni és írni.
Konfigurációs fájl
ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. For more information, see Access Control Evaluation.
Például:
/etc/openldap/slapd.conf
…
access to attrs=userPassword
by dn="cn=ldapreader,dc=genfic,dc=org" read
by self read
by anonymous auth
by * none
access to dn.base="cn=Subschema" by users read
access to dn.base="" by * read
…
Konfigurációs könyvtár
ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. This order, when using OLC, is handled through the olcAccess
directives.
Például:
add_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to dn.base="cn=subschema" by users read
olcAccess: {1}to dn.base="" by * read
The following example inserts a new ACL on top, making the existing olcAccess
entries to shift by one:
insert_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword
by dn="cn=ldapreader,dc=genfic,dc=org" read
by self read
by anonymous auth
by * none
Az ACL törléséhez:
delete_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}
Replikáció
Magas rendelkezésre állás
Az OpenLDAP általános magas rendelkezésre állású beállítása a változtatások replikációja több LDAP rendszeren keresztül.
Replication within OpenLDAP is, in this guide, set up using a specific replication account ( ldapreader
) which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secondary.
This setup is then mirrored, allowing the secondary LDAP server to act as a primary. Thanks to OpenLDAP's internal structure, changes are not re-applied if they are already in the LDAP structure.
Az OpenLDAP klaszter upstream normál működéséhez ugyanazt a verziót ajánlja minden csomóponton.
Replikáció beállítása
To setup replication, first setup a second OpenLDAP server, similarly as above. However take care that, in the configuration file:
- The sync replication provider is pointing to the other system
- The serverID of each OpenLDAP system is different
Using a mirrored installation means that the OpenLDAP service should be configured like a single server installation, so the serverID value on each of the nodes must be the same. Instances are identified by rid values, which must be unique.
Synchronisation account
Next, create the synchronisation account. We will create an LDIF file (the format used as data input for LDAP servers) and add it to each LDAP server:
user $
slappasswd -s myreaderpassword
{SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM
ldapreader.ldif
dn: cn=ldapreader,dc=genfic,dc=org
userPassword: {SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: ldapreader
description: LDAP reader used for synchronization
user $
ldapadd -x -W -D "cn=Manager,dc=genfic,dc=org" -f ldapreader.ldif
Password: ## enter the administrative password
Enabling syncprov overlay
Overlay can be linked statically and dynamically. When it is built dynamically, you'll need to load module. For now in Gentoo it's usually built statically. To ensure type:
root #
/usr/lib64/openldap/slapd -VVV
@(#) $OpenLDAP: slapd 2.4.44 (Feb 28 2017 10:07:46) $ @larry:/var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44-abi_x86_64.amd64/servers/slapd </div> <div lang="en" dir="ltr" class="mw-content-ltr"> Included static overlays: syncprov Included static backends: config ldif bdb hdb
Load syncprov module (optional)
To load syncprov module, use the following ldif file:
syncprov-module-load.ldif
#Load the syncprov module.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
Setting up replication for database
Next step, mandatory for everybody, is to setup replication for database (must be done on both nodes):
syncprov-add-overlay.ldif
# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpCheckpoint: 100 10
olcSpSessionlog: 100
# Add indexes for replica to the frontend db.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
-
add: olcDbIndex
olcDbIndex: entryUUID eq
One of poorly-documented feature of
ldif
-backend is that it doesn't permit file deletion. So, you can add overlay, but cannot remove it.Final configuration
Finally, add replication's definition.
On node 1:
add-replication-node1.ldif
dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl:
rid=001
provider=ldap://ldap-2.genfic.org
binddn="cn=ldapreader,dc=genfic,dc=org"
bindmethod=simple
credentials="secret"
searchbase="dc=genfic,dc=org"
type=refreshAndPersist
timeout=0
network-timeout=0
retry="60 +"
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE
secret
traditionally means the password string.
On node 2:
add-replication-node2.ldif
add-replication-node2.ldif
dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl:
rid=002
provider=ldap://ldap-1.genfic.org
binddn="cn=ldapreader,dc=genfic,dc=org"
bindmethod=simple
credentials="secret"
searchbase="dc=genfic,dc=org"
type=refreshAndPersist
timeout=0
network-timeout=0
retry="60 +"
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE
The only difference is in server's ident (rid) and provider uri.
You need to load ldap database only on one node of cluster and should not load on another. The database will be replicated automatically after adding quoted definition.
If LDAP master (mirror node with initially loaded database) is unavailable (slapd daemon not started, or 389/tcp port is blocked by a packet filter) slapd daemon on secondary node fails to start with the following error message:
root #
tail -f /var/log/slapd.log
May 14 15:39:29 ldap2 slapd[1749]: olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow May 14 15:39:29 ldap2 slapd[1749]: config error processing olcDatabase={1}mdb,cn=config: <olcMirrorMode> database is not a shadow May 14 15:39:29 ldap2 slapd[1749]: slapd stopped. May 14 15:39:29 ldap2 slapd[1749]: connections_destroy: nothing to destroy.
Almost certainly the database will not fit into default limits. So, you will need to increase ldapreader
's limits. For example:
add_replicator-limits.ldif
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcLimits
olcLimits: dn.exact="cn=ldapreader,dc=genfic,dc=org" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
Database file note: replicated database size may be significantly different with origin. In my case about 300 megabytes ldif-dump is loaded into almost 900 megabytes mdb-data file and replicated in 1.5 gigabyte mdb-data file.
Performance tuning
Default daemon settings significantly limits LDAP server performance.
Symptoms
When server load fits system limit client applications fails with different kind of timeout errors.
In server log this produces error messages like following:
/var/log/slapd.log
May 17 15:56:11 ldap2 slapd[13834]: fd=76 DENIED from unknown (192.168.210.101)
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.allow: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.deny: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: fd=237 DENIED from unknown (192.168.77.130)
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.allow: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: daemon: accept(8) failed errno=24 (Too many open files)
Increasing OS limits
First, read ldap system user limits:
root #
su ldap -c 'ulimit -aHS' -s '/bin/bash'
core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 6981 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 6981 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
The first parameter, you need to increase, is the open files limit.
Maximum available value is described in Documentation/sysctl/fs.txt file of kernel documentation:
/usr/src/linux-4.9.95-gentoo/Documentation/sysctl/fs.txt
nr_open:
This denotes the maximum number of file-handles a process can
allocate. Default value is 1024*1024 (1048576) which should be
enough for most machines. Actual limit depends on RLIMIT_NOFILE
resource limit.
PAM system limits are stored in /etc/security/limits.conf file or, optionally, in /etc/security/limits.d/ directory. Daemons, started with sys-apps/openrc init system use these parameters (see sys-apps/openrc: start-stop-daemon should use system-services PAM stack for details), so you need just to put in the file:
/etc/security/limits.conf
ldap soft nofile 4096
ldap hard nofile 8192
And restart daemon.
For some unknown reasons, upstart init system together with systemd by design ignores system PAM settings i.e. /etc/security/limits.conf file. Users of systemd init in Gentoo please contact me to verify the solution.
The next limitation is sysctl's net.core.somaxconn
parameter.
During run time, this value can be updated via:
root #
sysctl -w net.core.somaxconn=256
net.core.somaxconn = 256
After verifying new value do not forget to fix it:
/etc/sysctl.conf
## For LDAP:
net.core.somaxconn = 256
And, possibly, some other application-specific parameters.
Configuring the OpenLDAP client tools
Edit the LDAP Client configuration file. This file is read by ldapsearch and other ldap command line tools.
/etc/openldap/ldap.conf
Add the followingBASE dc=genfic, dc=org
URI ldap://ldap.genfic.org:389/ ldap://ldap-1.genfic.org:389/ ldap://ldap-2.genfic.org:389/
TLS_REQCERT allow
TIMELIMIT 2
Test the running server with the following command:
user $
ldapsearch -x -D "cn=Manager,dc=genfic,dc=org" -W
If errors are received, try adding -d 255
to increase the verbosity and solve the issue.
Client configuration for centralized authentication
There are numerous methods/tools that can be used for remote authentication. Some distributions also have their own easy to use configuration tool. Below there are some in no particular order. It is possible to combine local users and centrally authorized accounts at the same time. This is important because, for instance, if the LDAP server cannot be accessed one can still login as root.
- SSSD (Single Sign-on Services Daemon). Its primary function is to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system. It provides PAM and NSS modules, and in the future will support D-Bus interfaces for extended user information. It also provides a better database to store local users as well as extended user data.
- Use
pam_ldap
to login to the LDAP server and authenticate. Passwords are not sent over the network in clear text.
- NSLCD (Name Service Look up Daemon). Similar to SSSD, but older.
- NSS (Name Service Switch) using the traditional
pam_unix
module to fetch password hashes over the network. To permit users to update their password this has to be combined with thepam_ldap
method.
The first two are demonstrated below with the minimum necessary configuration options to get working.
Client PAM configuration SSSD Method
Untested as of 2021
Here is the more direct method. The three files that are required to be edited are mentioned below.
/etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
domains = genfic
debug_level = 5
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[domain/genfic]
id_provider = ldap
auth_provider = ldap
ldap_search_base = dc=genfic,dc=org
ldap_tls_reqcert = never
# primary and backup ldap servers below [first server and],[second server]
ldap_uri = ldap://X.X.X.X,ldap://X.X.X.X
Add sss to the end as shown below to enable the lookup to be handed to the sssd system service. Once you have finished editing start the sssd daemon.
/etc/nsswitch.conf
Example nsswitch.conf with SSSD supportpasswd: files sss
shadow: files sss
group: files sss
netgroup: files sss
automount: files sss
sudoers: files sss
The last file is the most critical. Open an extra root terminal as a fallback before editing this. The lines that end with #
have been added to enable remote authentication. Note the use of pam_mkhomedir.so to support creating the user home directories.
/etc/pam.d/system-auth
Enable pam_sss support#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass #
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so #
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok #
password required pam_deny.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so #
Now try logging in from another box.
SSSD method could be used not only for LDAP-authentication, but also to use AD-authentication.
Client PAM configuration the pam_ldap module method
Before starting any change to the client side authentication configuration, make sure that the LDAP server can be reached and presents the correct information. The following steps assume a user Bert Ram was created in the LDAP with login name bertram. Exchange accordingly with a user from the LDAP instance. Use the manager role with caution. But at least check with the LDAP read user role and a user that will logon to the client(s) to be configured:
# Uses the manager role, prompts for Manager's password
# if you can't use the manager role change -D to reader role
ldapsearch -x uid=bertram -H ldaps://ldap.genfic.org -b "dc=genfic,dc=org" -D cn=Manager,dc=genfic,dc=org -W
</div>
<div lang="en" dir="ltr" class="mw-content-ltr">
# Make a member query for the initgroups with the user that will login
# tests also this user's password
ldapsearch -x '({{|}}(&(objectClass=posixAccount)(uid=bertram))({{&}}(objectClass=posixGroup)(memberUid=bertram)))' -H ldaps://ldap.genfic.org -b "dc=genfic,dc=org" -D "cn=Bert Ram,dc=genfic,dc=org" -W
First, configure PAM to allow LDAP authorization. Install sys-auth/nss-pam-ldapd so that PAM supports LDAP authorization. Then edit /etc/pam.d/system-auth and include the relevant lines so that local login is checked first. This gives safety with at least a local root login and a local user – created during Gentoo installation. Third /etc/nsswitch.conf must be edited to check LDAP in addition to local database and files option. Finally check login on one of the terminals before restarting the client/ logging out root and/ or current user.
sys-auth/pam_ldap in combination with sys-auth/nss_ldap is an alternative. It requires a globally readable /etc/ldap.conf which is questionable with recent OpenLDAP setups that prohibit anonymous binds. A readable plain text password is as good as anonymous binds. Also code did not change for a long time and some links are dead. Nevertheless it still works. Also ldap.conf on cliet systems may collide with other services.
root #
emerge --ask nss-pam-ldapd
Backup this file first. Copy to a safe place (outside /etc) in case you made changes. Make the copy read only, e.g. chmod 444 system-auth.copy
. Insert one statement for pam_ldap.so in each of the blocks for auth, account, password and session.
/etc/pam.d/system-auth
#%PAM-1.0
# anything before pam_unix left out
auth sufficient pam_unix.so ...
# ...after pam_unix, before pam_deny
auth sufficient pam_ldap.so minimum_uid=1000 use_first_pass
auth required pam_deny.so
# anything before pam_unix left out
account required pam_unix.so
# ...after pam_unix again, before pam_permit.so
account sufficient pam_ldap.so minimum_uid=1000
account required pam_permit.so
# anything before pam_unix left out
password sufficient pam_unix.so nullok md5 shadow use_authtok
# ...after pam_unix again, before pam_deny.so
password sufficient pam_ldap.so minimum_uid=1000 try_first_pass
password required pam_deny.so
# anything before pam_unix left out
session required pam_unix.so
session optional pam_ldap.so minimum_uid=1000
In /etc/nsswitch.conf each line for passwd, group, shadow and initgroups needs to be prepended with ldap:
/etc/nsswitch.conf
# Many explanations in comments before...
passwd: db files ldap
group: db files ldap
shadow: db files ldap
initgroups: db [SUCCESS=continue] files ldap
gshadow: files
# more statements afterwards
If initgroups lacks ldap as source users logging in with LDAP credentials will have only their primary group. All other groups like wheel, audio, video and so on will be missing.
Now change /etc/nslcd.conf. It should contain
- URI to contact LDAP server, use TLS/ ldaps:// by any means, otherwise passwords are transferred unencrypted
- Base (general) to lookup DNs
- Bind-DN (and secret) since anonymous binds are bad
- Base per group, passwd and/ or shadow in case your LDAP tree deviates from defaults (as mentioned in the file's comments)
- optional client certificates if you use mutual TLS
- mapping for group membership to memberUid if you use primary group with additional groups expressed by membership
{{{1}}}
Make sure that /etc/nslcd.conf is owned by nslcd and only readable by nslcd through
chmod 400
./etc/nslcd.conf
# shows only the lines that were edited/ mentioned above, there is plenty more
# well documented. Order of the lines stays the same.
# The user and group nslcd should run as.
uid nslcd
gid nslcd
uri ldaps://ldap.genfic.org/
base dc=genfic,dc=org
# a plain assumption for a user with only read permission on the LDAP
binddn userid=ldapreader,dc=genfic,dc=org
bindpw a plain text secret
# Reduce timeout from 30s to something sane otherwise login waits at least
# until timeout
bind_timelimit 2
# There are many other mappings for different schemas. Assuming you use
# posixAccount as schema member can be mapped to memberUid to add
# initgroups correctly
map group member memberUid
This is just a note and needs distinction between systemd and OpenRC, start nslcd:
root #
/etc/init.d/nslcd start
If the daemon started successfully, change to one of the console terminals. Return to the graphical session by pressing Ctrl+Alt+F7. Switch to one of the 6 login consoles by pressing Ctrl+Alt+F1..F6. At the login prompt, try user bertram.
Convert file userbase to LDAP
The link is broken. Other Linux distributions provide packages and patches.
Configuring OpenLDAP for centralized administration and management of common Linux/Unix items isn't easy, but thanks to some tools and scripts available on the Internet, migrating a system from a single-system administrative point-of-view towards an OpenLDAP-based, centralized managed system isn't hard either.
Go to https://www.padl.com/OSS/MigrationTools.html and fetch the scripts there. You'll need the migration tools and the make_master.sh script.
Next, extract the tools and copy the make_master.sh script inside the extracted location:
root #
mktemp -d
/tmp/tmp.zchomocO3Q
root #
cd /tmp/tmp.zchomocO3Q
root #
tar xvzf /path/to/MigrationTools.tgz
root #
mv /path/to/make_master.sh MigrationTools-47
root #
cd MigrationTools-47
The next step now is to migrate the information of the system to OpenLDAP. The make_master.sh script will do this, after it has been provided with the information regarding the LDAP structure and environment.
At the time of writing, the tools require the following input:
Input | Description | Example |
---|---|---|
LDAP BaseDN | The base location (root) of the tree. | dc=genfic,dc=org |
Mail domain | Domain used in e-mail addresses | genfic.org |
Mail host | FQDN of the mail server infrastructure. | smtp.genfic.org |
LDAP Root DN | Administrative account information for the LDAP structure. | cn=Manager,dc=genfic,dc=org |
LDAP Root Password | Password for the administrative account, cfr earlier slappasswd command. |
The tool will also ask which accounts and settings to migrate.
You don't need to make changes to pam.d/system-auth file.
Hibaelhárítás
Emerge hibák jelentkezése az LDAP-a történő konverzió után
If for any reasons local user accounts (i.e. /etc/passwd /etc/shadow) or groups (i.e. /etc/group) are deleted after converting the file userbase to LDAP, errors may be encountered relating to missing user (or group) while emerging certain packages.
Example of error while emerging www-servers/apache due to missing "apache" local user account:
Installing build system files make[1]: Leaving directory '/var/tmp/portage/www-servers/apache-2.4.41/work/httpd-2.4.41' [ ok ] chown: invalid user: ?apache:apache? * ERROR: www-servers/apache-2.4.41::gentoo failed (install phase): * fowners failed
In such cases, a workaround involves emerging the package using FEATURES=-network-sandbox. Doing so has potential security consequences so system users should remain in local files.
Köszönetnyilvánítás
We would like to thank Matt Heler for lending us his box for the purpose of this guide. Thanks also go to the cool guys in #ldap (webchat) on the Libera Chat IRC network.
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Benjamin Coles, Sven Vermeulen (SwifT) , Brandon Hale, Benny Chuang, jokey,
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.