Win AD LDAP Success Users Groups

Openfire Openfire Support
21

Although the baseDN of everyone above was commas I tried changing to semi-colons. Sadly it didn’‘t help. I changed adminDN to cn=ADMINISTRATOR but again, sadly, it didn’'t work.

Am I correct in thinking that the adminDN is the Windows login information for Wildfire to use to get permission from Active Directory to get any other information from AD?

I’‘m sure my mistake is something obvious and it’‘ll come down to “doh!” when I or someone else figures out what I’'m doing wrong.

When the ldap section is not commented out I can’‘t log into the console in any way and the server is saying it’'s listening to FRED:9090 & 9091.

When it is commented I can log in as admin/admin and it’'s listening to 127.0.0.1:9090 and 9091. Neither of which may mean anything…I just thought it odd.

22

yes, you are correct in your assumption that the adminDN is for the user identity that has access to read the LDAP tree. In this you only need an account that has the read attribute but any other access to it isn;t needed (i.e. dont use a domain or OU admin account for security reasons.)

Another thing, go into your debug and error logs and see if it touches anything. the admin console will always listen to fred:9090 & 9091, what you want to see if wildfire is touching Wilma for authentication for anything.

23

Try adding the two items I put in for you, see if that helps at all.

24

Ok, I moved ADMINISTRATOR to the IT ou.

Error log is zero bytes. Debug log shows a problem if I try to log in to the console as “admin” (not a user in our domain). When I try to log in as ADMINISTRATOR I get no entries in debug at all.

…do I need to create a user in the console before turning on LDAP so that I CAN log in in some way after turning it back on? Or worse, do I have to create a user in Wildfire for each domain user? That might be the “doh” I’‘m looking for if that’'s the case. Do I have to set something up in server-to-server in the console?

I can’‘t log into the service (using Trillian Pro) as a domain user (in the IT ou, don’‘t know if that makes a difference). The error I’'m getting inside Trillian is:

*** Creating connection "dharmon@MYDOMAIN.COM/"

*** Connect: connection failed, unable to connect to MYDOMAIN.COM

(nothing shows in error.log or debug.log about this)

Here’'s my debug.log with a few comments added. All other logs except the admin-console.log are empty (and that one grows every few seconds).

debug.log:

2006.06.16 10:46:14 Created new LdapManager() instance, fields:

2006.06.16 10:46:14 host:

2006.06.16 10:46:14 port: 389

2006.06.16 10:46:14 usernamefield: sAMAccountName

2006.06.16 10:46:14 baseDN: ou=IT,DC=MYDOMAIN

2006.06.16 10:46:14 alternateBaseDN: null

2006.06.16 10:46:14 nameField: displayName

2006.06.16 10:46:14 emailField: mail

2006.06.16 10:46:14 adminDN: cn=administrator,ou=IT,dc=MYDOMAIN

2006.06.16 10:46:14 adminPassword: SECRET

2006.06.16 10:46:14 searchFilter: (sAMAccountName=)
2006.06.16 10:46:14 ldapDebugEnabled: false
2006.06.16 10:46:14 sslEnabled: false
2006.06.16 10:46:14 initialContextFactory: com.sun.jndi.ldap.LdapCtxFactory
2006.06.16 10:46:14 connectionPoolEnabled: true
2006.06.16 10:46:14 autoFollowReferrals: false
2006.06.16 10:46:14 groupNameField: cn
2006.06.16 10:46:14 groupMemberField: member
2006.06.16 10:46:14 groupDescriptionField: description
2006.06.16 10:46:14 posixMode: false
2006.06.16 10:46:14 groupSearchFilter: (member=)

2006.06.16 10:46:16 Loading plugin admin

2006.06.16 10:46:22 Loading plugin search

10:47 -

Tried to log in as administrator, no entries -

10:47 -

now trying to log in as “admin” -

2006.06.16 10:48:27 Trying to find a user’'s DN based on their username. sAMAccountName: admin, Base DN: ou=IT,DC=MYDOMAIN…

2006.06.16 10:48:27 Creating a DirContext in LdapManager.getContext()…

2006.06.16 10:48:27 Created hashtable with context values, attempting to create context…

2006.06.16 10:48:27 Exception thrown when searching for userDN based on username ‘‘admin’’

javax.naming.CommunicationException: WILMA.MYDOMAIN:389 Root exception is java.net.UnknownHostException: WILMA.MYDOMAIN

at com.sun.jndi.ldap.Connection.(Unknown Source)

at com.sun.jndi.ldap.Connection.createSocket(Unknown Source)

… 47 more

10:49 -

tried to log in as dharmon with good PW and bad, no entries -

25

is that server in DNS? it is giving info that it is an unknown host. try using the IP instead of wilma.domain. See if that gets you farther. No, when it is connected properly the ONLY people that will be able to login to the admin console will be the persons that you have added to the wildfire.xml file. So you dont create any users inside of wildfire when you connect to LDAP.

Jeff

26

There is no “admin” user in the domain…that should be why I got an error, and WILMA is the DNS server.

The error log, debug log, warning log have nothing in them(anymore)…none of those add an entry when I try to log in as an actual domain user. I’‘m a Wildfire and LDAP newbie but I have to wonder if there’‘s anything at all wrong with my LDAP settings anymore. I’‘m wondering now if I simply didn’'t set up the web setup correctly.

If I comment out LDAP I can connect into a chat client as user@FRED. With LDAP in I can’‘t log in any way, shape or form, but I also get no log entries anywhere unless I use a non-domain user’'s name (then I get auth problems).

Message was edited by: Dan Harmon

Message was edited by: Dan Harmon

27

Yes, but if you look at the error it is giving Unknown Host. as a reason. try putting WIlma’'s IP in the file instead of the FQDN. Then take a look at the logs and see if the error changes…

Jeff

28

After getting groups to populate properly, the group members’’ status would not update

http://www.jivesoftware.org/community/thread.jspa?threadID=20138

What have I done this time?

Is groups not working for you out of my doco?

Message was edited by: bstapleton

29

You can do a lot with the group and member filters.

For instance, most test and/or service accounts either won’‘t have a last name, or they’'ll have a last name of test. So putting the following in the user filter prevents those accounts from showing up. (sn=) ensures the account has a surname. (!(sn=test)) blocks any account with the last name of test. the builtin accounts don’'t have last names. (mail=) makes sure the account has an email address. And you can always filter out individual accounts with (!(sAMAccountName=username)). Groups work the same way, you can specify a group to add with (cn=groupname)

Hope that helps

Message was edited by: fathed