Have set a new user with LDAP as shown in the attached
Using the new set credentials am unable to log in odk -x server keep getting the error message wrong username or password
Which credentials do we use to log in the odk-x server
Please assist![Unable to connect to LDAP server ldap-service|690x270]
Hi Duncan,
Sorry to hear you experience this problem. 
Have you made sure to add your user to e.g. the admin group (gid no. 501)?
Here’s the link to the desciption of how to add users to groups:
https://docs.odk-x.org/sync-endpoint/?highlight=group#assigning-users-to-groups
To verify:
If you click on “gidNumber = 501” in the menu, you should be able to see you user listed?
best regards
/emil
Sometimes I have also found it necessary to go to the group, e.g. gidNumber = 501, and click “Add new attribute” and then select “memberUid” in the dropdown and type your user id (eg. “dotieno”) in the value field and click “Update object”.
Then afterwards you can use the “modify group members”-link that appears under “memberUid” to manage the users in that group…
Many many thanks Emil.I have created my users some with gidNumber=501,others with gidNumber=500 ,one with gidNumber=507 and one with gidNumber=503
The only one that is able to log in to the server is the one with the gidNumber=503 all the others i get an error message username or password is in correct
The credentials that are able to log in can only synch tables what happens to the other operations
How do I move ahead
Please guide
Attached is the interface after login as gidNumber=503
Hi Duncan,
That’s strange…
Could you try resetting the user in the 501-group to a super simple password (to rule out problems related to character sets)? Also - what is the exact error message that is shown when you try to log-in?
If it is unable to validate the password, that can sometimes also mean that there was a crash in the openldap-container, so in that case you can try the following command and have a look at the uptime column (i.e. if the openldap container crashes, it restarts automatically - in which case it will have a significantly shorter uptime than the other containers);
docker ps
Out of curiousity - how big is the machine/vm that you are running the sync endpoint on? I have sometimes run into problems with the openldap container crashing mysteriously when I try to run the sync endpoint on (virtual) hardware with too little RAM etc (I personally think that 2gb ram is the minimum for openldap to run, although I don’t know the official requirements for that)
Oh - and I forgot to mention the simple but sometimes effective trick to just restart docker;
If you are on an ubuntu 20.* flavored linux you could write something like:
systemctl restart docker
That vm should definitely be able to run it without problems. 
Do you still experience the problem after docker restart?
Many many thanks @Emil
Followed your guide and now am successful on this
I have created 2 users:
1 with role_synchronize_tables and the other with role_administer_tables
Do I still need to create other users with other roles or am ready to go with the 2 users
Once again am grateful and many thanks!
Great. I’m happy to hear it worked out. 
I normally have one user with role_administer_tables and one role_super_user, but that really depends on your work process. Sometimes it is good to use users that do not have the role_administer_tables for data entry officers.
@elmps2018 Perhaps we should improve the documentation around what roles are recommended for each user type?
Hi @Emil and @Duncan,
I tried using all the login credentials that were created in the admin interface of the LDAP, but I was unable to log in to the ODK-X server. Could you please advise what might be causing this issue? I would greatly appreciate any feedback or guidance you can provide.
Sincerely,
Suman
Have you assigned users to group 503? The users cannot login unless they are assigned a proper group. Generally 504, 505, and 506 were used for integration with ODK 1.0.
Please follow the link.
From the link: “A user needs to be assigned one of the roles in addition to any other group of your choosing. These roles are available as groups 500 (SITE_ADMIN), 501 (ADMINISTER_TABLES), 502 (SUPER_USER_TABLES), 503 (SYNCHRONIZE_TABLES).”
Further description can be found here:
Hi @W_Brunette ,
I got to fix the issue by removing the old ODK-X server stack and redeployed a fresh one using Docker Swarm.
azureuser@sync-endpoint-cft:~$ sudo docker stack rm syncldap
Removing service syncldap_cert-bootstrap
Removing service syncldap_certbot
Removing service syncldap_db
Removing service syncldap_db-bootstrap
Removing service syncldap_ldap-service
Removing service syncldap_nginx
Removing service syncldap_phpldapadmin
Removing service syncldap_sync
Removing service syncldap_web-ui
Removing secret syncldap_org.opendatakit.aggregate.security.properties
Removing secret syncldap_org.eff.certbot.bootstrap_tls_privkey
Removing secret syncldap_org.opendatakit.aggregate.jdbc.properties
Removing config syncldap_org.eff.certbot.bootstrap_tls_fullchain
Removing config syncldap_com.nginx.sync-endpoint-locations.conf
Removing config syncldap_com.nginx.sync-endpoint.conf
Removing config syncldap_com.nginx.proxy_buffer.conf
Removing config syncldap_org.opendatakit.sync-web-ui.application.properties
Removing network syncldap_sync-network
Removing network syncldap_default
Removing network syncldap_ldap-network
Removing network syncldap_db-network
Removing network syncldap_certbot-network
azureuser@sync-endpoint-cft:~$ ls
azureuser@sync-endpoint-cft:~$ ls -la
total 32
drwxr-x— 5 azureuser azureuser 4096 Mar 10 15:39 .
drwxr-xr-x 4 root root 4096 Mar 10 14:35 ..
-rw-r–r-- 1 azureuser azureuser 220 Mar 31 2024 .bash_logout
-rw-r–r-- 1 azureuser azureuser 3771 Mar 31 2024 .bashrc
drwx------ 2 azureuser azureuser 4096 Mar 10 14:33 .cache
drwxrwxr-x 3 azureuser azureuser 4096 Mar 10 15:39 .local
-rw-r–r-- 1 azureuser azureuser 807 Mar 31 2024 .profile
drwx------ 2 azureuser azureuser 4096 Mar 10 14:19 .ssh
-rw-r–r-- 1 azureuser azureuser 0 Mar 10 14:35 .sudo_as_admin_successful
azureuser@sync-endpoint-cft:~$ cd ..
azureuser@sync-endpoint-cft:/home$ ls
azureuser script_to_run.sh sync-endpoint-default-setup
azureuser@sync-endpoint-cft:/home$ cd sync-endpoint-default-setup
azureuser@sync-endpoint-cft:/home/sync-endpoint-default-setup$ sudo docker stack deploy -c docker-compose.yml -c docker-compose-https.yml syncldap
Since --detach=false was not specified, tasks will be created in the background.
In a future release, --detach=false will become the default.
Creating network syncldap_certbot-network
Creating network syncldap_sync-network
Creating network syncldap_db-network
Creating network syncldap_ldap-network
Creating network syncldap_default
Creating secret syncldap_org.opendatakit.aggregate.jdbc.properties
Creating secret syncldap_org.opendatakit.aggregate.security.properties
Creating secret syncldap_org.eff.certbot.bootstrap_tls_privkey
Creating config syncldap_com.nginx.sync-endpoint-locations.conf
Creating config syncldap_com.nginx.proxy_buffer.conf
Creating config syncldap_org.opendatakit.sync-web-ui.application.properties
Creating config syncldap_com.nginx.sync-endpoint.conf
Creating config syncldap_org.eff.certbot.bootstrap_tls_fullchain
Creating service syncldap_cert-bootstrap
Creating service syncldap_ldap-service
Creating service syncldap_phpldapadmin
Creating service syncldap_sync
Creating service syncldap_web-ui
Creating service syncldap_certbot
Creating service syncldap_db
Creating service syncldap_db-bootstrap
Creating service syncldap_nginx
