We have Api configured and was working fine till upgrading our multi tenant environment to 2021 R1 (from 2020R1). post upgrade the connection fails with error "401 - Unauthorized: Access is denied due to invalid credentials. ".
If the issue is with credential it should have got failed for one tenant, but we are facing the issue across all the tenants so it should be the issue post upgrade.
is there any changes made in the 2021R1 which is causing this issue? or did we missed any configuration during the upgrade?
"401 - Unauthorized: Access is denied due to invalid credentials. You do not have permission to view this directory or page using the credentials that you supplied. At line:1 char:11 + $result = .\GetCustomView_custom.ps1 -RowLimit 10000 -FNMSSite https: ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,GetCustomView_custom.ps1 "
It's unlikely this issue would be related to changes in DLLs that were updated in the upgrade. An authentication failure like this occurs before any DLLs get loaded - the executable code in the FlexNet Manager Suite DLLs themselves is not touched until after IIS has authenticated the user.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
Are you explicitly passing a username & password to authenticate when calling the API, or are you using the currently logged on user's identity and relying on integrated authentication?
If you are relying on integrated authentication, as a troubleshooting step try running a web browser as the same user that you are running the GetCustomView_custom.ps1 script as and ensure you can access the site without having to enter a username & password. If you have to enter a username & password when viewing the site in the browser, you will likely have to specify a username & password for authenticating when calling the API over HTTP.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
I have tried both ways, supplied the credential within the script and also it took the logged in user credential. even though both have the permission it failed to authenticate
I'm not sure I have a direct answer, but what you've described seems to be pointing to something related to your IIS configuration, whereby IIS is failing to authenticate the user identity against the Active Directory domain. I'd be focusing troubleshooting and looking closely at the settings in the IIS configuration relating to the ManageSoftServices virtual directory.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
I have validated the authentication mode set for ManageSoftServices virtual directory and looks fine to me.
We have not made any changes during\after the upgrade on the IIS. Before upgrade it was working fine and it started failing exactly on the day when we have upgraded the platform . Also the issue is occuring on both test & prod environment. So i suspect changes on the binary files \ dll's would have caused this issue.
It's unlikely this issue would be related to changes in DLLs that were updated in the upgrade. An authentication failure like this occurs before any DLLs get loaded - the executable code in the FlexNet Manager Suite DLLs themselves is not touched until after IIS has authenticated the user.
(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)
After weeks of troubleshooting we identified the issue is on the authentication part. As you correctly mentioned it is not with dll's or binaries. We are validating api\bearer token on 3rd party authentication and access is getting denied there it self.
