Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Login with user from a non-trusted domain
#1
Hi Smile

I found a couple posts related to this already. With some info around technical limitations, but asking again since they were old/in german.

Is there any plans to enable login/authentication from a domain\username account that is not in a trusted domain for your computer?

We have a secured domain that we will never be allowed to setup a trust to from our personal computers domain.
Ideally we want to use the secured domain as the place for the ASG-RD users/access groups.

We have that covered when starting ASG-RD from a computer/VDI etc that is located in the secure domain.
But since you can only choose fully trusted domains within the ASG-RD client to login we are unable to authenticate/connect to our profile from outside the secure domain.

Any way to get around this / any plans on enabling windows authentication without requiring full trust with that domain?
Typically were you would type the user name as "domain\username"?
Or is this done for security reasons and not technical limitations?
Reply
#2
I can add this again on the feature list - and then we have to check if it would be possible to ensure this - at the moment it is not possible...
Regards/Gruss
Oliver
Reply
#3
Thanks for the update Smile Guess we will look into some alternative ways until it might come as a feature, worst case 2 different profiles.
Reply
#4
Hi Oliver Smile

Any updated on the status on this enhancement request?
Or at least if it were to be implemented, any chance for it to be happening this year or is that very unlikely?

Asking as it will lead to some discussions in some design work we are doing.
Reply
#5
I can't tell you at the moment when this will be checked again - we have several extensions that we like to implement - so not before end of Q3 - but I can not promise that
Regards/Gruss
Oliver
Reply
#6
Ok, thanks for the reply Smile
Reply
#7
Hi

Any updates on this one? Smile
Asking as we are in the middle of a large change regarding access management. 
Authentications for tools like ASG-RD need to be done by a special management domain account (and for security reasons, this domain is not trusted with the client domain).

Conclusion: if no option to manually enter the domain credentials will come as a feature if might require us to look for a different software :/
Reply
#8
Still not working on this - why you don't use username/pwd instead of that? Makes no difference because you can't use integrated auth - and you need to configure your domains inside ASG-RD - so it should be only the login...
Regards/Gruss
Oliver
Reply
#9
(10-10-2017, 09:08 AM)DevOma Wrote: Still not working on this - why you don't use username/pwd instead of that? Makes no difference because you can't use integrated auth - and you need to configure your domains inside ASG-RD - so it should be only the login...

Because with that you are thinking internal username/pwd in ASG-RD right? As far as I have seen you cannot create a non trusted domain inside ASG-RD.
The thing with the management domain account is that it will give tons of access groups in terms of what you will be allowed to see. In tools like ASG-RD, Monitoring tools, Tickets systems, CMDB etc etc.

So the idea is to build the security in ASG-RD around these AD groups.
Ex if you have access to see "Citrix servers" based on the AD group, you will see the Citrix servers in ASG-RD etc. And possibly get other stuff like credentials, shared favorites etc unlocked by that.

We have ten thousands of objects and working as a service provider for hundreds of customers. That is why we want to have all our tools give access based on the same management domain access groups. Instead of manually building the same logic with other access groups in the different tools, as that will take tons of time Smile
Reply
#10
Can't you set up a one way trust ?
We do it like that, then we can use or "desktop AD" groups for autentication towards client connections and you still can restrict access towards you secured domain.
Reply
#11
(16-10-2017, 03:38 PM)Jorgen Wrote: Can't you set up a one way trust ?
We do it like that, then we can use or "desktop AD" groups for autentication towards client connections and you still can restrict access towards you secured domain.

I can check with the security team, but I have already asked regarding these things in the past.
Some customers are extremely strict on what you can are allowed to see (bank/finance sector etc). So pretty much everything regarding this secure management domain are not suppose to be connected to the office domain in any possible way to prevent external visibility.

We are using a lot of different tools with AD authentication.
But ASG-RD is the only tool that demands your client to be in the same domain/have trust towards the authentication domain for the tool/application.

And yeah, we probably are a bit of a special case. But still I can't see why the tool does not allow you to manually enter domain info/connect to the domain with LDAP or similar as normal.
Reply
#12
Smile 
Hi Smile

Checking this again.
Any plans now to make it possible to login to ASG-RD from a non-trusted domain account from the client side?
If not I guess we need to look for an alternative tool for the company now.
Reply
#13
It is implemented in the latest version (or on before)!
Regards/Gruss
Oliver
Reply
#14
(31-08-2018, 02:19 PM)DevOma Wrote: It is implemented in the latest version (or on before)!

Awesome :D
Thanks Smile Haven't been able to update to the last patches yet, but then I have to do that Smile   

Have a great weekend Wink
Reply
#15
I am trying to get the ans that do i login from a non-trusted domain if yes not then whats the solution
Reply
#16
I do not understand your question
Regards/Gruss
Oliver
Reply
#17
We updated at least, and it worked good in the latest version  Smile The main issue now if that is still requires LDAP from the Client to the non-trusted domain.
I'm working on getting some read only DCs to support that.

But ideally we do not want LDAP opened into the security domain from the client subnet.
Any chance that we can see something in the future that only required LDAP from the DB side? 
Cause that is the most common approach for tools.

That you have an application server/DB that does the LDAP connection. And not all the client installations.
Reply
#18
Ok now I understand - I have to think about your request - I will add a ToDo for that
Regards/Gruss
Oliver
Reply
#19
(27-09-2018, 08:52 AM)DevOma Wrote: Ok now I understand - I have to think about your request - I will add a ToDo for that

Great Smile
Btw the "I am trying to get the ans that do i login from a non-trusted domain if yes not then whats the solution" question that you (and I) did not understand came from someone else than me Smile
Reply




Users browsing this thread: 1 Guest(s)