Hi,
Are you using an Identity file in this set-up? If you do, try switching the USERAUTH_METHOD method to
Identity file authentication.
Thanks,
Kasun
Thanks @Kasun Balasooriya for the reply.
Switching the authentication method didn’t work for us.
One thing we noticed in the application is that there is no traces of new application messages (including failures) for the same queue. I suspect that this issue is occurring before the message reaches the application.
Thanks @Kasun Balasooriya for the reply.
Switching the authentication method didn’t work for us.
One thing we noticed in the application is that there is no traces of new application messages (including failures) for the same queue. I suspect that this issue is occurring before the message reaches the application.
If the authentication is failing I don’t think there will be an attempt to create an application message in the application. May be you can try increasing the log level and try to narrow down the issue further from logs.
Thanks,
Kasun
still same issue.
Customer is on Apps10 UPD6.
The issues exists in PROD and TEST, but not CLON environment.
TEST and CLON is on same application server. The configurations are exactly the same in both environments. Same ftp page is being used.
Still, TEST is trying to authenticate with Kerberos, but CLON is not.
Caused by: java.lang.IllegalArgumentException: No Configuration was registered that can handle the configuration named com.sun.security.jgss.krb5.initiate
at com.bea.common.security.jdkutils.JAASConfiguration.getAppConfigurationEntry(JAASConfiguration.java:130)
at sun.security.jgss.LoginConfigImpl.getAppConfigurationEntry(LoginConfigImpl.java:156)
at javax.security.auth.login.LoginContext.init(LoginContext.java:251)
at javax.security.auth.login.LoginContext.<init>(LoginContext.java:512)
at sun.security.jgss.GSSUtil.login(GSSUtil.java:256)
at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:337)
at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:333)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:332)
at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122)
at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187)
at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212)
at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179)
at com.jcraft.jsch.jgss.GSSContextKrb5.init(GSSContextKrb5.java:129)
at com.jcraft.jsch.UserAuthGSSAPIWithMIC.start(UserAuthGSSAPIWithMIC.java:135)
at com.jcraft.jsch.Session.connect(Session.java:463)
I had the same issue, but mine was with my SFTP_SENDER. After a lot of research, I found that adding this entry into the login.config file within the IFS_HOME and restarting extended server solved my problem.
com.sun.security.jgss.krb5.initiate {
com.sun.security.auth.module.Krb5LoginModule required
principal="HTTP/<enter your principal>"
useKeyTab=true
keyTab=<enter your keytab>
storeKey=true
debug=false;
};
This file already had the entry:
com.sun.security.jgss.initiate, but not with krb5.