Skip to main content

So you want to setup Windows Native Authentication with your Oracle Access Manager 11g implementation. According to the documentation, it’s pretty straightforward and simple. And it is =)

The royal pain in the ass comes when something fails and you don’t know why. You’re going to receive 1 of 4 generic errors that when googled will give you all kinds of possible causes. I’m going to give you some more =)

Here’s the common error’s you may receive:

– kinit(v5): KDC has no support for encryption type while getting initial credentials
– kinit(v5): Key table entry not found while getting initial credentials
– kinit(v5): No such file or directory while getting initial credentials
– kinit(v5): Client not found in Kerberos database.

Instead of going into the rhetoric, I’m just going to bullet out the different issues I ran into and their fixes in order of the Oracle setup doc. Hopefully they’ll help someone else out down the road!

1. Your krb5.conf file can be a host of problems.

– First make sure that all the REALM parts are in CAPITAL LETTERS ALWAYS AND EVERYWHERE. Anytime you use the realm name (in the krb5 file, krpass commands, anywhere…) it must be in caps. This is not a host name. All the hostname parts that are in lowercase are actual hostnames (or suffixes) of the box your on.

– Encryption types between your nix box and the AD server can cause problems. If AD isn’t Windows 2008 R2 (yes… R2), you’re going to experience issues. Like until R2, any authentication will fail of the SPN has a “/” in it (which they all do for us here). To help with the encryption problems, put these two lines in your [libdefaults] section:

default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

– The example in the Oracle guide is painful to understand if you have no clue what your doing. Also the default port for Kerberos authentication is 88. I just put it there explicitly because I rock like that. Here’s mine:

[logging] default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults] default_realm = CORP.DOMAIN.COM
ticket_lifetime = 600
dns_lookup_realm = true
dns_lookup_kdc = true
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

[realms] CORP.DOMAIN.COM = {
kdc = addc1.corp.domain.com:88
admin_server = addc1.corp.domain.com:88
default_domain = CORP.DOMAIN.COM
}

[domain_realm] .corp.domain.com = CORP.DOMAIN.COM
corp.domain.com = CORP.DOMAIN.COM

2. Creating the Service Principal Name

– A simple one line command right? HA! N00Bs beware =). When you run this command on the AD server, the password you provide will SET the password for that account to whatever you put. So don’t guess if you’re modifying an existing service account!

– If your password has some crazy characters or spaces in it, you’ll need to wrap it in quotes

– If you receive the error “DsCrackNames returned 0x2 in the name entry for [username]. ktpass:failed getting target domain for specified user.” This just means you need to add the domain to the username like “DOMAIN\username”

– Here’s the command I run that works. notice the “HTTP/[email protected]”. Yes. That’s how it should be, and yes the REALM needs to be in CAPITALS:

C:\>ktpass -princ HTTP/[email protected] -pass “c0mpl3x P455w0rd!” -mapuser DOMAIN\username -out c:\temp\keytab.service

– Now that you have your keytab.service file you should be able to get the Kerberos ticket from the AD server with the kinit command. Here’s an example that flows with the rest of the config I’ve given so far:

kinit -V HTTP/[email protected] -k -t keytab.service

– The REALM must be in CAPS here too

Here’s where you’re going to get the majority of your errors too. I’ll try to help here.

kinit(v5): KDC has no support for encryption type while getting initial credentials

– run “klist -ke keytab.service” to see what level of encryption is setup for your file
– verify that it’s one in the list in your krb5.conf file
– Make sure your AD administrator didn’t check “Use Kerberos DES encryption types for this account”. This will cause it to fail.
– If all else fails, regenerate your keytab.service file with the “-crypto All” flag at the end to get all encryption keys

kinit(v5): Key table entry not found while getting initial credentials

– Make sure your AD administrator didn’t check “Use Kerberos DES encryption types for this account”. This will cause it to fail.
– Verify that the HTTP/host@REALM is the same in the keytab.service file matches the FQND of the OAM server and the REALM is in caps and matches what’s in your krb5.conf file

kinit(v5): No such file or directory while getting initial credentials

– The path to your keytab.service file is wrong

kinit(v5): Client not found in Kerberos database.

– Make sure that there is only 1 account in AD that has the SPN of your HTTP/host@REALM. If there is more than one account set to the SPN authentication will fail. You can issue these two commands to verify:

c:\setspn -Q HTTP/oamserver.corp.domain.com
ldifde -f c:\upn_out.txt -d “DC=domain,DC=com” -l * -r “(userprincipalname=HTTP/[email protected])” -p subtree -s addc1.corp.domain.com
(if you don’t have the ldifde.exe file, google: ldifde.exe “index of” 😉

– You can also verify things with:

kinit [username]

You’ll be prompted for the password. If it’s correct you’ll be dropped to the prompt. If wrong, you’ll receive an error. If that works, then try:

kinit HTTP/host@REALM

You’ll again be prompted for the password for the account it’s attached to. If successfull you’ll be dropped to the prompt. If wrong, you’ll receive an error.

If that works, and kinit with the keytab file fails it’s something in the keytab file or a setting on the AD server.

Lastly, let’s say you don’t like the auto-failover to Basic authentication when WNA fails. Well… there’s no way to change it. Sorry. As per Oracle support, “it’s supposed to work that way”. The actual auth scheme is packaged together when sent to the user. So when WNA fails to get the SPNEGO token, it doesn’t go back to the WebGate or OAM server for a secondary authN scheme or use the Login Failed Redirect URL. It just immediately prompts the user with the popup box.

That’s all I got, but I haven’t found these answers for OAM-WNA integration specifically in one place, so hopefully this’ll save some people some time =)

Cheers!