OIM910 - Extend User Profile

OIM910 - Extend User Profile

It is obviously, you would need to extend user profile from time to time, so here is the steps to do it:

1) Define new field by using "User Defined Field Definition" in Design Console.
e.g.
Label Variant Type Length Column Name Order Field Type Propperties
Users.Suspension boolean 1 USR_UDF_SUSPENSION 22 CheckBox FALSE

2) Define lookup definition for new field
Code Field Lookup Type Group
Users.UDF.SUSPENSION USR_UDF_SUSPENSION Field Type Users

Code Key Decode
Account Suspension Account Suspension

3) Add new entry in xlWebAdmin.properties
global.label.accountsuspension=Account Suspension

4) Add new Attributes in FormMetaData.xml
<code>
<!-- List of attributes that can be displayed in the "User" Form -->
....
....
....
<Attribute name="-53" label="global.label.accountsuspension" displayComponentType="CheckBox" dataLength="1" map="Users.UDF.SUSPENSION" />

....
....
<!-- Fields that will be displayed on "user" form -->
<AttributeReference editable="true" optional="true"> -53</AttributeReference>
</code>

Restart OIM Server, You'lll see the newly added field "Account Suspension"

Drop All User's Objects in a Single Query

Recently, I needed to find a single command to drop all the tables from an Oracle database without explicitly naming each table and without dropping the entire schema.

One possible solution would be to login as SYS and drop the schema itself,
e.g.
------------------------------
sqlplus sys/syspwd

Drop user username cascade
------------------------------

However, I don't want to drop the whole schema, and I just want to drop all the tables, constaints, triggers, sequence, procedures, database links, packages, so I come out with the following sql:
----------------------------------------------------------------------------------
set heading off;
set feedback off;
spool c:\dropobj.sql;
prompt --Drop constraint
select 'alter table '||table_name||' drop constraint '||constraint_name||' ;' from user_constraints where constraint_type='R';
prompt --Drop tables
select 'drop table '||table_name ||';' from user_tables;

prompt --Drop view
select 'drop view ' ||view_name||';' from user_views;

prompt --Drop sequence
select 'drop sequence ' ||sequence_name||';' from user_sequences;

prompt --Drop function
select 'drop function ' ||object_name||';' from user_objects where object_type='FUNCTION';

prompt --Drop procedure
select 'drop procedure '||object_name||';' from user_objects where object_type='PROCEDURE';

prompt --Drop package
prompt --Drop package body
select 'drop package '|| object_name||';' from user_objects where object_type='PACKAGE';

prompt --Drop database link
select 'drop database link '|| object_name||';' from user_objects where object_type='DATABASE LINK';

spool off;
set heading on;
set feedback on;

@@c:\dropobj.sql;
host del c:\dropobj.sql;
----------------------------------------------------------------------------------

I save it as an SQL file in the name of "ClearUserAllObjects.sql", then I login as the user that I want to delete all objects from, then execute the sql file. e.g.

sqlplus targetUser/targetUserPwd
@c:\ClearUserAllObjects.sql

then a clearing objects process begins, wait until it is done.

OIM910 - Prevent Exchange Overwrite title and department in AD User

OIM910 - Prevent Exchange Overwrite title and department in AD User

If you are using OIM910 standard adapter for exchange, you might notice that after you provision a exchange account, it overwrites the title and department attributes of AD account, that is probably not what you want.

So how to solve this issue?

The cause of this issue is process task "Set Exchange Related Properties" of Exchange process, this task sets the organization name for department, and employee type(role) for title in AD.

Once we known the cause, then solve it become easy, actually I am thinking of two method:
1) Create a new Adapter call "MEXC Set User Properties Basic", then map it to a newly created process task called "Set Exchange Related Properties" in Process Exchange, then you have to do all the mapping stuff.
Note that: We need to remove variable department and title in new adpater.

2) Maping the right property for department and title
Note: Don't change the process adapter
Example:
a. department -> User Definition (Users.Department)
b. corporateTitle -> User Definition (Users.JobTitle)

3) Mapping Empty String for process task "Set Exchange Related Properties"
a. department -> Literal (A Empty String)
b. corporateTitle -> Literal (A Empty String)

OIM910: Can not get ObjectGUID during provisioining Exchange account

Can not get ObjectGUID during provisioining Exchange account

As you know, exchange stores its informatin in AD, and when OIM provision exchange account, it needs to get the object GUID of the corresponding AD account.

What OIM actually do are summarized as below:
1) Check AD User Process
If Check AD User Process succeed, then proceed to step 2.
2) Get ObjectGUID from Process
What Get ObjectGUID from Process do is to get the corresponding object GUID, and save
it to exchange table : UD_MSEXCHG, column: UD_MSEXCHG_OBJECTUID , meaning get the AD account's object GUID from AD process table: UD_ADUSER, then convert it to exchange process table.
3) Check ObjectGUID Set
This step checks whether the column UD_MSEXCHG_OBJECTUID got set or not in step 2, if got set then proceed to step 4.
4) Create Mailbox.

