cancel
Showing results forĀ 
ShowĀ Ā onlyĀ  | Search instead forĀ 
Did you mean:Ā 

UAS Strange behavior since upgraded to V4CP1HF01

RGenin
Trusted Contributor

Hello, 

 

Since we have installed V4 CP1 HF01 (straight from V4) in our DEV environment, we have a problem with UAS authentification we did not have before:

 

1/ If we go to URL https://hopex.dev.uni/Hopex/ it is going as it should to https://hopex.dev.uni/Hopex/uaslogin.ashx . However, there is a 404 status:

RGenin_0-1603383569351.png

If we refresh the page on the same url, the error code changes (from 404 to IDX20803) :

RGenin_2-1603383675146.png

2/ If we go directly to https://hopex.dev.uni/Hopex/login.aspx it is going to to https://hopex.dev.uni/Hopex/uaslogin.ashx again and we get the same 404 error page.

However, if we go directly  to https://hopex.dev.uni/Hopex/login.aspx again (as many times as we want within the same session in the browser), then we can correctly login:

Snag_3d865bc.png

 

We have double checked everything : permissions, rights on certificates (we even reimported them according to the UAS procedure, ect)

 

Any clue ?

 

Thanks

11 Replies

RGenin
Trusted Contributor

Hello Joseph, 

 

So I can confirm we double/triple checked, and still no luck.

 

So we have taken another approach:

- We have completely removed Mega Hopex from our VM

- We have redownloaded the V4  (now embedding CP1) and reinstalled it , and installed the hotfix as well. 

-=> it works well now (without doing anything else)

 

So going the fresh V4CP1 + hotfix route worked for us, whereas the V4 + CP1 + hotfix did not.

 

Thanks for your assistance !

Hello,

 

