Since everyone seems to have personal outlook, hotmail, and gmail accounts, is it possible to prevent people from using non-company email accounts when logging into Google, Bing, and other websites on company computers and devices?

Or, is it possible to prevent internet access completely without an approved domain e-mail address?

  • I want to prevent users from accessing websites with non-company email accounts. The users need to be able to access sites like google, bing and even facebook, but I want to only allow our company emails to be used to log in to those sites while the user is connected to our domain. Is this even possible?
    – GreyLine
    Nov 2 at 19:14
  • You would have to implement some sort of TLS MITM device to do that, since you have no way of seeing what data is being sent to those services otherwise. I suggest you read some papers on the security history of those devices and the security vulnerabilities they tend to introduce, and also take note that they are well known to break a variety of software, including Git.
    – bk2204
    Nov 4 at 0:00

Yes, this is possible. You implement a Cloud Access Security Broker (CASB). This basically means that you block all those services except through this service. Then you authorise what accounts are permitted to log into the services, like your company accounts.

CASB acts as an authentication wrapper so you have this level of control.

  • Can it cover all? For example what if I've opened a web page that lets you login GMail?
    – kelalaka
    Nov 3 at 20:00
  • If all traffic flows through it, sure. If you use some kind of a proxy, then maybe no. As with anything, there is no 100% solution that will cover every conceivable method to bypass it. But it does cover the vast majority of situations described in the use case.
    – schroeder
    Nov 4 at 8:16

To a first approximation, what you're asking for is impossible. There's nothing special about Microsoft/Google/etc. accounts; they're just web pages where users POST some credentials (as text wrapped with TLS) and get back a token. You're asking for a tool that can prevent users from sending certain kinds of web requests to certain servers unless the requests contain certain strings. Put like that, hopefully you see how unlikely this is as an actual feature. You're trying to put restrictions on how web browsers are used, at a level where no web browser is designed to support such restrictions.

With that said, while actual total prevention is probably impossible, there are things you can do to make it much less likely to happen by accident or without lots of effort on the user's part. They will probably still be able to get around it if they really want to but it'll be clearly working around a restriction.

Deep packet inspection at the egress proxy

If your company uses a corporate proxy and prevents outbound connections that don't go through the proxy, and if that proxy supports TLS interception (using a private CA certificate installed on all corporate devices), then filtering credentials used is possible (at least for devices connecting to the Internet through the corporate network; you can't do anything about a device connecting through some other network e.g. outside the office or on a guest network at the office or through a personal WiFi hotspot). You would need to do the following:

  1. Identify the sites you care about (e.g. accounts.google.com, login.live.com, etc.)
  2. Set up interception for those sites at the proxy (if you already support interception for all sites, set up custom rules for these ones)
  3. On the relevant sites, examine the request to see if it's an actual login request (as opposed to e.g. the GET request for the page itself). Note that there will sometimes be a multi-step login process which may involve multiple requests; you specifically want the one where the email address is specified.
  4. Parse the email address out of the request (note that different sites may use different request formats e.g. JSON, XML, etc.)
  5. If the email address is allowed, forward it to the server as usual. If it is not allows (is a non-company-domain address), have the proxy respond to the request directly with an error.

I believe this approach is what at least some "Cloud Access Security Broker" products do.

Note that this will not necessarily fix situations where somebody has already logged in and still has a live session. Additionally, this kind of deep packet inspection will increase load on your proxy; make sure it can handle it. Finally, make sure you aren't inadvertently logging, or otherwise exposing, user credentials to anybody who isn't authorized to see them (in particular, you probably want to ensure passwords are masked out of any request logging you do).

Remember that any device connected to the Internet but not through the corporate proxy (e.g. through an employee's personal WiFi hotspot, or home Internet in the case of laptops/mobiles) will not be checked.

Client-side extension

An alternative that works without a corporate proxy, but is much easier for a user to bypass even from the office, is to create a custom browser extension (or install a user script for an existing browser extension such as TamperMonkey). The extension/script would be active on the same set of identified login pages as above, and could work either at the DOM level (acting as a normal script on the page) or at the request level (similar to how e.g. ad blocking works). The script would check the email address submitted by the user to ensure it uses the company domain, and prevent the user from submitting the login request (and present an error message) if it doesn't.

Extensions and scripts are much easier to remove or disable - typically this doesn't require admin privileges, and it's very hard to prevent tampering with the extension configuration or scripts - but it may prevent non-technical users from bypassing the restriction, or at least make it obvious that they're bypassing something set up by IT and therefore violating company policy.

  • This is a confusing answer. You state that it's not possible and then go on to explain how to do it.
    – Blake
    Nov 3 at 12:08
  • @Blake It's not possible in most environments or against any moderately dedicated user/attacker who e.g. brings in a WiFi hotspot. Under specific conditions, you can make it more trouble than it's worth for most users (and make it clear that they're doing something "wrong" though honestly circumventing IT just feels like the cost of getting work done, at lots of companies). I'll edit the answer to make that distinction clearer though.
    – CBHacking
    Nov 3 at 17:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.