We’re currently in the middle of an Openfire deployment, and I’m experiencing an issue on version 4.1.6 where no matter which format I use (I’ve tried CN=,OU=,DC=domainname,DC=org, the UPN, and everything in between for the openfire administrator account, and nothing. Test connection fails every time with the vague “check supplied credentials” error message. I know they credentials are correct; otherwise the account wouldn’t be able to log in itself. Quick thought, can the name of the AD account that is the admin account have a space in it? Could that be the issue, I wonder? Because our Openfire administrator account does, in fact, have one. Any more info I can provide, please let me know, because this is driving me fifteen kinds of bonkers. Thanks for the hand in advance, guys; very much appreciated!
the admin account used for ldap is a bit misleading. if youre running a default AD, a normal domain users account can be used. this account is only used for ldap searches and does not require elevated access.
Id suggest making doing the following: make your base dn the root of your domain(dc=domainname,dc=org) and then use email@example.com
Thanks for that; very helpful! Does it matter that the users in our directory are not in the default OU? We have a sort of custom OU structure; it’s not default at all, I’ll tell you that. The DC=domainname,DC=Org is I think the only variant with the UPN I’ve not tried.
the OU structure does matter…the BASE DN is the starting level of the search, which is why I suggest using the root of the domain. search filters can be used later on to exclude or include more specific information.
I just tried that as you’ve suggested; nothing, still a error authenticating, check supplied credentials message. I’ve checked the credentials a couple times, though, so I know they are correct.