December 27, 2006

Microsoft giving away a Ferrari or two!

Well, the Net is buzzing with the fact some bloggers received free laptops from Microsoft. Nice Acer Ferrari laptops. Sweet looking things. Charlie and Mitch both have one (bought with their own money... not from Microsoft), and I have been quite jealous to see how well Vista runs on them. My lowly Acer TravelMate C110 Tablet can't run Aero... so I miss some of the sexiness in Vista, as well as the performance.

What bugs me though is the conspiracy theory that MS is buying bloggers. Gimme a break. Who cares. Microsoft... feel free to send me a Ferrari any time. We both know I will continue to say what I feel... and not what you WANT me to feel. Actually... people inside of Microsoft have always been supportive of my own views... even when they go against their own. Sometimes conflict is the only way to get things brought to the forefront of discussion.

If you believe a blogger's integrity can be bought so easily... is that really a blogger you want to read/trust? Get off it. Kudos to Microsoft for going out of its way to give these machines to the community, and not to mainstream media. I think it was a great idea. And if you are a blogger who received one and think its wrong, immoral or what have you... feel free to contact me. I can put it to good use.

Posted by SilverStr at 08:50 AM | Comments (1) | TrackBack

Disappointment in VS2005 SP1 on Vista

Well, I installed SP1 of Visual Studio 2005 yesterday on my laptop running Vista, and I have to say there was one think that really disappointed me. So much so that I am not just going to blog about it... I want everyone that reads this to go AGAINST Microsoft recommendations. Here is what I mean:

Thats right.... Microsoft is recommended to run Visual Studio as Administrator. NO. NO. NO. NO. NO. Don't do this!!

You are on Vista. You should be running as a Standard User, and running Visual Studio as a standard user. Why? Because then you can SEE how your application will work while in least privilege mode AS you develop the software.

Now, some people will complain that they need to be administrator because they need some of the tools in the IDE. A good example would be if you are writing a COM component. You cannot register the library when running as a standard user. Is there a solution? Yes. Open up a cmd window as Administrator and do it by hand. Don't like that idea? Have a post build event that runs a custom app to do it... and modify the manifest to REQUIRE the UAC elevation. This way, you elevate a separate process to do your administrative task without requiring the IDE to be run with higher privileges that you really don't need.

And NOTHING prevents you from starting a second copy of VS2005SP1 elevated in those cases where you really have to debug as Administrator. But for your day to day use of VS... DON'T run elevated!!!

I am really surprised and disappointed to see this dialog. I only hope Microsoft reconsiders this position in its next version. If they REQUIRE admin privs for some tools, separate them out so only they have to be run as Administrator. You should only elevate when you need to; you should try to run with least privilege throughout the entire development process so you can REALLY see the impact of the code on normal users.

Well, IMNSHO anyways.

Posted by SilverStr at 08:28 AM | Comments (3) | TrackBack

December 24, 2006

The problem with OpenID... will it ever leave the confines and control of the geek world?

When it comes to identity management, one of the more interesting things these days that I have been following is the whole idea of OpenID. Alan even went so far as to link to a great video screencast by Simon Willison that shows how to use OpenID. There is quite a bit of buzz about it. Heck, Dick and his crew over at SXIP are actually throwing an OpenID 2.0 Vancouver Mash Pit in January to try to get more people working with it. And I'll be there. (If you want to join me Alan, let me know) All good stuff.

In the midst of all the buzz though, I am seeing one trend that I think is doing more to HURT OpenID than help it. Everyone wants to be the "provider"... but few want to be the "consumer". Let me see if I can put this into perspective for you. Let's look at the majority of sites that I regularly use that could benefit from OpenID:

  • My Bloglines account
  • My Technorati account
  • My Google Ads and Analytics account
  • My Movable Type blog author logins (I have 3 separate blogs)
  • My comments on other peoples blogs
  • My phpBB Forums account
  • My YouTube account

Now, it IS possible to get 3rd party patches/modules for some of these that can consume OpenID auth. But by default, most of these sites want to be the provider. And that drives me nuts. These guys all obviously GET the idea behind OpenID... going so far as investing in building the code to let them be the IdP. But few are making it easy to consume OpenID. I could care LESS if Six Apart or Technorati can be an OpenID provider. I don't particularly have a lot of care or trust in them. I want these sites to trust MY provider... which in this case is my own corporate authentication server.

