Could the share be restricted some other way? Hey trying to hand you a straw that might become a rope.
Jon On Thu, May 13, 2010 at 7:53 PM, Peter van Houten <[email protected]>wrote: > It is really odd the way it properly parses the login credentials but > won't accept the same credentials when one tries to map to a share, > remote regedit, computer management, etc (all rejected "access denied") > > -- > Peter van Houten > > On the 14 May, 2010 01:43, Jon Harris wrote the following: > >> Sorry was not paying attention to that. It sounds like it is time to >> get a ticket and pack a bag unless he has someone closer that could go >> do the work. >> Jon >> >> On Thu, May 13, 2010 at 7:41 PM, James Hill >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> He covered that one. >> >> What can't be done / makes no difference: >> >> 4) Map drives to *any* shares from another box >> >> *From:* Jon Harris [mailto:[email protected] >> >> <mailto:[email protected]>] >> *Sent:* Friday, 14 May 2010 9:40 AM >> >> *To:* NT System Admin Issues >> *Subject:* Re: XP Box inaccessible >> >> What about just mapping the drive's admin share and pulling what you >> need? >> >> Jon >> >> On Thu, May 13, 2010 at 7:34 PM, Peter van Houten >> <[email protected] <mailto:[email protected]>> wrote: >> >> Well ironically, it is far from "hung" but I know what you mean. There >> are a number of bugs that have this effect; the less elaborate just >> overwrite files such as userinit.exe with their own code, make a few >> reg >> changes and cause the login problem. >> >> Type in the login and password, off it goes..."loading your personal >> settings"...but then instead of going to the desktop, it simply logs >> off. >> >> So the computer is "running" and one can observe certain >> processes remotely as I pointed out. One just can't get any %$#&@(&$! >> work done! >> >> -- >> Peter van Houten >> >> On the 14 May, 2010 01:21, Jon Harris wrote the following: >> >> So what you have is a hung box some where between logon and logoff? >> Jon >> >> On Thu, May 13, 2010 at 7:09 PM, Peter van Houten >> <[email protected] <mailto:[email protected]> >> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> Thanks Jon; I probably didn't lay out my explanation properly >> but I do >> have remote access; it simply goes through the same login-logoff >> routine >> as a local login. >> >> -- >> Peter van Houten >> >> On the 14 May, 2010 00:58, Jon Harris wrote the following: >> >> Isn't there a GPO that would turn on remote access for Domain >> Admins? >> If it is part of a domain and you have access to the Domain >> Controller >> then just have it restarted once or twice and you should be >> good >> to go. >> Jon >> >> On Thu, May 13, 2010 at 6:26 PM, Peter van Houten >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> wrote: >> >> I have a XP Pro [fully patched :-) ] box on a network that >> has been >> infected (probably Virut). It is the classic >> login...loading >> your >> personal settings...logging off scenario. >> >> Recovering the data and fixing the malware problem is easy. >> The real >> problem is that the box is 300 miles away, so I am trying >> to >> avoid >> flying there tomorrow, just before the weekend. >> >> What can't be done / makes no difference: >> ----------------------------------------------------------- >> 1) Login locally (admin credentials make no difference) >> 2) Login remotely using RDP or VNC, directly via VPN or via >> another box >> on the remote network (goes through the motions as above). >> 2) Start in any form of safe mode. >> 3) Restore to earlier date, last known good config. >> 4) Map drives to *any* shares from another box >> 5) Use any clever login scripts on the server >> 6) Use psexec to run anything remotely. >> 7) Instruct the user to step through anything technical :-( >> >> What can be done: >> -------------------------- >> 1) Ping the box >> 2) Netbios is enabled, so it shows in network >> 3) Scan the IP and show ports 139 and 445 open >> 4) Open and close a null RPC connection (enum, etc not >> helping) >> >> My hope is that one of you boffins has a script that will, >> via RPC turn >> on the telnet server, open port 23 and let me copy a >> document from the >> desktop [aarrgh] to USB. Or something equally as clever... >> >> TIA but please no advice on malware, >> >> -- >> Peter van Houten >> > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
