Which external data do you mean?
You could use LDAP? Isn´t that the mayor datasource for user data?
If LDAP isn´t the user source of you choice, there is an api for creating users that is pretty easy to use:
https://docs.zammad.org/en/latest/api-user.html#
Cheers
LDAP seems to be pretty buggy - I try to connect our Estos MetaDirectory to it.
We have zammad connected to our ldap and didn´t see any issues right now.
There definately are some points of enhencements possible. But it works.
So maybe give it a try and “see” if it is buggy instead of “thinking” that “it seems” buggy?
I’d like to give it a try, but it just does not connect to metadirectory.
After submitting “ldap://ldapserver.domain.local:712”, it says “Can’t connect to ‘exchange2013.zeteko.local’ on port ‘712’, Can’t bind to ‘exchange2013.zeteko.local’, 49, Invalid Credentials”. No way to give credentials 
Already tried the protocol://user:password@server:port - notation, but no sucess.
Despite of that, the ldap-server is accessible without credentials.
maybe you could first give it a try to test with a public accessible ldap server.
I tried the following one some minutes ago with success:
LDAP Server Information (read-only access):
Server: ldap.forumsys.com
Port: 389
Bind DN: cn=read-only-admin,dc=example,dc=com
Bind Password: password
If this one works, you are shure tha your installation is fine.
My next try would be, using a default port for the ldap server.
Did you configure this port for the ldap server to listen to?
If not check your configuration. By default it’s probably 389 for LDAP and 636 for LDAPS.
Another way to test this is using any ldap client and try to connect to your ldap server
f.e.
This way you’ll know what exactly the problem is (your server, zammad or whatever).
I have configured MetaDirectory on 389 - still the “Invalid Credentials”-Problem.
On the public LDAP, it works.
Estos MetaDirectory 4 is a commonly used Directory Service, so I think Zammad should work together with it.
What can I do?
If your zammad is running against the public ldap it seems that zammad ldap is working.
My next try would be to use any other ldap client like @dvnkln suggested.
Take the suggested http://www.ldapadministrator.com.
First step would be to connect with the ldap client to the public ldap to be shure your ldap client is working.
Second step would be to connect to your Estos Meta Directory.
If the ldap client is able to connect to both, next step would be to check the communication between zammad and Estos.
If the ldap client is also not able to connect to Estos, the problem must searched on the Estos ldap.
Softerra LDAP Browser 4.5 connects perfectly with the MetaDirectory.
I put my username in, connect and it asks for the password - perfect.
IMO, the problem is on zammad-side.
(btw: do any zammad team members watch community.zammad.com?)
Okay that’s kinda strange.
Next thing to do would be a tcpdump on your zammad server AND/OR your ldap meta server.
Just sniff the ingoing/outgoing ldap traffic to furthermore investigate the source of the problem.
Yeah they do but they got a lot on their to-do (just have a look at the github issues) and need to handle the paid customer support simultaneously. So they can’t post here that frequently.
But that’s what we are for. Distract you until they have a solution 
jk 
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.