Hi Philip, Which application you are using? As I am not exactly sure how 'syncing' feature of that application working with Gluu; so ....

Thank you for the reply. I'm using Apache Syncope version 2.0.7. Syncope offers connection to any LDAP server. Once proper connection is achieved Syncope grants you capabilities such as UPDATE, AUTHENTICATE, CREATE, DELETE, SEARCH and SYNC. So in my case I am already connected and able to test its capabilities. The only thing is the delete function as to why it wont perform deletion when the user already performed their first log in in Gluu.

Your Gluu Server LDAP is OpenLDAP, so it might be helpful to look into OpenLDAP docs and troubleshooting tips to figure out what might cause this issue. I haven't heard any similar reports about protection of active users... I know users can be deleted from the LDAP at any time. If you figure it out, let us know. Also, if you're feeling generous with your time, we would be happy to host a blog about your Gluu / Syncope integration. Thanks, Will

Will keep you updated hoping to find a solution on my issue. Thank you!

After searching here is an issue that is somewhat similar to mine but I have no idea how to implement the provided solution in Gluu or if the said solution is applicable in Gluu but it's better than nothing right? :) Please take a look here: https://github.com/nuxsmin/sysPass/issues/575 The solution provided in the thread said that the problem is caused by an account's history record so the record must be deleted in order to achieve desired result. Maybe in Gluu there is some kind of account's history record for logged in user which restricted me to perform deletion? Correct me if I'm wrong it's just my own opinion. Thanks, Philip

Philip, I'm not extremely familiar with Apache Syncopy, but what I would try is testing deletion of a user that's already been logged in while also 'tail -f /var/log/openldap/ldap.log' to see what responses openLDAP is saying on the backend. There might be a hint as to what's happening.

