this is my situation
-
openfire runnin on linux ubuntu. (started by root user)
-
KDC server running on windows 2000 server named teldc01.DOMINIO.INT
this is the gss.conf
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule
required
storeKey=<b>true</b>
keyTab="/opt/openfire/resources/feapache01.keytab"
doNotPrompt=<b>true</b>
useKeyTab=<b>true</b>
realm="DOMINIO.INT"
principal="xmpp/feapache01.dominio.int@DOMINIO.INT"
debug=<b>true</b>;
};
&lt;!-- sasl configuration --&gt; &lt;sasl&gt; &lt;!-- Include a comma-separated list of the authentication mechanisms to advertise support <b>for</b> to clients. Make sure GSSAPI is listed, and best <b>if</b> it's listed first. The order of mechanisms is important; clients should <b>try</b> to use the first mechanism they support (although not all will). Some clients will <b>try</b> to use the most secure first. You can add other mechanisms in order to support non-GSSAPI clients, or clients who cannot authenticate to the realm (like Windows 9X, off-site, and so on). Keep in mind that by allowing other mechanisms you are compromising the security of your realm. Be sure to talk to the Security Officer/Directory/Manager/Administrator about any policies your organization might have before enabling less secure mechanisms. By removing PLAIN and ANONYMOUS from the list, you will also disable non-SASL authentications. Keep in mind that a mechanism listed here might not actually be advertised, such as when the authProvider can't support the mechanism. PLAIN and ANONYMOUS mechanisms also enable non-SASL authentication (the old style XMPP auth), so removing them from <b>this</b> list will disallow non-SASL authentication. --&gt; &lt;mechs&gt;GSSAPI&lt;/mechs&gt; &lt;!-- &lt;mechs&gt;CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS&lt;/mechs&gt; --&gt; &lt;!-- Specify the realm you used when you created the service principal and keytab.--&gt; &lt;realm&gt;DOMINIO.INT&lt;/realm&gt; &lt;!-- Mechanism-specific configuration here --&gt; &lt;gssapi&gt; &lt;!-- Use <b>true</b> to turn on debugging information. This adds a lot of noise to your log files, but it can help you spot problems sooner in the initial setup. --&gt; &lt;debug&gt;true&lt;/debug&gt; &lt;!-- Specify the location of the GSSAPI configuration file you edited. --&gt; &lt;config&gt;/opt/openfire/conf/gss.conf&lt;/config&gt; &lt;!-- Sets the system property with the same name. You'll probably want "false" here (the <b>default</b>). For more details, see [http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html] --&gt; &lt;useSubjectCredsOnly&gt;false&lt;/useSubjectCredsOnly&gt; &lt;/gssapi&gt; &lt;/sasl&gt;
root@FeApache01:/opt/openfire/conf# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: root@DOMINIO.INT Valid starting Expires Service principal 10/10/07 17:15:08 10/11/07 03:15:01 krbtgt/DOMINIO.INT@DOMINIO.INT renew until 10/11/07 17:15:08 Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached
ktpass -princ xmpp/feapache01.dominio.int@DOMINIO.INT -mapuser root -pass PASSWORD -out feapache01.keytab
this is the openfire.xml
&lt;!-- sasl configuration --&gt;
&lt;sasl&gt;
&lt;!-- Include a comma-separated list of the authentication mechanisms
to advertise support <b>for</b> to clients. Make sure GSSAPI is listed,
and best <b>if</b> it's listed first. The order of mechanisms is important;
clients should <b>try</b> to use the first mechanism they support
(although not all will). Some clients will <b>try</b> to use the most
secure first. You can add other mechanisms in order to support non-GSSAPI clients,
or clients who cannot authenticate to the realm (like Windows 9X,
off-site, and so on). Keep in mind that by allowing other mechanisms
you are compromising the security of your realm. Be sure to talk
to the Security Officer/Directory/Manager/Administrator about any
policies your organization might have before enabling less secure
mechanisms. By removing PLAIN and ANONYMOUS from the list, you will
also disable non-SASL authentications. Keep in mind that a mechanism listed here might not actually be
advertised, such as when the authProvider can't support the mechanism.
PLAIN and ANONYMOUS mechanisms also enable non-SASL authentication
(the old style XMPP auth), so removing them from <b>this</b> list will
disallow non-SASL authentication. --&gt;
&lt;mechs&gt;GSSAPI&lt;/mechs&gt;
&lt;!-- &lt;mechs&gt;CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS&lt;/mechs&gt; --&gt; &lt;!-- Specify the realm you used when you created the service principal
and keytab.--&gt;
&lt;realm&gt;DOMINIO.INT&lt;/realm&gt; &lt;!-- Mechanism-specific configuration here --&gt;
&lt;gssapi&gt; &lt;!-- Use <b>true</b> to turn on debugging information. This adds a lot
of noise to your log files, but it can help you spot problems
sooner in the initial setup. --&gt;
&lt;debug&gt;true&lt;/debug&gt; &lt;!-- Specify the location of the GSSAPI configuration file you edited. --&gt;
&lt;config&gt;/opt/openfire/conf/gss.conf&lt;/config&gt; &lt;!-- Sets the system property with the same name. You'll probably want
"false" here (the <b>default</b>). For more details, see
[http://java.sun.com/j2se/1.4.2/docs/api/org/ietf/jgss/package-summary.html] --&gt;
&lt;useSubjectCredsOnly&gt;false&lt;/useSubjectCredsOnly&gt;
&lt;/gssapi&gt;
&lt;/sasl&gt;
klist output
root@FeApache01:/opt/openfire/conf# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: root@DOMINIO.INT Valid starting Expires Service principal
10/10/07 17:15:08 10/11/07 03:15:01 krbtgt/DOMINIO.INT@DOMINIO.INT renew until 10/11/07 17:15:08 Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
i’ve created the keylist using
ktpass -princ xmpp/feapache01.dominio.int@DOMINIO.INT -mapuser root -pass PASSWORD -out feapache01.keytab
on the AD server running as a DomainAdmins (i have created a user named root yet on the AD domain)
when i try to use spark i’ve the errore message
“unable to connect using Single Sign-On. Please check your principal and server settings”
any suggestion??
p.s.
sorry for my english