Tuesday, May 29, 2012

Google Apps receives ISO 27001 certification

In the early days of the cloud, security concerns were often at the top of business minds as they considered moving to Google Apps. More recently, though, security has become a major reason businesses are moving to the cloud....

Official Google Enterprise Blog: Google Apps receives ISO 27001 certification: Posted by Eran Feigenbaum, Director of Security, Google Enterprise In the early days of the cloud, security concerns were often at the ...

Wednesday, May 23, 2012

Quick access to contact details on Gmail

When searching for an email address, the results will now show you contact details in addition to that person's profile photo and the emails sent from and to them. From here, you can start a chat, call their phone and more.

Google Apps update alerts: New Gmail features: Quick access to contact detail...: The following new features are now available to Google Apps domains: - Quick access to contact details: When searching for an email addres...

Monday, May 21, 2012

A new way of working?

Published in the Oxford Times (16th May 2012)

Bring your own device

How do you feel about using your own computer or tablet at work? For many this is becoming the reality as the trend for ‘bring your own device’ or BYOD starts to take off.

The benefits and risks of BYOD have been the subject of heated debate amongst the technology community for some time now. Some technology experts resist the idea on the grounds that it is too difficult to manage and secure such a wide range of devices in a business setting. Others see it as an opportunity to boost productivity and cut costs.

A classic early example of the BYOD phenomenon was the iPhone. Just as the technology departments had invested significant sums in providing staff with an email-enabled Blackberry, along came users with their iPhones asking why they couldn’t use these instead.

The response by some at the time was to say they didn’t support iPhone. That becomes a difficult position to take against the type of enthusiasm found amongst Mac users. It certainly doesn’t make sense for business users to find themselves having to carry two smartphones.

Now we have the iPad, Android phones and a whole host of other ‘devices’ that users feel their workplace would benefit from. The consumerization of technology has no doubt been a challenge for technology support staff, but it’s certainly here to stay, even if it isn’t favoured by advocates of a more traditional corporate approach.

Instead of pushing back, now many are now starting to embrace the idea. Certainly asking users to buy, support and maintain their own hardware has the potential to offload some of the work carried out by technical support. The nagging concern is that the diversity risks making life just too complicated.

Fortunately, at the same time as the demand for BYOD has increased, so has the popularity of ‘cloud computing’, a slightly abstract term given to the use of web based applications provided by vast data centres maintained by the likes of Google and Microsoft.

This is a game changer, because it promises to make makes BYOD a viable solution. By providing applications through secure web pages, device maintenance becomes much simplified. All that is required is an internet connection and a browser. The device itself becomes almost unimportant.

A good example of this is the implementation of Google Apps at Oxford Brookes University. Staff and students are now provided with a web based email, calendar and document system powered by Google as opposed to locally maintained servers and disks. By providing these services as web applications the university has also removed the need to configure email software on student or staff computers.

So, here we have three trends which promise to revolutionize the way we work. The first is the popularity of consumer devices. They get thinner and faster, but are in many ways becoming more standard because their job is to serve web applications. That’s driving the second trend which is for business and other organizations to make their applications available over the web. Which in turn will drive the third trend of users being able to work from any location on any device.

The transition from work based technology presents its own challenges. One is how to migrate vast amounts of legacy data to web applications. Another is connecting these devices to corporate technology like the printers and photocopiers, although these too are becoming web enabled.

Perhaps the biggest challenge is to make the applications, the data and the devices more secure. The obvious danger of making web applications available to any device from any location you are also increasing the potential ease with which hackers can target them.

Some technologists are against the consumerization of technology for different reasons entirely. If the likes of Google and Microsoft are providing corporate email and document services to consumer devices, where does the control belong? Who owns the data? How secure and private is that data? What else can it be used for?

The take up of cloud based services by all sectors from charity and education to industry and finance suggest there has been some reassurance on these questions. One way these concerns have been addressed has been for the cloud providers to give finely tuned administrative responsibility to the business. That means the business can still retain control of the data, if not the hardware on which it runs.

