Category Archives: Google Apps

Google Apps Redux – 1 year later

Leave a reply

I posted about Google Apps in the Enterprise a year ago. Google constantly evolves, I decided it would be a good time to update the post with more current information. Updates in red font.

Pluses

  • Email and calendar syncs with multiple devices – Native apps for Android and Blackberry, and IMAP support for the iFolks. No need for Blackberry Enterprise Server. Coming from an environment where only upper level management got Blackberries, having my calendar and e-mail on my phone was a huge plus.
  • Multiple editors – Google Docs lets you have multiple users in the same document editing simultaneously. This proved highly useful for many collaborative efforts.
  • Education – Provides a low cost, easy way to provide email accounts and collaboration tools for a constantly changing set of users.
  • This is a benefit of all cloud-based email, but you relieve your admins of the need to run a mail server. Google manages antivirus, antispam, storage, and updates. You can buy Google Vault for email compliance, no need to continue buying trays of disk as your archive storage demands grow.

Minuses

  • User Deletion – When you delete a user, it’s 5 days before you can put that user back in. It was an accident? Too bad. That user is without their e-mail account for 5 days. This extremely annoying problem seems to have been resolved.
  • Document Deletion – When a user is deleted, so are all their documents. Seriously. Every document they own is *poof* – gone. If you’re running Sharepoint, deleting the owner of a document does nothing. The rest of the team is able to access the documents authored by the deleted user. This is not the case with Google Apps. Forcing a specific user to own documents is a major flaw in Google Apps. There is now a document transfer utility, but you have to run it before the user gets deleted. It’s a manual process to assign the user’s documents to another user. If you’re running the Google directory sync tool (GADS), it gets even more difficult to manage. You can’t let the users automatically delete, so instead you have to suspend the users. You then need to go back in and manually clean up the suspended users, saving whatever documents need saving. Doing this on an enterprise level is EXTREMELY difficult and time consuming.
  • Management Delegation – There are no degrees of admin rights – you’re either an admin or you’re not. Although you can do some interesting thing with delegation using Google Organizations, many corporations have a centralized helpdesk. If you want any helpdesk worker to be able to help any employee, the helpdesk worker has to be a full blown administrator over the entire Google Apps domain. This is not a particularly palatable choice when you’re talking about hundreds of outsourced workers. Fortunately, Google updated this system to include a wide array of permission delegation.
  • Bandwidth – Your bandwidth costs are going up. WAY up. Using Lotus Notes, a file attachment sent within the company never left the WAN. With GMail, the sender has to upload the attachment to the Internet, and then each user who receives it has to download it over the Internet. Every time people check their email, it’s Internet bandwidth and not WAN bandwidth. That’s thousands of users generating Internet traffic that didn’t exist with Notes. No change here, but that’s the deal when you go a cloud service.
  • Constant Development – Google Apps is continuously changing, and changes are pushed to Production with no warning. Things break overnight and it irritates the hell out of your users, and drives up support costs for IT. The business has to get used to the fact that IT no longer has any control over changes to the email system.
  • No Logs – Logging is nonexistent. There’s no event viewer, no activity log, nothing. You have no idea who is doing what and no way to look it up
  • Extracting Information – You can’t even get a simple list of who your domain’s administrators within the Google GUI. If you want to extract the information, you’ll be writing a script. They have libraries in Java, JavaScript, .NET, PHP, Python, and Objective-C. If you’re a system admin, you’re probably not a programmer, so you’d better brush up on your Python. You’re not likely to make it past the learning curve to be able to use anything else.
  • Emergency support – You can’t get support without your support PIN, and you can’t get that without administrative access to your Google domain. The PIN changes periodically, so you can’t rely on having written it down. If you’re locked out of the domain, you’re stuck with filling out a form and waiting for e-mail support to get back to you.
  • The apps – Using the apps feels a lot like using Office 1.0. They’re rough, good enough for the very basics but not really ready for primetime. Your accounting department would stage a revolt if you forced them to use Google Spreadsheets instead of Excel
  • Enterprise Integration
    • Passwords – You can use the Google Apps Directory Sync (GADS) tool to automate user provisioning up to Google Apps by syncing your existing LDAP infrastructure with Google. However, passwords are quite a challenge. If you have a way to extract the user’s password out of your LDAP directory, you can push that up to Google – but who wants Google to have a copy of the user’s corporate password? So you’re left with maintaining a separate Google password. Even if you implement Single Sign-On and authenticate users against your own LDAP server, that only applies to access via web browser. The separate Google password is still used for mobile device access. The GADS tool will allow you to sync passwords, but only if your directory stores them with easily broken SHA-1 encryption, or plaintext. I am not in favor of reducing the security posture of your internal network just to be able to sync email passwords out to the Google cloud.There is a new tool called GAPS, the Google Apps Password Sync utility. You have to install it on all of the domain controllers in your domain. When a user changes their Windows password, the change is synced up to their Google Apps account.  The tool works well but I am also not an advocate of installing a utility on all domain controllers, particularly one that reads all password changes in plaintext.
    • Single Sign-On– If you decide to go the SSO route, you have to have a secure way to store a user’s e-mail address within your directory structure. With SSO, no user credentials are sent to Google – instead, Google uses a certificate to ask your company’s SSO server to authenticate you. Your SSO server must send the user’s e-mail address back to Google. This directory attribute must be created and secured, otherwise anybody with access to that attribute can impersonate any user. Let me repeat that – *ANY* user in the organization with access to the “email” property in your directory system can use SSO to read *ANY* user’s e-mail. For many enterprises, this means an unacceptable number of non-privileged IT workers have the ability to read anybody’s e-mails. Google does not offer any kind of AD schema update like an Exchange installation would to create a properly secured set of properties for e-mail address, so you are forced to create the properties manually and come up with a set of ACLs to achieve the proper security. This can be extraordinarily tricky in a large enterprise.Despite the difficulty, I prefer the SSO route. You don’t have to install anything on your domain controllers and user passwords never leave your network. Some of the SSO software vendors such as PING Identity have a Google Account password change plugin for their SSO software, so your users can authenticate with their AD credentials and can change their Google account password without a helpdesk call. I find this to be the most secure of the choices.

