Sync AD Passwords across Domains

The "primary" forest and it's domain is our Company, the "secondary" forest and it's domain is of another company that we bough. They are now part of our Wide Area Network and need to access their own systems as well as some of our systems (one common intranet for the "group" etc.)

We have not setup a Domain Trust between us (for a few reasons) and as an alternative we have created their users (same usernames) on our Domain and would now like to find out if there's a way to sync their AD User passwords to the matching user on our side on our domain.

Example:

Their Domain is COMPANY2
Our Domain is COMPANY1

They had a User "COMPANY2\JoeSoap" with password "MySecretPassword"
We created a COMPANY1\JoeSoap with password "Password1"

The user can now use one login (JoeSoap) but he's got two passwords and because it being normal users they get confused when to use which password.

I now need to know how can I sync the password "MySecretPassword" back to COMPANY1\JoeSoap so that he also has this password (without asking each and every user for their password ofcourse...) Is there for instance any kind of LDAP tool or similar that can take a password from one user and sync to a matching username even thought it's on another domain and will have a differnet SID ?

There is a small amount of overhead as you are now managing two separate AD infrastructures, group policies, and other pieces. How much overhead depends on the environment, and whether it is a short term

There is no good way to accomplish what you want. Although given the situation you laid out, a trust is exactly what you want. A domain trust isn't an open gate. You can still control and manage resources by security groups or other means. All a domain trust does is allow authentication of a claim to occur.

We had a chat to our service provider that supports our infrastructure and their exact words were:

It would be best to move everything into your domain as a long term measure. Creating a trust would be suitable and easy, but is very short term and can be quite an overhead from an operational and administration point of view.

In your opinion would you agree with this as being a short-term solution? I am unsure as to what "overhead" they are referring to, but as you stated a trust is merely allowing authentication of a claim to occur, and this seems to me is exactly what we need.

There is a small amount of overhead as you are now managing two separate AD infrastructures, group policies, and other pieces. How much overhead depends on the environment, and whether it is a short term solution or could be long-term is also very subjective. There are instances where a plan to merge makes sense. And there are times when a newly bought company will keep some autonomy and keeping separation is desirable. So I do not *necessarily* agree, but it isn't entirely inaccurate either.

Regardless, for the short term for sure, a trust makes far more sense than maintaining duplicate accounts.

Thanks that makes sense, I think I now understand what they meant with "overhead", they mean that we would have to still separately manage their domain's Group Policies etc. which is fine as they have another Company looking after it in any way, and in time we can merge the domains.

Thanks, I think I've got my answer, there is not really any danger in doing a domain trust, as long as one is happy with managing Group Policies, integrated DNS etc. separately for that period of time (which will work for us).

This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller.
Log onto the new domain controller with a user account t…

This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource.
Use Google, Bing, or other preferred search engine to locate trusted NTP …