Hi Chris, I tried the tail command and follow the logs on my ldap but unfortunately after I have deleted the user in syncope there were no error logs present that points to my action. The logs just keeps on refreshing and showing slapd[7430] logs which I barely understand also I dont know why the ldap logs keep on refreshing even though I am not performing any action. Here is a part of the log please check if you dont mind reading long logs. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Jan 16 02:12:37 sampleuser slapd[7430]: conn=1013 op=122 SRCH base="ou=201801,ou=oxauth,ou=@!8775.822D.BF0C.2FBA!0002!E500.7167,ou=metric,o=@!8775.822D.BF0C.2FBA!0001!EB53.2DD4,o=gluu" scope=0 deref=0 filter="(objectClass=*)" Jan 16 02:12:37 sampleuser slapd[7430]: conn=1013 op=123 SEARCH RESULT tag=101 err=0 duration=0.497ms nentries=1 text= Jan 16 02:12:37 sampleuser slapd[7430]: conn=1011 op=125 SRCH base="ou=scripts,o=@!8775.822D.BF0C.2FBA!0001!EB53.2DD4,o=gluu" scope=2 deref=0 filter="(&(&(objectClass=top)(objectClass=oxCustomScript))(|(oxScriptType=cache_refresh)(oxScriptType=update_user)(oxScriptType=user_registration)(oxScriptType=id_generator)(oxScriptType=scim)))" Jan 16 02:12:37 sampleuser slapd[7430]: conn=1011 op=125 SRCH attr=dn inum oxRevision oxScriptType oxModuleProperty gluuStatus Jan 16 02:12:37 sampleuser slapd[7430]: conn=1011 op=125 SEARCH RESULT tag=101 err=0 duration=0.301ms nentries=6 text= Jan 16 02:12:38 sampleuser slapd[7430]: conn=1008 op=129 SRCH base="inum=@!8775.822D.BF0C.2FBA!0002!E500.7167,ou=appliances,o=gluu" scope=0 deref=0 filter="(objectClass=*)" Jan 16 02:12:38 sampleuser slapd[7430]: conn=1008 op=129 SRCH attr=gluuApplianceDnsServer oxAuthenticationMode oxCacheConfiguration oxTrustCacheRefreshServerIpAddress oxTrustEmail c description displayName gluuFreeDiskSpace gluuFreeMemory gluuFreeSwap gluuBandwidthRX gluuBandwidthTX gluuDSstatus gluuHTTPstatus gluuSPTR gluuVDSstatus gluuGroupCount gluuHostname iname inum inumFN gluuIpAddress gluuLastUpdate gluuLoadAvg gluuManageIdentityPermission gluuMaxLogSize o oxIDPAuthentication oxLogConfigLocation oxLogViewerConfig oxTrustAuthenticationMode gluuPassportEnabled passwordResetAllowed gluuPersonCount gluuAppliancePollingInterval gluuOrgProfileMgt gluuScimEnabled gluuShibAssertionsIssued gluuShibFailedAuth gluuShibSecurityEvents gluuShibSuccessfulAuths oxSmtpConfiguration gluuSmtpFromEmailAddress gluuSmtpFromName gluuSmtpHost gluuSmtpPassword gluuSmtpPort gluuSmtpRequiresAuthentication gluuSmtpRequiresSsl gluuSmtpUserName gluuSslExpiry gluuStatus gluuSystemUptime oxTrustStoreCert oxTrustStoreConf userPassword gluuVdsCacheRefreshEnabled gluuVdsCacheRefreshLastUpdate gluuVdsCacheRefreshLastUpdateCount gluuVdsCacheRefreshPollingInterval gluuVdsCacheRefreshProblemCount gluuWhitePagesEnabled objectClass Jan 16 02:12:38 sampleuser slapd[7430]: conn=1008 op=129 SEARCH RESULT tag=101 err=0 duration=0.157ms nentries=1 text= Jan 16 02:12:38 sampleuser slapd[7430]: conn=1005 op=258 MOD dn="inum=@!8775.822D.BF0C.2FBA!0002!E500.7167,ou=appliances,o=gluu" Jan 16 02:12:38 sampleuser slapd[7430]: conn=1005 op=258 MOD attr=gluuLastUpdate gluuSystemUptime Jan 16 02:12:38 sampleuser slapd[7430]: slap_queue_csn: queueing 0x7f0d3416be00 20180116021238.079740Z#000000#000#000000 Jan 16 02:12:38 sampleuser slapd[7430]: conn=1005 op=258 RESULT tag=103 err=0 duration=0.169ms text= Jan 16 02:12:38 sampleuser slapd[7430]: slap_graduate_commit_csn: removing 0x7f0d3416be00 20180116021238.079740Z#000000#000#000000 Jan 16 02:12:38 sampleuser slapd[7430]: conn=1014 op=118 SRCH base="inum=@!8775.822D.BF0C.2FBA!0002!E500.7167,ou=appliances,o=gluu" scope=0 deref=0 filter="(objectClass=*)" xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx btw, please check the screenshots these are logs before 02:12:37 and after 02:12:38. [1]https://pasteboard.co/H37V4pW.png [2]https://pasteboard.co/H37VqW8.png If I'am missing something please just let me know. Thank you!

Hi Philip, I think it's worthy to ask how 'Syncope' is actually talking to Gluu Server's LDAP; is it SCIM? or .. is it direct connection which performs ldap operation directly? Here is how ldap log looks like when you perform operation from oxTrust: - Add user in Gluu Server: ``` Jan 16 07:21:17 centos slapd[2877]: conn=1000 op=150 ADD dn="inum=@!C40A.6FB7.42B8.3D7A!0001!CA37.F314!0000!FEC3.2EB1.69F1.85A3,ou=people,o=@!C40A.6FB7.42B8.3D7A!0001!CA37.F314,o=gluu" Jan 16 07:21:17 centos slapd[2877]: slap_queue_csn: queueing 0x7f709817b6d0 20180116072117.207359Z#000000#000#000000 Jan 16 07:21:17 centos slapd[2877]: conn=1000 op=150 RESULT tag=105 err=0 duration=91.071ms text= Jan 16 07:21:17 centos slapd[2877]: slap_graduate_commit_csn: removing 0x7f709817b6d0 20180116072117.207359Z#000000#000#000000 Jan 16 07:21:17 centos slapd[2877]: conn=1002 op=117 SRCH base="inum=@!C40A.6FB7.42B8.3D7A!0001!CA37.F314!0000!FEC3.2EB1.69F1.85A3,ou=people,o=@!C40A.6FB7.42B8.3D7A!0001!CA37.F314,o=gluu" scope=0 deref=0 filter="(objectClass=*)" Jan 16 07:21:17 centos slapd[2877]: conn=1002 op=117 SEARCH RESULT tag=101 err=0 duration=0.189ms nentries=1 text= ``` - Delete user in Gluu Server: ``` Jan 16 07:22:42 centos slapd[2877]: conn=1000 op=170 DEL dn="inum=@!C40A.6FB7.42B8.3D7A!0001!CA37.F314!0000!FEC3.2EB1.69F1.85A3,ou=people,o=@!C40A.6FB7.42B8.3D7A!0001!CA37.F314,o=gluu" Jan 16 07:22:42 centos slapd[2877]: slap_queue_csn: queueing 0x7f7094142960 20180116072242.414843Z#000000#000#000000 Jan 16 07:22:42 centos slapd[2877]: conn=1000 op=170 RESULT tag=107 err=0 duration=0.953ms text= Jan 16 07:22:42 centos slapd[2877]: slap_graduate_commit_csn: removing 0x7f7094142960 20180116072242.414843Z#000000#000#00000 ``` Also.. do you think you can share some documentation how you connected Syncope with Gluu Server [ as none of our customer hasn't used it so we don't have hands on experience using that ].

