FNMS Cloud integration with Active Directory | Business Adapter
Hello Dear Community,
We plan on implementing FNMS Cloud inegrated with Active directory for allowing FNMS to be able to capture user data updates on a daily basis.
I wanted a road map or the steps that needs to be dealt with to establish this requirement.
I have gone through the forums and there has been information on the Active Directory component on the Flexnet beacon application under the data collection tab. Any links to concrete information would be greatly appreciated!
How will the process be like - to constantly update the fields on the users page in the FNMS UI through this integration work like - I would appreciate a lot if I got a road map to work with this requirement that I have.
This thread has been automatically locked due to inactivity.
To continue the discussion, please start a new thread.
Both for FNMS Cloud as well as for the FNMS on-prem software, you would:
- Use the Active Directory (AD) data import feature integrated into the FNMS Beacon and/or
- Configure a custom Business Adapter (MGSBI) for importing or augmenting the AD information
The AD data import feature provided with the FNMS Beacon is kind of limited.
For AD users, it generally imports the "Full name"", Account name" and "Domain name" user attributes only.
For importing additional user properties like "First name", Last name" or "Email",
a Business Adapter (MGSBI) needs to be configured.
The best documentation on Business Adapters probably is the "Business Adapter Practice Guide" available
for download in the "Learning Center" under "FlexNet Manager Implementation and Administration".
While the release 4.0 that is available for download currently has a lot of good information,
the previous release 2.0 of this document did contain additional documentation specifically on
importing data from a Directory Services (Active Directory or LDAP) data source.
Check out page #16-17 in the attached "Business Adapter Guide 2.0" document for further information.
@erwinlindemann Thank you soo much for the information shared here - this is immense! I did have the 4.0 v of the document. I appreciate the 2.0 shared here.
I will go through the document and focus on implementing the same in our UAT environment for FNMS Cloud.
I will keep the forums updated on how this goes.
@erwinlindemann Hi There,
Right now everything seems promising with the staging adapter and business adapter set up.
The problem is that the staging adapter brings in only limited rows from the ldap path specified in the xml script for staging into FNMSStaging.
Could you please let me know if I am doing any thing wrong? I have attached the XML for your reference.
Your config file looks good .
The only thing that I noticed in your XML config file is that the ServerTimeLimit is set to "0". According to the documentation, a value of "-1" (which is the default value) means that the server will wait for up to 120 seconds for an entire search. You may want to try the default value.
Also, perhaps try ClientTimeout="-1" instead of ClientTimeout="7200". Although, 7200 seconds (2 hours) clearly should be enough.
I have now implemented the Active directory adapter - however, The number of rows read from source is 339,035
but the Flexera created 338,993 - a difference of 42 records.
I have attached a snapshot. Could you please help share me your thoughts on how to identify these 42 records . These 42 don't show up as rejected records as well.
Thank you for all the assistance that was given here - it certainly made us celebrate!
The reason why you are getting more users from the MGSBI Active Directory adapter compared to the standard Active Director (AD) interface most likely is the 'User Blacklist' used for filtering users in the standard AD interface.
You can see the list of black-listed user names in the FNMS Web UI under "(cogs) > System Settings > Users". This list contains account names available on any Windows computer, like 'Administrator' and 'Guest'. The list also contains generic accounts using the percent sign ('%') as a wildcard. You don't want these standard accounts to be counted as real users.
In case you want to check the list of AD users imported by your Business Adapter for Windows accounts to be filtered, you can run the following SQL statement on the staging table where you store users:
FROM [ComplianceUser] cu
LEFT JOIN [ComplianceDomain] cd ON cd.ComplianceDomainID = cu.ComplianceDomainID
FROM [UserNameBlacklist] unb
WHERE cu.SAMAccountName LIKE unb.UserName
OR (cd.FlatName IS NOT NULL
AND (cd.FlatName + '\' + cu.SAMAccountName LIKE unb.UserName))
This statement assumes that you did import the users into tables named [ComplianceUser] and [ComplianceDomain] built like the original tables in the [FNMSCompliance] database, and that you have the black-listed users stored in a column [UserName] in a table named [UserNameBlacklist].
A quick word of warning: Be careful when replacing the FNMS standard Active Director (AD) interface by a Business Importer. The import process (compliance reader) relies on the standard [FNMSInventory].[ADUser] table being populated by the Active Director (AD) interface. Any users not found in the standard user table will be deleted from the users visible in the FNMS Web UI (stored in the [FNMSCompliance].[ComplianceUser] table) when running a compliance import.
Customizing the SQL code used in the compliance import (READERs and WRITERs) might be an option when working in an FNMS on-premises environment. You don't have that option when working in the Cloud.
The best practice approach for populating user data in FNMS would be:
- Use the standard Active Director (AD) interface for importing users from AD. This interface will import the "Full name"", Account name" and "Domain name" user properties only.
- Use a Business Adapter for augmenting the user information imported from AD with additional user properties, like "First Name", "Last Name" and "Email".
IT Software Asset Manager, Lead Sr.