Jump to content

Kernix

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Kernix

  • Rank
    Newbie
  1. 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?
  2. 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...
  3. 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
×
×
  • Create New...