You see, for me to adopt OpenID I would like to use this blog as my identifier, and configure authentication delegation to the company's two factor authentication server, which can provide support as an OpenID provider. Then I could simply use my same hardware token to logon to all these sites.

And that to me is the REAL value of an "open" ID. I think that is getting lost with all these players. It's nice that they want to be providers for their users. But they should ALSO be willing to be the consumer for those of us that use their service, but wish to use a different provider.

I think part of the problem is that if we plotted OpenID on Gregory Moore's "Technology Adoption Life Cycle", we aren't even close to "crossing the chasm". Geeks see the value of OpenID and are coding support in as the provider. It's only a small step from being an identity silo to offering a way "out". But what we need is more ways "in".

If I consider the value of the information available to my accounts on sites like Bloglines and Technorati, there shouldn't be a problem with their sites trusting MY identity from somewhere else through OpenID. I only hope they realize that soon... so I can truly be an OpenID adopter and advocate.

If you work for these sites, or have a popular site yourself, please consider being a consumer BEFORE being a provider. Don't get me wrong... fill your boots and be an OpenID provider if your users want it. But if you want ME (and people like me) to use your site, consider first to be a consumer of it. It's much easier for me to adopt that way.

It's MY identity after all.

Posted by SilverStr at 03:32 PM | Comments (11) | TrackBack

December 19, 2006

Comparing Microsoft infrastructure security with Open Source software

Recently Nick over at WiKID Systems blogged about How to get Microsoft-esque security with open-source software. Now, to be fair WiKID is an open source company and has an interest in such a post, and has plenty of experience behind it. However, I had to comment because I feel it just wasn't a fair comparison, especially when considering two factor authentication in small business environments that leverage Windows environments like SBS 2003.

I am posting the comment here, for many of my readers that don't visit Nick's blog.


No, its not as simple as Plone vs Sharepoint.

Trying to compare SquirrelMail to Outlook over RPC/HTTPS is just insane. Hell Squirrelmail vs Outlook Web Access isn't even close to the same thing. If you are on the Windows stack, Microsoft solutions work just as well for small business as it does at scale.

I know both Linux and Windows. We use both in our network. And I can say without quarrel that a deployment, including TCO, of Small Business Server 2003 is MUCH more effective than a custom built Linux box, ESPECIALLY if you use Microsoft technology in the office such as Outlook, Sharepoint, SQL Server and Exchange together.

I remember using this argument when I was in the grass roots movement for Linux years ago. Why fret about all the insecurities and problems with Windows when there were open source counterparts. But the reality is... there ISN'T a heterogeneous solution like what Microsoft offers. Find a REAL replacement for Exchange. And Sharepoint. And Office. And .NET. All tied together. It doesn't exist. Yes great technology like Mono, Apache and PostgreSQL exist, but in the greater scope of things in a business trying to leverage their IT resources as an asset and not a burden... its much easier AND cheaper to deploy a Windows solution with SBS2003 than Linux. And MUCH easier to maintain.

Adding two-factor authentication (2FA) on either solution makes total sense. And you can indeed deploy strong authentication in small business environments for under $100 a user. The trick is finding the right solution for your needs. If you are going to deploy the solution, you have to weigh the 2FA server against its agents. If you want just a web based strong authentication server (SAS), your choice will be different than a solution that works with Windows logon, IIS/Apache agents and PAM modules. Now I know WiKID is in the business of 2FA, but I don't think its very balanced to recommend open source blindly without telling the whole story. You still need a SEPERATE 2FA server if you want to leverage your Windows network. Instead... why doesn't WiKID build agents for those Windows networks? Example: Why tunnel over SSH when you can simply use the secure comms in RDP with a strong authentication logon agent? Eliminates the need for another port to be opened through the firewall that's not needed. If you use Microsoft's ISA Server you can even proxy filter the Active Directory Logon credentials in a way so an adversary won't even GET to the real resources until authenticating via AD at the firewall. Guess what, you can't do that in an open source environment. Even with Samba, you cannot leverage your AD infrastructure for security policy enforcement at the firewall (be it iptables, ipf or what have you).

It's all about using the right tool for the right job. You typically have interesting and relevant content on your blog. However I gotta call you on your comparison of the Microsoft infrastructure vs open source. It's not a practical comparision in the REAL world of SMB networks, and really is inaccurate in the definitions of what the technologies offer the business.

