How to alter NTFS permission WITHOUT asking user to logoff.

There is, but it would require the user to execute a script that purges and renews his Kerberos tickets. This will not look easier to him, believe me.

But, isn't it possible for the server to remotely start a script on a workstation?  Why would that not be transparent to the user?

By the way, I did some further research and ran across a link which has a workaround.  But, I like your idea of a script better.  Would it be difficult for you to create such a script? ( I'm pretty good at vb so if you give me some pointers to the APIs I could probably do the grunt work myself.)

This workaround came from here.
ADD group to folder. ADD individual to GROUP, then ADD user directly to the Folder.
The User would then have immediate access to files, then within a weeks time, remove Individual user, since the group security would then be in effect of Users next login.

Not transparent. The server would have to impersonate the user.
But please feel free and use it, it's using the single line
klist.exe purge

I'll try it tomorrow and see what happens.

klist.exe purge did not work.

On the server, I added jane.doe to security group named "Full Control of Contracts Folder".

On Jane's Windows 7 Pro computer I opened a command line and ran "klist.exe purge" which responded "tickets purged".  Jane was still not able to access the Contracts Folder.

I logged her off, and logged her back on, and she then had full access.  

Does anybody have any better ideas?

Each test is time consuming because I am trying to always start from the same initial state - which is to have admin remove user from group, then log jane.doe off and back on.

in my first test, I thought I had success.

I added jane.doe to security group named "Full Control of Contracts Folder".
On Jane's Windows 7 Pro computer I ran
klist.exe purge

Jane was still not able to access the s:\sharename\Contracts.
but, she WAS able to access \\server.mydomain.local\sharename\contracts.

I flipped back an forth using explorer, and it was very clear that FQDN\sharename\contracts worked but s:\sharename\contracts

But then I logged off and  tried to repeat the test carefully, it did not work.  

I then tried 3 more times and was about to give up when a the fourth try worked  !!  And again, it was clear that fqdn was the only way to access the file -- attempts through the "normal" name would fail.

I then I logged off again and repeated the test 5 more times but they all failed.

So, the fully qualified domain name helped twice, but there seems to be some unknown variable that is needed to make it work all the time. I tried variations such as running klist purge with elevated privilege and frequently ran gpupdate /force but nothing made it work again.

Any help would be appreciated.

No other variables in here, what makes it work sometimes an sometimes not is maybe just latency. Allow a moment after purging and accessing fqdn. It always worked for me, did several tests.

yes latency seems to explain it.  I  have determined that the security change takes somewhere between 15 minutes and 3 hours to become effective. I had hoped that klist purge would speed up the process, but that does not seem to be the case.  In fact, I am not entirely convinced that klist purge affects things at all.

Here is the important thing. I can change the logon script so the S: drive is mapped to \\server.domain.local\sharename  !!!.  instead of \\server\sharename.

I think this will be giant step towards making security work "properly" and I believe it will be entirely transparent to users. In the future, changes to security would become effective in 3 hours (or maybe less.)

I will probably close this question soon, but I want to do a few more experiments first.

The latency I am talking about is some seconds. I tested multiple times and got instant reproducible results.

<<The latency I am talking about is some seconds>> I no longer think latency is the issue.  

I continue to get random results.  My most recent test was to return jane doe to "normal" and log her on, then add her to the Folder Allowed group.  20 hours later she still could not get the fqdn folder.  All attempts to use klist and gpupdate failed.  The only way I could get her access was to logoff and logon again.

So, 3 times fqdn has helped, but all other times it has not.  I suspect that my Windows Small Business Server 2003 might have a bug (yikes !!!! it really is a decade old !!!)


What version of Windows Server are you running?

If you don't have any further ideas, I will close this question.  The "correct" answer is "the only straightforward way to make Windows security take affect is to log off an log on again".

after 24 hours, Jane's session now has access to the fqdn folder!!!  And yes, I am sure that it is the same session - there has not been a logoff since yesterday afternoon.

Totally random, and I still think it is due to 10 year old server software.

McKnife:  You said " I tested multiple times and got instant reproducible results. "

Could you give me more details of your test?  Specifically, I hoped you granted folder permission using security groups.

(if you granted folder permission using user names, that always seems to take affect immediately.  That was the workaround I mentioned in my initial post.)

Windows security is simply not designed to allow "Quick" changes.  For security to work properly, users MUST sign off then back on.

All workarounds are of limited value.

More details on the test:
While user is logged on, I added him to a domain security group that had been granted access to a certain folder. Using klist purge (in fact for most tesst I use kerbtray.exe from the windows resource kit (of win NT)), I he can get access after a few seconds if he uses the FQDN - without logging off.

Thanks.  I may give kerbtray a  try sometime.  Unfortunately, right now I have wasted enough time on this minor problem.

Bob

Hi rberke.

In another thread here, I came across this link http://community.spiceworks.com/how_to/show/7562-refresh-user-s-group-membership-without-logging-off-and-on as another method. Didn't know that :)

I won't be able to test it until next week, but that sound very encouraging.  I could create a batch file that does a taskkill of explorer followed by  RunAs /user:MYDOMAIN\marysUsername explorer.exe  /pw=marysPassword.

A minor downside is that it is not transparant.  Even if the user is not at her desk to watch, when she comes back she will know something happened because all windows explorer windows will have closed.  (Excel and other applications will not disappear. If security is being reduced, it might be annoying for Mary.

Bob

And that batch would need to be executed within her session, not only using her password, but executed by her!