How to prevent domain admin credentials from being cached under a domain user's security context
When I remotely assist another user in my domain and subsequently access a share on a server I am prompted for my (domain) administrative credentials. That's expected. What is troublesome is that during any subsequent traversal to that location, I am not prompted for my credentials again. This implies that my credentials are cached somehow under the remote user's security context. In essence, I could end the remote assistance session and they could still access the share on the server. Where in Group Policy or AD is this setting defined and how can I prevent my administrative credentials from being cached on all remote users' computers in the future?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
The glaring issue I see with this McKnife is the following statement: "The usage scenario: User needs support, the problem has been identified: it is not a user profile problem so we will not need to work inside the user's session..."
The assumption in my use case is that I need to perform Windows Remote Assistance in the user's session. In your experience is this possible using the same or similar techniques that you've described using RDP?
The assumption in my use case is that I need to perform Windows Remote Assistance in the user's session. In your experience is this possible using the same or similar techniques that you've described using RDP?
Look, you seem to misunderstand something: if it is a problem that can only be corrected when acting as user, then no administrative permissions are needed, thus no account change. If it is a problem that can only be corrected by an admin, then the corrective action can and should be performed in the admin session, not in the user session.
Your use case "enter admin credentials inside the user session" is never needed and should never be done for security reasons.
Your use case "enter admin credentials inside the user session" is never needed and should never be done for security reasons.
Hi SnAkEhIpS,
Do you mean that there is a one-time requirement during, say, initialisation / first run (as opposed to installation) of an application, that needs to do something requiring admin rights (or at least more rights that the user has) in order to run, but thereafter, the software will run fine as the normal user?
Thanks,
Alan.
Do you mean that there is a one-time requirement during, say, initialisation / first run (as opposed to installation) of an application, that needs to do something requiring admin rights (or at least more rights that the user has) in order to run, but thereafter, the software will run fine as the normal user?
Thanks,
Alan.
ASKER
Actually, both issues exist Alan. That is to say, domain credentials are being used to perform remote support tasks and we also have some applications that have a one-time requirement for initialization or first use. The former practice we can eliminate, but the latter we don't have a workaround for at this time.
Please come back to my suggestion and name one example where it wouldn't suffice to remote into the machine with a different account and make the required change or installation or corrective measure as admin.
Sure, there are applications that ask the user for administrative permissions at first start, but that can be overcome by preseeding things as admin - if you know how.
Sure, there are applications that ask the user for administrative permissions at first start, but that can be overcome by preseeding things as admin - if you know how.
ASKER
"Preseeding things as admin"... it seems to me that you are referring to https://msdn.microsoft.com/en-us/library/windows/desktop/aa369519(v=vs.85).aspx or https://msdn.microsoft.com/en-us/library/windows/desktop/aa372468(v=vs.85).aspx or altering an application's manifest or using some other method. Obviously, I'm seeking the solution involving the least complexity, because, as we all know, every IT department has limited resources and staff with varying skill sets. If anyone has anything more to add, please do. Perhaps I'm still misunderstanding something.
Those links are not what I meant. Reseeding would simply mean to adjust permissions before the user runs into permission issues. I am on vacation and not ready to type a lot on my phone. Will return on Tuesday. If you could name an example by then, we can discuss it.
If it is just the one-time initialisation that is an issue, then you could do it this way:
1) Change the user password to something only you know
2) Make the user a local admin
3) RDP in using the user credentials
4) Install / initialise as required
5) Reboot the user's machine
6) Make the user a normal (non admin) user
7) Change the user's password to something, and force them to immediately change it to whatever they like
That way you have never had your (domain admin) credentials on their machine.
Alan.
1) Change the user password to something only you know
2) Make the user a local admin
3) RDP in using the user credentials
4) Install / initialise as required
5) Reboot the user's machine
6) Make the user a normal (non admin) user
7) Change the user's password to something, and force them to immediately change it to whatever they like
That way you have never had your (domain admin) credentials on their machine.
Alan.
ASKER