Posted by SilverStr at 04:23 PM | Comments (3) | TrackBack

December 17, 2006

Want to know how to make your apps play nice with Vista's UAC?

MSDN Magazine has an EXCELLENT article on teaching your apps to play nicely with Windows Vista User Account Control (UAC).

The Table of Contents for the article can do a pretty good just of quickly showing you why its so interesting:

  • Active at Logon
  • Creating a Filtered Token
  • Designing Apps to Run with the Filtered Token
  • Designing Apps that Require Administrator Privileges
  • Privileges During Installation
  • Marking the Privileges for an MSI
  • Running Your App with Administrator Privileges
  • Marking Required Privileges Using an Application Manifest
  • Marking a COM Object
  • Alerting Users to Elevated Privileges
  • Communicating between Processes in Different Security Contexts
  • Low Rights Internet Explorer
  • Securing a Windows Service in Windows Vista
  • Common Application Compatibility Issues
  • Problems During Installation
  • Typical Runtime Application Issues

Lots of kewl stuff here. Happy reading!

Posted by SilverStr at 11:12 PM | Comments (0) | TrackBack

December 09, 2006

Is it ever appropriate to disable UAC on Vista?

Maybe. Depends on your tolerance for UAC dialogs during the initial build of a Vista workstation.

Recently Vlad wrote an entry on his blog that got me in a pretty defensive position about UAC. He stated that:

"I have personally walked several people through the disabling of UAC."

On the surface I was vexed. How could such a competent geek do such a thing? I wanted to get Susan's 2x4 and show Vlad what I thought of his actions. Instead, I decided to ask him WHY he did such a thing, and what caused him to take such drastic action. I was glad I did.

He spoke of the fact that during the initial build of the workstation, installing drivers and application software was painful. He also commented that developers were always installing software, and as an end user experience... this wasn't a desired state. Hence why he disabled it.

I am of two minds. When initially building the machine I can understand wanting to disable UAC. If you trust the software you are installing, I could actually see where it would be desirable to speed things along. If the machine is in an isolated environment firewalled away from the rest of the Internet... go for it. Just remember to turn UAC on when you are done. Although, as someone who has installed a number of Vista machines now... its not that bad.

For the developers though... that's a different story. They SHOULD keep UAC on at all times. For a NUMBER of reasons. First off... maybe they will see how annoying their own software is if it wasn't designed to work in a least privileged environment :) Secondly... and more importantly... DEVELOPER'S ARE USERS as far as the IT resources are concerned. They SHOULDN'T been installing software hap-hazardly on corporate machines. That's what their test (virtual) machines are for. They should have to adhere to the same corporate security policy as everyone else... detailed for their particular role in the organization (assuming the policy supports the definition of roles). People SHOULDN'T be allowed to install software on the machines unless it is part of the duties they must perform. As such, the UAC prompt is a REMINDER of that. If the developer is going to override it... AND has authority to do so... they can enter their credentials and continue on.

UAC is a good thing. It might seem nice to do it old school 'sudo' like Unix environments, but globally disabling such security controls is a mistake if you ask me. Being prompted of all elevation requests help you to understand what apps are really doing. As 3rd party apps build their software for Vista we will see a reduction in the prompting as the applications will be written properly with least privilege. As someone who has run Vista for months now I can attest to the fact that I rarely see UAC prompts. I did during the initial install phase... but now that I am using the platform... I don't see it that much. And when I do, it's expected.

So don't turn UAC off. Instead educate your users on NOT installing software unless they absolutely need it. And if they DO need it to do their job... why wasn't it already cataloged as an information asset of the business and previously installed? Your IT asset catalog should define all software needed for a role's responsibilities in your organization, and you should be making sure you have backup media to ensure you can always reinstall it on a rebuild.

When set up properly, Vista's UAC isn't there to hinder a user's experience. Rather it is there to inform the user when they take action that requires higher privileges and may be against the policy of the organization. Don't lose that. Don't disable UAC.

Posted by SilverStr at 01:07 AM | Comments (8) | TrackBack

December 07, 2006

What tarot card are you?

Maryam admitted that she was the devil. Apparently I am the SUN.

You are The Sun

Happiness, Content, Joy.

The meanings for the Sun are fairly simple and consistent.