Hi mohib, I am using direct connection which performs LDAP operation directly. In Syncope there is a section called topology inside that section you can create your own connector and resource. The Connector is responsible in connecting to Gluu's server by choosing their predefined LDAP bundle and by providing your Gluu LDAP information. Once proper connection is achieved Syncope grants you capabilities such as UPDATE, AUTHENTICATE, CREATE, DELETE, SEARCH and SYNC as what I have said above. Hope this information helps. Thanks!

I wonder how Syncope successfully created bind with localhost:1636... In any case I think we need a doc how you installed,configured and connected syncope with Gluu Server; so we can try to replicate your situation if you want.

I opened ldap 1389 under symas-openldap.conf and restart using service solserver then I bind my Syncope with 1389. Apache Syncope has its own documentation you can check it here: 1.) http://syncope.apache.org/docs/getting-started.html#introduction (getting started) 2.) http://syncope.apache.org/docs/reference-guide.html (reference guide)

I requested Thomas to try to reproduce your issue. We will try to publish a doc on this.

Hi Feliprada, I need some information to reproduce your issue. 1. There are multiple way to install Apache syncope. Which way have you use? 2. Since Gluu ldap is inside a container. Have you installed apache syncope in the same container? in the same the same VM? in a separate VM? Please provide all information that can help reproduce the issue. In the mean time. I have some doc to cover.

Hi Thomas, 1.) I used GUI installer(section 3.3 in syncope getting started docs) 2.) No I installed apache syncope in a separate VM. using tomcat as container and mysql as dbms. Thank you so much! Your efforts are much appreciated.

Hi Thomas, Try to click the syncope box on top of the file:// box then click reload all connectors that should display all the provided bundles. Good luck! Just keep me updated and Thank you for your continuous support!

Hi Feliprada, A quick reload show me all connectors as you say,cool. But my sync task is not working. The error have to do with SSL certificate since the Gluu serveur required SSL. You can see that on the links: https://pasteboard.co/H3ZmmlI.png https://pasteboard.co/H3ZmT7U.png Can you provide your connector's settings or how do you managed to solve that? Thanks!

Hi Thomas, Before you perform tasks you make sure that you are successfully connected with Gluu. In your case you are not able to connect successfully as seen here(https://pasteboard.co/H3ZmmlI.png) In my case I did not use ssl and I said at the earlier comments of these thread that "I opened ldap 1389 under symas-openldap.conf and restart using service solserver then I bind my Syncope with 1389" but maybe you can connect using 1636 but I have not tried it yet. If you managed to connect successfully You can refer here(http://coheigea.blogspot.it/2016/08/pulling-users-and-groups-from-ldap-into.html) for the additional information in dealing with tasks this blog is kinda old but it might be handy. Thanks!

Hi Thomas, I noticed that there was a new release of Gluu which is version 3.1.2 then I immediately performed resetup. Tried to clone my setup last time in 3.1.1 and it worked well and good news I tried to reproduce my problem and now I can seem to delete my desired user including the ones that performed their first log in. If you want to continue on your investigation on why I encountered my error in version 3.1.1 and you're having some trouble just post it here and I will try my best to assist you. If there are no more issue, let's just close this thread. Btw, I have another problem purely Gluu related you can check it here(https://support.gluu.org/access-management/5020/gluu-server-set-up-publicly/) maybe you have an idea. A big thanks for all your help.

Great to hear!