39 comments

[ 4.6 ms ] story [ 87.3 ms ] thread
Google's APIs make it easy to audit your groups, and if you don't want to write your own program to do it you can use the GAM command line tool. https://github.com/jay0lee/GAM/wiki
GAM is awesome for this. We've also had good luck with Google Apps Scripts. The advantage is that it makes it marginally easier to set up credentials: it does so behind the scenes so you never have creds with admin permissions hit disk. The disadvantage is you're now editing an old-ish version of JavaScript in a janky browser editor that saves to some weird bespoke JSON format. You can also use clasp (https://github.com/google/clasp) to edit these files from your favorite editor but now you own a Software Engineering Project.

Here's roughly what that looks like to get all the mentioned info out:

    function getGroups(domain) {
       var groups = [], pageToken, page;
       do {
           page = AdminDirectory.Groups.list({
               domain: domain,
               maxResults: 100,
               pageToken: pageToken
           });
    
           if (page.groups && page.groups.length > 0) {
               groups = groups.concat(page.groups);
           }
           pageToken = page.nextPageToken;
    
       } while (pageToken);
       return groups;
    }
    
    function getGroupPerms(groups) {
     var perms = [];
     for (var i = 0; i < groups.length; i++) {
       perms.push(AdminGroupsSettings.Groups.get(groups[i].email));
     }
     return perms;
    }
Disclaimer: I'm the author of the linked blog post.
Apps Script has a lot of potential when it comes to Groups (and other resources a company has to manage). As you said, clasp is an alternative to the web UI. What’s an ideal platform you’d like to see for easily executing code on to work with groups (Apps Script, Cloud Functions, or other)?
I mean, I'm me, so I want to write Clojure. I haven't tried ClojureScript -> clasp to see if I can use ClojureScript. Does Google Apps Script document exactly what the runtime is? It looks like Rhino from some of the failure modes, but I don't know the exact modern JS features it supports.

The huge benefit to GAS IMO is that creds never hit my disk.

Does it still provide a list of user access rights for single files and directories on Team Drives?
FWIW I haven't found a way to get access to unshared files until after you remove access from someone. The Admin SDK only provides usage reports. The Drive SDK allows you to get files et cetera, but only for the current user (!) -- so that doesn't help for anything you don't have access to, which I'm guessing from the phrasing of your question you already knew :)

I'm guessing this is a feature? As in Google wants it to be easy to just create local sheets/docs/... without them being shared with your org by default and would rather worry about giving admins better features to manage and audit sharing than give admins access to every document under the sun :)

This is an LVH post, but the basic idea is: if you're using GSuite as a source of truth for identity in your company (lots of people do this, and it's not a bad idea), you have to be aware of the dual duty Google Groups does. People set up Groups to manage communications, like Slack channels, but also to manage authorizations ("can run this application").

It is a little bit crazy that the authorization construct in Google Groups has an "allow the Internet to join" option. I don't think you'll find that particular button anywhere in Okta or OneLogin.

(comment deleted)
This stems from the origin of Google Groups as the OP mentioned. It’s definitely not ideal but we are actively working on making groups more suitable for the various enterprise/business scenarios they are being used for.

(I’m a PM @ Google working on some of these efforts)

I'd be happy if I could just setup an email distro list in google domains, or in the G Suite admin, instead of having to setup groups... I swear it took me half an hour to figure out why my dev@ list wasn't getting email from outside the domain.
Sounds like the issue might have been confusion with the UI. groups.google.com has a lot of settings and it can be really confusing to know how to set up a group that functions in a particular way (i.e. receive email from outside the domain). G Suite admin has less settings but from what I've heard from customers it doesn't expose enough of them so they end up having to go to groups.google.com anyway.

I think some of the updates we're working on will help.

