Openfire SSO Issue?

Alex60 · June 25, 2018, 4:03pm

Hello, previously I’ve had single-sign on working fine - so this post is more for a sanity check to confirm that it does actually work with this current version Openfire 4.2.3 and I’ve not missed anything obvious!

As an example are the configs I’m trying out.

Openfire properties:

sasl.gssapi.config			C:\Program Files\Openfire\conf\gss.conf
sasl.gssapi.useSubjectCredsOnly		FALSE
sasl.mechs				GSSAPI
sasl.realm				AD.EXAMPLE.CO.UK
xmpp.domain				example.co.uk
xmpp.fqdn				openfire01.ad.example.co.uk

In the gss.conf file:

com.sun.security.jgss.krb5.accept {
	com.sun.security.auth.module.Krb5LoginModule required
	storeKey=true
	keyTab="C:/Program Files/Openfire/resources/xmpp.keytab"
	doNotPrompt=true
	useKeyTab=true
	isInitiator=true
	debug=true
	realm="AD.EXAMPLE.CO.UK"
	principal="xmpp/openfire01.ad.example.co.uk";
};

krb5.ini file:

[libdefaults]
	default_realm = AD.EXAMPLE.CO.UK
	
[realms]
	AD.EXAMPLE.CO.UK = {
		kdc = ad.example.co.uk
		admin_server = ad.example.co.uk
		default_domain = ad.example.co.uk
	}
	
[domain_realms]
	ad.example.co.uk = AD.EXAMPLE.CO.UK
	.ad.example.co.uk = AD.EXAMPLE.CO.UK

I can get a ticket with the keytab file for xmpp/openfire01.ad.example.co.uk@AD.EXAMPLE.CO.UK
And the server name itself resolves fwd and reverse.

Finally the ‘AllowTgtSessionKey’ dword key is set to 1

Have also tried xmpp/example.co.uk and other variations of principal name just in case.

On the Spark side of things, all I seem to get in the logs is:

Jun 25, 2018 3:29:13 PM org.jivesoftware.spark.util.log.Log warning
WARNING: Exception in Login:
org.jivesoftware.smack.sasl.SASLErrorException: SASLError using GSSAPI: not-authorized
	at org.jivesoftware.smack.SASLAuthentication.authenticationFailed(SASLAuthentication.java:365)
	at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1052)
	at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:956)
	at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:971)
	at java.lang.Thread.run(Unknown Source)

And in the Openfire logs (sorry for the mass error text):

018.06.25 14:41:58 org.jivesoftware.openfire.net.SASLAuthentication - An unexpected exception occurred during SASL negotiation. Affected session: org.jivesoftware.openfire.session.LocalClientSession@6a4447dc status: 1 address: example.co.uk/6suy6zckm id: 6suy6zckm presence: 
<presence type="unavailable"/>
java.util.NoSuchElementException
	at java.util.StringTokenizer.nextToken(Unknown Source)
	at org.jivesoftware.openfire.sasl.SaslServerPlainImpl.evaluateResponse(SaslServerPlainImpl.java:115)
	at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:329)
	at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:185)
	at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:177)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:690)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
	at org.apache.mina.core.filterchain.IoFilterAdapter.messageReceived(IoFilterAdapter.java:109)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
	at org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolDecoderOutputImpl.flush(ProtocolCodecFilter.java:407)
	at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecFilter.java:236)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:417)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:47)
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:765)
	at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74)
	at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63)
	at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTask(OrderedThreadPoolExecutor.java:769)
	at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.runTasks(OrderedThreadPoolExecutor.java:761)
	at org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:703)
	at java.lang.Thread.run(Unknown Source)
2018.06.25 14:42:01 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x00000002: nio socket, server, /10.0.1.1:62003 => 0.0.0.0/0.0.0.0:5222)
java.io.IOException: An existing connection was forcibly closed by the remote host
	at sun.nio.ch.SocketDispatcher.read0(Native Method)
	at sun.nio.ch.SocketDispatcher.read(Unknown Source)
	at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
	at sun.nio.ch.IOUtil.read(Unknown Source)
	at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
	at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:273)
	at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:44)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:690)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:664)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:653)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1124)
	at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
2018.06.25 15:19:44 org.jivesoftware.database.SequenceManager - Autocreating jiveID row for type '25'
2018.06.25 15:21:43 org.jivesoftware.openfire.spi.LegacyConnectionAcceptor - Configuration allows for up to 16 threads, although implementation is limited to exactly one.
2018.06.25 15:30:27 org.jivesoftware.openfire.nio.ConnectionHandler - Closing connection due to exception in session: (0x00000002: nio socket, server, /10.0.1.1:54946 => 0.0.0.0/0.0.0.0:5222)
java.io.IOException: An existing connection was forcibly closed by the remote host
	at sun.nio.ch.SocketDispatcher.read0(Native Method)
	at sun.nio.ch.SocketDispatcher.read(Unknown Source)
	at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
	at sun.nio.ch.IOUtil.read(Unknown Source)
	at sun.nio.ch.SocketChannelImpl.read(Unknown Source)
	at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:273)
	at org.apache.mina.transport.socket.nio.NioProcessor.read(NioProcessor.java:44)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:690)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:664)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:653)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:67)
	at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:1124)
	at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

Earlier, when I was trying to strace the openfire java process, I was getting
Mechanism level: Failed to find any Kerberos credentails

So it seems that Openfire itself is failing to get the kerberos ticket somehow? Is it worth trying to debug in some way?

Thanks
Alex

speedy · June 25, 2018, 7:44pm

at first glance, it looks ok. what version did you have sso working with? the the keytab user account locked out or has the password expired? That that password change?

Alex60 · June 27, 2018, 10:46am

Hi Speedy. apologies for the late reply - I’ve had some success now, just trying to work out now what I’m doing which is breaking it!

I know when the keytab principal, the gss.conf principal and the xmpp.fqdn do not match then sso will fail.

The other bit I need to confirm is if the keytab works with AES256 crypto and if an alternative UPN suffix is used.

Will post an update when I get some progress!

speedy · June 27, 2018, 1:34pm

yes, AES256 crypto will work. You have to mark your AD account as such. Also you’ll need to add JCE to openfire and the client.

I think I’ve tried using a alt upn at one point, but don’t recall if it was successful or not…

Alex60 · June 27, 2018, 3:30pm

So I don’t think the ‘This account supports Kerberos AES 128/256 bit encryption’ user account property does much since Win 7 / 2008R2 (by default at least).

Looks like it depends on group policy settings for the domain.
https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/

Anyway, I can confirm the AES 256 works (even when the account is not marked as such), though advise to set password to never expire.

I think the ‘openfire-4.2.3-1.x86_64.rpm RPM (64bit JRE bundled)’ package also includes the unlimited strength crypto policies. Alternatively, the OpenJDK packages work fine. (possibly preferred(?) as they are kept up to date with the package manager). Not sure if there are any other differences between the jre bundled package.

Alternative UPN suffixes also work fine!

I think I was just being too impatient in testing… it takes a little while for changes to get replicated around AD sometimes. That might be why things were being so inconsistent.