AD sync failing

Update:

Running /var/storage/chroot-http/usr/bin/ad-sync.plx -v  failed twice with errors pointing to user account. Interestingly enough, that's the user account which joined UTM to AD, not the one configured for sync.

Running it a third time results in a successful sync.

Any ideas?

Out of curiousity: Any reason for the password being displayed in plain text?

Manual sync failed again, please find complete run result below:

/var/storage/chroot-http/usr/bin/ad-sync.plx -v
started
running: /usr/sbin/net ads --request-timeout 45 -w '<AD-Domain>' -U '<user>'%'<pass>' dn '' 'defaultNamingContext' -p 3268
kerberos_kinit_password <user>@<AD-Domain> failed: Clients credentials have been revoked
kerberos_kinit_password <user>@<AD-Domain> failed: Clients credentials have been revoked
error returned from samba command on <AD-Domain>
running: /usr/sbin/net ads --request-timeout 45 -w '<AD-Domain>' -U '<user>%'<pass>' dn '' 'defaultNamingContext' -p 389
kerberos_kinit_password <user>@<AD-Domain> failed: Clients credentials have been revoked
kerberos_kinit_password <user>@<AD-Domain> failed: Clients credentials have been revoked
error returned from samba command on <AD-Domain>
failed to run samba command on <AD-Domain>, exiting now

So, it looks like the sync failed because the Password changed in AD for the Bind DN in your AD server definition in 'Authentication Services'.  Try changing the 'Bind DN' definition to a new user, uniquely used for the UTM, with administrative privileges that has "password never expires" selected.  Any better luck now?

Cheers - Bob

Thanks Bob for your suggestion. However I fear that isn't our issue. The account being complained about is not the one used for syncing in the server definition but the account which was used to join UTM to AD.

If it was the used sync account being complained about I'd be with you. Any other hint?

Cheers,

Ben

Then I'd un-join the UTM by using incorrect credentials on the 'Single Sign On' tab, and then rejoin with the correct credentials of the new user as suggested.

Cheers - Bob

Would you expect any (user) impact while doing so? What would you suggest to do with the computer account in AD? Leave it where it is or delete at some point when re-joining?

We used to think that you had to delete the UTM account in AD, but that's no longer the case.

The only impact would be on AD-SSO user authentication.  A user's IP is cached for 5 minutes.  If it takes you 12 seconds to unjoin and rejoin, users have a 4% chance of a rejection for not authenticating.

Cheers - Bob

Could you maybe provide me with a step by step incl. where to navigate? What kind of administrative permissions would you expect when saying the joining account would need those?

Also, what I still don't get: In the authentication configuration you have to enter a user. This was done and this is not the user which was used for domain join. We found that a failing sync is down to the account used for joining being locked out. But why is that user important when it's joined? What's the other user for then?

Although it's not practical, it's possible to join to do AD-SSO and not configure an AD server.  Likewise, it's possible to configure an authentication server for AD without joining.  My conclusion is not that the failing sync was caused by the join account not authenticating,  I think there's something else going on, but it would take a look through your system.  If my suggestion below doesn't resolve your issue, you will want to get Sophos Support involved.  Please come back and tell us what they found.

I would both change the Server definition on the 'Servers' tab and unjoin/rejoin on the 'Single Sign-On' tab using the new user with Administrative Privileges in AD.

Cheers - Bob

Although it's not practical, it's possible to join to do AD-SSO and not configure an AD server.  Likewise, it's possible to configure an authentication server for AD without joining.  My conclusion is not that the failing sync was caused by the join account not authenticating,  I think there's something else going on, but it would take a look through your system.  If my suggestion below doesn't resolve your issue, you will want to get Sophos Support involved.  Please come back and tell us what they found.

I would both change the Server definition on the 'Servers' tab and unjoin/rejoin on the 'Single Sign-On' tab using the new user with Administrative Privileges in AD.

Cheers - Bob