First of all, all tasks in your master and your other project should be auto-scheduled. Manual scheduling should only be used for initial conceptual planning.
It isn't clear if your structure is a dynamic master with the separate project inserted as a subproject, or if you simply have two separate files, one called your master and the other called whatever. If you want to link the start of certain tasks in the second file with tasks in the master, one way to do that is with external dependencies wherein the Predecessor of a task in the second file shows a file path to the driving task in the master. For example, here is a test file I have that contains both an internal and external dependency from a task in another file. But a warning, inter-project links in Project are susceptible to corruption as is a master/subproject structure.
As far as hard constraints (must-start-on, must-finish-on), yeah everybody wants their plan to be ironclad with respect to start and finish but that's not the real world. There is nothing wrong with linking a task to start when another task finishes (finish-to-start) or starts (start-to-start), those are normal (and desirable) dependencies to form a good logic network. But attempting to fix a finish date is unrealistic. Project does have a Deadline field that is very useful for establishing a "stake in the ground" so the project manager can dynamically manage the plan to achieve that goal. But forcing the issue by "fixing" the plan isn't going to help anybody.
John