Client not found in Kerberos DB (Alfresco 4.0d MSAD 2008R2)

[mniess]

Hallo Community,

so langsam bin ich am Ende meiner Kräfte und hoffe auf freundliche Hilfestellung seitens der Community. Ich würde gerne meiner Abteilung die Möglichkeiten von Alfresco präsentieren, aber mein Weg ist nicht von Erfolg gesäumt ;-)

Den ersten Versuch unternahm ich mit dem Betriebssystem Windows 2008R2 (wird in der Abteilung favorisiert) und bekam die Kerberosauthentifizierung ans Laufen um letztlich bei der CIFS-Schnittstelle zu scheitern. Das habe ich als Windows-Problem abgehakt und den zweiten Versuch mit Ubuntu 12.04 LTS (wird von mir favorisiert) unternommen. Diesmal bekomme ich leider mit viel Kampf Kerberos nicht ans Laufen.

Natürlich habe ich akribisch die Anleitung "Configuring Kerberos against Active Directory befolgt" und mehrfach getestet und wiederholt, doch leider erhalte ich beim Startup den Fehler

"Client not found in Kerberos Database"

und weiß mir nicht mehr zu helfen.
Über

kinit -V -T /etc/alfrescohttp.keytab -p "HTTP.collab.firma.com@FIRMA.COM"

kann ich mich allerdings fehlerfrei authentifizieren. Ein Mitschnitt mit Netmon zeigt mir in diesem Fall

KerberosV5: AS Request Cname: cifs/collab.firma.com Realm: FIRMA.COM

Beim normalen Startup des Servers erhalte ich folgendes

KerberosV5: AS Request Cname: root Realm: FIRMA.COM

Kann mich bitte jemand in die richtige Richtung schubsen / treten? Sollten Infos fehlen liefere ich diese natürlich gerne nach.


java.login.config

Alfresco {
   com.sun.security.auth.module.Krb5LoginModule sufficient;
};

AlfrescoCIFS {
   com.sun.security.auth.module.Krb5LoginModule required
   storeKey=true
   useKeyTab=true
   keyTab="/etc/alfrescocifs.keytab"
   principal="cifs/collab.firma.com@FIRMA.COM";
};

AlfrescoHTTP {
   com.sun.security.auth.module.Krb5LoginModule required
   storeKey=true
   useKeyTab=true
   keyTab="/etc/alfrescohttp.keytab"
   principal="HTTP/collab.firma.com@FIRMA.COM";
};

com.sun.net.ssl.client {
   com.sun.security.auth.module.Krb5LoginModule sufficient;
};

other {
   com.sun.security.auth.module.Krb5LoginModule sufficient;
};

krb5.conf

[logging]
    default = FILE:/var/log/krb5.log

[libdefaults]
    default_realm = FIRMA.COM
    kdc_timesync = 1
    ccache_type = 4
    forwardable = true
    proxiable = true

[realms]
    FIRMA.COM = {
        kdc = dc1.firma.com
        admin_server = dc1.firma.com
        default_domain = FIRMA.COM
    }

[domain_realm]
    .firma.com = FIRMA.COM
    firma.com = FIRMA.COM

Ich möchte mich vorab bei allen bedanken, die sich Zeit für mich nehmen.

[afaust]

Hallo,

die Authentifizierung via kinit unter Linux ist nicht zwangsläufig gleichbedeutend mit einer Java-basierten Authentifzierung des Servers. Wurde Alfresco schon mal mit dem Parameter

-Dsun.security.krb5.debug=true‍

gestartet? Wie sieht die Logausgabe hierzu aus?
Sind u.U. zwei unterschiedliche Services auf den gleichen Nutzeraccount im AD gemappt? Dann könnte dies hier zutreffen: https://issues.alfresco.com/jira/browse/ALF-5994

Mich wundert auch ein wenig das Ergebnis zu

kinit -V -T /etc/alfrescohttp.keytab -p "HTTP.collab.firma.com@FIRMA.COM"‍

