Azure Auth. Internal error server after update

[AntonAndreevichMoroz]

Describe the bug Authentication failed after updating to latest version when using Azure strategy

To Reproduce With Azure Authentication configured, update to 1.0.84

Expected behavior A clear and concise description of what you expected to happen.

Screenshots

Server Software (please complete the following information):

OS: Debian 10 Virtualization: KVM Network: hybrid mode, reverse proxy (NGINX) with ssl offload Version: 1.0.84 Node: v16.17.0

Additional context When you roll back to 1.0.80, the problem disappears, on 1.0.82 the error is also present

Your config.json file

      "authStrategies": {
        "azure": {
          "callbackurl": "https://company.ru/auth-azure-callback",
          "newAccountsRights": [ "nonewgroups", "notools" ],
          "newAccounts": true,
          "clientid": "XXXXXXXXXXXXXXXXXXXXX",
          "clientsecret": "XXXXXXXXXXXXXXXXXXXXXXXX",
          "tenantid": "XXXXXXXXXXXXXXXXXXXXXXXXXXX"
        }

[mstrhakr]

I'd recommend rolling back to 1.0.82 until this can be resolved. 1.0.83 added the groups. There is now a pull pending to fix this at #4521

[Ylianst]

Should be fixed in just released v1.0.85.

[Matt-CyberGuy]

I was excited about this feature, but found after logging in with my Azure credentials, I couldn't edit fields in my profile like the email address or user name.

[mstrhakr]

I was excited about this feature, but found after logging in with my Azure credentials, I couldn't edit fields in my profile like the email address or user name.

Isn't the point of sso to unify user credentials into one place? I'm curious as to why you would want to edit them in MeshCentral, vs editing them in azure.

[Ylianst]

@mstrhakr Is correct. I explicitly removed the ability to edit user account fields as they are imported from the single sign-on server and no longer under MeshCentral control. If I had left them editable, they would revert back to the user's single-sign-on server values the next time they log in. If you have other ideas, let us know.

[Matt-CyberGuy]

I see... the reason for the want to change the email after login was I have ManageAllDeviceGroups set in the config for specific email addresses for our staff so I wouldn't have to add them as an admin for every group (we have LOTS).

Would there possibly be a way to specify the SSO accounts in the ManageAllDeviceGroups setting? This would also solve my issue.

[mstrhakr]

I think you can already do that, the azure sso section appends the unique_name attribute to the end of ~azure: to give you your user ID.

Azure User-Object Creation:

var user = { sid: '~azure:' + userex.unique_name, name: userex.name, strategy: 'azure' };

Although it seems there may be issues using unique_name based on this post:

Though that said if you need a unique identifier for the user that does not change, you can use either the oid or sub claims. The former is the object id for the user which can be used in calls to MS Graph API for example, while the latter is a unique identifier for the user in context to your app. So the object id will be the same across all apps, and the subject will be unique within one app.

Not to mention this bit of documentation from Microsoft regarding the unique_name claim:

Only present in v1.0 tokens. Provides a human readable value that identifies the subject of the token. This value is not guaranteed to be unique within a tenant and should be used only for display purposes.

So maybe this could be updated, although we would have to still pull in unique_name to provide backwards compatibility or check the db for that style of sid and run a conversion to the new way.

I'm gonna go put in an issue for all this but I digress, in theory from what I have gathered skimming the relevant sections of code, you should be able to use the sid ~azure:${unique_name} in that field.

[Matt-CyberGuy]

Awesome!! That worked, thank you!

[mstrhakr]

Describe the bug Authentication failed after updating to latest version when using Azure strategy

To Reproduce With Azure Authentication configured, update to 1.0.84

Expected behavior A clear and concise description of what you expected to happen.

Screenshots

Server Software (please complete the following information):

OS: Debian 10 Virtualization: KVM Network: hybrid mode, reverse proxy (NGINX) with ssl offload Version: 1.0.84 Node: v16.17.0

Additional context When you roll back to 1.0.80, the problem disappears, on 1.0.82 the error is also present

Your config.json file

      "authStrategies": {
        "azure": {
          "callbackurl": "https://company.ru/auth-azure-callback",
          "newAccountsRights": [ "nonewgroups", "notools" ],
          "newAccounts": true,
          "clientid": "XXXXXXXXXXXXXXXXXXXXX",
          "clientsecret": "XXXXXXXXXXXXXXXXXXXXXXXX",
          "tenantid": "XXXXXXXXXXXXXXXXXXXXXXXXXXX"
        }

This was fixed by #4521 in v1.0.85 so this can be closed. @AntonAndreevichMoroz