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:
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.
chrklo
July 26, 2019, 1:04pm
10
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.
system
Closed
December 7, 2019, 5:32pm
12
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.