Google Credential Provider for Windows
tools.google.com
tools.google.com
We also go beyond this and support MFA on Windows, Mac, Linux login.
Orgs with less than 10 users are free.
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 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 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.
Missing windows hello, so I presume other smart logins like cards is going to make this a non-starter for a lot of orgs.
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'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.
[1] https://latacora.micro.blog/gripes-with-google/
> I want to pre-register the device into a device whitelist that I maintain before I allow that device unfettered access to protected resources.
> 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.
https://support.google.com/a/answer/7543044?visit_id=6372369...
(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.)
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.
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!
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.
https://old.reddit.com/r/google/comments/8l231x/google_banne...
Its a good reason to never link a gmail address as a recovery address for gsuite - always use another free mail provider.
Also, what if the recovery address is another g suite account in a separate domain?
I personally never link or login with my personnal accounts on work devices, nor do I use work accounts on personal devices.
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.
Well, I guess you can't log in to your own Windows computer. A brave new world as it is.
It was a nice coincidence that someone gave me a Gmail invitation around that date.
However, I had been burned once, and now I have my own domain for the important emails, and that Gmail account is used for things that can be spam.
Lesson: Any huge provider can suspend accounts at will and there's nothing you can do about it.
Almost like in "looks photoshopped" meme
To help ensure unauthorized access to the device, you need to configure a registry key to restrict device sign-ins to accounts in specific domains.
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.
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!
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.)
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.
I can't use a google home mini in the office because I can't add other gsuite accounts like a family can. That's so arbitrary.
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.
don't you think?
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.
It allows logging into the device using your Google Account... and? How does that affect usage in any way? What changes?
This seems to make it much simpler for IT to handle.
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.
However in the case of the Windows NT NetWare client I don’t think this happened.
I think one of the variations on Hanlons razor is a more likely explanation.
“You have attributed conditions to villainy that simply result from stupidity”
The really worrying thing is that all the major players seem to have the same strategy at the moment. That is to own and control the platform.
https://www.geek.com/law/microsoft-settles-novell-case-for-u...
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.
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.
From that the settlement was around NDS for NT
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.
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?
This site was failing to render correctly for me on Chrome for OSX.
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.
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.
Openldap looks like my best bet, but I haven't figured out the obtuse configuration syntax.
https://github.com/chromium/chromium/tree/master/chrome/cred...