Protecting users and their emails after FA-P2T in On-Prem Environments

Introduction

The P2T – Prodution to Test – procedure is a very popular feature that FA customers utilize. It allows them to have their production data copied to another environment. Nowadays, P2T is a very common cloud SAAS and on-premise procedure. An important aspect that is not discussed frequently is the post-process of P2T. This approach is very important to avoid security issues, such as production passwords and emails being available in a different environment.

Main Article

This article will cover the post-process of FA-P2T and changing information that comes from production that is unwanted in the test environment. For this blog, our specific test case is email’s attribute. Note: There isn’t a requirement to change this specific attribute, but if they are not changed, then you may inadvertently send notifications from a non-production environment to valid, production email addresses. This may cause confusion and frustration from some users trying to identify what environment these e-mails are coming from. Hence, this article provides step-by-step instructions to accomplish the change e-mail task making sure your end-user’s email will not be available on lower environments.

NOTE: ALL THESE STEPS HAVE TO BE DONE ONLY IN THE TEST ENVIRONMENT

Step 1: FROM OID SIDE
1.1)Do a backup first:

/u01/oid/oid_home/ldap/bin/ldifwrite connect=oiddb basedn="cn=users,dc=us,dc=oracle,dc=com" thread=3 verbose=true ldiffile=/tmp/backup-ENVXXX-[DATE].dat

1.2)Change e-mail address(And avoid special characters issues) :

/u01/oid/oid_home/ldap/bin/bulkmodify connect=oiddb attribute="mail" value="Global-Fusion.alerts@oracle.com" replace="TRUE" basedn="cn=users,dc=us,dc=oracle,dc=com" threads=4 size=1000 verbose=true

1.3)NOTE: If you want to protect admin e-mails or change to something else, add those values into a ldif file and run as ldapmodify command below(instead of 1.2):

ldapmodify -p 3060 -D cn=orcladmin -w **** -a -f return-SYSADMINEMAILS.ldif (file attached)

Step 2: FROM OIM SIDE:
2.1)UPDATE or CREATE SYSPROP into OIM(WEBUI) to allow unique e-mails. Set ‘OIM.EmailUniqueCheck’ to FALSE

OIM11G-UniqueEmailProperty

2.2)Run SQL:

 update usr set usr_email='Global-Fusion.alerts@oracle.com' where (usr_login not in('XELSYSADM', 'OAMADMINUSER','FUSION_APPS_HCM_SOA_SPML_APPID','WEBCHATADMIN','XELOPERATOR','WEBLOGIC','OIMINTERNAL','POLICYROUSER','POLICYRWUSER',
'OBLIXANONYMOUS','WEBLOGIC_IDM','IDROUSER','IDRWUSER','OAMSOFTWAREUSER','FAADMIN','OIM_ADMIN','OAMADMINUSER','OCLOUD9_OSN_APPID','OSN_LDAP_BIND_USER','HCM.USER','OIMADMINUSER'))

Step 3: FROM FUSION SIDE
3.1)Updating per_email_addresses table

 
UPDATE fusion.per_email_addresses pea set pea.email_address = 'Global-Fusion.alerts@oracle.com' where pea.email_address like '%oracle.com'

3.2)Updating hz_parties table

 
update fusion.hz_parties hp set hp.email_address = 'Global-Fusion.alerts@oracle.com' where hp.email_address like '%oracle.com'

3.3)Updating hz_contact_points table

update fusion.hz_contact_points hcp set hcp.email_address = 'Global-Fusion.alerts@oracle.com' where hcp.email_address like '%oracle.com'

Step 4: RUN ESS JOB to update FA from OID data:
4.1)Login into FA(Navigator–>Setup & Manitenance–>Search Schedule Person Keyword Crawler(Named as ‘Update Person Search Keywords’)–>Submit.

Conclusion

Well done, however, protecting email addresses for an organization is a proposition that should be done carefully, and an entire environment backup must be done before it starts. Using proper planning and understanding the various dimensions provided by this solution and its concepts allows an organization to discern how they handle email data. It also highlights what of the enterprise is willing to protect end- user data from copied environments, and how best to offer Oracle protection in an integrated and effective manner.

Add Your Comment