Google Apps seems has matured sufficiently that I believe you can successfully deploy it in most use cases. I would still question it for a large enterprise, but for SMB or Education purposes, Google Apps is a solid choice.

License activation for Adobe CS6 in a View linked clone environment

12 Replies

Update 2018-08-02

I haven’t had to do this since I wrote this blog post in 2012. However, somebody found this post about a year ago and told me they were able to use Adobe’s current tooling with my old post to make it work for their Horizon environment. I just got a question today on this blog post.

The current tool is called Creative Cloud Packager. It’s not quite the same as Adobe Application Manager, but the concepts are similar.

https://helpx.adobe.com/enterprise/kb/edu-deployment.html
https://helpx.adobe.com/enterprise/package/help/creating-packages.html
https://helpx.adobe.com/enterprise/package/help/create-license-file.html

 

Original Post 2012-09-23

I recently had to work out the process for license activation of the Adobe CS6 suite. Adobe offers an academic FTE licensing scheme similar to Microsoft’s FTE program. The calculation for licensing cost is based on your employee count; the entire district is then licensed and you don’t pay a dime for students. The Adobe K-12 Enterprise Agreement contains Design/Web Premium, Photoshop Elements, Captivate, and Presenter.

The total installed size of these products turns out to be 8-10GB, quite a bit of a nightmare to attempt a ThinApp. I decided to bake the Adobe software directly into the base image. However, Adobe license keys do not survive the quickprep process. The software comes up unlicensed when you log in to a linked clone.

Adobe offers a free enterprise deployment tool called Adobe Application Manager. One of the functions is to create a serialized installer key along with an executable that will license the already-installed Adobe software. Note that this does NOT work on Photoshop Elements. We have a ticket in to Adobe support for assistance, but at the moment it doesn’t appear possible to activate Photoshop Elements anywhere other than during installation.

First, download and install Adobe Application Manager. Then download your Adobe software and unzip the installation files. Then launch Adobe Application Manager. I found that it only worked properly when I chose Run as Administrator.
Launch Adobe Application Manager
Select the Serialization File option from the main menu.
AAM Main Menu Selector
Browse to your unzipped installer, you need to point to the folder that contains Set-up.exe. Then enter a folder name to save the serialized output, and a location on the network to save the folder.
Path to Installer

Enter the serial number.
Enter Serial Number

The output of the tool will be an executable and XML configuration file.
Application Manager output

Now we need to make this script run after guest customization. We put a C:\scripts folder inside each template. Then create customize.cmd in C:\scripts. Customize.cmd is a generic batchfile that will be called by View after it performs guest customization. You can only call one batchfile, so you either need to put every command in the customize.cmd batchfile, or use customize.cmd to call other batchfiles.
The script looks like this:
Customize script

Put one copy of the AdobeSerialization.exe into C:\scripts\adobe. Then create a folder for each Adobe product that you installed. Inside each of those folders is the prov.xml output file. Create the adobe-commands.cmd file and write it to call the executable once for each xml config file.
The syntax to run the licensing is as follows: AdobeSerialization.exe –tool=VolumeSerialize –provfile=prov.xml
Adobe licensing commands

Configure your View pool to run the customization script after the linked clone is quickprepped.
View Post-sync script

Now the Adobe products will be fully activated anytime you recompose your linked clone pools.

Google Apps – Lost Admin Password

4 Replies

