Posted by Shawn Anderson on Fri, Jan 29, 2010
Photo by Rennett Stowe
Windows administrators are often bearers of news. Sometimes good, sometimes bad.
When the news is good, you look like a hero. When it's bad you offer suggestions on how to a) deal with repurcussions, and b) avoid the problem next time. While no one likes to give bad news there is something worse... not knowing.
When it comes to knowing what software is installed on the computers that you manage there are myriad ways to discover. Here are the 7 reasons a windows administrator might not know what is installed on their systems:
- Limiting inventory collection to entries in Add/Remove Programs
- Excluding important registry entries
- Giving them what they 'ask for'
- Limiting inventory scans to .exe files
- No master baseline table to compare against
- Data is static
- Poor reporting ability
Number 1 is quite common. Software inventory is much more than what is listed in Add/Remove. While true that most of what you'll need to report on will be gleaned from this section, sometimes the data you need isn't a stand-alone program per se, but rather a file or group of files that together may cause a vulnerability.
The solution is to determine what you are looking for and then find the right solutions, be they over the counter or custom scanning ability. Keep reading to see some common mistakes made by admins on the quest for too much information.
Number 2 isn't answered easily. The registry is a big place and it's easy to get lost. You need to know what you're looking for before you create a custom scanner to glean registry data. That said, sometimes the registry is the only place to get the data, especially when you are looking for the configuration of specific applications.
Number 3 is a fun one. We all know that what a customer asks for isn't necesarily what they want. I'll elaborate a bit more in the end of the artcile, but suffice it to say that gathering every piece of information on the computer won't help much if you can't put it into their perspective.
Number 4 is a common mistake made when an admin tries to venture beyond Add/Remove. Simply put, they scan for all .exe's while forgetting that there are many files that are executable.
Keep an eye out for some of the following (certainly not an exhaustive list):
The next mistake is looking for too much, which takes us to number 5, which I will cover in next Friday's blog post.
Posted by The Admin Arsenal Team on Wed, Jan 27, 2010
Generally I despise information security measures that are so strict the computer users basically have to resort to using old Selectric typewriters to any work done.
Password enforcement is one area where I roll my eyes a lot. A good, reasonable, password strength policy is appropriate, no question. However, the stricter the policy the greater the probability that the respective computer users will end up writing their hard-to-remember passwords on a sticky note stored under their keyboard and then, of course, the security is worse than allowing certain patterns or longer modified words.
Then I read this article posted on ZDNet.
http://blogs.zdnet.com/security/?p=5325&tag=wrapper;col1
From the article:
Key findings include:
- In just 110 attempts, a hacker will typically gain access to one new account on every second or a mere 17 minutes to break into 1000 accounts
- About 30% of users chose passwords whose length is equal or below six characters
- Moreover, almost 60% of users chose their passwords from a limited set of alpha-numeric characters
- Nearly 50% of users used names, slang words, dictionary words or trivial passwords (consecutive digits, adjacent keyboard keys, and so on). The most common password among Rockyou.com account owners is “123456”.
One thing I definitely recommend is forcing passwords to be longer than 8 characters. Even HomerSimpson changed to H0m3&s!mP$i is a great password and one that a user who prefers typing HomerSimpson can more easily remember.
If you or someone you know creates password policies so strict I would consider taking a stroll through your users' offices and cubicles and looking under keyboards. I'd also consider easing up on your password policies if you find passwords written down.
Of course I'm not telling you anything you don't already know.
Posted by The Admin Arsenal Team on Mon, Jan 25, 2010
Photo by Tim Morgan
I was recently bitten by a PowerShell quirk that took me quite a while to find. It has to do with how PowerShell deals with the current directory when making .NET function calls. I created a script to make changes to an XML file that looked similar to this:
cd c:\some-directory
$xml = [xml](get-content "file.xml")
$xml.Parent.Node.Id = [system.guid]::newguid().tostring()
echo $xml.Save("file.xml")
When I ran the script, the file didn't change. I couldn't for the life of me figure out why. This was the first time I was working the XML libraries in PowerShell and I was certain it must be due to how I was using the library. Finally, after about a half hour of searching I discovered that the change file was being saved to the original directory, not to the directory I had changed to. It turns out that when you change directories in PowerShell, you don't change the current directory in the environment and so the .NET libraries think you're still in the original directory. Since I read the file using PowerShell with get-content and saved using the .NET XML library, I was properly reading the file, but saving it in the wrong place.
This quirk is apparently deliberate, having something to do with enhancements in a future version of PowerShell which will allow suspending of jobs in the background. I'm not sure that this is the best way to deal with that eventuality, but there you go.
There are two ways around this problem. The first, and simplest is to use the resolve-path cmdlet:
echo $xml.Save(resolve-path "file.xml")
This will ensure that the full path to the file will be sent to the .NET class, ensuring that the file is saved in the correct location.
The second option, which may be preferable in some situations, is to change the directory using the .NET Directory class:
[IO.Directory]::SetCurrentDirectory("c:\foo")
This will change the current directory in the environment. It's probably safer to use resolve-path, but it will not be sufficient if a .NET class must work on the current directory and you can't pass in another path.
Posted by The Admin Arsenal Team on Fri, Jan 22, 2010
Author: Shane Corellian
What 3 words define the home theatre system of the 1980's?
Listening to the TWiT episode 231 (titled Be Kind, Rewind) I heard that Microsoft is now offering "rented" copies of Windows and Office.
Extracted from Mary-Jo Foley's ZDNet article.
"The new rental option “could give a boost to Internet cafes, companies renting rather than buying computers, etc.,” DeGroot said. “It also could be good for seasonal businesses who could rent additional PCs for a short time, then send them back.
To attract interest in the new rental program, Microsoft is offering a promotion (through the end of June 2010), via which a rental version of Office Professional is available for $58 (regularly $83 via volume discount pricing). Office Standard (rental) is available for $45 per copy (as opposed to $64 per copy regularly.) Windows is available for $23 per copy (as opposed to $32 per copy), DeGroot noted."
At least these rentals won't have the problem that plagued rented VHS copies of Basic Instinct where one particular scene had been paused so much and so often it was, well, unwatchable. (or so I, ahem, hear).
Posted by The Admin Arsenal Team on Wed, Jan 20, 2010
Author: Adam Ruth
At last year's
Business of Software conference I received a copy of a book called
Coders at Work. It was fortuitous because I was planning on buying a copy of it anyway. It's a collection of interviews with some of the world's most influential programmers, modeled on
Founders at Work (which is also a good read.) It's a really interesting book for anyone who has ever done, or who wants to start, programming.
Each of the interviewees have different takes on things such as debugging, reading code, designing new software, and the philosophies of different programming languages. I found myself at times in strong agreement with their answers, sometimes disagreeing, but most of the time humbled by their accomplishments and clarity of thought. These individuals have been amazingly influential on the current landscape of programming, and none of them is satisfied that programming has really achieved its potential. From the original implementer of SmallTalk (Dan Ingalls) to the Chief Java Architect at Google (Joshua Bloch) you will find something fascinating from getting into each of their minds.
Of particular interest is what books they each recommend that programmers should have in their collection. I've read many, but not all, of them so I can see I've got some reading ahead me! Also, since I'm a bit of a programming language geek, I liked the interviews that talked about the genesis of a new language. I find that learning the philosophies of any language can only make you better in every other language (usually… Perl may be an exception :-)) I think this holds true for things in the system administration realm as well (e.g. learning something about OpenLDAP can only help in administering Active Directory.)
It's a pretty light and quick read, even though it weighs in at 601 pages. Its format is something that you can put down and pick up days later for a few minutes of reading without getting lost, which is pretty much how I got through it. If you've got a small gap in your reading list, I can recommend this book to fill it.
Posted by Shawn Anderson on Mon, Jan 18, 2010
The US Department of Defense (DoD) is being advised to take a long hard look at Google Apps Premier edition.
As I wrote about using Google Apps for the company last October, the topic has been on my mind - which explains why this article jumped out at me.
I've done quite a bit of consulting with the DoD. Some of their policies, like any other organization, don't seem to make much sense. Other policies however, are cutting edge (Federal Desktop Core Configuration, for example).
This past week China and Google have been having some fairly heated discussions, some of which have been released publicly, no doubt to up the ante to the other side. Google in short is thinking of pulling out of China, including their server farms. That brings us to the heart of the China/Google problem.
Paul Strassmann wrote a guest post for Larry Dignan column on ZDNet titled "Government Gmail use following Google's China news". The crux of Mr. Strassmann's position is that all Google servers should be removed from China because it must be assumed that the Chinese government has access to the server farms. He was specifically discussing gmail servers, and Google released a statement stating that Google has no gmail servers in China.
While the back-and-forth is certainly entertaining, it begs the question; can the DoD, and for that matter any organization, really trust a cloud in which they do not have full control.
This poses problems not only for the DoD, some of whose smaller organizations actually use Google Apps Premier, but for their contractors, sub-contractors, and vendors. A number of companies use Google Apps Premier for their internal email solutions. If these companies have dealings with the DoD they may find themselves at odds with new policies, should the DoD find cause to ban Google Apps from inside its network and with any vendors it deals with.
Keep an eye on this, Windows administrators. When it comes to the DoD and security, especially during times of war, they prefer to err on the side of security.
What do you think? Cutting edge or paranoid?
Posted by Shawn Anderson on Fri, Jan 15, 2010
The world is a-twitter about Adobe's decsion to bundle the current 8.3 and 9.3 patch into its already scheduled January 12 update. Now that the patch is out, some admins are scratching their heads on getting it rapidly deployed.
We already have a step-by-step process on deploying Adobe, and the patch is much easier. We have a video that demonstrates the ease of getting it pushed out to one, some, or all of your systems.
To make things easier Adobe has released the patch under the 9.3 (or 8.3) versioning, so using Admin Arsenal inventory to show a collection of all systems that have Adobe installed but are not at the correct version is a snap. You can push the package to the entire collection and move on to other tasks.
Download the Admin Arsenal collection .xml for export.
Posted by Shawn Anderson on Wed, Jan 13, 2010
Google has announced that their document collaboration tool (no, not Wave) will receive an upgrade. Google Docs is about to receive (and none too soon) the ability to upload files.
This honor has been limited to specific file types, usually office documents and .pdf's. As a Google Apps Premier user I've been one of those waiting for this announcement.
Google Docs users will get 1GB of storage space, with up to 250 MB per file. Additional space is available for purchase.
Google Apps Premier customers will not (at least it hasn't been announced) be receiving additional space, but rather the ability to use 3rd party apps for desktop syncing.
I'm a little surprised that the Premier customers aren't starting off with a larger bowl, but all in good time I suppose.
Here's a good take on Google's announcement from Ars Technica.
Posted by The Admin Arsenal Team on Mon, Jan 11, 2010
Photo by Brad & Ying
Author: Adam Ruth
Our goal at Admin Arsenal is about helping administrators work remotely by getting them to unplug their sneakernets. System security can sometimes make it difficult to achieve this goal. It would be great to live in a world without the need for security, not least because of its delicious gumdrop houses, use of sparkling rainbow wishes for currency, and ruler Princess Yum-yum-tum-tum of the Rose Scented Flatus. Unfortunately, we don't live in that world (which is a shame because the dollar to rainbow wish exchange rate is at its highest ever.)
Like most things in life there is a trade-off between the security of assets and their availability for use (or administration, as the case may be.) We've found that security issues tend to be the biggest roadblocks in achieving remote administration nirvana. So in that vein, I present the 5 biggest security roadblocks that we encounter regularly.
Firewall
This one should be obvious. If a computer doesn't allow inbound connections to its remote administration facilities, then it's not going to work. With the advent of the Firewall in Windows XP more and more people are seeing their remote administration break. It's been a while since the Windows Firewall entered the scene so this problem, and its cure, are quite well known now. The simplest fix (short of disabling the firewall) is to enable the
remote administration firewall exception, the file sharing exception (for remote access to the file system) and the ICMP echo exception (for ping.)
DCOM Security
WMI (Windows Management Instrumentation) is one of the primary methods of remotely administering computers. It uses DCOM (Distributed Component Object Model) as its method of communication. If the rights for DCOM aren't properly set, then WMI isn't going to work correctly, if at all. WMI, for all its power, seems to be quite fragile or brittle. One of the reasons behind this is its reliance on DCOM which seems to be the target of well meaning but misguided security experts and tools. We see this problem so often that we created a tool called DCOMAcls which allows for the remote setting of DCOM security settings.
System Time
Windows security has trouble coping with computers with clocks that are out of sync. This is actually for a good reason, since security tokens use timestamps and expirations to prevent their misuse. Depending on the settings of your authentication scheme (such as Active Directory's implementation of Kerberos) a clock that is out of sync by only a few minutes can cause connectivity problems. Usually, though, it takes clocks off by a few hours (such as reversing AM/PM or being on the wrong day.) Troubleshooting this problem can be difficult because the connectivity issues don't usually indicate that it's a time sync problem.
DNS/DHCP
WMI's authentication validates the host name being used to access the computer (unless a raw IP address is used.) If there are DNS or DHCP problems causing the wrong computer name to be used for connection, WMI will quite often fail. Windows DNS is notorious for stale records and it takes some effort and planning to ensure that a good DHCP setup prevents the same addresses being reused often. Then throw NetBIOS into the mix and once your name resolution is compromised then all bets are off.
The Double-Hop Problem
This problem only affects a certain type of remote administration, so while it's not generally encountered by most administrators, those who use this type of administration will almost always run into it. The
double-hop problem is, to put it simply, the inability for a security token to hop twice between machines. If you connect from computer A to computer B to execute a task (such as start a remote software install) and that task needs files on computer C then the security token can't hop again from B to C and access to those files will be denied. There are three solutions to this problem, the first is to configure a level of trust called "delegation" between computers, but this requires some high-level settings in Active Directory and is usually discouraged. The second solution is to send a user name and password from computer A to computer B so that a new token can be created to hop between B and C, but this is also problematic because it involves sending a password over the wire (possibly encrypted, but out in the open) and there aren't any native Windows tools that work that way. The third solution is to figure out a way to not need files on computer C, but this may not always be possible. So, while you may never run into this problem, when you do it can be a bear to deal with.
Hopefully this list will help any of you having security problems in your remote administration daily lives. Personally, I've filled out the immigration paperwork for the the land of gumdrop houses...
Posted by The Admin Arsenal Team on Fri, Jan 08, 2010
In this article we will create a Custom Inventory Report inside of Admin Arsenal. This report will show all computers that do NOT have Symantec Antivirus service installed / configured.
From the main window in Admin Arsenal select "New Report..." item in the Reports menu.
Now we write our query. I used the Fields dropdown menu to select the appropriate Table / Field.
This query simply requests that the Computer Name, AD Description, OS Name and Last Inventory Scan Date be returned for every computer that does NOT have a Windows Service called Symantec Antivirus.
Click here to download the video if you cannot access the YouTube version above
Posted by Shawn Anderson on Wed, Jan 06, 2010
A recent slashdot article on IT Administrator abuse might more appropriately be titled IT Administrator Biases. It brings up an excellent point which highlights the known fact that, generally speaking, IT departments are horrible at eating their own dogfood.
The example in the article points to the blocking of forums or discussion groups, but leaving wide open the access for Digg, Fark, and Slashdot.
My experience points to management deference. They either don't understand or don't want to understand the nuances of IT life. They will often accept point blank what their IT guys say. In a way this is beneficial. Afterall, most companies don't make money from their IT departments.
While it could generate bad will among the rank and file within a company I think little is likely to change.
It goes much deeper than website blocking. IT admins will commonly install software on their systems that has not passed internal security checks or is not documented or even (gasp) licensed.
I recall running a software inventory scan for a client only to find several sys admins who had sniffer applications installed. To say that 'it' hit the fan would be an understatement.
All in all it will build a stronger environment if the IT department eats the same dogfood, but then again, how would we get anything done if that were the case?
Posted by The Admin Arsenal Team on Mon, Jan 04, 2010
Photo by Michael | Ruiz
Author: Adam Ruth
I have the problem, which is probably pretty common among programmers and system administrators, of sitting for too long at my computer. I've been having some trouble with a stiff neck and shoulders, not to mention eye strain and other problems with not taking enough breaks. In order to alleviate this problem I went looking for software to remind me when it's time to take a break.
After some searching I settled on
MacBreakZ (which, for some reason, I keep pronouncing as "mac break zee" instead of "mac breaks" which I'm sure is correct.) I've been using it for a couple of weeks now and I'm really pleased with it. It has a number of options for when it reminds you to take a break, as well as tracking your mouse and computer use. I've got it set up for a 5 minute break after 30 minutes of computer use. During the break it shows random stretches from its collection of 42 geared toward office workers allowing you to do the stretches if you don't get away from the computer all together.
There is also a feature to track your keyboard and mouse usage and warn you when you've been typing or mousing too fast for too long, to prevent repetitive stress injuries. I had to disable this feature, however, because either I'm a superhuman typist or it's just too sensitive to work with my pace. It's configurable, but only the least sensitive setting didn't get triggered by just a couple minutes of my working.
I've found it to enhance my productivity, even though you might think it would slow you down by taking regular breaks. I highly recommend such software for anyone that spends a long time with a computer, particularly for anyone susceptible to repetitive strain injuries.
Posted by Shawn Anderson on Fri, Jan 01, 2010
We get a number of requests for assistance with deploying Adobe Reader. Here's a quick way to install the software remotely using Admin Arsenal.
Step 1: Download the latest version of Adobe Reader
Step 2: Place the installation file(s) on your computer or on a networked share
Step 3: Select which computer, collection, or OU that you will be installing to and double click to open
Step 4: The Deploy Software window opens. Select the Deployment File button and navigate to the downloaded Adobe Reader installation file. (If additional files were downloaded, be sure to select the Include Entire Directory check box.)
Step 5: Check the Send Password option and enter the following into the Command Line field:
/sAll /rs /rps /msi"ALLUSERS=TRUE EULA_ACCEPT=YES SUPPRESS_APP_LAUNCH=YES"
NOTE: Always test before doing a large push. We've found the above command line to work but Adobe Reader versions change regularly.
The deployment should be very quick and should not be noticed by any users currently logged onto any of the computers receiving the software push.
We have a handful of step-by-step instructions for deploying common applications. If you have an app that is not listed please let us know and we'll get it tested in our lab and post the steps.
The biggest challenge for many is determining the correct command line usage, as was discussed last year.