powered by Jive Software

Openfire access from internet

Hi,

We have a Openfire server in comunication via LDAP whit a Microsoft Active Directory in our intranet.

I’d like some help to know if it´s possible connect Spark clients locate out our intranet.

Those clients aren´t registered in Active Directory, but they are locate in a same office.

Could they connect through Internet? Is it possible expose the server?

Could they be registered in the native database whitout belong to Active Directoy?

The security is the most important in this case.

best regards!!

Hi,

Openfire has a hybrid auth provider so it should be possible to use two different data sources for access. You may need to look at the source code to set it up. Maybe it’s more easy to add all users to your AD.

You may want to install a connection manager for the internet users: (Internet users -


connection manager in DMZ -


Openfire). A CM seems to be a XMPP server for the clients, so they will not notice it. And you can shutdown it separately if you want to keep the internet users out.

LG

Javadoc:

org.jivesoftware.openfire.auth.HybridAuthProvider
The hybrid auth provider allows up to three AuthProvider implementations to be strung together to do chained authentication checking. The algorithm is as follows: Attempt authentication using the primary provider. If that fails: If the secondary provider is defined, attempt authentication (otherwise return). If that fails: If the tertiary provider is defined, attempt authentication. To enable this provider, set the following in the XML configuration file: <provider>
     <auth>
         <className>org.jivesoftware.openfire.auth.HybridAuthProvider</className>
     </auth> </provider> The primary, secondary, and tertiary providers are configured as in the following example: <hybridAuthProvider>
      <primaryProvider>
          <className>org.jivesoftware.openfire.auth.DefaultAuthProvider<className>
      </primaryProvider>
      <secondaryProvider>
          <className>org.jivesoftware.openfire.auth.NativeAuthProvider</className>
      </secondaryProvider> </hybridAuthProvider> Each of the chained providers can have a list of override users. If a user is in an override list, authentication will only be attempted with the associated provider (bypassing the chaining logic).
The full list of properties: hybridAuthProvider.primaryProvider.className (required) -- the class name of the auth provider. hybridAuthProvider.primaryProvider.overrideList -- a comma-delimitted list of usernames for which authentication will only be tried with this provider. hybridAuthProvider.secondaryProvider.className -- the class name of the auth provider. hybridAuthProvider.secondaryProvider.overrideList -- a comma-delimitted list of usernames for which authentication will only be tried with this provider. hybridAuthProvider.tertiaryProvider.className -- the class name of the auth provider. hybridAuthProvider.tertiaryProvider.overrideList -- a comma-delimitted list of usernames for which authentication will only be tried with this provider. The primary provider is required, but all other properties are optional. Each provider should be configured as it is normally, using whatever XML configuration options it specifies. @author
Matt Tucker

Following it2000’s suggestion, one idea might be to not use a connection manager but to use a machine in the DMZ that is running a copy of Openfire with embedded database, and restrict the server 2 server interconnectivity between the two to only allow the other server. that way, you have full control over your “internal” openfire with AD, keeping it completely separated from anything else while allowing the “external” openfire server to be reached from the internet.

Hi it2000,

For the solution with connection manager, what are the requirements of hardware in the case of 300+ users from internet. Is Connection manager server in DMZ like Openfire server about resources?. Where are the extern users storaged?. Is the implementation simple?

Thank you for response.

Hi wolfbeest,

For the solution with other Openfire server, how can i run a copy of the original Openfire server?, How can i create the copy? How do i establish the interconnectivity between both servers?. Is necesary federated servers? Is the solution simple?

Thank you for response

davijamo wrote:

Hi wolfbeest,

For the solution with other Openfire server, how can i run a copy of the original Openfire server?, How can i create the copy? How do i establish the interconnectivity between both servers?. Is necesary federated servers? Is the solution simple?

Thank you for response

Actually, you don’t want to make a straight copy of Openfire, but rather make 2 different installations of Openfire: one in the DMZ, and one internally. (ext-jabber.domain.com and int-jabber.domain.com, for example)

So, on a different server machine (either a physical or virtual machine, makes no difference) that is in the DMZ, you install Openfire, and set it up to allow connections from the Internet/office network outside your own LAN for your users who are outside the company. You can choose here to authenticate against a different company user database (that isn’t using Active Directory), by using the embedded one with manually created different users you want to give access to the company jabber server.

