Active Directory Domain Trust(s)
-
@Dashrender Well, I know the term, but know nothing about it.
Trust vs Federation is another thing I'll need to research.
-
@anthonyh said:
@Dashrender Well, I know the term, but know nothing about it.
Trust vs Federation is another thing I'll need to research.
Trust as I understand it is really only for internal company components. Federation is the ability for your system to use portions of someone else's authentication system to secure parts of yours - i.e. your application can use the username/passwords from the other company, allowing the other company to be responsible for enabling/disabling accounts, etc.
-
@Dashrender Well, from a quick search, it looks like the application needs to be "claims-aware" for federation to work. I don't know if the application in question is claims-aware. I'll have to find out.
I know you can establish what are called "external" trusts, which is what I was going to aim for. It's not a matter of connectivity. We have private connections to the agencies in question, so it would just be a matter of appropriately adjusting our firewall for whatever is needed for the domain trust and/or federation.
-
I would think Federation would be the preferred way, but i haven't researched it enough to know for sure.
-
We have a transitive domain trust with a company we just bought out..
A trust isn't something you really want for External Agencies.
-
@anthonyh said:
@Dashrender Well, from a quick search, it looks like the application needs to be "claims-aware" for federation to work. I don't know if the application in question is claims-aware. I'll have to find out.
I know you can establish what are called "external" trusts, which is what I was going to aim for. It's not a matter of connectivity. We have private connections to the agencies in question, so it would just be a matter of appropriately adjusting our firewall for whatever is needed for the domain trust and/or federation.
Yeah - Claims-aware, that founds familiar. I read about Federation Services a year or two ago. Really liked the options it could grant. Sadly it seems no one is offering it's use.
To bring it into an existing application would probably require a non trivial amount of back end work.
-
@Jason said:
We have a transitive domain trust with a company we just bought out..
A trust isn't something you really want for External Agencies.
Why is that?
-
It may be worth reporting the end users who continuously ask to have their passwords reset to their respective managers (even if they are employees of the other company).
I say this because if EmployeeA from the other company leaves and they never disable that employee's account, they potentially still have access to your stuff after they are no longer employed. If you have a website that helps them reset their passwords... They should be directed to it... Every. Single. Time. Hold their hands a few times and let THEM do the password reset while you watch over their shoulder or do a screen sharing session.
The end users never learn anything if we juts keep doing it for them.
-
-
@Jason said:
@anthonyh said:
@Jason said:
We have a transitive domain trust with a company we just bought out..
A trust isn't something you really want for External Agencies.
Why is that?
Because it is a Trust.. With something you have no control over. Not really something I'd recommend doing.
So, if we were to establish a one way external trust with one of the external agencies, what sort of control would that external agency have that I cannot control?
-
@dafyre said:
It may be worth reporting the end users who continuously ask to have their passwords reset to their respective managers (even if they are employees of the other company).
I say this because if EmployeeA from the other company leaves and they never disable that employee's account, they potentially still have access to your stuff after they are no longer employed. If you have a website that helps them reset their passwords... They should be directed to it... Every. Single. Time. Hold their hands a few times and let THEM do the password reset while you watch over their shoulder or do a screen sharing session.
The end users never learn anything if we juts keep doing it for them.
This is a big issue. We has a Self service portal. And require a new password every 90days.
-
@anthonyh said:
@Jason said:
@anthonyh said:
@Jason said:
We have a transitive domain trust with a company we just bought out..
A trust isn't something you really want for External Agencies.
Why is that?
Because it is a Trust.. With something you have no control over. Not really something I'd recommend doing.
So, if we were to establish a one way external trust with one of the external agencies, what sort of control would that external agency have that I cannot control?
Pretty sure One Way trusts don't exist anymore. I think those went out in 2003.
-
@Dashrender said:
@anthonyh said:
@Jason said:
@anthonyh said:
@Jason said:
We have a transitive domain trust with a company we just bought out..
A trust isn't something you really want for External Agencies.
Why is that?
Because it is a Trust.. With something you have no control over. Not really something I'd recommend doing.
So, if we were to establish a one way external trust with one of the external agencies, what sort of control would that external agency have that I cannot control?
Pretty sure One Way trusts don't exist anymore. I think those went out in 2003.
Actually, I just set one up between my test DC (we'll call it test.com) and our production domain (we'll call it prod.com).
I was able to set up a trust so that prod.com trusts test.com, but test.com does not trust prod.com. I was also able to set it up as selective authentication which, if I understand the description properly, means they cannot authenticate to any resource unless specifically allowed. Not sure if that'll work for the app in question, but hey it's worth a shot!
-
@anthonyh said:
@Dashrender said:
@anthonyh said:
@Jason said:
@anthonyh said:
@Jason said:
We have a transitive domain trust with a company we just bought out..
A trust isn't something you really want for External Agencies.
Why is that?
Because it is a Trust.. With something you have no control over. Not really something I'd recommend doing.
So, if we were to establish a one way external trust with one of the external agencies, what sort of control would that external agency have that I cannot control?
Pretty sure One Way trusts don't exist anymore. I think those went out in 2003.
Actually, I just set one up between my test DC (we'll call it test.com) and our production domain (we'll call it prod.com).
I was able to set up a trust so that prod.com trusts test.com, but test.com does not trust prod.com. I was also able to set it up as selective authentication which, if I understand the description properly, means they cannot authenticate to any resource unless specifically allowed. Not sure if that'll work for the app in question, but hey it's worth a shot!
let us know what you figure out.
-
@Jason said:
@dafyre said:
It may be worth reporting the end users who continuously ask to have their passwords reset to their respective managers (even if they are employees of the other company).
I say this because if EmployeeA from the other company leaves and they never disable that employee's account, they potentially still have access to your stuff after they are no longer employed. If you have a website that helps them reset their passwords... They should be directed to it... Every. Single. Time. Hold their hands a few times and let THEM do the password reset while you watch over their shoulder or do a screen sharing session.
The end users never learn anything if we juts keep doing it for them.
This is a big issue. We has a Self service portal. And require a new password every 90days.
If that is the case, then your end-users should well know how to reset their password in the Self Service Portal.
-
@dafyre said:
@Jason said:
@dafyre said:
It may be worth reporting the end users who continuously ask to have their passwords reset to their respective managers (even if they are employees of the other company).
I say this because if EmployeeA from the other company leaves and they never disable that employee's account, they potentially still have access to your stuff after they are no longer employed. If you have a website that helps them reset their passwords... They should be directed to it... Every. Single. Time. Hold their hands a few times and let THEM do the password reset while you watch over their shoulder or do a screen sharing session.
The end users never learn anything if we juts keep doing it for them.
This is a big issue. We has a Self service portal. And require a new password every 90days.
If that is the case, then your end-users should well know how to reset their password in the Self Service Portal.
And our technicians never get tickets for that either.. Sorry. I couldn't even keep a straight face typing that.
-
ROFL.
-
Well, I've been successful at establishing a one was external trust between my test domain and production domain. I was able to grant permissions on file shares to users across the trust and authenticate successfully. However, I cannot get the application in question (the reason for the trust) to authenticate via an account across the trust. I believe this is due to the way the application is querying AD (it's doing an LDAP lookup with a base of our production domain). So, this may not be an option after all...which I'm OK with.
We are considering one of two options:
- Continuing to enforce the Password Self Service portal
OR
- Configuring accounts for each agency so that someone technical on their end has restricted access to their respective OU. This would allow them to reset passwords and create/delete accounts for their respective organization (with oversight from us, of course).
I'm trying to push my boss towards option 1, but the decision is really up to him.
-
for the username on the application, have you tried domain\username or [email protected]?
-
@Dashrender said:
for the username on the application, have you tried domain\username or [email protected]?
I did try [email protected], but I did not try domain\username. I'll give that a shot.