Cloud and BYOD advocates even argue that this approach is more secure. By keeping data in the cloud rather than on a device, a stolen laptop or disposed desktop computer no longer carries the same risk of exposing data it once did. This is particularly true as remote wipe technology (where phones can be wiped once reported as stolen) is adopted as standard.

The debate will no doubt continue, but one question remains. If you can bring your own device to work, what will you choose?

Ray Allen is the founder of Third Way IT, an Oxford based provider of Google Apps for Business.

Tuesday, May 15, 2012

Introduction to Google Apps Directory Sync (GADS) by example - a beginners guide


This article is intended to help first time users of Google Apps Directory Sync which allows for the automatic provisioning of user accounts to Google Apps from your directory service. A more detailed explanation of the software is available online in the administration guide but this should be enough to perform a basic sync of users and groups from Microsoft's Active Directory on Windows Server 2000, 2003 or 2008.

This article is published by Gappsconnect, a Google for Work Partner  based in the UK. Please contact us if you have any questions or would like to discuss the use of a specialist to undertake this work on your behalf.


1. Active Directory structure. The job of synchronising user accounts is made much easier if the users and groups that you are planning to sync belong to a common organizational unit (OU). If you have your users spread across multple OUs, consider creating a a parent OU called 'Google users'. It is not possible to sync user accounts unless they are in an OU.

LDAP refresher (skip this part if you know it already)
Before starting, remind yourself about directory services (called Active Directory or AD on windows) and the use of LDAP (Lightweight Directory Access Protocol). GADS uses LDAP queries to extract the required information from your directory. A good understanding of terms and acronyms will help!
DC: Domain Component. This describes your domain. For example, the domain example.com would be described in directory services as dc=example,dc=com
OU: Organization Unit. Organizes your directory into a tree structure (nested folders). Typically, you will have separate OUs for users, computers, etc, but also have OUs to help distinguish types of users. You might for example have a separate OU for power users. These will vary site-to-site depending on the preferences of the domain administrator. This is an excellent way to organize the user accounts that you want to replicate to Google Apps. If they are in a distinct OU, the job of syncing becomes much easier.
CN: Container Name. Think of this as a built in OU. Active directory has a CN called users for system user accounts for example. These are usually not replicated to Google Apps. 
DN: Distinguished Name. The path of tree containing the objects that you are interested in. (Example ou=visitors,ou=2012,dc=example,dc=com is the DN to use if you are only interested in objects held in the OU called visitors which in part of the OU called 2012). 
object class: Object classes describe the objects stored in directory services. The most commonly used objects in active directory (and relevant to GADS) are users and groups.
Attributes. Each object will have any number of attributes. For example a user will typically have sn for surname and givenName for their given name. 
A typical LDAP query:
This query would find all users who are in the OU called 2011 at example.com. Several good articles are available if you type 'LDAP query language' into your search engine and these may come in handy as you build your GADS config file, although variations on the given example above should suffice for a straightforward sync.

2. Active Directory user account. Create a separate, empty, top level OU in your directory called 'Google sync' and add a standard user account to it called ldap_user. This will be used to look up your directory during the sync. Set it to have a non-expiring password so that you can run scheduled syncs. The account does not require admin privilege as it is only performing directory look ups.

3. Google Apps admin account. Create an account in your Google Apps domain called ldap_sync and give it admin rights so that it can create and delete accounts in the domain.

4. Provisioning API. Switch on the provisioning API in your Google Apps domain control panel. This is found in 'domain settings > user settings'

Configuring Google Apps Directory Sync

5. Install GADS. Download the program and install it to a directory that you have write access to (not program files). http://support.google.com/a/bin/answer.py?hl=en&answer=106368

6. Open the Configuration Manager. This is a GUI that helps you build the XML configuration file that will be used to carry out the synchronization. Each menu item has multiple tabs that you should review before saving. The first menu item, General Settings, is where you declare what you plan to synchronize. I recommend you only start with the first three options.

