Konto gesperrt (falsch) bei Anmeldeversuch an fernem Server

[Kernix 0]

Hallo zusammen,

 

folgende Situation:
Der User auf einem Windows 7 Rechner in der Domäne A soll sich mit der Freigabe auf einem Windows 2016 Server in der Domäne B verbinden.
Die Anmeldung schlägt fehl mit der Meldung: "Das angesprochene Konto ist momentan gesperrt und kann nicht für die Anmeldung verwendet werden"

 

Diese Meldung ist so nicht richtig, das Konto ist definitiv nicht gesperrt. Nach verschiedenen Tests kommt eigentlich nur noch eine falsch konfigurierte Firewall in Frage.
Genau hier liegt das spezielle Problem. Der Kunde mit Domäne A hat seine Firewall an einen externen Dienstleister vergeben, Kommunikation nur per Ticket möglich.
Der Lieferant des Kunden in Domäne B hat gleich seine gesamte IT outgesourced, gleiche Art der Kommunikation. 

Das naheliegende Vorgehen: "Firewalladmin am Telefon, Anmeldeversuch starten und sehen, welche Pakete verworfen werden" habe ich nach drei Wochen(!) organisatorisch nicht hinbekommen.

Diese Organisation zwingt mich nun dazu, die möglichen Fehlerquellen selbst zu benennen und diese dann gezielt an die verschiedenen Bereiche mitsamt Eskalation zur Überprüfung zu geben.

 

Deshalb frage ich Euch: Woran kann es liegen, dass es nicht klappt?

 

Hier das aktuelle Testszenario:
Auf dem Server in Domäne B gibt es die Freigabe \\server\share mit dem lokalen User test
Ein Windows 10 Rechner in Domäne B kann sich erfolgreich mit dieser Freigabe unter Nutzung von test verbinden

Ein Anmeldeversuch vom Windows 7 Rechner in Domäne A unter Nutzung des Users server\test scheitert mit o.g. Fehler.

 

Auf dem Rechner in Domäne A gibt es sowohl in hosts als auch in lmhosts die Einträge
1.2.3.4      server
"Ping server" funktioniert

 

Firewall Konfiguration:
Die IPs sind definiert und die Ports inklusive ICMP nur für diese IPs freigeschaltet

 

Ports ausgehend und eingehend zunächst:
TCP 137, 139, 445
UDP 137, 138

Mittlerweile zusätzlich
UDP 135, 136, 139, 445

 

Die beiden Class-B Netze sind (durch einen weiteren Dienstleister) 1:1 per VPN verbunden, da gibt es keine Restriktionen, nur einfaches Routing.

 

Wie gesagt, ich vermute, dass ein Teil der Firewall Freischaltung (trotz mehrfacher Überprüfungsanforderung) nicht korrekt erfolgt ist. Lässt sich das weiter eingrenzen?
Gibt es vielleicht noch eine ganz andere mögliche Fehlerursache?

 

Reichlich ratlos
Frank

 

bearbeitet 14. März 2020 von Kernix
Fehlende Infos

[daabm 1.366]

1. (Willst Du nicht hören) Der User sollte nicht von einem Win7-Client kommen...

2. (Willst Du auch nicht hören) Konto gesperrt ist komplett interpretationsfrei. Und das hat auch nichts mit fehlenden FW-Freischaltungen zu tun.

[Kernix 0]

Doch, will ich hören, hab ich auch gehört und mit allem Nachdruck weitergeleitet. Jetzt versteh ich aber gar nichts mehr:

Windows 10 Client wurde frisch und manuell aufgesetzt und zeigte genau den gleichen Fehler.

Da kommenden Freitag Deadline ist, haben wir heute ohne Verstand nur noch ausprobiert, was einem so in den Sinn kam.

 

Und hier ist der "Workaround", der mich schlecht schlafen lässt:

Firewalls sind komplett unschuldig, TCP 445 reicht.

Das Konto ist doch interpretationswürdig, denn es war und ist nicht gesperrt. 

Wenn ich aber in Domäne A den gleichen User mit gleichem Passwort anlege wie er lokal auf dem Server in Domäne B angelegt ist, funktioniert es. Berechtigungen greifen, wie auf dem Server der Domäne B hinterlegt. Es muss nur ein gewöhnlicher, ansonsten rechtloser Benutzer in Domäne A existieren.

 

Nä, das versteh ich nicht. Und weil ich das nicht verstehe, habe ich meinen Post hier ausgedruckt und einem Kollegen mit den Worten in die Hand gedrückt: Schau mal ob das wirklich alles genau so eingerichtet ist, wie hier beschrieben. Antwort war ja.

 

Höchst mysteriös...

bearbeitet 19. März 2020 von Kernix

[daabm 1.366]

Hm, ok. Noch mal von vorne. Da steht was von Einträgen in hosts und lmhosts. Warum?