As what we have stated above, the most important part of provisoning exchange account is getting objectGUID from AD process, which is step 2, so we need to discuss more about step 2, actually, step 2 needs to know the user key and IT resource key as a parameter for the query below:
*****************************************************************************
select distinct UD_ADUSER.UD_ADUSER_OBJECTGUID from UD_ADUSER UD_ADUSER, orc orc ,sta sta where UD_ADUSER.orc_key=orc.orc_key and orc.usr_key=2662 and UD_ADUSER.UD_ADUSER_AD=161 and orc.orc_status=STA.sta_status AND STA.sta_bucket != 'Cancelled'

****************************************************************************
Parameters:
-----------------------------------------
a. 2662 is a user Key in USR table.
b. 161 is a IT Resource Key in table SVR.
Explain how the get param a and b
(1) For user key, get be actually get from ORC (process table), as ORC has user key column, beside UD_MSEXCHG table has ORC_KEY column as well, that how be get user key,
(2) For IT Resource key, this is very obviously, UD_MSEXCHG has a column of AD IT Resource, UD_MSEXCHG_ADSERVER.
-----------------------------------------
Result
-----------------------------------------
UD_ADUSER.UD_ADUSER_OBJECTGUID
87e1bf040c85ba49b3d57ce9b4c38ec8
-----------------------------------------


How to solving the problem stated as the title of this article
If you can not get object GUID from UD_ADUSER table, and you confirmed that the corresponding AD account record in UD_ADUSER table has objectGUID, then the problem probably is that you use different AD IT Resource for AD User and Exchange,
e.g. You use ADITResource_DEV for AD User, but ADITResource for Exchange, and the key for ADITResource_DEV is 161, but the key for ADITResource is 1,

AD User - ADITResource_DEV - 161
Exchange - ADITResource - 1

so when you create exchange account, you will be executing the SQL below:
select distinct UD_ADUSER.UD_ADUSER_OBJECTGUID from UD_ADUSER UD_ADUSER, orc orc ,sta sta where UD_ADUSER.orc_key=orc.orc_key and orc.usr_key=2662 and UD_ADUSER.UD_ADUSER_AD=1 and orc.orc_status=STA.sta_status AND STA.sta_bucket != 'Cancelled'

Then you won't get any result, because corresponding AD User account in UD_ADUSER table has a key of ITResource key (UD_ADUSER.UD_ADUSER_AD) equals to 161, not 1 , that's the reason why you get not get object GUID from AD USER Table.

About Auto Save in OIM

About Auto Save in OIM

1. Make Resource Object Auto Save, if you don't want user's intervention with Object

form.

Note: Make sure object form has no mandatory fields, otherwise, you will not be able
to make resource object Auto-Saved.


2. Make Process ( normally provisioning process) Auto Save, if you don't user
to modify process form.

3. Make a Access Policy with approval, Add tcCompleteTask for "Awaiting Object Data"

process task, Add tcCompleteTask for process task "Approve".

once the policy is made, the approval process for the resource of that policy starts,

If User did not set Resource Object to Auto Save, then the approver will
not be able to see the "request". So set Object to Auto-Save.


4. Besides setting Object to Auto Save, we also need to make sure all the compulsory

field of that Object form has prepopulated or default value, So that
Approver will be able to See the "Request".
******** Actually, If the object form got compulsory field, then It can not be
Auto-saved.


5. If did above items correctly, the approver will be able to receive the requst,
and modify the object form, then approve or deny that request.




6. About Process Form Auto-Save.
If you have mandatory (required) field in your form, and you want your form to be
auto-saved, you must ensure that all the mandatory field either has prepopulated

value or default value.

e.g.

You have a process named "Exchange Request", and you have an process form associated
with it, called "UD_EXCHG", and this process form has a mandatory field call "Email
Alias".

In this case, if you want to make process "Exchange Request" Auto-saved, you must
either prepopulate value or using default value, so that the Auto-Save check box
on process "Exchange Request" is functioning correctly.

In conclusion, If you prepopulate value or set default value for process value, then
The Auto-Save feature of process works perfectly.


7. About Object Form Auto-Save.
If the object form got compulsory field, then It can not be Auto-saved.

In order to prove it, I made a test:

I got one compulsory field, and I set default value for it, then I make the resource
object auto-saved, However, It turned out the request resource process took me to
the object form -------------- Weird!!!!!!

e.g.
You have a Object named "Exchange Request", and you have an object form associated
with it, called "UD_EXCH_OB", and this obect form has a mandatory field call "Email
Alias".

So If you want to make this object "Exchange Request" auto-saved, you'd better make

all the form not compulsory!!!, meaning make "Email Alias" a normal non-compulsory '
field.

*********
Note that:

If the Object Form got "password" field, even you can make the auto-save works, you
will never get pass the submit request, ---- a every strange exception will be
thrown, saying that you could not save the request, and you can get any database
connections ---------------------------

***********
Solution for password synchronization.
You want to synchronize password between OIM and target resource, and you also want
to make object form auto-saved, the only way to do is to following the precedure

below:


