http://www.emco.is/msi_package_builder/features.html
It monitors the install of an application and then modify it any way you want. The you compile the product as a MSI.
Hi everyone,
I decided to add to this thread rather than open a new one. I’'m still having issues getting SSO to work in the same environment as the previous posters. XP sp2 with Spark 2.5.3 and Windows Server 2003 with Openfire 3.3.1 connected to MS SQL 2000.
I have followed the instructions in this thread and in the FAQ page and went through the same errors as mentioned above and removed those by creating the krb5.ini and copying it to C:\Windows on the client and the server.
I also created the registry key as follows on the client:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01
My client still won’‘t connect, I’‘ve included as much info as I can think of below. I’‘m sure I’'m very close.
I don’‘t know if I created my keytab file properly, or if it’'s even being used. Also I just created a basic domain user account called xmpp-athena. Did this need any extra permissions.
Couple you please take a look at the files below and let me know what I’'ve done wrong.
thanks
Steve
Errors:
***Spark Error.log
SASL authentication failed: at org.jivesoftware.smack.SASLAuthentication.authenticate(SASLAuthentication.java:209)
at org.jivesoftware.smack.XMPPConnection.login(XMPPConnection.java:341)
at org.jivesoftware.LoginDialog$LoginPanel.login(LoginDialog.java:785)
at org.jivesoftware.LoginDialog$LoginPanel.access$400(LoginDialog.java:185)
at org.jivesoftware.LoginDialog$LoginPanel$1.construct(LoginDialog.java:589)
at org.jivesoftware.spark.util.SwingWorker$2.run(SwingWorker.java:129)
at java.lang.Thread.run(Unknown Source)
***Spark Output.log
Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt true ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Principal is SDavis@DOMAIN.CO.UK
Commit Succeeded
***Openfire warn.log
2007.06.15 13:34:57 SaslException
javax.security.sasl.SaslException: Failure to initialize security context [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)]
at com.sun.security.sasl.gsskerb.GssKrb5Server.<init>(Unknown Source)
at com.sun.security.sasl.gsskerb.FactoryImpl.createSaslServer(Unknown Source)
at javax.security.sasl.Sasl.createSaslServer(Unknown Source)
at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java:220)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:141)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandler.java:132)
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)
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos Key)
at sun.security.jgss.krb5.Krb5AcceptCredential.getInstance(Unknown Source)
at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSManagerImpl.getCredentialElement(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.add(Unknown Source)
at sun.security.jgss.GSSCredentialImpl.<init>(Unknown Source)
at sun.security.jgss.GSSManagerImpl.createCredential(Unknown Source)
***d:\program files\wildfile\conf\gssapi.conf
/** * Login Configuration for JAAS. */ com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required storeKey=true keyTab="D:/Program Files/Wildfire/resources/jabber.keytab" doNotPrompt=true useKeyTab=true realm="DOMAIN.CO.UK" principal="xmpp/athena.domain.co.uk@DOMAIN.CO.UK" debug=true;
};
***C:\Windows\krb5.ini
[libdefaults]
default_realm = DOMAIN.CO.UK
noaddresses = true [realms]
DOMAIN.CO.UK = { kdc = lada.domain.co.uk default_domain = domain.co.uk
}
***keytab generated on domain controller using the command:
ktpass -princ xmpp/athena.domain.co.uk@DOMAIN.CO.UK -pass password -mapuser xmpp-athena -out jabber.keytab
and stored in D:\Program Files\Wildfire\resources on Openfire server
- Openfire.xml sections:
....... <sasl> <mechs>GSSAPI,ANONYMOUS,PLAIN,DIGEST-MD5,CRAM-MD5,NTLM</mechs> <realm>DOMAIN.CO.UK</realm> <gssapi> <!-- GSSAPI needs its own config file --> <config>D:/Program Files/Wildfire/conf/gssapi.conf</config> <!-- most will set useSubjectCredOnly to false (the default) See http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html for more details --> <useSubjectCredsOnly>false</useSubjectCredsOnly> <debug>true</debug> </gssapi> </sasl> ..........
<provider> <authorization> <classList>org.jivesoftware.openfire.sasl.LooseAuthorizationProvider org.jivesoftware.openfire.sasl.DefaultAuthorizationProvider</classList> <!-- other options: null, LdapAuthorizationProvider, UnixK5LoginProvider, Strict and Lazy--> </authorization>
Steve, posting a new thread gives you the opportunity to use the extra features of the forums- such as marking your question answered and indicating useful posts (only the original poster can do that). It seems many people are not aware of those features, though.
That aside- it looks like you have a problem with your keytab, probably in the principal name used. I see that you named the principal xmpp/athena.domain.co.uk@DOMAIN.CO.UK. So lets run through the checklist:
1: DOMAIN.CO.UK is the correct realm
2: athena.domain.co.uk resolves to the ip ________ (use nslookup)
3: The ip in step 2 resolves to athena.domain.co.uk (use nslookup)
4: keytab is in D:\Program Files\Wildfire\resources\jabber.keytab and the user running Openfire can read this file
There should be some output in the start.out or start.err log that has some Kerberos related messages. Make sure you have enabled debugging in Openfire too, that should help. Also, what is the version of Java on the server?
-
I’'ve obviously mashed the domain but yes, our AD domain is DOMAIN.CO.UK.
-
athena.domain.co.uk resolves to 10.0.0.11 and
-
10.0.0.11 resolves to athena.domain.co.uk
-
jabber.keytab is definately in d:\program files\wildfire\resources. The openfire service runs as LocalSystem should should have rights to read that file.
-
Openfire is reporting the java version as: 1.6.0_01 Sun Microsystems Inc. – Java HotSpot™ Server VM
This is the entry in stdout.log
Debug is true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator true KeyTab is d:/program files/wildfire/resources/jabber.keytab refreshKrb5Config is false principal is xmpp/athena.domain.co.uk@DOMAIN.CO.UK tryFirstPass is false useFirstPass is false storePass is false clearPass is false
principal''s key obtained from the keytab
Acquire TGT using AS Exchange
principal is xmpp/athena.domain.co.uk@DOMAIN.CO.UK
EncryptionKey: keyType=1 keyBytes (hex dump)=0000: 58 0E 19 A4 70 9D E3 67 Added server''s keyKerberos Principal xmpp/athena.domain.co.uk@DOMAIN.CO.UKKey Version 1key EncryptionKey: keyType=1 keyBytes (hex dump)=
0000: 58 0E 19 A4 70 9D E3 67 [Krb5LoginModule] added Krb5Principal xmpp/athena.domain.co.uk@DOMAIN.CO.UK to Subject
Commit Succeeded
stderror.log is not updated as a result of an SSO attemp.
there is nothing I can see that is related to this in the debug.log file either, it lots of reports from the gateway plugin about msn sessions.
Ok, looks like the server’'s GSS code is getting the service principal key ok, but the SASL code seems a little unhappy. This sort of error happens most often with name mis-matches, often related to DNS. athena isnt a CNAME, right? Its either an A or a AAAA record.
A few more questions- is the xmpp.domain the same as your hostname? Are you using SRV records? Do you have a HOSTS or LMHOSTS file?
The next step in debugging is likely to do a packet capture of the session. Doing so and posting here will reveal your domain name and perhaps your IP addresses. While this isnt really a huge concern for most people, if its a problem with you send me a private message and Ill see what we can work out in private.
OK - time to abandon the domain hiding, it’'s all internal only anyway.
We do have SRV records, these are all for emedia.co.uk so our jabber id is name@emedia.co.uk for example jsmith@emedia.co.uk. When normally logging into spark, we specify emedia.co.uk as the server name, NOT athena.emedia.co.uk
To confuse the issue further, we have a CNAME on our network of im.emedia.co.uk, pointing at athena.emedia.co.uk and it is this address used by the SRV records xmpp-client and xmpp-server.
athena.emedia.co.uk is an A record for 10.0.0.11
the xmpp.domain is emedia.co.uk
No I don’'t use HOSTS or LMHOSTS files.
Ok, so to make sure I have the DNS setup correct:
xmpp-client.tcp.emedia.co.uk. IN SRV 0 0 5222 im.emedia.co.uk.
im.emedia.co.uk. IN CNAME athena.emedia.co.uk.
athena.emedia.co.uk. IN A 10.0.0.11
11.0.0.10.in-addr.arpa. IN PTR athena.emedia.co.uk.
This setup should be supported without any issues, but I dont know anyone reporting it so its possible there is a bug.
Do you have the ability to install Wireshark or WinDump on the openfire server? Also, can you set wildfire to enforce that encryption (SSL/TLS) is NOT used (we want to see the packets in the buff on the wire). If you can do that, capture the packets during the auth exchange and post them here. For everyone’'s sanity, though, can you use the Plain Text editor and wrap the packet capture in {code}…{code} so it formats nicely? From what you have described, the only sensitive thing that will be seen in the exchange is a GSSAPI token, which will contain the principal names, but no other visible sensitive information (it would be encrypted in the token)
Yes, those DNS settings are correct.
I’'ll see what I can do about the packet sniffer and report back. Thanks for taking the time to respond.
Steve
If you cant get a packet sniffer installed, there is another alternative. Packet sniffers are just good tools overall to have.
Which would you recommend for ease of use and reporting?
If you don’‘t do this before next Monday, I’‘ll do it on my network. It’'s been on my to-do list for a couple of weeks now.
However, I can say that out of the box, SSO when using SRV records to locate a Openfire server does not work with Spark 2.5.3.
If I change my environment to use a hostname, it works perfectly but I had the same results as you when attempting to get it to work with SRV.
D
That was my suspicion here- but Im trying to figure out what is getting requested by whom.
Sorry to go off topic, but slushpuppie, I remember you mentioned in a thread that you had some code for spark that didn’'t require the krb5.ini file. When will that get added to Spark?
papawu- I have no idea. Ill talk to Derek about it again.
I just committed the changes to subversion (r8551 if interested). Its only been tested by me so far, so if you have the ability to compile Spark yourself, give it a whirl.
Some (rough) documentation is here: http://wiki.igniterealtime.org/display/SPARK/SSO+Usage
Message was edited by: slushpupie
I’'ll give that a whirl. Did you ever document the methods it would attempt to use to locate the appropriate Kerberos server?
I remember you saying that you were planning to use the Berkeley standard through info records in the directory? Is any of that written down anywhere?
cheers,
D
Its on that wiki page I posted.
Unfortunately I cannot get Wireshark installed on my Open Fire server as it seems to think Winpcap already exists and is in use. I can’‘t find what’'s using it either.
You said there was another way…
Or am I better of ditching SRV records and moving back to a hostname connection? If so what’'s the best way of doing this?
Steve
I did the trace yesterday, and it looks like an Openfire bug; the server does the following:
DNS lookup: domain name = result
Reverse DNS lookup: result = princ
Authenticate with the security principal xmpp/princ
That’'s obviously incorrect - the first step should be to lookup the SRV record and use that rather than the actual domain name.
So, if you want this to work without fixing Openfire you need to go back to using the hostname
However, if you do that then your clients will have to be changed, and the JID of every user will also change.
Message was edited by: DeeJay