SSO Problem continues (not authorized to login as...)

Thomas_Deliduka · October 2, 2007, 3:19pm

I got some great help trying to figure out my SSO problems before. Thank you again! However, while my login works just fine with SSO now, it turns out other logins don’t! I don’t know why.

Rundown:

Windows Server / client (latest of each)
krb5.ini on server and client
kerbeos is working according to spark debugging.
had a problem previously with two <provider> tags in xml file, that has been fixed.
using looseAuthorizationProvider in xml for the authorization tag.

I’m getting this error in the debug screen:

2007.10.02 11:11:24 ~~first.last@CMAOHIO.ORG~~ not authorized to first.last

2007.10.02 11:11:24 SaslException

javax.security.sasl.SaslException: Problem with callback handler (Caused by javax.security.sasl.SaslException: ~~first.last@CMAOHIO.ORG~~ is not authorized to connect as first.last)

at com.sun.security.sasl.gsskerb.GssKrb5Server.doHandshake2(Unknown Source)

at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(Unknown Source)

at org.jivesoftware.openfire.net.SASLAuthentication.handle(SASLAuthentication.java :281)
at org.jivesoftware.openfire.net.StanzaHandler.process(StanzaHandler.java:144)
at org.jivesoftware.openfire.nio.ConnectionHandler.messageReceived(ConnectionHandl er.java:132)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)

at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:176)

at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)

at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)

at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)

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: javax.security.sasl.SaslException: ~~first.last@CMAOHIO.ORG~~ is not authorized to connect as first.last

… 19 more

NO_MESSAGES_OR_FRIEN · October 2, 2007, 4:10pm

Did you make the needed registry additions?

refer to this document: http://www.igniterealtime.org/community/docs/DOC-1060

Thomas_Deliduka · October 2, 2007, 4:11pm

Yes, sorry forgot to mention that. Yes, I put the registry additions in.

What we’re slowly figuring out is that domain admins (Those in the domain admins group) can login with SSO, normal users aren’t able to.

NO_MESSAGES_OR_FRIEN · October 2, 2007, 5:11pm

Is the base dn that you are searching in Ad inclusive of the everyone that you want to access the server? Are you using any filters in your ou config of openfire server?

Thomas_Deliduka · October 2, 2007, 5:14pm

I am using some filters to weed out disabled people and some other groups. However, if I go to the listing of users under the users/groups tab, I can search and find the users in question that couldn’t login before.

Also, if I don’t use SSO, and manually put in their password they can login just fine. the search in my xml file is this:

<searchFilter>(&(objectCategory=person)(objectClass=user)(!(userAccoun tControl:1.2.840.113556.1.4.803:=2))(!(CN=*FTP))(!(OU=Institutional Mailboxes and Mail Distribution Groups)))</searchFilter>

Jay · October 2, 2007, 5:29pm

Can you post your full openfire.xml ? Feel free to redact any passwords that show up in there. Also, please post it putting \

before and after, so the formatting is preserved. It will format like this then (use Preview to make sure you got it right):

Thomas_Deliduka · October 2, 2007, 5:31pm

It appears to have gone in double-spaced. tried to fix it.

