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:
