What you are asking is opinionated, therefore the answer is: it depends!
The main conception of the Onion Architecture is that dependencies point inward the circle but never out. You should choose responsibilities of your application layers. As you wrote:
The way I currently did it is add Active Directory operations classes directly into MVC's Model folder.
This sounds as it's currently an application layer responsibility, which of course may be good or bad, only you can decide.
But, I see three main ways to implement this:
Application layer: in the UI layer as it currently is
Service layer: access the AD from your service classes, in which way you can have a "shared" access of said functionality
Repository layer: abstract away all the AD related queries/updates you need.
If your fear is that your company would change authenticating from AD to say TACACS, you can have implementations of
IAuthenticationEngine in an assembly that is concerned about infrastructure level stuff.
To sum up all these: this is an infrastructure concern, therefore I would definitely just separate these responsibilities away into points 2 OR 3, maybe 2 AND 3. Again this all depends on your needs.
To answer your question in comment: I see you have fallen into the typical trap of following the examples presented about the Onion Arch. As you currently have the flow of your program, you are just creating levels of abstraction for no real benefit other than difficulty. I suggest you to read this answer I wrote on StackOverflow, about a similar question you are facing right now. In short it is about you might not really need to have the code flow all those layers. Just use vertical slices of the layers.