Ok, thanks for the reply and information. Another thing to check would be consistency of the case sensitivity of the URLs in the Megasite.ini and Hopex Administration.exe "Site" Options. In standing up an installation of V4 CP1 on a virtual machine (leveraging Hopex's Native authentication for a test user)

jcamara_2-1604954162434.png

 

 

I had to confirm that all URLS in the Megasite.ini

 

jcamara_1-1604950586303.png

 

 

and specific settings in the extended view of the Options were identical (using an Upper Case "H") 

jcamara_3-1604954310033.png        jcamara_4-1604954338875.png

 

Could you take a look and confirm?

RGenin
Trusted Contributor

Hello Joseph, 

 

Here is the screenshot of the registry key:

RGenin_0-1604698788409.png

 

Indeed in our installation is not clustered and we used CNAME.

 

We are always using the supervisor tool (swl 6 mode) to restart all the suite after ay modification.

 

Thanks !

jcamara
Administrator
Administrator

Hi RGenin,

 

What does the MWAS URL in the registry look like on the server? It is located here:

 

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MEGA\WEB ACCESS SERVER\7.1

jcamara_0-1604675028142.png

 

 

If your deployment is not clustered (All on a Single Server) you can set it to leverage the CNAME as well (if it isn't already).

 

Also, when changing/updating URLs, I'd recommend leveraging the Supervision Utility to stop all services/IIS then Restart IIS followed by Server Supervision Services (Microsoft Services) then the Watchdog.

jcamara_1-1604675219653.png

 

RGenin
Trusted Contributor

Hello Olivier, 

 

Thanks for your detailed answer.

 

 

  • Did you change the URL when moving from V4 to V4 CP1 HF1 ? => No changes is IIS or in the configs
  • Does the URL of the SSL certificate is aligned with the URL we see in this post ? => yes
  • Are you sure of the option of the web.config of HOPEX ? => yes

Here is the content of openid-configuration :

 

{
    "issuer": "https://hopex.dev.uni/hopex/UAS",
    "jwks_uri": "https://hopex.dev.uni/hopex/UAS/.well-known/jwks",
    "authorization_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/authorize",
    "token_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/token",
    "userinfo_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/userinfo",
    "end_session_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/endsession",
    "check_session_iframe": "https://hopex.dev.uni/hopex/UAS/connect/checksession",
    "revocation_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/revocation",
    "introspection_endpoint": "https://hopex.dev.uni/hopex/UAS/connect/introspect",
    "frontchannel_logout_supported": true,
    "frontchannel_logout_session_supported": true,
    "scopes_supported": ["phone", "email", "address", "roles", "openid", "profile", "offline_access", "hopex", "write", "read"],
    "claims_supported": ["phone_number", "phone_number_verified", "email", "email_verified", "address", "role", "sub", "name", "family_name", "given_name", "middle_name", "nickname", "preferred_username", "profile", "picture", "website", "gender", "birthdate", "zoneinfo", "locale", "updated_at"],
    "response_types_supported": ["code", "token", "id_token", "id_token token", "code id_token", "code token", "code id_token token"],
    "response_modes_supported": ["form_post", "query", "fragment"],
    "grant_types_supported": ["authorization_code", "client_credentials", "password", "refresh_token", "implicit"],
    "subject_types_supported": ["public"],
    "id_token_signing_alg_values_supported": ["RS256"],
    "code_challenge_methods_supported": ["plain", "S256"],
    "token_endpoint_auth_methods_supported": ["client_secret_post", "client_secret_basic"]
}

 

 

As for the  https://hopex.dev.uni/Hopex/uaslogin.ashx , I believe it comes from our megasite.ini  (I don't remember having that many values configured in it before, but I don't have a copy on hand) (check Client.DTPX.AllowedRedirectUris)

 

[Authentication]
Client.DTPX.AllowedRedirectUris=https://hopex.dev.uni/hopex/uaslogin.ashx;https://hopex.dev.uni/hopex2/uaslogin.ashx
Client.DTPX.PostLogoutRedirectUris=https://hopex.dev.uni/hopex/Default.aspx
Provider.Windows.ServerUrl=https://hopex.dev.uni/WindowsAuthenticationService
Client.DTPX.RedirectUris=https://hopex.dev.uni/hopex/uaslogin.ashx;https://hopex.dev.uni/hopex2/uaslogin.ashx
Authentication.InvalidSignInRedirectUrl=https://hopex.dev.uni/hopex/Default.aspx
Client.Swagger.RedirectUris=https://hopex.dev.uni/hopexapi/api/v1.0/uasproxy
Client.Swagger.AllowedRedirectUris=https://hopex.dev.uni/hopexapi/api/v1.0/uasproxy
PublicOrigin=https://hopex.dev.uni/hopex
Cookie.AllowRememberMe=1
SigningCertificate.Password= REDACTED
SigningCertificate.Name=hopex.dev.uni

 

 

Thanks, 
Raphaƫl.

Hello,

 

Looking at the error message "PII is hidden" it refers to issues with URL not being aligned across all the layers of the call.

 

  • Did you change the URL when moving from V4 to V4 CP1 HF1 ?
  • Does the URL of the SSL certificate is aligned with the URL we see in this post ?

 

I'm also suprised by the URL of UAS.

 


@RGenin wrote:

If we go to URL https://hopex.dev.uni/Hopex/ it is going as it should to https://hopex.dev.uni/Hopex/uaslogin.ashx .


If a UAS properly configured installation

 

Are you sure of the option of the web.config of HOPEX ?

 

Particularly the keys :

 

<add key="AuthenticationUrl" value="https://hopex.dev.uni/UAS"/>
<!-- Authentication service url -->

 

 

RGenin
Trusted Contributor

Hi Asim, 

 

Indeed points 1/2/3 are correct.

If we enable Mega auth, it will work without any issue.

If we enable UAS, the problems shown above arise. It was working fine before CP1/HF1.

 

All paths/links are correct in every web.config subfolders, as well as a matching SSP key.

 

Thanks, 

Raphaƫl.

Hi RaphaĆ«l,
Regarding your 1st post, I am assuming that:

1. It is working fine when you change the authentication to "Mega" in web.config file ("C:\inetpub\wwwroot\HOPEX")

2. There is no Single Sign on configured

3. This address (https://hopex.dev.uni) seems to me a CNAME to actual server name

 

So, to start with, if you do the point 1, does it work?

If yes then check the megasite.ini file, does it has the correct paths/links with "hopex.dev.uni" and also in web.config files for "C:\inetpub\wwwroot\HOPEX" and "C:\inetpub\wwwroot\UAS" ?

RGenin
Trusted Contributor

Hi @oguimard , 

 

No, we haven't : our migration path is to upgrade directly from V2R1CP7 to V4CP2 when it will be out, and we have already spent too much time trying to test this version or make it work. This post was more a FYI / raise concern for Mega in case something was broken (or a security issue in our example) 

Other then that the problem mentioned above, in this version:

* Service-Now integration is also broken (was working on V4), all jobs failing at tRESTClient step.

RGenin_0-1603460812312.png

This was an improvement, as Talend was showing a java error message before. 

This was solved by adding certificates (mega + our own sub-domain where Mega runs)  to the cacerts file in the java folder(s).

EG: 
keytool -importcert -file "C:\temp\mega.com.cer" -alias mega.com -keystore "C:\Program Files (x86)\MEGA\HOPEX V4\java\jre\lib\security\cacerts"

The cacerts trick also solved the "UAS - Refresh Bearer token" that was broken in Postman as well.

 

Best, 

Raphaƫl.