OIA only displays 500 records in the Identity Warehouse user list regardless of how many exist. One project i worked on had 70,000+ users in OIA. This isn't really a problem, because there seems to be little need to display all the users in the ID warehouse at once.
At least that's what I thought until I saw the same behavior on other OIA screens. For example, I needed to add 11,000 users to a role, but OIA only allows me to add a distinct set of 500. I can't choose the others after adding the first 500. OIA displays a distinct set of 500 users no matter what you do. Strangely, the set it presents includes a sample of users through out the alphabet. That is, it includes some users from A to Z. So I've got "aadams" through "zvincent". This is puzzling.
I found a setting in the config files that may affect this behavior in the idw-context.xml config file.
I changed it to 5000 and restarted OIA. The result is that my 2880 user records showed up in the Identity Warehouse user search screens instead of the usual 500 users.
This post describes how to link an OIA global user to a business structure (or business unit as it's also known in OIA or even BU).
The most obvious way to link users to BUs is to display the BU in the Identity Warehouse and add users through the Users tab.
But that's not very efficient, especially when you have to add hundreds or thousands of users to the BU.
In those cases, use a BU rule. After creating the rule, you'll need to run the rule.
1. Display the BU in the Identity Warehouse (Identity Warehouse>Business Structures).
2. Click the Rules link located below the tabs.
3. Click New Rule.
4. Follow the wizard steps. The important screen is Add Conditions where you will specify what the rule is applied to. For example, you can specify the following:
Attribute: Primary Email
5. Select which business structure the user will be assigned to if the condition is met, on the Select Business Structure screen.
6. Save the rule.
7. Run the rule now.
It may take a few minutes depending on how many records are involved. The rule will add all users who have "acme.com", in this example, in their email address to the selected business structure.
To validate, look up some of the users you know the rule should apply to. Their global record details should show they are part of the new business structure and the business structure should show they are members.
When I started working with OIA, I wondered how we would add OIA admin accounts for all the managers and data owners who were going to conduct Identity Certifications. We had hundreds on one project. That sounded like lots of work.
Little did I know OIA is built to automatically create the OIA admin user accounts for those managers/data owners.
Here's how it works.
1. The managers who will conduct certifications must be OIA global users.
2. Create an identity certification.
3. OIA automatically creates the OIA admin account with certification privileges in the background. It even provides them with a unique password.
4. When the manager accesses OIA to conduct the identity certification, the OIA admin account is ready for them.
Here are a few pointers to help:
1. Configure the OIA Access Control settings to force a password change on first login.
2. Change how the new password is configured using the following property located in ../rbacx/WEB-INF/security-config-context.xml :
The comments located above the property should help you configure the password differently if you need to.
When you import resource accounts from a file that have no corresponding OIA global user, the imported account is an orphan.
By default, OIA creates a report listing the orphaned accounts and does not import those orphaned accounts.
To see if any orphaned accounts exist as a result of an import, go to Adminstration>Import/Export Logs>View Details for the import. Then click the Show Exceptions button. You can export the exceptions also using the Export button. These are OIA CORRELATION ERRORs.
Orphaned accounts can also occur when an OIA global user is deleted and the resource account remain in OIA. These orphaned accounts can be found by choosing Identity Warehouse>Users>Orphaned Accounts. This screen lets you assign the orphaned account to an existing OIA global user if necessary.
Alternatively, OIA can handle orphaned accounts (those with correlation errors) found during imports differently using the following property located in the iam.properties file (../oia/conf/iam.properties): # CORRELATION PARAMETERS # dropOrphanAccounts=true => accounts not correlated are not imported # dropOrphanAccounts=false => accounts not correlated are imported com.vaau.rbacx.iam.correlation.dropOrphanAccounts=true
Set .dropOrphanAccounts to false and restart OIA.
This change causes OIA to import the account with “correlation errors” into the resource account. This account shows up in the Users>Orphaned Accountsscreen and is listed under the resource.
The orphaned accounts are still included in the import exception file. This provides a means to report on the orphans, but it would be nice to find a cleaner way to deliver the orphaned account results to an application support person. If you know of a better way, let me know.
A coworker recently pointed out that single-sign on systems, once installed, are as important as any other piece of infrastructure. That's because if the SSO system goes down, users can't get to applications. In that respect, SSO is as important as a database or network.
This point is probably obvious to many people, but it's important to keep in mind.
I have found the following file system types among my drives:
1. NTFS (used on portable hard drives and I have Tuxera installed on my Mac to read this FS). I believe that without Tuxera, my Mac could not read NTFS.
2. FAT 16 MSDOS (used on an old USB flash drive). My Mac can read this and the info dialog does not mention the use of Tuxera. I believe this indicates my Mac natively reads FAT16.
3. Mac OS Extended (Journaled). This is used by my Mac's internal hard drive. I'm not sure what Journaled means.
This leads to the reason behind my interest in file systems. My Linux VM won't read my portable hard drives that use NTFS. I need to transfer a file that is so large it requires a device like one of my portalbe hard drives.
I wonder if a solution exists that allows the Linux system to read NTFS? I'll look into that.