Kein CIFS Mount mit kurzem Namen
Ein Kunde kann in seiner bei uns gehosteten Umgebung nicht auf ein Share zugreifen, wenn er es nur mit dem kurzen Namen anspricht. Die Fehlermeldung spricht von fehlenden Zugriffsrechten. Mit den langen Namen (angehängter Domain) geht es aber problemlos. Der Fehler ist eine Verkettung unglücklicher Umstände, beteiligte Parteien sind: Der Kunde, ein Kunde des Kunden, Microsoft, Apple und die IETF.
Problem
Greift man auf das Share mit vollem FQDN zu, gibt es keinerlei Probleme:
Und so soll es auch mit einem kurzen Namen sein, denn der Kunde mag nicht immer seine eigene Domain hinschreiben. Insbesondere dann nicht, wenn der Kurzname sonst überall funktioniert.
Probiert man also im File-Exporer per UNC auf das Share zuzugreifen, klappt das allerdings nicht. Stattdessen poppt eine Fehlermeldung auf:
Obwohl der Zugriff nicht funktioniert, ist das Share aber eingebunden, wie net use zeigt. Nur der Zugriff klappt nicht.
Witzigerweise gibt es keinerlei Probleme, wenn man im Explorer den kurzen UNC-Pfad an einen Laufwerksbuchstaben bindet. Das ist bei Laufwerk U: im Bild schön zu sehen.
Die Fehlersuche dieses Phänomens dauerte Wochen:
- Gruppenrichtlinien wurden geprüft
- Changelogs der Updates und Hotfixes intensiv studiert
- Mitschnitte der Netzwerkkommunikation zwischen den beteiligten Servern nebeneinander gelegt (evtl. Paketverlust im Netzwerk?)
- Andere Shares wurden untersucht (keine Probleme dieser Art)
- Das Share bekam andere Aliasnamen (und die Probleme waren weg)
Am Ende kristallisierte sich heraus, daß der Name des Shares das Problem darstellt. Schon die Änderung eines einzigen Zeichens lies den Effekt verschwinden. Was war also so speziell an dem Namen?
Nein, es heißt nicht com oder nul, jedoch gibt es Dateiendungen, die diese drei Buchstaben haben. Hat sich evtl. eine Anwendung für diese Zeichenfolge zu übereifrig registriert?
Lösung
Auf die richtige Spur kamen wir, als wir die Namensauflösung komplett mitschnitten. Denn die Maschine versucht beim Zugriff auf das Share DNS-Anfrage an die Nameserver eines Kunden (vom Kunden) zu schicken. WTF?
Wenn ein Windows auf ein reines UNC Share zugreift, benutzt es intern einen anderen (moderneren) Codepfad. Deswegen kommt es da auch prima mit IPv6 klar.
Dieser moderne Code benutzt auch aktuellere Standards, z.B. RFC 6762. Dort heißt es:
this document allows any computer user to elect to give their computers link-local Multicast DNS host names of the form: "single-dns-label.local."
In this respect the ".local." suffix is treated no differently from any other search domain that might appear in the DNS search list.
Die IETF hat die proprietäre Entwicklung von Apple standardisiert und dabei Fallbacks aufs klassische DNS mit eingebaut, um auch bei Mischumgebungen noch funktionsfähig zu sein. Microsoft hat diesen Standard irgendwann implementiert.
Kurz und gut, der Client hat die Namensauflösung per Multicast DNS versucht und einen .local. Namen konstruiert. Den hat er angefragt und bekam eine unerwartete Antwort:
Unser Kunde hat mit seinen Kunden z.T. Active-Directory-Trusts zwecks Singe-Sign-One auf gemeinsame Ressourcen im Einsatz. Inzwischen wird lieber über ADFS gearbeitet, aber die alten Lösungen für Bestandskunden sind nach wie vor aktiv.
Für den AD-Trust müssen sich die Nameserver der beiden Domains gegenseitig erreichen können. Dies wird hier per Conditional Forwarder gemacht, um Eingriffe in den normalen Namensraum zu vermeiden.
In dem vorliegenden Fall, ist der Kurzname exakt der Name der AD-Domain beim Kunden (um .local erweitert). Deswegen glaubte der DNS-Server, eine Antwort zu haben, und schickte dem Client die entsprechende Delegation.
Infolge dessen fragt der Client dann selbst direkt bei den Nameservern des Kunden an, bekommt als eine Antwort eine IP Adresse, zu der er sein SMB-Paket schickt … Permission denied.
Fazit
Eigentlich müßte der Kunde des Kunden seine AD-Domain umbenennen. Ich habe den Namen extra unkenntlich gemacht, weil er durch seine Größe doch zu leicht zuzuordnen ist.
Bleibt als Alternative: Das Share wird umbenannt.
Merke:
- Benutze niemals die Domain .local für eigene Zonen.
- Benutze niemals einen Namen, der als .local-Domain irgendwie erreichbar sein könnte.