Friday, April 13, 2007

Forms, SSO, and a 500 Internal Server Error

After reinstalling OAS 10g 10.1.2, I was getting a 500 Internal Server Error when trying to use SSO with Forms.

The OC4J~OC4J_BI_Forms~default_island~1 log file contained this info:

07/04/12 15:25:32 Error: Unable to connect to OID
07/04/12 15:25:32 oracle.ias.repository.schema.SchemaException: Unable to connect to Oracle Internet Directory Server. Please verify that the correct Oracle Internet Directory Server parameters are specified in c:\oracle\mid1012\config\ias.properties. Make sure that the Oracle Internet Directory Server specified in OIDhost, OIDport is up and running. Base Exception : javax.naming.NamingException: [LDAP: error code 1 - User does not exist in directory for Proxy Switch]

. . . blah blah blah.

Found Note 279707.1 in Metalink, which states this error is caused by a mis-match between the oid_formsid and formsid_group_dn parameters in the formsweb.cfg file and the orclapplicationcommonname attribute for Forms in OID. After I corrected the mismatch, Forms and SSO began playing nice again.

How did this mismatch occur? I was guilty of copying a formsweb.cfg file from a previous installation into the current installation. I do this with several configuration files, including httpd.conf and tnsnames.ora to save time. But you have to be careful with Oracle because nothing is ever as simple as it seems.

At least I now know a little bit more of the mysterious internal workings of the Oracle Application Server. . .

Labels: ,

Thursday, April 12, 2007

Windows 2003 Certificate Authority

First post in an Oracle blog and its about. . . the Windows 2003 Server Certificiate Authority.

Long story short: have to setup a test network to develop a reduced sign-on solution for an Oracle Forms application. User's use smart cards to log on to the network, so the test network has to be the same. Windows 2003 Standard Server is the domain controller. Several weeks ago, a co-worker installed the Certificate Authority and successfully implmented smart card logins for the domain. Then I came along, working another problem, and removed Certificate Authority using the Windows Add/Remove Programs tool.

Turn's out it's a little more complicated than that.

After several reinstallations, lots of googling, and more Microsoft KB and TechNet articles than I want to remember, I found How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003 and from Windows 2000 Server. I followed all the steps, reinstalled Certificate Authority, set up my enrollement station, created a smart card and still couldn't login, although I was getting a different error message than the ". . . credential retrieval failed" I had been getting. This error directed me the Windows event viewer, where I discoverd the KDC (Key Distribution Center) was complaining the Root certificate was untrusted. This confirmed my earlier suspicison that Active Directory was using an old Root certificate to authenticate the smart card against. However, after I followed the decommissioning guidelines, the KDC was still complaining.

So I googled some more, swore so more, and finally used this command:

certutil -pulse

This loaded the Certificate Authority root certificate into all the domain stores - I think. Whatever it did, I can now log on to the domain using a smart card.

Now, back to Oracle and a malfunctioning Forms Servlet. . .


Labels: ,