MISP icon indicating copy to clipboard operation
MISP copied to clipboard

Support: Getting Internal server error when Azure AD auth configured and MISP behind HTTP proxy

Open trizzosk opened this issue 2 years ago • 13 comments

Support Questions

I followed the guide for enabling authentication using Azure AD. Azure AD registration is done, added user groups (as proposed created 3 groups -> user, org admins and site admins) as permitted for the enterprise application use in Azure AD, added plugin config + adjusted config.php. My instance is sitting behind corporate proxy, configured as system ENV variable + added this setting in MISP config. All the sync jobs are working properly, so the MISP instance is indeed using proxy for accesing internet.

I used browser developer console for checking any HTTP requests or errors, but no luck here.

Unfortunately, I still getting Internal Server Error, as stated above (/var/log/apache2/misp.local_error.log). Any clues what could be wrong? How to troubleshoot these kind of issues? Thx for any useful advice.

MISP version

2.4.162

Operating System

Ubuntu

Operating System version

20.04. TLS

PHP version

PHP 7.4.3 (cli) (built: Jun 13 2022 13:43:30)

Browser

chromium

Browser version

Version 105.0.5195.125 (Official Build) built on Debian 11.5, running on Debian 11.5 (64-bit)

Relevant log output

Tue Sep 20 15:32:17.493896 2022] [php7:error] [pid 1483984] [client __redacted__:47386] PHP Fatal error:  Uncaught InternalErrorException: Internal Server Error in /var/www/MISP/app/Lib/cakephp/lib/Cake/Error/ErrorHandler.php:261\nStack trace:\n#0 /var/www/MISP/app/Lib/cakephp/lib/Cake/Error/ErrorHandler.php(212): ErrorHandler::handleFatalError()\n#1 [internal function]: ErrorHandler::handleError()\n#2 /var/www/MISP/app/Lib/cakephp/lib/Cake/Error/ErrorHandler.php(138): trigger_error()\n#3 [internal function]: ErrorHandler::handleException()\n#4 {main}\n  thrown in /var/www/MISP/app/Lib/cakephp/lib/Cake/Error/ErrorHandler.php on line 261, referer: https://__redacted__/

Extra attachments

No response

Code of Conduct

  • [X] I agree to follow this project's Code of Conduct

trizzosk avatar Sep 20 '22 14:09 trizzosk

Hello @trizzosk Could you please check this patch #8610 to see if it solves your problem?

righel avatar Sep 22 '22 13:09 righel

thx a lot @righel for advice. However, once I applied the patch, I am getting different error..... this time from Azure AD:

AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid......

Adding full message - inside MISP logs (every time I fail I am switching back to local auth so I can get logs from app):

POST request to url: https://login.microsoftonline.com/__redacted__/oauth2/v2.0/token returned HTTP code: 400 with response body: {"error":"invalid_grant","error_description":"AADSTS54005: OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.\r\nTrace ID: __redacted__\r\nCorrelation ID: __redacted__\r\nTimestamp: 2022-09-22 14:06:56Z","error_codes":[54005],"timestamp":"2022-09-22 14:06:56Z","trace_id":"__redacted__","correlation_id":"__redacted__"}

trizzosk avatar Sep 22 '22 14:09 trizzosk

Could you please enable the debug logs on your instance? There should be more detailed information there. Go to /servers/serverSettings, Security tab set debug to on, then retry the login action and share the error logs.

righel avatar Sep 22 '22 14:09 righel

Thx for @righel suggestion. seems that auth is somehow running, at least a little bit... but..... at the end I see another errors....

the /var/www/MISP/app/Config/config.php contains (except the other stuff) following config for AAD auth:

