ODSEE Upgrade from 11.1.1.3.0 to 11.1.1.7.0

So below are the steps we followed for upgrading our existing ODSEE set-up to the latest 11.1.1.7.0 .

1. Find out the patch for the version you wanna upgrade to (in this case Patch: 29893742)
2. Take complete backups of the dsee7 folders.(preferably using tar -cvf or tar -cvzf test.tar.gz).
3. keep the ODSEE installation owner credentials ready with you .
4. Patch the server which hosts the Directory Server Control Center before you patch any other servers. (often the admin server)

Once the basics are done, and you've already downloaded the patch file from Oracle site  : 

5. check the odsee instances informations with the below command :  
$ install-path/bin/dsadm info instance-name
6. check the current version of the ODSEE  : 
$ install-path/bin/dsadm -V
7.Be sure the Directory Server and Directory Proxy Server instances you are patching are started before running the dsccsetup prepare-patch command.
You can use ps -ef | grep slapd command for it

Run the following command : 
# install-path/bin/dsccsetup prepare-patch

what this does is, it attempts to stop all the instances at one go by running the below command for each, if it fails for any reason, it warns you and you've to manually stop the instances with  :
# install-path/bin/dsadm stop instance-path

8. Next steps would be to completely unzip the patch-set binaries to the current installation :

# unzip -q p29893742_111170_.zip
# gunzip -c dsee.11.1.1.7.190716..full.zip.tar.gz | tar -xf -

# unzip -q sun-dsee7.zip -d install-path
# cd install-path/dsee7                             
This step effectively overwrites the existing installation, by this I mean it only overwrites the existing binaries that oracle provided for the ODSEE, and existing in the patch AND in the install-path both , should be overwritten.

No subfolder , or instance-homes you may have created under dsee7 folder, won't be affected. 

9. Run the follwoing command to complete the patching:
# install-path/bin/dsccsetup complete-patch

Notice if it outputs upgrading the instances , if not run the following commands separatetly : 

To patch all Directory Server instances that were not patched , run the following command:
# install-path/bin/dsadm upgrade -i install-path
To patch all Directory Proxy Server instances that were not patched , run the following command:
# install-path/bin/dsadm upgrade -i install-path

10. If you are patching the server that hosts Directory Service Control Center , redeploy the Directory Service Control Center (DSCC) WAR file, install-path/dsee7/var/dscc7.war to /root/weblogic-deploy-base/dscc(check the path from wlst console under deployment for dscc, it may not be same for your environment ).

Recreate the war file by running the following command :
# install-path/bin/dsccsetup war-file-delete
# install-path/bin/dsccsetup war-file-create

To Deploy the DSCC WAR File With Oracle WebLogic Server

10.a - Browse the WebLogic console using http://localhost:7001/console.
10.b - Navigate to base_domain/Deployments in the Domain Structure panel.
10.c - Click Lock and Edit.
10.d - Click Install.
10.e - Click Upload your file(s).
10.f - In Deployment Archive, select install-path/var/dscc7.war and click Next.
10.g - Select dscc7.war and click Next.
10.h - Select Install this deployment as an application and click Next.
10.i - Provide a Name for the deployment, accept the default Optional Settings and click Finish.
10.j - Click Activate Changes in the top left corner. The dscc7 deployment must be in the active state.

Use http://hostname:port/dscc7 to connect to DSCC.
The default port number for Oracle WebLogic Server is 7001.

IF the dscc app is not on 'Active' stage after step 10.j above, and on 'prepared' stage, do the following  : 

https://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/wls/12c/03-DeployApps/deployapps.htm 

Select the check box to the left of the application in the Deployments table. Then use the Start drop-down list to select Servicing all requests. 
Click Yes to continue. 
A message is displayed indicating a start request was sent. Momentarily you will see the State of the application become "Active." 

at last, check the versions again by running  : 

$ install-path/bin/dsadm -V

dsadm              : 11.1.1.7.190716      B2019.0627.0913 ZIP

