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
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 logic.zip 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 'https://login.microsoftonline.com/common/oauth2/v2.0/authorize' -TokenEndpoint 'https://login.microsoftonline.com/common/oauth2/v2.0/token' -ClientID '5bb1a5a2-0d97-4335-9448-119f7b27aff9' -RedirectUrl 'https://login.microsoftonline.com/common/oauth2/nativeclient'
# After successfully logging into the browser and consenting to permissions, the browser window closes
# Now get the returned token
$res.RefreshToken
# 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
‎Jan 29, 2020 05:03 AM - edited ‎Jan 29, 2020 05:03 AM
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 https://community.flexera.com/t5/FlexNet-Manager-Knowledge-Base/Office-365-Adapter-fails-with-an-error-when-trying-to-capture/ta-p/128838 as a result of this so may be worth trying those steps to see if it helps you also.
‎Jan 29, 2020 09:57 AM
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:
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
‎Jan 29, 2020 02:33 PM
Hi,
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.
https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
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.
j
‎Jan 29, 2020 06:58 PM
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_?
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
‎Jan 30, 2020 02:42 AM
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]_20200130082035.zip
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
‎Jan 30, 2020 06:14 AM
‎Feb 04, 2020 07:16 PM
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 (flxo365@customer.com )
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,
Dennis
‎Feb 12, 2020 03:26 AM
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 office.com or portal.azure.com, 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.
Thanks!
‎Feb 14, 2020 09:21 AM
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 ...
‎Feb 15, 2020 01:24 PM
‎Feb 15, 2020 03:09 PM