Openfire: Effectively Managing Users

In this article by Mayank Sharma , you will learn how to effectively manage users in Openfire.

The difference between a hassled always-on-the-job admin and an admin who has plenty of time to dress for a lovely date in the evening, is how effectively they manage their users. As any admin knows, managing users is one thing, but managing users effectively takes something special—from both you and the server software. In this article, I'll show you some tips and tricks that you can use to become a happy-go-lucky system admin. But finding a beautiful date is beyond the scope of this book!

Despite the way it sounds, managing users isn't an all-involving activity—at least it shouldn't be. Most system administrators tend to follow the "install-it-forget-it" methodology to running their servers. You can do so with Openfire as well, but with a user-centeric service such as an IM server, keeping track of things isn't a bad idea. Openfire makes your job easier with its web-based admin interface.

There are several things that you can setup via the web interface that'll help you manage the users. You can install some plugins that'll help you run and manage the server more effectively, such as the plugin for importing/exporting users, and dual-benefit plugins such as the search plugin, which help users find other users in the network, and also let you check up on users using the IM service.

In this article, we will cover:

• Searching for users
• Getting email alerts via IM
• Broadcasting messages to all users
• Managing user clients
• Importing/exporting users

Searching for Users with the SearchPlugin

Irrespective of whether you have pre-populated user rosters, letting users find other users on the network is always a good idea. The Search Plugin works both ways—it helps your users find each other, and also helps you, the administrator, to find users and modify their settings if required.

To install the plugin, head over to the Plugins tab (refer to the following screenshot). The Search plugin is automatically installed along with Openfire, and will be listed as a plugin that is already installed. It's still a good idea to restart the plugin just to make sure that everything's ok. Locate and click the icon in the Restart column that corresponds to the Search plugin. This should restart the plugin.

The Search plugin has various configurable options, but by default the pluginis deployed with all of its features enabled. So your users can immediately start searching for users.

To tweak the Search plugin options, head over to the Server | Server Settings |Search Service Properties in the Openfire admin interface. From this page, you can enable or disable the service. Once enabled, users will be able to search for other users on the network from their clients. Not all clients have the Search feature but Spark, Exodus, Psi, and some others do.

Even if you disable this plugin, you, the admin, will still be able to search for users from the Openfire admin interface as described in the following section.

In addition to enabling the Search option, you'll have to name it. The plugin is offered as a network "service" to the users. The Openfire server offers other services and also includes the group chat feature which we will discuss in the Appendix. Calling the search service by its default name, search.< your-domain-name > is a goodidea. You should only change it if you have another service on your network with the same name.

Finally, you'll have to select the fields users can search on. The three options available are Username , Name , and Email (refer to the previous screenshot). You can enable any of these options, or all the three for a better success rate. Once you're done with setting up the options, click the Save Properties button to apply them.

To use the plugin, your users will have to use their clients to query the Openfire server and then select the search service from the ones listed. This will present them with a search interface through which they'll be able to search for their peers(refer to the following screenshot) using one or more of the three options (Username ,Name , Email ), depending on what you have enabled.

Searching for Users from Within The Admin Interface

So we've let our users look for their peers, but how do you, the Openfire admin, look for users? You too can use your client, but it's better to do it from the interface since you can tweak the user's settings from there as well. To search for users from within the admin interface, head over to the Users/Groups tab. You'll notice an AdvancedUser Search option in the sidebar.

When you click on this option, you'll be presented with a single text field withthree checkboxes (refer to the previous screenshot). In the textfield, enter the user'sName, Username, and Email that you want to find. The plugin can also handle the * wildcard character so that you can search using a part of the user's details as well.For example, if you want to find a user "James", but don't know if his last name isspelled "Allen" or "Allan", try entering "James A*" in the search field and make sure that the Name checkbox is selected. Another example would be "* Smith", which looks for all the users with the last name "Smith".

The search box is case-sensitive.