I had a client who lost the password to their Google Apps administrator account. When you set up a Google Apps domain, you have to register an administrator e-mail address, and you have the option to add a second administrator e-mail address. If you forget your admin password, you can automatically have a password reset to the secondary administrator’s email.

If you fail to register the secondary e-mail, you can prove that you own the domain in question by setting up a custom CNAME record. Google tells you what record to set up, and if the CNAME shows up in DNS Google will send a password reset email to any e-mail address that you specify.

Unfortunately, none of this can be done if your Google Apps domain has more than 500 mailboxes. I don’t know why this arbitrary number was selected, but that’s what you have to work with. Enterprise and Education customers have a phone number to call for help, but you are stuck in a catch-22. You can not access Google support for help because you need your support PIN, but the only way to get the PIN is to log on with an administrative account. You can’t write your PIN down because it changes regularly. There is no published way to contact support without your support PIN.

I ended up using another customer’s support PIN to access support so I could find out what the process is to reset a lost admin password. I was provided with this URL: https://support.google.com/a/bin/request.py?contact_type=admin_no_access. This is a form that you can fill out without your support PIN and Google will assist.

Hopefully this post saves somebody a few hours of headaches.

Google Apps – Active Directory Sync

3 Replies

We do a lot of education sector consulting and questions on Google Apps invariably pop up. The pricetag (free for education) is obviously attractive. Running a mail server in-house can be an endless time sink, so it’s not a bad idea to outsource it to Google. They deal with the spammers and storage, all you have to do is provision the accounts. Choosing how to provision is a critical decision for a Google deployment. One of the biggest sources of confusion that I see is directory integration with Google Apps. Most schools already have an existing directory, typically AD or Novell eDirectory. The school admins are interested in getting Google to autoprovision accounts and how to manage user passwords.

Google has a provisioning tool called Google Apps Directory Sync (GADS) used to sync your LDAP directory with Google Apps. GADS runs as a scheduled task on a Windows server inside the client network. The program collects data from an LDAP server, then syncs the results to the Google Apps. I’ve done this with Novell too, but most of my experience is with AD, so I am writing this article from that perspective.

There are many ways to handle the sync of both users and passwords. None of the methods are perfect; as with most things in IT, you have to balance convenience with security.

  1. Sync your AD accounts and passwords directly into Google Apps

    2. You can sync your existing AD accounts and passwords into Google. However, to make that happen you have to jump through Active Directory hoops and store your user passwords in an additional attribute on the user object. There is sample code out there showing you how to intercept password changes on domain controllers, then save them in another format that GADS can read. The passwords has to be either SHA-1, MD5, or plaintext. SHA-1 and MD5 are no longer secure encryption protocols.

    I’m not a big fan of any of this. I don’t want to downgrade the security of my Windows network by using a poorly secured password attribute. Even worse, this method means all of your AD credentials, some of which will be privileged and some of which have VPN access, are floating around in the Google cloud.

  2. Sync your AD accounts with a one-time password

    3. You can sync your existing AD accounts into Google and use another directory attribute to set a one-time password. You might key on EmployeeID or StudentID or something similar. The user uses that password for first login, then changes their password on login. After the initial password is set, the AD password is not connected to the Google password at all. You use the Google password to access Google’s services whether you’re using a web browser or mobile phone. AD password changes have no effect on the Google password.

  3. Use Single Sign-on

    4. This is arguably the most secure, but also the most complex to set up. This requires setting up an IIS server with a public IP and SSL certificate, and installation of Microsoft’s ADFS 2.0 services (there are other ADFS providers, but this is free). This server is hosted on the customer’s network. The nice thing about this is that all authentication happens on your own ADFS server – Google doesn’t have a copy of your AD passwords. Your SAML server is trusted by Google via the use of certificates. The servers pass authentication tokens without actually transmitting passwords. Google offers a detailed diagram of what happens during a SAML exchange.

    The problem here is that you still have a Google password. ADFS only comes into play when checking your GMail via web browser – you still need a Google password to connect from your mobile device using the GMail app. So you still have to manage Google passwords and your users can get confused.

In the end, I think the SSO solution is the best for education. I don’t see much of a need for students to access their school GMail account with their cellphones. Some of the more tech-oriented teachers will want that feature, but you can do it on an as-requested basis. For the most part, you’re providing Google passwords to a subset of your administrative staff. This is a perfectly manageable number of mobile devices to support for the vast majority of districts that I’ve been involved with.

Google Apps in the Enterprise – Not for the Faint of Heart

Leave a reply

November 3, 2012: I wrote an update for this post.

I helped with a massive Google Apps deployment to over 30,000 users at my last job with Fortune 250 RR Donnelley. We were moving away from Lotus Notes, which I was happy to be rid of. However, in retrospect, Notes is a relative joy to manage compared to Google Apps. Although being “in the cloud” is trendy and provides your management with a cool golf course buzzword, supporting Google Apps in the enterprise is nightmarish and should not be taken lightly.

