I'll throw out there that I work for JumpCloud, an Identity Management Provider, and we have a credential provider as well for seamless Windows login. We also have a Mac login window so your users have a seamless experience regardless of the OS (our Linux solution doesn't really need one). We've also got LDAP, RADIUS, gsuite, and O365 backends (plus more I'm forgetting I'm sure) and a ton of other niceties. Check us out if you're into that.
We also go beyond this and support MFA on Windows, Mac, Linux login.
Y'all should make a guide for setting up a small environment for a home network. With the homeschooling situation, our kids are suddenly using our various computers a lot, and it'd be really nice to have a simplified situation with one login across all computers. I don't want to run a server locally for it, but my Jumpcloud trial was a bit bewildering for this use case.
Would you mind speaking a little about what you had issues with? It's so hard to get feedback for the users who try us out where we didn't 'just click' for them, and I'd love to hear where some of our pain points are.
There's a pretty overwhelming amount of options to go through. A wizard or simplified console for home networks would be great.
I don't need Radius, GPOs, groups. I just want everyone in the family to be able to use their GSuite account to log in on any of the computers in the house... and it's hard to figure out exactly what I need to turn on/off to do that.
Side note: I'd happily pay a monthly/annual fee for a family version like this. We already do for things like GSuite and 1Password.
I know y'all are free for orgs up to 10 users, and my family is never getting that big (shudder), but a "Jumpcloud for Families" you could easily get me to pay for if it's super easy to use.
I just tried configuring this on a new Windows 10 laptop (Dell XPS 13). I'm by no means an IT expert, but it seems painful to get working.
I had to first setup a local Windows account. Then install Google's GCPW software. After that, I had to make changes in the Registery Editor -- a place I haven't had to visit in many years.
I then had to logout of the local account and then select "Add work account" from the Windows 10 lock screen to login with a Google Account. I setup Windows Hello fingerprint login, however it doesn't seem to allow signing in with this method meaning I need to use a password everytime!
The whole setup process is just too outdated. Does anyone know how to automate all of this?
Meanwhile on Chrome OS, I can just hand a device to someone and they can login with their G Suite account in 30 seconds. No configuration needed.
> The whole setup process is just too outdated. Does anyone know how to automate all of this?
The usual way is to use the Windows unattended installation tools to create an image which has everything included - I'm assuming this is how this is supposed to be used. IT in your organization just puts a prepared image on your computer. That imshr will automatically have everything you need installed including this plugin and its registry changes.
I've scrolled down the install guide and there seems to be also a PS script that sets up the registry keys for you so you can probably do remote unattended install as well.
> After GCPW installation, the device appears in the Admin console Windows device list after the user signs in with their Google Account for the first time.
We use G Suite at work (legacy decision) and it really kills me just how poorly the G Suite product team seems to understand enrollment and authorization workflows.
No, I don't want to allow every device to register itself into the device list. If I'm managing installations of organization-owned devices, then I want to pre-register the device into a device whitelist that I maintain before I allow that device unfettered access to protected resources.
This is right up there with other dumb moves like requiring AWS roles to be added per-user for SAML login and functionally being unable to setup G Suite as an OIDC IdP for Kubernetes because G Suite refuses to expose group membership (or even more importantly, transitive group membership) to service providers.
If Google uses G Suite internally then I have zero idea how they manage to actually get anything done, unless they have a lot of in-house automation that they haven't open-sourced. It doesn't make sense unless they're not eating their own dogfood.
I agree with many of your complaints, this article[1] from Latacora comes to mind. However, a lot of the "good stuff" that fixes some of these problems already exist and are fully implemented in GSuite, they just happen to be locked behind the priciest service tier[2].
I've had many frustrations like these, because if you're on the lower tiers of GSuite you pretty much have to DIY using their API. But, if you choose to bite the bullet and pay up, your life will be way better in many of these aspects.
Also other things about the "GSuite way" just diverge philosophically from the standard IT operation playbooks, if you haven't already, I suggest giving the BeyondCorp paper[3] a read. Most of their IdP-related products build on top of these concepts, rather than plain "directory-management style" ITOps.
> it really kills me just how poorly the G Suite product team seems to understand enrollment and authorization workflows.
> No, I don't want to allow every device to register itself into the device list. If I'm managing installations of organization-owned devices, then I want to pre-register the device into a device whitelist that I maintain before I allow that device unfettered access to protected resources.
you have a best practice, but narrow vision.
the very, very, very large majority of "enterprises" (certainly SMB) do not have an inventory of devices. even if they do, they have to onboard them into the G Suite inventory somehow. just like MDM solutions always have an "open enrollment" method, this is a way to jumpstart that process. by setting a point in time at which open enrollment is allowed, rolling it out, then closing said open enrollment, inventory collection is easily streamlined without needing any IT skill. you could then audit your inventory to make sure there is just 1 device per user. last step, you disable the auto enrollment option.
But possibly not for other Kubernetes deployments. I wonder if this is a business decisions or the consequence of nonpublic technical details.
(Disclosure: I used to work at Google including on GCP, but I have no inside info related to this discussion and haven't worked there in just over 5 years.)
Is that a problem with G Suite? I think all such cases I've heard of have been with the free personal accounts offered to the general public, not the corporate product.
And if random account suspension is something that happens to G Suite accounts, I think the answer is that your IT department's G Suite admins can click the button to un-suspend your account.
Yes, this is happening to me right now on my G Suite: https://twitter.com/ivankozik/status/1254988039467614209 - no warning and no spam on my part. Every account is disabled, all incoming emails bounce, messages to my Google Voice number are /dev/nulled, my YouTube channel does not exist. Requesting account review as the super admin results in the same "please contact another administrator" autoresponse...
This is very strange, but also is your Super admin an everyday user account, or a specific isolated admin account?
Google normally suspends accounts (notification after suspension with no real info) for heavily reported spam, they will suspend a ton of accounts if your domain is sending a ton of spam, even if its not via g-suite directly. This may be the case are you sure your domain is secured?
I don't know how any of my accounts could have been sending spam. I don't send unsolicited email, and I forward messages from those other four accounts to my primary email account, so I hope I would have noticed a spam problem. But because I cannot log in to anything, and didn't get any information or notification from Google, I can't be sure, of course.
I am subscribed to a lot of mailing lists and I wonder if, given my low human outbound volume, whether gmail-generated "bad attachment" bounces could have resulted in this. But that seems unlikely. More likely is someone ran a query and decided I had too many emails or was using too much G Suite storage. I look forward to hearing any information at all from Google!
This might be strange, but it's not unusual. Google is notorious for banning users, and providing no recourse - except getting your story to the front page of course. HN / Reddit / etc front page is the one true customer service channel they have.
I had a "personal" account which Google buggered up because it had the same email address as my GSuite one. I never even signed up for GSuite; they forced the migration sometime after they acquired Postini, and I was a happy customer of the latter (and kept paying Google for some time after the conversion).
I got locked out of the personal account, and IIRC stuck in an edge case that needed me to authenticate on Android (can't remember why - some kind of 2FA thing?). Of course the Android login screen didn't accept those @googletempaccount style addresses.
Chased Google for over a year trying to get this fixed. It was difficult reaching any live humans with powers over Accounts. Even brought it up with some devs at I/O. Lots of sympathy, but nobody interested in championing my issue.
In the end I managed to get the account partially recovered, but there are still some Google products for which my data was never seen again (e.g. lost all starred threads from Google Groups).
After the ordeal, I doubt I would entrust Google to replace my DC. Certainly not as much as a third party whose whole business is this and whose revenue depends on maintaining good customer service. Just hope they don't get bought by the juggernaut.
If the gmail address linked as the recovery address for the first gsuite admin on a domain is suspended for a T&C violation, then the whole gsuite domain will be suspended too automatically.
Its a good reason to never link a gmail address as a recovery address for gsuite - always use another free mail provider.
T&C violations disable an account and any linked recovery addresses (and accounts with the same recovery phone number).
If an account is disabled, all resources associated are disabled and deleted 30 days later.
A GSuite domain is considered a resource 'owned' by the first admin, so if that account is disabled, so are all in the domain. If it is deleted, so is the domain.
If it's the work account, assuming it's through no fault of the user, I would argue that's the best that can happen, since it might make the company think twice about what they are doing in the first place.
I think it'll still be possible to log in with a cached password if you disconnect the computer from the network (that's how it works with domain and Microsoft accounts).
The login provider can emit event log entries which say who logged in and when, and reasons for login failure etc.
Those entries aren't plain text - they are protobufs decoded by a google-provided dll file. If event viewer is open, it won't load that dll, and it will fail to render any event log entries for logins until it is restarted.
A previous debugging hole I fell into once accidentally and barely managed to escape left me with the impression that every event has a "custom" decoder associated; there's no "built-in" event types from the Event Viewer's perspective. There are a handful of very common "custom decoders" that when they break it is an interesting world of madness. In the case of my debugging, one of the decoders installed by the .NET Framework (and used by almost all apps that use the main .NET Event Log libraries) broke and needed repair. It seems like there is a bunch of power in building custom decoders, but I never want to try debugging one again.
Feels like a gentle reminder about corp.com. If some configuration works out of the box in an insecure way, that's what everybody is going to be using.
The lack of effort here seems like such a strategic mistake for Google...
For this to work, it has to be single click, it has to be slick, it has to 'just work', it has to integrate with otp's, security keys, SMS 2 factor, etc.
It should be for both work accounts and home accounts, and Google should have come up with a strategic set of default options. Those options should have included "just log me in with a low privilege account which can browse the web like chromeOS, but still syncs everything like chromeOS".
I put the failure of realising this vision mostly due to lack of inter-department communication within Google. This is a direct (yet years late) response to active directory logins for GSuite, when it should additionally have been shipped for home users and marketed as a "do anything from anywhere any time" thing.
But then they failed to make the "One account all of Google" true of Gmail and Gsuite accounts (there's a long list of things you can do with one account that you cannot do with the other, and this is with Google products and features).
So it doesn't feel suprising that Google lacked the organisational-wide impetus to get this working fully for Windows and Microsoft products and features.
These kinds of projects need to be driven with very strong vision from above. It makes me think of the Yegge rant about platforms at Google, and the mentioning of the Bezos mandate on APIs https://gist.github.com/chitchcock/1281611
His Big Mandate went something along these lines:
1. All teams will henceforth expose their data and functionality through service interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team's data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom protocols -- doesn't matter. Bezos doesn't care.
5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn't do this will be fired.
7. Thank you; have a nice day!
When it comes to making the experience right for Google accounts (of any type, anywhere)... this is what it takes. But this is precisely Yegge's rant, Google lack this.
> But then they failed to make the "One account all of Google" true of Gmail and Gsuite accounts (there's a long list of things you can do with one account that you cannot do with the other, and this is with Google products and features).
The clients of GSuite explicitly do not want any of that - even more, they (and the media and HackerNews) is very vocal that GSuite data should never be merged or touch the GMail account data, ML advertising systems and other non-enterprise data.
Did you consider that perhaps you're not the target market for these kind of features? It is an Enterprise cloud system after all.
(The arbitrary GSuite limitations are pissing me off as well though.)
The OP wasn't clear, but I think I know what they mean.
Years ago they offered Google Apps For Your Domain (GAFYD) - this was a normal Google account, but with your domain on it. I had one, probably for around 15 years or so, as did many other adopters and fanboys.
GSuite came around, paid, and the GAFYD stuff became free GSuite account. This is where the problems started - we didn't want GSuite, we wanted a Google account on our domain with the same services. Hell, I didn't even mind paying GSuite prices, but what I did mind was services didn't work.
So a few months ago I spent 3 days moving stuff from my GAFYD account to a normal Google one. Plenty of stuff is lost - photo metadata and free Pixel storage, Assistant functionality, tonnes of these things. All could have been avoided had Google bothered to write a conversion for this, but they didn't bother as usual.
So, yeah, your GSuite clients may not want that - understood. However some of us were grandfathered into the GSuite limitations without a route to getting back out.
Part of it has to do with the different data protection regulations and privacy policies between consumer and business Google accounts. Since very few enterprise customers use consumer smart home products, Google doesn’t want to make a special version that respects deletion policies and legal holds.
I see this comment all the time. Besides my bias against mobile, can HN add a blockquote syntax or fix it so mobile users have feature parity with desktop users? Is there a reason why this hasn't been done yet?
Most absurd missing feature ever. I tried to get some support for the feature request a while ago but got no attention [0]. I feel like every day I bump into this issue at least once, and there's always someone saying "don't use code formatting for quotes".
My next step was going to be a Twitter bot that tweets when someone posts a quote with long lines in code format on HN. Haven't gotten around to it yet.
From my limited perspective, Google struggles with top-down commandments from leadership, of which the biggest one was Google+. Look how that turned out..
The authentication provider runs as a highly trusted account, it can do anything it likes.
The only tricky bit would be not opening massive security holes. After all, a regular windows box you can't do anything at all with without a password. With my proposed solution, you'd be able to log in and browse the web with just any old random gmail password. Thats a massive increase in attack surface - now any buggy printer driver or router web interface is suddenly open to attack by anyone with access to the screen and keyboard.
Authentication providers are a huge pain for modern software security unfortunately since updates mandate that the system has to be restarted (they're only loaded at boot).
Seems like this would be useful to organizations who use G suite for their accounts &authentication. That way each user can sign into their work machine using their Google account, instead of having a separate username/password.
I'm not OP but I can likely explain. In the late 90's Novell Netware 4 and above had a client package which replaced the Windows login with their own GINA, so users could log in to Windows client machines using their Netware credentials.
Let's hope Microsoft can refrain from the same dirty tactics they used back in the nineties.
I was a junior sysadmin/desktop support back then. Every single software update for the Microsoft Netware Client (which I think sucked on purpose) always caused problems for the Novell one! It was a real cat and mouse release cycle.
My memory, and it's been a while, was that at least partially related to some interop tricks that MS played to make Netware's software work less well in the Windows world. , although I'm sure part of it was also down to Novell finding it challenging to adapt.
I thought that was about WordPerfect etc rather than NetWare.
Totally agree that Microsoft did some bad stuff, I just don’t remember there being any malign attempts to disrupt NetWare integration.
NetWare was the main player in PC networking at the time, so arguably it would not have been a good strategy.
It’s absolutely true that the NDS integration was an issue, but my memory is that this was a quality/competency issue on both sides, and not due to a lack of cooperation.
Authentication on Windows using FreeIPA is already possible although not recommended by the FreeIPA project. There are several guides for doing so a Google search away.
The FreeIPA project recommended solution is to deploy Active Directory either via a Windows server or Samba4 and then create a cross realm trust between AD and FreeIPA.
Yeah, I've pointed Windows directly at an MIT KRB5 KDC several times in the past, but it's not reliable enough for real use.
And I don't want to have to pay for Windows Server just to authenticate on a couple of Windows machines. Plus is it even safe to put AD DS on the Internet?
I have lost access to one of emails because I've bulk deleted my old emails from my Gmail UI. Now I cannot recover my Gmail account. It asks me few questions and then says that I'm not the owner of my account.
This looks like a small tech demo, which Chrome OS has been adding features to make it suitable for general purpose development use by Google engineers for years now.
Yes, not unlike Apple and Microsoft but for business users of Google suite, this makes the need to sign up to any Microsoft cloud services less of a necessity.
It seems the direction Google, Apple and Microsoft are all heading in is to own authentication and control access to our computers both at work and home.
Third party authentication technology has been around on Windows in one form or another for decades, but this is interesting because it's cloud based authentication that doesn't rely on corporate infrastructure.
It would be really nice if Google releasing this is a catalyst for an Open Source project doing something similar.
Chromebooks, Windows S (and RT before it), notarization of apps on MacOs could be helpful in an Enterprise environment to prevent malware, this is at the expense of freedom of choice.
I worry that the PC era is ending and we're drifting towards a future market more like consoles and mainframes where you never really own the platform that you paid for.
> Chromebooks, Windows S (and RT before it), notarization of apps on MacOs could be helpful in an Enterprise environment to prevent malware, this is at the expense of freedom of choice.
I think the opposite is true: these are useful in a home environment, for the vast majority of non IT expert users. In the enterprise, there have always been other mechanisms for preventing malware, mainly in the forum of not giving users full admin rights on company laptops, PCs etc.
Even as a software engineer, I don't always feel fully knowledgeable on how to run a secure system. I can absolutely assure you that my grandma is not qualified to act as a sysadmin on her own PC. So while I dislike the idea of not having the option of taking full control of your system, I nevertheless think that the vast majority of users are better off not using that option. And when I say vast majority, I don't think it's like 80%,but much closer to 99.9%, including most programmers and enterprise users.
I totally agree with you that the secure by default / sandboxes for application approach is useful for consumers and developers too.
My point is that when this is wrapped up with a closed software distribution platform (Windows Store / App Store) or with a Surveillance Capitalism business model that relies on monetisation of user data there is a problem for the consumer.
The PC accidentally contributed to breaking the control IBM had over the market.
Antitrust investigations into IBM and later Microsoft are also key to the freedom we’ve had. The worry is that we’ve forgotten how bad it was and we’re potentially headed for a cartel like control of our computers.
Can I use this self hosted? I don't want Google to have control over my personal logins. I have a bunch of computers at home for the family to use and a NAS system for data. All I lack to make it work well is central login.
Openldap looks like my best bet, but I haven't figured out the obtuse configuration syntax.
We also go beyond this and support MFA on Windows, Mac, Linux login.
Orgs with less than 10 users are free.
https://jumpcloud.com/