Skips Password Entry

[earratia14 11]

Apologies if this has been raised before.

 

I found that I can login to the Emby app in Roku without entering a password following these steps:

* Make sure you are first signed out of Emby on the Roku app (select the sign out option).

Once signed out you can close the Emby app, or continue to the next step directly, or even exit Emby and reboot your Roku, the result will be the same.

* On the Emby login screen select one of your users. You will get the password prompt scree.

* Click on the big big back arrow at the top of your remote without actually entering the pin or the password.

 

You will now be logged on to that accout and viewing all of their content.

 

Thus far I have only tried this with LDAP authenticated local accounts.

Next I'll try with Emby Connect accounts.

[Luke 36997]

@@speechles

[speechles 1917]

Make sure you have "Remember User" turned OFF in the settings and try. That might be the entire reason why you can do it. Report back and I can take a look at what is happening.

Edited December 16, 2018 by speechles

[ebr 14902]

Next I'll try with Emby Connect accounts.

 

Connect won't have that login process.

 

I cannot reproduce this.  I get an "Invalid password" dialog.

[Luke 36997]

Does the user you tested with have a password?

[earratia14 11]

Hi, thanks for the prompt replies.

 

Make sure you have "Remember User" turned OFF in the settings and try. That might be the entire reason why you can do it. Report back and I can take a look at what is happening.

 

Yes, "Remember User" is turned OFF.

I verified by logging in to the Emby app using the admin account (Emby Connect account), pressing * on the roku remote and selecting "Settings", I then scrolled down to the Remember User option. It is turned OFF.

 

 

Does the user you tested with have a password?

 

Yes, all users have password (from the LDAP server) and also Easy PIN Code with the "Enable in-network sign in with my easy pin code" option enabled.

 

Other than the Admin user (linked to the Emby Connect account, green cloud appears on the user card in the server Dashboard), all other users have the "LDAP" Authentication provider selected.

 

This afternoon I also tested whether I can logon to the server using the Admin account without entering a its password... turns out I can using both the Emby Roku client and the Web Client.

 

Roku:

The Admin account does not appear on the user selection listing (I have selected the option to hide it). So I select Manual Login.

Enter the Admin userid on the first prompt, continue.

Leave the password blank and simply press on the big back arrow on the Roku remote.... I'm in as the administrator.

 

PC:

Make sure I sign out of any sessions.

Clear all cache (select Everything option). Close browser for good measure.

Open browser again and enter the server's address.

Click on Manual Login.

Enter Admin on the User field and leave Password blank. Click on "Sign In". I'm in as the admin.

 

Perhaps is not an issue with the Roku Emby app but rather with my server?

[Luke 36997]

Did you enable the easy pin code sign in but not actually assign any pin code? Because that will result in being able to login without a password.

[Happy2Play 8239]

That is what it sounds like to me.  I can't reproduce with steps listed above.

Enable in-network sign in with my easy pin code
If enabled, you'll be able to use your easy pin code to sign in to Emby apps from inside your home network. Your regular password will only be needed away from home. If the pin code is left blank, you won't need a password within your home network.

Edited December 17, 2018 by Happy2Play

[earratia14 11]

I checked this morning before leaving for work.

 

All LDAP authenticated users have actual easy pin codes entered.

The only other user is the administrator (Emby Connect) and there is no option for this user to have an easy pin code.

 

I was kind of doubting that one of those LDAP users had a pin entered, so I actually reset it and entered a new one this morning. Then verified the other two (there's three total at this time). They all have pins entered.

Tested again using Emby on a Roku 3 and same behavior. I chose the user I had just reset and entered a new pin for, on the password prompt screen I pressed the back arrow on the remote and I was logged on as that user.

 

Couple of additional items: one is a reminder of something I mentioned before and the other is new info on this matter.

1) Reminder: I can logon as the admin account (Emby Connect) without entering a password both with Roku and with the Web client. So this may be a server issue and not necessarily a problem with the Roku app.

 

2) New info: After the LDAP users logged on for the first time their profiles were created and I assigned those easy pins.

However, I left the 'Current Password' and New Password' fields blank. I have not entered anything on those three fields (including the new password confirmation) ever.

My expectation is that since they are LDAP authenticated, that I would not need to enter anything here. But I thought I'd mention it just in case.

[earratia14 11]

Some new information.

 

When I created the administrator account, I simply entered my Emby Connect userid/password and made sure the "Allow this user to manage the server" option was selected.

 

