0

Our users work in terminal services domain environment. It happens sometimes that users are logged on multiple servers. When security policy forces user to change the password, he changes it on one server (one which would first find out that password has expired, usually when the user logs on new server), while the other sessions are still logged, but with already invalid credentials. From now, all other logged sessions will prevent this user from accessing network services - mapped drives are disconnected, network printers are disconnected. That's normal behaviour, and it's not the problem. But it's confusing for a user.

So i figured it out, it would be nice to inform a user, after he change it's password, that his other sessions are no longer valid and he should re-logon. I was thinking about a small helper process which would run with user privileges all the time, checking if ... And that's the problem.

I know, that something probably happens to access token when the user changed the password on other server. As far as i know access token is after logging only way to determine if a user has access to network ressources. But how to read this specific information? Access tokens have many information structures: http://msdn.microsoft.com/en-us/library/windows/desktop/aa379626(v=vs.85).aspx Maybe somone has better experience with these structures?

Tomasz Szkudlarek
  • 97
  • 1
  • 2
  • 10

1 Answers1

-1

One solution could be to periodically poll a user's homeshare to validate whether it is accessible. This bit of Powershell will accomplish this

[System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") | out-null
$s = {env:HOMESHARE}
if(!(Test-Path($s))){
    $a = [System.Windows.Forms.MessageBox]::Show("Homedrive inaccessible, would you like to log off?" , "Homedrive" , 4)
    if($a -eq "Yes"){
         ## log of if yes clicked
         logoff
    }
}
Raf
  • 308
  • 1
  • 8
  • That's kind of workaround. However we don't use homeshares. There is instead one network share, where we keep all the profiles and all users have access to this path. Only i was hoping for more elegant solution which wouldn't require to test any access ... – Tomasz Szkudlarek Mar 03 '14 at 13:28