Hallo Leute!
Ich habe einen Server mit Ubuntu 14.04, auf dem ich mit Samba4 einen Active Directory Controller eingerichtet habe (der funktioniert). Auf dem Server habe ich Apache 2.4.7 installiert.
Nun wollte ich eine Seite in Apache anlegen, die die Nutzer mit SSO erreichen können. Ich habe also folgendes gemacht:
samba-tool user create --random-password http-www samba-tool spn add HTTP/www.cch.intra http-www samba-tool domain exportkeytab /etc/apache2/apache.keytab --principal=HTTP/www.cch.intra@CCH.INTRA chown www-data:www-data /etc/apache2/apache.keytab chmod 640 /etc/apache2/apache.keytab
Damit habe ich den "principal" angelegt und den keytab für Apache. Dann in Apache habe ich folgendes:
<Directory /home/www/cchportal/> AuthType Kerberos AuthName "Interner Bereich"
KrbMethodNegotiate On KrbMethodK5Passwd On KrbAuthRealms CCH.INTRA Krb5KeyTab /etc/apache2/apache.keytab KrbLocalUserMapping On
Require valid-user </Directory>
Apache startet ohne Fehlermeldungen, aber das ganze funktioniert nicht... Wenn ich mit lynx versuche mich anzumelden wird ein Passwort gefragt (logisch!). Ich gebe meine Daten und die Authentifizierung klappt nicht. In der ErrorLog sehe ich:
[Fri Apr 15 21:26:28.557109 2016] [auth_kerb:error] [pid 14416] [client 192.168.50.1:34412] failed to verify krb5 credentials: Wrong principal in request
Wenn ich von einem Windows-Client mit Firefox oder IE versuche, wird nach einem Passwort gefragt, also der SSO geht nicht.
Hat jemand eine Ahnung warum?
Danke Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de schrieb:
Wenn ich von einem Windows-Client mit Firefox oder IE versuche, wird nach einem Passwort gefragt, also der SSO geht nicht.
Noch was:
Ich habe gerade versucht, den principal HTTP/main.cch.intra@CCH.INTRA (main.cch.intra ist der Hostname des Servers) in den Keytab hinzuzufügen und die Apachekonfiguration so anzupassen:
<Directory /home/www/cchportal/> AuthType Kerberos AuthName "Interner Bereich"
KrbAuthoritative off KrbAuthRealms CCH.INTRA Krb5Keytab /etc/apache2/apache.keytab KrbMethodNegotiate on KrbServiceName HTTP Require valid-user </Directory>
Nun kann ich mich mit dem Passwort anmelden, allerdings der SSO von Firefox oder IE geht immer noch nicht (und keine Meldung ist in der Log zu sehen).
Ich freue mich auf eure Ideen!
Grüße Luca Bertoncello (lucabert@lucabert.de)
Nun kann ich mich mit dem Passwort anmelden, allerdings der SSO von Firefox oder IE geht immer noch nicht (und keine Meldung ist in der Log zu sehen).
Da prüfen wir mal der Reihe nach:
1. auf dem Apache-Server die Gültigkeit der Krb5Keytab =========================================
Muß in etwa so aussehen:
$ klist -k /etc/apache2/apache.keytab Keytab name: FILE:/etc/apache2/apache.keytab KVNO Principal ---- -------------------------------------------------------------------------- 4 HTTP/main.cch.intra@CCH.INTRA
$ kvno HTTP/main.cch.intra@CCH.INTRA HTTP/main.cch.intra@CCH.INTRA: kvno = 4
$ kvno -k /etc/apache2/apache.keytab HTTP/main.cch.intra@CCH.INTRA HTTP/main.cch.intra@CCH.INTRA: kvno = 4, keytab entry valid
Die KeyVersionNumber (kvno) kann bei Dir eine andere sein, Hauptsache in Keytab und auf dem Kerberos-Server gleich.
2. auf dem Rechner, wo Firefox läuft =========================== - gleiche /etc/krb5.conf wie auf dem Apache-Server?
- gültiges Kerberos-Ticket vorhanden? (ansonsten fällt der Brauser auf Passwort-Eingabe zurück) Bekommt man frisch bei Anmeldung oder Bildschirm-Entsperren, wenn das System korrekt konfiguriert ist. Ansonsten "$ kinit"
Prüfen geht mit $ klist Ticket cache: DIR::/<woauchimmer> Default principal: dein_login_name@CCH.INTRA
Valid starting Expires Service principal <Datum, Uhrzeit> <Datum, Uhrzeit> krbtgt/CCH.INTRA@CCH.INTRA renew until <Datum, Uhrzeit>
3. Firefox - "about:config" ===================
Da muß
network.negotiate-auth.trusted-uris - cch.intra
gesetzt sein. Bei G*gle Ch*me geht da auch "*"
Zitat von William Epler william.epler@globalfoundries.com:
Nun kann ich mich mit dem Passwort anmelden, allerdings der SSO von Firefox oder IE geht immer noch nicht (und keine Meldung ist in der Log zu sehen).
Da prüfen wir mal der Reihe nach:
Am Ende das Problem war eine Einstellung in IE und Firefox, zu sagen, dass die Seite zu vertrauen ist. Eingestellt, geht problemlos!
Also, das Problem lag nicht am Server.
Danke trotzdem Luca Bertoncello (lucabert@lucabert.de)
lug-dd@mailman.schlittermann.de