Earlier today, I noticed that under the "Password" tab (Server Dashboard > Users > Administrator User card > Password tab) the only fields available were "New password" and "New password confirm"... as if it was not aware that the user already has a password.

 

So I went ahead and entered a new password (different from the one on the Emby cloud).

Well, that fixed the issue where I was able to logon as the administrator user without a password. Except now it is letting me logon with either the cloud password or the new password I had assigned on the server Dashboard.

 

This is telling me that the Emby server is keeping a local record of the User, which is in and of itself fine. The problem is that even though it is supposed to know it is Cloud authenticated it will still accept a local password.

If no local password is supplied, then the user will be able to sign-on with a password (the cloud password) or without one (because there isn't one locally).

If there is a local password, then the user will be able to sign-on with either password.

 

I think the same thing is happening with the LDAP authenticated accounts. For them, the LDAP server is the equivalent to the Emby Cloud authentication server of the Emby Connect accounts.

 

This is either some sort of misconfiguration on my server or an actual bug in the Emby server software.

 

I used "emby-server-deb_3.5.3.0_amd64.deb" to install the Ubuntu server and "embyserver-win-x64-3.6.0.78.7z" to install a separate server on a Windows 2016 machine.

Both of the servers are showing the same behavior.

[ebr 14902]

Okay, so what happened was you had actually created your admin user with no password.  The attaching to a cloud account is a totally optional procedure and does not restrict the user to only being used that way.  So the fact it will accept either password is by design and for convenience.

[earratia14 11]

Yes, I completely agree on the Admin side of the issue. If it is by design then perhaps making it more clear on the documentation front will help.

 

On the other side of this problem I still have the LDAP users being able to logon without entering a password or an easy pin code.

[Luke 36997]

On the other side of this problem I still have the LDAP users being able to logon without entering a password or an easy pin code.

 

Can you please attach the emby server log from when this happened? thanks.

[earratia14 11]

Yes, of course.

 

I'll do it tonight when I get home from work. Thanks!!

[Luke 36997]

Thanks.

[earratia14 11]

Attached is the embyserver.txt log file.

 

Before extracting the file I did this:

1) Woke my Roku and started Emby

2) Selected one of my LDAP users and signed on without password or pin

3) Exited the Emby app making sure to select the option "Sign Out" first and then Exit Emby

4) Restarted the Roku

5) Restarted the Emby server (OS and all)

6) Once everything was back online I again entered the Roku Emby app and signed on with the LDAP user without entering a password or pin.

 

Interestingly, it looks like it is reissuing an access token. However, I made sure to sign out first and I had already verified that the Remember User option was unchecked on the Roku Emby app.

 

Thanks.

embyserver.txt

[earratia14 11]

I tried a few more things:

* Uninstalled / Re-installed the Emby application from the Roku

* Cleared all user data (from within the Emby app, it is one of the options)

* Sign-in to a different LDAP user (again, not using a password or pin), sign-out and then re-sign in to the first user

 

These are portions of the log:

 

2018-12-19 23:30:15.463 Info HttpServer: HTTP POST http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json. UserAgent: Roku/DVP-9.0 (299.00E04084A)

2018-12-19 23:30:15.464 Info UserManager: Authentication request for Enrique has succeeded.

2018-12-19 23:30:15.465 Info SessionManager: Reissuing access token: eccbf617afc0462f98888224163deda5

2018-12-19 23:30:15.466 Info HttpServer: HTTP Response 200 to 192.168.2.48. Time: 3ms. http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json

 

**Up until this point, the server had been re-issuing the same eccbf6... token**

 

 

2018-12-19 23:30:28.970 Info HttpServer: HTTP POST http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json. UserAgent: Roku/DVP-9.0 (299.00E04084A)

2018-12-19 23:30:28.971 Info UserManager: Authentication request for Julia has succeeded.

2018-12-19 23:30:28.971 Info SessionManager: Logging out access token eccbf617afc0462f98888224163deda5

2018-12-19 23:30:28.973 Info SessionManager: Creating new access token for user cab1c02f-6ee8-43fb-b94d-59e668716473

2018-12-19 23:30:28.975 Info HttpServer: HTTP Response 200 to 192.168.2.48. Time: 5ms. http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json

 

**First logon by second LDAP user, note it is logging out the eccbf6 token and creating a new one**

 

 

2018-12-19 23:32:31.779 Info HttpServer: HTTP POST http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json. UserAgent: Roku/DVP-9.0 (299.00E04084A)

2018-12-19 23:32:31.781 Info UserManager: Authentication request for Enrique has succeeded.