7. Configure Google Apps connection. Use the ldap_sync account created in step 3 to connect. Use OAuth token for secure authentication in preference to the username and password.

Tick 'replace domain names' if the domain name of your AD is different to your Google Apps domain.

Use second tab if you have a proxy server. You can use the third tab to protect any Google Apps users from deletion when the sync takes place (if they are not present in AD).

8. Configure LDAP connection. Use the account created in step 2 to connect to your AD. This step will only work if you have a Base DN that includes an organizational unit; If you have created a parent OU this should be your Base DN.

9a. Configure Organizational Units (mapping). Use the distinguished name (DN) of the parent OU container that you have created for your users and groups and map it to the Organizational Unit name that you would like to use in Google Apps (it will create this for you).

All child organizational units will be synchronized.

9b. Configure Organizational Unit (search rule). The rule for finding all organizational units within the base DN is 'objectclass=organizationalunit'

10a. Configure user accounts (attributes). You need to map user attributes in AD with those required to create accounts in Google Apps.

Because some users may not have an email address defined, the 'userPrincipalName' attribute is useful for defining the mail address in Google Apps. The domain name will be substituted in Google Apps if you ticked the box in step 7.

If you plan to use AD to manage your user accounts, you will want accounts that are deleted from AD, deleted from the Google Apps domain too.

10b. Configure user accounts (additional attributes). You will need to know the given name and surname attributes to create Google Apps accounts. These are usually givenName and sn. Note that it is not normally possible to sync AD passwords using GADS, but a separate product called Google Apps Password Sync is available now to do this.

10c. Configure user accounts (search rule for active accounts). The first rule will find all active (non-suspended) user accounts. This can be achieved with the search rule:


10d. Configure user accounts (search rule for suspended accounts). The second rule will find all suspended user accounts and can be used to ensure Google Apps accounts are suspended if marked as such in Active Directory. The rule syntax is:


Make sure you tick the 'Suspend these users' box!

10e. Review search rules. You should have two rules, one for active accounts, one for suspended accounts.

11. Define group search rules. The search rule to find defined groups in your AD is:

objectclass=group. You will also need to declare the member reference attribute (normally member), group email address attribute (normally mail), display name (normally name), description (normally description) and the owner (normally managedBy)

12. Finally. Define your notifications, sync limits and logging preferences.

Congratulations. You have configured Google Apps Directory Sync and you should be able to perform a test sync to ensure the appropriate changes will be made. Once this has been done you will want to consider synchronizing other information and performing scheduled synchronization. This is documented in the administration guide.

Ray Allen. All rights reserved. Please use comments to let me know how you find this guide, or contact me at GAPPSCONNECT with any questions.

Friday, May 4, 2012

Are you a workplace hack?

In an interesting article on the BBC website, author Josh Klein argues that we should embrace the concept of workplace hacking. Workplace hacking involves finding ways round restrictive systems in the workplace. His first example involves the use of Google Docs.
Find one hated piece of software you're "required" to use and Google a workaround; use Google Docs instead of Excel, Drop Box instead of Sharepoint, or whatever it is you're saddled with. Try it for a week or two. See how much more efficient you are.
Many will recoil in horror at the idea of employees using these systems that are not in the control of the organization, but whether it's liked or not, the truth is this is happening everywhere. It's like BYOD (bring your own device). You can argue that it's dangerous and should not be permitted, but it happens.

IT departments need to embrace the technology users find most effective. If they want to retain control, find out more about why they prefer Google Docs to Sharepoint (after all, who wouldn't). Integrate the systems your users like into your organization. You may even find you same some money.

The enlightened organizations I'm working with who have started to incorporate Google Apps have been pleasantly surprised at the administrative control the can retain. These tools are not just for consumers, but increasingly used by business to both reduce costs and increase productivity.