The Community is now in read-only mode to prepare for the launch of the new Flexera Community. During this time, you will be unable to register, log in, or access customer resources. Click here for more information.
Looking for some input from the community regarding fnms user info.
Currently, our user information is sourced from the out of box AD connection. The oob connection populates minimal information and also creates a user for any/all AD accounts.
Questions:
1. Does FNMS need a user for every AD account? Service accounts, administrative accounts? Our company has regular user and administrative accounts for several employees (multiple ad accounts for single user).
2. Is it best practice to keep the oob AD user information? Or build custom business adapter to employee HR database?
‎May 08, 2020 12:20 PM
Hi Rob,
FNMS does not need a user for service accounts or administrative accounts. For eliminating at least some of these administrative accounts, the list of users imported from Active Directory is filtered by an "Exclusion list". This will eliminate standard Windows users like 'ASPNET', 'IUSR_%' etc before creation of users in FNMS.
You can view the standard exclusion list from the FNMS Web UI under "Admin (cogs) > System Settings > Users". In case you have access to the [FNMSCompliance] database, you can modify and extend this list using the [UserNameBlacklist] table.
And yes, it is best practice to use the OOTB Active Directory user information. For adding additional user attributes, a business adapter should be used.
There is some documentation on building such a business adapter in the "Business_Adapter_Practice_Guide" available from the Learning Center. In addition to the latest 4.0 version of this document, I find the previous 2.0 version (see attachment) helpful, too.
‎May 09, 2020 12:54 AM - edited ‎May 09, 2020 12:55 AM
Hi Rob,
FNMS does not need a user for service accounts or administrative accounts. For eliminating at least some of these administrative accounts, the list of users imported from Active Directory is filtered by an "Exclusion list". This will eliminate standard Windows users like 'ASPNET', 'IUSR_%' etc before creation of users in FNMS.
You can view the standard exclusion list from the FNMS Web UI under "Admin (cogs) > System Settings > Users". In case you have access to the [FNMSCompliance] database, you can modify and extend this list using the [UserNameBlacklist] table.
And yes, it is best practice to use the OOTB Active Directory user information. For adding additional user attributes, a business adapter should be used.
There is some documentation on building such a business adapter in the "Business_Adapter_Practice_Guide" available from the Learning Center. In addition to the latest 4.0 version of this document, I find the previous 2.0 version (see attachment) helpful, too.
‎May 09, 2020 12:54 AM - edited ‎May 09, 2020 12:55 AM
Thanks for the reply.
I am looking at filtering out accounts not needed and enriching the user records with information from our HR database.
Why is it best practice to use AD for the base record vs an HR database?
Thanks again.
‎May 14, 2020 09:21 AM
@rwiltshire - that is a great question!
The concept of a "user" in FlexNet Manager Suite more closely and naturally matches the concept of a "user" in Active Directory (i.e. a login account) than a "person" in an HR database. Another way to think of it is that FlexNet Manager Suite user records primarily correspond to accounts used for logging on to or accessing systems, O365 accounts, etc. Each person in an HR database will often have multiple accounts (such as across AD domains, or even within a single domain). In a mature and comprehensive reflection of this there would often be multiple user records in FlexNet Manager Suite (representing their multiple accounts) for the one person. There will also be accounts used on systems (and therefore user records in FlexNet Manager Suite and Active Directory) which do not directly map to a single unique person.
So on this basis, AD is typically used as a primary source for identifying users. Information from an HR database is often used to augment those records by setting additional properties on them, but HR databases do not typically provide a list of accounts that each person has.
Hope that makes sense!
‎May 14, 2020 06:14 PM
That is a great reply Chris.
Thank you very much for the clarity.
‎May 15, 2020 10:05 AM