Unable To Search Users - Active Directory

Openfire Openfire Support
1

Hello Everyone,

I just got Openfire installed and that was a major hassle, as I used the .deb package (Running on Debian 5.0 Lenny) but it installed the files under /etcopenfire but only a couple. In order for it to work I had to get the tar files and copy them over raw into the /usr/bin/openfire cretaing two different openfire.xml files. No big deal as it is running now and connected to mysql database.

the issue is when we try to connect it to Microsoft Windows 2003 Active Directory it authenticates successfully and moves on to the “User Mapping” were it fails with the following error:

Test: User Mapping

A
random profile is selected for you to review. Bold fields with no value
mean that an error may have been found. To view another profile click
‘Next random profile’. When you are finished close this window.

Status: Error

No users were found using the specified configuration. Try changing the base DN, user filter or username field.

In the webGUI the “Username Field:” is set to “uid” and the “User Filter:” is left blank. I have tried numberous combinations on the “BaseDN:” under the “Connection Settings:” Here is the basic line I add to get authetication:

ou=state, dc=xyz, dc=com

The above ou=state is not the actual ou it is just based off the state the branch office is in, which we only have one now. The dc=xyz is not the actual name used but it is a single line with no spaces or periods.

Here is our openfire.xml file after i skipped using LDAP / Active Directory and went with the “default” settings

<?xml version="1.0" encoding="UTF-8"?> 9090 9091 en org.jivesoftware.database.DefaultConnectionProvider com.mysql.jdbc.Driver jdbc:mysql://servername:3306/openfire dbusername dbpassword select 1 true true 5 25 1.0 true

Is there anything I can add manual to get the Openfire application to pull the Active Directory users though editing the openfire.xml file or does it have to be through the WebGUI?

If I can edit the openfire.xml file does anyone have an example of a fully functional openfire.xml file i can use as a template?

If not then how in the world do I get this to communicate with the Active Directory server to find users and add them?

I have search the forums all day only to find references to things such as:

(&(objectClass=organizationalPerson)(memberOf=cn=IM,dc=domain,dc=com))

However I don’t understand where this type of information is suppose to go?

Any and all suggestions are welcomed with open eyes, PLEASE help because the Net Admin and myself are at our wits end trying to get this working and we really want to use this software!

Thank you!

2

it is virtually impossible to diagnose issues like this with fake trees. You could always use the legitimate structure of your ad tree but change the name of the domain to somthing like mycompany.com.

3

Did you read this: http://www.igniterealtime.org/community/docs/DOC-1554

4

Sorry about not being able to provide the actual LDAP info and it is a good idea to use mycomputer.com so I will keep that in mind.

I found a solution in the manor of which the BaseDN was written. I used a tool called “Adsiedit.msc” which takes the Active Directory tree and displays it in an LDAP format using OU and DC variables. This allowed me to better understand how the Active Directory Treet was organized (I did not set it up) and in turn provided me the needed information.

I still have a couple issues to battle, the first being that in the AdminDN I had to go all the way down to my specific user CN= and provide my domain password, this bothers me. Here is that AdminDN:

CN=MYUsername,OU=Engineering,OU=Users,OU=Ohio,OU=My Company,DC=mycompany,DC=local

Is there a way to make it so that any domain admin has the AdminDN?

Here is the LDAP Tree:

Naming Context = My Company

DC= mycompany.local

OU=My Company

OU=Ohio

OU=Users

OU=Administrative

CN=FirstName LastName

OU=Customer-Care

CN=FirstName LastName

OU=Engineering

CN=FirstName LastName

OU=Executive

CN=FirstName LastName

OU=Former

CN=FirstName LastName

OU=Installation

CN=FirstName LastName

OU=Marketing

CN=FirstName LastName

OU=Operations

CN=FirstName LastName

OU=Printer PC

CN=FirstName LastName

OU=Research

CN=FirstName LastName

OU=RMA

CN=FirstName LastName

OU=Sales

CN=FirstName LastName

OU=Service

CN=FirstName LastName

OU=Shipping

CN=FirstName LastName

OU=Support

CN=FirstName LastName

OU=Test-User

CN=FirstName LastName

The second issue is with the groups. When I was going through the setup time before last I was able to get it to find the groups however each group had zero users, but the users were pulled and they can log into the Spark client with no issues.

Here is the BaseDN:

OU=Users,OU=Ohio,OU=My Company,DC=mycompany,DC=local

The groups are each of the OU’s under OU=Users and the users I need in each group is under that OU as a CN.

Here are the values under System Properties:

ldap.groupDescriptionField = adminDescription

ldap.groupMemberField = members

ldap.groupNameField = OU

ldap.groupSearchFilter = (objectClass=group)

I know that it is due to these above values being wrong or the BaseDN not being correct, however I am not sure what are the correct values I need to put into these fields for it to work correctly.

Suggestions?

Thanks a Million!

5

Not sure how much help I can be as I’m just learning and I’m having similar problemw with groups.

First, I’m using Openfire version 3.6.4 on a WIndows 2003 platform. I know your platform is Debian – what version Openfire are you using?

Second, the admin account to logon to the Openfire Admin Console does not need to be an Active Directory domain admin account. I created a domain account called chatAdmin, put it into the BaseDN for simplicity, and gave it no permissions other than Domain Users. I use this account only to logon to the Openfire Admin Console.

