Mercuriano
asked on
How to stop normal users from managing user accounts in Windows XP
I have just discovered in panic that any of the common users (i.e. without administrator privileges) of two different WinXP machines have full control of the user accounts. I am really surprised how could that happen and how could I avoid it to happen again. Other exclusive tasks of administrator users, like changing the IP address are not compromised.
Could a worm or virus be the culprit? How to protect against? (of course I have the normal security in place).
Thanks in advance for a quick reply.
Could a worm or virus be the culprit? How to protect against? (of course I have the normal security in place).
Thanks in advance for a quick reply.
Are you sure they are normal users?
Are you in a domain or workgroup?
If in a domain, are the user id's in question domain or local userids?
Are you in a domain or workgroup?
If in a domain, are the user id's in question domain or local userids?
Remove the name from the administrator group and also the user group. since if the user has the local admin privilages it will automatically gets the domain privilages and he would be able to make changes. remove all the names that is relevantant to the user whom you are addressing and then check if he is able.
I am sure he should not be able to access.
Cheers
Gopal Krishna K
I am sure he should not be able to access.
Cheers
Gopal Krishna K
Make sure the users are at most of group Users / Domain Users only. Do not group them to Power Users or Administrators.
ASKER
Thanks to all for your response. I did not have time to read in detail the microsoft link but I respond to all the questions:
Hard to believe, yes, surprising, but it is happening to two of my machines. The question is how to solve it now.
It is a workgroup, not a domain. These users are limited users, not privileged, and do not belong to any group other than "user".
gopal_krishna, since they are not in the administration group, there is no way to "remove" them from there, but what do you mean by removing them "the user group"? Please explain.
Hard to believe, yes, surprising, but it is happening to two of my machines. The question is how to solve it now.
It is a workgroup, not a domain. These users are limited users, not privileged, and do not belong to any group other than "user".
gopal_krishna, since they are not in the administration group, there is no way to "remove" them from there, but what do you mean by removing them "the user group"? Please explain.
Creating the account local account and giving the admin rights to the local account.
Cheers
Gopal Krishna K
Cheers
Gopal Krishna K
ASKER
Sorry, I still don´t get it. Could you be more specific?
This statement is not correct "...since if the user has the local admin privilages it will automatically gets the domain privilages ..."
Any local or domain account can be a member of the 'local Administrator' Group without having any network/domain Administrator privileges.
Mercuiano,
There are versions of malware that will 'elevate' privileges of basic accounts.
There are also Registry edits that a normal user can do to increase their own privileges.
I suggest that you do a data back up and re-load the OS on those two computers.
Trying to dive down inside the registry to find any/all changes will be like chasing a rabbit down a hole - way too much work with no sure way to know the end result.
A simple way to verify that they have 'Administrator' rights is to attempt to 'open' the "User Accounts" function in Control Panel. If one of their accounts is allowed to open the Panel and select any of the functions (without an error message), then they truly do have Admin rights.
Back up and reload the entire system.
Good Luck,
Vic
Any local or domain account can be a member of the 'local Administrator' Group without having any network/domain Administrator privileges.
Mercuiano,
There are versions of malware that will 'elevate' privileges of basic accounts.
There are also Registry edits that a normal user can do to increase their own privileges.
I suggest that you do a data back up and re-load the OS on those two computers.
Trying to dive down inside the registry to find any/all changes will be like chasing a rabbit down a hole - way too much work with no sure way to know the end result.
A simple way to verify that they have 'Administrator' rights is to attempt to 'open' the "User Accounts" function in Control Panel. If one of their accounts is allowed to open the Panel and select any of the functions (without an error message), then they truly do have Admin rights.
Back up and reload the entire system.
Good Luck,
Vic
Are these XP Home or XP Pro machiens?
Have these machines ever been members of a domain and had a group policy applied?
If not, then the issue could be with the local security policy.
If you install the Administrative Tools package included on the XP CD, then this will let you use POLEDIT, and you can use this to fix the local security policy and put it back to how you want it.
Have these machines ever been members of a domain and had a group policy applied?
If not, then the issue could be with the local security policy.
If you install the Administrative Tools package included on the XP CD, then this will let you use POLEDIT, and you can use this to fix the local security policy and put it back to how you want it.
Double-check the local Administrators group to make sure that no other user or group is in there. The only member of the Administrators group should be the Administrator user.
Vic,
"Any local or domain account can be a member of the 'local Administrator' Group without having any network/domain Administrator privileges."
For all intents and purposes one should consider them to have domain admin privileges, as having local administrative privileges is just barely down the ladder on the possibility of damaging the domain/network environment.
"Any local or domain account can be a member of the 'local Administrator' Group without having any network/domain Administrator privileges."
For all intents and purposes one should consider them to have domain admin privileges, as having local administrative privileges is just barely down the ladder on the possibility of damaging the domain/network environment.
AdamRobinson,
A local administrator on ComputerA can't even log into or access a file on ComputerB -- much less access a Network Server.
Domain/Network privileges are a function of network user accounts, not local machine accounts.
A local administrator on ComputerA can't even log into or access a file on ComputerB -- much less access a Network Server.
Domain/Network privileges are a function of network user accounts, not local machine accounts.
Young:
I am quite aware of that. Within a domain/network, local administrator accounts can allow for install of things (0-days, or in MS' case, 14-days) that will dig through holes within a domain's security (which, in SMBs, there almost always are).
I am quite aware of that. Within a domain/network, local administrator accounts can allow for install of things (0-days, or in MS' case, 14-days) that will dig through holes within a domain's security (which, in SMBs, there almost always are).
Young,
Perhaps I should be clearer, as I re-read my comment before yours and see why you wrote what you did. I did not mean to imply that local administrator accounts are the same as domain administrator accounts in any way. My own experience is that when a business has this type of question, they were often are not fully patched, properly firewalled, and in most cases not properly configured (re: permission rights on the server being wrong all over the place) and suffer from numerous other problems that allow for a virus installed on a single workstation to propagate throughout the network -- specifically if they have extraneous ports open for no reason. While what you stated is explicitly correct, I've watched businesses (one with local administrative rights given, one without) in virtually the same set up have drastically different reactions to an infection. In the former case, while the domain controllers weren't affected, all of the clients became infected within an hour. In the latter case, the logs showed failed attemtps at malware installs on all of the client computers. One had a clogged network for the day, the other had normal operations.
Didn't mean to sound as if you were incorrect, as you obviously are not, but I deal with the "Should I give my users local administrator rights?" issue quite often, and while in many cases it's the most cost effective, if you're domain isn't secure/up to date, I think it causes far more trouble than it's worth.
In the case of this question, I may be somewhat off target given it is a workgroup, but I doubt it's too much so.
Perhaps I should be clearer, as I re-read my comment before yours and see why you wrote what you did. I did not mean to imply that local administrator accounts are the same as domain administrator accounts in any way. My own experience is that when a business has this type of question, they were often are not fully patched, properly firewalled, and in most cases not properly configured (re: permission rights on the server being wrong all over the place) and suffer from numerous other problems that allow for a virus installed on a single workstation to propagate throughout the network -- specifically if they have extraneous ports open for no reason. While what you stated is explicitly correct, I've watched businesses (one with local administrative rights given, one without) in virtually the same set up have drastically different reactions to an infection. In the former case, while the domain controllers weren't affected, all of the clients became infected within an hour. In the latter case, the logs showed failed attemtps at malware installs on all of the client computers. One had a clogged network for the day, the other had normal operations.
Didn't mean to sound as if you were incorrect, as you obviously are not, but I deal with the "Should I give my users local administrator rights?" issue quite often, and while in many cases it's the most cost effective, if you're domain isn't secure/up to date, I think it causes far more trouble than it's worth.
In the case of this question, I may be somewhat off target given it is a workgroup, but I doubt it's too much so.
AdamRobinson,
I think we're singing from the same hymnal (if not from the same page).
richrumble (the Security Editor) talks a lot about the 'Principle of Least Privilege' and I wish I had known more about that when I was fighting Network Security problems.
The only chunk of malware that ever made into one of my Domains was 'nimda' - and the only boxes that got infected were the ones where the normal user was a member of the local box Admin Group.
Since finding that stuff out the hard way, I don't even put my own account in ANY of the Administrator Groups (Local or Domain). I log in as a straight leg user and 'Run AS' when I have to do admin stuff.
Good Discussion.
Vic
I think we're singing from the same hymnal (if not from the same page).
richrumble (the Security Editor) talks a lot about the 'Principle of Least Privilege' and I wish I had known more about that when I was fighting Network Security problems.
The only chunk of malware that ever made into one of my Domains was 'nimda' - and the only boxes that got infected were the ones where the normal user was a member of the local box Admin Group.
Since finding that stuff out the hard way, I don't even put my own account in ANY of the Administrator Groups (Local or Domain). I log in as a straight leg user and 'Run AS' when I have to do admin stuff.
Good Discussion.
Vic
ASKER
Thanks again to all the respondents and for the interesting discussion. I will answer here to these that expect an answer from me:
younghv
Regarding the administrator rights, as I said, they are not complete. These users can fully manage user accounts, but nothing else I could see so far. Other administrator tasks like changing the IP address of the machine are not allowed to them, with the customary error message saying that they have no privileges for that. So it seems that they have just the capability of managing accounts, but I have not seen any other “dangerous” capability they may have.
About you suggestion of reloading the whole OS, this means a LOT of work as well. These machines have dozens of applications and settings installed. I would only reinstall when all the other options have failed.
tim_holman
These are XP Pro machines. They have never been members of a domain (this responds also to some other of the comments from other people). I will try your suggestion with POLEDIT as soon as I get the opportunity (I am now 600Km away from the machines).
Which brings me to another issue. I have VNC installed on these two machines but I cannot get connected. I imagine I need to set up some security settings, does anybody know which? I do not have this problem with the Win2000 machines, just with XP.
younghv
'nimda' runs a bell. I had this virus about a year ago in another machine in the network, but I managed (I think) to eliminate it. And indeed one of the two machines (but not the other) where I have this problem now, did during several months (but long after eliminating nimda) belong to the administration group, but that was long after nimda was eliminated in the third machine. Lets assume that the virus was hidden somewhere and infected the machine that got for some period of time administrator rights, how could it be able to go to the other one?
younghv
Regarding the administrator rights, as I said, they are not complete. These users can fully manage user accounts, but nothing else I could see so far. Other administrator tasks like changing the IP address of the machine are not allowed to them, with the customary error message saying that they have no privileges for that. So it seems that they have just the capability of managing accounts, but I have not seen any other “dangerous” capability they may have.
About you suggestion of reloading the whole OS, this means a LOT of work as well. These machines have dozens of applications and settings installed. I would only reinstall when all the other options have failed.
tim_holman
These are XP Pro machines. They have never been members of a domain (this responds also to some other of the comments from other people). I will try your suggestion with POLEDIT as soon as I get the opportunity (I am now 600Km away from the machines).
Which brings me to another issue. I have VNC installed on these two machines but I cannot get connected. I imagine I need to set up some security settings, does anybody know which? I do not have this problem with the Win2000 machines, just with XP.
younghv
'nimda' runs a bell. I had this virus about a year ago in another machine in the network, but I managed (I think) to eliminate it. And indeed one of the two machines (but not the other) where I have this problem now, did during several months (but long after eliminating nimda) belong to the administration group, but that was long after nimda was eliminated in the third machine. Lets assume that the virus was hidden somewhere and infected the machine that got for some period of time administrator rights, how could it be able to go to the other one?
M,
The rights you describe sound as though the users were made part of the "Account Operators" group. Managing other accounts is how that is used.
If you have run completely updated AV and Anti-spyware scans (in Safe Mode), then you can have a fair level of confidence that the boxes are not infected.
For a real deep look at what might be hidden on them, follow this advice:
Author: rpggamergirl
https://www.experts-exchange.com/M_3598771.html
Get the newest version of HJT:
(an already renamed hijackthis)
http://danborg.org/spy/hjt/alternativ.exe
Open Hijackthis, click "Do a system scan and save a logfile" don't fix anything yet.
Then go to the below link and login using your Experts-Exchange username and password.
http://www.ee-stuff.com
Click on "Expert Area" tab
type or paste the link to your Question
"Browse" your pc to the location of your Hijackthis log and click "Upload"
Copy the resulting "url" and post it back here.
OR: paste the log to either of these sites:
1. http://www.rafb.net/paste/
then at the bottom left corner click "paste"
Copy the address/url and post it here.
2. or at --> http://www.hijackthis.de/
and click "Analyse", click "Save". Then post the link to the saved list here.
Be aware that several forms of malware are designed to 'run' along the network to any vulnerable hosts. Just one infected system on your backbone will reach out and infect any other that it can touch.
There is a special place in Hell for malware writers.
Post back when you can.
Vic
The rights you describe sound as though the users were made part of the "Account Operators" group. Managing other accounts is how that is used.
If you have run completely updated AV and Anti-spyware scans (in Safe Mode), then you can have a fair level of confidence that the boxes are not infected.
For a real deep look at what might be hidden on them, follow this advice:
Author: rpggamergirl
https://www.experts-exchange.com/M_3598771.html
Get the newest version of HJT:
(an already renamed hijackthis)
http://danborg.org/spy/hjt/alternativ.exe
Open Hijackthis, click "Do a system scan and save a logfile" don't fix anything yet.
Then go to the below link and login using your Experts-Exchange username and password.
http://www.ee-stuff.com
Click on "Expert Area" tab
type or paste the link to your Question
"Browse" your pc to the location of your Hijackthis log and click "Upload"
Copy the resulting "url" and post it back here.
OR: paste the log to either of these sites:
1. http://www.rafb.net/paste/
then at the bottom left corner click "paste"
Copy the address/url and post it here.
2. or at --> http://www.hijackthis.de/
and click "Analyse", click "Save". Then post the link to the saved list here.
Be aware that several forms of malware are designed to 'run' along the network to any vulnerable hosts. Just one infected system on your backbone will reach out and infect any other that it can touch.
There is a special place in Hell for malware writers.
Post back when you can.
Vic
Anyone finding Least Privilege not as easy to work with since IE7? I restrict my personal acct the same as anyone else here. I used to be able to runas in IE6 and older with elevated rights and then change the location away from the web and instead to C: OR \\computername\C$ and effectively have a windows explorer window with elevated rights. Can't do it anymore in IE7. I'm going to post this as a question so 500 to the person who delivers the best workaround.
https://www.experts-exchange.com/questions/22093822/Can't-gain-escalated-privileges-to-windows-explorer-by-doing-a-RUNAS-on-IE7.html
Okay, that may have been rude to post my own question and not look at / offer advice on this one. So,...
[quote]Which brings me to another issue. I have VNC installed on these two machines but I cannot get connected. I imagine I need to set up some security settings, does anybody know which? I do not have this problem with the Win2000 machines, just with XP.
Sure. Dump VNC on the XP machines. You don't need it, and last I heard there was a major zero day for vnc, so if nothing else ensure you are using the latest and greatest version of it. Instead, enable remote desktop on the destinations and on the computer you want to connect FROM, go START->RUN->MSTSC and supply the IP or computername. Baddabing baddaboom. Remote access. Built in encryption with RDP. No VNC worries.
https://www.experts-exchange.com/questions/22093822/Can't-gain-escalated-privileges-to-windows-explorer-by-doing-a-RUNAS-on-IE7.html
Okay, that may have been rude to post my own question and not look at / offer advice on this one. So,...
[quote]Which brings me to another issue. I have VNC installed on these two machines but I cannot get connected. I imagine I need to set up some security settings, does anybody know which? I do not have this problem with the Win2000 machines, just with XP.
Sure. Dump VNC on the XP machines. You don't need it, and last I heard there was a major zero day for vnc, so if nothing else ensure you are using the latest and greatest version of it. Instead, enable remote desktop on the destinations and on the computer you want to connect FROM, go START->RUN->MSTSC and supply the IP or computername. Baddabing baddaboom. Remote access. Built in encryption with RDP. No VNC worries.
How to reset security settings back to pre-policy defaults:
http://support.microsoft.com/kb/313222
To get VNC working, you'll need to allow it through the Windows XP firewall.
To do this remotely is tricky, seeming you can't get in, but you could write a script that the user runs, which allows through the VNC ports.
http://www.windowsecurity.com/articles/Customizing-Windows-Firewall.html
If you need help with netsh, suggest you open up another question, as we're digressing a bit from the original thread.
http://support.microsoft.com/kb/313222
To get VNC working, you'll need to allow it through the Windows XP firewall.
To do this remotely is tricky, seeming you can't get in, but you could write a script that the user runs, which allows through the VNC ports.
http://www.windowsecurity.com/articles/Customizing-Windows-Firewall.html
If you need help with netsh, suggest you open up another question, as we're digressing a bit from the original thread.
It's easy to edit/open the firewall remotely if you can gain access to the remote registry.
(from a technet article)
Windows Firewall stores its rules in two locations in the registry:
HKLM\Software\Policies\Mic
This subkey contains the settings you configure through Group Policy (both local Group Policy and domain-based Group Policy).
HKLM\System\CurrentControl
This subkey contains the settings you configure through Windows Firewall in Control Panel, the netsh firewall command, and scripts.
(from a technet article)
Windows Firewall stores its rules in two locations in the registry:
HKLM\Software\Policies\Mic
This subkey contains the settings you configure through Group Policy (both local Group Policy and domain-based Group Policy).
HKLM\System\CurrentControl
This subkey contains the settings you configure through Windows Firewall in Control Panel, the netsh firewall command, and scripts.
Reg script that would open VNC on the windows personal firewall.
Note: You must replace 5900 with whatever port you're using if it isn't 5900.
Replace 123.123.0.0/255.255.0.0 with the IP & mask of the computer or subnet you wish to connect from.
Rather than rely on the script, you could connect to the remote registry and manually create the string and name it "5900:TCP" and set the value as "5900:TCP:123.123.0.0/255.
==========================
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM
"5900:TCP"="5900:TCP:123.1
Note: You must replace 5900 with whatever port you're using if it isn't 5900.
Replace 123.123.0.0/255.255.0.0 with the IP & mask of the computer or subnet you wish to connect from.
Rather than rely on the script, you could connect to the remote registry and manually create the string and name it "5900:TCP" and set the value as "5900:TCP:123.123.0.0/255.
==========================
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM
"5900:TCP"="5900:TCP:123.1
Vic is absolutely correct in what he says, and there is a world of difference between local & domain admin rights.. Local admin may give you the keys to the castle, but domain admin has them for the kingdom!
Like I said, just my two cents, not a criticism Adam :)
~isyseurope
Like I said, just my two cents, not a criticism Adam :)
~isyseurope
ASKER
Again, a multiple response in one letter:
Since I am not anymore in the vicinity o the two machines (I was when I started this thread), in order to do anything I have first to get access. I can get into the network via VPN and can login into any Win2000 machines in there via VNC, but this does not work for the XP.
expexchuser
I have two problems with MSTSC:
1. I still have to enable something in the remote machine, don’t I? What is it?
2. I cannot use a Win2000 as remote terminal, can I? Or is there any solution for that?
younghv,
I cannot run hijack until I gain access. I shall do it as soon as I am able to do so.
tim_holman/expexchuser
I do not use PC software firewall but a firmware based specialized router, which I can control remotely and set any ports required. The 5800 and 5900 ports are enabled, and this is how I can connect into the Win2000 machines. It is only the WinXP that does not work and it may have to do with some security setting in these PC’s. The question is to identify this setting.
Sorry to digress from he original thread. If anybody else things this way I will open another thread. In any case I will do it (selecting and crediting the appropriate messages) when this issue is solved.
Since I am not anymore in the vicinity o the two machines (I was when I started this thread), in order to do anything I have first to get access. I can get into the network via VPN and can login into any Win2000 machines in there via VNC, but this does not work for the XP.
expexchuser
I have two problems with MSTSC:
1. I still have to enable something in the remote machine, don’t I? What is it?
2. I cannot use a Win2000 as remote terminal, can I? Or is there any solution for that?
younghv,
I cannot run hijack until I gain access. I shall do it as soon as I am able to do so.
tim_holman/expexchuser
I do not use PC software firewall but a firmware based specialized router, which I can control remotely and set any ports required. The 5800 and 5900 ports are enabled, and this is how I can connect into the Win2000 machines. It is only the WinXP that does not work and it may have to do with some security setting in these PC’s. The question is to identify this setting.
Sorry to digress from he original thread. If anybody else things this way I will open another thread. In any case I will do it (selecting and crediting the appropriate messages) when this issue is solved.
Windows XP SP2 has a built in software firewall, which is where you'll need to open the ports. You could either ask the users to open the relevant ports, or script something using NetSH for them to run.
ASKER
I know, but the Windows Firewall is not active (I always to that if I have an external firewal). I thing there is something else that needs to be activated/enabled.
Not with VNC - you just install it, start the server, and if there are no firewalls in the way, then you will be able to connect to it with the VNC client.
Are you sure the firewall isn't enabled? If you turn it off, users are constantly reminded that it's not on, so it's possible that your users have reactivated it.
Are you sure the firewall isn't enabled? If you turn it off, users are constantly reminded that it's not on, so it's possible that your users have reactivated it.
Mercuriano ,
To address the 2 concerns you have, this article answers both. See the sections on "Firewall settings" and "Installing Remote Desktop connection on non-XP systems."
http://articles.techrepublic.com.com/5100-10877-6119547.html
1) Yes, you have to open the port and have the service running (terminal services). 3389 is the default port for MSTSC traffic. To get the service running/listening on the client side you can go to the Remote tab in System Properties, or by connecting to its remote registry and modifying the following key:
[HKEY_LOCAL_MACHINE\SYSTEM
"fDenyTSConnections"=dword
*By setting it to 0, you are saying DON'T deny remote connections.
2) Not sure I fully follow you.
Can I connect TO Win2k (does win2k support Remote Desktop)? NO; use VNC.
Can I connect TO an XP box FROM win2k? Yes; you can even use it from windows 98 with no installation required:
Copy these 3 files from the windows\system32\ directory of an XP computer: mstsc.exe, mstscax.dll, and mstsc.chm
Drop them to a floppy, CD, or USB Flash drive (whatever's easiest). Then go to any computer you want, xp or not, and double-click the mstsc.exe.
By the way, I would VERIFY no windows personal firewalls are enabled on the client side.
To address the 2 concerns you have, this article answers both. See the sections on "Firewall settings" and "Installing Remote Desktop connection on non-XP systems."
http://articles.techrepublic.com.com/5100-10877-6119547.html
1) Yes, you have to open the port and have the service running (terminal services). 3389 is the default port for MSTSC traffic. To get the service running/listening on the client side you can go to the Remote tab in System Properties, or by connecting to its remote registry and modifying the following key:
[HKEY_LOCAL_MACHINE\SYSTEM
"fDenyTSConnections"=dword
*By setting it to 0, you are saying DON'T deny remote connections.
2) Not sure I fully follow you.
Can I connect TO Win2k (does win2k support Remote Desktop)? NO; use VNC.
Can I connect TO an XP box FROM win2k? Yes; you can even use it from windows 98 with no installation required:
Copy these 3 files from the windows\system32\ directory of an XP computer: mstsc.exe, mstscax.dll, and mstsc.chm
Drop them to a floppy, CD, or USB Flash drive (whatever's easiest). Then go to any computer you want, xp or not, and double-click the mstsc.exe.
By the way, I would VERIFY no windows personal firewalls are enabled on the client side.
ASKER
Thanks to all for the comments.
expexchuser, I thing your comments should fully solve my questions of 12/16/2006 02:25PM CET and that closes this "disgression". As soon as I can try this solutions I will make sure this goes into another thread and is independently credited.
Whith this we should be back on track. Once I gain access to the machines I will be able to try the other suggestions for my original problem (user accounts management) and provide feedback.
Keep tunned!
expexchuser, I thing your comments should fully solve my questions of 12/16/2006 02:25PM CET and that closes this "disgression". As soon as I can try this solutions I will make sure this goes into another thread and is independently credited.
Whith this we should be back on track. Once I gain access to the machines I will be able to try the other suggestions for my original problem (user accounts management) and provide feedback.
Keep tunned!
ASKER
Sorry for the delay, but I am 600 Km away from the computers where this problem ocurred. I will be back there in about 3 weeks and then I will be able to test the suggestions I received here and eventually close the issue. Is it any problem in leaving the issue open for so long?
I would also like to ask about the new thread that appeared here in regard to VNC/MSTSC. I think this is worth 250 points that I woudl like to credit to expexchuser. Perhaps the best would be to copy the question and the answer and creatd with them a new thread and close it as indicated. Can someone take care of that?
Thanks
I would also like to ask about the new thread that appeared here in regard to VNC/MSTSC. I think this is worth 250 points that I woudl like to credit to expexchuser. Perhaps the best would be to copy the question and the answer and creatd with them a new thread and close it as indicated. Can someone take care of that?
Thanks
Merc,
After reading through these posts one more time...glancing really...there is one more thing I would be sure to do to make certain this doesn't happen again. Reset the LOCAL admin password on each PC. Maybe they were able to figure out the local admin password, login as that acct, and use it to elevate their own accounts. I wouldn't have thought this was possible, and I had a feeling someone would chime in, YOU CAN'T ADD A DOMAIN ACCT FROM A LOCAL ACCT, but I just tested and IT IS! At first you wouldn't think so b/c after you add the standard user's domain acct the computer says "Enter the name and password of an account with permissions for <domain>.com". To my amazement, when I added a standard domain user while logged in as local admin, then it prompted for credentials as I just mentioned, I just put the name and password of that standard user in and it allowed it to be joined to the machine's admin group. No admin credentials needed other than the local admin. This is just another reason why it's important to give all local admin accts strong passwords.
Also, like everyone else said:
- Verify there are no unneccessary users in the admin or power user groups
(MMC->Local Users & Groups -> Groups Directory -> open each of the 2 groups to verify)
- Verify the users are ONLY members of the users group
(MMC->Local Users & Groups -> Groups Directory -> Users --- either their name explicitly or the DOMAIN\Domain Users group)
Also try this: Go START->RUN and enter "control userpasswords2" (without quotes) and see what all users are setup and their corresponding permission level.
After reading through these posts one more time...glancing really...there is one more thing I would be sure to do to make certain this doesn't happen again. Reset the LOCAL admin password on each PC. Maybe they were able to figure out the local admin password, login as that acct, and use it to elevate their own accounts. I wouldn't have thought this was possible, and I had a feeling someone would chime in, YOU CAN'T ADD A DOMAIN ACCT FROM A LOCAL ACCT, but I just tested and IT IS! At first you wouldn't think so b/c after you add the standard user's domain acct the computer says "Enter the name and password of an account with permissions for <domain>.com". To my amazement, when I added a standard domain user while logged in as local admin, then it prompted for credentials as I just mentioned, I just put the name and password of that standard user in and it allowed it to be joined to the machine's admin group. No admin credentials needed other than the local admin. This is just another reason why it's important to give all local admin accts strong passwords.
Also, like everyone else said:
- Verify there are no unneccessary users in the admin or power user groups
(MMC->Local Users & Groups -> Groups Directory -> open each of the 2 groups to verify)
- Verify the users are ONLY members of the users group
(MMC->Local Users & Groups -> Groups Directory -> Users --- either their name explicitly or the DOMAIN\Domain Users group)
Also try this: Go START->RUN and enter "control userpasswords2" (without quotes) and see what all users are setup and their corresponding permission level.
<it allowed it to be joined to the machine's admin group> <No admin credentials needed other than the local admin> etc
Local Admin would be allowed to add a new user to the local machine account..
Local Admin would be allowed to add a new user to the local machine account..
isys - not to be rude, but I'm not sure I follow what you're saying / what your point is.
I'm talking specifically taking about LOCAL account granting a DOMAIN account admin privileges. I'm sure I'm not the only one in the world who would be surprised to find a LOCAL acct can add DOMAIN accts. And besides, the point is valid. He should reset the local admin password ... could be how they did it in the first place.
I'm talking specifically taking about LOCAL account granting a DOMAIN account admin privileges. I'm sure I'm not the only one in the world who would be surprised to find a LOCAL acct can add DOMAIN accts. And besides, the point is valid. He should reset the local admin password ... could be how they did it in the first place.
PS - it's not just a new user...it's an existing DOMAIN USER that is only intended to be a member of the domain users group with no admin rights on any system. Members of domain users should, for the most part, be locked down. Unless someone figures out a way to elevate at the local level. Which was the point of my comment.
ASKER
Sorry to interrupt the discussion, but the pc's are not members of a domain. There are just a workgroup and ther users are plain common users, without any privileges. The only strange capability they have is to manage the accounts, but I did not see any other extrange thing.
Is there any way to modfy rights just by tampering with files? Both machines share directories with many users.
Is there any way to modfy rights just by tampering with files? Both machines share directories with many users.
Then I would look at
Start->Run->control userpasswords2
and look at all the users. Delete any unneccesary ones and verify only admin is administrator (unless you have other admin accounts). Reset the passwords on all admin accounts. You should do this every 90 days for security anyway.
Who knows, maybe you should put a keystroke logger on the computer if you really want to get to the bottom of it (with management approval, if applicable, of course).
Since having learned how to use both Reatogo (bartpe) and Knoppix CD-Bootable OS's, nothing amazes me anymore. All the NTFS permissions in the world can't keep a person out of you data/registry when you boot to those. The only way to protect against that is to employ full drive encryption. I'm definitely looking forward to Vista bit locker.
Start->Run->control userpasswords2
and look at all the users. Delete any unneccesary ones and verify only admin is administrator (unless you have other admin accounts). Reset the passwords on all admin accounts. You should do this every 90 days for security anyway.
Who knows, maybe you should put a keystroke logger on the computer if you really want to get to the bottom of it (with management approval, if applicable, of course).
Since having learned how to use both Reatogo (bartpe) and Knoppix CD-Bootable OS's, nothing amazes me anymore. All the NTFS permissions in the world can't keep a person out of you data/registry when you boot to those. The only way to protect against that is to employ full drive encryption. I'm definitely looking forward to Vista bit locker.
Okay, I apologize for only glancing at the previous threads. I just glanced over them again (I know - I'm asking for it). I would not play with poledit...I would look at local group policy from within the management console (start-run-mmc).
Also, it may not be a bad idea to just blast the profiles out of the water. Rename the C:\Documents and Users\<username> directory to <username.old>. Then go to System Properties (for you geeks, that's windowsbutton+Break...at least Microsoft has a sense of humor...windows+break to get to system properties) and choose the advanced tab. User profiles button is in the middle - click it. Then select the profile you renamed and delete it. Create a new one with the same username as before. Then you should be able to delete the <username> folder that is newly created, and rename the .old one back to what it should be. Otherwise you can just leave the new one and the .old one and migrate the data from .old to the new one...specifically mydocs, desktop, favorites, etc.
Good luck. I'm outta here. It's Saturday night and I'm geeking out. Absolutely pathetic. Gonna go check out that new Labrynth flick. Later!
Also, it may not be a bad idea to just blast the profiles out of the water. Rename the C:\Documents and Users\<username> directory to <username.old>. Then go to System Properties (for you geeks, that's windowsbutton+Break...at least Microsoft has a sense of humor...windows+break to get to system properties) and choose the advanced tab. User profiles button is in the middle - click it. Then select the profile you renamed and delete it. Create a new one with the same username as before. Then you should be able to delete the <username> folder that is newly created, and rename the .old one back to what it should be. Otherwise you can just leave the new one and the .old one and migrate the data from .old to the new one...specifically mydocs, desktop, favorites, etc.
Good luck. I'm outta here. It's Saturday night and I'm geeking out. Absolutely pathetic. Gonna go check out that new Labrynth flick. Later!
I should clarify something on that last one. More important than re-generating a user profile is generating a new user acct and SID. After renaming the C:\docume~1\<username> to <username.old>, go into control userpasswords2 and delete the user. DO NOT DO THIS IF YOU USE WINDOWS FILE SYSTEM ENCRYPTION W/O FIRST BACKING UP THE KEYS AND TESTING THEM! If you don't use encryption, then you can safely do this. After you delete the user, re-create the user, even with the same name so they're none the wiser. You will still get a new SID for the acct. Verify they are only members of Restricted User (Users Group) by highlighting the user and clicking properties. Then open the new C:\docume~1\<username> that should be created. Delete all contents. Open the <username.old> folder and copy all contents from there into the newly created <username> directory.
ASKER
Let me go back to the access problem, since I am far away from the machines and will not be able to get close to them in the next 10 days at least. As I said, although I can access other PCs in the LAN running Win2K, I can not access the two troubled machines, both running WinXP, neither with VNC nor with MTSC.
What is still to be done in MTSC is to enable remote desktop on these machines.
I can access their disks with admin rights, but is it there any way to enable remote desktop this way?
Until I get this done I will not be able to do anything regarding the initial thread.
Thanks and sorry again for the digression.
What is still to be done in MTSC is to enable remote desktop on these machines.
I can access their disks with admin rights, but is it there any way to enable remote desktop this way?
Until I get this done I will not be able to do anything regarding the initial thread.
Thanks and sorry again for the digression.
Please answer the following (sorry, I will fully read over the thread again soon...way too busy right now):
1) Are the IP addresses configured for NAT or does each machine have a public IP address?
2) Are the IP addresses static or DHCP assigned?
3) Is port 3389 open on the firewall? I believe that's the default mstsc port.
If you remote into a win2k machine from VNC, you can use that 2k machine as a launchpad to get at the XP computers. Just connect to the C$ share of one of the XP computers and copy the mstsc files I mentioned earlier (mstsc.exe, mstscax.dll, and mstsc.chm) onto the root of the 2k box you're remoted into and double click mstsc.exe. Then specify the XP computer's name or IP address. If you can't connect to that XP computer (I'm still talking from w/in the VNC connection to the 2k box), you'll need to connect to the XP computer's remote registry and change the following key:
[HKEY_LOCAL_MACHINE\SYSTEM
"fDenyTSConnections"=dword
If it's set to dword:00000001, you won't be allowed to remote into it via mstsc. If it's set to 00000000, then you can.
1) Are the IP addresses configured for NAT or does each machine have a public IP address?
2) Are the IP addresses static or DHCP assigned?
3) Is port 3389 open on the firewall? I believe that's the default mstsc port.
If you remote into a win2k machine from VNC, you can use that 2k machine as a launchpad to get at the XP computers. Just connect to the C$ share of one of the XP computers and copy the mstsc files I mentioned earlier (mstsc.exe, mstscax.dll, and mstsc.chm) onto the root of the 2k box you're remoted into and double click mstsc.exe. Then specify the XP computer's name or IP address. If you can't connect to that XP computer (I'm still talking from w/in the VNC connection to the 2k box), you'll need to connect to the XP computer's remote registry and change the following key:
[HKEY_LOCAL_MACHINE\SYSTEM
"fDenyTSConnections"=dword
If it's set to dword:00000001, you won't be allowed to remote into it via mstsc. If it's set to 00000000, then you can.
PS - if you use mstsc to connect to an XP box, the user will be kicked off if they are logged in (you will be warned if that will happen) and it will be locked by the account you remote in with. In other words, they will know you are remoting in.
In addition to the terminal server registry tweak mentioned above, if their windows personal firewall is on and won't let you in over the remote desktop protocol (port 3389 by default), since you have a network firewall protecting you, just go ahead and remote registry into the xp box (from your vnc connection to a 2k box) and connect to it's remote registry (assuming the windows personal firewall isn't EXTREMELY tight...in which case you shouldn't be able to get at C$ either). To temporarily drop the firewall from the remote registry session, just connect to the remote computer's registry from a remote registry connection and open the following key:
HKEY_LOCAL_MACHINE\SYSTEM\
then change EnableFirewall from 1 (enabled) to 0 (disabled).
Shields down.
once you are remoted in with mstsc, you can turn the firewall back on and configure it to allow remote desktop as an exception - but I would open it to your local subnet only. Unless you absolutely want to connect from anywhere in the world. But that could be very dangerous and you will need to open necessary ports on your network firewall. Not a good idea in my opinion.
HKEY_LOCAL_MACHINE\SYSTEM\
then change EnableFirewall from 1 (enabled) to 0 (disabled).
Shields down.
once you are remoted in with mstsc, you can turn the firewall back on and configure it to allow remote desktop as an exception - but I would open it to your local subnet only. Unless you absolutely want to connect from anywhere in the world. But that could be very dangerous and you will need to open necessary ports on your network firewall. Not a good idea in my opinion.
ASKER
Expexchuser, thanks again you for your quick response. I finally could manage to access. I respond to your previous questions because I have questions too:
1) The IP addresses are local. There is a hardware firewall doing NAT, but I do not go through because I access via VPN, but why does it matter?
2) All IP’s are static. Again, why does it matter?
3) The local firewall in the PC should be disabled, but it seems that some user did enabled it again. That was the problem. I could solve it doing as you said.
4) PS - if you use mstsc to connect to an XP box, the user will be kicked off …
Yes, I noticed (I did local tests first), and thanks to VPN I could see that the user had left some files open unsaved that wold have been lost if I had just logged in with mstsc. And this is something I wanted to ask about: VPN has helped me to avoid data loss that I would have produced with mstsc. I see an advantage in mstsc for XP, since it does not need to be installed, but I also see the advantage in VNC in being able to see what the user is doing and so being able to provide help or, as in this case, avoid disrupting his work. So , what are the issues with VNC, security perhaps? What are exactly its security risks?
1) The IP addresses are local. There is a hardware firewall doing NAT, but I do not go through because I access via VPN, but why does it matter?
2) All IP’s are static. Again, why does it matter?
3) The local firewall in the PC should be disabled, but it seems that some user did enabled it again. That was the problem. I could solve it doing as you said.
4) PS - if you use mstsc to connect to an XP box, the user will be kicked off …
Yes, I noticed (I did local tests first), and thanks to VPN I could see that the user had left some files open unsaved that wold have been lost if I had just logged in with mstsc. And this is something I wanted to ask about: VPN has helped me to avoid data loss that I would have produced with mstsc. I see an advantage in mstsc for XP, since it does not need to be installed, but I also see the advantage in VNC in being able to see what the user is doing and so being able to provide help or, as in this case, avoid disrupting his work. So , what are the issues with VNC, security perhaps? What are exactly its security risks?
ASKER
Another inconvenient I find in mstsc is that it not only kicks out the user, but atter using it, it leaves the PC blocked in such a way that requires admin rigths, which is even worse. Is there any way to avoid this?
What do you mean by "kicks the out the user"?
That I am aware of MSTCS will not log the user off, but in some instances due to network issues it may terminate the connection. This leaves the user logged onto the remote computer, which will require that user to either logon and then log off, or require a admin to logon and logoff. Just like if you were physically at the computer.
It almost sounds like some user has obtained the password of the local admin or has obtain local admin rights and is messing with the computer settings.
That I am aware of MSTCS will not log the user off, but in some instances due to network issues it may terminate the connection. This leaves the user logged onto the remote computer, which will require that user to either logon and then log off, or require a admin to logon and logoff. Just like if you were physically at the computer.
It almost sounds like some user has obtained the password of the local admin or has obtain local admin rights and is messing with the computer settings.
ASKER
What I mean is: if a non-administrator user is working or has left a session on, when you try to mstcs in, it will log off the user to log you in. That's bad enough since you have to disturb/make aware the user every time that you are working, but what disturbs me he most is that when you are finished and you close mstcs, instead of closing the admin session it leaves the admin session on (blocking the pc).
Howeve, now that I reconsider it, this imakes sense, since you may want to leave something running. So if you want to leave the machine back to the user you have to end your session instead of just closing the mstcs window. What I would like is something like Unix (or VMS or other OS's) being able to log in and perform my tasks without disturbing/allerting anybody. To do this in Windows means, I guess, allowing this thing called "quick session switching" or whatever the name is, but I like the this solution even less than the problem.
Resuming, forget my message of 01/24/2007 - 01:36PM CET.
Howeve, now that I reconsider it, this imakes sense, since you may want to leave something running. So if you want to leave the machine back to the user you have to end your session instead of just closing the mstcs window. What I would like is something like Unix (or VMS or other OS's) being able to log in and perform my tasks without disturbing/allerting anybody. To do this in Windows means, I guess, allowing this thing called "quick session switching" or whatever the name is, but I like the this solution even less than the problem.
Resuming, forget my message of 01/24/2007 - 01:36PM CET.
Merc -
1) If you were using NAT, you would need to have your firewall configured to direct port 3389 traffic (or whatever you manually set for rdp) to the correct internal IP address.
2) The IP address being static matters only if connecting directly to the machine from the internet. If it were DHCP you would need to know what IP was leased at the time you want to connect to it. This is a big issue, but does not apply to you.
3) Nice registry trick, isn't it? Just remember to turn the firewall back on once you are remoted in and PROPERLY configure it...you can have it on and allow remote desktop exceptions to the local subnet. I would do that.
4) My experience with mstsc is that it kicks people off. Just like if they locked their workstation and walked away, then you wanted to login, you would have to supply admin level credentials and then it would kick the currently logged in user off. mstsc is not really intended to be used as a terminal server in the traditional sense.
As far as why vnc vs mstsc, it's personal preference as long as you genuinely have it setup correctly, which I recommend through a good SSH tunnel. (http://www.google.com/search?hl=en&lr=&q=secure+vnc+ssh) VNC can be considered a backdoor if not worse, an exploit vector. Not sure what I mean? Just google "vnc injection" or "vnc exploit" and include the quotes in the query. There are other VNC type solutions like tight-vnc, but I believe that only offers authentication encryption by default; not full traffic encryption. I could be wrong. Not sure about ultra. Of course mstsc has it's shortcomings as well, but at least RDP is encapsulated and 128 bit RC4 encrypted w/in TCP by default. Granted it is has the potential to fall victim to man-in-the-middle attacks b/c Microsoft used a public RSA key for a private key. Not a good idea, but any remote access method that does not use actual certificates will be vulnerable to that to some degree. TLS can mitigate this (http://support.microsoft.com/?id=895433).
I'm not going to get too much into which one is better than the other. Each has things better and worse than the other. You can research that here, but I wouldn't necessarily consider any of it expert advice:
http://www.google.com/search?hl=en&lr=&q=vnc+vs+OR+over+mstsc+OR+RDP&btnG=Search
Me, I don't use VNC b/c I don't need it. Remote access outside our network permiter is forbidden. Also, why install the tools hackers would like to have...why make their job easier for them? Let them figure out a way to install it. Also, in that sense, it is nice that RDP will kick a user off...know what I mean? You will know immediately if someone is remoting in. BTW, I don't think quick session switching will help you with that if you are on Pro. If I'm wrong, please tell me how to do it or send me a link to documentation explaining it.
In the end, the only safe computer is the one that's not plugged in...and by that, I mean to a power outlet. Anyone who has played with knoppix or reatogo/bartpe bootable CDs knows exactly what I'm talking about.
To help you with your session remaining open when you log out of mstsc, that is a glitch. To not have to worry about that, when you are done, go Start->Run and enter "shutdown -l" without the quotes. That switch is "l" as in logoff...the command forces a logoff. If that still doesn't work (it should, though), then just force a reboot: "shudown -r". Regardless, don't just click Start->Logoff.
If you don't want the user to see your name (or admin or whatever) in the logon box after you've been on, go into the registry and clear it out:
HKEY_LOCAL_MACHINE\SOFTWAR
(Change these values back to the user's username:)
DefaultUserName
AltDefaultUserName
I hope this helps!
==========================
BACK TO THE SUBJECT AT HAND...
I agree with giltjr that someone probably figured out your admin passwords, which is why I mentioned that on 1-20. I would change the password immediately and consider changing your local admin passwords on all your machines at least every 90 days.
1) If you were using NAT, you would need to have your firewall configured to direct port 3389 traffic (or whatever you manually set for rdp) to the correct internal IP address.
2) The IP address being static matters only if connecting directly to the machine from the internet. If it were DHCP you would need to know what IP was leased at the time you want to connect to it. This is a big issue, but does not apply to you.
3) Nice registry trick, isn't it? Just remember to turn the firewall back on once you are remoted in and PROPERLY configure it...you can have it on and allow remote desktop exceptions to the local subnet. I would do that.
4) My experience with mstsc is that it kicks people off. Just like if they locked their workstation and walked away, then you wanted to login, you would have to supply admin level credentials and then it would kick the currently logged in user off. mstsc is not really intended to be used as a terminal server in the traditional sense.
As far as why vnc vs mstsc, it's personal preference as long as you genuinely have it setup correctly, which I recommend through a good SSH tunnel. (http://www.google.com/search?hl=en&lr=&q=secure+vnc+ssh) VNC can be considered a backdoor if not worse, an exploit vector. Not sure what I mean? Just google "vnc injection" or "vnc exploit" and include the quotes in the query. There are other VNC type solutions like tight-vnc, but I believe that only offers authentication encryption by default; not full traffic encryption. I could be wrong. Not sure about ultra. Of course mstsc has it's shortcomings as well, but at least RDP is encapsulated and 128 bit RC4 encrypted w/in TCP by default. Granted it is has the potential to fall victim to man-in-the-middle attacks b/c Microsoft used a public RSA key for a private key. Not a good idea, but any remote access method that does not use actual certificates will be vulnerable to that to some degree. TLS can mitigate this (http://support.microsoft.com/?id=895433).
I'm not going to get too much into which one is better than the other. Each has things better and worse than the other. You can research that here, but I wouldn't necessarily consider any of it expert advice:
http://www.google.com/search?hl=en&lr=&q=vnc+vs+OR+over+mstsc+OR+RDP&btnG=Search
Me, I don't use VNC b/c I don't need it. Remote access outside our network permiter is forbidden. Also, why install the tools hackers would like to have...why make their job easier for them? Let them figure out a way to install it. Also, in that sense, it is nice that RDP will kick a user off...know what I mean? You will know immediately if someone is remoting in. BTW, I don't think quick session switching will help you with that if you are on Pro. If I'm wrong, please tell me how to do it or send me a link to documentation explaining it.
In the end, the only safe computer is the one that's not plugged in...and by that, I mean to a power outlet. Anyone who has played with knoppix or reatogo/bartpe bootable CDs knows exactly what I'm talking about.
To help you with your session remaining open when you log out of mstsc, that is a glitch. To not have to worry about that, when you are done, go Start->Run and enter "shutdown -l" without the quotes. That switch is "l" as in logoff...the command forces a logoff. If that still doesn't work (it should, though), then just force a reboot: "shudown -r". Regardless, don't just click Start->Logoff.
If you don't want the user to see your name (or admin or whatever) in the logon box after you've been on, go into the registry and clear it out:
HKEY_LOCAL_MACHINE\SOFTWAR
(Change these values back to the user's username:)
DefaultUserName
AltDefaultUserName
I hope this helps!
==========================
BACK TO THE SUBJECT AT HAND...
I agree with giltjr that someone probably figured out your admin passwords, which is why I mentioned that on 1-20. I would change the password immediately and consider changing your local admin passwords on all your machines at least every 90 days.
Also, if anyone cares I never gave up on my IE7 Run as question I challenged you all to earlier on 12-14-06. The question was abandoned, so I closed it.
https://www.experts-exchange.com/questions/22093822/Can't-gain-escalated-privileges-to-windows-explorer-by-doing-a-RUNAS-on-IE7.html#18150844
But I never gave up. Here is an excellent solution:
I found how to fix this on Aaron Margosis' weblog:
http://blogs.msdn.com/aaron_margosis/archive/2004/07/07/175488.aspx
See option 2 on this page:
Set the flag that allows explorer.exe to work with RunAs
https://www.experts-exchange.com/questions/22093822/Can't-gain-escalated-privileges-to-windows-explorer-by-doing-a-RUNAS-on-IE7.html#18150844
But I never gave up. Here is an excellent solution:
I found how to fix this on Aaron Margosis' weblog:
http://blogs.msdn.com/aaron_margosis/archive/2004/07/07/175488.aspx
See option 2 on this page:
Set the flag that allows explorer.exe to work with RunAs
ASKER
I would be very surprised that someone figured out the admin pw. These machines are not in an advanced environment. Is there any log of the admin activity?
I don’t understand giltjr's coment :
That I am aware of MSTCS will not log the user off, but in some instances due to network issues it may terminate the connection.
Unless you are talking about the remote user..., i.e me: In my comment I was talking about the guy using the machine where I am MSTCS-ing into.
Finally, since I am using VNC on a VPN connection, is that not safe enough? This should be equivalent to a VNC over SSH ins´t it?
I don’t understand giltjr's coment :
That I am aware of MSTCS will not log the user off, but in some instances due to network issues it may terminate the connection.
Unless you are talking about the remote user..., i.e me: In my comment I was talking about the guy using the machine where I am MSTCS-ing into.
Finally, since I am using VNC on a VPN connection, is that not safe enough? This should be equivalent to a VNC over SSH ins´t it?
Like I said. Nothing amazes me anymore after learning reatogo and knoppix. Furthermore, if they had admin access for even a second, it isn't hard to install a keylogger or similar activity monitor. I'm not saying that's what happened, so don't panic or anything. I'm just saying you should reset them to be on the safe side, AND get in the habbit of changing them occassionally. Be careful, though, you don't want to loose the admin password or anything since you aren't on a domain.
I believe giltjr is just saying he doesn't believe you will kick off a user by remoting in with mstsc unless there is a connectivity issue...I guess it's not my place to clarify, though.
It all depends on VPN solution you have and how well it's configured. If you think it's up to par and up to spec, then sure. Without getting into equivelancy, that should be good enough.
I believe giltjr is just saying he doesn't believe you will kick off a user by remoting in with mstsc unless there is a connectivity issue...I guess it's not my place to clarify, though.
It all depends on VPN solution you have and how well it's configured. If you think it's up to par and up to spec, then sure. Without getting into equivelancy, that should be good enough.
I think I mis-understood what you were saying. I thought that you were saying that you were remote into a PC and that something happened and remote desktop kicked you off.
I went back and re-read and I believe that what you mean is that a user was physically at the PC and logged on and you remote'ed in and it kicked the user off. If this is what you meant, then it is working as designed. MSTCS is nothing magic, it is limited to what Windows can, or can't, do. Remote desktop does the same thing as if you were physically at the PC.
If a normal user is already logged on and you logon as a admin it kicks the user off. Disconnecting a MSTCS session without logging off is just like locking the desktop when physically at the PC, so if you logon to the PC as admin and then lock the desktop, it takes a admin to get back on to the PC.
Windows, unlike other OS's UNIX, is not really a multi-user system. XP is really a "single user graphical desktop" environment. Now Windows Server with a full term serv license can act like a "multi user graphical desktop" enviroment.
Now, I have never tried this, but you might be able to add /console on the end of the command:
c:\windows\system32\mstcs /console
I have been told that this works with servers, but I am not sure about desktops. If you can do your work from a command line, you could enable the telnet server on the PC's and telnet into them.
As for logging of admin activity, if you enabled auditing for both succesful and failed logons, then the event log will have this information. If you have not enabled auditing, then there is no record of any admin activity.
As for the users not figuring out the password because they are not "in an advanced enviroment", well that may be a mistake. All it takes is one person guessing the right password because they are taking some class. Or worse yet, they find the password someplace.
I went back and re-read and I believe that what you mean is that a user was physically at the PC and logged on and you remote'ed in and it kicked the user off. If this is what you meant, then it is working as designed. MSTCS is nothing magic, it is limited to what Windows can, or can't, do. Remote desktop does the same thing as if you were physically at the PC.
If a normal user is already logged on and you logon as a admin it kicks the user off. Disconnecting a MSTCS session without logging off is just like locking the desktop when physically at the PC, so if you logon to the PC as admin and then lock the desktop, it takes a admin to get back on to the PC.
Windows, unlike other OS's UNIX, is not really a multi-user system. XP is really a "single user graphical desktop" environment. Now Windows Server with a full term serv license can act like a "multi user graphical desktop" enviroment.
Now, I have never tried this, but you might be able to add /console on the end of the command:
c:\windows\system32\mstcs /console
I have been told that this works with servers, but I am not sure about desktops. If you can do your work from a command line, you could enable the telnet server on the PC's and telnet into them.
As for logging of admin activity, if you enabled auditing for both succesful and failed logons, then the event log will have this information. If you have not enabled auditing, then there is no record of any admin activity.
As for the users not figuring out the password because they are not "in an advanced enviroment", well that may be a mistake. All it takes is one person guessing the right password because they are taking some class. Or worse yet, they find the password someplace.
ASKER
Well, all clear. And now that I have access to the machines I will be able to change the passwords and start solving the original issue of this threat.
Resuming all what has been said here about it, it looks like what I have to do is:
- change the admin pw
- delete the users
- rename their directories
- create the users again
- rename back their directories to their original names
By the way, does someone know if I could do ALL these operations from a console or I need windows for that?
I have one more caveat about the hypothetical discovery of the admin pw. Why ALL users are allowed to manage the user capabilities? It is not just one or two users who can do that, it is ALL of them. Why the trouble? It seems more like some glitch or some malware that a malintentioned action by a person, don't you think?.
Resuming all what has been said here about it, it looks like what I have to do is:
- change the admin pw
- delete the users
- rename their directories
- create the users again
- rename back their directories to their original names
By the way, does someone know if I could do ALL these operations from a console or I need windows for that?
I have one more caveat about the hypothetical discovery of the admin pw. Why ALL users are allowed to manage the user capabilities? It is not just one or two users who can do that, it is ALL of them. Why the trouble? It seems more like some glitch or some malware that a malintentioned action by a person, don't you think?.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
How many computers do you have on your network?
If all users can manage all accounts then my guess is that the users are all part of the localadmin group or they have been given group admin capabilities for the group they are in.
You should be able to do all you want from a command line, look at the "NET" command.
You should be able to do all you want from a command line, look at the "NET" command.
Umm,
--> Why ALL users are allowed to manage the user capabilities? It is not just one or two users who can do that, it is ALL of them.
You are in a workgroup enviroment, how are you getting the users' ids on multiple comptuers? Are you manually creating each user on each machine?
--> Why ALL users are allowed to manage the user capabilities? It is not just one or two users who can do that, it is ALL of them.
You are in a workgroup enviroment, how are you getting the users' ids on multiple comptuers? Are you manually creating each user on each machine?
ASKER
Quickl answers to your questions:
expexchuser:: around 20, in a factory environment
giltjr:
1) They are plain vanila users, no admin group, no special rights. How else could they have this capability? IIs ther perhaps any security setting switch that could allow a user to do that?
2) Yes, but htis is not too much work. Users do not have individual userids only tasks have userids an these are only half a dozen. And only a couple of boxes are shared among tasks, exactly those which show the problem. Everytihng seems seemli consistent to be a glitch somewhere and the whole environment has been stable (no changes) for years.
expexchuser:: around 20, in a factory environment
giltjr:
1) They are plain vanila users, no admin group, no special rights. How else could they have this capability? IIs ther perhaps any security setting switch that could allow a user to do that?
2) Yes, but htis is not too much work. Users do not have individual userids only tasks have userids an these are only half a dozen. And only a couple of boxes are shared among tasks, exactly those which show the problem. Everytihng seems seemli consistent to be a glitch somewhere and the whole environment has been stable (no changes) for years.
Would it be possible to get a Win2K3 server? You would likely not have this type of problem. Also, it would be a lot easier to administer your network. P2P is okay until you hit around 10 or 12.
I don't believe there is any "security setting switch" that would allow a restricted user the right to manage a system.
Can you clarify what you mean by users not having IDs...only tasks have them. Are you saying you have user IDs for certain computer services, or for a group of employees who perform a certain task? If those are the ones with the issues...there must be some connection. If you go into the mgmt console (start->run->mmc) and add the local users and groups snapin, then open the groups folder and open the admins group, do you see anything other than admin? What about in power users?
I don't believe there is any "security setting switch" that would allow a restricted user the right to manage a system.
Can you clarify what you mean by users not having IDs...only tasks have them. Are you saying you have user IDs for certain computer services, or for a group of employees who perform a certain task? If those are the ones with the issues...there must be some connection. If you go into the mgmt console (start->run->mmc) and add the local users and groups snapin, then open the groups folder and open the admins group, do you see anything other than admin? What about in power users?
It is possible that there is a hole so big in Windows that it allows "normal" users to have "admin like rights" and that it has gone undiscovered for years. But it is not likely.
Um, your second comment is interesting. Basically "John" does not have an ID and "Bill" does not have and ID. But "TASK1" has an id and "TASK2" has an ID. On COMP1, the id TASK1 exists, on COMP2, the id TASK2 exists, and on COMP3 "TASK1" and "TASK2" exist. Do you see the the problem here?
If John and Bill both need to do TASK1 and TASK2, then know the password for both. This means they can actually change the setting for each by just logging on.
At this point in time I would rule out a bug in Windows that allows normal users to do admin functions an d start looking at the possibility that the users are sharing passwords between the "task accounts."
Um, your second comment is interesting. Basically "John" does not have an ID and "Bill" does not have and ID. But "TASK1" has an id and "TASK2" has an ID. On COMP1, the id TASK1 exists, on COMP2, the id TASK2 exists, and on COMP3 "TASK1" and "TASK2" exist. Do you see the the problem here?
If John and Bill both need to do TASK1 and TASK2, then know the password for both. This means they can actually change the setting for each by just logging on.
At this point in time I would rule out a bug in Windows that allows normal users to do admin functions an d start looking at the possibility that the users are sharing passwords between the "task accounts."
ASKER
expex,
Sorry I do not follow, which type of problem would I avoid with a server? Are you talking about having a domain?
tasks vs users is well described by ggiltj.
giltjr,
nobody can change any settings, they have no rights at all. There is no one with any special privilege. What is the problem in having two profiles that you can use?
Sorry I do not follow, which type of problem would I avoid with a server? Are you talking about having a domain?
tasks vs users is well described by ggiltj.
giltjr,
nobody can change any settings, they have no rights at all. There is no one with any special privilege. What is the problem in having two profiles that you can use?
--> nobody can change any settings, they have no rights at all.
Um, if they are "normal" users, they can change their own settings. If you have a userid "TASK1", then when somebody is logged on as that user, they can change their own settings.
If I have the password for the user id's "TASK1" and "TASK2", I can logon as "TASK1" make changes to "TASK1"'s settings, then logoff as "TASK1" and logon as "TASK2" and change "TASK2"'s settings.
I see no problem if ONE person has access to two different userid's and ONLY that one person.
If 10 people have the password for "TASK1" then there are 10 people that can change "TASK1"'s settings. This setup has its advantages and its problems.
Um, if they are "normal" users, they can change their own settings. If you have a userid "TASK1", then when somebody is logged on as that user, they can change their own settings.
If I have the password for the user id's "TASK1" and "TASK2", I can logon as "TASK1" make changes to "TASK1"'s settings, then logoff as "TASK1" and logon as "TASK2" and change "TASK2"'s settings.
I see no problem if ONE person has access to two different userid's and ONLY that one person.
If 10 people have the password for "TASK1" then there are 10 people that can change "TASK1"'s settings. This setup has its advantages and its problems.
ASKER
Well, of course someone can change "some" settings, I still don't see how this can be of concern to anybody. Any settings that user1 could modify user2 could set back. And since users just run a couple of applications I have not noticed any changes in years, except of the extrange case that is the origin of this discussion, which is something they shoould't be allowed to do.
In this production environment the PC is not seen as a personal tool but as one more machine, used by several people at once, like any other shared tool. IfWinXP works as expected why should be this an inconvenient?
In this production environment the PC is not seen as a personal tool but as one more machine, used by several people at once, like any other shared tool. IfWinXP works as expected why should be this an inconvenient?
Still think you should try this, as deleting/recreating users/policies has absolutely NO effect on system/local/group security policy, which is where the problem could lie:
How to reset security settings back to pre-policy defaults:
http://support.microsoft.com/kb/313222
How to reset security settings back to pre-policy defaults:
http://support.microsoft.com/kb/313222
O.K. when you say that the users have "have full control of the user accounts", what exactly do you mean? What can they actually do that you feel they should not be able to do?
Do you beleive that some how when "TASK1" is logged on they can modify "TASK2" settings? If so, do you actually have proof that when logged on as "TASK1" you can modify "TASK2"?
Why is sharing userid's a concern? I don't know about your environment, but if you assign id's based on tasks instead of people, how do you know 100% for sure who did something? If "person 1" made a change you can't tell the "person 1" did it because they were not logged on "TASK1" was logged on and there are 10 people that can logon as "TASK1". This is a security issue and is strongly discourages. In fact for some environment it is not allowed at all.
Not to mention that I may be blue color blind so I need the colors setup one way and somebody else may be red color blind and need the colors setup another way. If we share the same ID, we are constantly waisting time flipping the color scheems back and forth just so we can see our work.
Do you beleive that some how when "TASK1" is logged on they can modify "TASK2" settings? If so, do you actually have proof that when logged on as "TASK1" you can modify "TASK2"?
Why is sharing userid's a concern? I don't know about your environment, but if you assign id's based on tasks instead of people, how do you know 100% for sure who did something? If "person 1" made a change you can't tell the "person 1" did it because they were not logged on "TASK1" was logged on and there are 10 people that can logon as "TASK1". This is a security issue and is strongly discourages. In fact for some environment it is not allowed at all.
Not to mention that I may be blue color blind so I need the colors setup one way and somebody else may be red color blind and need the colors setup another way. If we share the same ID, we are constantly waisting time flipping the color scheems back and forth just so we can see our work.
I agree with giltjr that you need to clarify what exactly the users can do that bothers you.
I also agree that people should not be allowed to share passwords/accounts. That is forbidden in my environment. This is the only way you can have nonrepudiation should an incident occur. In other words, if someone does something wrong / against policy, they cannot disavow whether or not it was really them. The logs will show the actual person's account at a time and date was on a certain computer doing certain things. Not one of 5 people might have been on doing this at such and such a time on such and such a date. Not to mention it could be none of the 5 since the password is shared and may have been leaked.
You should invest in a 2k3 server and setup a domain where everyone has their own user credentials. You can then setup groups on the computer to and join the users to those groups so that only those users are allowed to use the apps and make changes that they need. This will also help with group policy management and address giltjr's point about accessibility for handicapped (or whatever ... you know what I mean) getting their own settings and profiles. It will also help you with user acct and password management. Plus with WSUS you can push out Windows, Office, SQL, etc patches easily. It would be well worth the investement.
I also agree that people should not be allowed to share passwords/accounts. That is forbidden in my environment. This is the only way you can have nonrepudiation should an incident occur. In other words, if someone does something wrong / against policy, they cannot disavow whether or not it was really them. The logs will show the actual person's account at a time and date was on a certain computer doing certain things. Not one of 5 people might have been on doing this at such and such a time on such and such a date. Not to mention it could be none of the 5 since the password is shared and may have been leaked.
You should invest in a 2k3 server and setup a domain where everyone has their own user credentials. You can then setup groups on the computer to and join the users to those groups so that only those users are allowed to use the apps and make changes that they need. This will also help with group policy management and address giltjr's point about accessibility for handicapped (or whatever ... you know what I mean) getting their own settings and profiles. It will also help you with user acct and password management. Plus with WSUS you can push out Windows, Office, SQL, etc patches easily. It would be well worth the investement.
If you aren't comfortable with setting up a server and domain, you can easily outsource the install to a 3rd party technology service provider (not geek squad, though) for a reaonable price. They will also help you plan what's best and setup the PCs to be secure and properly configured for your apps etc. Then you can just manage it which is very simple and it sounds like you have those skills. That's the difference between an network engineer and a network administrator and it doesn't sound like you have a big enough shop to need a network engineer. So outsouce it as needed.
ASKER
Thanks you all for your comments.
Tim, your suggestion is more in line with that I thing the solution to my problem is. I will test that option if the changes proposed before don’t solve the problem. I am looking for a window of opportunity (not that easy) to be able to work on the machines and test the proposed alternatives.
Giltjr,
a) by full control of the user accounts I mean: ability to create new users, to change the level or pw’s of the existing ones, to delete existing users, … Once again, I have not seen any other “administrator level” capability in these users.
b) task1 user can modify the *user account* of task2, but no more. For example, cannot open his private files or directories.
c) you must accept that not all users in the world are MS Office users. These users use the PC as a terminal to another application with its own security (again, also based on tasks and not on users). It you consider that these are not PC’s but dumb terminals (sort of 3270 or VT100 like), then the WinXP pw would be the equivalent to the power switch. This is in fact a total overkill for what is required. Having a pw per task is already a luxury. I could have them WITHOUT any pw and nothing would change. You could ask me now, well then why do you care? I care about this problem because it is surprising and it shocked me to discover it.
d) Color preferences? we did not have this problem so far, and if we had it it would be a shame because the real application has no skins, color options or none of this fancy stuff.
Expex,
a) I hope the previous explanation answers your concerns.
b) No ofense, but when I think I need a domain I will build one, although I am not an MS domain expert, I think I could manage. In fact I may have to do it in another network. I count with your help. For the moment my policy in this particular instance is to use as little MS stuff as possible and solving MS glitches with even more MS stuff does not seem appropriate.
Tim, your suggestion is more in line with that I thing the solution to my problem is. I will test that option if the changes proposed before don’t solve the problem. I am looking for a window of opportunity (not that easy) to be able to work on the machines and test the proposed alternatives.
Giltjr,
a) by full control of the user accounts I mean: ability to create new users, to change the level or pw’s of the existing ones, to delete existing users, … Once again, I have not seen any other “administrator level” capability in these users.
b) task1 user can modify the *user account* of task2, but no more. For example, cannot open his private files or directories.
c) you must accept that not all users in the world are MS Office users. These users use the PC as a terminal to another application with its own security (again, also based on tasks and not on users). It you consider that these are not PC’s but dumb terminals (sort of 3270 or VT100 like), then the WinXP pw would be the equivalent to the power switch. This is in fact a total overkill for what is required. Having a pw per task is already a luxury. I could have them WITHOUT any pw and nothing would change. You could ask me now, well then why do you care? I care about this problem because it is surprising and it shocked me to discover it.
d) Color preferences? we did not have this problem so far, and if we had it it would be a shame because the real application has no skins, color options or none of this fancy stuff.
Expex,
a) I hope the previous explanation answers your concerns.
b) No ofense, but when I think I need a domain I will build one, although I am not an MS domain expert, I think I could manage. In fact I may have to do it in another network. I count with your help. For the moment my policy in this particular instance is to use as little MS stuff as possible and solving MS glitches with even more MS stuff does not seem appropriate.
No offense taken and I certainly didn't mean to offend anyone either. It's obviously you're call and maybe it would be overkill at this point since all the apps are terminal based. We'll be here for you when you are ready to cross that bridge. You wouldn't have the problems you are concerned about if you implemented a domain, though. I would also add that sometimes it takes a little more "MS stuff" to make your existing "MS stuff" work better and more efficient.
Is sounds like they have been added to the Power Users Group.
The color changing was just one example of the issues that could occur sharing ids. Yes, I realize that there are enviroments that do things other than PC based functions, in fact the enviroment I work in the PC's are mainly used as dumb 3270 terminals. However, we have had people record automatic logon scripts for the 3270 sessions and if you share userids on Windows, then you now have a situation where they are sharing 3270 ids.
I am sure there are some enviroments where sharing ID's is O.K., it just I have yet to work in one and your's may be one where sharing is O.K. Its based on your requirments.
I would suggest that you look at local security settings, specifically User Rights Assignments.
The color changing was just one example of the issues that could occur sharing ids. Yes, I realize that there are enviroments that do things other than PC based functions, in fact the enviroment I work in the PC's are mainly used as dumb 3270 terminals. However, we have had people record automatic logon scripts for the 3270 sessions and if you share userids on Windows, then you now have a situation where they are sharing 3270 ids.
I am sure there are some enviroments where sharing ID's is O.K., it just I have yet to work in one and your's may be one where sharing is O.K. Its based on your requirments.
I would suggest that you look at local security settings, specifically User Rights Assignments.
You may want to issue the command:
net localgroup "Power Users"
and see if by chance they got moved to the "Power Users" group. I know that we just distributed a new 3270 emulation program that required users to be "Power Users" to install the program. We had a few customers that had to change their users privileges from "Users" to "Power Users", or have their desktop groups do the install.
net localgroup "Power Users"
and see if by chance they got moved to the "Power Users" group. I know that we just distributed a new 3270 emulation program that required users to be "Power Users" to install the program. We had a few customers that had to change their users privileges from "Users" to "Power Users", or have their desktop groups do the install.
ASKER
OK here are finally the two hijack files requested by rpggamergirl, expexchuser and others weeks ago.
https://filedb.experts-exchange.com/incoming/ee-stuff/2302-hijackthis2.zip
Looking forward to your comments.
https://filedb.experts-exchange.com/incoming/ee-stuff/2302-hijackthis2.zip
Looking forward to your comments.
ASKER
Problem partially solved, but now I have side-effect PROBLEM due to the change of user!!!
expexchuser,
I followed the plan ion 01/25/2007 12:14AM CET and I got in trouble:
Renaming and seting back the names of the user profile is not working cleanly. The newly created user cannot start MS outlook.
Since I did all these changes as administrator, I thought that perhaps some files got the administratos as owner. And this helped indeed, I could find out that this is true for some files.
So, first I gave full control to the user in question to the whole directory (its own user profile directory) but it was not enough. I also had to give administrator rights to this user in order to get its Outlook starting.
With both these changes I gan get Outlook to work as before, but of course is not a satisfactory solution. Granting administrator rights is ever a worse situation than the original problem.
Which oother files needs the user to have acces besides those in the user provile?
Are there any other files somewhere else that need to be owned by the user?
expexchuser,
I followed the plan ion 01/25/2007 12:14AM CET and I got in trouble:
Renaming and seting back the names of the user profile is not working cleanly. The newly created user cannot start MS outlook.
Since I did all these changes as administrator, I thought that perhaps some files got the administratos as owner. And this helped indeed, I could find out that this is true for some files.
So, first I gave full control to the user in question to the whole directory (its own user profile directory) but it was not enough. I also had to give administrator rights to this user in order to get its Outlook starting.
With both these changes I gan get Outlook to work as before, but of course is not a satisfactory solution. Granting administrator rights is ever a worse situation than the original problem.
Which oother files needs the user to have acces besides those in the user provile?
Are there any other files somewhere else that need to be owned by the user?
ASKER
Hi there, anybody?
I have placed the two hijack files, as requested, and explained that the renaming of user profiles does not seem to work in the case of outlook.
Any feedback?
I have placed the two hijack files, as requested, and explained that the renaming of user profiles does not seem to work in the case of outlook.
Any feedback?
Have you issued the command:
net localgroup "Power Users"
I have look at logs and I did not see anything that jumped out at me.
net localgroup "Power Users"
I have look at logs and I did not see anything that jumped out at me.
ASKER
There a no "power users", the list comes up empty.
Well, if nothing can be found from hijack, since the problem is now partly solved following expexchuser's plan of 01/25/2007 12:14AM, my last dificulty now (and with this the case is closed) is to do this right. As I said, the mentioned 7-step plan does not work for Outlook: the setings are lost, the db files are not accepted, etc, i.e. one has to redefine the whole thing from scratch by hand. This is fine just for 1 user, but each machine has 7 users and it is realy a pain having to repeat the whole settings 14 times.
Well, if nothing can be found from hijack, since the problem is now partly solved following expexchuser's plan of 01/25/2007 12:14AM, my last dificulty now (and with this the case is closed) is to do this right. As I said, the mentioned 7-step plan does not work for Outlook: the setings are lost, the db files are not accepted, etc, i.e. one has to redefine the whole thing from scratch by hand. This is fine just for 1 user, but each machine has 7 users and it is realy a pain having to repeat the whole settings 14 times.
Hey, you may want to look at
http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c17621675.mspx
Just do a search on whoami and read up on it. This is a utility that you can install from the XP OS CD and if you enter the command "whoami /all" it will show you a lot of the security related information for the ID that is current logged on.
http://www.microsoft.com/technet/prodtechnol/winxppro/reskit/c17621675.mspx
Just do a search on whoami and read up on it. This is a utility that you can install from the XP OS CD and if you enter the command "whoami /all" it will show you a lot of the security related information for the ID that is current logged on.
One other, wild off the wall, thing to check is when logged on as the local admin, look at the security properites for the NTUSER.DAT file for each of the "normal" users and see if there is anything unusual with those file. Only Administrator and SYSTEM should have ANY access to it.
From the security tab on that file you can also select Advanced, bottom right, then click on the effective permissions and put in one of the other userid's and see what the effective permissions are.
So you look at USER1 ntuser.dat file and then put USER2's id in to see what permissions they have.
I will admit this is a bit off the wall. But this whole situation seems to be a bit off the wall.
From the security tab on that file you can also select Advanced, bottom right, then click on the effective permissions and put in one of the other userid's and see what the effective permissions are.
So you look at USER1 ntuser.dat file and then put USER2's id in to see what permissions they have.
I will admit this is a bit off the wall. But this whole situation seems to be a bit off the wall.
ASKER
I will close the issue and give the points to expexchuser for all his help, not onlyin resolving the main question, but also with the remote access.
Although the accepted solution solves the main problem, however, it does not fully work. The re-creation of users does not work as presented. I will post another question with this problem..
Although the accepted solution solves the main problem, however, it does not fully work. The re-creation of users does not work as presented. I will post another question with this problem..
information about account is ther
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ua_c_account_types.mspx?mfr=true