How to alter NTFS permission WITHOUT asking user to logoff.

I created a new user group named "Contract Folder Administrators" on a small business server 2003.  
"Joe" was a member of this group.

I added this group with Full Control to a preexisting folder:

s:\contracts\   where S: is mapped to shared folder \\server02\Shared. The full UNC name is
\\server01\Shared\Contracts\    

on server01 joe could not access the folders.  I ran gpedit  and gpedit /force but that did not help. I asked Joe to lock and unlock his computer with Windows Key L but that did not help.  Finally, I asked him to log off and back on and that did the trick.

Is there any way to force the security updates to take effect immediately so my users don't have to log off?  

rberke
LVL 5
rberkeConsultantAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

McKnifeCommented:
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.
0
rberkeConsultantAuthor Commented:
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.
0
McKnifeCommented:
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
0
Introducing the "443 Security Simplified" Podcast

This new podcast puts you inside the minds of leading white-hat hackers and security researchers. Hosts Marc Laliberte and Corey Nachreiner turn complex security concepts into easily understood and actionable insights on the latest cyber security headlines and trends.

rberkeConsultantAuthor Commented:
I'll try it tomorrow and see what happens.
0
rberkeConsultantAuthor Commented:
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?
0
McKnifeCommented:
I will help you out.
I tried myself and could figure out this: after purging, you need to use the FQDN and afterwards, you are given access right away. So before, you might have used \\server\share. Instaed, now use \\server.domain.local\share
This worked here and I think THAT was the reason why (10 years ago) we abandoned the thought... far too complicated for the ordinary user.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
rberkeConsultantAuthor Commented:
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.
0
McKnifeCommented:
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.
0
rberkeConsultantAuthor Commented:
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.
0
McKnifeCommented:
The latency I am talking about is some seconds. I tested multiple times and got instant reproducible results.
0
rberkeConsultantAuthor Commented:
<<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".
0
rberkeConsultantAuthor Commented:
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.
0
rberkeConsultantAuthor Commented:
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.)
0
rberkeConsultantAuthor Commented:
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.
0
McKnifeCommented:
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.
0
rberkeConsultantAuthor Commented:
Thanks.  I may give kerbtray a  try sometime.  Unfortunately, right now I have wasted enough time on this minor problem.

Bob
0
McKnifeCommented:
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 :)
0
rberkeConsultantAuthor Commented:
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
0
McKnifeCommented:
And that batch would need to be executed within her session, not only using her password, but executed by her!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
OS Security

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.