So why were you looking for "James Allan", the guy with two first names? It was because his last name is in fact "Allen" and he wants to get it corrected. So you find his record with the plugin and click on his username. This brings up a summary of his properties including his status, the groups he belongs to, when he was registeredon the network, and so on. Find and click the Edit Properties button below the details, make the required changes, and click the Save Properties > button.

This article has been extracted from: Openfire Administration

A practical step-by-step guide to rolling out a secure Instant Messaging service over your network Build a feature-packed Instant Messaging network using free open-source Openfire server Set up an efficient and secure IM service that spans multiple offices Connect with users over external IM networks, integrate VoIP, and more Easy to understand, with clear step-by-step instructions and examples For more information, please visit: http://www.packtpub.com/step-by-step-guide-to-openfire-administration/book

Get Email Alerts via IM

Instant Messaging is an alternate line of enterprise communication, along with electronic ones such as email and traditional ones such as the telephone. Some critical tasks require instant notification and nothing beats IM when it comes to time-critical alerts.

For example, most critical server software applications, especially the ones facing outwards on to the Internet, are configured to send an email to the admin in case of an emergency—for example, a break-in attempt, abnormal shutdown, hardware failure, and so on. You can configure Openfire to route these messages to you as an IM, if you're online. If you're a startup that only advertises a single [email protected] email address which is read by all seven employees of the company, you can configure Openfire to send IMs to all of you when the VCs come calling!

Setting this up isn't an issue if you have the necessary settings handy. The email alert service connects to the email server using IMAP and requires the following options:

• Mail Host: The host running the email service. Example: imap.example.com
• Mail Port: The port through which Openfire listens for new email. SSL can also be used if it is enabled on your mail server. Example: 993.
• Server Username: The username of the account you want to monitor.Example: [email protected].
• Server Password: The accounts password.
• Folder: The folder in which Openfire must look for new messages. Typically this will be the "Inbox" but if your server filters email that meet a preset criteria into a particular folder, you need to specify it here.
• Check Frequency: How frequently Openfire should check the account for new email. The default value is 300000 ms which is equal to 5 minutes.
• JID of users to notify: This is where you specify the Openfire Jabber IDs(userids) of the users you want to notify when a new email pops up. If you need to alert multiple users, separate their JID's with commas.

But first head over to the Plugins tab and install the Email Listener plugin from the list of available plugins. Once you have done this, head back to the Server tab and choose the Email Listener option in the sidebar and enter the settings in the form that pops up (refer to the following screenshot). Click the Test Settings button to allow Openfire to try to connect to the server using the settings provided. If the test is successful, finish off the setup procedure by clicking the Save button to save your settings. If the test fails, check the settings and make sure that the email server is up and running. You can test and hook them with your Gmail account as well.

That's it. Now close that email client you have running in the background, and let Openfire play secretary, while you write your world domination application!

Broadcasting Messages

Since Openfire is a communication tool, it reserves the coolest tricks in the bag for that purpose. The primary purpose of Openfire remains one-to-one personal interactions and many-to-many group discussion, but it can also be used as a one-to-many broadcasting tool.

This might sound familiar to you. But don't sweat, I'm not repeating myself. The one-to-many broadcasting we cover in this section is different from the Send Message tool. The Send Message tool from the web-based Openfire administration console is available only to the Openfire administrator. But the plugin we cover in this section has a much broader perspective.

For one, the Broadcast plugin can be used by non-admin users, though of course, you can limit access. Secondly, the Broadcast plugin can be used to send messages to a select group of users which can grow to include everyone in the organization using Openfire.

One use of the broadcast plugin is for sending important reminders. Here are some examples:

