The Flexera Community is currently in maintenance mode to prepare for the upcoming launch of the new community. Click here for more information.
Hello All,
A number of our Users that are set up with accounts in FNMS are unable to login to the tool due to the system identifying their credentials as incorrect even though they're correct.
We're receiving inventory from all associated AD's, and FNMS recognises the user's usernames and the corresponding domains they're attempting to login from.
This only affects approximately 20% of our users reporting in from multiple different AD's.
Any ideas as to the issue?
Screenshot attached of error message received by users.
‎May 30, 2019 10:16 AM
‎May 31, 2019 09:41 AM
Hi Daniel,
kclausen is correct. There is a difference between the authentication in FNMS and the way agents report.
When a user logs into FNMS, the credentials are verified against the domain of the account running the FNMS application (Service account). Because the password is not stored into FNMS itself, this step is mandatory. Other domains can be used for access but only if the domain is trusted with the domain of the service account.
If this is not the case, the service account cannot verify the credentials against an untrusted domain (no permissions) so the users cannot be verified and therefor do not have access in FNMS.
For agents, the inventory file only contains the user name and not the password. So the account can only be used for license consumption but not for authentication as long as the domain is not trusted with the service account domain.
Hope this helps,
Stefan
‎Jun 03, 2019 03:14 AM
I have had this exact same issue and we determined the account were accidentally setup as non-interactive accounts. This cannot be changed in the FNMS User User Interface
If you have access to your data you can follow these steps below to find and correct the users. If you are using the SaaS solution you likely need to open a case with Support.
1. Query the FNMS Compliance database directly for the user you are having trouble with:
select * from complianceoperator
where OperatorName = 'domain\userid'
2. Validate the user is set not interactive. Observe field, Interactive=0
3. If Interactive was set to 0 (zero), run the following update statement.
update ComplianceOperator
set Interactive =1
where OperatorLogin = 'domain\userid'
and Interactive = 0
‎May 30, 2019 11:09 AM
We've had a look and all the accounts in question and they're already set to Interactive so that problem can be ruled out.
Thanks for the help, hopefully another fix will pop up.
‎May 31, 2019 03:20 AM
Do you have cross-domain trust between the Domain that the FNMS server is in and the domain where these user accounts are that are failing? FNMS will rely on Windows Authentication managed by IIS.
‎May 31, 2019 07:07 AM
Yeah we have inventory agents reporting in from those domains with no problem. Which only adds to the confusion as to why the user accounts aren't working.
‎May 31, 2019 09:19 AM
‎May 31, 2019 09:41 AM
Cheers for the help!
As you suggested we hadn't set the corresponding domains to trust one another.
Thanks again
‎Jun 04, 2019 03:43 AM
Hi Daniel,
kclausen is correct. There is a difference between the authentication in FNMS and the way agents report.
When a user logs into FNMS, the credentials are verified against the domain of the account running the FNMS application (Service account). Because the password is not stored into FNMS itself, this step is mandatory. Other domains can be used for access but only if the domain is trusted with the domain of the service account.
If this is not the case, the service account cannot verify the credentials against an untrusted domain (no permissions) so the users cannot be verified and therefor do not have access in FNMS.
For agents, the inventory file only contains the user name and not the password. So the account can only be used for license consumption but not for authentication as long as the domain is not trusted with the service account domain.
Hope this helps,
Stefan
‎Jun 03, 2019 03:14 AM
Thanks for the help with this.
As kclausen and yourself pointed out it was a cross-domain trust issue.
Cheers
‎Jun 04, 2019 03:44 AM