New Domain Join necessary after Firmware Update

Use dedicated AD user account for that purpose and configure "Password never expires" attribute along with "User cannot change password".

Thanks for the hint. Just had the situation again and rejoined the utm to the active directory with my domain admin. Before rejoining I activated "User cannot change password" and "password never expires" (which was already set before). After rejoining the UTM the account was locked out again and the "User cannot change password" option was deactivated again.

What do you exactly mean by using a dedicated AD Account?

Best Regards,

Chris

Create AD account only for that purpose (for example sophosutm). It does not have to be domain admin, just a regular user account.

Edit: with workstation domain join priviledges.

Hi vilic,

 

is that best practise? Never heard of it before.

Changing the password of BIND DN user create problems with AD SSO, that is well known. But, changing the password of the user account who joined UTM to domain also create problems with AD backend sync. UTM saves that password locally, and can even be listed in clear text format (screenshot below).

My best practice is to use separate account for UTM/AD integration, with password never expires option enabled. I don't remember that it is officially documented anywhere.

 

 

 

 

Changing the password of BIND DN user create problems with AD SSO, that is well known. But, changing the password of the user account who joined UTM to domain also create problems with AD backend sync. UTM saves that password locally, and can even be listed in clear text format (screenshot below).

My best practice is to use separate account for UTM/AD integration, with password never expires option enabled. I don't remember that it is officially documented anywhere.

 

 

 

 

That´s very interesting and both statements, are absolutely new to me.

 

 

vilic said:

Changing the password of BIND DN user create problems with AD SSO, that is well known.

 

I had some learning lessions with Sophos support directly, when we introduced SSO with our first customer. They told me, that the SSO (winbindd) has nothing to do with the AD Backend Server. So they say basically for SSO, you don´t need to configure an AD-Backend Server. I also configured the Backend Servers, to be able to test users etc... But up to the sophos support, it is not necessary.

 

Wouldn´t this something, that should be in the RULZ?

 

Regards

Sebastian

Unknown said:

I had some learning lessions with Sophos support directly, when we introduced SSO with our first customer. They told me, that the SSO (winbindd) has nothing to do with the AD Backend Server. So they say basically for SSO, you don´t need to configure an AD-Backend Server. I also configured the Backend Servers, to be able to test users etc... But up to the sophos support, it is not necessary.

If I remember correctly backend server is not necessary only for Web Filtering module AD authentication.

Edit: My terminology was wrong, I have equaled authentication with SSO in my previous post....:(
Anyway the point is the same, use one AD separate account for both purposes and never change its password...;)

"Anyway the point is the same, use one AD separate account for both purposes and never change its password"

Interesting, I've done that for as long as I can remember.  Probably learned it from someone here.  When I made Configuring HTTP/S proxy access with AD SSO, I demonstrated that my dedicated account was bob2, but I failed to mention that it was only used in my WebAdmin configuration.

Thanks for making this explicit, vilic.  Yes, Sebastian, if vilic uses it, I think we can say it's a best practice! [;)]

Cheers - Bob