OpenLdap connection fail

Infos:

  • Used Zammad version: 3.0.x
  • Used Zammad installation source:zammad-3.0.0-1561629709.c101f730.centos7.x86_64
  • Operating system: CentOS7
  • Browser + version: Firefox + Chrome (latest)

Expected behavior:

  • Connect Local Linux openldap DB.

Actual behavior:

  • Fail to connect

Zammad%20Helpdesk%20-%20LDAP-v2

Steps to reproduce the behavior:

  • Able to connection LDAP server via CLI or LDAP admin tools
  • Connect LDAP via non SSL method. Using ldap://xxx.xxx.xxx.xxx

Please advise how to solve it.

Thanks!

1 Like

Hello,

Further check LDAP log. It shown the BIND dn and SRCH base are same value. The SRCH base value is not my input vlaue. Is it a bug?

For reference, the ldap did not allow access via anonymous.

Thanks!

The above message simply tells you that Zammad can’t auto-detect the settings needed to authenticate.
If you give the base DN manually with the correct login data, it should continue.

Thanks for your suggestion. I have double check which others LDAP admin tools to make sure the Bind, DN user and its password is correct. However, it still no luck.

Following please find the production log and ldap log

https://drive.google.com/file/d/1Z997CBsVPzcIM2DMm9pgsG9x2Q_1uKKs/view?usp=sharing

Could you please check once again and advise?

Thanks!

Looks like it’s searching for samaccountname but fails to find it.
smaccountname is usually always there and mandatory as far as I’m aware.

Might be just me reading that logfile wrong.

Jul  2 22:05:16 zammadtest1 slapd[4461]: conn=1038 fd=17 ACCEPT from IP=aaa.bbb.ccc.ddd:44822 (IP=0.0.0.0:389)
Jul  2 22:05:16 zammadtest1 slapd[4461]: conn=1038 op=0 BIND dn="cn=Manager,dc=dcdomain,dc=org,dc=zz" method=128
Jul  2 22:05:16 zammadtest1 slapd[4461]: conn=1038 op=0 BIND dn="cn=Manager,dc=dcdomain,dc=org,dc=zz" mech=SIMPLE ssf=0
Jul  2 22:05:16 zammadtest1 slapd[4461]: conn=1038 op=0 RESULT tag=97 err=0 text=
Jul  2 22:05:16 zammadtest1 slapd[4461]: get_filter: conn 1038 unknown attribute type=samaccountname (17)
Jul  2 22:05:16 zammadtest1 slapd[4461]: get_ssa: conn 1038 unknown attribute type=samaccountname (17)
Jul  2 22:05:16 zammadtest1 slapd[4461]: conn=1038 op=1 SRCH base="dc=dcdomain,dc=org,dc=zz" scope=2 deref=0 filter="(&(?objectClass=user)(?samaccountname=*)(!(?samaccountname=*$)))"
Jul  2 22:05:16 zammadtest1 slapd[4461]: conn=1038 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jul  2 22:05:16 zammadtest1 slapd[4461]: conn=1038 fd=17 closed (connection lost)

Thanks for your comment.

So how to solve it? As I see there is a lot of related topic on samaccountname but not sure how’s it suitable for my case.

Thanks!

Can you please check if your ldap objects contain the attribute samaccountname?

I see, there is not samaccountname attribute in my ldap objects there. Is it must be add back or can skip it?

Could you please advise what will this field used for? or does there is some standard Ldap schema for Zammad?

Thanks!

Hey,

up to now I always thought samaccountname is a default entry within any LDAP. But I can be wrong.
Usually this attributes holds the login name.

We’re expecting this attribute to be set - you can fiddle with the code at your own risk, but I can’t help you with that. Sorry.

samaccountname is an Microsoft Active Directory Attribut.

Zammad should be open for all LDAP directorys - not only Microsoft.

Therefore the UID should be configurable and not hardcoded.

see - LDAP attribute for login (Choose instead of hardcode)

Because of some other work for a paid customer I had to install an openldap server.
This is a default installation without any special restrictions - I can bind to openldap with Zammad without any problems.

Might be possible that it’s because the default seems to allow anonymous read on ldap.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.