Asset Management Suite

To determine what software is available and published for a user who is accessing the Software Portal, you must determine what user groups the user is a part of. This can be done either directly or indirectly through other groups. The analysis of relationships between groups within domains and between domains is determined. The result of the analysis is a set of SIDs (Security IDs).

The user only has access to the software that is published to at least one of the groups that the user is a member of. I.e. has at least one publishing item with SIDs of a set, obtained by analysing Parent user groups . Parent user group analysis is held solely by means of .NET.
.NET API is used for interfacing with the Active Directory service.

Algorithm for User Memberships

The following algorithm is used in the analysis for user memberships.

1. Obtain the directory entry of the user accessing the Software Portal.
2. If it is a local user, then analyse only the local context . For .NET API this means that we are using the name of the local machine for corresponding LDAP queries. The machine name is taken from the user context that is filled with LOGIN to the Software Portal.
3. If it is a domain user, we must first analyse its domain relations (including relations between multiple domains) and then analyse its local context (case 2) because the domain user can also be in local group (a member of local groups).
   • Analyse relations between groups means that we obtain a SID for every group that current user belongs to.
4. Parent groups search is a recursive process. First it looks for groups that the user belongs directly to, and then for each matched group it looks for groups that include this group, etc. For optimization and to prevent the analysis of cyclic dependencies, the process remembers previously found analysed groups and does not analyse them again.
5. To find the Parent groups LDAP queries are used. For example, "Select all the groups that have such user”.
6. LDAP queries are executed within a single domain.
7. There can be trusted relationships between domains. This means that groups of one domain may be Parent groups in other domain, and if this is so trusted Domain group’s analysis is required.
   • First analyse if domain is the user’s domain.
   • After user relations analysis within a domain, search for all domains that have trusted relations with the current user’s domain.
   • NOTE: Only the domains allowed via the UI are evaluated, otherwise non-allowed domains are ignored during this process
8. Relations between groups which are found in trusted domains are also analysed.
9. Trusted domain analysis is a recursive process. For optimization and to prevent the analysis of cyclic dependencies, the process remembers previously found analysed groups and does not analyse them again.
10. Analysis process ends when all domains and groups within domains are discovered and all SIDs are obtained.
11. Using the SIDs gathered all published Software, whether Approved or Require Approval, is checked to see if the user possesses a SID for that software, and will publish it accordingly.
12. The process is complete when all software is loaded into the Software Portal and user begins interaction.

Additional Notes

Since the analysis of all the trusted domains is a very intensive operation, there is now the option to switch off the trusted domains check in the Software Portal settings page.

There is now also the option for you to check some of the trusted domains after this check has been switched off. You can add specific domains to a list via the registry in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Altiris\SWM by creating there multistring “includeDomainList”.

NOTE: The domain names in the list should be in FQDN and NetBIOS (short) format. This is to avoid FQDN resolving during the publishing or Software Portal configuration.