Restrict Registration Based On Domain


On the customer portal it seems like anyone can register no matter what domain they are apart of. Is there way to only allow people to register if they say only have the domain @example.com or whatever I wanted. Thanks.


This topic has been closed for comments

35 replies

That's a pretty valid point you have raised Kyle. I have put this forward to the team and this has been added to the roadmap. Thanks and my apologies for the delay in replying to you. 

I think that the best solution is have a"Register Request" state for a new user, otherwise every user can register and see everything (Solutions, Tickets..ecc..)

I think either of these solutions would be ideal.  We're using Freshdesk internally and I would love to be able to allow our users to sign-up, but only to our domain.

Zendesk offer this i'm sure FreshService should

Requester registration should also be blocked by domain in the case of an email forward that gets automatically converted into a ticket. The email forwarded could have an unwanted external domain listed in the head of the email, sending a requester registration email to that external user in addition to the actual requesting user within the domain.

 

Bump.


I too "am much disappoint" since other in-house OAuth tools allow us to restrict to a domain. The "workaround", which is to disable OAuth login (read: "Log in with Google" button), and have people use the app drawer, is rather lame.


I'm very impressed with the Freshservice tool though and can only cross my fingers that this doesn't sit on the roadmap for another six months...


Hey Dave


Sorry for the trouble and we really don't want to disappoint our customers


We can restrict such domain based Logins using some IDP - Identity Providers like OneLogin or OKTA, which can tie up with your Domains and set such restrictions


I will see if there are such options and will surely keep you updated, but you could also check it and update us


regards
Vijay

Thanks Vijay but I prefer to keep it lean in the sense that, since we're a Google Apps organization, I'd abhor tacking on additional SSO solutions when Google Apps already affords this capability through OAuth.


I'm probably not alone when I say that this is the only method I'd consider.

  1. I am currently piloting FreshDesk, and this topic is big for me. We have students on a separate google email domain from our staff, but it looks like student can "login with google" for freshdesk just as easily as staff. I do not want the students to be able to login using their google credentials. 


I guess I could just block our freshdesk domain in the web filter... That is an option if Freshdesk support is unable to filter "login with google"  by domain.

Just wondering if this ever became a thing.  I'm currently trialing Fresh Service and this was the very first option I went looking for, but haven't seen a solution within the admin panel yet.

I would like to restrict access to users within my domain, and while I see that there is a signup mechanism available, it would be very much preferable if I could simply permit the domain as a whole.

This seems like a must-have feature, for me.

Currently there is not the option top restrict domains. So we had to setup our web filter to block student access to freshdesk. Even though that does not help us when they get home. Regardless we have not had any problems. Very happy with the product. 

The fact that this hasn't been addressed after over a year is pretty bad. This is the ABCs of in-house IT Help Desk. Please implement this ASAP.

This is needed to prevent any clear spam.

 

Requester registration should also be blocked by domain in the case of an email forward that gets automatically converted into a ticket. The email forwarded could have an unwanted external domain listed in the head of the email, sending a requester registration email to that external user in addition to the actual requesting user within the domain.

Douglas - this exact thing just happened to us.  I see that there is an IP Whitelisting option available now that I don't think was there before, but I don't think that setting would prevent a notification email from going out.  Until this gets addressed unfortunately I've had to turn off registration emails. 


Any word FreshService?

Yeah, seriiously, the silent treatment is getting old.


Freshservice devs, I have googled this for you.

A year and two pages worth of comments, and you've yet to make this change? We just picked up OAuth for our apps, and it was one of the first things we figured out. Common.

Hi all,


I understand there has been a delay (a lot of) in addressing this (and a couple of other) issue in the forums. In fact, there is a thread about this in the Freshservice User Groups on LinkedIn. Before I being explaining, please accept my apologies for this delay in replying to this thread.


We have been creating some new features (Bomgar integration, new self service portal, Box integration, improvements in automation, service catalog, mobile apps etc) in the last year - our engineers and product guys really had to work hard to make sure that we are good enough to compete with the older (and more established) service desk solutions out there. And trust me, we are almost there. We are seeing enterprises shift to Freshservice from the established players like ServiceNow, Cherwell, HP etc.


We are scaling up real fast - we launched in Jan 2014 and currently 4500+ enterprises are using Freshservice for ITSM. We are scaling up engineering and support to meet the exponential demand that we are seeing.


Please bear with us, we are doing everything we can to make sure we meet our customers' requests. There are certain features that we don't consider (trust me, we want to develop every feature request that comes our way; we really want to). We make sure we communicate the same.


But please don't worry, this feature is definitely there in the plan - we understand the importance of this particular feature. I will ask someone from product to answer to this thread ASAP so that you can get a better perspective.


Thanks a lot and once again, my apologies.


Narain

After another six months, is there any update?

I agree, I understand that lots of "features and new integrations" have been made, but serioulsy, what we are asking for here is BASIC. This feature is a must, and should be ahead of some of those features you mentioned

I'm giving this software a try. The feature list holds so much promise, but now the very first thing I would want from a cloud-based application: to lock the portal down to my organization, is not even supported and backlogged for two years? This is very confusing.

 

I was able to restrict portal access to organizational users by implementing single sign-on and simply disabling the ability for requesters to sign up from the portal. Authentication is performed exclusively by my identity provider. Users that exist within my identity provider are automatically provisioned in Freshservice when logging in for the first time.
If you are using Google Apps Authentication, you can log in from any Google Apps domain, which is silly.

You can restrict access as John describes, then export your user list from the Google console, and import your users into freshservice, then manually provision new users.

So, I'm testing JIRA Service Desk instead. That took all of a few seconds to link my Google Apps domain.

I too would like to see that feature implemented, as we are a company in IT security and would like to restrict login only to selected domains. Thanks.

I was excited at the prospect of using an ITIL based tool, but the inability of Fresh Service to answer this basic issue has led us to deploy JIRA instead. :(

Hello,


Still no update on this serious issue ?

I cannot deploy this solution in my domain if there is no restriction...