Stop windows silently using domain credentials to access a share folder

Question

Hi and thanks in advance for the time spent to read my issue.

At work we've some user on our domain (lets call it DomA) that need to access a share on a fileserver in another domain (DomB).

The issue is that windows tries silently to log in on the share with the DomA credential and only after failure it shows the credentials prompt.

Not much a issue for the user but this generates a lot of failed attempts (win EvID 4625) to our SIEM making difficult to distinguish this "noise" from potential brute force attacks.

Is there a way to change this behaviour? The ideal one is that it asks for credentials without trying to use the DomA ones preventing 4625 events flood.

Also maintaing the credential-less login inside DomA shares would be expected.

I suspect that some policies could help me, but I'm not sure where to look.

The users computers are on Win10, DCs and FileSrv are on WS2016. The 2 domains are NOT in trust and comunicate through a vlan.

Answer 1

Hi @Alessio L

If the user get a popup when he try to access on a share in another that means that SSO based on kerberos protocol is not working between domaA and DomB to access on this share.

If kerberos works , the user will access on share silentcy. You should check the kerberos settins beteen the both domain:

UPN suffix routing, : you can check it in trust properties betwwen the domains. This settings helps user to find target domain when he try to authenticate via kerberos protocol to a share or another application hosted in trusted domain

SPN : is required to configure kerberos protocol on server which hosts the share.

Network : you have to check if required ports for kerneros is alreday opened.

You can launch a netwoork capture on impacted client machineto more understand and get more details why the user is not authenticated at first time.

Please don't forget to mark helpful answer as accepted

Answer 2

I've made a little progress.

After deletion of all mapped drive and remount with the cmd
NET USE X: \\Server_IP\ShareFolder /savecred /p:yes

the access to the share won't generate EvID4625 anymore but those failed login events keeps popping up when I write/delete files.

One failed login event for each write operation. Since the write operations goes well despite the event audit, I suspect that windows tries local domain credential to write into the share folder, only after the failure it uses the credential saved with the drive mount cmdlet.

Is the only solution to estabilish a trust relationship between the two domains?