Unable to log into Admin portal using admin credentials on brand new installation

[maccamb]

Hello,

I am new to Keycloak and am not yet fully familiar with its details.

I have been able to successfully install, start and log into the Admin console using a Ubuntu VM and containers for keycloak and mariadb.

However I am unable to log in to the Admin console using the provisioned admin credentials if I repeat the setup on my Synology NAS that runs its own nginx web server. (And I have been unsuccessful in locating any leads to debug this issue, so I am humbly seeking help here.)

My experience is as follows:

• I have installed Keycloak in a container and it successfully connects to a mariadb server in another container.
• Keycloak is started in development mode.
• I can successfully load the Admin console login page.
• However when I enter the admin credentials I receive an error message: We are sorry... Cookie not found. Please make sure cookies are enabled in your browser.
• The URL for this page is: http://mymachine.local:8082/realms/master/login-actions/authenticate?session_code=HaanjqIjp09Pc5uEtJzjaOMkch3toZDpnkIslV7cutM&execution=6ef32364-3ee2-4ecd-b9ce-7b5993df89b7&client_id=security-admin-console&tab_id=3UxWLRvp8Yw
• (8082 is the exposed port)
• Keycloak logs reveal: WARN [org.keycloak.events] (executor-thread-11) type="LOGIN_ERROR", realmId="f0ca17aa-b545-427c-af1a-c8ba1d544863", clientId="null", userId="null", ipAddress="172.19.0.1", error="cookie_not_found"
• (172.19.0.1 is the container's IP address.)

Since (1) the error does not occur on my VM and I am able to successfully login using admin credentials, and (2) the only difference between the two setups that I can think of is the nginx web server, I suspect that my keycloak setup on the NAS may deficient, specifically wrt reverse-proxy.

I would greatly appreciate any guidance on this matter.

Many thanks!

[codespearhead]

If you're running Keycloak behind a reverse proxy, you have to configure it accordingly.

[maccamb]

Many thanks for your response! I applied KC_PROXY_HEADERS: forwarded to the compose file but no luck.

I am also curious to understand if realmId="f0ca17aa-b545-427c-af1a-c8ba1d544863" is a hint?

Should the master realm be seen as realmId=master or a key for the realm? If the former is true then what could be the reason I am getting an incorrect realm?

[codespearhead]

No, realms have a name and an id.

[darius-m]

Make sure Keycloak has the hostname, port and path configured correctly. Check for errors in the network tab and the stored cookies in the browser's developer tools. There should be no errors in the network tab, and cookies set for the mymachine.local:8082 domain, with the /realms/master path.

[darius-m]

Considering you are exposing the service on port 8082 (which differs from the default 8080 / 8443), you probably need to set the hostname-url parameter - https://www.keycloak.org/server/reverseproxy#_relevant_options

[maccamb]

Thanks so much for your help!

So...

• I am using HTTP as I am still in the development and testing phase.
• I run keycloak in a container and remap the default port: so the compose file has: 8081:8080 i.e. default in the container maps to 8081 outside.
• My NAS's web setup (Synology Web Station) then requires me to setup the access portal and since I dont have a domain yet I am simply mapping the port.
• So in the end the ports go: clients accesses 8030; web server translates that to 8081 which is mapped to the default port in the keycloak container.
• I know that the port mapping works as I can access the Admin Console.

So my guess is that the issue may be related to hostname- parameters.

I continued exploring and found the following page: https://www.keycloak.org/server/hostname

It has 2 sections that I think may be relevant - see attached screenshot below - and am considering the following:
--hostname=mymachine.local --hostname-strict-backchannel=true --hostname-url=https://mymachine.local:8030

I am going to try this and will report results. But I would also appreciate any guidance based on the above.

Many thanks!

[codespearhead]

You're passing --hostname-url=https://mymachine.local:8030, but shouldn't it be --hostname-url=http://mymachine.local:8030? Because you don't seem to be using HTTPS.

[maccamb]

I mis-typed in my post - I had set it up correctly with http.
(Nice catch though!)

[codespearhead]

Are you able to create a minimal reproducible example with Docker compose?

From what you've shown --hostname-url should have worked.

[maccamb]

Yes in fact the containers are created from a compose file included below. Very straight-forward.
The Synology NAS handles nginx itself (via a package called Web Station) - I can try to unearth the web configuration if there could be nginx config issues.

version: '3.1'

name: mymachine-basic-services

services:

  mymachine_db:
    image: mariadb
    container_name: mymachine-mariadb
    restart: always
    environment:
      MARIADB_ROOT_PASSWORD: 
    ports: 
      - 8040:3306

  mymachine_access:
    image: keycloak/keycloak
    container_name: mymachine-keycloak
    restart: always
    environment:
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: 
      KC_HEALTH_ENABLED: true
      KC_METRICS_ENABLED: true
      KC_DB: mariadb
      KC_DB_URL: jdbc:mariadb://mymachine_db:3306/mymachine_keycloak
      KC_DB_USERNAME: mymachine_keycloak_user
      KC_DB_PASSWORD: 
      KC_DB_SCHEMA: mymachine_keycloak
      KC_PROXY_HEADERS: forwarded
      KC_HOSTNAME_URL: http://mymachineds723.local:8030
    ports: 
      - 8080:8080
      - 8443:8443
    entrypoint: ["/opt/keycloak/bin/kc.sh", "start-dev"]

[maccamb]

So unfortunately none of the above worked.

I have reverted to the minimal config that works the same way (i.e. can reach admin console but no successful login) - see the attached screenshot for the config.

I also turned on hostname-debug and have attached the screenshot of http://mymachine.local:8030/realms/master/hostname-debug

Note: only thing I have not tried is the hostname-path variable but I don't even know what to set it with to try.

[maccamb]

Also attaching screenshots of browser inspector for network and cookies.

Network (1st and 2nd screenshots): The response to the POST for the login is a 400.

Cookie (3rd screenshot): A cookie appears in the storage but none with the /realms/master path.

[darius-m]

It's likely that Keycloak still misses some parameter - try setting hostname and hostname-port (not sure if hostname-url is required when setting both of them) - see https://www.keycloak.org/server/all-config#category-hostname.

You should at least see some session cookies - AUTH_SESSION_ID, AUTH_SESSION_ID_LEGACY - which are set as soon as you access the login page, even without attempting a log in. If those are not set, it's likely Keycloak does not see the correct domain / path and does not correctly set the cookies (hence, the error you are receiving). I'm not sure whether the browser logs any error messages in the Console tab of the web developer tools if the site attempts to set cookies for a different domain (which would point to a wrong domain directly), but it's worth also checking it for any warnings or errors regardless.

[maccamb]

I tested with hostname and hostname-port with same result. I believe hostname-url fulfills both hostname and hostname-port; in addition to allowing you to specify the scheme to be used (https, http). So I am not sure that is the issue.

I do not see any AUTH_SESSION_ID or AUTH_SESSION_ID_LEGACY cookies. So that may be the next clue.

Do I need to specify a path also? And if so, what would it be?

Many thanks for your continued help!

[maccamb]

So... using the browser's inspector I find that the cookies are being rejected. Will dig into it to understand why.

What is baffling is that since keycloak is operating in dev mode, I would assume that it would work with most typical browser setups. I am using Firefox with a vanilla configuration. So if keycloak is in dev mode, then why is Firefox rejecting the cookie?

Attaching the shot of the browser inspector and a PDF with the browser settings

EDIT: added screenshot of offending cookies also

Settings.pdf

[codespearhead]

Just to make sure, is your internet behind some sort of network proxy (like a proxy server used at companies)? Are you using a VPN?

I'll check out the Docker compose file in a few hours.

[maccamb]

Nope - am at home. Setup is:

• eero - wired cx to NAS
• eero - wireless cx to laptop where run the browser

But based on my last post I am 99% sure that keycloak's start-dev mode is not setting the cookies correctly. But that 1% doubt has a strong hold on me as I am sure plenty of folks use the dev mode and are able to log in as admin.

Thanks for staying with me on this frustrating journey!

[maccamb]

I forgot to add that on the NAS, keycloak is behind a reverse-proxy, nginx. Setup on NAS is:
nginx <-> dockerized keycloak

But unless the reverse-proxy is supposed to alter the cookies being set by keycloak, it should not matter.

[maccamb]

After much digging in I have concluded that there may be inconsistencies in the way keycloak supports dev-mode - either in documentation or in code. Specifically the way cookies are set when HTTPS is not used.

So I decided to switch to HTTPS and that solved the issue. Lol!

Thank you guys for engaging, encouraging and helping me! Much appreciated!