In the server to server setup, you tell it to only allow server connections from your other openfire server with a whitelist (server settings > server to server > allowed to connect : whitelist). This way, the “external” users can only see the DMZ Openfire server, but can still chat with “internal” users, and the internal server and active directory is not in any way exposed.

See also the small image I slapped together, hope that clarifies what you could do. It’s relatively easy to set up, and you can do a lot more than what I just said with it, like automatic grouping/rosters, filtering traffic, etc, but this is the basic setup.

Is Connection manager server in DMZ like Openfire server about resources?

It needs some MB, anyhow much less than Openfire. It has no cache, no database, … - it terminates only the client connections.

Where are the extern users storaged?

The users are stored in Openfire (AD, database or other auth provider)

Is the implementation simple?

Yes.

Hi it2000,

In http://www.igniterealtime.org/community/docs/DOC-1031 are the ports and protocols that use Openfire in application layer.

In the solution with Connection manager, what others ports and protocols are used for layers different to application layer? For example TCP, UDP,…

Best regards!

Hi wolfbeest,

In http://www.igniterealtime.org/community/docs/DOC-1031 are the ports and protocols that use Openfire in application layer.

In the solution with other Openfire Server, what others ports and protocols are used for layers different to application layer? For example TCP, UDP,…

It´s very important your response for the implementation.

Best regards!

Hi,

it’s usually enough to open port 5222 TCP (XMPP TLS). A connection manager does not offer the full functionality as Openfire but that’s usually fine.

LG

In this case, the only port that needs to be open between the DMZ and the internal lan is TCP 5269 to connect both servers (note: both directions, lan > dmz and dmz > lan), and that can be further restricted to just the IP of the other server. Everything else can be closed.

As for the other ports in that document, depending on what you plan to use, open the relevant ports.

For only client connections to the server in the DMZ, port 5222 TCP should be all you need, and perhaps 7777 if you wish to let it work as a file proxy too. Since it will be strictly private jabber servers, no other connections to the outside world would be needed from the DMZ.

Hi again,

A new question.

Does the solution work fine through Novell Ichain?

http://www.novell.com/products/ichain/

Thanks for response.

Hi again,

A new question.

Does the solution work fine through Ichain?

http://www.novell.com/products/ichain/

Thanks for response.

I’m not familiar with this product and don’t have time to do this kind of research, but ANY software that filters/routes IP properly shouldn’t be a problem.

It’s regular TCP traffic.

Hi,

Does this solution have costs of license?

Thanks.

Hi,

Does this solution have costs of license?

Thanks.

davijamo wrote:

Hi,

Does this solution have costs of license?

Thanks.

I suggest you look up the licensing information of all the products involved in your solution (Openfire, novell ichain, etc.),to see if there are any costs for the combination of products you use.

Hi,

I´m talking about Openfire only. Does Openfire have some license type? How much is it cost?

Thanks for response.

This process is quite simple really. But you must start with giving your openfire server a real world Fully Qualified Domain Name (i.e. chatserver.domain.com). With any luck your intranet domain is a sub domain of your external domain, meaning they both end the same way (domain.com). If not you can still name your openfire server with an external domain name. Here are the steps (blue are needed if internal domain is onot a sub domain of external domain):

  • Stop the openfire server

  • Edit the openfire.xml setup tag to be <setup>false</setup>

  • Start the openfire server

  • During the re-setup give the server a FQDN for your external domain (i.e chatserver.domain.com) on the second scree in the field Domain

  • Delete any certificates from the server that do not match the new FQDN ([http://localhost:9090/ssl-certificates.jsp|http://localhost:9090/ssl-certificates.jsp]) Restart http as requested

  • Add openfire FQDN to external DNS as an A Record pointing to a real world IP

  • Map the ports you wish to use from attachment below from the external IP to your internal IP on the openfire server on your router, pix, firewall or what ever is between the internet and your intranet

  • Test by accessing the sever via a client pointing to the external FQDN, and test accessing the admin page via the external FQDN

  • Use the external FQDN for all clients, internal and external.

See: Openfire Readme