"The account is not authorized to log in from this station" on Redirected Folders, after 12 hours of stable running
I use Redirected Folders extensively on my Windows based network. Through GPOs, my Documents, Pictures, Desktop, AppData, etc are redirected to a network path on the file server, instead of the local C: drive. I've used it this way for years and never had any problems.
Back around May 2018, I updated to Windows 10 Pro 1803 on my desktop PC. As you may have heard, this universally broke the redirection for AppData (for me totally unfixable with the registry hack work around, but now properly fixed by MS in a late June patch). So I had to roll back to 1709, which I'd been running before. This was a success and I carried on working with the 1709 release.
Everything works fine, but typically after approx 12 hours, the network connections for all my Redirected Folders seem to get cut off / deauthorised. I get a message up as so, if I try to refresh my desktop or access an SMB share on the file server:
The fixes people have posted online don't seem relevant as this is not a constant problem - as mentioned all is fine for typically about 12 hours after logging in. The only way to resolve is to log out and back in again, which clears the problem for another 12 hours or so.
I have tried upgrading to Win 10 1803 again, now the patch is available that fixes the issue with AppData redirection. Also, I have left the PC being part of the AD domain on my desktop PC, deleted the computer account from the AD domain, and rejoined again. No joy.
This is a really weird one (and frustrating as I can only test things I've tweaked every 12 hours or more, when it goes wrong again), and I was going to throw in the towel and do a clean install, but I'd really rather find out what is going wrong and save myself many hours of work reinstalling and reconfiguring apps and settings.
Any thoughts appreciated! Cheers :-)
Back around May 2018, I updated to Windows 10 Pro 1803 on my desktop PC. As you may have heard, this universally broke the redirection for AppData (for me totally unfixable with the registry hack work around, but now properly fixed by MS in a late June patch). So I had to roll back to 1709, which I'd been running before. This was a success and I carried on working with the 1709 release.
Everything works fine, but typically after approx 12 hours, the network connections for all my Redirected Folders seem to get cut off / deauthorised. I get a message up as so, if I try to refresh my desktop or access an SMB share on the file server:
The fixes people have posted online don't seem relevant as this is not a constant problem - as mentioned all is fine for typically about 12 hours after logging in. The only way to resolve is to log out and back in again, which clears the problem for another 12 hours or so.
I have tried upgrading to Win 10 1803 again, now the patch is available that fixes the issue with AppData redirection. Also, I have left the PC being part of the AD domain on my desktop PC, deleted the computer account from the AD domain, and rejoined again. No joy.
This is a really weird one (and frustrating as I can only test things I've tweaked every 12 hours or more, when it goes wrong again), and I was going to throw in the towel and do a clean install, but I'd really rather find out what is going wrong and save myself many hours of work reinstalling and reconfiguring apps and settings.
Any thoughts appreciated! Cheers :-)
ASKER
Thanks for your post - variants of that suggestion are indeed the ones I've come across. I haven't actively tried it as in all cases I've read the person has a terminal problem accessing shares (whereas with mine, all works fine for 12 hours+, then decides to break). I was also a little worried about disabling the security signature, although does that simply mean that some kind of token based or similar security validation that's taking place is no longer enforced, and it's not too big a deal? I don't want to do anything to reduce the security of the network, even if it is just effective on the LAN.
I suppose the answer is to try this to just rule out whether it will work or not, even if it isn't the ideal long term solution, so I'll give it a go now.
Cheers!
I suppose the answer is to try this to just rule out whether it will work or not, even if it isn't the ideal long term solution, so I'll give it a go now.
Cheers!
if SMB signing is the reason for the issue as suggested by the link FOX gave you, you might read the article MS provided to explain the issue
https://support.microsoft.com/en-us/help/887429/overview-of-server-message-block-signing
here is an excerpt of the article which describes how to configure group policies to solve the issue rather than write manually into the windows registry.
the article and the issue is pretty old such that i have some doubts that it will solve your problem.
as far as i understand you have a domain driven network and an active directory running on your system. if so, why would you need redirection rather than using AD for your purposes?
Sara
https://support.microsoft.com/en-us/help/887429/overview-of-server-message-block-signing
here is an excerpt of the article which describes how to configure group policies to solve the issue rather than write manually into the windows registry.
Configuring SMB signing
We recommend that you use Group Policies to configure SMB signing because a local registry value change does not function correctly if there is an overriding domain policy. The following registry values are changed when the associated Group Policy is configured.
Policy locations for SMB signing
Note The following Group Policy settings are located in the "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options" Group Policy Object Editor path.
Windows Server 2003 - default domain controllers Group Policy
Workstation/Client
Microsoft network client: Digitally sign communications (always) Policy Setting: not defined
Microsoft network client: Digitally sign communications (if server agrees) Policy Setting: not defined Effective Setting: enabled (because of local policy)
Server
Microsoft network server: Digitally sign communications (always) Policy Setting: enabled
Microsoft network server: Digitally sign communications (if client agrees) Policy Setting: enabled
Windows XP and 2003 - local computer Group Policy
Workstation/Client
Microsoft network client: Digitally sign communications (always) Security Setting: disabled
Microsoft network client: Digitally sign communications (if server agrees) Security Setting: enabled
Server
Microsoft network server: Digitally sign communications (always) Security Setting: disabled
Microsoft network server: Digitally sign communications (if client agrees) Security Setting: disabled
the article and the issue is pretty old such that i have some doubts that it will solve your problem.
as far as i understand you have a domain driven network and an active directory running on your system. if so, why would you need redirection rather than using AD for your purposes?
Sara
To me it sounds like the kerberos ticket lifetime is set to 12 hours. Please verify the time as outlined in the policies mentioned in https://www.stigviewer.com/stig/windows_server_2012_domain_controller/2014-01-07/finding/V-2378
ASKER
Hi Sara - thanks for your input and link to that article. Wasn't sure about your final question: "why would you need redirection rather than using AD for your purposes?" as those are two separate things.
As mentioned in my question, I'm using Group Policy to redirect key user folders to the file server, instead of sitting locally. So for example, my 'Documents' folder, which would normally be in "C:\Users\bobby\Documents"
What's clearly happening is something is causing access rights to these network shares to 'expire' at intervals. When it happens, the immediate indicator is that my desktop icons disappear and applications cease to work properly (such as Firefox) as the 'Desktop' and 'AppData' folders are redirected through this policy. If I try to refresh the desktop, I get the message I screenshotted appearing.
Thanks :-)
As mentioned in my question, I'm using Group Policy to redirect key user folders to the file server, instead of sitting locally. So for example, my 'Documents' folder, which would normally be in "C:\Users\bobby\Documents"
What's clearly happening is something is causing access rights to these network shares to 'expire' at intervals. When it happens, the immediate indicator is that my desktop icons disappear and applications cease to work properly (such as Firefox) as the 'Desktop' and 'AppData' folders are redirected through this policy. If I try to refresh the desktop, I get the message I screenshotted appearing.
Thanks :-)
ASKER
Thanks McKnife - the 'Maximum lifetime for user ticket' I can confirm is the default 10 hours. It may well be that this problem is actually happening after only 10 hours (12 hours was an estimate). This was the kind of thing I was thinking - that some kind of token type resync that was supposed to occur at this interval was failing for some reason.
I'm wondering whether the rollback to the system did something to way in which the DCs are interacting with my system, something quite abstract. I'd hoped leaving and rejoining the domain (and recreating the Computer account / SID) would fix it. I also wanted to try running sysprep, but for reasons well beyond this question I know that won't work on this system.
I'll see whether FOX's suggestion has worked later today, but won't hold my breath and think I might just be reinstalling the OS later tonight!
Thanks
I'm wondering whether the rollback to the system did something to way in which the DCs are interacting with my system, something quite abstract. I'd hoped leaving and rejoining the domain (and recreating the Computer account / SID) would fix it. I also wanted to try running sysprep, but for reasons well beyond this question I know that won't work on this system.
I'll see whether FOX's suggestion has worked later today, but won't hold my breath and think I might just be reinstalling the OS later tonight!
Thanks
Short of reinstalling the OS, you could change the "Maximum lifetime for user ticket" value to a longer interval and check whether it is the actual problem source.
ASKER
Thanks McKnife - after typing my response the same occurred to me (or indeed just setting it to zero for a bit?) but for completeness I won't do this until I've seen the result of FOX's suggestion later, otherwise we wouldn't know what fixed it if it does work :-)
Cheers for the thought
Cheers for the thought
ASKER
The same problem has happened as normal, despite the SMB signing being disabled. So I've now set the "Maximum lifetime for user ticket" through the default domain GPO to 72 hours, and will see how it holds up and report back!
Cheers
Cheers
I've started getting this issue with a few users lately. This coincides with a major change in IP addresses (went from 10.0.x.x to 10.2.x.x) and also we raised both Domain and forest functional level to 2008 R2.
So far, I'm just asking the users to disconnect and reconnect to their PCs, but If this starts happening to more people, it'll raise the urgency of this tiny issue quite a bit!
So far, I'm just asking the users to disconnect and reconnect to their PCs, but If this starts happening to more people, it'll raise the urgency of this tiny issue quite a bit!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Is the below one of the reads you already saw and tried?
ref link: https://social.technet.microsoft.com/Forums/windows/en-US/cc1d74af-f739-4070-84fb-86319d103cc9/problem-the-account-is-not-authorized-to-login-from-this-station?forum=itprovistanetworking