Azure Authentication results in 404 (inconsistently)

[fishter]

Describe the bug
I enabled Azure authentication many versions and months ago. Recently I have seen an occasional 404 error after the login button is pressed. The frequency of these 404 errors appears to be increasing. At first I thought it was correlated with my use of a particular VPN, or network connection, but that seems to have been a red herring.

To Reproduce
Steps to reproduce the behavior:

1. Open the login page for mesh central
2. Click on the Microsoft login icon
3. (optional) pick the right account to use for sign in.
4. See error 404 page. The URL appears to be double-encoded...
   https:///%2Fauth-azure-callback%3Fcode%3D1.AXoAizEgpnSl0kyqD5u8IsNpUJoSP

Expected behavior
I expect the log in to proceed to the main view, but I get stuck at this 404 page. The login has suceeded on the Azure end, but the callback to Mesh Central has failed in some way. Using a local account instead of the Azure login works.

Server Software (please complete the following information):

• OS: Amazon Linux 2023
• Virtualization: none
• Network: WAN
• Version: 1.1.49
• Node: 22.14.0

Client Device (please complete the following information):

• Device: Laptop
• OS: Windows
• Network: Remote, variously through home ISP, VPN to main office ISP, office ISP, etc...
• Browser: Chrome 141.0.7390.123

Additional context
Annoyingly, this is not a consistent error. For instance, while writing this bug report, I tried it in Edge browser and it worked. Then I went back to Chrome and it also worked after failing for over an hour and >10 attempts.

Your config.json file

{
  "$schema": "https://raw.githubusercontent.com/Ylianst/MeshCentral/master/meshcentral-config-schema.json",
  "__comment1__": "This is a simple configuration file, all values and sections that start with underscore (_) are ignored. Edit a section and remove the _ in front of the name. Refer to the user's guide for details.",
  "__comment2__": "See node_modules/meshcentral/sample-config-advanced.json for a more advanced example.",
  "settings": {
    "cert": "redact",
    "WANonly": true,
    "_LANonly": true,
    "sessionKey": "secret",
    "_port": 443,
    "_aliasPort": 443,
    "_redirPort": 80,
    "_redirAliasPort": 80,
    "relayPort": 453,
    "_syslog": "meshcentral",
    "Minify" : true,
    "Compression" : true,
    "webRTC": true,
    "wsCompression":true,
    "agentPing" : 50,
    "agentWsCompression":true,
    "_debug": "*",
    "dbExpire" : {
      "events" : 5184000
    },
    "_maxInvalidLogin" : {
      "time": 10,
      "count": 10,
      "coolofftime":10
      }
  },
  "domains": {
    "": {
      "title": "Access",
      "title2": "Europe",
      "allowedOrigin": "redact",
      "_minify": true,
      "NewAccounts": false,
      "_userNameIsEmail": true,
      "authStrategies": {
        "azure": {
          "callbackurl": "https://<domain>/auth-azure-callback",
          "newAccounts" : true,
          "clientid": "xxx",
          "clientsecret": "xxx",
          "tenantid": "xxx"
        }
      },
      "agentCustomization": {
        "displayName": "xxx",
        "descripton": "Agent for Europe server",
        "companyName": "xxx",
        "serviceName": "xxx",
        "fileName": "xxx"
      },
      "ssh" : true
    }
  },
  "letsencrypt": {
    "__comment__": "Requires NodeJS 8.x or better, Go to https://letsdebug.net/ first before trying Let's Encrypt.",
    "email": "redact@redact.fr",
    "names": "redact,redact",
    "rsaKeySize" : 3072,
    "production": true
  }
}

[si458]

try this config instead - https://ylianst.github.io/MeshCentral/meshcentral/openidConnectStrategy/#azure-preset

[fishter]

      "authStrategies": {
        "oidc": {
          "client" : {
              "client_id": "a...5",
              "client_secret": "O...b"
          },
          "custom": {
              "preset": "azure",
              "tenant_id": "a...0"
          },
          "callbackurl": "https://domain/auth-azure-callback",
          "newAccounts" : true
        }
      },

If I use this as my authStrategies content I end up with a new user when I log in "user//~oidc:cUjLI-..." vs "user//~azure:user@domain.ex".
I suppose this is expected, but is there a way to have it use the old method of generating the userid?

(Also, as this appeared to be an intermittent problem, I've gone back to the original config while I wait for the problem to reoccur).

[si458]

Yes its expected to say oidc as its an oidc method

As for the fact its showing a hash rather then the email address, you would need to change the azure setting in the cloud so it provides the uid as an email address rather than an email address, but im not sure how to do this as i don't have 365/entra/etc, I only have free entra provided to me by my Hotmail account and things are limited

[mstrhakr]

      "authStrategies": {
        "oidc": {
          "client" : {
              "client_id": "a...5",
              "client_secret": "O...b"
          },
          "custom": {
              "preset": "azure",
              "tenant_id": "a...0"
          },
          "callbackurl": "https://domain/auth-azure-callback",
          "newAccounts" : true
        }
      },

If I use this as my authStrategies content I end up with a new user when I log in "user//~oidc:cUjLI-..." vs "user//~azure:user@domain.ex". I suppose this is expected, but is there a way to have it use the old method of generating the userid?

(Also, as this appeared to be an intermittent problem, I've gone back to the original config while I wait for the problem to reoccur).

This is a known issue. I've considered a migration route but have not spent the time to implement anything at this point. Ideally (As laid out in the linked issue) we would want to migrate existing users away from the old to the new style. IMO The old azure authStrategy and others covered by OIDC should be depreciated with a migration path provided before eventual removal. But I'm not a real developer so really idk.
#4531

[si458]

@mstrhakr @fishter i found this solution for yous
ok so after testing with my free azure account (thank you hotmail) i got it working with oidc and using email addresses
the key part is the CLAIMS/UUID options,
it generates the identifiers as user/azureoidc/~oidc:myemailaccount@myemailaccountshortened.onmicrosoft.com in my case
but yin your case it would be user//~oidc:email@address.com

"authStrategies": {
  "oidc": {
    "client": {
      "client_id": "Application (client) ID",
      "client_secret": "Client Secrets Value"
    },
    "custom": {
      "preset": "azure",
      "tenant_id": "Directory (tenant) ID",
      "claims": {
        "uuid": "email"
      }
    },
    "groups": {
      "siteadmin": ["mesh-admins"],
      "sync": true
    },
    "newAccounts": true
  }
}

NOTE: groups is optional, i just added it to test my account becoming the siteadmin and syncing groups etc

[si458]

is this still an issue at all?

[fishter]

Hi @si458. I've not seen a reoccurence of the issue since I posted about it. I haven't updated my config, but I did update MC a few days ago. When we're next going through a "quiet" period at work I'll test out the config changes.

#7419 seems to be related and appears to be a good step up for the OIDC side of things.

Update: The very next morning... 404 error!

I've updated my config.json with your suggested updates and I'm migrating my users over as they login. So far, so good.

[fishter]

I'll close this given that I've had no repeats.