Richtig gebunden:
Emby im Active Directory

Der Medienserver Emby lässt sich ohne großen Aufwand an ein LDAP anbinden. Doch was ist bei der Verwendung von Active Directory zu beachten?

Ich bin ein ziemlicher Fan von Emby. Einmal eingerichtet, stellt der Emby Server eine recht unkomplizierte und elegante Möglichkeit zur Verfügung seine privaten Medien – wie z.B. Musikdateien – in Bibliotheken zu organisieren und auf nahezubeliebigen Geräten wiederzugeben. Mithilfe verschiedener Plugins lassen sich zudem externe Quellen, wie z.B. IP TV, einbinden und der Funktionsumfang erweitern.

Eines dieser Plugins erlaubt es auch den Medienserver an das lokale Active Directory und damit auch das zentrale Nutzermanagement anzubinden. Folgt man der zugehörigen Anleitung, ist die Installation selbst schnell erledigt – leider ist die Konfiguration nicht ganz so intuitiv wie ich es erwartet hätte. Obwohl nur aus einer Seite mit ein paar Textfeldern bestehend, hat es mich einigen Aufwand gekostet die richtigen Konfigurationsparameter zu setzen:

Während LDAP server url und LDAP server Port number im Grunde selbsterklärend sind, muss ich zugeben, dass ich bereits für Bind DN auf einen Thread aus dem Community-Forum zurückgreifen musste. Es ist zwar nicht sonderlich überraschend, Authentifizierungsdaten für eine LDAP-Abfrage bereitstellen zu müssen und ich behaupte einfach mal, dass ich kein absoluter Newbe bei der Integration mit LDAP bin, aber den Distinguished Name komplett angeben zu müssen, kommt bei den meisten Anwendungen nicht so häfig vor. Nchdem man diesen dann jedoch ausgefüllt und noch das zugehörige Passwort in Bind credentials hinterlegt hat, kommt der Konfigurationsparameter, der mich einige Stunden an Suche und Nerven gekostet hat: User search filter.

Verwendet man ein Windows Active Directory als Backend und belässt gleichzeitig den standardmäßigen Filter (uid={0}), kann man noch so verzweifelt versuchen sich mit einem AD-Nuterkonto anzumelden, es wird immer die Fehlermeldung auftauchen „Nutzerdaten falsch; Anmeldung verweigert“. Im Emby Server Log sieht das Problem in etwa so oder so ähnlich aus:

Die Ursache: Relativ häufig ist das uid-Attribut standardmäßig nicht mit dem Nutzernamen belegt, so dass der Versuch den Nutzer bei der Anmeldung zu intentifizieren ins Leere läuft. Die Lösung: Verwendung des sAMAccountName-Attributes mit dem Filter (sAMAccountName={0}). Da dieses Attribut in einem AD als einmaliger Schlüssel verwendet wird, ist er immer mit dem Nutzernamen belegt. Eine vollständige Konfiguration würde dann wie folgt aussehen:

Wie war das gleich nochmal?
Passwortschutz aus Word-Dokumenten entfernen

Die Word-Datei ist passwortgeschützt, aber niemand erinnert sich an das Passwrot? Kein Problem!

Ich bin mir ziemlich sicher, dass jeder von uns bereits schon einmal in diesem oder einem ähnlichen Dilemma war: Sie versuchen auf ein geschütztes Dokument oder einen passwortverschlüsselten Datensatz zuzugreifen, den Sie seit Jahren nicht mehr benötigt haben – und Sie haben das Kennwort vergessen. So aktuell mir geschehen mit einem vor mehr als vier Jahren für einen Kunden erstellen und gegen (versehentliche) Bearbeitung geschützten Word-Formular, das nun doch bearbeitet werden soll.

Trotz intensivster Suche im Passwortmanager und/ oder diversen Readme-Dateien lässt sich natürlich genau dieses Kennwort nicht finden. Was tun?

Eine Schnellsuche beim Internetsuchdienst meines Vertrauens rät:

  • Mittels STRG+A den kompletten Inhalt aus dem Dokument markieren, kopieren und in ein neues Dokument einfügen – funktioniert zumindest in meiner Word-Version (Office365, Januar 2020) nicht
  • Die Datei als .odt oder .rtf neu abspeichern und anschließend öffnen – erzeugt zwar eine bearbeitbare Kopie, entfernt aber auch die Formularfeldfunktionen; also nur eine Notlösung

Ein Artikel aus dem Jahr 2012 hat mich dann aber doch auf die richtige Lösung gebracht:

Im Grunde ist eine .docx-Datei ein ZIP-Container, der u.a. verschiedene XML-Dateien mit dem Dokumententext und den -Eigenschaften beinhaltet. Ändert man die Dateiendung in .zip, lassen sich die einzelnen Parts einer .docx-Datei mithilfe eines üblichen Archivmanager durchsuchen und bearbeiten.

Zwar hat sich inzwischen das Dateiformat gegenüber dem Artikel aus dem Jahr 2012 verändert, innerhalb des word-Verzeichnisses gibt es aber eine Datei namens settings.xml, in der ein XML-Knoten namens w:documentProtection zu finden ist.

Löscht man nun diesen gesamten Knoten, speichert die settings.xml und ändert anschließend die Dateierweiterung des Dokuments wieder in .docx um, erhält man eine ungeschützte und passwortfreie Datei, die sich nicht nur problemlos in Word öffnen lässt, sondern auch noch alle (Formular-)Features aufweist.