2018-12-19 23:32:31.781 Info SessionManager: Logging out access token 5c5543ac76a8471893cc01791b13b543

2018-12-19 23:32:31.782 Info SessionManager: Creating new access token for user 5eaf229a-afac-4def-a969-c3bbddd9c519

2018-12-19 23:32:31.785 Info HttpServer: HTTP Response 200 to 192.168.2.48. Time: 5ms. http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json

 

**I had logged of from second LDAP usser and logged on as the original. I don't know why it is logging out access token 5c5543... I ran grep on the logs directory and it only returned the line you see above**

 

2018-12-19 23:32:50.676 Info HttpServer: HTTP POST http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json. UserAgent: Roku/DVP-9.0 (299.00E04084A)

2018-12-19 23:32:50.676 Info UserManager: Authentication request for Julia has succeeded.

2018-12-19 23:32:50.677 Info SessionManager: Logging out access token 13aec1eb1e3e467aa3ff44068964572c

2018-12-19 23:32:50.681 Info SessionManager: Creating new access token for user cab1c02f-6ee8-43fb-b94d-59e668716473

2018-12-19 23:32:50.683 Info HttpServer: HTTP Response 200 to 192.168.2.48. Time: 7ms. http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json

 

**Signed out of the first LDAP user and again signed on with the second one. Again, ran a grep on the folder looking for the 13aec1 token and it only found the line you see above.

Also, note that the created a new access token that appears to be the same as the one it had already created 2 or 3 minutes ago**

 

 

2018-12-19 23:33:02.543 Info HttpServer: HTTP POST http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json. UserAgent: Roku/DVP-9.0 (299.00E04084A)

2018-12-19 23:33:02.544 Info UserManager: Authentication request for Enrique has succeeded.

2018-12-19 23:33:02.544 Info SessionManager: Logging out access token 32a351e859fb484ea26e8463298a58d9

2018-12-19 23:33:02.546 Info SessionManager: Creating new access token for user 5eaf229a-afac-4def-a969-c3bbddd9c519

2018-12-19 23:33:02.547 Info HttpServer: HTTP Response 200 to 192.168.2.48. Time: 5ms. http://192.168.2.21:8096/emby/Users/AuthenticateByName?format=json

 

**Final sign out/in of the evening. Signed out of the second LDAP user and signed in with the first. Results look a lot like the previous ones. I don't know where the token 32a35 came from, grep comes back with only the line above.

And again it seems to create the same token (5eaf2) it had just created a few minutes ago**

 

 

Thanks!

[Luke 36997]

This would seem to suggest that you've enabled the pin code sign in for these users, but their pin code is blank. Can you double check that? Thanks.

[earratia14 11]

 

I'm pretty sure it isn't because it signs me on if I enter the pin. And it blocks me if the pin is incorrect.

 

But I'll check again.

[earratia14 11]

OK, I just double checked and all the PIN codes were entered (six stars appear on the Easy pin code text box).

Afterward, I ran the following steps and subsequent tests in the order I show. Sorry, this is going to get a bit lengthy. The attached log "embyserver.txt" should mirror the steps I describe here.

 

1) Shut down the Emby server (software only) completely. Made sure it was dead from the command line

2) Using the command line re-started the server

3) Opened a browser and when to the Server Dashboard as the admin user (non-ldap)

4) Clicked on the Reset easy pin code button under the Password tab of each LDAP user card

5) Once all pins were reset, I went back to each LDAP user Password tab and entered a new Easy pin code. See attached "BeforeSave.png" and "AfterSave.png" screenshots. Screenshot does not show actual pin I used 

6) Went to Roku and un-installed the Emby application

7) Rebooted Roku

8) Re-installed Emby application

9) Launched Emby application

10) Once I had the user list, I selected the first LDAP user and then clicked on the big back arrow button on the remote when the password screen came up.

Result: I was logged in as User 1

11) Clicked * on remote and selected "Sign Out"

12) Selected second LDAP user and then clicked on the big back arrow button on the remote when the password screen came up

Result: I was logged in as User 2

13) Clicked * on remote and selected "Sign Out"

14) Repeated steps 10 through 13 with same results. So:

    14.1) Selected the first LDAP user and then clicked on the big back arrow button on the remote when the password screen came up.

    Result: I was logged in as User 1

    14.2) Clicked * on remote and selected "Sign Out"

    14.3) Selected second LDAP user and then clicked on the big back arrow button on the remote when the password screen came up

    Result: I was logged in as User 2

    14.4) Clicked * on remote and selected "Sign Out"

 

