PortQRY: Ein Hilfsmittel zum AD-Troubleshooting

Dieser Artikel erschien zuerst auf dem Blog Consulting-Lounge.de.

In verteilten Active Directory-Umgebungen mit mehreren Standorten tauchen regelmäßig immer wieder die folgenden “Klassiker” unter den gemeldeten Problemen auf:

• Replikationsstörungen zwischen den Standorten
• Probleme bei standortübergreifender Namensauflösung (DNS, sowie NetBIOS (WINS))
• Probleme bei der Anmeldung
• etc.

Schnell ist man geneigt, in den Eventlogs der beteitilgten Server zu suchen bzw. bekannte Bordmittel wie “DCDiag”, “NetDiag” oder “Replmon” zu bemühen. Oft wird man dort auch fündig, gerade wenn es um die Konnektivität zwischen Standorten oder DCs in verschiedenen Subnetzen geht. Woher diese Verbindungsprobleme letztendlich rühren, verraten die Ausgaben dieser Tools aber oft nicht, oder nur “höchst verklausuliert”.

Der Verdacht liegt meist nahe, dass die Ursachen im Bereich Netzwerk oder Firewall-Regeln zu suchen sind. Auf Nachfrage in den entsprechenden Abteilungen heißt es dann oft sinngemäß: “Nein, an der Firewall haben wir nichts geblockt, LDAP / AD sind freigegeben” oder so ähnlich. Ich selbst z.B. war in solchen Situationen als “Windows-Mensch” oft in der Beweispflicht.

Hier kommt ein sehr nützliches (wenn auch altes) Tool von Microsoft ins Spiel: PortQRY. Es handelt sich hierbei um einen simplen PortScanner, welcher allerdings gewisse “Scan-Templates” für bestimmte Dienste, wie z.B. “Domains and Trusts” mitbringt.

Da zu einer erfolgreichen Kommunikation im AD bzw. zwischen DCs weitaus mehr nötig ist als “LDAP” und man die benötigten TCP- bzw. UDP-Ports ggf. nicht immer im Kopf hat, bietet das Tool eine komfortable schnelle Möglichkeit, die Protokoll-Endpunkte zwischen zwei DC´s auf “Durchlässigkeit” zu prüfen. Ursprünglich handelt sich um ein reines Kommandozeilen-Tool, es existiert allerdings bereits seit langem auch eine GUI dafür, welche keiner Installation bedarf und hier heruntergeladen werden kann:

https://www.microsoft.com/en-us/download/details.aspx?id=24009​

Sobald das Tool (z.B. auf einem DC) gestartet ist, kann man sich wie in folgendem Beispiel einmal die vorgefertigten “Services” anschauen, welche in XML-Beschreibungen definiert sind und zeigen welche Ports dabei gescannt werden:

Dieses Bild zeigt den Auszug eines “Beispiel-Output” eines Query von DC zu DC zwischen zwei Standorten:

Man muss beim Auswerten des Outputs natürlich im Hinterkopf behalten, dass es sich bei UDP um ein “verbindungsloses” Protokoll handelt. Die Ergebnisse müssen für UDP nicht aussagekräftig sein. Einem “FILTERED” oder “NOT LISTENING” für TCP basierte Queries sollte man allerdings auf den Grund gehen, denn hier könnte eine Firewall den Zugriff verhindern, oder es gibt mit dem Dienst auf dem Zielsystem ein anderweitiges Problem.

Zur Interpretation des Output siehe auch:

https://technet.microsoft.com/en-us/library/cc759580%28v=ws.10%29.aspx​