There are three types of uses that can be created and used in UIM
1. Real Nimbus Users
2. Account Contact Users
3. LDAP Users
All these users can run in same security context though they are created and managed in different ways.
Release: CNMSPP99000-7.6-Unified Infrastructure Mgmt-Server Pack-- On Prem Component:
There are essentially two types of users: Real Nimbus Users and Account Contact users. LDAP users fall into one these two categories but are a little more fluid.
1. Real Nimbus Users are created in Infrastructure Manager, (IM), through Security->User Administration. These users are written to security.dta file in the hub folder and the NimsoftSLM database never sees these users, (so UMP cannot see them).
2. Account Contact Users are created in IM through Security->Account Administration, and also in UMP through the AccountAdmin portlet. These users are written to the NimsoftSLM database and IM can read ACLs written this way. When a user logs into UMP for the first time, their user account is copied to the separate Liferay tables. Also, Account Contact users cannot assign alarms to Real Nimbus users.
3. LDAP Users can be treated as Real Nimbus Users or Account Contact Users - it depends on which ACL they are given. If the ACL is Linked to an Account, then the LDAP user will be treated as an Account Contact (even if they're not a member of that account.) If the ACL they are given is not linked to any account, the LDAP user gets treated as a Real Nimbus User.
Some notes: - User information can be stored in four different places: - Nimsoft\hub\security.dta for real nimbus users. - NimsoftSLM > Account_, Group_ and User_ tables for account contact users. - NimsoftSLM Liferay tables for users who have successfully authenticated in UMP. - The completely separate Active Directory tables for LDAP users.
- Users who want to access UMP's SLM portlet or Dashboard Designer must be Real Nimbus Users, created in IM under Security->User Administration and have the 'SLM Admin' or 'Dashboard Designer' permission on their ACL. This is by design and is intended to prevent one customer from one account from being able to view data that belongs to a different account. Again, these users are created exclusively in IM through "User Administration".
- All usernames should be unique. Creating LDAP users, Real Nimbus Users, and/or Account Contact users with identical usernames will create confusion about which credentials are being used to authenticate in UMP.
- Something to note about the Liferay Accounts - if a User is deleted in UMP, they don't really get deleted. Their record in the Account_, Group_, and User_ tables gets updated with a "deleted = 1" flag. In order to truly delete these accounts the the rows in the database must be manually deleted. However, in most circumstances it's not necessary to do this, as the user's account will be updated with the latest information upon successful authentication
You could say ACLs are "one way". When you create an ACL in AccountAdmin (UMP or OC) they will show up in IM, but if you add ACLs in IM they won't show up in OC/UMP/AccountAdmin. This is ultimately by design.
When adding an ACL in AccountAdmin the ACL first goes into the database (e.g. CM_ACCOUNT_ACL) and then we also add it to security.cfg via a hub callback. But the other way around is not possible - when you add directly in IM the security.cfg gets updated but the database tables do not.
- users who are created directly in IM are "bus users" and they have access to all origins by default and are somewhat like "administrator" users as they can log into all systems and are not restricted by Origin; - therefore you don't usually need to create ACLs in IM as the "superuser" or administrator ACLs are usually given to those who will be accessing IM - but when you do create ACL's in IM, they stay in IM and are accessible only to "bus users" who have been created in IM. - non-admin or "Operator" users don't usually access IM and their accounts are usually created directly in AccountAdmin so you can limit their access to only certain origins; - Therefore the "account" users created in OC/AccountAdmin/UMP have their own set of ACLs to choose from which are not exactly the same ACLs as the ones in IM. They are in a sense "separate but equal".
So the best practice at this point would be to always create ACLs in AccountAdmin generally speaking. You want to have as few ACLs in IM as possible that don't exist in OC/AccountAdmin. New ACLs should mostly be created in AccountAdmin and the ones in IM like superuser/administrator can be used for your (limited number of) admin users that have access to everything.