• The Chief Accounts Officer broadcasts a message to everyone in the organization reminding them to file their returns by a certain date.
• The CEO broadcasts a message explaining the company's plans to merge with or acquire another company, or just to share a motivational message.
• You, the Openfire administrator, use the plugin to announce system outages.
• The Sales Department Head is upset because sales targets haven't been met and calls for a group meeting at 10:00 a.m. on the day after tomorrow and in forms everyone in the Sales department via the plugin.
• The intern in the advertisement department sends a list of his accounts to everyone in the department before returning to college and saves everyone a lot of running around, thanks to the plugin.

Setting up the Plugin

To reap the benefits of the Broadcast plugin, begin by installing it from under theAvailable Plugins list on the Plugins tab. This plugin has a few configuration options which should be set carefully—using a misconfigured broadcast plugin, the new guy in the purchase department could send a message of "Have you seen my stapler?" to everyone in the organization, including the CEO!

The broadcast plugin is configured via the Openfire system properties. Remember these? They are listed under the Server tab's System Properties option in the sidebar. You'll have to manually specify the settings using properties (refer to the following screenshot):

• plugin.broadcast.serviceName — This is the name of the broadcast service. By default, the service is called "broadcast", but you can call it something else, such as "shout", or "notify".
• plugin.broadcast.groupMembersAllowed — This property accepts two values—true and false. If you select the "true" option, all group members will be allowed to broadcast messages to all users in the group they belong to. If set to "false", only group admins can send messages to all members of their groups. The default value is "true".
• plugin.broadcast.disableGroupPermissions — Like the previous property, this property also accepts either true or false values. By selecting the "true" option, you will allow any user in the network to broadcast messages to any group and vice versa, the "false" option restricts the broadcasting option to group members and admins. The default value of this group is "false". As you can imagine, if you set this value to "true" and allow anyone to send broadcast messages to a group, you effectively override the restrictive value of the previous setting.
• plugin.broadcast.allowedUsers —Do not forget to set this property! If it is not set, anyone on the network can send a message to everyone else on the network. There are a only a few people you'd want to have the ability to broadcast a message to everyone in the organization. This list of users who can talk to everyone should be specified with this property by a string of comma-separated JIDs.

In most cases, the default options of these properties should suffice. If you don't change any variables, your service will be called "broadcast" and will allow group members to broadcast messages to their own groups and not to anyone else. You should also add the JIDs of executive members of the company (CEO, MD, etc.) to the list of users allowed to send messages to everyone in the organization.

Using The Plugin

Once you have configured the plugin, you'll have to instruct users on how to use the plugin according to the configuration. To send a message using the broadcast plugin, users must add a user with the JID in the following format @. (refer to the following screenshot).

If the CEO wants to send a message to everyone, he has to send it to a user called [email protected] , assuming that you kept the default settings, and that your Openfire server is called serverfoo. Similarly, when members of the sales department want to communicate with their departmental collegues, they have to send the message to [email protected] .

Managing User Clients

There's no dearth of IM clients. It's said that if you have ten users on your network, you'll have at least fifteen different clients. Managing user's clients is like bringing order to chaos. In this regard you'll find that Openfire is biased towards its own IMclient, Spark. But as it has all the features you'd expect from an IM client and runs on multiple platforms as well, one really can't complain.

So what can you control using the client control features? Here's a snapshot:

1. Don't like users transferring files? Turn it off, irrespective of the IM client.
2. Don't like users experimenting with clients? Restrict their options
3. Don't want to manually install Spark on each and every user's desktop? Put it on the network, and send them an email with a link, along with installation and sign-in instructions.
4. Do users keep forgetting the intranet website address? Add it as a bookmark in their clients.
5. Don't let users bug you all the time asking for the always-on "hang-out"conference room. Add it as a bookmark to their client!

Don't these features sound as if they can take some of the work off your shoulders? Sure, but you'll only truly realize how cool and useful they are when you implement them! So what are you waiting for? Head over to the Plugins tab and install the Client Control plugin. When it is installed, head over to the Server | ClientManagement tab. Here you'll notice several options.

