KitKat 10 Geschrieben 7. Februar 2014 Melden Teilen Geschrieben 7. Februar 2014 Hallo Zusammen, ich habe derzeit ein komplexes Problem und bin für jedewede Anregung dankbar. Wir mirgrieren von Novell (eDirectory) und XP auf AD und Win7 Bundesweit. Das ganze ist in mehrere Teilprojkete unterteilt und ich bin verantwortlich für die Migration der Kunden PCs inkl. der reibungslosen Aufnahme der PCs ins AD. Das AD für den Kunden ist fertig und befindet sich innerhalb einer Gesamtstruktur. Nach ersten Tests sind DNS Probleme aufgefallen, die angeblich behoben sein sollen. Es gibt 2 Server für meinen Kunden die neben DNS auch die AD-Dienste hosten. Jeder DC (Ich glaube es sind so an die 200) innerhalb der Gesamtstruktur hostet auch DNS. Ich habe heute einen Benutzer-Account in der übergeordneten Domain erhalten, der das Recht hat den Domain-Join in einer bestimmten OU zu vollziehen. Ich habe ein Win7 Testgerät. Die DCs stehen aus Clientsicht hinter einer FW. (Es wurden Ports freigeschaltet hierzu etwas weiter unten mehr) Ich habe das Win7 Testgerät erfolgreich der Domäne hinzugefügt. Allerdings folgte die Fehlermeldung das der RPC-Server nicht verfügbar sei auf dem Fuß. Danach schlägt jedwede Anmeldung fehl. Also die Aufnahme funktioniert die Anmeldung jedoch nicht. Melde ich mich mit meinem Account in der Untergeordneten Domäne an erhalte ich die Fehlermeldung: Kennwort oder Benutzername falsch Versuche ich mich an der übergeordneten Domäne anzumelden erhalte ich die Fehlermeldung: Die Sicherheitsdatenbank habe keinen Eintrag über den PC und die Vertrauensstellung sei nicht vorhanden. (Was ja auch irgendwie stimmt, der PC befindet sich ja in der untergeordneten Domain) Ich habe mehrere Benutzerkonten für Testzwecke erhalten, das Ergebnis ist immer das Gleiche. Heute wurde die FW für ein Netzsegment mit einer Portfreischaltung Any<->Any konfiguriert. Die Fehlermeldung ist die Gleiche. Ich kann mich nicht anmelden. Ich versuche es trotzdem mal etwas besser darzustellen. Beispiel:NRW.test.de (Hier wurde mein Benutzeraccount angelegt)RS.NRW.test.de (Hier in einer OU - man hat mir nicht mal gesagt in welcher - ist mein Workstation Objekt) Da die FW heute Any<->Any geschaltet war und erübrigt sich hier zu posten welche Ports freigeschaltet wurden. Ereignisanzeige des Clients bemängelt: die Arbeitsstation kann sich nicht in DNS registrieren RPC-Server nicht verfügbar, sowie DCOM fehler. Die Replication der DCs ist statisch eingerichtet. Mir reichen spontane Ideen. Jedem dem was einfällt woran das liegen könnte darf sich gerne austoben. (Bitte Bitte Bitte bemängelt nicht irgendwelche konzeptionell möglichen Fehler, das bringt nichts, das ganze sieht so aus, wie ich es beschrieben habe und es wird auch niemand mehr an den grundlegenden Dingen etwas ändern, ich schon mal gar nicht) Ich bin insgesamt etwas handlungsunfähig, Ich selbst habe keinen Zugriff auf das DNS oder den DC aber ich kann meinen Kollegen Anregungen bieten. Unsere FW-Künstler schieben es aufs AD-DNS die AD-DNS-Admins auf die FW und so kommen wir nicht weiter. Noch was dazu:nslookup auf die Servernamen löst die IP auf jedoch als nicht autorisierende Server. Vielen Dank im Voraus KitKat Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 7. Februar 2014 Melden Teilen Geschrieben 7. Februar 2014 Bitte einmal ipconfig /all am Client prüfen. Wen fragt der Client als DNS-Server? Ist die Standortkonfiguration im AD korrekt? Zitieren Link zu diesem Kommentar
NeMiX 76 Geschrieben 8. Februar 2014 Melden Teilen Geschrieben 8. Februar 2014 Hi, vielleicht hilft es dir: http://social.technet.microsoft.com/wiki/contents/articles/4494.windows-server-troubleshooting-the-rpc-server-is-unavailable.aspx#Tools_for_Testing_RPC Ganz unten sind die Tools for Testing RPC, vlt. kannst du damit dem Problem auf die Spur kommen. Generell ist der Artikel voll mit Tipps wie/wo man Troubleshooten kann. Ich würde auch mal mit Wireshark schauen wo der Client hin will und o das überhaupt erlaubt ist (Stichwort Sites im AD) Zitieren Link zu diesem Kommentar
KitKat 10 Geschrieben 8. Februar 2014 Autor Melden Teilen Geschrieben 8. Februar 2014 Hi Daniel, Hi NeMiX der Client fragt den immer schon vorhandenen DNS Server (Unix). Trage ich einen der DCs als alternativen DNS ein, kennt mein Client den nicht mehr, keine Auflösung mit nslookup über die IP oder den Namen möglich. Ich kenne die Standortkonfig in unserem AD nicht. Wir haben gestern mit Wireshark die Aufnahme in die Domain sowie die Anmeldung bei geschlossener FW (nur benötigte Ports geöffnet) gesniffert, der Client kennt seinen Server und der Server spricht auch brav mit dem Client. Bei geöffneter FW gab es viel Kommunikation im Highport Bereich, der sonst unterbunden wird. Die Kollegen die die FW betreuen werden keine Massenhighports von den Bundesweiten Clientnetzen zu den AD-Servern freischalten. Der Kollege der meinen Kundenbereich des AD-Betreut, hatte zu Anfang einen Antrag gestellt, aus den Clientnetzen 15.000 Ports freischalten zu lassen. Das ganze wurde auf 150 Ports reduziert. Jetzt sind es noch 100 und es sind immer noch zu viele. Und es bleibt dabei, trotz offener FW keine Anmeldung möglich, es kann also auch nicht zwingend allein an den 100 fehlenden Highports in der FW-Konfig liegen, wobei dies natürlich als eine mögliche Fehlerquelle identifiziert wurde. Danke auch für den Link!! Zitieren Link zu diesem Kommentar
Dunkelmann 96 Geschrieben 8. Februar 2014 Melden Teilen Geschrieben 8. Februar 2014 (bearbeitet) Moin, zunächst sollte die Firewallablteilung sich mal mit RPC Inspection befassen. Es gibt Firewalls, die RPC können und bei denen nicht pauschal alle Ports geöffnet werden müssen. Dabei sollte möglichst darauf geachtet werden, dass die Firewall neben strict RPC auch benutzerdefiniertes RPC unterstützt. Den AD Standort des Clients kannst Du z.bsp. mit 'nltest /dsgetsite' abfragen Stellt der Unix DNS auch die für's AD notwendigen Service Records bereit? http://technet.microsoft.com/en-us/library/bb727055.aspx bearbeitet 8. Februar 2014 von Dunkelmann Zitieren Link zu diesem Kommentar
Daniel -MSFT- 129 Geschrieben 8. Februar 2014 Melden Teilen Geschrieben 8. Februar 2014 (bearbeitet) Schaut Euch mal http://blogs.technet.com/b/luistog/archive/2012/05/08/restricting-ad-replication-traffic-between-dcs-to-only-a-few-ports.aspx an. Zusätzliche Ports sind 53 (DNS), 88 (Kerberos), 123 (NTP), 135 (RPC Endpoint Mapper), 389 (LDAP), 445 (SMB over TCP/IP), weitere, statisch festlegbare High Ports, etc. Bei der Projektgröße empfehle ich Euch dringendst ein AD RAP von Microsoft Consulting Services. Ihr braucht unbedingt einen fähigen AD-Architekten. Das, was Du bisher beschreibst, klingt wie ein 'Setup for failure'! Ich werde an der Stelle aufhören, zu helfen, weil Dir nicht langfristig mit Workarounds geholfen ist. Bei Euch stimmen wohlmöglich schon die Basics nicht. Das kann auch kein Forum abdecken. Viel Erfolg! Daniel bearbeitet 8. Februar 2014 von Daniel -MSFT- Zitieren Link zu diesem Kommentar
Doso 77 Geschrieben 9. Februar 2014 Melden Teilen Geschrieben 9. Februar 2014 Kenne ich nur zu gut die Probleme. Bei uns war es eine ISA Firewall mit aktivem RPC Filter. Windows XP keine Probleme, Win7 Anmeldefehler, obwohl domainjoin klappte und "alle Ports offen" waren. Filter ausgeschaltet, Problem gelöst. Ist bei euch vermutlich nicht ganz so einfach, aber ich vermute stark das auch bei euch irgendwas irgendwo blockiert wird. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.