Windows Homedrive - mounting fails due to delayed firewall authentication

I would rather remove the authentication for this particular access to the domain for domain clients. 

I do not see much value in accessing the domain DFS File share, as you would have a much higher data value in your DFS/Fileshare anyway. Firewalls could only pickup the general access, but the file server can pickup the particular files. 

Generally speaking, access control on IP base for a file share would be to hard to implement based on the way, the service of heartbeat is started. If windows starts the script faster than SFOS can do the authentication, you will likely run into this issue all the time. 
Only delaying the script would be a viable way or - as mentioned, not using user based authentication for this particular traffic. 

LHerzog said:

The homedrive is a user attribute in AD, it would not be a workaround to use a start script with delay, because this would mount the share but will not set the attribute.

Can you explain what you mean by this? Particularly "but will not set the attribute".

Are you mapping the Home drive through the AD 'Home folder' attribute? Have you tried mapping it with a GPO instead?

I haven't tried this as a solution as we don't use Home folders but we do use user authentication for access to other GPO mapped drives and it works, so I don't see why the Home mapping should be any different if done by GPO.

It isn't perfect as you can't access the drives for about thirty seconds after logging on but the drives are mapped and access works fine after that.

We also get the delay logging in. Not minutes but I usually have to wait about thirty seconds after the login prompt before I try and login.

JasP  it's like you said: GPO mapping of drives is no issue - they will be available after a short time and the drive is mounted.

But if you set this, it is not the same as a standard drive mount.

(screenshot taken from google)

We have apps that read the attributes here:

and want to use them.

it's a huge plus in security if you can leave out unauthenticated usesrs from your file shares in my opinion. Now you would only rely on file share ACL. Maybe one day there is some zero day in Windows SMB again that would allow anonymous access. You'd want a firewall that can stop it then.

I understand the need, but at this point, i am not sure, how we should be faster than the windows sub system. And clearly, if the sub system is not doing it "again", we are not able to build the authentication after that. 

I agree and cannot see how Sophos would be able to manage this. Eventually with a cached authentication pushed to firewall before the user is fully authenticated. Not perfect but an idea.

I hope someone has a "delay home drive mount" option for the windows side.

Maybe set H: using GPO and read H: UNC-path within loginscript and write to homeDirectory Attribute?
What kind of Software uses that AD-Attribute? I'd rather look for another solution within that software.

At least as server stored userprofles getting more and more outdated and being replaced with fslogix...
I think you will not build your whole it-concept around one specific (old?) software, that uses legacy windows functions/attributes?

You can set homeDirectory yourself and use GPO to map Home drive (instead of using 'Home folder' in AD) then it should behave the same as all the other GPO mapped drives.

I set the path \\server\share\username in HomeDirectory attribute in AD without HomeDrive

Windows Client uses it in variables as:

before:
set
...
HOMEDRIVE=C:
HOMEPATH=\Users\username
...

after (only when firewall rule allows unauthenticated traffic)
set
...
HOMEDRIVE=C:
HOMEPATH=\
HOMESHARE=\\server\share\username
...

unfortunately, this is causing the same issue. When the firewall rule to the file server requires user authentication, the home share variable will not be set on the client and the user login to Windows is slow, "waiting for user profile service".

screenshot shows firewall blocking access to file server during Windows logon. And one success after the user is logged on and did a manual browse on the server file share.

So Windows seems to want to access the UNC path of HOMESHARE even when there is no need to mount it as drive.

Sophos Support has no solution currently but has filed is as Feature Request WINEP-I-293

thank you Vivek Jagad  for your confirmation today via mail