KDC ID:11 - mehrfache Konten vom Typ DS_Service_Principal_Name

[Stonehedge 12]

Hallo Zusammen,

 

ich versuche die ganze Zeit schon die Auswirkungen dieser Meldung zu verstehen.

Wir haben drei Microsoft Dynamics Server (Produktiv, Testumgebung & Entwicklung). Nun sind im Log des DCs stündlich Einträge der Quelle KDC mit der ID 11, dass mehrfache Konten vom Typ DS_Service_Principal_Name vorhanden sind. Ich habe mittlerweile herausgefunden, dass es sich um die Dienstkonten für das CRM handelt, die für alle drei Server verwendet wurden. Alle drei Dienstkonten haben den gleichen SPN eingetragen.

 

Was ich nicht verstehe ist, was hier nun schief gehen kann? Bekannte Probleme der Anwender gibt es nicht, mich nervt allerdings der Eintrag im Log und noch mehr nervt mich, dass ich nicht genau verstehe, welche Auswirkungen das nun hat.

 

 

 

Kann mir das evtl. einer von euch erklären?

 

 

 

Das hier hatte ich noch gefunden, macht mich aber irgendwie nicht schlauer:

 

This is what MVP Joe Kaplan had to say:

 

Kerberos uses SPNs extensively.

 

When a Kerberos client uses its TGT to request a service ticket for a specific

service, the service is actually identified by its SPN. The KDC will grant

the client a service ticket that is encrypted in part with a shared secret

that the service account as identified by the AD account that matches the

SPN has (basically the account password).

 

In the case of a duplicate SPN, what can happen is that the KDC will

generate a service ticket that may be created based on the shared secret of

the wrong account. Then, when the client provides that ticket to the service

during authentication, the service itself cannot decrypt it and the auth

fails. The server will typically log an "AP Modified" error and the client

will see a "wrong principal" error code. I forget the exact error code and

description, but hopefully that's close enough. :)

 

So, duplicate SPNs are very bad, much in the same way that duplicate UPNs

are bad. Both can cause Kerb auth to break and Windows uses Kerb for auth

everywhere it can.

 

Probleme, dass die Authentifizierung fehlschlägt sind nicht bekannt.

 

Danke an jeden, der Licht in Dunkel bringt :)

 

Grüße,

Stonehedge

[olc 18]

Hi,

 

Du hast "Glück" - Dein CRM spricht derzeit kein Kerberos (aufgund des Fehlers), fällt jedoch auf NTLM zurück. Daher siehst Du keine Probleme, obwohl es im Kern eines gibt.

 

Warum verwendest Du anstatt der drei Konten nicht ein Dienstkonto? Im Regelfall ist das die Konfiguration, wenn es um Lastenausgleich o.ä. gibt, so daß mehr als eine Maschine im gleichen Kontext / Dienstbenutzer läuft.

 

Viele Grüße

olc

[Stonehedge 12]

Hallo olc,

 

vielen Dank für deine Antwort und sorry, dass ich jetzt erst antworte. Habe mir das Ticket nochmal vorgenommen und wollte es endlich schließen, daher bin ich jetzt erst wieder darauf gekommen ;)

 

Die Installation ist leider nicht von mir, aber um den Verantwortlichen dazu zu bringen, es abzuändern, würde er gerne die Auswirkung erläutert haben und mir ist es einfach nicht ganz klar, was passieren kann.

 

Was wäre denn, wenn das CRM Kerberos bzw. kein NTLM sprechen würde? Wie würde sich der Fehler darstellen?

 

Viele Grüße,

Stonehedge

[olc 18]

Hi,

 

Was wäre denn, wenn das CRM Kerberos bzw. kein NTLM sprechen würde? Wie würde sich der Fehler darstellen?

 

Genau anders herum - NTLM statt Kerberos. ;)

 

Das führt jetzt ganz schön weit... ;)

Ganz kurz und knapp: Kerberos ist sicherer, performanter, kann Tickets delegieren, single sign-on usw. usf.

 

Insgesamt hat es Sinn, das Thema wie angesprochen anders zu adressieren, z.B. mit einem Service Account. :)

 

Viele Grüße

olc