Ich hätte erwartet, hier nicht

KerberosV5: AS Request Cname: cifs/collab.firma.com Realm: FIRMA.COM‍

sondern

KerberosV5: AS Request Cname: http/collab.firma.com Realm: FIRMA.COM‍

erwartet. Sind die keytab Dateien korrekt generiert worden?

Das beim Serverstart der Principal "root" angefragt wird, deutet darauf hin, dass ggf. die java.login.config / eingetragenen Principals in der Alfresco Kerberos Konfig nicht korrekt eingetragen bzw. ausgewertet werden. Gerade letztere Dateien (ohne Passphrases u.ä.) wären nützlich, wenn sie hier mit aufgeführt wären. Die Startparameter des Servers (JAVA_OPTS) wären auch recht interessant.

Gruß
Axel

[mniess]

Hallo Axel,

erstmal vielen Dank für deine Antwort.
Ich fürchte ich habe das falsche kinit-Kommando mit der Ausgabe von Netmon gepostet. In den Mitschnitten stimmt der Principal mit dem Kommando überein. Der Dreher war schlichtweg
meine Schuld. Ich habe versucht mit kinit die Keyfiles zu prüfen, allerdings entwickeln sich bei mir zunehmend Zweifel ob die Files in Ordnung sind. Hier werde ich wohl weiter ansetzen. Gibt es eine Möglichkeit die Keyfiles eindeutig zu validieren.
Anfänglich habe ich versuchte 2 Services auf dieselben User zu mappen und bin dann auf den von dir geposteten Artikel gestossen. Deswegen habe ich kurzerhand die User gelöscht, neu angelegt und nur noch den neuen Service an die Accounts gebunden. Die Namen der User habe ich allerdings beibehalten.


Anbei die beiden Kerberos-Configfiles, welche ich angepasst habe:

kerberos-authentication.properties

kerberos.authentication.realm=FIRMA.COM
kerberos.authentication.user.configEntryName=Alfresco
kerberos.authentication.defaultAdministratorUserNames=Administrator
kerberos.authentication.cifs.configEntryName=alfrescocifs
kerberos.authentication.cifs.password=Pass123
kerberos.authentication.authenticateCIFS=true

kerberos-filter.properties

kerberos.authentication.http.configEntryName=alfrescohttp
kerberos.authentication.http.password=Pass123
kerberos.authentication.sso.enabled=true
kerberos.authentication.browser.ticketLogons=true

Ich lese mich mal in den von dir genannten Startparameter ein und versuche dir ein vernünftiges Ergebnis zu liefern. Außerdem spiele ich noch ein wenig mit den keytabs rum.

Nochmals vielen Dank für deine Antwort. ;-)

[mniess]

Hi Axel,

ich nochmal.

Bin gerade hierüber gestolpert.
https://issues.alfresco.com/jira/browse/DOC-109

Eventuell trifft mich das Problem obwohl ich die User gelöscht habe. Ich checke mal mein AD ob noch Leichen von der ersten Instanz an den Usern haften und / oder erstelle neue Accounts unter einem anderen Namen.


PS: Ich fürchte ich weiß mit "-Dsun.security.krb5.debug=true" nichts anzufangen. Das Debug-Level rund um Kerberos in der log4j.properties habe ich bereits hochgedreht.


Update:
- Nachdem der ServicePrincipalName nur ein Attribut des Users ist kann ich den Ansatz wohl ausschliessen. Beide Attribute der beiden User scheinen stimmig zu sein.
- Mein Versuch die Keyfiles über kinit zu überprüfen scheint wertlos zu sein, da folgender Versuch

kinit -V -t /crap -p "HTTP/collab.firma.com"
Using default cache: /tmp/krb5cc_0
Using principal: HTTP/collab.firma.com@FIRMA.COM
Password for HTTP/collab.firma.com@FIRMA.COM:
Authenticated to Kerberos v5

ebenso erfolgreich zu sein scheint und das obwohl es sich bei dem File /crap um eine leere Datei handelt.