Young, healthy, new, fresh. The brain is working, things that were muddled come clear, everything falls into place, and everything seems to go your way.

The Sun is ruled by the Sun, of course. This is the light that comes after the long dark night, Apollo to the Moon's Diana. A positive card, it promises you your day in the sun. Glory, gain, triumph, pleasure, truth, success. As the moon symbolized inspiration from the unconscious, from dreams, this card symbolizes discoveries made fully consciousness and wide awake. You have an understanding and enjoyment of science and math, beautifully constructed music, carefully reasoned philosophy. It is a card of intellect, clarity of mind, and feelings of youthful energy.

What Tarot Card are You?
Take the Test to Find Out.

Posted by SilverStr at 11:31 PM | Comments (0) | TrackBack

Can you really trust what you read on blogs?

Sorry I haven't posted lately. I have been totally wrapped up on a project that has been sucking the marrow out of every bone in my body. I have had to bring myself up to speed on a lot of technology I have been happy to avoid over the last decade, only to have many interesting challenges arise from those decisions over the years. I consider myself a fairly competent software architect... but when I get stuck, man do I get stuck. I put a product we expected to launch last month at least a month behind. *sigh*

I wanted to share a story about a challenge I had for sometime. A failure that has taught me a clear lesson. It took me over a month and a half to conquer this problem, which I am sure many of you could have solved quickly by making different choices in the design phase.

My first mistake was that I put blind trust in people who were NOT in my circle of influence. I ASSUMED that they had real world experience in what they spoke of, only to find out after the fact that this wasn't the case. This bit me both on public Microsoft newsgroups and with MSDN blogs, where employees at Microsoft made statements that were found to be OFFICIALLY unsupported, and in a few cases, UNTRUE or not properly tested. That is a problem with blogs; people give their own experiences... and we the reader don't always know where their experience comes from. We just take the words as fact.

In my case I was directed by various Microsoft employee comments in newsgroups and a few blogs that I could write a managed COM component in C# to take advantage of web services and WS-* security, and that I could then use it in unmanaged C++ code. Well.... that's not entirely correct. That is true of standalone applications in user mode. But go ahead and try to do it in services like IIS or IAS, where you CANNOT do INPROC COM interop. You come up to loader lock issues which can freeze the system with a massive deadlock and isn't supported in the currently released Windows kernels. This is a KNOWN but undocumented limitation by Microsoft, and something being addressed in Longhorn. And I only found this out after 4 different PSS cases were opened in the last month, where the support engineers at Microsoft were solving symptoms of the problem, and not the actual root cause. When I finally got escalated to a guy on the Redmond campus in charge of this sort of stuff, only then was I clear about the REAL problems, and how to really solve it. I was so pleased to work with him; he made everything clear to me without making me feel uncomfortable. Of course I had to re-architect a huge piece of our system to deal with this issue. But I am not fretting about it; the new design is much more robust... and more reusable for other stuff we are doing anyways.

What did I really learn here though? Well the first thing is that I am NOT a COM guru. I already knew that... but never realized how much I still had to learn about COM and interop issues with managed code. The last month has NOT been fun as I tackled the learning curve. More importantly though... I learned that you cannot blindly trust what people say on blogs or in newsgroups, no matter WHAT domain they belong to. I trusted that a *@microsoft.com employee comments on newsgroups and MSDN blogs were golden... I should have known better than that. That is not to say these people aren't smart; it's just that you have to understand what COULD work in theory doesn't always work in practice. "Patterns and Practices" people got that down cold. They are the people I should go to in the first place.

For those that are interested in what I ended up doing, here was the solution to my problem:

  1. Write an unmanaged COM DLL (C++) that services like IIS and IAS can call directly INPROC.
  2. Have that DLL communicate via DCOM RPC (LOCAL) to a Windows service, ALSO written in unmanaged code (C++).
  3. Have that Windows service load up the managed COM component (C#) via INPROC, where it is safe to load the CLR.
  4. Voila. You can now call into any managed code without loader lock issues.

Ya, pretty simple looking back. But when you are told by various sources that you can call the managed COM component directly, you just don't think you need all the middle tier comms. Wrong.

Lesson learned. Time to load up Bloglines and go catch up on all those blog posts I haven't had time to read lately. *chuckle*

Posted by SilverStr at 10:26 PM | Comments (6) | TrackBack