Pluses

  • Email and calendar syncs with multiple devices –  Native apps for Android and Blackberry, and IMAP support for the iFolks.  No need for Blackberry Enterprise Server. Coming from an environment where only upper level management got Blackberries, having my calendar and e-mail on my phone was a huge plus.
  • Multiple editors – Google Docs lets you have multiple users in the same document editing simultaneously. This proved highly useful for many collaborative efforts.
  • Education – Provides a low cost, easy way to provide email accounts and collaboration tools for a constantly changing set of users.

Minuses

  • User Deletion – When you delete a user, it’s 5 days before you can put that user back in. It was an accident? Too bad. That user is without their e-mail account for 5 days.
  • Document Deletion – When a user is deleted, so are all their documents. Seriously. Every document they own is *poof* – gone.
  • Management Delegation – There are no degrees of admin rights – you’re either an admin or you’re not. Although you can do some interesting thing with delegation using Google Organizations, many corporations have a centralized helpdesk. If you want any helpdesk worker to be able to help any employee, the helpdesk worker has to be a full blown administrator over the entire Google Apps domain. This is not a particularly palatable choice when you’re talking about hundreds of outsourced workers.
  • Bandwidth – Your bandwidth costs are going up. WAY up. Using Lotus Notes, a file attachment sent within the company never left the WAN. With GMail, the sender has to upload the attachment to the Internet, and then each user who receives it has to download it over the Internet. Every time people check their email, it’s Internet bandwidth and not WAN bandwidth. That’s thousands of users generating Internet traffic that didn’t exist with Notes
  • Constant Development – Google Apps is continuously changing, and changes are pushed to Production with no warning. Things break overnight and it irritates the hell out of your users, and drives up support costs for IT.
  • No Logs – Logging is nonexistent. There’s no event viewer, no activity log, nothing. You have no idea who is doing what and no way to look it up
  • Extracting Information – You can’t even get a simple list of who your domain’s administrators within the Google GUI. If you want to extract the information, you’ll be writing a script. They have libraries in Java, JavaScript, .NET, PHP, Python, and Objective-C. If you’re a system admin, you’re probably not a programmer, so you’d better brush up on your Python. You’re not likely to make it past the learning curve to be able to use anything else.
  • Emergency support – You can’t get support without your support PIN, and you can’t get that without administrative access to your Google domain. The PIN changes periodically, so you can’t rely on having written it down.  If you’re locked out of the domain, you’re stuck with filling out a form and waiting for e-mail support to get back to you.
  • The apps – Using the apps feels a lot like using Office 1.0. They’re rough, good enough for the very basics but not really ready for primetime. Your accounting department would stage a revolt if you forced them to use Google Spreadsheets instead of Excel
  • Enterprise Integration
    • Passwords – You can use the Google Apps Directory Sync (GADS) tool to automate user provisioning up to Google Apps by syncing your existing LDAP infrastructure with Google. However, passwords are quite a challenge. If you have a way to extract the user’s password out of your LDAP directory, you can push that up to Google – but who wants Google to have a copy of the user’s corporate password? So you’re left with maintaining a separate Google password. Even if you implement Single Sign-On and authenticate users against your own LDAP server, that only applies to access via web browser.  The separate Google password is still used for mobile device access.
    • Single Sign-On – If you decide to go the SSO route, you have to have a secure way to store a user’s e-mail address within your directory structure. With SSO, no user credentials are sent to Google – instead, Google uses a certificate to ask your company’s SSO server to authenticate you. Your SSO server must send the user’s e-mail address back to Google. This directory attribute must be created and secured, otherwise anybody with access to that attribute can impersonate any user. Let me repeat that – *ANY* user in the organization with access to the “email” property in your directory system can use SSO to read *ANY* user’s e-mail. For many enterprises, this means an unacceptable number of non-privileged IT workers have the ability to read anybody’s e-mails. Google does not offer any kind of AD schema update like an Exchange installation would to create a properly secured set of properties for e-mail address, so you are forced to create the properties manually and come up with a set of ACLs to achieve the proper security. This can be extraordinarily tricky in a large enterprise.

While Google will try to sell you Google Apps as a simple solution, neither the implementation nor the ongoing maintenance are simple. The Google resources assigned to the implementation project were simply not up to the task of navigating the complex political and technical landmines of a Fortune 250 corporation. The resources weren’t necessarily at fault – it was Google’s fault for several reasons. The resources assigned were simply too junior with insufficient experience at the enterprise level. They also had no idea how to address many of the enterprise level problems we encountered because they had never had to deal with a corporation the size of RRD. We felt like we were flying by the seat of our pants with little to no direction from Google.

Google Apps a great choice for a small company and possibly for education, but it’s just not ready for the enterprise.