That would be nice... I mean, no offense, but for my needs, I'd just assume not use groups at all, and just have the option for a distribution list.
I wrote this, underlying work is collaboration with the other Latacora folks, happy to answer questions :)
Thanks for writing this up. I'm a PM working on many of the issues you've raised. Happy to chat via email (jaisen@) or offline as well.
Out of curiosity, are the "example scenarios" things you've actually seen in the wild?
I can't provide details re: where/when/who of course, but all of these are functionally equivalent to things that have happened. Reality tends to be a bit messier than these scenarios but not in a way that fundamentally changes anything.
I'm a PM at Google working on groups functionality for enterprise customers. We're working on ways to make groups easier to manage and more secure.

Happy to answer questions related to this post or other gripes you may have with Google Groups.

Cool! Can you elaborate on what easier to manage and more secure might look like?
Easier to manage and more secure fall generally end up falling into the same bucket.

We're working on ways to ensure that a group contains the people you expect it to have. Sounds like a no-brainer but this is one of the most common pain points we hear from customers.

Secondly, there's a slew of group settings exposed through groups.google.com which are not exposed elsewhere (Admin console, APIs). We're working on improving that which will help users know what a group's settings are across all the groups surfaces (groups.google.com, Admin console, APIs).

I was going to bring up that I wish that groups was more like MS teams, but that leads me into Google Hangouts (Chat, Meet, Allo, Duo, Messenger, Voice, stray dogs everywhere)... Frankly, I loved Hangouts right after the Google Voice integration happened... then they broke it up and made it horrible...

I think you (google) should drop them all, bring back "Google Chat" as one named umbrella, get all of it working in one place/system, and do an "update" that points them all to the new app. Having 147 disconnected apps to communicate outright sucks horribly.

We are about to give up on Groups. It is like a stray dog for google. The filtering is hit of miss with groups. Our internal help desk gets 1-2 google group issues / week from our user-base of 70 employees.
Feel free to reach out to me via email (jaisen@). I imagine you're hitting the same pain points that many of the customers I've talked to over the last few months are. Hopefully what we're working on will address them and it's not too late.

Stray dog is an accurate description. Groups has not received the updates needed for use in enterprises but it's a current focus area for us (for reasons you mentioned).

One thing that's sort of wonky (and possibly it's something that just got set up in a weird way by an admin here at some point, I'm not remotely a G Suite expert or admin) is connecting Groups and service accounts, or having a service account for a group. For example having support@example.com be a group, but also having a support@example.com service account.