Copyright (c) 2013, Oracle and/or its affiliates. All rights reserved.
[slapd 64-bit]
Oracle Corporation.
Sun-Directory-Server/11.1.1.7.190716 B2019.0627.0913 64-bit
ns-slapd            : 11.1.1.7.190716      B2019.0627.0913 ZIP
Slapd Library       : 11.1.1.7.190716      B2019.0627.0913
Front-End Library   : 11.1.1.7.190716      B2019.0627.0913


As Always, thanks for reading ! 

ORAPKI commands, oracle wallets ,OHS certificate import export update

This summary is not available. Please click here to view the post.

Install locate command in Linux

'locate' is quite a familiar command to many of you guys to find a directory or file quickly in a linux server, and many of the set-ups would already have it installed. 

Just in case this is not available and you get a error like below, here're my findings to help you install it on your own  : 

1.Find out what linux are you using :

uname -a
lsb_release -d | awk -F"\t" '{print $2}'

In my case, it's SUSE Linux

2. If the linux platform is Ubuntu , run the below commands : 

sudo apt-get update
sudo apt-get install mlocate

The locate command builds a databse to keep a tab on all the server entries. Run this command as root user with the sudo command, otherwise you will get an error. The default database storage location is /var/lib/mlocate/mlocate.db.

sudo updatedb

you can also run this once  a month to keep the locate db updated with new file entries in server.

3. If the linux platform is CentOS,run the below commands: 

sudo yum -y update

sudo yum -y install mlocate

and create the db  :  

sudo updatedb

4. If the linux platform is SUSE,run the below commands: 

The glibc development files are in the package "glibc-devel" on openSUSE, which you could install by typing:
sudo zypper in glibc-devel 

sudo zypper in findutils-locate
sudo updatedb

Here're my outputs from the server  : 

user@server:/> sudo zypper in glibc-devel

Refreshing service 'spacewalk'.

Loading repository data...

Reading installed packages...

Resolving package dependencies...

The following package is going to be upgraded:

  glibc-devel

1 package to upgrade.

Overall download size: 4.9 MiB. After the operation, additional 264.0 KiB will be used.

Continue? [y/n/?] (y): y

Retrieving package glibc-devel-2.11.3-17.84.1.x86_64 (1/1), 4.9 MiB (31.2 MiB unpacked)

Retrieving: glibc-devel-2.11.3-17.84.1.x86_64.rpm [done]

Installing: glibc-devel-2.11.3-17.84.1 [done]

user@server:/> sudo zypper in findutils-locate

Refreshing service 'spacewalk'.

Loading repository data...

Reading installed packages...

Resolving package dependencies...

The following NEW package is going to be installed:

findutils-locate

1 new package to install.

Overall download size: 57.0 KiB. After the operation, additional 140.0 KiB will be used.

Continue? [y/n/?] (y): y

Retrieving package findutils-locate-4.4.0-38.26.1.x86_64 (1/1), 57.0 KiB (140.0 KiB unpacked)

Retrieving: findutils-locate-4.4.0-38.26.1.x86_64.rpm [done]

Installing: findutils-locate-4.4.0-38.26.1 [done]

Additional rpm output:

Updating etc/sysconfig/locate...

user@server:/> sudo updatedb

As always, thanks for reading ! 

"Request Account" button is disabled under the "Manage Accounts" section

Since Sailopint mostly encourages RBAC through IT roles, Business roles, Org roles, populations and groups, assigning just an application account is not so practiced.
However, there is and will be needs of just account provisioning and in such cases you may come to find out the 'Request Account' button deactivated. 

To activate it  - 

Open Global settings -> Quicklink population -> "Self Service" Menu -> "Quicklinks" Tab
Open "Configure" section of "Manage Accounts".
Check "Allow requesting new accounts" and click on save.

Also, make sure that the applications (all or a few selected) should be marked and selected under the "Applications that support account only requests" in the Lifecycle Manager -> Configure setting.

The same changes in the settings needs to be followed in case of allowing multiple accounts for a single application / resource. 

