Authentifizierung und Authentisierung erfolgen primär über die vorgestellte zpub-eigene Benutzerverwaltung. Es ist jedoch auch möglich, die in zpub verwendeten Komponenten (hier: apache und subversion) z.B. gegen einen LDAP-Verzeichnisdienst authentifizeren zu lassen oder Single Sign-On einzurichten.
Auf dem Verzeichnisdienst muss ein Abfrage-User (hier: apacheconnect) eingerichtet sein.
Aapche-Module:
a2enmod authnz_ldap ldapBeispiel 4. vhost.conf (Ausschnitt)
AuthType Basic
AuthBasicProvider ldap file
AuthUserFile /var/lib/zpub/${instance-name}/settings/htpasswd
AuthLDAPURL ldaps://dc1.domain.tld:636/dc=domain,dc=tld\
?sAMAccountName?sub?(objectClass=*)
AuthLDAPBindDN apacheconnect@domain.tld
AuthLDAPBindPassword geheim
Require ldap-group ou=zpubgruppe,DC=domain,DC=tldDie LDAP-Abfragen können mit ldapsearch aus dem Debian-Paket 'ldap-utils' getestet werden:
$ ldapsearch -x -D "apacheconnect@domain.tld" -w geheim -b "dc=domain,dc=tld" \
-H "ldaps://dc1.domain.tld:636" "(sn=apacheconnect)" dnDie Zeit muss auf allen beteiligten Hosts korrekt gestellt sein. Weiter ist auf eine korrekte Namensauflösung (DNS-Lookup wie auch Reverse-DNS-Lookup) sowie auf die korrekte Klein- und Großschreibung für die Kerberos-Konfiguration zu achten.
Alle Angaben beziehen sich auf die Realisierung der Authentifizierung und Authentisierung gegen ein Microsoft Active Directory™ bzw. folgende Umgebung:
Domain Controller: Windows Server 2012R2™
HTTP Service: Apache 2.4/Debian 8.x
Client: Microsoft Windows 7™
Bei der Nutzung von Kerberos ist keine "fallback"-Authentifizierung durch andere Authentifizierungs-Provider (z.B. file) möglich.
Host AD: Erstellen eines Service Principals im Active Directory: Neuer Benutzer anlegen
HTTP/$zpub-instance-name.domain.tldHost AD: keytab für diesen Service Principal erstellen
C:\>ktpass -princ HTTP/$zpub-instance-name.domain.tld@DOMAIN.TLD \ -mapuser kerberosprinc@DOMAIN.TLD \ -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL \ -pass not_be_guessable -out c:\keyfile
Der Name Service Principal, sprich der Teil zwischen dem HTTP/ und dem @DOMAIN.TLD, muss exakt auf den FQDN des zu "kerberisierenden" Hosts lauten.
Host zpub: keytab-Datei auf zpub-Host übertragen und Dateisystemberechtigungen anpassen:
$ chown www-data http_zpub.krb5keytab $ chmod 400 http_zpub.krb5keytab
Host zpub: LDAP-Konfiguration
/etc/ldap/ldap.conf:
BASE dc=domain,dc=tld URI ldap://dc1.domain.tld
Host zpub: Kerberos-Konfiguration
/etc/krb5.conf:
[libdefaults]
default_realm = DOMAIN.TLD
[realms]
DOMAIN.TLD = {
kdc = dc1.domain.tld
admin_server = dc1.domain.tld
default_domain = domain.tld
}
[domain_realm]
.domain.tld = DOMAIN.TLD
domain.tld = DOMAIN.TLDHost zpub: Testen von Ticket und Keytab-Datei:
$ kinit -k -t http_zpub.krb5keytab HTTP/$zpub-instance-name.domain.tld $ kvno HTTP/$zpub-instance-name.domain.tld@DOMAIN.TLD $ klist -e $ klist -e -k -t http_zpub.krb5keytab
Drei Angaben müssen jeweils übereinstimmen:
kvno
principal name
encryption type
Die zum Testen erstellen Tickets sollten wieder gelöscht werden:
$ kdestroy
Host zpub: apache-Module aktivieren:
$ a2enmod auth_kerb ldap authnz_ldap
Host zpub: apache konfigurieren:
AuthName "zpub single Sign On"
AuthType Kerberos
KrbAuthRealms DOMAIN.TLD
KrbServiceName HTTP/${zpub-instance-hostname}.domain.tld@DOMAIN.TLD
Krb5Keytab /etc/apache2/http_${zpub-instance-hostname}.krb5keytab
KrbMethodNegotiate on
KrbMethodK5Passwd off
KrbAuthoritative off
KrbLocalUserMapping on
#KrbVerifyKDC off
#KrbSaveCredentials on
AuthBasicProvider ldap
AuthLDAPURL ldap://dc1.domain.tld:3268/dc=domain,dc=tld?\
sAMAccountName?sub?(objectClass=*)
AuthLDAPBindDN apacheconnect@DOMAIN.TLD
AuthLDAPBindPassword not_be_guessable
<RequireAll>
Require ldap-group CN=zpub,DC=domain,DC=tld
</RequireAll>
Client: Webbrowser für SSO konfigurieren:
Firefox: network.negotiate-auth.trusted-uris: domain.tld
IE: Host zu Trusted Sites hinzufügen