I have the same problem with security groups in that my groups show up with 0 members in the Group Summary page. Unlike your situation, the users in these groups are NOT able to logon to Openfire. Are the AD accounts of the members in your security groups located in the OU tree of your BaseDN? That would explain why they are able to logon.

As for your ldap search parameters, I’m sure ldap.groupNameField should be “cn”, not “ou”. Other than that I don’t know since my groups are not working either. My ldap.groupMemberField is “member”. I changed it to match the value “members” that you list, but the change did not resolve the problem. I think the key is ldap.groupSearchFilter, but as far as I can tell the default “(objectClass=group)” should work, and whenever I make any changes to that value the groups no longer show up at all.

I’ve posted twice requesting assistance for this issue and so far no one has responded. I get the feeling most of the experts in this community are linux gurus and are not sure what to to with Microsoft’s implementation of LDAP.

I was also wondering if this problem is a glitch in version 3.6.4. I’m tempted to download an older version and see if the problem persists.

6

It looks like you’re making things a little more complicated then they need to be. Try this

set yoru basedn to your AD root

DC=company,DC=local

edit ldap.searchFilter
This is what I like to use. you can edit it to your needs, but it reads all of AD and pulls from users with email address, then filters out disabled users,system accounts, and computer acccounts

(objectclass=person)(mail=*)(!(objectclass=computer))(!(objectclass=contact))(!( cn=SystemMailbox))(!(cn=IUSR))(!(cn=IWAM))(!(userAccountControl:1.2.840.11 3556.1.4.803:=2)))

Next do the same for your Groups

edit ldap.groupSearchFilter

In my example, all my openfire groups start with _IM, so my filter will only list those groups.

(objectClass=group)(cn=_IM*)

Since your basedn is root, it doesn’t matter where your users are or your groups. I hope this helps

7

Thanks, but the problem is not locating resources. At least not in my case, and I think the original poster got around that problem.

For now I have all resources in the BaseDN. The problem is that the security groups I create in the BaseDN show up with no members, even though in AD they do have members. My post is here for additional info:

Ultimately, once I’m through with testing, the Openfire implementation will be used in an Active Directory environment with tens of thousands of objects, so in my case it wouldn’t do to set the BaseDN at the top of the domain. Plus, we’re looking at pulling in users from peer domains in the same forest and even trusted domains in an external forest.

That’s why I need the security groups to work, specifically universal security groups, so I can pull in users from all those locations.

The only other possiblity is to implement a virtual directory application. I’m playing with Pemrose Virtual Directory now, but I prefer not to introduce another level of complexity if possible.

8

are your group members also in your basedn?

9

No. If the group members were in the BaseDN, I wouldn’t need them to be in the groups: they would show up as users.

The goal is to have the members of the groups, from many locations outside the BaseDN and indeed outside the domain and even outside the forest (although in a trusted external domain), to be allowed to authenticate based on their membership in the security group which is located in the BaseDN.

Perhaps my problem is that the intent of groups in Openfire is only to search and filter which users in the BaseDN are allowed authentication, in which case this solution won’t work for us at all, unless I can get the virtual directory application working (no luck there so far).

10

That seems to be the case. I just tested this, and if my group members are not within the basedn, they will not show up.

11

you could also try this

make sure openfire is binded to a dc that is also a global catalog server, and set your basedn to dc=

by being null, it should search the global catalog server and therefore find everything in your forest.

I would test this, but I only have my production system up and running.

12

oh…you’ll have to change the port used for ldap to 3268 to access the global catalog

13

I had to do a re-install of Openfire to get rid of manual changes I’d made over the past couple of days, but I confirm what you say. The group membership only shows users whose AD accounts are within the BaseDN. Therefore, I must conclude the groups are merely a convenience for searching and not for bequeathing LDAP authentication to their members.

Thanks for your time, Speedy!

This means I must get the virtual directory application to work or this solution will not be workable in our Active Directory environment.

14

Did you see my post about using the global catalog?

15

Yes, thanks. But even going to the top level forest would not work because there are satelite comms involved (low bandwidth, hight latency) and the forest contains tens of thousands of objects. Plus, that still would not pull in users from the trusted domains in the external forest.

16

that is correct, the global catalog is limited to its own forest. The ojects wouldn’t be that big of deal since you can use filters. The low bandwidth sites won’t be an issue since openfire would be reading from the GC, not them

It looks like your only issue would be the external forest. I guess you could set up an openfire server for each forest, but that may be more than you would want to do.

I’m curious to see how the virtual directory works for you. Please keep us all posted on your solution!

17

Okay, so I decided to try the forest wide open part, at least in my test environment to see how it worked. I made the forest the the BaseDN and pointed to the domain controller in the forest domain. That part works great. I now see all users in all domains of the forest and they are able to log onto the Openfire server.

I then modified the ldap.groupSearchFilter to (&(objectClass=group)(cn=xmpp*)). That successfully isolated the two groups I created beginning with “xmpp”, one in each domain under the forest. But the groups show no members and everyone in the forest is still able to log onto the Openfire server.

I’m still missing something. I haven’t even begun to meddle with the ldap.searchFilter yet.

18

what do you have your ldap.groupMemberField set to, and what kind of groups are you using?

19

The groups are AD global security groups. Attached is a text file with all the server parameters. Specifically, the ldap.groupMemberField is member.
system_properties.txt.zip (754 Bytes)

20

you could try changing member to memberOf, or you could try using a universal group.