(Currently we have a support@ service account that sometimes sends automated emails and which forwards incoming things to a group where everyone in the group has been granted "send as support@," since the group side is basically acting as a collab support inbox. I think the whole thing could possibly be a "shared inbox" type group were there just a way to have a service account matching the group email. And of course there may some benefit to it being set up how it is that I'm missing, or a way to do so currently that got overlooked somehow.)

When you say service account are you talking about one of these?

https://cloud.google.com/iam/docs/understanding-service-acco...

I think so? I'll see if I can double check.

(My understanding is that it's a kind of psuedo-user account, and that it's being used because there's no "virtual user" to "act as the group" when it comes to automated emails and tasks or something along those lines. I wouldn't be surprised if it's more complicated and they created an actual domain user that belongs to no-one and then give the service account permission to act as it or something along those lines.)

Whatever is actually happening isn't supper important though - I think somebody over here just did whatever they thought the minimum effort thing to do was without thinking or looking into it much.

I'm fairly certain each group having an admin panel having a page that allows "app passwords" or Oauth2-integrations to be set up for its address/account by the group owner/admins would cover at least 90% whatever we've got going.

(And once again, it is completely possible that something like that can already happen and just isn't obvious to anybody over here.)

I'm not sure how much this stumbles into the woes of Google accounts in general, but it's really hard to deal with Groups if Gmail isn't your mail address. When I left Gmail, I had to invent a new alias to get subscribed to a group because it affiliated my main address with my Google account and so wouldn't let me subscribe with it. But if I go to Groups and interact with it there, it uses my Gmail address, which I don't think is changeable.

So I have inbox@mydomain which Google knows is affiliated with my Google account, google@mydomain which had to be subscribed to the list for me to get mail at my actual email address, and my Gmail address, which Groups uses when I post from the web UI.

Help.

Sidebar: I don't say a ton of nice things about Google, but absolute kudos for you just dropping in here and asking for feedback. Gold star, I'd really like to see more of this.

So you had a google account @yourdomain.com as a Google (and GMail?) account but later left GMail? Did you delete your Google account or just disassociate it with GMail?

I haven’t heard of this but I can see how it could happen depending on the exact state of your @yourdomain.com Google account. Sounds messy though and maybe we can sort it out.

My email address at my own domain (now my primary address) is listed as a secondary address on my Google/Gmail account, I believe. Last I checked though, I wasn't able to have Groups send list emails to or from that address though.

Using another alias at my domain was a method to bypass that, as it isn't connected to the Google account at all. (But of course, it also means my real email and my Gmail each get a copy of list emails.)

Google Groups is the pain point of using GSuite. It's not HIPAA compliant, so only about a third of the company can use groups and everyone else uses workarounds. Security controls as mentioned in the article. Really I just want aliases, not aliases and forums combined into one thing. Glad to hear that Groups is being worked on. I've been seriously considering switching to office 365 primarily because of groups
Can you expand on what HIPAA compliance you’re looking for? HIPPA compliance is something that’s come up but not something I’ve dove into understanding yet.

You can add an alias to a group today but perhaps you’re talking about something else?

When looking at enterprise usage, groups aren’t always a mailing list or forum. We are working to decouple a lot of what is baked into a Google Group today.

I'd be fine with just an alias to a group of emails. A use case is that a customer service rep finds out that there is an issues with a patient's data. They can't forward a request to a business operations team to look into the issue or to the engineering support team. Just having an alias for a team that we could email would be a big win
Agreed... I'd love that as well... to be able to have outside users email dev@mydomain, I had to setup a group, allow posting from the internet, etc... (it took a while for me to figure out, as the permissions are strewn across the gsuite admin, and in a few places in the groups admin, when all I wanted was a distribution list that anyone could send to.
Even Googlers are perplexed when it comes to what certain group settings do and where you go to change them. We're working on improving that.

Do you primarily use groups.google.com, admin.google.com or the AdminSDK APIs?

I mainly use the admin console (and that's where I would prefer the controls to be). Right now to update group permissions I use the admin console to go into the google groups console and then update the permissions there (as far as I know, there's no way to update google group permissions from the admin console).
Personally, I'd prefer it in the admin.google.com area. Having to dig in felt painful... TBH, I'd love it if there were an option in google domains' mail, the mail forward option is great, if I could add multiple people, even better.
Would nesting groups meet your needs?

For example...

  service_requests@ (group)
    -> operations@ (group)
        -> user1@
    -> eng-support@ (group)
        -> user2@
Then sending an email to service_requests@ would send the email to both user1@ and user2@.
So I don't even need that much (although I do use nesting groups for other things). The problem is that while Gmail is hipaa-compliant, groups is not. HIPAA considers any personal health information INCLUDING account ids, names, etc to be PHI. Since it's quite easy to accidentally include any of this information, we can't give operations or eng-support a group (or even customer service. To workaround this we have individual email accounts for customer service with shared credentials, with personnel taking turns to log in and triage. Super-ugly)

So right now what we have looks like ``` customerservice_for_client1@ (user account with shared credentials) -> user1@ -> user2@ -> user3@ -> user4@ ```

That groups isn't hipaa compliant, feels inane, especially since email is hipaa-compliant. There's obviously something that prevents it (probably the ease of making records public).

If you'd prefer to get on a call or meet in NYC let me know.

It requires JavaScript enabled to read text...
Google has an excellent track record closing services, but this one is an outlier. No JS fallback, difficult to scrape, par google, par.