The first option under client management, Client Features , lets you enable or disable certain client features (refer to the following screenshot). These are:

1. Broadcasting : If you don't want your users to broadcast messages, disable this feature. This applies only to Spark.
2. File Transfer : Disabling this feature will stop your users from sharing files.This applies to all IM clients.
3. Avatar/VCard : You can turn off indiscriminate changes to a user's avatar or virtual visiting card by disabling this experimental feature which only applies to Spark.
4. Group Chat : Don't want users to join group chat rooms? Then disable this feature which will prevent all the users from joining discussion groups, irrespective of the IM client they are using.

By default, all of these features are enabled. When you've made changes as per your requirements, remember to save the settings using the Save Settings button.

Next, head over to the Permitted Clients option (refer to the following screenshot) to restrict the clients that users can employ. By default, Openfire allows all XMPPclients to connect to the server. If you want to run a tight ship, you can decide to limit the number of clients allowed by selecting the Specify Clients option button. From the nine clients listed for the three platforms supported by Openfire (Windows,Linux, and Mac), choose the clients you trust by selecting the checkbox next to them.If your client isn't listed, use the Add Other Client text box to add that client. When you've made your choices, click on the Save Settings button to save and implement the client control settings.

The manually-added clients are automatically added to the list of allowed clients. If you don't trust them, why add them? The remove link next tothese clients will remove them from the list of clients you trust.

This article has been extracted from: Openfire Administration

A practical step-by-step guide to rolling out a secure Instant Messaging service over your network Build a feature-packed Instant Messaging network using free open-source Openfire server Set up an efficient and secure IM service that spans multiple offices Connect with users over external IM networks, integrate VoIP, and more Easy to understand, with clear step-by-step instructions and examples For more information, please visit: http://www.packtpub.com/step-by-step-guide-to-openfire-administration/book

If Spark is one of the IM clients your users are allowed to use, Openfire will help you manage and roll out new versions of Spark for various plantforms as they are relaeased. From the Spark Version option in the sidebar, you can upload versions of Spark for each of the three platforms it supports—Linux, Windows,and Mac. You can also place them in the directory specified on that page(such as C:Program FilesOpenfireenterprisespark ).

In case you have multiple Spark versions for a particular platform, such as when a new version is released, you have the option of selecting an Active client (refer tothe previous screenshot). If the "Active" version is a newer version the one currently deployed, users on the network will automatically be notified that a new version is available for download. The page also has an Optional Message text box that you can use to specify a short message that users will see when downloading the client from the Openfire server.

Unlike an update, when you deploy the Openfire server for the first time, sending IM updates to users wouldn't do them any good. In this case, you can use Openfire's direct download links to download Spark. Under the Download Spark option in Openfire Enterprise, there are three sets of download links, one each for the three platforms on which Spark can run (refer to the screenshot above). Below the download links is a template email blurb that you can send to all of your users. The email informs the users of the new IM server that you have deployed and has instructions on downloading a client (Spark) for their platform as well as information on logging on.

Before the users get their hands on Spark, it's a good idea to load them with important bookmarks (refer to the screenshot above). Then you can include this information in the introductory email as well. Wouldn't your users love you if you told them that all of the important intranet URLs and the settings page are bookmarked in their clients and that if they ever run into any problems they should join and ask for solutions in the bookmarked troubleshoot chat room, the company's always-on IT helpline. You'll be a demigod! All hail the Openfire admin!

Private Data Storage

Do your users move around a lot? If yours is a terminal server environment where users don't have a fixed computer but rather they log in to the server (which stores their files) from any machine, it doesn't make sense to store the user's settings on a particular machine. Openfire can support this setup by aping the network settings and storing user files on the server instead of a local machine. This is done via thePrivate Data option.

Using private data storage, all XMPP/Jabber clients store their settings, group and web bookmarks, and so on, for every user on the Openfire server. This allows users the freedom to log into their account from any machine on the network, and their settings will follow them around.

