Problem mit Kerberos unter Apache
Hallo zusammen,
ich versuche gerade Kerberos auf unserem Apache zu konfigurieren und komme leider nicht weiter.
Die Webseite (Typo3) auf dem Apache wird von intern und extern mit sub.domain.com aufgerufen
Die lokale Domain lautet intern.local
das keytab File habe ich so erzeugt:
das krb5.conf File sieht so aus:
der Apache vhost sieht so aus:
Problem ist nun, wenn ich die vhost Konfig so aktiv schalte, dann erhalte ich beim Aufruf der Seite https://sub.domain.com immer direkt ein Browser-Popup zur Eingabe von Username und Passwort. Und egal was ich hier eingebe, ich gelange nicht auf die Webseite und erhalte nur den Fehler:
ich versuche gerade Kerberos auf unserem Apache zu konfigurieren und komme leider nicht weiter.
Die Webseite (Typo3) auf dem Apache wird von intern und extern mit sub.domain.com aufgerufen
Die lokale Domain lautet intern.local
das keytab File habe ich so erzeugt:
ktpass -princ HTTP/sub.domain.com@INTERN.LOCAL -mapuser kerb@intern.local -pass P@55w0rd -crypto ALL -ptype KRB5_NT_PRINCIPAL -out C:\temp\kerbkey.keytab
das krb5.conf File sieht so aus:
[libdefaults]
default_realm = INTERN.LOCAL
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
[realms]
INTERN.LOCAL = {
kdc = dc01.intern.local
admin_server = dc01.intern.local
default_domain = intern.local
}
[domain_realm]
.sub.domain.com = INTERN.LOCAL
sub.domain.com = INTERN.LOCAL
intern.local = INTERN.LOCAL
.intern.local = INTERN.LOCAL
der Apache vhost sieht so aus:
<VirtualHost *:443>
ServerName sub.domain.com
ServerAdmin it-administration@domain.com
DocumentRoot /var/www/page
<Directory /var/www/page>
AllowOverride All
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/wildcart-zert.crt
SSLCertificateKeyFile /etc/apache2/ssl/wildcart-key.key
<IfModule !mod_auth_gssapi.c>
LoadModule auth_kerb_module /usr/lib/apache2/modules/mod_auth_gssapi.so
</IfModule>
LimitRequestFieldSize 32768
<Location "/">
AuthName kerb@INTERN.LOCAL
AuthType GSSAPI
GssapiBasicAuth On
GssapiCredStore keytab:/etc/apache2/krb5/kerbkey.keytab
Require valid-user
</Location>
ErrorLog ${APACHE_LOG_DIR}/page-ssl_error.log
CustomLog ${APACHE_LOG_DIR}/page-ssl_access.log combined
</VirtualHost>
Problem ist nun, wenn ich die vhost Konfig so aktiv schalte, dann erhalte ich beim Aufruf der Seite https://sub.domain.com immer direkt ein Browser-Popup zur Eingabe von Username und Passwort. Und egal was ich hier eingebe, ich gelange nicht auf die Webseite und erhalte nur den Fehler:
Unauthorized
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
Apache/2.4.41 (Ubuntu) Server at sub.domain.com Port 443
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1738778250
Url: https://administrator.de/forum/problem-mit-kerberos-unter-apache-1738778250.html
Ausgedruckt am: 26.12.2024 um 17:12 Uhr
3 Kommentare
Neuester Kommentar
funktioniert denn das kerberos setup wenn man "per hand" was machen will?
also beim aufruf von
bekommst du da das krbtgt ticket? zu prüfen mit
Desweiteren:
Was sagt der Apache access/error log? Da müsste genaueres stehen, hast ja schön konfiguriert mit:
also beim aufruf von
kinit
klist
Desweiteren:
Was sagt der Apache access/error log? Da müsste genaueres stehen, hast ja schön konfiguriert mit:
ErrorLog ${APACHE_LOG_DIR}/page-ssl_error.log
CustomLog ${APACHE_LOG_DIR}/page-ssl_access.log combined
Puh, leider habe ich letzte mal vor Jahrzehnten mal gemacht...
Schau dir mal andere Tutorials an, ich tippe mal das man die Optionen im Apache conf etwas anpassen muss, hier z.B.
https://serverfault.com/questions/1018615/authenticating-apache-httpserv ...
ggf. hilft es auch auf der Auth-Gegenstelle, dem DC, im Log zu schauen, vielleicht wirste schlau draus
Schau dir mal andere Tutorials an, ich tippe mal das man die Optionen im Apache conf etwas anpassen muss, hier z.B.
https://serverfault.com/questions/1018615/authenticating-apache-httpserv ...
ggf. hilft es auch auf der Auth-Gegenstelle, dem DC, im Log zu schauen, vielleicht wirste schlau draus