SOA 10.1.3.3 install fails on multi IP machine...

Of course, it's the 10.1.3.1 install, before patching to 10.1.3.3.
You need to define VIRTUAL_HOST_NAME (yes - that is virtual-underscore-host-underscore-name).
In addition to OUI_HOSTNAME, ORACLE_HOSTNAME and EMHOSTNAME, that is...

So, if confronted with errors during the configuration stage (ESB goes wrong according to log, but gets status succeeded, BPEL Process Manager fails with Failed at "Could not get DeploymentManager", define VIRTUAL_HOST_NAME, and retry the installation.

Kerberos errors

As extension of the previous blog on Windows Native Authentication with Oracle, this little piece of info:

Kerberos Error 68.
Kerberos testing (kinit -k -t command) responded with

kinit: KRB5 error code 68 while getting initial credentials

Searches revealed:

KDC_ERR_WRONG_REALM 68 Reserved for future use
is being returned by Active Directory because your users are attempting to obtain a Kerberos TGT for a realm that is not hosted on the server to which they are authenticating.
The existing MIT Kerberos distribution that you are using does not know how to respond to this error. Windows machines can attempt to search the Active Directory Global Catalog in order to determine the actual principal name to use for authentication.

The krb5.conf file had port 88 specified on (one of the member) Active Directory server. Changing that to port 3268 (which is the Global Catalog port), changes the error into this:

kinit: Cannot contact any KDC for requested realm while getting initial credentials

I think this means the realm (domain in AD speak) is not serviced by this server. Problem is: where is it serviced.
Addition.
OK - got that solved; you can specify many Kerberos servers in the [realms] section of the krb5.conf file. Doing so resolved the issue of error 68.

Kerberos Encryption
Now, the next problem arises:

kinit: Bad encryption type while getting initial credentials

klist
There is a handy utility, klist, that can help out here. Klist can read the keytab file, and display all kinds of details, one of which is the encryption type used. Previous keytab files revealed RSA-MD5 was used, the latest one revealed CRC32:

klist -k -e -K -t FILE:/home/bortel/second.keytab

Keytab name: FILE:/home/bortel/second.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
1 01/01/70 01:00:00 HTTP/[nondisclosed] (DES cbc mode with CRC-32) (0x3e4986bc07972cda)


Keytab name: FILE:/home/bortel/first.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
4 01/01/70 01:00:00 HTTP/[nondisclosed] (DES cbc mode with RSA-MD5) (0x855d98e6793186e9)

With the first keytab file (listed as second entry), WNA works without any changes from the Oracle examples. The second keytab file (listed on top) has a different encription type, compared to the first. This might explain the encryption error...
Sure enough; altering the krb5.conf file, adding enctypes, so that the file reads the following resolved that issue:

[libdefaults]
default_realm = HOME.LOCAL
default_tkt_enctypes = des-cbc-crc
default_tgs_enctypes = des-cbc-crc
clockskew = 300

[realms]

Another enctype would be des-cbc-md5. This looks like the default one, as I did not specify enctypes in an earlier krb5.conf file.

Windows 2000 versus Windows 2003?
Now for the underlying reason, I can only guess. Is this a MS Windows issue? Did MS change from des-cbc-crc to des-cbc-md5 between Windows 2000 Server and Windows Server 2003? Seems unlikely, unless MS Windows always tries CRC32 as well as MD5.

Anyway, the problems I was facing were resolved, as this shows:

kinit -k -t /home/bortel/second.keytab HTTP/[nondisclosed]
klist
Ticket cache: /tmp/krb5cc_879
Default principal: HTTP/[nondisclosed]@HOME.LOCAL

Valid starting Expires Service principal
01/30/08 09:39:37 01/30/08 19:39:37 krbtgt/HOME.LOCAL@HOME.LOCAL

klist also allows to show the encryption type used:

klist -e
Ticket cache: /tmp/krb5cc_879
Default principal: HTTP/[nondisclosed]@HOME.LOCAL

Valid starting Expires Service principal
01/30/08 09:39:37 01/30/08 19:39:37 krbtgt/HOME.LOCAL@HOME.LOCAL
Etype (skey, tkt): DES cbc mode with CRC-32, DES cbc mode with CRC-32

UltraSearch - manual install

Because of switching operating systems, my iAS repository needs rebuilding. And of course, UltraSearch was forgotten.
So, after adding UltraSearch, I still needed the wksys user in the database. Have been looking for it once beore, and now decided to make a 'note to one self'. Of course, the Database Creation Assistent is useless, because it does not recognize the already installed instance, as so often.

SQL> set echo on
SQL> spool ultrasearch_inst.log
SQL> @$ORACLE_HOME/ultrasearch/admin/wk0setup.sql /oracle/db/10gRel2 "" SYS change_on_install "as sysdba" wksys SYSAUX TEMP "" "FALSE" DATABASE "" /oracle/db/10gRel2/jdbc/lib/classes12.zip /oracle/db/10gRel2/jlib/orai18n.jar /oracle/db/10gRel2/jdk/bin/java /oracle/db/10gRel2/ctx/bin/ctxhx cs-frank03:1521:o10gr2 cs-frank03:1521:o10gr2 /oracle/db/10gRel2
SQL> spool off
SQL> exit

Test with:

select comp_name, version, status from dba_registry
where COMP_ID='WK';

Once bitten twice shy.

Or should it be "Three strike - you're out!"?
Strike one: MicroSod started complaining about the validity of my XP install - out.
Strike two: tried Ubuntu 7.10 instead - graphics (solved) and networking issues; tried for two days - out.
Strike three: running CentOS 5.1 now. Graphics is OK - nVidia recognized, network is a known issue on an Asus P5B, and the solution is to prepare a driver disk for the installation, and make a new r8168 network module afterwards. I know, that sounds strange, but the driver (install with "linux dd") was not included in the install; during install, the network was activated correctly, after a reboot, network failed to start.

Anyway - download the latest driver, and -as root- perform:

# cd /tmp/r8168-8.004.00
# make
# depmod -a

# modprobe r8168

# ifconfig -a

You should now see an active network link (eth0). Just add a line "alias eth0 r8168" to /etc/modprobe.conf and configure the interface. Reboot to see if everything works.

balance 3.40

I used this piece of software in an earlier setup, and much to my surprise, there's even a Metalink note, that references the product.
Anyway, download it here, documentation can be found here.

How to setup WNA with Oracle

Just a short note on how to set up Windows Native Authentication (WNA) with Oracle Internet Directory (OID), V10.1.2.2 (patched 10G Rel 2).
Of course, it requires you have your setup done, that is, OID is in place, it synchronises with Actice Directory (from AD to OID minimal, or two way), and the external authentication plugin works. Maybe I will publish on those steps and update this entry with the links. (I did, I did! See this entry on OID AD sync in 10.1.4)

1. Create an account in Active Directory for your Single Sign On server. The accout is the short name, i.e. login.home.local should be created in AD as login.
2. Generate a keytab file for this account on the AD machine; take care, the process is highly case-sensitive!
   
   
   ktpass -princ HTTP/login.home.local@BORTEL.AD.LOCAL -pass <ad_passwd> -ptype KRB5_NT_PRINCIPAL +desonly -crypto des-cbc-md5 -mapuser login -out login.keytab
   
   
   
   The entry, following the "-princ" flag is uppercase "HTTP/", followed by the fully qualified domain name (FQDN) of your Single Sign On server in lower case, followed by "@YOUR_AD_DOMAIN", where your Active Directory entry should be in uppercase.
3. Transfer the generated keytab file (in this example, login.keytab) in binary(!) mode to your Single Sign On server. the location is
   $ORACLE_HOME/j2ee/OC4J_SECURITY/config
4. Create the Kerberos configuration file, krb5.conf. Many Unixes locate the file in /etc. The contents of the file:
   
   
   [libdefaults]
   default_realm = BORTEL.AD.LOCAL
   
   [realms]
   BORTEL.AD.LOCAL = {
   kdc = pdc01.bortel.ad.local:88
   }
   
   [domain_realm]
   .home.local = BORTEL.AD.LOCAL
   
   
   Don't be fooled with the "LOCAL" stuff; default_realm is the Active Directory realm (domain, in Windows terminology), the realms entry tells how your AD server is called, and on what port it listens - port 88 is the default for Kerberos.
   The last line is very important: it explains the mapping between your default OID context and AD - mind the leading dot. The login account, created in step 1 is login@BORTEL.AD.LOCAL, so users can be found 'under' BORTEL.AD.LOCAL. Similar for OID: the corresponding entries for other users can be found in OID under dc=home, dc=local.
   Your setup will differ, and your AD domain probably has an internal named domain, whereas your OID probably has "company_name.com".
5. Check time on AD and SSO servers; time should be (almost) the same!
6. Test your Kerberos config:
   
   
   kinit –k –t $ORACLE_HOME/j2ee/OC4J_SECURITY/config/login.keytab HTTP/login.home.local
   
   
   It should not respond with anything, just give back the cursor.
   
   I did get the following error, though:
   
   kinit: KRB5 error code 52 while getting initial credentials"
   The solution is listed in Microsoft KB832572, and is simply setting the 'Do not require Kerberos preauthentication' option with AD for the 'login' account. It's located under Account options on the Account details tab - last entry (you will need to scroll down in the option).
7. Make a copy of the configuration files for safekeeping:
   
   cp $ORACLE_HOME/sso/conf/policy.properties $ORACLE_HOME/sso/conf/policy.properties.org
   cp $ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn.xml $ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn.xml.org
   cp $ORACLE_HOME/opmn/conf/opmn.xml $ORACLE_HOME/opmn/conf/opmn.xml.org
   cp $ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn-data.xml $ORACLE_HOME/j2ee/OC4J_SECURITY/config/jazn-data.xml.org
   cp $ORACLE_HOME/j2ee/OC4J_SECURITY/applications/sso/web/WEB-INF/web.xml $ORACLE_HOME/j2ee/OC4J_SECURITY/applications/sso/web/WEB-INF/web.xml.org
   cp $ORACLE_HOME/j2ee/OC4J_SECURITY/application-deployments/sso/orion-application.xml $ORACLE_HOME/j2ee/OC4J_SECURITY/application-deployments/sso/orion-application.xml.org
   
8. Run the ssoca shell:
   
   cd $ORACLE_HOME/sso/bin
   ./ssoca
   [snip]
   Usage5: To configure the Single Sign-On server to enable Windows Native Authentication, do:
   java -jar ossoca.jar wna -mode sso -oh -ad_realm -kdc_host_port -keytab -ssohost -oid -verbose
   where:
   oh = Oracle Home Path, AD_realm = Active Directory Realm Name, kdc = Kerberos KDC in the format "hostname:port", keytab = path of the keytab file that you created for the SSO server, sso_host = SSO server hostname with domain, oid_server = OID server in the format "ldap://oid.acme.com:389"
   
   
   The actual command will become:
   
   ./ssoca wna –mode sso –oh $ORACLE_HOME \
   –ad_realm BORTEL.AD.LOCAL –kdc_host_port pdc01.bortel.ad.local:88 \
   -keytab $ORACLE_HOME/j2ee/OC4J_SECURITY/config/login.keytab \
   –verbose
   
   
9. Test your WNA - you should now be able to go to the OIDDAS pages without being asked to login.

How to log on as orcladmin with WNA?

Finally have WNA working, but now there is another "problem": how can I login as orcladmin (or any other user, for that matter)? Because every time, I switch to anything administrative on my oiddas page, Windows Native Authentication kicks in, and presents me with less privileged pages.

The only workaround I have found so far, is to disable WNA for the time being.
In IE, it is located in the Advanced Options (Enable Integrated Windows Authentication, under Security), under FireFox, you would have to remove the Single Sign On server from network.negotiate-auth.trusted-uris, in the about:config.

If anyone has another solution, please comment!