We’re planning to apply the January 2025 Critical Patch Update (CPU) to our JD Edwards 9.2.2 environment. Our accounts receivable system integrates with multiple external applications using various authentication methods - some use basic auth, others OAuth, and legacy systems still use JDE user credentials directly.
I’m concerned about potential authentication flow disruptions based on CPU release notes mentioning password policy changes and deprecated authentication methods. Here’s our current integration landscape:
// Current auth patterns:
AR_Invoice_API: Basic Auth (username/password)
Payment_Gateway: OAuth 2.0 (token-based)
Legacy_Credit_System: Direct JDE credentials
EDI_Partner_Portal: SAML SSO
Has anyone experienced authentication breaks after applying recent CPUs? Particularly interested in hearing about password policy impacts on service accounts and any integration compatibility issues. What’s your testing strategy before applying these patches to production?
The CPU release notes mention deprecation of certain authentication protocols but don’t explicitly disable them immediately. However, we found that TLS 1.0 and 1.1 support was removed, which affected our legacy credit system integration that hadn’t been updated in years. The connection just stopped working after the patch. Had to upgrade the legacy system to support TLS 1.2 minimum. Check your integration endpoints’ TLS versions before patching.
OAuth integrations were fine for us, but we discovered the CPU changed default token expiration times from 8 hours to 2 hours. Our payment gateway integration started failing midday because tokens expired faster than our refresh logic expected. Review your OAuth configuration settings after the patch and adjust token lifetimes if needed. Also, the CPU added mandatory client certificate validation for certain API endpoints, which wasn’t documented well in the release notes.
You can temporarily disable the new password policy enforcement by modifying the jde.ini file after CPU application. Add ‘PasswordPolicyEnforcement=Legacy’ under the [SECURITY] section. However, Oracle support strongly discourages this for more than 90 days. Better approach: create a phased rollout plan. Update critical integrations first with new password standards, test thoroughly, then apply CPU to production. We used a staging environment that mirrored production integrations and ran automated tests for 48 hours before production deployment.
Thanks for these insights. The TLS version issue is concerning since we do have older integration partners. For the password policy changes, are there any CPU configuration options to maintain backward compatibility temporarily while we update all service accounts? We have about 15 integration service accounts across different systems and updating them all simultaneously during a maintenance window seems risky.