Cheers  ! 

Sailpoint IIQ Dropdown / LOV functionality with Key-Value pair

It was surprising to find out that Sailpoint do not provide a key-value pair / code-decode LOV/Dropdown functionality OOTB till IIQ 7.2 (Please feel free to differ as I literally have 24 hrs of experience with the tool at the moment, however I did research the community and it seems it's an issue a lot of people are facing).
Sure you can use the 'Allowed Values' functionality with the actual 'Value' , but that does not solve the problem of showing 'key' or 'decode' values in the front end.

So without further ado, here's how we can achieve it (taking Salesforce Profile IDs for example ) -

Prob - I need to show 'System Administrator' to the user in the application account request form , while sending '00e2v000002Xj74AAC' to the target (Salesforce in this case).

Solution :

STEP 1. Create a custom object which holds this Key-Value pairs of a dropdown, you can add multiple dropdown values in the same custom object by storing the Map in the value, and specifying a unique Key for each Map value -

Go to "Debug" page  -> Find Custom objects -> Click on 'New' -> Paste your custom object and save.

<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Custom PUBLIC "sailpoint.dtd" "sailpoint.dtd"> <custom name="List of Values"> <attributes> <map> <entry key="getProfileCode"> <value> <map> <entry key="System Administrator" value="00e2v000002Xj74AAC"/> <entry key="Chatter Free User" value="00e2v000002Xj75AAC"/> <entry key="Read Only" value="00e2v000002Xj7aAAC"/> <entry key="Standard User" value="00e2v000002Xj7gAAC"/> </Map> </value> </entry> </Map> </Attributes> </Custom>

STEP 2. Create a 'Allowed Value' rule for returning the key set of the mentioned custom object from debug page -

<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd"> <rule language="beanshell" name="SF Profile values" type="AllowedValues"> <source> import java.util.List; import java.util.Map; import sailpoint.object.Custom; List orgList=null; Custom custom=context.getObjectByName(Custom.class,"List of Values"); if(custom!=null) { Map orgMap=custom.get("getProfileCode"); orgList = new ArrayList(orgMap.keySet()); } return orgList; </Source> </Rule>

STEP 3. go to your application definition -> Configuration -> Provisioning Policy -> Create Policy ->Edit the dropdown attribute -> Select 'Rule' under 'Allowed Value' section, and select the rule you created in last section. (alternatively, you can use 'Script' )

So now, you have your desired user-friendly list of values showing in the dropdown , however, you need to change those Key/Decode/Front end values to the value/code/backend values before actually pushing the user account data in the target.


Hence, STEP 4 - Create / Add to an existing 'Before Provisioning Rule' for the data modification  :
Application definition -> Rules -> Before Provisioning Rule -> Select the rule

<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd"> <rule language="beanshell" name="SF Profile values decode beforeProv" type="BeforeProvisioning "> <source> import sailpoint.object.*; import sailpoint.tools.*; import sailpoint.object.ProvisioningPlan; import sailpoint.object.ProvisioningPlan.AccountRequest; import sailpoint.object.ProvisioningPlan.AttributeRequest; import sailpoint.object.ProvisioningPlan.Operation; import java.util.List; import java.util.Map; import sailpoint.object.Custom; AccountRequest acctReq = plan.getAccountRequest("Demo Salesforce integration"); List attributeRequests = acctReq.getAttributeRequests(); List orgList=null; String valueCode = ""; Custom custom=context.getObjectByName(Custom.class,"List of Values"); Map orgMap=custom.get("getProfileCode"); if ( attributeRequests != null ) { for ( AttributeRequest req : attributeRequests ) { String name = req.getName(); if ( name != null && name.compareTo("ProfileId") == 0 ) { if(orgMap.containsKey(req.getValue())) { req.setValue(orgMap.get(value)); } } } } </Source> </Rule>

and voila ! you can now leverage the LOV/Dropdown functionality with key-value pairs.

Also, alternatively you can add an additional step in the workflow to achieve this data modification.

Thanks for reading !