Wir haben eine Situation, in der eine Softwareanwendung nicht installiert werden kann, weil das während der Installation verwendete Administratorkonto während der Voraussetzungsprüfungen gesperrt wird. Nach einigen Untersuchungen haben wir die Ursache gefunden: Die Voraussetzungsprüfung prüft die Remote-Registrierungseinstellungen anderer Server per RPC-Aufruf an die IP-Adresse des Servers statt an seinen FQDN, und aus irgendeinem Grund führt dies dazu, dass die Authentifizierung fehlschlägt und das Konto gesperrt wird.
Wir haben dies wie folgt überprüft:
- Wenn Sie regedit verwenden und versuchen, über den FQDN des Servers eine Verbindung zur Registrierung eines anderen AD-Servers herzustellen, funktioniert die Verbindung problemlos.
- Wenn wir versuchen, dieselbe Verbindung mit der IP-Adresse des Servers herzustellen, werden wir zur Eingabe neuer Anmeldeinformationen aufgefordert.
- Alle AD-Anmeldeinformationen schlagen fehl und sperren schließlich das verwendete Konto. Bei der Verwendung eines lokalen Administratorkontos treten jedoch keine Probleme auf.
Wir haben diesen Test auch von anderen Servern in der Umgebung aus durchgeführt, aber sie hatten keine Probleme mit der Verbindung und Authentifizierung per IP. Wir haben die NIC-/DNS-/WINS-Einstellungen verglichen, aber es gab keinen nennenswerten Unterschied. Wir sind dabei, die GPO-Einstellungen zu überprüfen, aber wir erwarten nicht, etwas zu finden.
Wir könnten natürlich einfach lokale Administratorkonten verwenden, aber wir wollen verstehenWarumEin RPC-Aufruf, der eine IP-Adresse statt des FQDN verwendet, führt dazu, dass die AD-Authentifizierung fehlschlägt und AD-Konten gesperrt werden. Irgendwelche Ideen?
Antwort1
Wenn das Konto gesperrt wird, liegt definitiv ein Kennwortproblem vor. Andernfalls liegt es möglicherweise daran, dass Kerberos nicht verwendet wird und NTLM deaktiviert ist oder etwas anderes. Sie müssen das Sicherheitsprotokoll des Quell- und Zielservers überprüfen und alle Protokolleinträge angeben, die mit dem Authentifizierungsproblem in Zusammenhang stehen könnten.
Sie können dies auch versuchen. Allerdings ist es nicht sehr effizient, Dinge zu ändern, wenn Sie nicht einmal wissen, warum etwas nicht funktioniert, und kann andere Dinge kaputt machen.
Ab Windows 10 Version 1507 und Windows Server 2016 können Kerberos-Clients so konfiguriert werden, dass sie IPv4- und IPv6-Hostnamen in SPNs unterstützen.
Standardmäßig versucht Windows nicht, einen Host per Kerberos zu authentifizieren, wenn der Hostname eine IP-Adresse ist. Stattdessen wird auf andere aktivierte Authentifizierungsprotokolle wie NTLM zurückgegriffen. Allerdings sind Anwendungen manchmal so codiert, dass sie IP-Adressen verwenden, was bedeutet, dass die Anwendung auf NTLM zurückgreift und nicht Kerberos verwendet. Dies kann zu Kompatibilitätsproblemen führen, wenn Umgebungen NTLM deaktivieren.
Um die Auswirkungen der Deaktivierung von NTLM zu verringern, wurde eine neue Funktion eingeführt, die es Administratoren ermöglicht, IP-Adressen als Hostnamen in Service Principal Names zu verwenden.
Lesen Sie mehr unter
https://docs.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip