Nextcloud version (eg, 10.0.2): 12.0.0
Operating system and version (eg, Ubuntu 16.04): CentOS 7 64bit
Apache or nginx version (eg, Apache 2.4.25): Apache 2.4.6
PHP version (eg, 5.6): 7.0.22
Is this the first time you’ve seen this error?: Yes
The issue you are facing: (If so, please outline steps): I have an LDAP bind to our Active Directory server. The users from the initial sync are listed as users in Nextcloud and can sign into their accounts. Password changes work succesfully - However none of the new users added to the AD show up in Nextcloud. The configuration is good - and when I test a user from the LDAP/AD tool it can find and verify those users that havent synced over, but they still dont show up.
I believe a contributor (Without knowing this for certain) may be that Cron was set but AJAX as left configured until just now - Does the system use cronjobs to process AD Syncs?
I hate to be a pain here but we deal with some government data and I’m unable to provide any logging or configuration information publicly. No errors or warnings in logs. Lots of Debug messages related to photos.
As I have continued to test and evaluate - I’ve discovered something else interesting. Although the user does not list when I go to Users in the Admin panel to view all of the users - I am able to sign in with one of the missing users. The user data folder shows up when viewing through the file system - but no mention of the user in the gui. Is it possible that the gui is just borked?
Okay! Phew. After an entire day of debugging I’ve solved the issue. Putting this here to help others in the future. Please mark as solved!
This was using Windows Server 2016 with an Active Directory as the LDAP.
Two separate problems here:
- The first issue was a red herring. The GUI did not show the users even though they are added. When clicking the Users tab - an example user of bohene does not show in the few b usernames that exist. Although if you search for that user at the top - it correctly displays the name. Not sure if this is a bug on our end or not - will report for posterity.
This did not fix the sign in problem though - that was fixed with the below
- There is no communication in the logs that a password has expired if you don’t enable the password reset option. The test user’s password had expired and since this is a test account we had no notification it expired. Logs correctly showed bind failed - but the same occurred for the user who initially reported the problem and insisted their password was correct - after resetting both the test user and original users passwords as a last ditch effort (because why reset them if they are working elsewhere?) things are working again.
Hi
I didn’t understand why you mark this as solution. You mean I must change the password of every new user one more time before it’s re-sync with active directory?