<?xml version="1.0" encoding="UTF-8"?> <!--
This file stores bootstrap properties needed by Openfire.
Property names must be in the format: "prop.name.is.blah=value"
That will be stored as:
<prop>
<name>
<is>
<blah>value</blah>
</is>
</name>
</prop>
Most properties are stored in the Openfire database. A
property viewer and editor is included in the admin console.
-->
<!-- root element, all properties must be under this element -->
<jive> <adminConsole> <!-- Disable either port by setting the value to -1 --> <port>9090</port> <securePort>9091</securePort> </adminConsole> <admin> <!-- Use this section to define users that will have admin privileges. Below,
you will find two ways to specify which users are admins. Admins will
have access to the admin console (only local users) and may have also access
to other functionalities like ad-hoc commands. --> <!-- By default, only the user with the username "admin" can login
to the admin console. Alternatively, you can specify a comma-delimitted
list usernames that should be authorized to login to the admin console
by setting the <authorizedUsernames> field below. --> <!-- <authorizedUsernames></authorizedUsernames> --> <!-- Comma-delimitted list of bare JIDs. The JIDs may belong to local
or remote users. --> <!-- <authorizedJIDs></authorizedJIDs> --> <authorizedUsernames>thomas.deliduka,matt.pigman,chad.anderson,brad.yochum</authorizedUsernames> </admin> <locale>en</locale> <!-- Network settings. By default, Openfire will bind to all network interfaces.
Alternatively, you can specify a specific network interfaces that the server
will listen on. For example, 127.0.0.1. This setting is generally only useful
on multi-homed servers. --> <!--
<network>
<interface></interface>
</network>
--> <connectionProvider> <className>org.jivesoftware.database.EmbeddedConnectionProvider</className> </connectionProvider> <ldap> <host>192.168.1.10,192.168.1.3</host> <port>389</port> <baseDN>DC=cmaohio,DC=org</baseDN> <adminDN>administrator@cmaohio.org</adminDN> <adminPassword>xxxxxxxx</adminPassword> <connectionPoolEnabled>true</connectionPoolEnabled> <sslEnabled>false</sslEnabled> <ldapDebugEnabled>false</ldapDebugEnabled> <autoFollowReferrals>false</autoFollowReferrals> <usernameField>sAMAccountName</usernameField> <searchFilter>(&amp;(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(!(CN=*FTP))(!(OU=Institutional Mailboxes and Mail Distribution Groups)))</searchFilter> <vcard-mapping><![CDATA[
<vCard xmlns="vcard-temp">
<N>
<GIVEN>{cn}</GIVEN>
</N> <EMAIL>
<INTERNET></INTERNET> <USERID>{mail}</USERID>
</EMAIL> <FN>{displayName}</FN> <ADR>
<HOME></HOME> <STREET>{homePostalAddress}</STREET> <PCODE>{homeZip}</PCODE> <CTRY>{co}</CTRY>
</ADR> <ADR>
<WORK></WORK> <STREET>{streetAddress}</STREET> <LOCALITY>{l}</LOCALITY> <REGION>{st}</REGION> <PCODE>{postalCode}</PCODE> <CTRY>{co}</CTRY>
</ADR> <TEL>
<HOME></HOME> <VOICE></VOICE> <NUMBER>{homePhone}</NUMBER>
</TEL> <TEL>
<HOME></HOME> <CELL></CELL> <NUMBER>{mobile}</NUMBER>
</TEL> <TEL>
<WORK></WORK> <VOICE></VOICE> <NUMBER>{telephoneNumber}</NUMBER>
</TEL> <TEL>
<WORK></WORK> <CELL></CELL> <NUMBER>{mobile}</NUMBER>
</TEL> <TEL>
<WORK></WORK> <FAX></FAX> <NUMBER>{facsimileTelephoneNumber}</NUMBER>
</TEL> <TEL>
<WORK></WORK> <PAGER></PAGER> <NUMBER>{pager}</NUMBER>
</TEL> <TITLE>{title}</TITLE> <ORG>
<ORGUNIT>{department}</ORGUNIT>
</ORG>
</vCard>\]\]\></vcard-mapping> <nameField>cn</nameField> <emailField>mail</emailField> <groupNameField>cn</groupNameField> <groupMemberField>member</groupMemberField> <groupDescriptionField>description</groupDescriptionField> <posixMode>false</posixMode> <groupSearchFilter>(&amp;(objectClass=group)(description=CMOA*))</groupSearchFilter> </ldap> <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.LooseAuthorizationPolicy</classList> </authorization> </provider> <setup>true</setup> <sasl> <mechs>GSSAPI</mechs> <realm>CMAOHIO.ORG</realm> <gssapi> <debug>true</debug> <config>C:\Program Files\Openfire\conf\gss.conf</config> <useSubjectCredsOnly>false</useSubjectCredsOnly> </gssapi> </sasl> <log> <debug> <enabled>true</enabled> </debug> </log> </jive>

Message was edited by: Tomnibus

Jay · October 2, 2007, 5:48pm

If you change the mecs section to have both GSSAPI and PLAIN, can other users log in without SSO?

Thomas_Deliduka · October 2, 2007, 5:53pm

Actually all the users can login without SSO with the current configuration. It seems that only Domain Admins can login with SSO. We want to configure everyone to login with SSO only.

Jay · October 2, 2007, 6:07pm

If they are logging in currently, they are doing so without sasl, which I dont think current versions support disabling. I dont remember if we added an option to prevent iq-auth, which means you cant really prevent it (that is something that certainly needs to be fixed).

Try this: enable PLAIN again, and in Spark turn on the debug window for logins (in advanced) and see how the user is logging in. If the auth packet is using jabber:iq:auth then SASL isnt working at all for non-admin users for some reason.

Thomas_Deliduka · October 2, 2007, 6:22pm

What happens is if I log them in without SSO, then from then on, even if I have SSO enabled in their setup, it will fail with that and as a backup use their stored password and log them in anyway. I don’t really want that to happen. So, I delete the c:\document and settings\username\spark folder to make sure there is no saved password information in there and then attempt SSO without first logging in. that is when it failed.

As a test, just now, I added a normal user to the domain admins. Then waited. I even restarted the openfire server to make sure the new user’s permissions were in there if that was even necessary. Then I tried to use SSO for that user and it still failed. So, whatever it is, it’s not a domain admins thing, although coincidentally, the only two users who can login with SSO are domain admins right now.

I thought, perhaps, it was the machine that I’m trying to test this on. So, I logged in as myself and Spark logged in perfectly with SSO without any configuration. So, there is certainly something about me that allows me in.

I will try what you say above and get back with you.

Jay · October 2, 2007, 6:30pm

Ok, if the domain admins theory proved incorrect, Im wondering about the envrionment. The fact the logs are saying the first.last@REALM is not authorized to first.last means the user has authenticated ok, so it sounds like the client is all good. Do you have anything in the stdout or stderr log files? The Java Kerberos debug stuff will go there, it may give some hints. I suspect not, though.

Do you have multiple realms involved here? Is your realm name the same as your xmpp.domain ?

Thomas_Deliduka · October 2, 2007, 6:32pm

Okay, I changed mechs to GSSAPI,PLAIN then I restarted the openfire server. Then I tried to login as “marybeth.kiser” a non-admin user and these are the smack debug lines.

RAW sent:

&lt;stream:stream to="po-test" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" version="1.0"&gt;
&lt;starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"/&gt;
&lt;stream:stream to="po-test" xmlns="jabber:client" xmlns:stream="http://etherx.jabber.org/streams" version="1.0"&gt;
&lt;auth mechanism="GSSAPI" xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;YIIFNgYJKoZIhvcSAQICAQBuggUlMIIFIaADAgEFoQMCAQ6iBwMFAAAAAACjggRJYYIERTCCBEGgAwIBBaENGwtDTUFPSElPLk9SR6ImMCSgAwIBAKEdMBsbBHhtcHAbE3BvLXRlc3QuY21hb2hpby5vcmejggQBMIID/aADAgEDooID9ASCA/CKb4hSe5N4G5ZcAA6bp5R8dP2+t8P1bl8wTK3ioK6Fbs2VMTIfhqHVAsxT5/4hN/m3V1z3U6TkH3F0Wji1Ad1znVvEidHBYyTcqLzJ1Jk49IZUru2Wkth7WI7AYLDDohFn4ZlIAbW0WfVXZ3oMPhACUM3fvJeNp4OiQG/kMkCmDzTT9mTSitmDLZmkQwKLhYX96T9chuvjTcoUv2eOOj9sG4CUfH4WUd4dzy8clGn1t0sGU7V4+y/rVMjkLTV1uZzoJdw2a5H2y4zDC8YTwtD9y/pG0RuezqrtLxu5LWHLe0YNrak8Z0g0gHjtWgcfNnARxzt7e3qaT5QS8x//hhP/SalM9xlFR12LJaqxjGm1Ba4etesIKwmKC14eKoYNxH8PNCzIcfJP5jWEPdb1zt+3EPGSqP0OH+0FGQziA86aOL+GGxDi7Gy/fDQm7vs41Rsam6qhcewBAYs87FNW7n9woam4BWV1iG0JYbQO5tqBPROKwWpI3kmrzei/NGLTROPoTFf6W2Szk9ycIyK4Rm7VxpUOxo8AA3XDXgDeii9NuQFtky3zJKboqcSo0kUQXthZ/ldwouvZ9FIdALJG4vsJhaFhAV/ZIap97PeDP1yva+bEvgu0Y+c6OurHdCxVGVJ74tDQZ6LSX80UR8s8KM4RudsY6+sooyc28MBmlY8zWnnpSPhaWyhKEa3b6LmMnjJHleZMuHz5mrWICspP4Gnx3A2TI6kU/BzrIJNv+MAzICrUOQiy0mqdOJlBIi7XyTSdI2WQ/w+F0V9SF3Xgv5Y7/7V2SkJ2cuhiHGvDJJshjAjfS3n0NtLW4XVmBvPpodK3t6x65aVZTe9zCnqJbGfYWd+b3W8YasL3jY+yiaSN9uLuu3MjbTgEvS8iF8yOYTimeDkaRZWVHUrjbbykXLLUX+/+zlQwLvcKn+192n6DRf6tJXiJ55Sg6s9DmHYU2L00XN+4FnypE0JXjvzvrL3XeZFWJ6mIIc9kMEOSdWDjY1UdvvA4/LDLi90fSeZLsicX67x9ndwlEgM6xd0BJx1pTPFYzZ+y6E0nRt1znEqTdTDWLlEKIu2tFHda7neO9efhM6FdVxNmHgIyH+hLUSqeBJsIQodwFi2IkoGWW0RfrFapQygHJi3hkX8lAnTUyUkqP/mqVjFL8B4VdlUIZKr1wFovEUgpRL1TJdluLzS/3QW1eyBc/Hhk4UwpVnBE7Xn7RXgnp7tNUFKWrGJfnh6KkY/heJmIzd8rp9Cj3C8tOHP9/i2XXocYeGQUwQbPaYaeMoyys0ju9JyWH4LNWMFO5xQ1Q4CIHPRrcOqgykK4zP5dOc5xEpc+M00Wcrky2mGkgb4wgbugAwIBA6KBswSBsICaIkLWGlDp4fpB1KQ7bfP2z6lh7oMlP922Xlp5icv4nG2lG56R67dFXgBNVMwYYrku2BpcqzZKzR8bIuQBOwhymhfgm48LyRqlRnziPZ12a7xqeQ5QsXrGDqqNTKyPlW/Eob0WKSm3+vr+PlCyIorssGJSRVq9QJFIuyf4gh97BBc5B0jCmiYG7WiQBqHDAyGLnleEDuaeBalbbHmt6iKy0cAKTQxUnFNKWt/gqyxa&lt;/auth&gt;
&lt;response xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;=&lt;/response&gt;
&lt;response xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;YEMGCSqGSIb3EgECAgIBAAD/////ovPTQQdklHjO48h5Nm40RQOPmZ0+o09BAQEAAG1hcnliZXRoLmtpc2VyBgYGBgYG&lt;/response&gt;

And RAW Received:

&lt;?xml version='1.0' encoding='UTF-8'?&gt;&lt;stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="po-test" id="f6666cae" xml:lang="en" version="1.0"&gt;
&lt;stream:features&gt;&lt;starttls xmlns="urn:ietf:params:xml:ns:xmpp-tls"&gt;&lt;/starttls&gt;&lt;mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;&lt;mechanism&gt;GSSAPI&lt;/mechanism&gt;&lt;mechanism&gt;PLAIN&lt;/mechanism&gt;&lt;/mechanisms&gt;&lt;compression xmlns="http://jabber.org/features/compress"&gt;&lt;method&gt;zlib&lt;/method&gt;&lt;/compression&gt;&lt;auth xmlns="http://jabber.org/features/iq-auth"/&gt;&lt;/stream:features&gt;
&lt;proceed xmlns="urn:ietf:params:xml:ns:xmpp-tls"/&gt;
&lt;?xml version='1.0' encoding='UTF-8'?&gt;&lt;stream:stream xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client" from="po-test" id="f6666cae" xml:lang="en" version="1.0"&gt;&lt;stream:features&gt;&lt;mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;&lt;mechanism&gt;GSSAPI&lt;/mechanism&gt;&lt;mechanism&gt;PLAIN&lt;/mechanism&gt;&lt;/mechanisms&gt;&lt;compression xmlns="http://jabber.org/features/compress"&gt;&lt;method&gt;zlib&lt;/method&gt;&lt;/compression&gt;&lt;auth xmlns="http://jabber.org/features/iq-auth"/&gt;&lt;/stream:features&gt;
&lt;challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;=&lt;/challenge&gt;
&lt;challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;YDMGCSqGSIb3EgECAgIBAAD/////GLy6kNgPAg8enfEOjBCqRPqNBzjOG/dxAQEAAAQEBAQ=&lt;/challenge&gt;
&lt;failure xmlns="urn:ietf:params:xml:ns:xmpp-sasl"&gt;&lt;not-authorized/&gt;&lt;/failure&gt;

Jay · October 2, 2007, 6:48pm

Ok, so at some point I added some code to disable the iq-auth . Set the property xmpp.auth.iqauth to false to disable it. This is only available in trunk right now, but should make it into 3.4.0. (The logs blame me on June 20th, 2007, I hardly even remember doing that…)

Thomas_Deliduka · October 2, 2007, 6:48pm

Hmmm. While I am the Network Admin/Director of IT here, I did not setup this network. In the Active Directory Users & Groups I have only one domain. Is that the same as Realm? When I ran the first command on the SSO configuration instructions only one realm was listed CMAOHIO.ORG I’m not sure what you mean by “realm name same as your xmpp.domain” where do I find that out?

Jay · October 2, 2007, 6:54pm

I hate the term “domain” since its too generic. xmpp.domain is what comes after the @ in your JID’s, or sometimes called the server name. In the Openfire properties its listed as xmpp.domain, though.

Realm refers to the Kerberos realm(s) you use. In Active Directory, it is sometimes called a domain as well (Windows Domain, AD Domain, NT Domain, and perhaps other names). Multiple realms in AD often goes along with the terms “Forrest” and “Trust”, so if you have not heard those terms used ever, its doubtful you have more than one.

Thomas_Deliduka · October 2, 2007, 6:57pm

When I login to the admin server, go to the server properties, there is no xmpp.domain value at all.

My Realm/AD Domain is cmaohio.org or CMAOHIO.ORG should I create a property in my openfire server properties page called xmpp.domain and put the value as CMAOHIO.ORG? after doing that do I restart the service?

NO_MESSAGES_OR_FRIEN · October 2, 2007, 8:52pm

Is the chat server bound to AD? Does it have a valid DNS entry, that matches the server name in the openfire admin? I am including a working basic openfire.xml config for a windows AD setup for SSO below:

<code> &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!--
    This file stores bootstrap properties needed by Openfire.
    Property names must be in the format: "prop.name.is.blah=value"
    That will be stored as:
        &lt;prop&gt;
            &lt;name&gt;
                &lt;is&gt;
                    &lt;blah&gt;value&lt;/blah&gt;
                &lt;/is&gt;
            &lt;/name&gt;
        &lt;/prop&gt;     Most properties are stored in the Openfire database. A property viewer and editor is included in the admin console.
--&gt;
&lt;!-- root element, all properties must be under this element --&gt;
&lt;jive&gt;   &lt;adminConsole&gt;     &lt;!-- Disable either port by setting the value to -1 --&gt;      &lt;port&gt;9090&lt;/port&gt;      &lt;securePort&gt;9091&lt;/securePort&gt;   &lt;/adminConsole&gt;    &lt;admin&gt;     &lt;!-- Use this section to define users that will have admin privileges. Below,
          you will find two ways to specify which users are admins. Admins will
          have access to the admin console (only local users) and may have also access
          to other functionalities like ad-hoc commands. --&gt;      &lt;!-- By default, only the user with the username "admin" can login
         to the admin console. Alternatively, you can specify a comma-delimitted
         list usernames that should be authorized to login to the admin console
         by setting the &lt;authorizedUsernames&gt; field below. --&gt;      &lt;!-- &lt;authorizedUsernames&gt;&lt;/authorizedUsernames&gt; --&gt;      &lt;!-- Comma-delimitted list of bare JIDs. The JIDs may belong to local
         or remote users. --&gt;      &lt;!-- &lt;authorizedJIDs&gt;&lt;/authorizedJIDs&gt; --&gt;      &lt;authorizedUsernames&gt;ofadmin&lt;/authorizedUsernames&gt;   &lt;/admin&gt;    &lt;locale&gt;en&lt;/locale&gt;    &lt;!-- Network settings. By default, Openfire will bind to all network interfaces.
      Alternatively, you can specify a specific network interfaces that the server
      will listen on. For example, 127.0.0.1. This setting is generally only useful
       on multi-homed servers. --&gt;    &lt;!--
    &lt;network&gt;
        &lt;interface&gt;&lt;/interface&gt;
    &lt;/network&gt;
    --&gt;    &lt;connectionProvider&gt;     &lt;className&gt;org.jivesoftware.database.EmbeddedConnectionProvider&lt;/className&gt;   &lt;/connectionProvider&gt;    &lt;!-- sasl configuration --&gt;    &lt;sasl&gt;     &lt;!-- Include a comma-separated list of the authentication mechanisms
        to advertise support for to clients. Make sure GSSAPI is listed,
        and best if it's listed first. The order of mechanisms is important;
        clients should try to use the first mechanism they support
        (although not all will). Some clients will try 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 this list will
        disallow non-SASL authentication. --&gt;      &lt;mechs&gt;GSSAPI,CRAM-MD5,DIGEST-MD5,PLAIN,EXTERNAL&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;FOREST.DOMAIN.COM&lt;/realm&gt;      &lt;!-- Mechanism-specific configuration here --&gt;      &lt;gssapi&gt;       &lt;!-- Use true 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;C:\Program Files\Openfire\conf\gss.conf&lt;/config&gt;        &lt;!-- Sets the system property with the same name. You'll probably want
            "false" here (the default). 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;    &lt;ldap&gt;     &lt;host&gt;server.forest.domain.com&lt;/host&gt;      &lt;port&gt;389&lt;/port&gt;      &lt;baseDN&gt;OU=folder,DC=forest,DC=domain,DC=com&lt;/baseDN&gt;      &lt;adminDN&gt;ldapuser@domain.com&lt;/adminDN&gt;      &lt;adminPassword&gt;**********&lt;/adminPassword&gt;      &lt;connectionPoolEnabled&gt;true&lt;/connectionPoolEnabled&gt;      &lt;sslEnabled&gt;false&lt;/sslEnabled&gt;      &lt;ldapDebugEnabled&gt;false&lt;/ldapDebugEnabled&gt;      &lt;autoFollowReferrals&gt;false&lt;/autoFollowReferrals&gt;      &lt;usernameField&gt;sAMAccountName&lt;/usernameField&gt;      &lt;searchFilter&gt;(objectClass=organizationalPerson)&lt;/searchFilter&gt;      &lt;vcard-mapping&gt;&lt;![CDATA[
&lt;vCard xmlns="vcard-temp"&gt;
  &lt;N&gt; &lt;N&gt;&lt;FAMILY&gt;{sn}&lt;/FAMILY&gt;&lt;GIVEN&gt;{givenName}&lt;/GIVEN&gt;&lt;MIDDLE/&gt;&lt;/N&gt;
  &lt;/N&gt;    &lt;EMAIL&gt;
    &lt;INTERNET/&gt;     &lt;USERID&gt;{mail}&lt;/USERID&gt;
  &lt;/EMAIL&gt;   &lt;FN&gt;{displayName}&lt;/FN&gt;   &lt;ADR&gt;
    &lt;HOME/&gt;     &lt;STREET&gt;{homePostalAddress}&lt;/STREET&gt;     &lt;PCODE&gt;{homeZip}&lt;/PCODE&gt;     &lt;CTRY&gt;{co}&lt;/CTRY&gt;
  &lt;/ADR&gt;   &lt;ADR&gt;
    &lt;WORK/&gt;     &lt;STREET&gt;{streetAddress}&lt;/STREET&gt;     &lt;LOCALITY&gt;{l}&lt;/LOCALITY&gt;     &lt;REGION&gt;{st}&lt;/REGION&gt;     &lt;PCODE&gt;{postalCode}&lt;/PCODE&gt;     &lt;CTRY&gt;{co}&lt;/CTRY&gt;
  &lt;/ADR&gt;   &lt;TEL&gt;
    &lt;HOME/&gt;     &lt;VOICE/&gt;     &lt;NUMBER&gt;{homePhone}&lt;/NUMBER&gt;
  &lt;/TEL&gt;   &lt;TEL&gt;
    &lt;HOME/&gt;     &lt;CELL/&gt;     &lt;NUMBER&gt;{mobile}&lt;/NUMBER&gt;
  &lt;/TEL&gt;   &lt;TEL&gt;
    &lt;WORK/&gt;     &lt;VOICE/&gt;     &lt;NUMBER&gt;{telephoneNumber}&lt;/NUMBER&gt;
  &lt;/TEL&gt;   &lt;TEL&gt;
    &lt;WORK/&gt;     &lt;CELL/&gt;     &lt;NUMBER&gt;{mobile}&lt;/NUMBER&gt;
  &lt;/TEL&gt;   &lt;TEL&gt;
    &lt;WORK/&gt;     &lt;FAX/&gt;     &lt;NUMBER&gt;{facsimileTelephoneNumber}&lt;/NUMBER&gt;
  &lt;/TEL&gt;   &lt;TEL&gt;
    &lt;WORK/&gt;     &lt;PAGER/&gt;     &lt;NUMBER&gt;{pager}&lt;/NUMBER&gt;
  &lt;/TEL&gt;   &lt;TITLE&gt;{title}&lt;/TITLE&gt;   &lt;ORG&gt; &lt;ORGNAME&gt;{company}&lt;/ORGNAME&gt;
    &lt;ORGUNIT&gt;&lt;/ORGUNIT&gt;
  &lt;/ORG&gt;
  &lt;URL&gt;{wWWHomePage}&lt;/URL&gt;
&lt;/vCard&gt;]]&gt;&lt;/vcard-mapping&gt;      &lt;nameField&gt;cn&lt;/nameField&gt;      &lt;emailField&gt;mail&lt;/emailField&gt;      &lt;groupNameField&gt;cn&lt;/groupNameField&gt;      &lt;groupMemberField&gt;member&lt;/groupMemberField&gt;      &lt;groupDescriptionField&gt;description&lt;/groupDescriptionField&gt;      &lt;posixMode&gt;false&lt;/posixMode&gt;      &lt;groupSearchFilter&gt;(objectClass=group)&lt;/groupSearchFilter&gt;   &lt;/ldap&gt;    &lt;provider&gt;     &lt;vcard&gt;       &lt;className&gt;org.jivesoftware.openfire.ldap.LdapVCardProvider&lt;/className&gt;     &lt;/vcard&gt;      &lt;user&gt;       &lt;className&gt;org.jivesoftware.openfire.ldap.LdapUserProvider&lt;/className&gt;     &lt;/user&gt;      &lt;auth&gt;       &lt;className&gt;org.jivesoftware.openfire.ldap.LdapAuthProvider&lt;/className&gt;     &lt;/auth&gt;      &lt;group&gt;       &lt;className&gt;org.jivesoftware.openfire.ldap.LdapGroupProvider&lt;/className&gt;     &lt;/group&gt;      &lt;authorization&gt;       &lt;classList&gt;org.jivesoftware.openfire.sasl.LooseAuthorizationPolicy org.jivesoftware.openfire.sasl.DefaultAuthorizationProvider&lt;/classList&gt;        &lt;!-- other options: null, LdapAuthorizationProvider, UnixK5LoginProvider, Strict and Lazy--&gt;     &lt;/authorization&gt;   &lt;/provider&gt;    &lt;setup&gt;true&lt;/setup&gt;    &lt;log&gt;     &lt;debug&gt;       &lt;enabled&gt;true&lt;/enabled&gt;     &lt;/debug&gt;   &lt;/log&gt; &lt;/jive&gt; </code>

Thomas_Deliduka · October 2, 2007, 9:07pm

Yes, even though it’s a test system (po-test) it is in the AD tree and it has a valid DNS entry. I can see from the debug logs that it is authenticating the users just fine. It seems to just fail somehow on the SSO thing, I don’t understand it. I haven’t heard from slushpupie but I will add the xmpp.domain thing and see if that helps.

Thomas_Deliduka · October 2, 2007, 9:09pm

I went to go add the property to my server but found it was already there. I must not have looked hard enough last time. The value for the xmpp.domain is just the server name “po-test” nothing else. Should it be po-test@CMAOHIO.ORG or should it be just CMAOHIO.ORG