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

O365 token generation -"interaction_required" error

Hi community,

I want to connect O365 (FNMS 2019 R2) to a customer and get the following error "interaction_required". After starting the "Generate token" function the O365 login window opens and I enter the email. The next step should be the login at the company-AD/password entry. At this point the window closes and the error message appears. The necessary URLs are all unlocked at the proxy and a connection test via IE works

O365_2020-01-29 10_46_36.pngO365_2020-01-29 10_46_53.png


With reference to a ticket (#01952377), I also tried this solution, but still the same error PS script and IE closed after entering the email and move on to the next step




The alternate approach is to generate the token on a separate machine using Powershell and then save it on the beacon. This should work because once the beacon has the RefreshToken it will not be redirected to the custom authentication site. I've attached a zip file which contains the powerhell script logic.ps1.  Here are the steps to generate the token from a machine which has access to the O365 and the authentication site --

# Copy the Logic.ps1 in Downloads folder. (logic.ps1 is attached to the case)

# Open an Administrator PowerShell window and navigate to Downloads folder.

# Execute the following commands:

# Load the script (Dot source the powershell script)

. .\Logic.ps1

# Launch the browser to login and generate refresh token

$res = Get-RefreshToken -AuthorizationEndpoint '' -TokenEndpoint '' -ClientID '5bb1a5a2-0d97-4335-9448-119f7b27aff9' -RedirectUrl ''

# After successfully logging into the browser and consenting to permissions, the browser window closes

# Now get the returned token


# Copy the token and paste it in a notepad, remove line breaks, if any and then paste it in RefreshToken text box on Beacon along with other values and save it.





Thanks for your support!

Best, Dennis

(10) Replies

Hi @dennis_reinhardt ,

I've not seen that particular error before but I know there were changes recently on the Microsoft side that required additional steps to be carried out.

We created as a result of this so may be worth trying those steps to see if it helps you also.

(Anything expressed here is my own view and not necessarily that of my employer, Flexera)
If the solution provided has helped, please mark it as such as this helps everyone to know what works.


Thanks for your feedback. We have already taken this advice into account and set the permissions.

I have executed the instructions from the ticket (PS Script to receive the token) on a normal client PC in the customer network and have successfully received a token. So it seems to be either a firewall or access problem. We have unlocked the following URL at the proxy:

  • *
  • *
  • *
  • access to internal ADFS server for authentication against O365 portal

I would be grateful for further information on troubleshooting, since the creation of the token outside the Beacon software does not represent a permanent solution.

In the next step I will first check the connection with the token to the O365 portal.


Best, Dennis

By Level 7 Champion
Level 7 Champion


I'm having similar issues with a customer that needs to:

1) use a proxy, and

2) the proxy has a whitelist enforced, meaning no connection to outside sites unless they are explicitly approved in the proxy.


The problem here is that Microsoft O365 has a huge range of fqdns and subnets to approve, depending on what services you need to interact with.

The following web site listed the current ones, and as documented they may be updated every 30 days.

I've gotten ID sets 56, 59, and 147 whitelisted in the proxy, and this allows for login to O365, and then configuration of the token. (I'm still having some issues grabbing usage, but I'm missing one of the privileges on the service account).

The potential for these sets subnets and hostnames to change every 30 days is an issue. We're starting the process of getting the customers proxy owners to monitor and keep this updated (it may be possible to automate).


If the proxy was just using a blacklist we wouldn't have this problem.




Thanks for your detailed answer. This is a huge list of url's and IP to allow in the proxy. Can't believe all of these are needed to get the adapter working ... o_?

@mrichardson @ChrisG 

Do you have any detailed information about the required URL/IP we've to allow in the proxy. The documentation is a bit limited in this case. Or could you confirm, that the ID 56,59 and 147 will work based on the latest Endpoint documentation by MS

Added all the mentioned URL from the MS O365 endpoint (56,59,147)

But running again into an error

