Inventory Adapter for User Data

[rwiltshire]

Hello,

Does anyone have a reference inventory adapter to import just users? 

I am looking to import HR data to compliment the AD data and prevent HR account users being deleted automatically when removed from AD.  From the docs, it looks like the AD remove will not happen if the user exists in another import set. The goal is to provide more control over which users are removed and when by the AD import.

[mfranz]

Some general comments:

• I think you're right in that if the user existed from another inventory source, it would ne be deleted, when removed from AD.
• However, I think an Inventory Adapter might not be the best choice, due to it's inherent limitation in data fields. Inventory Adapters will have to use the "ImportedUser" table, at least as long as they stick to the standard Reader/Writer approach.
• Instead, I would suggest going with a Business Import (Business Adapter Studio) and ignore the Beacon-based AD import altogether. The BAS allows setting of so much more data 

Typical things in Business Imports that the default method does not cover, would be:

• Properly filtering for natural persons, ignoring admin,  service, technical accounts, etc.
• Implementing your own data lifecycle with Create, Update and Delete, including status (see AD field useraccountcontrol for disabled accounts)
• Use non-standard fields in your AD (obviously customer-specific), e. g. to assign location, business unit, cost center, etc.
• Creating non-standard user names, like "First Last (Department)"
• Link managers
• Fill in custom fields

Please keep in mind that for some use cases the user import through Beacon is mandatory, e. g.  for some Citrix stuff the user SID is needed.

Of course, you can always establish a hybrid approach, with the Beacon standard user import and additional Business Import for more details. Another idea would be to disable or change the "Delete" step in the ManageSoft reader to match your needs (see "User.xml" in "C:\ProgramData\Flexera Software\Compliance\ImportProcedures\Inventory\Reader\ManageSoft", import step "InsertUpdateUsers").

It's difficult to provide a template, because AD is usually quite customer specific. A standalone Beacon will come with a BAS that has templates for most objects. The BAS documentation is also worth a look (in case you're not familiar) https://docs.flexera.com/FlexNetManagerSuite2024R1/EN/BusnAdap/index.html

[dbeckner]

Great answer @mfranz!

[rwiltshire]

Very detailed response thank you!

I top up the AD import today with a business adapter using data from our HR Systems. This works great until a user is disabled in AD then disappears from Flexera. This is the desired state for all non real user accounts but does add a hiccup for hr users in the off boarding process. 

I did think about disabling the out of the box AD adapter. However, it is not clear what impact that may have on other aspects of Flexera and compliance reporting. We are not using the Site or subnet data but the AD adapter also imports User Groups and other info. I am not sure how important that info actual is for Flexera to function.

[mfranz]

You have to check how the AD data (including groups and stuff) is currently used and then work through the use cases and define alternatives (e.g. based on Business Imports). If it's just about the users, I see these options:

1. Get rid of the AD integration and data and manage users yourself

FNMS does identify the gap between ImportedUser_MT and ComplianceUser_MT with ComplianceUserConnection_MT. The moment you "cut" that connection the system will not be able to remove the user. That means if you wanted to get rid of your out-of-the-box adapter and data and keep your existing users, you would need to clear:

• ImportedUser_MT
• ComplianceUserConnection_MT
• plus any of the actual "external" source tables, like FNMSInventory.dbo.ADUser and others
• and you would need to disable the actual AD import(s) in the Beacon.

The biggest values here would be:

• avoid importing non-personal accounts in the first place, by filtering your data
• have a clearly defined lifecycle for the user object (including status and deletion) based on multiple AD attributes

2. Change/disable the removal logic and handle that part yourself

If you feel that some data from the default AD integration might still be important (*), you can stick with it, disable the removal logic. Keep in mind that:

• you will need to implement your own removal logic
• whatever is still in the source data set will be re-imported daily, so this is not really an option to clean up unwanted data from AD

* AD-Group-based license assignment could be one reason.