powered by Jive Software

SSO and AD

this is my situation

  1. openfire runnin on linux ubuntu. (started by root user)

  2. 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=&quot;/opt/openfire/resources/feapache01.keytab&quot;
doNotPrompt=<b>true</b>
useKeyTab=<b>true</b>
realm=&quot;DOMINIO.INT&quot;
principal=&quot;xmpp/feapache01.dominio.int@DOMINIO.INT&quot;
debug=<b>true</b>;
};
&#38;lt;!-- sasl configuration --&#38;gt; &#38;lt;sasl&#38;gt;     &#38;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. --&#38;gt;     &#38;lt;mechs&#38;gt;GSSAPI&#38;lt;/mechs&#38;gt;     &#38;lt;!-- &#38;lt;mechs&#38;gt;CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS&#38;lt;/mechs&#38;gt; --&#38;gt;     &#38;lt;!-- Specify the realm you used when you created the service principal         and keytab.--&#38;gt;     &#38;lt;realm&#38;gt;DOMINIO.INT&#38;lt;/realm&#38;gt;     &#38;lt;!-- Mechanism-specific configuration here --&#38;gt;     &#38;lt;gssapi&#38;gt;         &#38;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. --&#38;gt;         &#38;lt;debug&#38;gt;true&#38;lt;/debug&#38;gt;         &#38;lt;!-- Specify the location of the GSSAPI configuration file you edited. --&#38;gt;         &#38;lt;config&#38;gt;/opt/openfire/conf/gss.conf&#38;lt;/config&#38;gt;         &#38;lt;!-- Sets the system property with the same name. You'll probably want             &quot;false&quot; 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] --&#38;gt;         &#38;lt;useSubjectCredsOnly&#38;gt;false&#38;lt;/useSubjectCredsOnly&#38;gt;     &#38;lt;/gssapi&#38;gt; &#38;lt;/sasl&#38;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

&#38;lt;!-- sasl configuration --&#38;gt;
&#38;lt;sasl&#38;gt;
    &#38;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. --&#38;gt;
    &#38;lt;mechs&#38;gt;GSSAPI&#38;lt;/mechs&#38;gt;
    &#38;lt;!-- &#38;lt;mechs&#38;gt;CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS&#38;lt;/mechs&#38;gt; --&#38;gt;     &#38;lt;!-- Specify the realm you used when you created the service principal
        and keytab.--&#38;gt;
    &#38;lt;realm&#38;gt;DOMINIO.INT&#38;lt;/realm&#38;gt;     &#38;lt;!-- Mechanism-specific configuration here --&#38;gt;
    &#38;lt;gssapi&#38;gt;         &#38;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. --&#38;gt;
        &#38;lt;debug&#38;gt;true&#38;lt;/debug&#38;gt;         &#38;lt;!-- Specify the location of the GSSAPI configuration file you edited. --&#38;gt;
        &#38;lt;config&#38;gt;/opt/openfire/conf/gss.conf&#38;lt;/config&#38;gt;         &#38;lt;!-- Sets the system property with the same name. You'll probably want
            &quot;false&quot; 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] --&#38;gt;
        &#38;lt;useSubjectCredsOnly&#38;gt;false&#38;lt;/useSubjectCredsOnly&#38;gt;
    &#38;lt;/gssapi&#38;gt;
&#38;lt;/sasl&#38;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

This is a duplicate thread. See: Re: SSO + AD