Blog Archives
Using RUNAS to launch Explorer as less-privileged user
As you probably know, runas.exe is a great tool for lowering the privileges under which some “unsafe” programs can run. One such example might be Firefox (or God forbid, Internet Explorer) or your favorite e-mail client, or perhaps Explorer itself. Well, explorer.exe is special in this case, because out of the box it doesn’t run with runas. I really never cared to find out why. Tonight was the night :-)
I entered the following magic keywords in Google search box: “Why can’t you run Explorer with runas” and few seconds later clicked on the very first hit Runas with Explorer that explains the topic quite well.
I prefer second suggested solution. Let’s say, that you have a special local user with minimal privileges, called Internet and that you would want to use that account for every (potentially) unsafe operation, including launching Explorer that’ll be used to run other programs and files.
You’ll have to change SeparateProcess flag for Explorer for the Internet user:
1) Log on locally as Internet user and open the registry editor – regedt32
Better yet, use runas:
cmd> runas /user:hostname\Internet regedt32
…where hostname is the name of your workstation.
2) Navigate to HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced and change SeparateProcess from 0 to 1.
3) Now, you can create shortcut on your desktop to launch Explorer as Internet user:
Target: runas /user:hostname\Internet explorer.exe
Regards,
Ales
Windows 2003 Standard Edition and /3GB switch
I was spending my day installing 32-bit Windows 2003 Standard Edition on one of our home build server with 4GB of RAM. Even thought the server could run x64 version of the operating system, I decided to install 32-bit Windows 2003 Standard Edition (the reason is out of the scope of today topic).
I know, that in the Windows 2000 time frame, only Advanced Server and Datacenter Server could really support 3GB user virtual memory space. Even thought, you could turn on /3GB switch on Windows 2000 Server and/or Windows 2000 Professional, the user virtual memory space is still limited to 2GB. Microsoft allowed this to help device driver developers – they could write and test the code without the need for Advanced Server.
The question that I asked myself was simple – is it possible to turn on /3GB switch on Windows 2003 Standard Edition? The answer is yes, but…According to Microsoft KB article “291988 A description of the 4 GB RAM Tuning feature and the Physical Address Extension switch” the /3GB switch in Windows 2003 Standard Edition is supported in production only for servers running Active Directory (DC). In all other cases, /3GB switch on W2K3 Standard Edition is not really supported by Microsoft; if application vendor is willing to take the risk – fine, otherwise you’re on your own.
I decided not use use /3GB switch – I’m not willing to take a chance, besides, the system will serve batch processing with little impact on system memory (up to 500MB) and the rest (up to 2GB) will be more than enough to run non-production Oracle XE instance.
On the bright side, I found some really good material on /3GB switch, searching the forum.sysinternals.com, I found excellent articles posted by Raymond Chen, a long time Microsoft employee and the author of the book “The Old New Thing: Practical Development Throughout the Evolution of Windows”.
Since /3GB switch (Virtual Memory in general) is so often miss understood, I’m sure you’ll enjoy reading short articles published by Raymond Chen on his blog:
http://blogs.msdn.com/oldnewthing/archive/2004/08/22/218527.aspx
ArcServe – how to reset forgotten caroot password
Another “lost” sticky note that I needed today :)
1) stop the ArcServe services with cstop utility:
cd C:\Program Files\CA\BrightStor ARCserve Backup
cmd> cstop
2) Find and rename directory with the SERVER NAME under directory named Discovery:
Rename directory:
?:\Program Files\CA\BrightStor ARCserve Backup\Data\discovery\SERVERNAME
to something like:
?:\Program Files\CA\BrightStor ARCserve Backup\Data\discovery\SERVERNAME.BAK
3) Start ArcServe services with cstart
4) Change caroot password:
cmd> authsetup /p newpwdforcaroot
That's it. From now on use the new password to authenticate as caroot.
ArcServe – ca_auth
I have always a problem remembering the proper steps needed to authorize DBA’s to execute backup jobs with CABATCH utility in ArcServe.
For example, assume the following setup:
BACKUPSERVER ... is the server with ArcServe running
DBAWORKSTATION ... is workstation from which DBA can execute remote backup job with <em>cabatch</em> utility
DBAUSER ... is Windows OS domain account for DBA.
The DBAUSER while logged on DBAWORKSTATION should be allowed to open command line, run cabatch utility and send the backup job to remote BACKUPSERVER.
The procedure to authorize DBAUSER to execute cabatch:
1) Log on BACKUPSERVER as Administrator (assuming this account was used during ArcServe installment)
2) Add ArcServe <em>internal</em> user named dbauser (I prefer the same name as it's used on windows domain for DBA)
cmd> ca_auth -user add dbauser password
Remember, both username and password is internal, ArcServe stuff, and has nothing to do with OS account!
You can list existing ArcServe users with:
cmd> ca_auth -user getall
3) Make account the equivalent to caroot
cmd> ca_auth -equiv add dbauser dbaworkstation dbauser caroot carootpassword
Here is explantion of positional parameters used above:
cmd> ca_auth -equiv add
Usage :
ca_auth [-cahost host] -equiv add ntuser hostName BrightStorUser [caroot_username] [caroot_password]
ca_auth [-cahost host] -equiv getequiv [ntuser hostName]
ca_auth [-cahost host] -equiv delete ntuser hostName [caroot_username] [caroot_password]
ca_auth -equiv whoami
I hope this note will spare me some time in the future :)
dbaportal.eu 