speedy will be back in a few days. maybe he will see something in these logs. It seems that Ofmeet can’t be used when AD integration is on. It needs to create a focus user locally, but local users are not available when AD integration is used.
Good catch. I’ll sit tight. My environment is running 2.7.7 atm and doing just fine. I’m just preparing to move to 2.8.
Thanks wroot! And speedy! @speedy
the LDAP provider is read only, so you’ll need to create a ldap user called ‘focus’ in your directory. Then within openfire, set the system property org.jitsi.videobridge.ofmeet.focus.user.password
speedy, i think that was a side issue and the main one, that they can’t login with a regular AD user.
I had the same issue where login was unsuccessful with wrong username/password error message. Try to use fully qualified domain name instead IP address, it appeared to work with newly installed Openfire 4.0.3 on Linux environment.
jim, is your issue only with 2.8? you can authenticate to AD with 2.7.7?
Ifan,
Thanks for the response. We currently use the FQDN w/ Spark 2.7.7 w/out issues.
Yes. Only with 2.8. 2.7.7 works flawlessly.
in openfire admin console, look at the main page; under “Server Information” > “Sever Properties” > “Server name”. What do you have for “Server Name”
is that different than what you are using with spark on the login screen for “server”? If so, change this to match what you have in openfire.
1 Like
Yes it is different. When I change the Spark server entry to reflect the OpenFire Server Name, it works.
Clients outside the network look at the external FQDN though. What changes do I need to make to allow them to continue to connect with their current configuration from outside of our network?
So the "“Server Name”, really should be “xmpp domain”, and as I understand, this is a carry over from years past…and there is talk to change this. anyway, there are a few options…
- use dns (and maybe srv records)
2, use the advance button on login, uncheck “automatically discover host and port” and enter the host info if different than “server name”
with the next release, we’ve added a “host name” override, to work around this as well, but its not recommended…
1 Like
Please be patient with me. I’m a little confused.
As we are currently configured, we have an external dns record taking xmpp traffic to im.domain.com and pointing it to the local 10. openfire server. This setup works for Spark 2.7.7, Jitsi, and Xabber, to name the few I’ve tried.
I’m not sure what changes (or why) would need to be made considering external DNS seems to be routing the traffic just fine.
As per #2, I had been trying that option to no avail.
Thanks for all your kind help and direction, guys.
option 2 requires the matching server name in addition to manually entering the host info.
so to go back to the dns part.
when you installed openfire, its likely the “server name” or XMPP Domain configured was in fact the short computer name. like SERV1, as the default during setup uses the computer name if not changed during setup. The SSL certificate is then created using “SERV1”. The other clients you mentioned probably gave your a certificate warning that you accepted . Spark 2.7.7 would just accept the mismatch, but not give a warning. Spark 2.8 would detect the mismatch and drop the connection, giving the error “username and password” error. that incorrect message will be fixed in 2.8.1.
you’re best option would be to use DNS. Change your xmpp domain to im.domain.com, update your admin jid properties to reflect the new domains (so you don’t get locked out of the admin console), deleted and recreated the certificates, and you should be good to go
1 Like
Or Option 3: Wait for Spark 2.8.1
Thanks Speedy!
well, option 3, would be to disable the hostname verification, but again, that’s not recommended. Id recommend updating your xmpp domain and using dns
1 Like
Ironically, external users are the ones you want to protect/control the most. So using correct certificate and recommended settings is the way to go, imho. Btw, you might want to install current test builds first, as i plan to change “Accept all certificates” to disabled by default for 2.8.1. Currently it is enabled. latest build: http://download.igniterealtime.org/spark/dailybuilds/spark_2_8_0_900.exe
2 Likes
But as you want to use the “disable hostname check” option, you will still need to instruct your users to check that setting. So they will need to also check the “accept all certificates”. So, you can wait for 2.8.1.
Yes. lol. About that. I haven’t configured OpenFire to use SSL yet for client communications…
According to the documentation:
As of Openfire 3.2 certificate management can be performed from the Admin Console
But there’s a whole lot of Stores under Certificate Stores. Oh boy.
wroot wrote:
But as you want to use the “disable hostname check” option, you will still need to instruct your users to check that setting. So they will need to also check the “accept all certificates”. So, you can wait for 2.8.1.
Yes, indeedy