To enable this feature, head over to Server | Server Settings | Private Data Storage (refer to the previous screenshot). All you have to do now is choose the Enable Private Data Storage option button and save the settings. If, on the other hand, you'd rather bind a user's settings to the machine from which they first log into the server, choose the Disable Private Data Storage option.

Importing/Exporting Users

Coming back to reality, there are only very few things in an admin's list of things that come close to a server migration. My 10-year veteran admin friend thinks there's nothing like a server migration to make your day! For him, migration involves a huge checklist and a wasted weekend. But if you use Openfire, you can retain your happy-go-lucky charm and get the job done before your users return from lunch.

Migration is actually a small subset of a bigger problem. There are a couple of situations that can very well be described as an admin's worst nightmare:

1. Moving over to Openfire: Ok, so this isn't totally a waste of effort—you do get a quality IM server at the end of the day. But exporting all of the users,their settings, and their rosters and then importing them into the new server can be quite a hassle.
2. Moving from one Openfire server to another: So your old server is slowly bleeding to death. You love the beast but you've got to cut it loose. Not only do you now have to export data from the old server and then import it into the new server, but you also have to take into account the new domain/server name. You shiver in fear—or excitement!

It might sound retro, but whatever the case maybe, have no fear, Openfire is here. Irrespective of whether you are switching servers, or moving users from an existing XMPP/Jabber IM server into Openfire, you're doing the right thing and you know you're doing the right thing because Openfire makes the process a walk-in-the park—thanks to the user Import/Export plugin.

The user Import/Export plugin lets you import and export Openfire user data via the Admin Console. This user data includes usernames, passwords, names, emailaddresses, creation and modification dates, and roster lists. Also, as I said, this plugin helps you when migrating users from other Jabber/XMPP based systems to Openfire.

Using The Plugin

For all the tough work it does, the plugin is relatively simple to use. Install it from the list of Available Plugins under the Plugins tab. Then head over to the Users/Groups tab where you'll notice a new Import & Export sub-tab. Clicking on this brings you to a simple page with two links—one to import user data, and the other to export user data.

Openfire data is exported as an XML file. There are two options when exporting user data. You can either save the export data to a file name or have it displayed on the screen and then copy-paste it to wherever you want to (refer to the following screenshot).

Select the To File option by clicking on the option button adjacent to it and specifya file name in the Export File Name: text box. When you click on the Export button,the Openfire user XML data will be saved to the file you specified.

The other option is to copy-paste the data yourself. Some administrators might prefer this option to save the data in multiple places or on remote machines. To export the data manually, choose the To Screen option button and click on the Export button. This displays the data in the text box provided.

Be careful when exporting user data, because all of the user passwords in the exported XML file are displayed unencrypted as plain text and can be used by anyone. It's not a bad idea to ask users to change their passwords immediately after you have completed the migration process.

You can import data into Openfire via an XML file imported from an XMPP/Jabberserver. On the import page (refer to the following screenshot), the Browse buttonwill help you locate the file that contains the user information. When you have the file, click on the Import button. This starts the import process.

When the plugin has successfully imported all user data, it will display a message stating All users added successfully . However, if the plugin was not successful in importing all user data, it will display an error message indicating what might have gone wrong. You can resolve the error and try again. Don't worry about duplicate data when resuming a broken import. If the plugin detects a user that already exists in the system, it will skip importing that user or its roster information.

During the import process, you also have the option of changing the domain name of the data being imported from the old domain to the new domain. To do this, after selecting the file to import the data from, in the Import User Data section, specify the old domain name as mentioned in the import file in the Replace Domain text field. Now when Openfire imports the data, it will replace all instances of the old domain, such as in roster information, with the domain name of the Openfire server you are importing the data into.

Here is a sample of an exported user list from the plugin's readme file. It contains two users, Joe and Sally, who have added each other to their respective rosters.

