I'm just starting out and having a spot of trouble getting users to authenticate against our AD server.
I initially had some trouble getting it to bind in the first place, but I'm fairly sure I've got the right credentials in there now for that.
{host_config, "mycompany.local", [{auth_method, ldap},
{ldap_servers, ["10.50.0.14"]}, % List of LDAP servers
{ldap_uidattr, "sAMAccountName"}, % LDAP attribute that holds user ID
{ldap_base, "DC=mycompany,DC=local"}, % Search base of LDAP directory
{ldap_rootdn, "CN=greasy pablo,OU=Directors,DC=mycompany,DC=local"},
{ldap_password, "xxxxxxxx"}]}. % Password to LDAP managerWhen I start the server up I get the following successful-looking messages:
=INFO REPORT==== 2013-11-22 12:05:51 ===
I(<0.275.0>:eldap:983) : LDAP connection on 10.50.0.14:389
=INFO REPORT==== 2013-11-22 12:05:51 ===
I(<0.285.0>:eldap:983) : LDAP connection on 10.50.0.14:389
=INFO REPORT==== 2013-11-22 12:05:51 ===
I(<0.37.0>:cyrsasl_digest:44) : FQDN used to check DIGEST-MD5 SASL authentication: "ubuntusquid.mycompany.local"
=INFO REPORT==== 2013-11-22 12:05:51 ===
I(<0.467.0>:ejabberd_listener:166) : Reusing listening port for 5222
=INFO REPORT==== 2013-11-22 12:05:51 ===
I(<0.468.0>:ejabberd_listener:166) : Reusing listening port for 5269
=INFO REPORT==== 2013-11-22 12:05:51 ===
I(<0.469.0>:ejabberd_listener:166) : Reusing listening port for 5280
=INFO REPORT==== 2013-11-22 12:05:51 ===
I(<0.37.0>:ejabberd_app:72) : ejabberd 2.1.10 is started in the node ejabberd@ubuntusquid
However, when I try to log on...
=INFO REPORT==== 2013-11-22 12:12:28 ===
I(<0.467.0>:ejabberd_listener:281) : (#Port<0.2003>) Accepted connection {{10,50,9,4},3177} -> {{10,50,0,2},5222}
=INFO REPORT==== 2013-11-22 12:12:33 ===
I(<0.483.0>:ejabberd_c2s:649) : ({socket_state,tls,{tlssock,#Port<0.2003>,#Port<0.2025>},<0.482.0>}) Failed authentication for greasypablo@company.local
Does anyone have any thoughts? Obviously I can turn the debug level up, but I end up drowning in info and I'm hesitant to post the whole thing.
Thanks
Turns out that by
Turns out that by replacing:
{ldap_uidattr, "sAMAccountName"},
with
{ldap_uids, [{"sAMAccountName", "%u"}]},
everything was fine.