User Restrictions and Inactive Accounts

Hello,

I want to begin by apologizing for my lack of knowledge since I am a newbie to Openfire. Nevertheless, I am hoping that you can help.

I have successfully setup our Openfire server using our Active Directory LDAP. I am also able to use Spark for client communication. Here are the versions that I am using:

Server: Openfire 3.6.3

Clients: Spark 2.5.8

But before I roll it out to our company, I have been asked for certain configuration changes to be made first:

  1. I need to restrict regular users to only IM with supervisors but allow supervisors to IM with anyone in the system. How do I set this up (keeping in mind that our users and groups are imported from AD–if this makes a difference)?

  2. I need to make sure that the users’ ability to manually add other users their contact list has been disabled.

  3. In the administrator’s console, all of the users from our AD are showing up, including accounts that have been disabled. Since our corporate policy is not to remove departing employees from our system but to disable them, how can I limit the users to active AD accounts?

Thank you in advance for any help that you can provide!

  1. This would require the packet filter plugin and I am not even sure it can be done that way.
  2. This is done via the subscription plugin. Set it to reject all. This will include every chat user including admins (no way to avoid that)
  3. This means your baseDN is too wide, or that you need to filter based on account status. Personally I do not use many filters because they do affect performance to a degree. I Would suggest cleaning up your AD OU structure to make it more LDAP friendly. Create an OU that conatins OUs for LDAP users and groups. Create an OU containig OUs for Non-LDAP users and groups. Creat and OU containing OUs for computer workstations. Create and OU for disabled accounts.

sample user filter ((objectClass=organizationalPerson)(!(userAccountControl:1.2.840.113556.1.4.803 :=2)))

Todd,

Thank you for your help! Hopefully I can make a few clarifications and ask a couple of questions:

  1. If I can restrict the regular users’ ability to manually add other users to their contact list and limit their Friends/Groups to the supervisors, then wouldn’t this work? But this leads me back to…

  2. I have installed the Subscription plugin and set the Subscription Properties to Reject All. However, even after restarting the server, I can log in to a regular user’s account in Spark, select Add Contact from the Contacts menu, enter another users’ username and then click Add and it works. The other user shows up as Pending. The next time I log in as the same regular user, the other user is now included in the list of friends.

Which also leads me to another question. Is it possible to share a contact list group with another group while not sharing it with the group itself? The way I see it, If I could restrict the ability of regular users to only have access to the supervisors group while enabling the supervisors to share the regular users group, then I think my dilemma would be solved.

  1. I agree with your assessment. I’ll reogranize my OUs. Thanks for reminding me of the obvious answer!

Again, I appreciate your prompt assistance!

The users should never go beyond a pending state if the subscription plugin is doing its job. You could combine this with the packet filter plugin an configure it to reject chat between group members.

It is not possible to share a contact list without sharing it to the members of the group.

Todd,

Thank you again for your help! However, I am still having the same problem with the Subscription plugin. A regular user in Spark can select Add Contact from the Contacts menu, enter another users’ username and then click Add. The other user is then included as a Pending status.

The good news is that the next time this other user logs in, s/he is never given the option to accept the contact request. The bad news is that when the user making the request logs in again, the other user is now included in their list of friends. The other user never even approved the request and they are now included as the requesting user’s Friend.

Is this a bug in the Subscription plugin itself? If so, it seems to render the plugin functionally useless with Spark. I have checked the System Properties of the Administration Console and the following properties are listed:

plugin.subscription.level: all

plugin.subscription.sparkCheck: true

plugin.subscription.type: reject

Any more thoughts?