Just to be 100% clear on the question: things are "changing crazily" between iteration planning and execution, and you want to know how to say "NO" and make everyone "do things in the right way" -- which makes it sound like the "right way" means people should not change their minds between iteration planning and execution.
The simple answer is that
you should try making one or two iterations shorter -- give that a shot for just those iterations and see how things turn out. You should also spend less time planning your iterations up front, and more time during each iteration discussing the plans with he whole team. This is what the daily Scrum meeting is for: inspecting the plan, and adapting it every day based on new information that the team discovered through their work.
There's also a deeper answer. It sounds like when your team discovers that what people really need is different from what they asked for or what's written in the plan, they feel the need to "say NO" and stick to the plan. If this is how the team works, I recommend really thinking about trying to change that.
This is part of what the Agile Manifesto means when it says that agile teams value customer collaboration over contract negotiation. The team is treating the decisions made during iteration planning as a sort of "contract" between the team and the users and stakeholders they're building software for. Things are "changing crazily" when those users realize they need something different than they asked for, and the team is "saying NO" and demanding that everyone stick to the contract.
I recommend a more agile -- and more productive -- attitude towards change. When users and stakeholders tell you the plan is wrong, that's great! You and the team would have spent all that time building the wrong product. Now the users can help you figure out the right product. They save you time, you give them a better product. That's collaboration!
Incidentally, I've talked in other posts about how the mindset or attitude of the team needs to match the principles and values of agile. This is a good real-world example that can dramatically change the actual outcome of a live project.