1) Remote Password Field from Process Data Flow Mapping.
2) Remove Password Field and its "prepops" from Object Form.
3) Add Password Prepop for the corresponding Process Form.(push data from user

definition)


In This way, User OIM password could be successfully synchronize to target resource.

Note: please make sure object form has no compulsory field, otherwise, you won't be
able to auto-save object form during request.

OIM Service Account vs Normal Account

OIM Service Account vs Normal Account

1. Service Account
Events:
Service Account Alert
Service Account Changed
Service Account Moved


2. Normal Account
Triggers:
Lookup.USR_PROCESS_TRIGGERS

We can configure trigger for normal account, so that resource profile
shall be changed upon OIM profile changed.

e.g.
Code Decoded
USR_PASSWORD - Change User Password

We add "Change User Password" as a process task name to process definition,
once USR_PASSWORD is changed in OIM Account, the process task:
Change User Password shalled be triggerd to run!



3. Differences:
the trigger: Lookup.USR_PROCESS_TRIGGERS has no effects to Service Account!
and
the Service Account Event won't be triggered for normal account.



4. More Explain on Service Account Event:
Service Account Alert - Triggered when target service account's Owner's OIM
account is disabled or deleted.

Service Account Changed - Triggered when service account Changed,
e.g. From Regular Account To Service Account, or From Service Account To Regular
Account.

Service Account Moved - Triggered when service account's owner is changed.

5. Use Service Account Event to Update Target Resource ProfileThis is an example:
a). We defined process task "Change Description" in service account provisioning process. This task changes the process data "Description"

b). We defined process task "Change Group Owner ID", This Task changes the process
data "Group Owner ID".

c). We configured "Service Account Alert" in that process.

d). we set "Tasks to Generate" of "Change Description" and "Change Group Owner ID"
for response "true" of process task : "Service Account Alert", so that the tasks that
we defined in step a and b will be triggered once "Sercie Account Alert" task is
completed, meaning right after service account ownership is tranfered.

e). then we disable User OIM account, the "Service Account Alert" task will be
triggered, after that "Change Description" and "Change Group Owner ID" runs after
because the owner has been changed.

OIM910 - Process Event

Reconciliation Events
Reconciliation Insert Received
Reconciliation Update Received
Reconciliation Delete Received

Service Account Alert
Service Account Alert
Service Account Changed
Service Account Moved

Field Updated Event
Use "Field Label Name + Updated" as the process task name so that this process task will become an field updated event, meaning if we update that Field, this process task will be called. e.g. We have Label "Group Name" in Process From "UD_ADGRP", if we create a process task in "AD Group" (Process Name), called "Group Name Updated", it will be triggering by Group Name field update event.

Enable and Disble Event
When we create process task we can assign the Task Effect as "Disable Process or Access to Appiction" or "Enable Process or Access to Application".
"Disable Process or Access to Appiction" triggers by Disable button of Resource Profile page and User Detail page.
"Disable Process or Access to Appiction" triggers by Disable button of Resource Profile page and User Detail page.

So If user click either of button, the corresponding event will be triggered.


More Explain on Service Account Event:
Service Account Alert - Triggered when target service account's Owner's OIM
account is disabled or deleted.

Service Account Changed - Triggered when service account's owner is changed.


Service Account Moved -

OIM910 - How to use lookup query

The example I am taking here is to have a lookup from a custom table "access_table" containing three

columns access_id, descritption and groupname (this is the column stating which group has access to which

switch)

Steps to follow:

1. Mandatory properties to specify are :
a) Lookup Query e.g.
select distinct a.access_id, a.description from access_table a, usg b, ugp c, usr d where c.ugp_name =

a.group_name and b.ugp_key = c.ugp_key and b.usr_key = d.usr_key and d.usr_status ='Active' and d.USR_LOGIN

= '$Requester Information.User Login$'

b) Column captions e.g. Access ID, Description
This will ensure that in the lookup table displayed in UI will have two columns Access Id and description.

c)Columns names e.g. ACCESS_ID,DESCRIPTION, these are the columns specified in the select query.
ACCESS_ID AND DESCRIPTION must have its own lookup code, otherwise it can not be inserted as
columns names, so let's say ACCESS_ID AND DESCRIPTION have their lookup code shown below:

code : Users.UDF.Access_id
field: ACCESS_ID
lookup type: field type

code: Users.UDF.DESCRIPTION
field: DESCRIPTION
lookup type: field type



In order to make the lookup query work, we need to the corresponding lookup filed in

"xlWebAdmin.properties",
otherwise, the pop-up window(lookup window) will not show captions and values!
===================================================================================
lookupfield.header.users.udf.access_id=Access ID
lookupfield.header.users.udf.description=Description
===================================================================================

Noted the captions have been converted to LOWER CASE and BLANK SPACE has been repaced with "-". Put in

section "LOOKUPFIELD column headers".

The LOOKUP FILED HEADER IS BASED ON LOOKUP CODE! NOT THE COLUMN NAME.


d) Lookup column name e.g. ACCESS_ID, this is the column that is put in the textfield associated with

lookup field.

e) Column widths e.g. 25,100 This is the column width in table