OpenFire Shared roster in two AD domains

I have two OpenFire servers with LDAP authorization. AD groups in both domains named “Jabber” and shared Rosters for them. Server to server transport works whell, i can send message from user@jabber.domain1.local to user@jabber.domain2.local.

  1. How can I populate openfire Roster/users from domain1.local to openfire Roster domain2.local?
  2. How can I get the online status for the other domain openfire users?

Or, maybe, i can add contacts from domain2.local to Openfire roster within domain1.local?

I’m not seeing a fast way of automating this. Openfire groups are specific to the domain that they’re defined in, and aren’t really usable on another domain.

Users on any domain can add users on the other domain to their roster, which implicitly causes them to subscribe to the presence of the user. That’s the manual way of doing things, which is probably not what you’re asking.

You could manually create groups in the admin console that holds users from both domains, but that is cumbersome to maintain.

Perhaps a new custom GroupProvider implementation needs to be created somehow, that can connect to both AD servers, and somehow combine all users in groups. I’m not sure if this is feasible.

is there a trust between the AD domains? If not, I don’t see a way of doing this. sounds like you want realm xyz to push/publish roster groups to realm 123. and vice versa. then you’d have to figure out a way way to handle the permissions of the publish group. Will everyone get the roster, or would it be published to selected users of 123?

1 Like

Yes, there is trust between this two domains. I created Local Security Group and added users from the second domain into the group, and a can’t see users from second domain in the roster.

are the domains part of the same forest? have you tried connecting to the global catalog?

Domains are part of different trees in one forest. How can i connect to the global catalog?

determine which of your DC is also a global catalog, and connect on port 3268 (LDAP) or 3269 (LDAPS), instead of 389/636. You’ll then want to make your search filter the root of the forest, not the domain.
keep in mind, depending on what you use for “username” you could run into duplications.