<?xml version="1.0" encoding="UTF-8"?>
<Openfire>
<User>
<Username>joe</Username>
<Password>joepwd</Password>
<Email></Email>
<Name></Name>
<CreationDate>1125601449177</CreationDate>
<ModifiedDate>1125601449177</ModifiedDate>
<Roster>
<Item jid="sally@localhost" askstatus="-1" recvstatus="-1"
substatus="3" name="Sally">
<Group/>
</Item>
</Roster>
</User>
<User>
<Username>sally</Username>
<Password>sallypwd</Password>
<Email></Email>
<Name></Name>
<CreationDate>1125601471848</CreationDate>
<ModifiedDate>1125601471848</ModifiedDate>
<Roster>
<Item jid="joe@localhost" askstatus="-1" recvstatus="-1"
substatus="3">
<Group/>
</Item>
</Roster>
</User>
</Openfire>

Notice the different status types? Here is a list of all of the different status types, witha brief description, also from the plugin's readme file.

askstatus

• -1—The roster item has no pending subscription requests.
• 0—The roster item has been asked for permission to subscribe to its presence but no response has been received.
• 1—The roster owner has asked the roster item to be unsubscribed from its presence notifications but hasn't yet received confi rmation.

recvstatus

• 1—There are no subscriptions that have been received but not presented to the user.
• •    1—The server has received a subscribe request, but has not forwarded it to the user.
• •    2—The server has received an unsubscribe request, but has not forwarded it to the user.

substatus

• 1—Indicates that the roster item should be removed.
• 0—No subscription is established.
• 1—The roster owner has a subscription to the roster item’s presence.
• 2—The roster item has a subscription to the roster owner’s presence.
• 3—The roster item and the owner have a mutual subscription.

 

Summary

In this article, we’ve explored several ways of effectively administrating users. The tips and tricks covered in the article will help you no matter how many users you have on the network— three or three thousand. Openfire can scale effortlessly as your organization grows, and thanks to some very useful accessories, you’ll be saved a lot of headache when it does If you are using an existing IM server, you can start enjoying the benefits of Openfire right from the word go. This article has detailed how you can import user data into their roster lists from any XMPP server to Openfire. The tool that helps you do this can also be used to export this data when switching servers and adjusting your domain name when migrating the server to another domain.

We’ve then seen how easily you can maintain decorum in conversations. Openfire can also work along with email to alert you of important messages. But it’s in a class of its own when it comes to doing what it’s designed to do—help you communicate. We’ve covered tools that’ll help members of the organization broadcast messages to their peers based on preset company rules. We have also discussed the client control features of the Enterprise version. If you want to run a tight ship, the Enterprise plugin can let you limit the number of IM clients authorized to interact with Openfire server in addition to disabling certain features. You can also use the Enterprise tools to place versions of Spark (Openfire’s official IM client) on the network and alert users to grab the latest version from the intranet, saving valuable bandwidth and leaving you in charge. Ah, every admin’s dream come true!

This article has been extracted from: Openfire Administration

A practical step-by-step guide to rolling out a secure Instant Messaging service over your network Build a feature-packed Instant Messaging network using free open-source Openfire server Set up an efficient and secure IM service that spans multiple offices Connect with users over external IM networks, integrate VoIP, and more Easy to understand, with clear step-by-step instructions and examples For more information, please visit: http://www.packtpub.com/step-by-step-guide-to-openfire-administration/book

About the Author

Mayank Sharma is a contributing editor at SourceForge, Inc's Linux.com. He also writes a monthly column for Packt Publishing. Mayank has contributed several technical articles to IBM developerWorks where he hosts a Linux Security blog. When not writing, he occasionally teaches courses on Open Source topics at the Indian Institute of Technology, Delhi, as Industry Expert.

 

http://translate.google.cn/translate?hl=zh-CN&sl=en&u=http://yc75.iteye.com/blog/355890