TCP 445 reicht nicht. Kerberos braucht ein paar Ports mehr zu ein paar Systemen mehr. Gescheit weiterkommen wirst Du nur mit zumindest einem Netzwerktrace auf dem Client, wenn möglich auf dem Zielserver und idealerweise zeitgleich auch auf allen Domain Controllern aller beteiligten Domains.

Und warum schreibst Du was von einem "lokal auf dem Server in Domäne B" angelegten User?

 

Wir haben ungefähr 2.000 Domains mit Trusts in alle möglichen Richtungen (Uni/Bidi/mit und ohne SID-Filterung/PAM), aber das, was Du beschreibst, kenne ich nicht. Wenn hier ein Account als locked gemeldet wird, dann ist er das auch. Bei Dir könnte die Frage daher sein "in welcher Domäne befindet sich der gesperrte Account"?

[Kernix 0]

Ok, dann doch mal ein paar Worte zum Hintergrund, auch wenn sie nicht zum Problem gehören: Das Projekt hier ist ein reines SAP Projekt, von uns hier hat niemand wirklich Windows Expertise. Der Zugriff auf den Server beim Lieferanten ist dabei nur ein nettes Zuckerl, daher der allgemeine Unwille, dafür Ressourcen aufzubringen. Aber es steht leider im Pflichtenheft - weil ich *** ganz zu Beginn behauptet habe, dass wir das schon hinkriegen. Ich persönlich war mal Windows Admin - vor 15 Jahren.

 

Begonnen habe ich diese Aufgabe, indem ich die Kunden IT gebeten habe, mit der Lieferanten IT Kontakt aufzunehmen, mit denen zusammen einen Trust einzurichten und mir User und Passwort mitzuteilen, wenn alles fertig ist. Diese Aufgabe ist durch alle Eskalationsstufen gelaufen - ohne verwertbares Ergebnis. Aus Sicht der Projektleitung ist damit dieser Punkt abgeschlossen. Zwar erfolglos, aber da der Kunde seiner Mitwirkungspflicht nicht nachgekommen ist, stört uns das nicht weiter.

Diese Vorgehen ist zwar vertraglich einwandfrei, aber nicht sehr kundenfreundlich. Deshalb habe ich das beschriebene, natürlich völlig unübliche und unprofessionelle Konstrukt zu realisieren versucht, um wenigstens einen Workaround zu schaffen.

 

Soviel zur Vorgeschichte. Die aktuelle Aufgabe lautete daher:

Wie kann sich ein Client der Domäne A mit einer Freigabe auf einem Server der Domäne B verbinden, ohne dass irgendwelche Arbeiten an irgendwelchen anderen Komponenten (DNS, AD, was auch immer) notwendig sind?

 

Das habe ich versucht zu lösen, indem auf dem Server lokale User anstelle von Domänen User angelegt wurden und auf dem Client hosts und lmhosts anstelle von DNS/AD genutzt werden.

Das war auch der Plan B, den ich bei Erstellung des Pflichtenheftes im Hinterkopf hatte.

 

Hier vorgestellt habe ich das Problem, weil dieser Plan B aus mir unverständlichen Gründen nicht funktioniert hat.

Oder ja eben doch funktioniert, aber der Grund ist mir noch unverständlicher.

 

Natürlich kann ich sagen: Was soll's, es funktioniert ja jetzt.

Trotzdem nagt es an mir, weil ich zum einen den Grund nicht verstehe (was immer schlecht ist) und der Kunde jetzt mit einem nicht verstandenen Konstrukt arbeitet - und das weiterhin tun wird, weil es funktioniert ja.

 

War jetzt viel untechnisches Geschreibsel, aber ich verstehe schon, wenn ohne diese Infos keiner Lust hat, auch nur einen Gedanken an dieses Problem zu verschwenden...

 

Zu guter Letzt eine Antwort zu der Frage "in welcher Domäne befindet sich der gesperrte Account"?

Ich sehe hier nur drei mögliche Quellen: Lokaler Benutzer auf Server. Domänen Benutzer in Domäne A. Domänen Benutzer in Domäne B.

Bei den gescheiterten Versuchen war der lokale Benutzer nicht gesperrt. Das ist per Screenshot belegt.

Weder in Domäne A noch in Domäne B existierte ein Benutzerkonto mit Namen des genutzten Users. 

Für Domäne A ist das erwiesen, weil nach Anlage(!) dieses Kontos die Verbindung funktioniert hat

Für Domäne B ist das anzunehmen (wurde überprüft, aber nicht nachweislich), weil (edit:) in Domäne B nichts gemacht wurde. Sollte also aus purem Zufall der willkürlich gewählte Username in Domäne B existieren, dann kann doch nicht dieses gesperrte Konto plötzlich irrelevant sein, nur weil in Domäne A ein gleichnamiges Konto angelegt worden ist?

 

bearbeitet 22. März 2020 von Kernix
Keine Annahmen als nachweislich verkaufen...

[daabm 1.366]

Das kapier ich dann leider auch nicht Schön wäre ein Trace am Client - einfach mal sehen, was der denn so an Authentifizierungsversuchen wo hin schickt.