Mechanism level: GSSHeader did not find the right tag,Error when accessing OAM WNA resources

Hi All,

After long gap I’m start writing blogs and I’m feeling for that.

Today I have faced login issue in WNA setup environment.

Requirement is user would need to login via WNA fallback authentication and access to the OAM WNA protected resources but it login request landed into error page “Account locked or disabled”.

From oam-server1.out logs

Note: If you are not able to see below then you should enable Kerberos trace level.

 <Jul 21, 2015 6:27:52 PM AEST> <Error> <oracle.oam.plugin> <BEA-000000> <Defective token detected (Mechanism level: GSSHeader
did not find the right tag)
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
        at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:80)
        at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:287)
        at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267)
        at oracle.security.am.plugin.authn.SPNEGOLoginModule$1.run(SPNEGOLoginModule.java:139)
        at javax.security.auth.Subject.doAs(Subject.java:394)
        at oracle.security.am.plugin.authn.SPNEGOLoginModule.login(SPNEGOLoginModule.java:124)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Normally this issue appears to be that something different from a Kerberos or NTLM token is being sent by the Microsoft IE browser client machine.

OAM only accepts Kerberos or NTLM tokens for now.

We noticed browser was sending the following token when accessing in company network domain.

And it keeps sending this similar like “Authorization: Negotiate” string over and over.

Authorization: Negotiate

YIGeBgYrBgEFBQKggZMwgZCgGjAYBgorBgEEAYI3AgIeBgorBgEEAYI3AgIKonIEcE5FR09FWFRTAA

AAAAAAAABgAAAAcAAAAByYkcFlDJDJ1CLBKiPp1EHAWr1ZstiFepuJLBr7EduFitBaRa45+4nQ/AGW

5Jf/GwAAAAAAAAAAYAAAAAEAAAAAAAAAAAAAAEVyfDIyRYtIv9kqa6BepAo=

This is not a standard NTLM value, as normally when we review the headers we would expect to see either:

Authorization: Negotiate TlRMTVNTUAABAAA…. (NTLM)

Authorization: Negotiate YIIGeAYGK…(Kerberos)

then this will still not work for OAM WAN Fallback, since the token received by OAM Server is NOT an NTLM token like, but appears to be more related to a NEGOEXTS token, which the Windows 7 clients sometimes send.

So, the token was not sent correctly by the browser to OAM server.

Cause:

On the UNIX host, use kinit on your user account and use klist to verify that you have a ticket to the HTTP/DOMAIN.NAME@REALM.NAME principal or not.

In our cause we have encountered below exception

kinit(v5): Client not found in Kerberos database while getting initial credentials

We have found a DNS issue for application OAM hostname. OAM VIP host name was resolving to different hostname and Keytab was created based on VIP hostname not actual hostname different and frontend host which is critical specially for creating a keytab

Solution:

Re-generated the keytab for DNS resolve hostname as follow

ktpass -princ HTTP/DOMAIN.NAME@REALM.NAME

-mapuser aurdev\srv-oam-iap1 -pass <Password> -out master.keytab -kvno 0

 

Copy the new keytab into <Oracle Home>/server/config/ and restart OAM server.

Hope above information helped you to get out of the issues.

Share This Post with Your Friends over Social Media!

About the Author sarath

An Oracle Identity and Access Management professional, having working on Oracle Access Manager Single Sign-On implementations, Installation/Configuration of Identity Server, Web Pass, Web Gate, Access Gate, Policy Manager, Access Server, Policy Domains, Authentication /Authorization schemes, Single Sign-On (single and multi-domain), OIM, OVD, OID, OAAM, OIF, High Availability/Failover/ SSL deployment.

Leave a Comment: