ATI 2018 and 2019 will not authenticate with Windows Domain Credentials

Tech OHPRS, 

Have you tested with a fresh install (clean without a previous version) on a test system using 2019?  I ask, because you may have old connection info in the registry that needs to be cleaned out before you try to authenticate to the share again.  This was a leftover bug in 2017 and early versions of 2018, which may still be in the registry if you are upgrading over the top to 2019.

https://kb.acronis.com/node/58004/

If the issue persists, try re-establishing connection to NAS:

1. Reboot PC, router and NAS
2. Make sure that True Image window is closed
3. Clear credentials cache for SMB connections by deleting registry key HKEY_CURRENT_USER\Software\Acronis\Connections\smb
4. Open True Image window, create a new backup task. Type the path to top-level share directly and use ip form, e.g. \\192.168.0.12\Public

------------------------------------------------------------------

ATI should authenticate fine with domain credentials - same as it does with NAS devices which are using authentication not tied to the local machine.  Keep in mind though that newer versions of Acronis and Windows have disabled old protocols with security vulnerability (smb 1.0, tls 1.0, etc). which make remote connection a bit more restrictive.  That said, I don't think that's the issue here (maybe though).  

You should not be using a regular domain  user account to authenticate to a domain share - especially because of the need to change passwords.  Instead, you should be using a dedicated domain Service Account or a dedicated AD user account specifically made to run backups and where only you (or your IT office) can manage it (for things like setting and changing the password).  If you change that password, you will need to update it on all clients, but this is going to be the same regardless of the account you use.

As for authenticating to the share in Acronis, make sure the dedicated account you use has read/write access to the actual location of the folder(s) on the server (like if you were logged in with that account directly on the server and accessing them).  Then, also make sure that the "share" permissions for that same account give read/write access.  AD uses the most restrictive access, so if the permissions are different for local access vs the share access and one is more restrictive than the other, it may fail to authenticate because the lower access is enforced.

Also, when connecting to the share in Acronis, make sure to enter domain/username when you authenticate. And make sure this account has administrative access on all of the computers (preferably via AD GPO).  If it is not in the local admin group of the PC, it won't work.

And because this account will be the one setup to run the backup and authenticate to the network share, users will not be able to launch Acronis and/or tweak the backup settings - this has to be a local admin account anyway.  True Image has to be launched and run with an admin account and in order to work correctly with the network shares, you should ideally be doing launching Acronis and setting it up and using those credentials for the network share where the backups will be located, with the same credentials.

Bobbo_3C0X1: Thanks for your comments.

This was a completely fresh installation on a new Windows 10 computer with no previous ATI installation.

At the moment, I have not created a dedicated domain account for backups. We've used the credentials for the user owning/using the workstation for this in the past and, as I mentioned, this works fine on Windows 7 and ATI 2017. Yes, these users have read/write access to the target network drive.

I reverted the ATI version to 2017 on the Windows 10 computer, but that still didn't work. Apparently, there is some difference between Windows 7 and Windows 10 in this regard. Perhaps related to your comment, "newer versions of Acronis and Windows have disabled old protocols with security vulnerability (smb 1.0, tls 1.0, etc). which make remote connection a bit more restrictive." Our Samba version is 4.6.16, which is well beyond your mentioned 1.0 (if that's related to the protocol). As far as I know, TLS is not used for this connection. But still, there is obviously something different.

Your comment about "make sure this account has administrative access on all of the computers" gave me some hope. The users on the Windows 7 computers were local administrators, but not the user on the Windows 10 computer. So, I tried making that user a local administrator, but no go.

Making the user part of the administrator group via AD GPO doesn't work as the target computer's samba will not authenticate with Administrative group credentials, possibly a limitation in Samba (or some samba settings I don't know about). That's something I could research with samba.

In the meantime, I've developed a work-around whereby the target NAS device will mount the Windows 10 drive containing the .tib files and copy them to the local file system.

I'll try a couple of more things alluded to by your comments. Otherwise, any other ideas of things I could try?

Interesting that you mention Samba... SMB 1.0 was the old connection protocol, but it's nixed in Windows 10 and Acronis 2019.  Are you able to verify if SMB 2.0 is enabled on the NAS, or can be (or SMB 3.0)?  

I can't find the specific thread I wanted to show you, but I believe it was a home Synology box where there were screenshots with an option to enable SMB 2.0 which fixed the authentication issues that allowed backups to start running.

So, if you use a local admin account, how is that authenticating to the NAS on the network in older versions? (Nevermind, duh)

https://forum.acronis.com/forum/acronis-true-image-2018-forum/latest-build-no-longer-sees-my-nas-recovery-environment

https://www.linuxquestions.org/questions/slackware-14/had-to-revert-samba-to-4-4-16-i586-3-from-4-6-16-i586-1-a-4175636990/

https://www.reddit.com/r/synology/comments/362xpe/dont_forget_to_enable_smb3/

I've checked the Samba protocol on the NAS:

        client max protocol = default
        client min protocol = CORE
        server max protocol = SMB3
        server min protocol = LANMAN1

and on the Windows 10 computer:

PS C:\Windows\system32> Get-SmbConnection ohprsstorage

ServerName   ShareName UserName    Credential        Dialect NumOpens
----------   --------- --------    ----------        ------- --------
ohprsstorage public    HPRS\user HPRS.LOCAL\user 3.1.1   6

That PowerShell command does not work on Windows 7. I'll see if I can find a way to check that.

Those protocols in Samba are not explicitly set. That tells me that Samba will connect with any client's protocol from LANMAN1 to SMB3. I'll check into how to set that explicitly. I assume the "Dialect" parameter in Windows 10 (3.1.1) is the protocol. I'm not sure how to actually find the protocol used for a given client/Samba-host pair. I'll investigate.

I've also got a question in to the SambaList group on this.

More info ...

smbstatus gives the info on the protocol used. So, for the Windows 10 host in question, the connection protocol is SMB3_11. For the Windows 7 computer which does authenticate with domain credentials using with ATI 2017 (but not ATI 2018/2019), the connection protocol is SMB2_10.

Does ATI 2018/2019 require SMB3? In any case, the Windows 10 computer is using SMB3, so protocol isn't the problem.

Have you download ATI 2020 trial and see if the same issue persists? I am not hopeful but you can never discount the possibility.

Ian

Tech OHPRS, no I don't believe it requires SMB 3.0 (in the post I still can't find, the fix was to use SMB 2.0 on the home NAS).

I'm not really sure of the issue other than that.  We use Windows 2012R2 and 2016 servers and have been able to authenticate with them. I'm not sure what could be the issue in this case. 

Have you opened up a technical support case? You'll probably have to do the dog-and-pony show with tier 1 at first, but hopefully it can be escalated higher up without too much trouble and have someone else take a look at the problem.  If it is a bug or some type of protocol issue, this would be the way to bring it to light and allow Acronis to try and fix it.

IanL-S: SInce it's a bit of a pain to uninstall ATI and make sure it's ALL gone, and then reinstall 2020, I'm going to go with my work-around for the time being and try ATI 2020 on the next Windows 10 computer. Which will be fairly soon.

Bobbo_3C0X1: I will experiment with forcing SMB2.0. That might explain why neither ATI 2017 nor ATI 2019 and 2019 work on the Windows 10 computer (or not).

IanL-S, can you confirm what version your 2012R2 and 2016 servers are running?

Bobbo_3C0X1 wrote:

Tech OHPRS, no I don't believe it requires SMB 3.0 (in the post I still can't find, the fix was to use SMB 2.0 on the home NAS).

ATI on one of my computers backups up to a WD MyBookLive using SMB 2.0.2.  Actually, I've got a desktop and two laptops backing up to that NAS.  No problems with either ATI 2019 or 2020.

Sorry for the long delay, but we've just recently installed Windows 10. And, I've installed ATI 2020 to test on one of the workstations. To recap, I am trying to backup to an network device.

I've done as Bobbo_3C0X1 suggested in reply #1. Specifically, 1) created a dedicated domain user for doing these backups whose password doesn't expire 2) entered the credentials using domain\user, not just user.

When trying to use only the user ID without the domain prefix it would not validate. The NAS connection does not even ask for credentials. It just goes ahead and uses the logged in user's credentials automatically, which is pretty much the point of AD authentication. This is an apparent change from ATI2017 and Windows 7 since I did not have to explicitly enter credentials.

Nevertheless, the backup to the NAS now works, so problem solved. I can now upgrade the office to ATI 2020.

btw - we are no longer user SMB1.0 on any office computers. That was a tangled web! For anyone struggling with that issue, Microsoft is no help. Here is a fantastic post on how to do that: https://www.ixsystems.com/community/resources/how-to-kill-off-smb1-netb…