Kerberos SSO Authenifikation mit dem Apache

[PlugAndPlay]

Hi,

ich versuche gerade meinen Apache Server die Kerberos Authenfikation beizubringen aber irgendwie will er nicht so ganz wie ich.

Ich bekomme immer folgende Fehlermeldung:

gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information (No principal in keytab matches desired name)

Ich bin folgendermaße vorgegangen: - In der AD habe ich einen User Names aSSO angelegt - Dann habe ich eine Keyfile mit folgenden Befehl erstellt:

"c:\Program Files\Support Tools\ktpass" -princ HTTP/apache_server.mein.lan@MEIN.LAN  -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapuser aSSO  -mapop set +desonly -pass test -out c:\temp\aSSO.keytab

- Die Keyfile auf den Apache Server kopiert und die Berechtigung für die Datei vergeben - beim Apache Server den Kerberosmod aktiviert

a2enmod auth_kerberos

- die /etc/krb5.conf folgendermaßen angepasst

[libdefaults]

    default_realm = MEIN.LAN


[realms]

MEIN.LAN = {

     admin_server = dc.mein.lan

     kdc = dc.mein.lan

}


[domain_realm]

    apache_server.mein.lan = MEIN.LAN

- folgenden vhost Eintrag verfasst

<Directory "/var/www/sso">


Allow from all



AuthName "Kerberos"

AuthType Kerberos

KrbAuthRealms MEIN.LAN

KrbServiceName HTTP

Krb5Keytab /share/aSSO.keytab

KrbMethodNegotiate on

KrbMethodK5Passwd off

Require valid-user



</Directory>

Sieht jemand den Fehler? Was vielleicht auch intressant ist: Wenn ich mich mit meinen user kinit und klist ausführe:

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: meinuser@MEIN.LAN


Valid starting     Expires            Service principal

04/20/09 10:03:10  04/20/09 20:05:19  krbtgt/MEIN.LAN@MEIN.LAN

        renew until 04/21/09 10:03:10



Kerberos 4 ticket cache: /tmp/tkt0

klist: You have no tickets cached

- wenn ich "kinit -k -t /share/aSSO.keytab HTTP/apache_server.mein.lan" und klist ausführe

Ticket cache: FILE:/tmp/krb5cc_0

Default principal: HTTP/apache_server.mein.lan@MEIN.LAN


Valid starting     Expires            Service principal

04/20/09 10:06:03  04/20/09 20:08:09  krbtgt/MEIN.LAN@MEIN.LAN

        renew until 04/21/09 10:06:03



Kerberos 4 ticket cache: /tmp/tkt0

klist: You have no tickets cached

[Dio]

Hi,

mit welchem DNS Namen versuchst du die Webseite aufzurufen?

apache_server.mein.lan oder apache_server?

Außerdem würde ich KrbMethodK5Passwd zu Testzwecken erst mal auf on setzen um Probleme mit dem IE auszuschließen.

LG,

Dio

[PlugAndPlay]

Hatte es mit beiden DNS Names versucht...

KrbMethodK5Passwd habe ich auf on gestellt aber ebenfalls ohne Erfolg

[Dio]

Welches SP hat dein Win 2003 Server denn?

Ich habe das Service Principal auf einem Server mit SP1 mit folgendem Befehl erstellt:

ktpass -princ HTTP/apache_server.mein.lan@MEIN.LAN -mapuser aSSO -crypto DES-CBC-MD5 -ptype KRB5_NT_SRV_HST -pass test -out c:\temp\aSSO.keytab

Ist in deiner Apache Config KeepAlive auf On gesetzt?

Hast du die Datei /etc/nsswitch angepasst?

Laufen die Daemons winbind und smb?

Bearbeitet 22. April 2009 von Dio

[PlugAndPlay]

Also

- der Windows 2003 Server hat ebenfalls SP1 und beim erstellen der Keyfile gab es auch keine Fehlermeldung.

- KeepAlive ist in der Apachekonfig ebenfalls aktiviert

- Der SMB Deamon läuft, der Winbound Deamon nicht.

- Die /etc/nsswitch.conf habe ich nicht angepasst. Was gehört den da normalerweise rein?

[Dio]

Bei der nsswitch und bei der smb.conf bin ich mir nicht sicher ob du die konfigurieren musst wenn du den Server nur für Apache SSO nutzen willst.

Ich hab in der nsswitch folgendes stehen:

passwd: files winbind

shadow: files

group: files winbind

Winbind muss meines Wissens nach auf jedenfall laufen.

Da die Fehlermeldung auf das Service Principal verweist tippe ich mal drauf das da irgendwas schief gelaufen ist. Versuchs doch nochmal mit dem Befehl der bei mir funktioniert hat. Kann ja nicht schaden..

EDIT: Habs grade getestet. SSO geht auch ohne Winbind.. Vergiss also die nsswitch.conf und den winbind Daemon..

Bearbeitet 22. April 2009 von Dio

[PlugAndPlay]

Hab das jetzt mit deinem Befehl probiert und bekomm jetzt eine andere Fehlermeldung :/

udn zwar:

gss_accept_sec_context() failed: Unspecified GSS failure.  Minor code may provide more information (Key table entry not found)

[PlugAndPlay]

Wie gesagt kommt bei mir jetzt die unten aufgeführte Fehlermeldung... stelle ich aber die "KrbMethodK5Passwd" auf "On"... funktioniert es!

