Here it is, our favorite reason to NOT go with Google Apps: Corporate Email Skills.

We believe that “getting prepared to use Corporate Email” is pretty much the antithesis of “getting prepared for your future”. The attitude so beautifully summarized in this Live@Edu tweet is precisely what got our education IT systems to where we are now, and a clear indication of what’s driving Live@Edu.

Attitude aside, arguing specific application features is not very useful- they are all fast-moving targets. What may actually be important to you is getting your data out, and ability to use tools like Android devices, iPads and the like. Or even Firefox. Before jumping into Live@Edu, find out what happens should you chose to migrate away from Microsoft, or pick one of the cool new ChromeOS netbooks for use in your classrooms.

Plug: we help educational institutions migrate to Google Apps, and build tools that make Google Apps easier to use in the classroom, and reduce admin effort for schools and school districts. Contact us to find out more!

Congratulations to the delivery team at Tait Radio and WaveAdept on great Google Apps implementation!

Really cool video overview of the process is available at http://www.waveadept.com/2010/tait-radio-goes-google-with-waveadept-video/.

Tait Radio is also a Hapara Access Manager customer: welcome to our community!

Innovative New Zealand cloud applications specialist, Cloudbreak, is renaming to Hapara and going global with its portfolio of cloud products and services that provide enhanced functionality for large enterprise deployments of Google Apps.

“Our evolution from a cloud consulting to cloud products business was in the plan from the beginning,” says Jan Zawadzki, CEO Hapara, “we encountered the same customer needs during a number of implementation projects and have sought to leverage the power of Google App Engine platform to extend the capability of Google Apps even further.”

Hapara is New Zealand’s most experienced Google Apps implementation company with over 20 Google and enterprise deployments under their belt – including the provision of specialist technical advice to New Zealand Post, and the largest Google Apps deployment in the country to Unitec’s 46,000 users.

“Hapara’s specialist expertise has helped us to leapfrog capabilities for our students,” says Unitec’s Director of Information Technology, Peter Winquist.

The company’s international go to market plans have been brought forward several months due to overwhelming interest in Access Manager for Google Apps, the first Hapara product to be released. Information on the product has gone viral and been picked up via the global grapevine of user group forums and social media channels. Hapara has been receiving daily enquiries from large organisations in North America, and Europe. The company will be announcing the global availability of Access Manager in the Google App Marketplace within the next few weeks.

Access Manager is an enterprise management add-on for Google Apps that simplifies the administration of large scale enterprise Google App deployments, and supplies the essential features required by security and network administrators. The product is purchased as a cloud service. Features include real-time password synchronization with systems like Active Directory and OpenLDAP, desktop single sign-on, two-factor authentication using mobile phones, integration with Facebook and the ability to customise and track access to login screens. The outcome for users is easier and more secure access to their mailbox using the same username and password they already use for logging into their enterprise’s network.

“What makes Access Manager unique is the way it leaves the enterprise in control over the management and storage of their own identity credentials,” says Mr. Zawadzki.

In just under 6 months since the initial release, Access Manager has gained over 45,000 users across 6 organisations including Unitec and a major New Zealand electronics company.

Access Manager is the first of several Hapara cloud applications to be released.

Tracy Voice, CIO at New Zealand Post (our client!),
talks about their experiences in migrating to Google Apps

1. Shoulder-surf behind them until they open their Google Apps Gmail.  (Or send them an email, walk over, and casually ask them to read it now now now please!)
2. Look at the top-right of their Gmail page.  Right next to their email address.
3. Is there a link that says “Manage this domain”?

If there isn’t, please congratulate your colleague on their sensibility and responsible management practices.  They are truly in the minority, and deserve the kudos.

If there is, you and your organization are at risk.

The “Manage this domain” link indicates that your colleague’s account has full administrative rights to your Google Apps domain.  While this might seem like a sensible thing (they are the Google Apps admin after all!), it’s actually a recipe for disaster.  Fortunately, there is an easy, if potentially ego-bruising, fix – more on that later.

Disaster may seem like a strong word to use here, but it’s entirely appropriate.  Four factors contribute to an unholy mix:

Google Apps admin is omnipotent. Any Google Apps domain admin can create and delete accounts, change passwords, delete content, or delete the domain itself.  More insidiously, through access to the Single-Sign-On settings and with a little bit of effort, they can read your email, impersonate you, or discover your password.  That is a lot of power, and role separation is an area that Google are keenly aware needs work.

The username/password login process is not that secure, really. Twitter learned this the hard way last year.  Unless you use two-factor authentication or a hardened login (plug: it’s easy to do using our Access Manager product!), all that stands between an attacker and your mailbox (or the delete button on your Google Admin console) is a username and password.

For a determined attacker there are a number of technical and non-technical ways to get at these: key loggers, wifi sniffers, tequila.  Worse yet, most people re-use the same passwords everywhere, so that disclosure (and attack) could come from anywhere.

Google admins are not so hard-core. Hard-core, die-in-the-wool, suspender-wearing admins will willingly use those impossibly long passwords, and  if necessary, will go to jail to keep the bad guys from getting them.  Really.  This has a lot to do with the fact that traditionally, IT admins dealt with arcane systems that took months if not years to fine-tune, and keeping the ignorant masses from hurting themselves was essential.

Google has made a fortune hiding the hard stuff behind pastel-colored buttons that do what your average user would expect them to.  It’s actually pretty hard to hurt yourself in Gmail, isn’t it?  Unfortunately, this has also contributed to the impression that administrating Google can be done by anyone – with minimal if any training, and with no discipline.

The lack of discipline is the problem – your hard-core, suspender-wearing admins of yore would jump through hoops to make sure that every change was tested, re-tested, re-tested again against a back-out plan, and then tested once more by someone who has only read the written procedure documentation, which was of course signed off in triplicate.

Perhaps this isn’t exactly what we need in the Google Apps admin world, but the attitude that seems endemic can only generously be described as laissez faire.

Passwords leak. Admin passwords leak.  It is the reality of most IT organizations: there will always be some oddball set of circumstances that forces your admin to give someone the password to “just fix that one thing”, on a Saturday evening, when they are away from their computer.  You should expect this, and manage accordingly.

So what do you do?  The unholy mix of the omnipotent Google Apps admin model, corporate Google admins coming from non-IT-admin roles, relative ease of getting at user credentials, and password leakage, is a significant risk to many organizations adopting Google Apps.

The fix? Some simple changes to how administrative access is managed, and some discipline:

1. Remove admin privileges from all user accounts, immediately. No one should check their email from an admin-enabled account, under any circumstances.
2. Set up at least two separate admin accounts: a “system” admin, and an “ops” admin. Assign strong passwords to both, and force rotation schedules accordingly.  Set up email forwarding rules to ensure that any messages get to your Google admins and don’t need to be checked using these accounts.
3. Use the “system” admin account for integration and batch jobs only. No operator should ever log in with this account.  If you use multiple integration points (provisioning, etc.) you can use multiple system accounts.
4. Use the “ops” account for day-to-day admin tasks – of which there really shouldn’t be many.  If you have more than one Google admin, create additional ops accounts to ensure traceability.  Do not allow logins on these accounts from anything other than trusted machines, over encrypted connections.  Change ops passwords frequently.

Yes it’s going to cost you fifty bucks per account to do this (unless you’re edu!), but compare that to the hourly fees your lawyers are charging.  Security-wise, this is the most bang for the buck you will get from some chump change and an hour of effort.

Once you’ve done this, have a look at our Access Manager and see how much more a few more dollars gets you :)