Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Alternative Domain credentials
#1
Hi everyone,

I've used Tools\Settings to specify under Environmnet alternative Domains that our Forest/Domain don't trust using an account that can read their AD/OU schema. No problems, it works fine and I can manually then import Computer Objects from their domains (I can't seem to get it to sync, it errors out), so for now import works OK.

Now when our support staff connects to those imported servers, they will not necessarily know that those server objects are from another domain.

I want to be able to supply just the DOMAIN part of the credentials and have the support person enter their user name and password. In other words I want to dump it down so the domain gets auto supplied, but I can't seem to get this right.

I've used credentials and created an account to prompt at each logon and by supplying the domain and a blank user and password - seems ASG ignores that totally at RDP logon.

I've thought about the variable %LocalUsername% but the problem is it literally uses the TEXT and does not resolve it as a variable, ie Domain\%LocalUsername% and not Domain\JonDoeUser.

Can this even be done in ASGRD2018 what I am proposing? One would think based on the server.domainsuffix that would indicate something in the program what domain it is from but it doesn't. And neither does using credentials work as I would expect it to (leaving username blank and just specific the domain).

Any ideas...?

Thanks

Werner
Reply
#2
Hi Werner,

Right now we dont support variable in the credential field. I think that would fit into the "Feature Request" section. If you can provide a username adittionally to a domain, and tick the checkbox "always prompt for password" the domain will be saved and used in the logon box ! It's not possible to save only the domain right now - that also would be a Feature Request we can think about !
I also tried to sync a) a trusted and b) an untrusted domain ( that was defined in settings - the way you described above) and had no problem with it. But I used ASG-RD2018 Patch4 Version 11.05988.1. Which version do you use ?

Best regards,
Michael
best regards,
Michael -- michael.scholz@asg.com --
Reply
#3
(22-06-2018, 03:07 PM)Michael Scholz Wrote: Hi Werner,

Right now we dont support variable in the credential field. I think that would fit into the "Feature Request" section. If you can provide a username adittionally to a domain, and tick the checkbox "always prompt for password" the domain will be saved and used in the logon box ! It's not possible to save only the domain right now - that also would be a Feature Request we can think about !
I also tried to sync a) a trusted and b) an untrusted domain ( that was defined in settings - the way you described above) and had no problem with it. But I used ASG-RD2018 Patch4 Version 11.05988.1. Which version do you use ?

Best regards,
Michael

Thanks for Clarifying the credential field and its use Michael. Specifying a domain\user and checking the box to prompt for password works as you described, but that won't do as it would mean an extra step in changing to "other" user. Since I can't do passthrough/SSON in a non-trusted forest or for lack of better technical description "one way trust", it would be easier to just have the admins user their wits and know when prompted to include the domain name (or just the UPN).

Interesting that your sync worked using the domains and credentials from those domains. It must be something else then with my accounts. I read that it only needs AD/OU READ permissions (ie a normal domain user). I'll try it again and will elevate perms just to see if that gets around it or not. If it does it is clearly an OU permissions thing (but I can read and import from those external domains....which is weird and the bit I don't get. If it can READ, why won't it sync then. Could it perhaps be that the account I'm using to connect to those other external domains does not have rights in my ASGRD database to create and populate the DB?  Hmmm, I wonder...that does make sense doesn't it?  

I log on as a domain admin domain\adminwvz. I myself cannot connect to those other domains and they obviously also don't show up in the list of regular "trusted" domains...unless ofcourse they are added to the environment settings as described in my previous post. At this point ASGRD2018 uses that "service account" to impersonate reading the AD OU schema...and that works fine....and if you do an import via AD of objects it works fine.....but not the sync. The difference is that sync has to create the OU Structure and thus folders for those objects inside the ASGRD Database. That may be something I'll need to test then. I have no other idea why yours would have worked if you simulated the same scenario, since I'm on the same SP4: 11.0.5988.1   

worth a try. I'll update my post what the outcome was.

Werner
Reply
#4
Hi Werner,

thanks for your findings and your thoughts ! I must admit I don't use a "normal" user account to sync, but an admin account of that untrusted domain in my test environment. Regarding the database access: I don't think this could be the reason because you already have the right to modify connection objects - obviously - so you should have the right to modify the database with that user ! But you are right: the user who syncs needs the right to do so. For testing i would use an ASG-RD admin that also is a dB owner to exclude possible problems from that side. I'm curious to see your outcome.

Have a good weekend ,
Michael
best regards,
Michael -- michael.scholz@asg.com --
Reply




Users browsing this thread: 1 Guest(s)