Nur eben halt mit einem Eingabe Fenster... ich wollte ja aber eigentlich per SingleSignOn... probiert habe ich es z.B. mit dem IE 6. Dort habe ich die Option "integrierte Windows-Authentifizierung aktivieren" eingeschaltet sowie die Site unter Sicherheit in Intranet aufgenommen!

Ich habe es auch mit dem IE7 und Firefox mit angepassten Einstellungen probiert.

Alles ohne Erfolg.... Es kommt immer unten aufgeführte Fehlermeldung sobald ich "KrbMethodK5Passwd" auf "Off" stelle.

Hast du mir vielleicht einen Tipp?

[Dio]

Wird die Seite als Lokale Intranetseite oder als vertrauenswürdige Seite im IE angezeigt?

Folgende GPO's müssen gesetzt werden:

Logon options Enabled

Logon options Automatic logon only in Intranet zone

[PlugAndPlay]

Die Seite wird im IE als Intranetseite erkannt.

Hast du mir nen Tipp wo diese Einstellungen in den GPOs sind?

[PlugAndPlay]

Ich habe die Einstellungen glaube ich auch unter "Internetoptionen / Sicherheit / Lokales Intranet --> Stufe anpassen --> [benutzerauthenfikation] [Anmelden]" gefunden und habe dort mal zu Testzwecken folgenden eingestellt: "Automatische Anmeldung mit aktuellen Benutzernamen und Password".

Aber leider ohne Erfolg :/

EDIT: Was mir auch noch gerade aufgefallen ist, das in dem Anmeldefenster folgendes steht:

Der Server "apache" an "" erfordert einen Benutzernamen und Kennwort....

Kann das mit meinem Problem zu tun haben?

Bearbeitet 28. April 2009 von PlugAndPlay

[Dio]

Der Pfad ist bei mir "User Configuration/Administrative Templates/Windows Components/Internet Explorer/Internet Control Panel/Security Page/Intranet Zone"

Bei mir steht nur "Verbindung zu $hostname herstellen" im Anmeldefenster.

Weiß nicht ob das was damit zu tun hat.

[PlugAndPlay]

Hier mal ein Screenshot vom Loginfenster:

[Dio]

Was gibts du denn für Logindaten ein?

domäne\username oder nur username?

[PlugAndPlay]

nur username.....

Meinst du das daran liegen kann das beim SSO mit domäne\username gearbeitet wird?

Naja werd das wohl erst am Montag testen können, hab jetzt erstmal 2 Tage Berufsschule ^^

[Dio]

Nein nur Username ist eigentlich richtig.

Entferne mal das Allow from all aus der httpd.conf

[PlugAndPlay]

Es kommt zumindest mal eine andere Fehlermeldung ^^

und zwar:

 [error] [client xxx.xxx.xxx.xxx] client denied by server configuration: /var/www/xxx

Aber ist das nicht ein Schritt zurück? Ich denke jetzt wird die Authenfizierung erst garnicht ausgeführt :/

[Dio]

Ja sieht so aus. Komisch.. Bei mir funktioniert es mit folgender Config:

<Directory "/var/www/html/test">

AuthType Kerberos

KrbAuthRealms DOMAIN.LOCAL

KrbServiceName HTTP

Krb5Keytab /usr/local/httpd/conf/http_hostname.krb5keytab

KrbMethodNegotiate on

KrbMethodK5Passwd on

require valid-user

</Directory>

[PlugAndPlay]

Was mir auch noch aufgefallen ist das anmelden an dem Loginfenster funktioniert mit folgenden Eingaben: "username" und "username@DOMÄNE"

aber so nicht "DOMÄNE\username"

In der phpinfo steht unter Apache Environment: REMOTE_USER auch "username@DOMÄNE", deshalb gehe ich mal davon aus das der Browser das auch so an Apache gibt.

Ich bin langsam echt am verzweifeln :/

[Dio]

"DOMÄNE\username" funktioniert bei mir ebenfalls nicht.. Nur "username"..

Mit meinem normalen Benutzer muss ich bei mir auch den Username eingeben da SSO bei uns durch globale GPO's verhindert wird. Nur mit meinem OU Admin funktioniert SSO einwandfrei da dort weniger Policies gesetzt sind.

Wenn der Login bei dir mit Username und Passwort funktioniert dann ist an der Config vom Linuxserver alles ok. Das Problem sind dann eher irgendwelche GPO's oder dein Browser.

[PlugAndPlay]

habe ich das aber richtig verstanden das SSO nur dann funktnioniert wenn mann "KrbMethodK5Passwd" auf "off" stellt?

Das mit den GPO´s werd ich nochmal mit einen User versuchen auf den keine GPO´s gelten sollten.....

Das merkwürdige ist das SSO bei unserem Sharepoint Server ja auch zu funktionieren scheint.

Bearbeitet 5. Mai 2009 von PlugAndPlay

[Dio]

Nein mit KrbMethodK5Passwd legst du nur fest ob ein Passwortfenster kommen soll falls der angemeldete User sich nicht anmelden darf bzw. SSO nicht funktioniert. Bei mir ist KrbMethodK5Passwd auf on.. Deshalb kann ich mich mit meinem Admin Account per SSO anmelden und bekomme bei meinem normalen User das Passwortfenster..

Ob und inwieweit sich SSO zwischen Apache und Sharepoint unterscheidet kann ich nicht sagen. Versuchs einfach mal mit einem User mit Default GPO's.