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
Please also mark the comments that contributed to the solution of the article
Content-ID: 1738778250
Url: https://administrator.de/contentid/1738778250
Printed on: December 14, 2024 at 15:12 o'clock
3 Comments
Latest comment
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