Integration with Active Directory

[manodory 0]

Hi, I'm trying to integrate Emby with Active directory with no success. 

I'm using Windows Server 2022 as my domain controller. 

Tried with or without ssl (port 443/636). When using SSL I use a certificate that comes from the local CA. 

Here are my settings:

LDAP
LDAP server address:
192.168.1.5
LDAP server Port number:
636

Enable SSL: Yes
SSL certificate thumbprint (SHA1):
2c5c2b1d5eec8fc18e4969b2f6d319e76fe3a5ee
Bind DN:
CN=emby,OU=Service Users,OU=Manos,DC=manos,DC=home
Bind credentials:
<password>
User search base:
DC=MANOS,DC=HOME
User search filter:
(&(objectClass=person)(objectClass=user))
 

[Luke 37057]

Hi, what exactly is the issue?

[manodory 0]

I just can't login with an AD user. It won't work, saying I have a bad username and password. Of course the credentials are correct. I couldn;t find a single article explaining how to integrate this. Tried eve to buy a subscription but it didn't seem to have any difference. 

Edited April 29, 2022 by manodory

[Luke 37057]

OK please attach the emby server log from the time of the attempt. thanks.

[manodory 0]

Tried now, (07:31,07:33). Log attached. Thank you. 

embyserver.txt

[Carlo 4330]

Hi manodory,

Ill throw in my 2 cents.  A lot of software meant for use in networking has standard and advanced features. Then there are different levels of these advanced features with some of them standard or easier to use and some very advanced. Even for these very advanced features there are levels of complexity.  Kind of following that thought LDAP is going to fall into the top level/most difficulty to understand/deploy type of feature you will typically come across in networking. This is in general and not specific to Emby Server. The reason is due to flexibility of LDAP and specific configurations.  LDAP is something you just have to learn and understand to make the most of. 

I don't personally use this plugin as I only share my server with a handful of family and friends but I've used LDAP professionally both in management and development on many platforms so I'm very familiar with LDAP in general.

It would be difficult to do a tutorial for Emby's LDAP plugin since the setup is going to be specific to the Directory Server you're using as well as the specific configuration being used.  The beauty of LDAP however is it's flexibility in setup for both the server and client side. Different servers have "unique" requirements to properly work.  For example pure authentication may only require a username and password (user, password) or might need domains (user@domain, password) or might need full scoped authentication (user@domain, \\domain\password) and no one can tell you the format you need unless they have access to the server and understand the requirements of the backend server.

If you're going to use profiles on top of authentication that too will give different results depending on backend server.  Some for example will fail an authentication request (even if correct) if the record does not contain all required information. 

env.put(Context.SECURITY_PRINCIPAL, "user");
env.put(Context.SECURITY_PRINCIPAL, "user@domain.com");
env.put(Context.SECURITY_PRINCIPAL, "CN=user,OU=one,OU=two,DC=domain,DC=com");

The above is from code not related to Emby Server but shows 3 ways sending username and the qualifications.  The last one for example will fail if any of the data is missing even if unrelated to the pure authentication.

Typically you try/test a configuration then on failure lookup the results you get back. I see from your log this example:
    Novell.Directory.Ldap.LdapException: LdapException: Invalid Credentials (49) Invalid Credentials
    LdapException: Server Message: 80090308: LdapErr: DSID-0C090434, comment: AcceptSecurityContext error, data 52e, v4f7c 

Each of the bold items is a message that you would need to look up if not familiar with already. I know many of these codes without lookup such as the 49, 80090308, data 52e which is saying the bad credentials. 

I said earlier "LDAP is something you just have to learn and understand to make the most of." which is true. It's kind of like learning to ride a bike.  You can watch videos, watch others, read about it but will never be able to immediately apply it as learning to ride a bike take persistence, time & some trial and error, not to mention balance.

While we don't need to worry about balance we do need solid foundation to start with so you need to understanding what things like CN, OU, DC are as well as how you use them and when you would use them. Like learning to ride a bike it's going to take practice and trial and error.  One of the best suggestions I would give you is to acquire a really good client tool you can use to try different syntax and use to test with against your LDAP server (AD in your case).  Assuming you're using Windows I'd suggest taking a look at these:
https://nettools.net/
https://community.bmc.com/s/article/How-to-use-LDP-exe-to-test-Active-Directory-AD-or-LDAP-connection-and-binding
http://www.ldapadmin.org/
You could also try the free or trial software from:
https://www.ldapsoft.com/

What this will do for you is develop the patterns and syntax you need to use for your AD server using LDAP that give proper results.  Once you've got that it's easy to transfer that to any LDAP client such as Emby Server's LDAP plugin.  That will get you 95% of the way there.  If it doesn't work in Emby just Google the error message and it's likely to be something trivial or Emby Specific (happens) but easy to adjust.

[Carlo 4330]

I wanted to split the message before it got to long and this got lost.

I can probably help you more with some specific info.
Can you give me an overview of what you're actually trying to do with the LDAP plugin?

Do you have any previous LDAP experience?  Ever used it for integration with other apps or protocols such as VPN, RADIUS, mail, etc?

Is this for a home setup?
Do you have a rough idea of the number of users you want/need to support via LDAP?

What other integrations do you have Active Directory?
How many domain controllers are you currently running?
How many forests and domains do you have setup in AD?  If multiple, do you need to support that via Emby as well or just a single domain?

That info will help,
Carlo

[manodory 0]

Hi, 

I'm trying to sync Emby server with Active Directory so that my users can login to it without me having to create them another username and password for the application. 

I do have previous LDAP experience. I'm an MCITP microsoft certified engineer. I did managed to integrate LDAP with lots of other solutions, including Pulse VPN and Fortigate, as well as Cisco VPN solutions. 

This is my home setup.

Need to support about 15 users. 

I have two domain controllers. One forest. One domain.

Got the whole thing as it should be configured, and still, Emby won't connect with AD.  

I do have experience with

[manodory 0]

So, any news regarding this? 

In general, I think Microsoft Active Directory is the most common LDAP solution today. 

I can see that the plugin is aimed towards Novell Directory server, which is known to be obselete. 

The attribute for the username in Microsoft AD is:

userPrincipalName - for user@domain.com

or 

sAMAccountName - for just the user. 

 

I've tried to put them both in the User search filter text box. Didnt work...

Is there any known good configuration for Emby server with AD? I really want to use it but this is a real dealbreaker for me. 

 

Thanks

 

Edited May 3, 2022 by manodory

[Luke 37057]

5 hours ago, manodory said:

So, any news regarding this? 

In general, I think Microsoft Active Directory is the most common LDAP solution today. 

I can see that the plugin is aimed towards Novell Directory server, which is known to be obselete. 

The attribute for the username in Microsoft AD is:

userPrincipalName - for user@domain.com

or 

sAMAccountName - for just the user. 

 

I've tried to put them both in the User search filter text box. Didnt work...

Is there any known good configuration for Emby server with AD? I really want to use it but this is a real dealbreaker for me. 

 

Thanks

 

Have you taken a look at this topic?

We have a lot of users here running active directory.