Authentification auf Userebene und Webseiten gegen OpenLDAP unter CentOS 7.x
Natürlich wollen wir bei der Authentifikation unserer Cleints auf unseren zentralen OpenLDAP-Verzeichnisdienst zurückgreifen. Nachfolgend werden wir auf einige Beispiele eingehen.
- lokale Benutzer
Bei den betreffenden Clients wollen wir nun die Authentifizierung der einzelnen User nicht mehr gegen die lokale /etc/shadow laufen lassen, denn dazu müssten wir nun auf jedem Host die User manuell (nach)pflegen. Schließlich sollen die User, egal an welchem Host sie sich anmelden, immer auch das gleiche Passwort benutzen können. Nicht zuletzt aus diesem Gründen, haben wir uns für einen zentralen OpenLDAP-Server entschieden. - remote Benutzer
Melden sich unsere Nutzer an unseren Webseiten an, die eine Authentifikation zum Abruf der Seiten notwendig machen, sollen die User sich mit Ihrem bekannten Nutzerkennung und Passwort aus dem zentralen OpenLDAP-Verzeichnisdienst tun. Hierzu betrachetn wir die nötigen Konfigurationsmaßnahmen an den beiden Webservern Apache und NGiNX.
lokale Benutzer
Vertrauensmodelle in Public-Key-Infrastrukturen
Wir haben nun in der Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem die nötigen Root-Zertifikate und müssen nun nur noch unserem openldap-client mitteilen, diesen auch zu nutzen. Hierzu editieren wir nun die Konfigurationsdatei des openldap-clients.
# vim /etc/openldap/ldap.conf
- /etc/openldap/ldap.conf
# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 # Django: 2015-07-17 # defaul: unset # Definition des standardmässig abgefragten Teilbaums / Searchbase # Anfragen werden unterhalb von dc=nausch, dc=org ausgeführt BASE dc=nausch, dc=org # Definition des LDAP-Servers URI ldap://openldap.dmz.nausch.org #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # Django : 2015-07-17 # default: TLS_CACERTDIR /etc/openldap/certs # Django : 2015-07-16 # Pfad und Datei mit den vertrauenswürdigen Root-Zertifikaten # default: unset TLS_CACERT /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on
Zum Testen richten wir erneut eine Anfrage an unseren OpenLDP-Server.
# ldapsearch -W -x -b "dc=nausch,dc=org" "uid=django" \ -D "cn=Technischeruser,dc=nausch,dc=org" -LLL \ -H ldaps://openldap.dmz.nausch.org
Enter LDAP Password:
dn: uid=django,ou=People,dc=nausch,dc=org uid: django cn: django objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 16617 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/django gecos: django userPassword:: RGQ0bWRkMyE=
Installation
Als erstes installieren wir uns die benötigten Pakete, sofern diese nicht schon bei der initialen Installation unseres CentOS 7-Clients erfolgt ist.
# yum install nscd nss-pam-ldapd authconfig -y
Paketinhalte
Welche Pfade angelegt und welche Dateien bei der Installation der RPM-Pakete ins System kopiert wurden, sehen wir uns bei Bedarf und Interesse mit Hilfe des Befehls rpm und der passenden Option -qil an.
nscd
# rpm -qil nscd
Name : nscd Version : 2.17 Release : 78.el7 Architecture: x86_64 Install Date: Mo 20 Jul 2015 16:30:11 CEST Group : System Environment/Daemons Size : 183104 License : LGPLv2+ and LGPLv2+ with exceptions and GPLv2+ Signature : RSA/SHA256, Sa 14 Mär 2015 09:20:11 CET, Key ID 24c6a8a7f4a80eb5 Source RPM : glibc-2.17-78.el7.src.rpm Build Date : Do 05 Mär 2015 22:50:19 CET Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.gnu.org/software/glibc/ Summary : A Name Service Caching Daemon (nscd). Description : Nscd caches name service lookups and can dramatically improve performance with NIS+, and may help with DNS as well. /etc/nscd.conf /etc/sysconfig/nscd /lib/systemd/system/nscd.service /lib/systemd/system/nscd.socket /usr/lib/tmpfiles.d/nscd.conf /usr/sbin/nscd /var/db/nscd /var/db/nscd/group /var/db/nscd/hosts /var/db/nscd/passwd /var/db/nscd/services /var/run/nscd /var/run/nscd/group /var/run/nscd/hosts /var/run/nscd/nscd.pid /var/run/nscd/passwd /var/run/nscd/services /var/run/nscd/socket
nss-pam-ldapd
# rpm -qil nss-pam-ldapd
Name : nss-pam-ldapd Version : 0.8.13 Release : 8.el7 Architecture: x86_64 Install Date: Mo 20 Jul 2015 16:30:14 CEST Group : System Environment/Base Size : 416576 License : LGPLv2+ Signature : RSA/SHA256, Fr 04 Jul 2014 05:58:15 CEST, Key ID 24c6a8a7f4a80eb5 Source RPM : nss-pam-ldapd-0.8.13-8.el7.src.rpm Build Date : Di 10 Jun 2014 08:03:46 CEST Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://arthurdejong.org/nss-pam-ldapd/ Summary : An nsswitch module which uses directory servers Description : The nss-pam-ldapd daemon, nslcd, uses a directory server to look up name service information (users, groups, etc.) on behalf of a lightweight nsswitch module. /etc/nslcd.conf /etc/tmpfiles.d/nss-pam-ldapd.conf /usr/lib/systemd/system/nslcd.service /usr/lib64/libnss_ldap.so /usr/lib64/libnss_ldap.so.2 /usr/lib64/security/pam_ldap.so /usr/sbin/nslcd /usr/share/doc/nss-pam-ldapd-0.8.13 /usr/share/doc/nss-pam-ldapd-0.8.13/AUTHORS /usr/share/doc/nss-pam-ldapd-0.8.13/COPYING /usr/share/doc/nss-pam-ldapd-0.8.13/ChangeLog /usr/share/doc/nss-pam-ldapd-0.8.13/HACKING /usr/share/doc/nss-pam-ldapd-0.8.13/NEWS /usr/share/doc/nss-pam-ldapd-0.8.13/README /usr/share/doc/nss-pam-ldapd-0.8.13/TODO /usr/share/man/man5/nslcd.conf.5.gz /usr/share/man/man8/nslcd.8.gz /usr/share/man/man8/pam_ldap.8.gz /var/run/nslcd
authconfig
# rpm -qil authconfig
Name : authconfig Version : 6.2.8 Release : 9.el7 Architecture: x86_64 Install Date: Do 30 Apr 2015 22:33:35 CEST Group : System Environment/Base Size : 2215055 License : GPLv2+ Signature : RSA/SHA256, Sa 14 Mär 2015 08:37:03 CET, Key ID 24c6a8a7f4a80eb5 Source RPM : authconfig-6.2.8-9.el7.src.rpm Build Date : Do 05 Mär 2015 23:01:30 CET Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : https://fedorahosted.org/authconfig Summary : Command line tool for setting up authentication from network services Description : Authconfig is a command line utility which can configure a workstation to use shadow (more secure) passwords. Authconfig can also configure a system to be a client for certain networked user information and authentication schemes. /etc/pam.d/fingerprint-auth-ac /etc/pam.d/password-auth-ac /etc/pam.d/postlogin-ac /etc/pam.d/smartcard-auth-ac /etc/pam.d/system-auth-ac /etc/sysconfig/authconfig /usr/lib64/python2.7/site-packages/acutilmodule.so /usr/sbin/authconfig /usr/sbin/authconfig-tui /usr/sbin/cacertdir_rehash /usr/share/authconfig /usr/share/authconfig/authconfig-tui.py /usr/share/authconfig/authconfig-tui.pyc /usr/share/authconfig/authconfig-tui.pyo /usr/share/authconfig/authconfig.py /usr/share/authconfig/authconfig.pyc /usr/share/authconfig/authconfig.pyo /usr/share/authconfig/authinfo.py /usr/share/authconfig/authinfo.pyc /usr/share/authconfig/authinfo.pyo /usr/share/authconfig/dnsclient.py /usr/share/authconfig/dnsclient.pyc /usr/share/authconfig/dnsclient.pyo /usr/share/authconfig/msgarea.py /usr/share/authconfig/msgarea.pyc /usr/share/authconfig/msgarea.pyo /usr/share/authconfig/shvfile.py /usr/share/authconfig/shvfile.pyc /usr/share/authconfig/shvfile.pyo /usr/share/doc/authconfig-6.2.8 /usr/share/doc/authconfig-6.2.8/COPYING /usr/share/doc/authconfig-6.2.8/NOTES /usr/share/doc/authconfig-6.2.8/README.samba3 /usr/share/doc/authconfig-6.2.8/TODO /usr/share/locale/ar/LC_MESSAGES/authconfig.mo /usr/share/locale/as/LC_MESSAGES/authconfig.mo /usr/share/locale/ast/LC_MESSAGES/authconfig.mo /usr/share/locale/bal/LC_MESSAGES/authconfig.mo /usr/share/locale/bg/LC_MESSAGES/authconfig.mo /usr/share/locale/bn/LC_MESSAGES/authconfig.mo /usr/share/locale/bn_IN/LC_MESSAGES/authconfig.mo /usr/share/locale/bs/LC_MESSAGES/authconfig.mo /usr/share/locale/ca/LC_MESSAGES/authconfig.mo /usr/share/locale/cs/LC_MESSAGES/authconfig.mo /usr/share/locale/cy/LC_MESSAGES/authconfig.mo /usr/share/locale/da/LC_MESSAGES/authconfig.mo /usr/share/locale/de/LC_MESSAGES/authconfig.mo /usr/share/locale/el/LC_MESSAGES/authconfig.mo /usr/share/locale/en_GB/LC_MESSAGES/authconfig.mo /usr/share/locale/es/LC_MESSAGES/authconfig.mo /usr/share/locale/et/LC_MESSAGES/authconfig.mo /usr/share/locale/eu/LC_MESSAGES/authconfig.mo /usr/share/locale/fa/LC_MESSAGES/authconfig.mo /usr/share/locale/fi/LC_MESSAGES/authconfig.mo /usr/share/locale/fr/LC_MESSAGES/authconfig.mo /usr/share/locale/gl/LC_MESSAGES/authconfig.mo /usr/share/locale/gu/LC_MESSAGES/authconfig.mo /usr/share/locale/he/LC_MESSAGES/authconfig.mo /usr/share/locale/hi/LC_MESSAGES/authconfig.mo /usr/share/locale/hr/LC_MESSAGES/authconfig.mo /usr/share/locale/hu/LC_MESSAGES/authconfig.mo /usr/share/locale/hy/LC_MESSAGES/authconfig.mo /usr/share/locale/id/LC_MESSAGES/authconfig.mo /usr/share/locale/is/LC_MESSAGES/authconfig.mo /usr/share/locale/it/LC_MESSAGES/authconfig.mo /usr/share/locale/ja/LC_MESSAGES/authconfig.mo /usr/share/locale/ka/LC_MESSAGES/authconfig.mo /usr/share/locale/kn/LC_MESSAGES/authconfig.mo /usr/share/locale/ko/LC_MESSAGES/authconfig.mo /usr/share/locale/ku/LC_MESSAGES/authconfig.mo /usr/share/locale/lo/LC_MESSAGES/authconfig.mo /usr/share/locale/lv/LC_MESSAGES/authconfig.mo /usr/share/locale/mai/LC_MESSAGES/authconfig.mo /usr/share/locale/mk/LC_MESSAGES/authconfig.mo /usr/share/locale/ml/LC_MESSAGES/authconfig.mo /usr/share/locale/mr/LC_MESSAGES/authconfig.mo /usr/share/locale/ms/LC_MESSAGES/authconfig.mo /usr/share/locale/my/LC_MESSAGES/authconfig.mo /usr/share/locale/nb/LC_MESSAGES/authconfig.mo /usr/share/locale/nds/LC_MESSAGES/authconfig.mo /usr/share/locale/nl/LC_MESSAGES/authconfig.mo /usr/share/locale/nn/LC_MESSAGES/authconfig.mo /usr/share/locale/or/LC_MESSAGES/authconfig.mo /usr/share/locale/pa/LC_MESSAGES/authconfig.mo /usr/share/locale/pl/LC_MESSAGES/authconfig.mo /usr/share/locale/pt/LC_MESSAGES/authconfig.mo /usr/share/locale/pt_BR/LC_MESSAGES/authconfig.mo /usr/share/locale/ro/LC_MESSAGES/authconfig.mo /usr/share/locale/ru/LC_MESSAGES/authconfig.mo /usr/share/locale/si/LC_MESSAGES/authconfig.mo /usr/share/locale/sk/LC_MESSAGES/authconfig.mo /usr/share/locale/sl/LC_MESSAGES/authconfig.mo /usr/share/locale/sq/LC_MESSAGES/authconfig.mo /usr/share/locale/sr/LC_MESSAGES/authconfig.mo /usr/share/locale/sr@latin/LC_MESSAGES/authconfig.mo /usr/share/locale/sv/LC_MESSAGES/authconfig.mo /usr/share/locale/ta/LC_MESSAGES/authconfig.mo /usr/share/locale/te/LC_MESSAGES/authconfig.mo /usr/share/locale/tg/LC_MESSAGES/authconfig.mo /usr/share/locale/tr/LC_MESSAGES/authconfig.mo /usr/share/locale/uk/LC_MESSAGES/authconfig.mo /usr/share/locale/ur/LC_MESSAGES/authconfig.mo /usr/share/locale/vi/LC_MESSAGES/authconfig.mo /usr/share/locale/zh_CN/LC_MESSAGES/authconfig.mo /usr/share/locale/zh_HK/LC_MESSAGES/authconfig.mo /usr/share/locale/zh_TW/LC_MESSAGES/authconfig.mo /usr/share/man/man5/fingerprint-auth-ac.5.gz /usr/share/man/man5/password-auth-ac.5.gz /usr/share/man/man5/postlogin-ac.5.gz /usr/share/man/man5/smartcard-auth-ac.5.gz /usr/share/man/man5/system-auth-ac.5.gz /usr/share/man/man8/authconfig-tui.8.gz /usr/share/man/man8/authconfig.8.gz /usr/share/man/man8/cacertdir_rehash.8.gz /var/lib/authconfig
Dokumentation
Bei der nachfolgenden Konfiguration der Authentifikationsmechanismen greifen wir vor allem auf den Befehl authconfig zurück. Ein Blick in dessen Man-Page sollte hier also von großer Hilfe sein.
# man authconfig
AUTHCONFIG(8) System Manager's Manual AUTHCONFIG(8) NAME authconfig, authconfig-tui - an interface for configuring system authentication resources SYNOPSIS authconfig [options] {--update|--updateall|--test|--probe|--restorebackup <name>|--save‐ backup <name>|--restorelastbackup} DESCRIPTION authconfig provides a simple method of configuring /etc/sysconfig/network to handle NIS, as well as /etc/passwd and /etc/shadow, the files used for shadow password sup‐ port. Basic LDAP, Kerberos 5, and Winbind client configuration is also provided. If --test action is specified, the authconfig just reads the current settings from the various configuration files and prints their values. If --update action is specified, authconfig must be run by root (or through console helper), and configuration changes are saved. Only the files affected by the configuration changes are overwritten. If --updateall action is specified, authconfig must be run by root (or through console helper), and all configuration files are written. The --probe action instructs auth‐ config to use DNS and other means to guess at configuration information for the cur‐ rent host, print its guesses if it finds them, to standard output, and exit. The --restorebackup, --savebackup, and --restorelastbackup actions provide a possibil‐ ity to save and later restore a backup of configuration files which authconfig modi‐ fies. Authconfig also saves an automatic backup of configuration files before every configuration change. This special backup can be restored by the --restorelastbackup action. If --nostart is specified (which is what the install program does), ypbind or other daemons will not be started or stopped immediately following program execution, but only enabled to start or stop at boot time. The --enablenis, --enableldap, --enablewinbind, and --enablehesiod options are used to configure user information services in /etc/nsswitch.conf, the --enablecache option is used to configure naming services caching, and the --enableshadow, --enableldapauth, --enablekrb5, and --enablewinbindauth options are used to configure authentication functions via /etc/pam.d/system-auth. Each --enable has a matching --disable option that disables the service if it is already enabled. The respective services have parameters which configure their server names etc. The algorithm used for storing new password hashes can be specified by the --passalgo option which takes one of the following possible values as a parameter: descrypt, bigcrypt, md5, sha256, and sha512. The --enablelocauthorize option allows to bypass checking network authentication ser‐ vices for authorization and the --enablesysnetauth allows authentication of system accounts (with uid < 500) by these services. When the configuration settings allow use of SSSD for user information services and authentication, SSSD will be automatically used instead of the legacy services and the SSSD configuration will be set up so there is a default domain populated with the set‐ tings required to connect the services. The --enablesssd and --enablesssdauth options force adding SSSD to /etc/nsswitch.conf and /etc/pam.d/system-auth, but they do not set up the domain in the SSSD configuration files. The SSSD configuration has to be set up manually. The allowed configuration of services for SSSD are: LDAP for user information (--enableldap) and either LDAP (--enableldapauth), or Kerberos (--enablekrb5) for authentication. In case SSSD does not support some feature of the legacy services that are required for the site configuration, the use of the legacy services can be forced by setting FORCELEGACY=yes in /etc/sysconfig/authconfig. The list of options mentioned here in the manual page is not exhaustive, please refer to authconfig --help for the complete list of the options. The authconfig-tui supports all options of authconfig but it implies --update as the default action. Its window contains a Cancel button by default. If --back option is specified at run time, a Back button is presented instead. If --kickstart is speci‐ fied, no interactive screens will be seen. The values the program will use will be those specified by the other options (--passalgo, --enableshadow, etc.). For namelist you may substitute either a single name or a comma-separated list of names. NOTES The authconfig-tui is deprecated. No new configuration settings will be supported by its text user interface. Use system-config-authentication GUI application or the com‐ mand line options instead. The /usr/bin/authconfig uses the consolehelper to authenticate as the system user before it starts up. If you want to run it directly without the authentication as the system user, run the /usr/sbin/authconfig command. The SSSD service is enabled and possibly started by authconfig when at least two of the following three conditions are met: 1) /etc/sssd/sssd.conf file exists (or is configured via the implicit SSSD support) 2) SSSD authentication is enabled (pam_sss.so is used in PAM configuration) 3) SSSD is enabled for user identity (nsswitch.conf contains sss) When --update action is used the enablement or disablement and possible restart of services happens only in case the changed configuration options affect the service to be restarted. This means that if for example the ypbind service is enabled with auth‐ config --update --nostart --enablenis but not started and you run the same command without the --nostart later the ypbind service will not be started because no configu‐ ration change affecting ypbind happened. RETURN CODES authconfig returns 0 on success, 1 on backup operation errors, 2 if not running with sufficient privileges, 3 if unknown password hash algorithm is specified or incorrect values are set for password strength checking (this error is non fatal), 4 if download of CA certificate fails, 5 if writing configuration files fails on --updateall action, 6 if writing fails on --update action, 7 if Winbind or IPA domain join fails. authconfig-tui returns 0 on success, 2 on error, and 1 if the user cancelled the pro‐ gram (by using either the Cancel or Back button). It can also return the same codes as authconfig. FILES /etc/sysconfig/authconfig Used to track whether or not particular authentication mechanisms are enabled. Currently includes variables named USESHADOW, USEMD5, USEKER‐ BEROS, USELDAPAUTH, USESMBAUTH, USEWINBIND, USEWINBINDAUTH, USEHESIOD, USENIS, USELDAP, and others. /etc/passwd /etc/shadow Used for shadow password support. /etc/yp.conf Configuration file for NIS support. /etc/sysconfig/network Another configuration file for NIS support. /etc/ldap.conf /etc/nss_ldap.conf /etc/pam_ldap.conf /etc/nslcd.conf /etc/openldap/ldap.conf Used to configure nss_ldap, pam_ldap, nslcd, and the OpenLDAP library. Only the files already existing on the system are modified. /etc/krb5.conf Used to configure Kerberos 5. /etc/hesiod.conf Used to configure Hesiod. /etc/samba/smb.conf Used to configure winbind authentication. /etc/nsswitch.conf Used to configure user information services. /etc/login.defs Used to configure parameters of user accounts (minimum UID of a regular user, password hashing algorithm). /etc/pam.d/system-auth Common PAM configuration for system services which include it using the include directive. It is created as symlink and not relinked if it points to another file. /etc/pam.d/system-auth-ac Contains the actual PAM configuration for system services and is the default target of the /etc/pam.d/system-auth symlink. If a local config‐ uration of PAM is created (and symlinked from system-auth file) this file can be included there. SEE ALSO authconfig-gtk(8), system-auth-ac(5), passwd(5), shadow(5), pwconv(1), domain‐ name(1), ypbind(8), nsswitch.conf(5), smb.conf(5), sssd(8) AUTHORS Nalin Dahyabhai <nalin@redhat.com>, Preston Brown <pbrown@redhat.com>, Matt Wilson <msw@redhat.com>, Tomas Mraz <tmraz@redhat.com> Red Hat, Inc. 22 July 2011 AUTHCONFIG(8)
Mindestens genau so interessant, vor allem wegen der vielen möglichen Optionen(!), ist die Hilfefunktion des Befehls authconfig, die wir wie folgt erreichen.
# authconfig --help
Usage: Aufruf: authconfig [Optionen] {--update|--updateall|--test|--probe|--restorebackup <name>|--savebackup <name>|--restorelastbackup} Options: -h, --help Diesen Hilfetext anzeigen und beenden --enableshadow, --useshadow Shadow-Passwörter standardmäßig aktivieren --disableshadow Shadow-Passwörter standardmäßig deaktivieren --enablemd5, --usemd5 MD5-Passwörter standardmäßig aktivieren --disablemd5 MD5-Passwörter standardmäßig deaktivieren --passalgo=<descrypt|bigcrypt|md5|sha256|sha512> hash/crypt-Algorithmus für neue Passwörter --enablenis NIS für Benutzerinformationen standardmäßig aktivieren --disablenis NIS für Benutzerinformationen standardmäßig deaktivieren --nisdomain=<Domain> Standard-NIS-Domain --nisserver=<Server> Standard-NIS-Server --enableldap LDAP für Benutzerinformationen standardmäßig aktivieren --disableldap LDAP für Benutzerinformationen standardmäßig deaktivieren --enableldapauth LDAP zur Authentifizierung standardmäßig aktivieren --disableldapauth LDAP zur Authentifizierung standardmäßig deaktivieren --ldapserver=<Server> Standard LDAP-Server-Hostnamen oder URI --ldapbasedn=<dn> Standard LDAP Basis-DN --enableldaptls, --enableldapstarttls Verwendung von TLS mit LDAP (RFC-2830) aktivieren --disableldaptls, --disableldapstarttls Verwendung von TLS mit LDAP (RFC-2830) deaktivieren --enablerfc2307bis Verwendung des RFC-2307bis-Schemas für Suchen nach Benutzerinformation via LDAP aktivieren --disablerfc2307bis Verwendung des RFC-2307bis-Schemas für Suchen nach Benutzerinformation via LDAP deaktivieren --ldaploadcacert=<URL> CA-Zertifikat von URL laden --enablesmartcard Smartcard-Authentifizierung standardmäßig aktivieren --disablesmartcard Smartcard-Authentifizierung standardmäßig deaktivieren --enablerequiresmartcard Smartcard-Authentifizierung standardmäßig voraussetzen --disablerequiresmartcard Smartcard-Authentifizierung nicht standardmäßig voraussetzen --smartcardmodule=<Modul> Standardmäßig zu verwendendes Smartcard-Modul --smartcardaction=<0=Sperren|1=Ignorieren> Beim Entfernen einer Smartcard folgende Aktion ausführen --enablefingerprint Fingerabdruck-Authentifizierung mit Fingerabdruck-Leser standardmäßig aktivieren --disablefingerprint Fingerabdruck-Authentifizierung mit Fingerabdruck-Leser standardmäßig deaktivieren --enableecryptfs Automatisches ecryptfs für Benutzer aktivieren --disableecryptfs Automatisches ecryptfs für Benutzer deaktivieren --enablekrb5 Kerberos-Authentifizierung standardmäßig aktivieren --disablekrb5 Kerberos-Authentifizierung standardmäßig deaktivieren --krb5kdc=<Server> Standard-Kerberos-KDC --krb5adminserver=<Server> Standard-Kerberos-Admin-Server --krb5realm=<Bereich> Standard-Kerberos-Bereich --enablekrb5kdcdns Verwendung von DNS für Ermittlung von Kerberos-KDCs aktivieren --disablekrb5kdcdns Verwendung von DNS für Ermittlung von Kerberos-KDCs deaktivieren --enablekrb5realmdns Verwendung von DNS für die Ermittlung von Kerberos-Bereichen aktivieren --disablekrb5realmdns Verwendung von DNS für die Ermittlung von Kerberos-Bereichen deaktivieren --enablewinbind Winbind für die Benutzerinformationen standardmäßig aktivieren --disablewinbind Winbind für die Benutzerinformationen standardmäßig deaktivieren --enablewinbindauth Winbind für die Authentifizierung standardmäßig aktivieren --disablewinbindauth Winbind für die Authentifizierung standardmäßig deaktivieren --smbsecurity=<user|server|domain|ads> Von Samba und Winbind zu verwendender Sicherheitsmodus --smbrealm=<Bereich> Standard-Bereich für Samba und Winbind, wenn security=ads --smbservers=<Server> Namen der Server, gegen die authentifiziert wird --smbworkgroup=<Arbeitsgruppe> Arbeitsgruppen-Authentifizierungsserver sind in --smbidmaprange=<niedrigste-höchste>, --smbidmapuid=<niedrigste-höchste>, --smbidmapgid=<niedrigste-höchste> uid-Bereich, den Winbind Domain- oder ADS-Benutzern zuteilen wird --winbindseparator=<\> Das Zeichen, das zur Trennung von Domain und Benutzer in von Winbind erzeugten Benutzernamen verwendet wird, sofern winbindusedefaultdomain nicht aktiviert ist --winbindtemplatehomedir=</home/%D/%U> Der Ordner, den von Winbind erzeugte Benutzer als persönlichen Ordner haben --winbindtemplateprimarygroup=<nobody> Die Gruppe, die von Winbind erzeugte Benutzer als primäre Gruppe haben --winbindtemplateshell=</bin/false> Die Shell, die von Winbind erzeugte Benutzer als Login-Shell haben --enablewinbindusedefaultdomain Winbind soll annehmen, dass Benutzer ohne Domain im Benutzernamen Domain-Benutzer sind --disablewinbindusedefaultdomain Winbind soll annehmen, dass Benutzer, ohne Domain im Benutzernamen keine Domain-Benutzer sind --enablewinbindoffline Konfiguriert Winbind, um Offline-Anmeldung zu ermöglichen --disablewinbindoffline Konfiguriert Winbind, um Offline-Anmeldung zu verhindern --enablewinbindkrb5 winbind wird Kerberos 5 zur Legitimation verwenden --disablewinbindkrb5 winbind wird die Standard Legitimations-Methode verwenden --winbindjoin=<Administrator> Jetzt der Winbind-Domäne oder dem ADS-Bereich mit diesem Administrator beitreten --enableipav2 Aktiviere IPAv2 für Benutzerinformationen und Authentifizierung standardmässig --disableipav2 Deaktiviere IPAv2 für Benutzerinformationen und Authentifizierung standardmässig --ipav2domain=<Domain> Die IPAv2 Domäne, bei der das System enthalten sein soll --ipav2realm=<Bereich> Der Bereich für die IPAv2-Domäne --ipav2server=<Server> Server der IPAv2 Domäne --enableipav2nontp NTP für die IPAv2-Domain nicht einrichten --disableipav2nontp NTP für die IPAv2-Domain einrichten (Standard) --ipav2join=<account> Mit diesem Konto der IPAv2-Domäne beitreten --enablewins WINS zur Auflösung von Hostnamen aktivieren --disablewins WINS zur Auflösung von Hostnamen deaktivieren --enablepreferdns DNS über WINS oder NIS zur Hostnamen-Auflösung bevorzugen --disablepreferdns DNS über WINS oder NIS zur Hostnamen-Auflösung nicht bevorzugen --enablehesiod Hesiod für die Benutzerinformationen standardmäßig aktivieren --disablehesiod Hesiod für die Benutzerinformationen standardmäßig deaktivieren --hesiodlhs=<lhs> Standard-Hesiod-LHS --hesiodrhs=<rhs> Standard-Hesiod-RHS --enablesssd SSSD für Benutzerinformationen als Vorgabe mit manuell verwalteter Konfiguration aktivieren --disablesssd SSSD für Benutzerinformationen als Vorgabe deaktivieren (wird noch für unterstützte Konfigurationen verwendet) --enablesssdauth SSSD für Authentifizierung als Vorgabe mit manuell verwalteter Konfiguration aktivieren --disablesssdauth SSSD für Authentifizierung als Vorgabe deaktivieren (wird noch für unterstützte Konfigurationen verwendet) --enableforcelegacy SSSD ausdrücklich nie verwenden, auch nicht für unterstützte Konfigurationen --disableforcelegacy SSSD unbedingt nur benutzen, wenn es die Konfiguration unterstützt --enablecachecreds Zwischenspeicherung von Benutzerinformation in SSSD standardmäßig aktivieren --disablecachecreds Zwischenspeicherung von Benutzerinformation in SSSD standardmäßig deaktivieren --enablecache Zwischenspeicherung von Benutzerinformation standardmäßig aktivieren (bei der Verwendung von SSSD automatisch deaktiviert) --disablecache Zwischenspeicherung von Benutzerinformation standardmäßig deaktivieren --enablelocauthorize Lokale Autorisierung ist ausreichend für lokale Benutzer --disablelocauthorize Lokale Benutzer auch über Fernzugriff autorisieren --enablepamaccess access.conf während der Autorisierung des Benutzerkontos überprüfen --disablepamaccess access.conf während der Autorisierung des Benutzerkontos nicht überprüfen --enablesysnetauth Systembenutzer über Netzwerkdienste authentifizieren --disablesysnetauth Systembenutzer nur über lokale Dateien authentifizieren --enablemkhomedir Persönliche Benutzerordner bei der ersten Anmeldung erzeugen --disablemkhomedir Keine persönlichen Benutzerordner bei der ersten Anmeldung erzeugen --passminlen=<Nummer> Minimale Passwortlänge --passminclass=<Nummer> Mindestanzahl von Charakter-Klassen in einem Kennwort --passmaxrepeat=<Nummer> Maximalanzahl gleicher Zeichen in einem Passwort --passmaxclassrepeat=<Nummer> Maximale Anzahl von aufeinanderfolgenden Zeichen derselben Klasse in einem Kennwort --enablereqlower Erzwinge mindestens einen Kleinbuchstaben im Passwort --disablereqlower Benötie keine Kleinbuchstaben im Passwort --enablerequpper Erzwinge mindestens einen Grossbuchstaben im Passwort --disablerequpper Keine Grossbuchstaben in einem Kennwort verlangen --enablereqdigit Erzwinge mindestens eine Zahl im Passwort --disablereqdigit Benötige keine Zahlen im Passwort --enablereqother Mindestens ein anderes Zeichen in einem Passwort verlangen --disablereqother Keine anderen Zeichen in einem Kennwort verlangen --nostart portmap, ypbind und nscd nicht starten/anhalten --test Konfigurationsdateien nicht aktualisieren, stattdessen nur die neuen Einstellungen ausgeben --update, --kickstart Im Gegensatz zu --test die Konfigurationsdateien mit geänderten Einstellungen aktualisieren --updateall Alle Konfigurationsdateien aktualisieren --probe Im Netzwerk nach Standards suchen und diese ausgeben --savebackup=<Name> Eine Sicherung aller Konfigurationsdateien speichern --restorebackup=<Name> Eine Sicherung der Konfigurationsdateien wiederherstellen --restorelastbackup Die vor der letzten Konfigurationsänderung gesicherten Konfigurationsdateien wiederherstellen
Konfiguration
authconfig
Die Konfiguration unseres Clients nehmen wir am einfachsten mit Hilfe des Programmes authconfig aus dem RPM-Paket authconfig vor. Hierzu rufen wir authconfig mit den nötigen Optionen für unsere (Test-)Umgebung auf. Eine ausführliche Beschreibung der Optionen erhält man, wie schon erwähnt, über die Manpage von authconfig oder beim Aufruf der Option –help.
- disablesssd SSSD für Benutzerinformationen als Vorgabe deaktivieren
- disablesssdauth SSD für Authentifizierung als Vorgabe deaktivieren
- disablemd5 MD5 Passworter abschalten
- passalgo Definition des Passworthash-Algoritmuses
- enablemkhomedir Homedirectory beim ersten Login eines neuen Users automatisch anlegen
- enableldap LDAP User Informationen aktivieren
- enableldapauth LDAP Authentifizierung aktivieren
- ldapserver LDAP Servername oder URI Definition
- ldapbasedn LDAP Basde DN Definition
- enableldaptls Verwendung von TLS mit LDAP (RFC-2830) über Port 636 verwenden
- enableldapstarttls Verwendung von StartTLS mit LDAP über Port 389 verwenden
- update Update der Konfigurationsdateien mit den gesetzten Werten.
Wir Konfigurieren nun also unsere LDAP-Client-Authentifizierung wie folgt.
# authconfig --disablesssd \ --disablesssdauth \ --disablemd5 \ --passalgo=sha256 \ --enablemkhomedir \ --enableldap \ --enableldapauth \ --ldapserver="ldap://openldap.dmz.nausch.org" \ --ldapbasedn="dc=nausch,dc=org" \ --enableldaptls \ --enableldapstarttls \ --update
Die einzelnen Konfigurationsdateien, die mit dem vorgenannten Programmaufruf angepasst wurden, werden wir uns im Detail betrachten, ggf. anpassen und mit Bearbeitungsvermerken versehen, damit wir später noch nachvollziehen können, welche Änderungen im Detail notwendig waren, damit die LDAPs Client Authentifizierung aktiviert werden konnte.
Zur Dokumentation und ggf. spätere weitere Dokumentationsschritte versehen wir am Besten optional alle Änderungen mit einem Kommentar, ala: # Django : Datum (YYY-MM-DD) [optionaler Grund]
.
nslcd.conf
Die erste Datei, die wir uns nun genauer ansehen, ist die Konfigurationsdatei /etc/nslcd.conf.
# vim /etc/nslcd.conf
- /etc/nslcd.conf
# This is the configuration file for the LDAP nameservice # switch library's nslcd daemon. It configures the mapping # between NSS names (see /etc/nsswitch.conf) and LDAP # information in the directory. # See the manual page nslcd.conf(5) for more information. # The user and group nslcd should run as. uid nslcd gid ldap # The uri pointing to the LDAP server to use for name lookups. # Multiple entries may be specified. The address that is used # here should be resolvable without using LDAP (obviously). #uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/ # Note: %2f encodes the '/' used as directory separator # Django : 2015-07-20 # default: uri ldap://127.0.0.1/ uri ldap://openldap.dmz.nausch.org # The LDAP version to use (defaults to 3 # if supported by client library) #ldap_version 3 # The distinguished name of the search base. # Django : 2015-07-20 # default: base dc=example,dc=com base dc=nausch,dc=org # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. #binddn cn=proxyuser,dc=example,dc=com # Django : 2015-07-20 # default: unset binddn cn=Technischeruser,dc=nausch,dc=org # The credentials to bind with. # Optional: default is no credentials. # Note that if you set a bindpw you should check the permissions of this file. #bindpw secret # Django : 2015-07-20 # default: unset bindpw YpKKoS1lV1AdAX1StGe1lTembvZW4XagnkLdWZ2Y4Xkw # The distinguished name to perform password modifications by root by. #rootpwmoddn cn=admin,dc=example,dc=com # The default search scope. #scope sub #scope one #scope base # Customize certain database lookups. #base group ou=Groups,dc=example,dc=com #base passwd ou=People,dc=example,dc=com #base shadow ou=People,dc=example,dc=com #scope group onelevel #scope hosts sub # Bind/connect timelimit. #bind_timelimit 30 # Search timelimit. #timelimit 30 # Idle timelimit. nslcd will close connections if the # server has not been contacted for the number of seconds. #idle_timelimit 3600 # Use StartTLS with verifying the server certificate. # Django : 2015-07-20 ssl start_tls tls_cacertfile /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem # Use StartTLS without verifying the server certificate. #ssl start_tls #tls_reqcert never # CA certificates for server certificate verification #tls_cacertdir /etc/ssl/certs #tls_cacertfile /etc/ssl/ca.cert # Seed the PRNG if /dev/urandom is not provided #tls_randfile /var/run/egd-pool # SSL cipher suite # See man ciphers for syntax #tls_ciphers TLSv1 # Client certificate and key # Use these, if your server requires client authentication. #tls_cert #tls_key # Mappings for Services for UNIX 3.5 #filter passwd (objectClass=User) #map passwd uid msSFU30Name #map passwd userPassword msSFU30Password #map passwd homeDirectory msSFU30HomeDirectory #map passwd homeDirectory msSFUHomeDirectory #filter shadow (objectClass=User) #map shadow uid msSFU30Name #map shadow userPassword msSFU30Password #filter group (objectClass=Group) #map group member msSFU30PosixMember # Mappings for Services for UNIX 2.0 #filter passwd (objectClass=User) #map passwd uid msSFUName #map passwd userPassword msSFUPassword #map passwd homeDirectory msSFUHomeDirectory #map passwd gecos msSFUName #filter shadow (objectClass=User) #map shadow uid msSFUName #map shadow userPassword msSFUPassword #map shadow shadowLastChange pwdLastSet #filter group (objectClass=Group) #map group member posixMember # Mappings for Active Directory #pagesize 1000 #referrals off #idle_timelimit 800 #filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*)) #map passwd uid sAMAccountName #map passwd homeDirectory unixHomeDirectory #map passwd gecos displayName #filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*)) #map shadow uid sAMAccountName #map shadow shadowLastChange pwdLastSet #filter group (objectClass=group) # Alternative mappings for Active Directory # (replace the SIDs in the objectSid mappings with the value for your domain) #pagesize 1000 #referrals off #idle_timelimit 800 #filter passwd (&(objectClass=user)(objectClass=person)(!(objectClass=computer))) #map passwd uid cn #map passwd uidNumber objectSid:S-1-5-21-3623811015-3361044348-30300820 #map passwd gidNumber objectSid:S-1-5-21-3623811015-3361044348-30300820 #map passwd homeDirectory "/home/$cn" #map passwd gecos displayName #map passwd loginShell "/bin/bash" #filter group (|(objectClass=group)(objectClass=person)) #map group gidNumber objectSid:S-1-5-21-3623811015-3361044348-30300820 # Mappings for AIX SecureWay #filter passwd (objectClass=aixAccount) #map passwd uid userName #map passwd userPassword passwordChar #map passwd uidNumber uid #map passwd gidNumber gid #filter group (objectClass=aixAccessGroup) #map group cn groupName #map group gidNumber gid # This comment prevents repeated auto-migration of settings.
Anschließend passen wir noch die Dateiberechtigungen an, so wie es bei der Option bindpw angeraten wurde.
# chown nslcd:ldap /etc/nslcd.conf
nsswitch.conf
In der Konfigurationsdatei /etc/nsswitch.conf ergänzen wir nun händisch die Optionen ldap. Änderungen wurden in dem Beispiel wie iimmer entsprechend gekennzeichnet:
- passwd: files ldap sss
- shadow: files ldap sss
- group: files ldap sss
- netgroup: files ldap sss
- automount: files ldap sss
# vim /etc/nsswitch.conf
- /etc/nsswitch.conf
# # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=return]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Valid entries include: # # nisplus Use NIS+ (NIS version 3) # nis Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # [NOTFOUND=return] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files nisplus nis #shadow: db files nisplus nis #group: db files nisplus nis # Django : 2015-07-21 LDAP Client Authentication # default: passwd: files sss # shadow: files sss # group: files sss passwd: files ldap sss shadow: files ldap sss group: files ldap sss #initgroups: files #hosts: db files nisplus nis dns hosts: files dns # Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss # Django : 2015-07-21 LDAP Client Authentication # default: netgroup: files sss netgroup: files ldap sss publickey: nisplus # Django : 2015-07-21 LDAP Client Authentication # default: automount: files sss automount: files ldap sss aliases: files nisplus
password-auth-ac
Damit sich unsere Nutzer auch anmelden können, ist es notwendig in der Konfigurationsdatei /etc/pam.d/password-auth-ac die option pam_sss.so durch ein pam_ldap.so zu ersetzen.
# vim /etc/pam.d/password-auth-ac
- /etc/pam.d/password-auth-ac
#%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 >= 1000 quiet_success # Django : 2015-07-21 # default: auth sufficient pam_sss.so use_first_pass auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet # Django : 2015-07-21 # default: account [default=bad success=ok user_unknown=ignore] pam_sss.so account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha256 nullok try_first_pass use_authtok # Django : 2015-07-21 # default: password sufficient pam_sss.so use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so # Django : 2015-07-21 # default: session optional pam_sss.so session optional pam_ldap.so
Start des Naming services LDAP client daemon
Nun ist es an der Zeit, den NSLCD1) zu starten.
# systemctl restart nslcd.service
Den erfolgreichen Start des Daemon fragen wir wie folgt ab.
# systemctl status nslcd.service -l
nslcd.service - Naming services LDAP client daemon.
Loaded: loaded (/usr/lib/systemd/system/nslcd.service; disabled)
Active: active (running) since Mo 2015-07-20 17:06:44 CEST; 34s ago
Process: 8771 ExecStart=/usr/sbin/nslcd (code=exited, status=0/SUCCESS)
Main PID: 8774 (nslcd)
CGroup: /system.slice/nslcd.service
└─8774 /usr/sbin/nslcd
Jul 20 17:06:44 vml010052.intra.nausch.org systemd[1]: Starting Naming services LDAP client daemon....
Jul 20 17:06:44 vml010052.intra.nausch.org systemd[1]: PID file /var/run/nslcd/nslcd.pid not readable (yet?) after start.
Jul 20 17:06:44 vml010052.intra.nausch.org nslcd[8774]: version 0.8.13 starting
Jul 20 17:06:44 vml010052.intra.nausch.org systemd[1]: Started Naming services LDAP client daemon..
Jul 20 17:06:44 vml010052.intra.nausch.org nslcd[8774]: accepting connections
Damit der Daemin automatisch gestartet wird, wenn der Clientrechner hochfährt, aktivieren wir den NSLCD entsprechend.
# systemctl enable nslcd.service
ln -s '/usr/lib/systemd/system/nslcd.service' '/etc/systemd/system/multi-user.target.wants/nslcd.service'
Wollen wir abfragen, ob der Daemon automatisch beim Systemstart gestartet wird benutzen wir nachfolgenden Befehl/Aufruf.
# systemctl is-enabled nslcd.service
enabled
Ein enabled signalisiert, dass der Daemon einen Autostart macht, ein disabled steht dafür, dass der Daemon nichtautomatisch beim Starten des Rechners hochfährt.
Tests
LDAP Abfrage
Zur Abfrage eines LDAP-Users können wir folgenden Aufruf verwenden:
$ ldapsearch -x -LLL -H ldaps://openldap.dmz.nausch.org -b "dc=nausch,dc=org" "uid=django" -W -D "cn=Technischeruser,dc=nausch,dc=org" Enter LDAP Password:
dn: uid=django,ou=People,dc=nausch,dc=org uid: django cn: django objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 16617 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/django gecos: django userPassword:: RGQ0bWRkMyE=
Das nächste Beispiel zeigt eine LDAP-Abfrage mit dem User django aber mit falschem Passwort:
$ ldapsearch -x -LLL -H ldaps://openldap.dmz.nausch.org -b "dc=nausch,dc=org" "uid=inge" -W -D "uid=inge,ou=People,dc=nausch,dc=org"
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
Hingegen eine Abfrage mit einer richtigen Kombination von Benutzer und Passwort, sieht entsprechend wie folgt aus:
$ ldapsearch -x -LLL -H ldaps://openldap.dmz.nausch.org -b "dc=nausch,dc=org" "uid=inge" -W -D "uid=inge,ou=People,dc=nausch,dc=org"
Enter LDAP Password:
dn: uid=inge,ou=People,dc=nausch,dc=org uid: inge cn: inge objectClass: account objectClass: posixAccount objectClass: top loginShell: /bin/bash uidNumber: 1002 gidNumber: 1002 homeDirectory: /home/inge gecos: inge userPassword:: e0NSWVBasdfaUJ1fM3101d3XJ1J19UR21TUjhpMWc=
Client-Abfragen
Die erfolgreiche Konfiguration unseres Rechners überprüfen wir so:
- Mit getent lassen wir uns die Informationen eines Users anzeigen, der sowohl in der /etc/shadow wie auch im zentralen LDAP-Verzeichnisdienst hinterlegt ist. Wenn alles gut gelaufen ist, werden uns zwei Einträge präsentiert.
$ getent passwd | grep django
django:$6$RG6zR$2RbzR$wDvit.DnWHSYGEFCrn0LXyEleQkOuJQ5mQLiVRHNEnm5svSCrn0LXyEleQkOuflVHvMkKnAEdQCCVU9Gc9nPe1:1000:1000:Django [BOfH]:/home/django:/bin/bash django:x:1000:1000:django:/home/django:/bin/bash
- Als nächstes wählen wir einen Nutzer der nur im LDAP-Verzeichnisdienst einen Account hat, nicht aber auf der lokalen Maschine.
$ getent passwd | grep michael
michael:*:1001:1001:michael:/home/michael:/bin/bash
- Dann melden wir uns nun an unserem Client als ein Benutzer an, der lokal auf der Maschine nicht existiert, werden wir beim Login nach dem Passwort gefragt, welches gegen den zentralen OpenLDAP-Server verifiziert wird. Ist das Passwort richtig wird auch gleich das zugehörige Nutzer-Homeverzeichnis angelegt.
[django@vml010008 ~]$ ssh -l ruben 10.0.10.52
Password:
Creating home directory for ruben.
remote Benutzer bei Web-Servern
Nachdem sich unsere Nutzer an ihren Arbeitsplatzrechner erfolgreich anmelden können, wollen sie mit unter auch von unterwegs aus auf Ihre eMail oder andere WEB-Dienste zugreifen. Auch dort sollen sich unsere User mit deren Anmeldedaten anmelden können.
Im folgenden gehen wir auf Konfigurationslösungen bei den beiden Webservern Apache und NGiNX im Detail eingehen.
Apache Webserver
In der Regel haben wir zur Verwaltung der Nutzerdaten ein Backendsystem zur Verwaltung im Einsatz. Im folgendem Konfigurationsbeispiel werden wir uns nun gegen einen vorhandenen LDAP-Server authentifizieren.
Damit sich unser Client mit dem OpenLDAP-Server verbinden kann, sind ein paar Vorkehrungen zu treffen.
Installation
openldap-clients
Als erstes installieren wir uns das RPM-Paket openldap-clients, wie soll es anders sein, verwenden wir hierzu das Programmverwaltungs-Tool YUM unter CentOS 7.x.
# yum install openldap-clients -y
Das was uns das Paket alles mitbrachte, können wir uns wie folgt ausgeben lassen.
# rpm -qil openldap-clients
Name : openldap-clients Version : 2.4.39 Release : 6.el7 Architecture: x86_64 Install Date: Fri 17 Jul 2015 07:29:06 PM CEST Group : Applications/Internet Size : 588433 License : OpenLDAP Signature : RSA/SHA256, Sat 14 Mar 2015 09:22:43 AM CET, Key ID 24c6a8a7f4a80eb5 Source RPM : openldap-2.4.39-6.el7.src.rpm Build Date : Fri 06 Mar 2015 05:36:42 AM CET Build Host : worker1.bsys.centos.org Relocations : (not relocatable) Packager : CentOS BuildSystem <http://bugs.centos.org> Vendor : CentOS URL : http://www.openldap.org/ Summary : LDAP client utilities Description : OpenLDAP is an open-source suite of LDAP (Lightweight Directory Access Protocol) applications and development tools. LDAP is a set of protocols for accessing directory services (usually phone book style information, but other information is possible) over the Internet, similar to the way DNS (Domain Name System) information is propagated over the Internet. The openldap-clients package contains the client programs needed for accessing and modifying OpenLDAP directories. /usr/bin/ldapadd /usr/bin/ldapcompare /usr/bin/ldapdelete /usr/bin/ldapexop /usr/bin/ldapmodify /usr/bin/ldapmodrdn /usr/bin/ldappasswd /usr/bin/ldapsearch /usr/bin/ldapurl /usr/bin/ldapwhoami /usr/share/man/man1/ldapadd.1.gz /usr/share/man/man1/ldapcompare.1.gz /usr/share/man/man1/ldapdelete.1.gz /usr/share/man/man1/ldapexop.1.gz /usr/share/man/man1/ldapmodify.1.gz /usr/share/man/man1/ldapmodrdn.1.gz /usr/share/man/man1/ldappasswd.1.gz /usr/share/man/man1/ldapsearch.1.gz /usr/share/man/man1/ldapurl.1.gz /usr/share/man/man1/ldapwhoami.1.gz
Konfiguration
openldap-clients
Versuchen wir uns jetzt schon mit unserem LDAP-Server zu verbinden, schlägt dies unweigerlich fehl. Beispiel:
# ldapsearch -W -x -b "dc=nausch,dc=org" "uid=django" \ -D "cn=Technischeruser,dc=nausch,dc=org" -LLL \ -H ldaps://openldap.dmz.nausch.org
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Die Verbindung schlägt fehl, da der Client dem Zertifikat des OpenLDAP-Servers (noch) nicht vertraut!
Wir müssen als erst noch die zum Serverzertifikat passenden Root-Zertifikate der CA2) CAcert als vertrauenswürdige Root-Zertifikate importieren.
Vertrauensmodelle in Public-Key-Infrastrukturen
Wir haben nun in der Datei /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem die nötigen Root-Zertifikate und müssen nun nur noch unserem openldap-client mitteilen, diesen auch zu nutzen. Hierzu editieren wir nun die Konfigurationsdatei des openldap-clients.
# vim /etc/openldap/ldap.conf
- /etc/openldap/ldap.conf
# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 # Django: 2015-07-17 # defaul: unset # Definition des standardmässig abgefragten Teilbaums / Searchbase # Anfragen werden unterhalb von dc=nausch, dc=org ausgeführt BASE dc=nausch, dc=org # Definition des LDAP-Servers URI ldap://openldap.dmz.nausch.org #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # Django : 2015-07-17 # default: TLS_CACERTDIR /etc/openldap/certs # Django : 2015-07-16 # Pfad und Datei mit den vertrauenswürdigen Root-Zertifikaten # default: unset TLS_CACERT /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on
Zum Testen richten wir erneut eine Anfrage an unseren OpenLDP-Server.
# ldapsearch -W -x -b "dc=nausch,dc=org" "uid=django" \ -D "cn=Technischeruser,dc=nausch,dc=org" -LLL \ -H ldaps://openldap.dmz.nausch.org
Enter LDAP Password:
dn: uid=django,ou=People,dc=nausch,dc=org uid: django cn: django objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 16617 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1000 gidNumber: 1000 homeDirectory: /home/django gecos: django userPassword:: RGQ0bWRkMyE=
mod_ldap
Im Gegensatz zum Konfigurationsbeispiel der Basic Authentifikation mit Hilfe von PasswordBasicAuth, benötigen wir das zusätzliche RPM-Paket mod_ldap, welches die beiden notwendigen Module mod_authnz_ldap und mod_ldap zur LDAP-Authentifikation benötigt werden. Das RPM installieren wir uns nun mit Hilfe von yum.
# yum install mod_ldap -y
Konfiguration
Was nun noch fehlt, ist die Konfiguration unseres vHOSTs. In der Konfigurationsdatei des betreffenden vHOSTs tragen wir nun folgende Zeilen nach.
# vim /etc/httpd/conf.d/vhost_443_postfixadmin.conf
... # Django : 2015-07-17 Konfigurationsbeispiel zur LDAP Authenifikation mit Hilfe # der beiden Module mod_authnz_ldap und mod_ldap aus dem RPM mod_ldap. <Location /> Options +FollowSymLinks +Multiviews +Indexes AllowOverride None AuthType Basic AuthName "PostfixAdmin-Webserver" AuthBasicProvider ldap AuthLDAPUrl ldaps://openldap.dmz.nausch.org:389/ou=People,dc=nausch,dc=org?uid AuthLDAPBindDN cn=Technischeruser,dc=nausch,dc=org AuthLDAPBindPassword e1n531f!D4xIi57n393I1354u! AuthLDAPBindAuthoritative on Require ldap-user django bigchief nagios </Location> ...
Damit unsere Änderungen aktiv werden bedarf es noch eines reloads unseres HTTP-Deamon.
# systemctl reload httpd.service
WICHTIG:
Damit die Anmeldedaten nicht von Dritten mitgelesen und abgefischt werden können, nutzen wir natürlich einen SSL-geschützten vHOST!
Test
NGiNX Webserver
In der Regel haben wir zur Verwaltung der Nutzerdaten ein Backendsystem zur Verwaltung im Einsatz. Im folgendem Konfigurationsbeispiel werden wir uns nun gegen einen vorhandenen LDAP-Server authentifizieren.
Der Webserver NGiNX stellt von Haus aus keine Möglichkeit zur LDAP-Authentifikation zur Verfügung. Mit Hilfe der Erweiterung nginx-auth-ldap von Valery Komarov kann diese aber nachgerüstet werden. Eine entsprechende aktuell Version von NGiNX mit LDAP-Authentifizierungsunterstützung ist im Repository nausch.org enthalten:
WICHTIG:
Im Gegensatz zur LDAPs Authentifikation beim Apache Webserver, vertraut das LDAP-Modul für NGiNX jedem Server-Zertifikat. Das bedeutet, wir brauchen hier nicht die Root-Zertifikate der genutzten CA3) importieren und diesen unser Vertrauen aussprechen.
Dies ist beim Einsatz von NGiNX im sicherheitskritischen Umfeld zu beachten!
Konfiguration
Die Konfiguration der LDAPs Authentifikation beim Webserver NGiNX ist aufgeteilt, in zwei Abschnitte. Der erste Abschnitt definiert den Zugang zum LDAP-Server, der zweite Teil ist dann im Abschnitt server der NGiNX-Konfiguration und verweist dann auf einen Eiintrag des „ersten Abschnitts“.
Sehen wir uns das an folgendem Beispiel genauer an.
# vim /etc/nginx/conf.d/1st_ldap.conf
- /etc/nginx/conf.d/1st_ldap.conf
# Django : 2015-07-18 # Definition für die Anbindung unseres nginx Servers an den # OpenLDAP-Server für die Authentifikation des Users django ldap_server ldap_group_1 { url ldaps://openldap.dmz.nausch.org:636/ou=People,dc=nausch,dc=org?uid?sub?(objectClass=posixAccount); binddn "cn=Technischeruser,dc=nausch,dc=org"; binddn_passwd "e1n531f!D4xIi57n393I1354u!"; group_attribute uniquemember; group_attribute_is_dn on; #parse_require user "uid=django,ou=People,dc=nausch,dc=org"; require user "uid=django,ou=People,dc=nausch,dc=org"; require user "uid=icinga2_checkuser,ou=Daemon,dc=nausch,dc=org"; } # Definition für die Anbindung unseres nginx Servers an den # OpenLDAP-Server für die Authentifikation des Users michael ldap_server ldap_group_2 { url ldaps://10.0.0.37:636/ou=People,dc=nausch,dc=org?uid?sub?(objectClass=posixAccount); binddn "cn=Technischeruser,dc=nausch,dc=org"; binddn_passwd "e1n531f!D4xIi57n393I1354u!"; group_attribute uniquemember; group_attribute_is_dn on; require user "uid=michael,ou=People,dc=nausch,dc=org"; }
Wichtig:
Der Name der Konfigurationsdatei 1st_ldap.conf wurde mit Absicht so gewählt, da nginx beim Starten die Dateien in alphabetischer Reihenfolge einliest. Die Definition des ldap_server muss vor dem verweisen der Serverkonfiguration erfolgen, andernfalls würde bei einem Test der Konfiguration, z.B. folgender Fehler auftreten:
# nginx -t
nginx: [emerg] http_auth_ldap: Using "auth_ldap_servers" when no "ldap_server" has been previously defined (make sure that "auth_ldap_servers" goes after "ldap_server"s in your configuration file) in /etc/nginx/conf.d/default.conf:29 nginx: configuration file /etc/nginx/nginx.conf test failed
Nun können wir in der Serverkonfiguration auf die gerade eben angelegten ldap_server rückverweisen.
# vim /etc/nginx/conf.d/betterawstats.conf
- /etc/nginx/conf.d/betterawstats.conf
server { # Django : 2015-05-28 # auf welchem Port soll der Server lauschen (HTTP: 80)? listen 80; # auf welchen Servernamen (vHOST) soll der Server reagieren? server_name betterawstats.nausch.org; # Welches Access- und Error-Logfile soll beschrieben werden? access_log /var/log/nginx/betterawstats_access.log; error_log /var/log/nginx/betterawstats_errors.log; # HTTP auf HTTPS mit Statuscode 301 "moved permanently" umleiten return 301 https://$server_name$request_uri; } server { # Django : 2015-05-28 # auf welchem Port soll der Server lauschen (HTTPS: 443)? # neben TLS soll auch SPDY (http://de.wikipedia.org/wiki/SPDY) # angeboten werden. listen 443 ssl spdy; # auf welchen Servernamen (vHOST) soll der Server reagieren? server_name betterawstats.nausch.org; # Welches Access- und Error-Logfile soll beschrieben werden? access_log /var/log/nginx/betterawstats_access.log; error_log /var/log/nginx/betterawstats_errors.log; # Standard-Parameter für TLS-Verschlüsselung inkludieren include /etc/nginx/ssl_params; # Zertifikatsdatei inkl. ggf. notwendiger Zwischen- und Root-Zertifikaten # 1) Server-Zertifikat, 2) Intermediate-Root-Zertifikat und # 3) Root-Zertifikat der CA ssl_certificate /etc/pki/tls/certs/betterawstats.nausch.org.certificatechain_150113.pem; # Schlüsseldatei, mit der der CSR erstellt wurde ssl_certificate_key /etc/pki/tls/private/betterawstats.nausch.org.serverkey.pem; # Zugriffe erst nach erfolreicher Authentifizierung gestatten # Authentifikation des Benutzers django gegen den zentralen # OpenLDAP-Verzeichnisdienst auth_ldap "gesperrter Bereich bei nausch.org"; auth_ldap_servers ldap_group_2; # Welcher Inhalt soll angezeigt bzw. auf welchen Server sollen # die HTTP-Requests # weitergeleitet werden? root /usr/share/betterawstats/; index index.php index.html; location ~ \.php { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~* ^/(.+\.(gif|jp?eg|png|css|js|cgi|pl|ico|swf|flv|s?html|php|xap|py|xml|txt))$ { expires 1y; root /usr/share/betterawstats; allow all; } location ~ icons { allow all; } }
Achtung:
Prüft man mit Hilfe des Befehls nginx -t die Konfiguration, wird der folgende Fehler angezeigt.
# nginx -t
nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:12 nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:13 nginx: [emerg] http_auth_ldap: parse_require in /etc/nginx/conf.d/1st_ldap.conf:24 nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
Dies ist ein bekannter Fehler4). NGiNX kann aber wie gewohnt ge(re)startet werden!
Damit unsere Änderungen aktiv werden bedarf es noch eines reloads unseres HTTP-Deamon.
# systemctl reload nginx.service
WICHTIG:
Damit die Anmeldedaten nicht von Dritten mitgelesen und abgefischt werden können, nutzen wir natürlich einen SSL-geschützten vHOST!