Zugriff verweigert bei Netzwerkzugriff über IP

[!faculty]

Hallo zusammen,

wir haben zur Zeit ein bisher nicht wirklich eingrenzbares und daher ungelöstes Problem.

Wir arbeiten in einer Server 2012r2 Domäne mit mehreren virtuellen Servern.

Seit Neuestem funktioniert der Aufruf von Freigaben nur noch über den DNS-Namen, ein Aufruf über IP-Adresse ruft ein Passwortfenster auf.

Beispiel:

SRV-DC

SRV-APP

Angemeldet als Domänenadmin

Zugriff von SRV-APP auf \\SRV-DC -> klappt, Freigaben werden angezeigt

Zugriff von SRV-APP auf \\<IP-Adresse SRV-DC> -> Passwortfenster, Zugriff verweigert, Eingabe des Domadmin-Accounts führt zu nichts

Zugriff von SRV-DC auf sich selbst -> klappt über \\localhost, \\SRV-DC, \\<IP SRV-DC>


Ich hoffe, ich konnte das Problem deutlich machen und jemandem fällt eine zündende Idee ein.

 

[Bruzla]

Ich hatte so einen Fall Mal aber ich weiß nicht mehr wie ich das Problem gelöst habe...

DNS-Dienst neugestartet? Cache geleert? Doppelte IP-Adressen?

 

[fuz2z3l]

Vielleicht das hier?

klick

 

[!faculty]

DNS hatte ich auch zuerst im Verdacht, wie so oft wenn im AD was schief läuft
Auflösung funktioniert aber sauber in beide Richtungen

DC wurde bereits neu gestartet.

Wenn ich vom DC aus auf Freigaben eines anderen Servers zugreifen will, bekomme ich allerdings "Die Vertrauensstellung zwischen dieser Arbeitsstation und der Domäne konnte nicht hergestellt werden", eine Meldung, die ich sonst nur von Clients kenne und das auch mehr beim Anmelden.

Der beschriebene Artikel von fuz2z3l ist es leider auch nicht, auf die Admin-Shares kann ich sauber zugreifen, allerdings natürlich auch nur über DNS Name

 

[wirelessy]

Das Stichwort ist Kerberos.
Für eine IP hast du keinen SPN.

//e: https://www.faq-o-matic.net/2015/08/26/wofuer-braucht-es-eigentlich-diesen-spn/, https://support.microsoft.com/de-de...you-connect-to-smb-shares-by-using-ip-address

Wieso aber jetzt anscheinend nicht mehr automatisch NTLM genutzt wird, ist mir nicht direkt klar. Da scheint das Trust-Issue mit reinzuspielen.

 

[!faculty]

Gut, dann stellt sich mir aber folgende weitere Frage:

Aufgefallen ist das Ganze, weil dort als Backup-Lösung veeam Backup&Replication eingesetzt wird und das Backup seit einiger Zeit fehlschlägt (gibt zwar jeden Tag ne Mail, aber die wird scheinbar erstmal 1,5 Wochen gekonnt ignoriert)
Dort werden normalerweise die VMs im laufenden Betrieb gesichert und dank der dort gespeicherten Windows-Credentials können die Objekte einzeln gesichert und wiederhergestellt werden.
Im Log des Ganzen zeigte sich dann ebendieses "Permission denied" und beim weiteren Überprüfen ist dann die oben beschriebene Problematik zutage gekommen.

Da die komplette Lösung aber vorher funktionierte muss kann das reine Verzichten auf Kerberos nicht des Pudels Kern sein.

Desweiteren habe ich gerade in unser eigenen Domäne das Gleiche nachgestellt und natürlich kann ich mich sowohl über DNS-Name als auch über IP mit meinen Netzwerkshares auf dem Server verbinden, wobei jeweils mein eigener Useraccount für die Rechte herangezogen wird.

Es muss also eine Möglichkeit geben, die beschriebene Problematik wieder aufzulösen.

Ereignisanzeige ist btw vollkommen unauffällig

 

[wirelessy]

Hat evtl. irgendwer NTLM komplett für Auth abgeschaltet? Wann ist denn der Fehler aufgetreten?
Frag mal evtl. euren Securitytyp, die basteln gerne mal an sowas rum
Oder es geschieht ein Fallback auf SMBv1, und das wurde für WannaCry abgeschaltet. Wär so meine Idee.