'AadAuth' => array ( 'client_id' => '__REDACTED__', // Client ID (see Azure AD) 'ad_tenant' => '__REDACTED__', // Directory ID (see Azure AD) 'client_secret' => '__REDACTED__', // Client secret (see Azure AD) 'redirect_uri' => 'https://__REDACTED__/users/login', // Your MISP URI, must be the same as in Azure AD 'auth_provider' => 'https://login.microsoftonline.com/', // No change required 'auth_provider_user' => 'https://graph.microsoft.com/', // No change required 'misp_user' => 'g-sec-zsd-security-misp-users', // The AD group for MISP users 'misp_orgadmin' => 'g-sec-zsd-security-misp-org-admins', // The AD group for MISP administrators 'misp_siteadmin' => 'g-sec-zsd-security-misp-site-admins', // The AD group for MISP site administrators 'check_ad_groups' => true, // Should we check if the user belongs to one of the above AD groups? ),

In the /var/www/MISP/app/tmp/logs/error.log I see following error:

2022-09-22 17:25:01 Warning: The user is not a member of any of the MISP AAD groups. 2022-09-22 17:25:01 Warning: Error received during Bearer token fetch (context). 2022-09-22 17:25:01 Warning: Error received during Bearer token fetch (context).

I checked the AAD, the user which I use for testing is a member of the g-sec-zsd-security-misp-org-admins user group (object type is Security group in AAD, not Office 365 group). The user is active, signin allowed, however several conditional access policies applied (although no issues). I can see that the test user sucessfully login to Azure AD (within signin logs). Once I take a look at the "non interactive logins" within Azure AD, I see the error:

Authentication requirement: Single-factor authentication Status: Failure Continuous access evaluation: No Sign-in error code: **54005** Failure reason: **OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token.**

no luck here....

trizzosk avatar Sep 22 '22 15:09 trizzosk

@righel Meanwhile - pls advice which logs or dumps you are asking for, i will paste it here (with sanitised sensitive data). Thx

trizzosk avatar Sep 23 '22 06:09 trizzosk

Could you set the check_ad_groups AadAuth setting to false and retry? I see you are getting: 2022-09-22 17:25:01 Warning: The user is not a member of any of the MISP AAD groups. Group names have to an exact match, check for case differences, special chars, etc.

You should be able to see debug logs in this file: /var/www/MISP/app/tmp/logs/debug.log after you switched your MISP debug setting to on

righel avatar Sep 23 '22 07:09 righel

Ok - once I set the check_ad_groups' to false` I was able to login with account, which already existed in MISP. Once I used an account (Azure AD account) which does not exist in MISP instance, I am not able to login.

So there must be a glitch in handling assertion tickets with groups (group name format....parsing...).

trizzosk avatar Sep 23 '22 07:09 trizzosk

As I posted above, naming convention for groups in our tenant require me to use - in name... I will try to create group without this char to double check it.

trizzosk avatar Sep 23 '22 07:09 trizzosk

- should be fine, just be sure the strings are a exact match. as it is, this plugin does not enroll users on MISP if it exists in Azure AD. There's PR open for that https://github.com/MISP/MISP/pull/8501, I haven't had time to test it yet feel free to test it and add some feedback.

With the debug logs you should see the exact responeses you get from Azure and you can compare the group names with the ones you set in AadAuth config on MISP side, there's likely a string mismatch.

righel avatar Sep 23 '22 08:09 righel

Hello @trizzosk, Have you found how to solve it? I think I'm having quite the same issue : no login if user not enrolled in MISP, same OAuth2 Authorization code was already redeemed, please retry with a new valid code or use an existing refresh token error. Thank you.

GuillaumeBrn avatar Jun 01 '23 13:06 GuillaumeBrn

@GuillaumeBrn well - partially. I do not use group assignments because of this issue. Without groups this works without any issue.

trizzosk avatar Jun 02 '23 12:06 trizzosk

@GuillaumeBrn well - partially. I do not use group assignments because of this issue. Without groups this works without any issue.

@trizzosk Yeah same for me. Just assigning roles through the application...

GuillaumeBrn avatar Jun 05 '23 06:06 GuillaumeBrn

Hi, Any update on this or shall we all ignore? The authentication is indeed working properly, but roles in MISP are not assigned on groups from Entra ID (formerly Azure AD). Shall we ignore this, so I can close the issue?

Cheers, Marian

trizzosk avatar Jan 24 '24 14:01 trizzosk