Jump to content

Emby LDAP plugin error during password change


Recommended Posts

Posted

Hello together,

I connected my Emby instance to my Active Directory for providing User Authentication within Emby.
Everything works fine in this aspect.

But when I try to change my password from within Emby, I always get the error "Insufficient access rights".
In the Emby server logs there is an LdapExemption stating:
2023-06-14 16:18:31.377 Info UserManager: Authentication request for abc has succeeded.
2023-06-14 16:18:31.390 Error Server: Error processing request
  *** Error Report ***
  Version: 4.7.13.0
  Command line: /app/emby/EmbyServer.dll -programdata /config -ffdetect /app/emby/ffdetect -ffmpeg /app/emby/ffmpeg -ffprobe /app/emby/ffprobe -restartexitcode 3
  Operating system: Linux version 4.18.0-477.10.1.el8_8.x86_64 (mockbuild@x86-vm-07.build.eng.bos.redhat.com) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC)) #1 SMP
  Framework: .NET 6.0.14
  OS/Process: x64/x64
  Runtime: app/emby/System.Private.CoreLib.dll
  Processor count: 12
  Data path: /config
  Application path: /app/emby
  Novell.Directory.Ldap.LdapException: LdapException: Insufficient Access Rights (50) Insufficient Access Rights
  LdapException: Server Message: 00002098: SecErr: DSID-031514A0, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
  LdapException: Matched DN:
  Source: LDAP
  TargetSite: Void ChkResultCode()

I tried to investigate this issue and captured the raw network traffic for this.

This showed, that showed the following procedure:
1. Lookup user DN using the BindDN configured in the Emby LDAP plugin
2. Create a new LDAP Bind context for the currently logged in user using the entered "Actual password" for verifying this actual password
3. Terminate this user bind context
4. Try to change the modify the user's password using a new LDAP Bind context for the configured BindDN from the Emby LDAP plugin

In common settings, so it is in my setup, this statically configured BindDN is an unprivileged "LDAP search user" (in former times often an anonymous context was used for that).
Obviously, this search user doesn't have the permission to change other user's passwords.

As you are already creating a "personal LDAP context" for verifying the actual password of the logged in user,
why you are not simply using this authorized context for modifying the user's password ?

From a conceptual point of view with respect to security, this is common practice to have an unprivileged search user and user's tasks are accomplished in an authorized personal LDAP context.

Thanks and have a nice day

Posted

Hi, that's a good point, although it's not that simple. The Emby LDAP plugin doesn't really keep any data. What you're saying makes sense, but would require some reworking, especially when you consider that you could authenticate, and then at some point later change your password after which point the server may or may not have been restarted.

Posted

Hi Luke,

thanks for your reply!
I fully understand the "generic issue" you're describinung.

But I'm concerned especially about the "Password change" dialogue: !
There you have everything you need for "switching the LDAP context to an authorized user context", meaning the user's DN, the user's actual password and the new password.

From the network capture I've seen, that you search the user's DN using the configured BindDN (in my case the underprivileged LDAP search user), then switch the LDAP context to the users's DN for validating the actual password. But then you immediately terminate the user's authenticated LDAP session and switch back and open a new session using the plugin configured BindDN for changing the password.

For my understanding, you just have to invoke the "modifyRequest" for changing the password in the already instantiated users's context instead of the "anonymous" or generic configured plugin LDAP user.

In other words: you just have to use the LDAP context you already have instead of switching back to "anonymous" again ?!

Just as info: I'm not a developer, I work in the area of IT security, so maybe I've misunderstood some developing aspects.

 

Have a nice day

  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...