2020-01-30 09:20:34,554 [INFO ]   Reading 'Computer' data from 'O365'  (ver 1.0) data source
2020-01-30 09:20:34,570 [INFO ]     Get Users from Office 365 (Transfer data from source 'O365' to FNMP)
2020-01-30 09:20:35,351 [ERROR]       The remote server returned an error: (400) Bad Request.
2020-01-30 09:20:35,367 [ERROR]       Error occurred trying to get the access token: Get-TokenSetInternal failed
2020-01-30 09:20:35,851 [INFO ]       Failed to execute Reader 'Get Users from Office 365' from file C:\ProgramData\Flexera Software\Compliance\ImportProcedures\Inventory\Reader\microsoft 365\User.xml, at step line 1
Error: The remote server returned an error: (400) Bad Request.
2020-01-30 09:20:35,851 [INFO ]       All retries have been attempted for Reader 'Get Users from Office 365'
2020-01-30 09:20:35,851 [INFO ]       Completed with error in 1 second.
2020-01-30 09:20:35,851 [ERROR]     System.Net.WebException: The remote server returned an error: (400) Bad Request.
   at ManageSoft.Compliance.Importer.Logic.PowerShellDataReader.CheckForPowerShellError()
   at ManageSoft.Compliance.Importer.Logic.PowerShellDataReader.Read()
   at ManageSoft.Compliance.Importer.Serialization.IntermediateWriter.WriteData(XmlWriter xmlWriter)
   at ManageSoft.Compliance.Importer.Serialization.IntermediateWriter.WriteData()
   at ManageSoft.Compliance.Importer.Logic.XML.SourceToTarget.ExecuteReader(IExecutionContext context, ISourceConnection sourceConn, IDataReader reader)
   at ManageSoft.Compliance.Importer.Logic.PublicObjectModel.SourceToImportedTableObject.ExecuteReader(IValidatingDataReader reader, SourceToObject STOObject)
   at ManageSoft.Compliance.Importer.Logic.PublicObjectModel.SourceToObjectImplementation.ExecuteImplementationSQL(IExecutionContext context, SourceToObject sourceToObject)
   at ManageSoft.Compliance.Importer.Logic.XML.Reader.Execute(IExecutionContext context)
   at ManageSoft.Compliance.Importer.Logic.ActionExecuter.ReaderExecuter.ExecuteSingleReader(Reader reader, Int32 procedureOrder, Version sourceDatabaseVersion)
   at ManageSoft.Compliance.Importer.Logic.ActionExecuter.ReaderExecuter.Execute()
   at ManageSoft.Compliance.Importer.Logic.ComplianceImporter.ProcessExecution(ComplianceReader p_ComplianceReader, Tenant p_Tenant, IExecutionContext p_Context)
2020-01-30 09:20:36,132 [INFO ]     Created intermediate package at C:\ProgramData\Flexera Software\Beacon\IntermediateData\I[S=O365]
2020-01-30 09:20:36,179 [INFO ]   Time: Donnerstag, 30. Januar 2020 09:20:36
2020-01-30 09:20:36,179 [INFO ]   Total import time: 6 seconds
2020-01-30 09:20:36,179 [INFO ]   0 source data warnings
2020-01-30 09:20:36,179 [INFO ]   3 errors, 0 warnings
One other quirk I didn't mention:
when you click 'Generate...', the Office 365 login prompt is an Internet Explorer session, and so whatever proxy set inside IE is the one that is used, NOT the one you just entered into the connection config. So if those are different proxyies, set the IE proxy to be the same as the connection's proxy.
Once the token is generated you can set the IE proxy back to whatever it was.


We could now solve the problem, but we are not yet satisfied with the solution.

The Beacon Service runs in the context of a Flexera-Service Account (svc-flx). The login via RDP and the execution of the Beacon App was also done in the context of the Flexera-Service Account (svc-flx). For the O365 connection we have a dedicated O365 user available ( )

As it turns out, the O365 adapter tried to connect with the Flexera-Service Account, which of course had no permissions on the portal and therefore the "interaction_requiered" error occurred, because no login page could be opened.

As a test, we have added the Flexera-Service Account to the O365 portal and assigned appropriate rights. Since this change access is possible.

Now the question - how can we ensure a separation of the accounts and make the Beacon O365 Adapter clear that the account which is specified in the first query field for the O365 login should be used.

Thanks and Best,


Hi Dennis,

I believe we have something like this earlier. This is not a beacon or FNMS issue. If you launch IE or any browser on the beacon machine and try to connect to or, you may see that it was trying to connect using the Service account. If you can fix that so that it prompts for a login, instead of trying to use the default credentials, this problem may go away and then beacon will be able to use the account that you specify in the connection details.

I hope this helps. Please let me know if this suggestion helps you.


HI @Alpesh 

what I forgot to add in my last post ... when running the O365 adapter setup a new browser windows opens (from the o365 powershell script) and asked to enter my current o365 email. Using the dedicated o365 account will cause the "interaction_required" error. As you said, looks like that the IE doesn't use the entered credentials while forwarding the login request to the o365 portal ...

Thanks Dennis. I believe this is the same behavior I had seen with other customer. They were able to work with their IT/O365 admin to ensure that IE uses the credentials that are entered manually instead of a default account. So check with your IT team and see they can help you fix this issue, which will also help you resolve the interaction required error.