Many thanks the problem was :
<sasl>
<mechs>ANONYMOUS,PLAIN,DIGEST-MD5,CRAM-MD5,NTLM</mechs>
<realm>ECOA30.ERY.COM</realm> (fails)
</sasl>

Instead of this

<sasl>
<mechs>ANONYMOUS,PLAIN,DIGEST-MD5,CRAM-MD5,NTLM</mechs>
<realm>ECOA30</realm> (correct )
</sasl>

Your config.jive.sasl.realm variable should be set to ECOA30, and you need to configure the authorization.classList to include the StrictAuthorizationPolicy. It looks like openfire can't find the authorization element, so my guess is that either you missed it, or you duplicated the provider element.

I use
Pandion v2.5
WildFire v3.2.4
config with SASL-SSPI v6.2 http://norman.rasmussen.co.za/dl/sasl-sspi/wildfire-sasl-sspi.v6.2.zip

if I configured Pandion Integarded Windows Authentication and not conect

the logs of WildFire is:

2007.05.03 13:23:07 No AuthorizationProvider's found. Loading DefaultAuthorizationPolicy
2007.05.03 13:23:07 santiago@ECOA30 not authorized to santiago
2007.05.03 13:23:07 SaslException
javax.security.sasl.SaslException: SSPI: santiago@ECOA30 is not authorized to act as santiago
at net.za.darkskies.security.sasl.SSPIImpl.completeAuthorization(SSPIImpl.java:180)
at net.za.darkskies.security.sasl.SSPIImpl.evaluateResponse(Native Method)
at org.jivesoftware.wildfire.net.SASLAuthentication.handle(SASLAuthentication.java:274)
at org.jivesoftware.wildfire.net.StanzaHandler.process(StanzaHandler.java:144)
at org.jivesoftware.wildfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:131)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived(AbstractIoFilterChain.java:703)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimpleProtocolDecoderOutput.java:62)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:200)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(AbstractIoFilterChain.java:362)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:54)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:800)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:266)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:326)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Somebody knows that it is what he passes
Dispense English to me

I fixed a bug with GSSAPI-

In SASLAuthentication.java (near line 194) when we create the SaslServer object, we have to give the server name. To get the server name, we had just used session.getServerName() . The problem with that, is that method returns whatever the xmpp.domain property is set to. When using GSSAPI the server name needs to be the FQDN. So to get the FQDN we can use session.getConnection().getInetAddress().getCanonicalHostName() instead. Fairly simple change.

However, if the SASL method is not GSSAPI but using some other method that is expecting the xmpp.domain, it will break. An example is DIGEST-MD5.

The JavaDoc for SaslServerFactory says that the server name paramater to createSaslServer must be the FQDN, so it might work. Currently my SASL libraries on my client has a bug in it that crashes every time CRAM-MD5 gets used, so I cant verify.

I hate Kerberos errors. "Failed to find any Kerberos Key" could mean just about anything. The fact that it works with the domain==realm tells me Kerberos and DNS are configured correctly. I would like to see Kerberos debugging output from the client side as well. Also, there is more debugging output- you have debug=true in the gssapi.conf, that output goes to stderr, so nohup.out or something should have more messages.

It concerns me that the exception is coming from org.jivesoftware.wildfire.net.SASLAuthentication, since none of my code has had a chance to look at the credentials yet (its all Java internals at that point). Can you double check that NOTHING else has changed but the domain setting between your configurations?