15) Again selected LDAP User 1 but this time I entered the Easy Pin Code on the password screen

Result: I was logged in as User 1

16) Clicked * on the remote an selected "Sign Out"

17) Selected LDAP user 2 and again I entered its Easy Pin Code on the password screen

Result: I was logged in as User 2

18) Clicked * on the remote and selected "Sign Out"

19) Selected LDAP User 1 and this time I did not enter the pin or the ldap password, I simply clicked on the big back arrow button

Result: I was logged in as User 1

20) Clicked * on the remote and selected "Sign Out"

21) Selected LDAP User 2 and this time I did not enter the pin or the ldap password, I simply clicked on the big back arrow button

Result: I was logged in as User 2

22) Clicked the big back button and selected "Sign Out" from the pop-up window

 

Final test:

23) Selected LDAP User 2 and entered a bad pin on the password screen.

Result: I was denied access

24) Again Selected LDAP User 2 and clicked on the big back arrow on the remote when the password screen came up

Result: I was logged in as User 2

 

embyserver.txt

[Luke 36997]

@@speechles are you able to reproduce?

[speechles 1917]

@@Luke On users assigned a password this gives the "invalid password" prompt. Emby connect requires PIN or you don't progress past the please enter pin screen and visit emby.media page. I cannot test LDAP as I have no idea what that is and I do not want to break my existing network.

[Happy2Play 8239]

Is the Roku the only client that this behavior is seen on?  As it appears to be impossible to reproduce without the LDAP plugin.

[earratia14 11]

@Happy2Play: yes, it is the only client I've seen this behavior on.

I've also tested on the web client (using chrome), on Android 8, and on a Fire 10 HD tablet. It is only on Roku that I see this.

 

I'm using version 1.0.25.0 of the LDAP plugin by @@Luke.

 

On the back-end I have a Windows 2016 Server machine as the Active Directory / Domain controller.

[earratia14 11]

So the problem seems to be with the LDAP plugin and/or with the way it creates accounts in the Emby server. I say this because I found a workaround which hints at this being the problem.

 

I was wondering what would happen if I changed the authentication method of the LDAP users to Default.

Would the Password tab look:

a) Like before, meaning three text boxes for password (current, new, confirm new), and a filled in easy pin code.

or

Like if this was a brand new user for whom a password had not been set.

 

The answer was 'b'. It makes sense since it is using the LDAP server for password authentication, so it doesn't need to store a local password.

 

Alright, at this point I'm thinking: what happens if I enter a new password (different from the LDAP password). It should behave like if it had always been a local user, right? Yes, it does. I enter a new password and, interestingly, after I save the new  password the easy pin box appears and it is already populated. Again, it makes sense because the easy PIN code is local to Emby.

 

I then go to the Roku and try to access the account without entering a ping or a password and I'm denied access (at it should). I then try again but this time I enter the local password and it lets me in. Next, I sign-out and the log back in using the easy pin, it logs me on fine. For final confirmation I again try to logon without entering the password or a pin, it denies me access. Awesome.

 

We are on the right track. Now, what happens if I set it back to LDAP? To make a long story short (*too late*), after I switch it back to LDAP, the Emby Roku client denies me access if I try to sign-on without a password. And, it will allow me to log-on if I enter either the PIN, the LDAP password, or the local password.

In a nutshell, that's the work around.

 

@@Luke, @speechless: it is obvious that when the LDAP plugin is used, and users are added when they logon to Emby for the first time, the user's local record gets created and it doesn't have a local password. This in and of itself is not a problem. I would expect it to work like this.

However, the issue is then with the authentication mechanism and how the Emby Roku client interacts with it. I'm thinking it is possibly one of these two scenarios:

 

1) When an authentication call is made, the Emby server's authenticate user routine first tries to reach out the LDAP server, if the password doesn't match it then looks at its local database to see if the password matches what is stored there.

So, if there's no password provided to the authenticate user routine, in all likelihood skips LDAP and goes straight to its own database, since there is no password stored it tells the Roku client to let the user in.

 

or

 

2) The Emby Roku client makes two calls to the server's authenticate user routine. If a password is provided, it makes an initial call to authenticate with LDAP, if that fails it makes a second call to authenticate against the local database.

If no password is provided, it makes just one call to authenticate against the local database.

 

Of course I don't know how all of this is coded behind the scenes. These two possibilities are based on my observations and also what I read from the logs. I'm thinking one of them might not be too far off the mark.

 

Hopefully this will assist you to locate the bug and fix it. Thanks!