OID Crashed (Non-Recoverable) Case Study
Scenario: OID server got crashed and there is no way to recover it in near time (i.e. media got crashed)
Impact: In case OID server got crashed, none of the E-BIZ user will be able to use it. It can cause serious business impact
Recovery plan: Best way to come-over this problem in lesser amount of time is below:
Step 1) De-register SSO from E-BIZ.
(i) Go to $FND_TOP/bin
(ii) Run txkrun.pl -script=SetSSOReg -deregister=Yes -removereferences=Yes--- (this script will prompt you for some info regarding password of different schemas and utility, imp thing is it will ask you for orasso schema password, orasso schema password is not written in any log file or base table it need to be retrieved using some script and that need to be run on OID server, as in our case OID server is completely lost, but luckily we remember ORASSO password, so it is useful to save such password).
Above script will first remove references of OID from E-BIZ, then it will try connecting OID and removing E-BIZ references from there, last step is to revert SSO related profiles option at site level to non-sso values.
In our scenario as OID server is not there so running de-register will do E-BIZ part only since it will not be able to connect OID server and hence step 2 and 3 is not possible.
Step 2) After running de-register script if you try connecting E-BIZ front-end, it will throw some SSO error for AppsLocalLogin page. Cause behind this is SSO related profile options at SITE level has not been changed and apache is still diverting authentication activity to SSO.
To come over this: Login into application using sysadmin local login page, sysadmin credentials and change following profile options at site level.
Applications SSO Login Typesà Local
Applications SSO Typeà SSWA
Applications SSO Auto Link Userà Disabled
Changing above profile option will not call SSO server for user authentication.
Step 3) Now you will be able to see user login screen but will not be able to login, this is because user password has been set to External in fnd_user table in 11i db. Reason behind password being set to external in fnd_user, is at time when you enable SSO for external authentication, fnd_user user_guid gets populated and password field gets populated with text "External" , it means that this user will not be authenticated with 11i db but authorized.
To come over this
(i) Go to $FND_TOP/patch/115/sql and run fndssouu.sql user_name for all users…other way is to update user_guid field of all users to null in fnd_user table
(ii) Now Next step is to change password of all users using FNDCPASS utility.
Now your users will be able to login fine.
*************************************************************************************************************
References:
What happens when you run "txkrun.pl -script=SetSSOReg -deregister=Yes"?
Above script is to deregister SSO & OID from Apps & 10g AS Infrastructure Tier. Here are steps in background
SSO validation phase - Above script
i) Checks if ssosdk schema existsii) Checks if script can connect to orasso schema in SSO databaseiii) Checks if script can connect to apps schema in apps database
OID Validation Phase - Above script
iv) Checks if script can bind to LDAP (OID) server using SSL OID portv) Validates orcladmin password in OID using ldapbindvi) Checks if orcladmin account can delete entry in OID (not actually deleting any entry)vii) Validates Apps Name, Service Name, Instance Password and ACCOUNTS from OID
SSO deregistration Phase - Above scriptviii) Extract ssosdk_902.zipinto $APPLRGF/sso/sso/902sdkix) Checks if any partner application (Apps Framework Agent) already registeredx) Removes entry (partner application related to apps) from SSO (SSOSDK in 11i & ORASSO in SSO Server) using "java oracle.security.sso.enabler.SSORegistrar -mode REMOVE…".OID Deregistration Phase - Above scriptxi) Checks provisioning profile which are candidate for deregistration and create LDIF file of type $APPLRGF/ sso/ RemoveGUID_$GUID_$Day$dd_$timestamp.ldif using template file $FND_TOP/admin/template/ProvDeRegistration.tmpxii) Runs ldapdelete using above ldif file to delete any provisioning profile from OIDxiii) Creates ldif file of format DeRegistration_$Day$dd_$timestamp.ldif to list application to deregister from OID and then run ldapdelete to delete application (11i/r12) from OID
Log file location for registering/deregistering: $COMMON_TOP/rgf/$CONTEXT_NAME/sso
Scenario: OID server got crashed and there is no way to recover it in near time (i.e. media got crashed)
Impact: In case OID server got crashed, none of the E-BIZ user will be able to use it. It can cause serious business impact
Recovery plan: Best way to come-over this problem in lesser amount of time is below:
Step 1) De-register SSO from E-BIZ.
(i) Go to $FND_TOP/bin
(ii) Run txkrun.pl -script=SetSSOReg -deregister=Yes -removereferences=Yes--- (this script will prompt you for some info regarding password of different schemas and utility, imp thing is it will ask you for orasso schema password, orasso schema password is not written in any log file or base table it need to be retrieved using some script and that need to be run on OID server, as in our case OID server is completely lost, but luckily we remember ORASSO password, so it is useful to save such password).
Above script will first remove references of OID from E-BIZ, then it will try connecting OID and removing E-BIZ references from there, last step is to revert SSO related profiles option at site level to non-sso values.
In our scenario as OID server is not there so running de-register will do E-BIZ part only since it will not be able to connect OID server and hence step 2 and 3 is not possible.
Step 2) After running de-register script if you try connecting E-BIZ front-end, it will throw some SSO error for AppsLocalLogin page. Cause behind this is SSO related profile options at SITE level has not been changed and apache is still diverting authentication activity to SSO.
To come over this: Login into application using sysadmin local login page, sysadmin credentials and change following profile options at site level.
Applications SSO Login Typesà Local
Applications SSO Typeà SSWA
Applications SSO Auto Link Userà Disabled
Changing above profile option will not call SSO server for user authentication.
Step 3) Now you will be able to see user login screen but will not be able to login, this is because user password has been set to External in fnd_user table in 11i db. Reason behind password being set to external in fnd_user, is at time when you enable SSO for external authentication, fnd_user user_guid gets populated and password field gets populated with text "External" , it means that this user will not be authenticated with 11i db but authorized.
To come over this
(i) Go to $FND_TOP/patch/115/sql and run fndssouu.sql user_name for all users…other way is to update user_guid field of all users to null in fnd_user table
(ii) Now Next step is to change password of all users using FNDCPASS utility.
Now your users will be able to login fine.
*************************************************************************************************************
References:
What happens when you run "txkrun.pl -script=SetSSOReg -deregister=Yes"?
Above script is to deregister SSO & OID from Apps & 10g AS Infrastructure Tier. Here are steps in background
SSO validation phase - Above script
i) Checks if ssosdk schema existsii) Checks if script can connect to orasso schema in SSO databaseiii) Checks if script can connect to apps schema in apps database
OID Validation Phase - Above script
iv) Checks if script can bind to LDAP (OID) server using SSL OID portv) Validates orcladmin password in OID using ldapbindvi) Checks if orcladmin account can delete entry in OID (not actually deleting any entry)vii) Validates Apps Name, Service Name, Instance Password and ACCOUNTS from OID
SSO deregistration Phase - Above scriptviii) Extract ssosdk_902.zipinto $APPLRGF/sso/sso/902sdkix) Checks if any partner application (Apps Framework Agent) already registeredx) Removes entry (partner application related to apps) from SSO (SSOSDK in 11i & ORASSO in SSO Server) using "java oracle.security.sso.enabler.SSORegistrar -mode REMOVE…".OID Deregistration Phase - Above scriptxi) Checks provisioning profile which are candidate for deregistration and create LDIF file of type $APPLRGF/ sso/ RemoveGUID_$GUID_$Day$dd_$timestamp.ldif using template file $FND_TOP/admin/template/ProvDeRegistration.tmpxii) Runs ldapdelete using above ldif file to delete any provisioning profile from OIDxiii) Creates ldif file of format DeRegistration_$Day$dd_$timestamp.ldif to list application to deregister from OID and then run ldapdelete to delete application (11i/r12) from OID
Log file location for registering/deregistering: $COMMON_TOP/rgf/$CONTEXT_NAME/sso
No comments:
Post a Comment