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>;
};
in openfire.xm i have added
<!-- sasl configuration -->
<sasl>
<!-- 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. -->
<mechs>GSSAPI</mechs>
<!-- <mechs>CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL,ANONYMOUS</mechs> --> <!-- Specify the realm you used when you created the service principal
and keytab.-->
<realm>DOMINIO.INT</realm> <!-- Mechanism-specific configuration here -->
<gssapi> <!-- 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. -->
<debug>true</debug> <!-- Specify the location of the GSSAPI configuration file you edited. -->
<config>/opt/openfire/conf/gss.conf</config> <!-- 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] -->
<useSubjectCredsOnly>false</useSubjectCredsOnly>
</gssapi>
</sasl> <provider>
<vcard>
<className>org.jivesoftware.openfire.ldap.LdapVCardProvider</className>
</vcard>
<user>
<className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
</user>
<auth>
<className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
</auth>
<group>
<className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className>
</group>
<authorization>
<classList>org.jivesoftware.openfire.sasl.LazyAuthorizationPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationProvider</classList>
<!-- other options: null, LdapAuthorizationProvider, UnixK5LoginProvider, Strict and Lazy-->
</authorization>
</provider>
if try a kinit of user root it seems to work
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