mirror of
https://github.com/Ylianst/MeshCentral.git
synced 2026-03-02 23:07:02 -05:00
Unable to authenticate when using MC2 in multi-zoned environment #1855
Labels
No labels
Can't Replicate
Closed
Feedback
Fixed - Please Verify & Close
Low Priority
Plugin's in use
Sponsor required
Stale
bootstrap
bug
docker
docs
duplicate
enhancement
help wanted
important
invalid
question
sponsor found
temporarily fixed
upstream fix needed
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/MeshCentral#1855
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @D4V3M0NK on GitHub (Dec 11, 2020).
Originally assigned to: @Ylianst on GitHub.
Please forgive the notes: it's taken me about 4 hours so far to write this as things keep on happening differently from prior testing...
I have a freshly built MC2 server that sits behind a network load balancer then an application load balancer (both operating their internal IPs from separate zones). I've created an admin account through the CLI, logged in and updated the version in my image (0.5.97) to the latest stable (0.6.70). I then start up the server in
--debugmodeI then attempt to login and get the
Unable to authenticateerror, similar to that in #1770. Debug1 shows the output from the server after I was initially rejected, then hit refresh after which I was able to login.Config1
Debug1
Now, in reading #1770 I see that there's a config setting (
"cookieipcheck": false) that I can potentially set, so I update my config accordingly:Config2
Debug2
Now I had other notes (see #2072 and #2073) but as I've gone through testing this out today I think perhaps the MFA issues that I've been experiencing are still related to IP issues. Additionally, and differing from #1770, we don't currently use IPv6.
I'm surmising here, but I'm thinking that because the MC2 server is sitting behind a load balancer, traffic within the same session is being requested from either of the two load balancer internal IPs, but the initial set up of the cookie is recorded and set from a single IP address. Depending on the traffic, intermittent issues arise in authenticating the source IPs (
WEB: ERR: Invalid cookie IP address, got "IP_ADDR_B", expected "IP_ADDR_C".) because it could be coming from the same IP (load balancer A) that was set up from the initial request, but a subsequent request could be sourced from another address (load balancer B). I'm unsure as to whether or not setting the LB's tostickymode would help here or not, but in the interests of making MC2 as flexible as possible, I've not currently enabled that on my LBs.I'm nowhere near the programmers you fine chaps are, but I wonder if there's a setting within the config that could be set that puts an array of IP addresses in the initial cookie as being "validated" IPs, so that if traffic comes in from one of the addresses in the array, it's assumed to be authenticated. For my particular scenario, I would configure IP_ADDR_B and IP_ADDR_C in this configuration. I see there are other IP options within the config.json file, but I don't believe that any of them address this particular situation?
@Ylianst commented on GitHub (Dec 12, 2020):
Can you try adding this line to the settings part of the config.json:
You will need to have the latest MeshCentral server. You can then remove the
"cookieipcheck": falsein the domain section.The trusted proxy line needs to include all of the internal IP addresses of you load balancer(s). This will indicate to MeshCentral that it's safe to parse the extra HTTP headers in these requests and your load balancers will likely tell MeshCentral what the original IP address of the request was. As, you will start seeing the actual IP address of the request, not the address of your load balancers. Let me know if that helps.
@D4V3M0NK commented on GitHub (Dec 12, 2020):
I'm running 0.7.24 and with the updated config, I start up MC2 in debug mode but get the following Unrecognized configuration option warning:
CurrentConfig
@D4V3M0NK commented on GitHub (Dec 12, 2020):
I do like the warning in the new version of the GUI though... Very useful!
@Ylianst commented on GitHub (Dec 13, 2020):
I see the problem, the
trustedProxyvalue needs to be in theSettingssection. You can look at an example here. Same goes forno2FactorAuth, that also goes in thesettingssection, but in the case ofno2FactorAuth, the default is false and you probably don't need it.Let me know if that helps,
Ylian
@D4V3M0NK commented on GitHub (Dec 13, 2020):
You know, I read and re-read that advanced sample JSON file so many times, I saw the
}on line 23 and every time read that as the closing ofsettingsand notdbexpire... I'm sorry @Ylianst that's a newbie mistake and I should've seen that waaaaaaaay before now.Apologies for the inconvenience. Enjoy your holiday sir.