Ugly solution

For such kind of auth-mixing the internet suggests the following algorithm:

In the controller of /admin, if a client is not windows authenticated then return response with status code 418, else do the normal job.

In global.asax.cs in Application_EndRequest() method, if the status code is 418, set it to 401.2 to provoke a challenge by an authentication module next in a pipeline.

Simple, but:

Windows authentication performed as a result of such 401 substitutions would be NTLM, but never Kerberos.

It doesn't consider the case of user walking from personnel URL to customer URL and back, having customer's fed-auth cookies and Kerberos / NTLM authentication at the same time. How would principal corresponding to URL be reconstructed?

It relies on fake code instead of some kind of authorization exception or filter attribute. This spoils structure of the code.

It relies on the order of EndRequest event handling in the pipeline. There's no documented guarantees about that order.

I believe a double response status code change is the dirty hack.

Correct solution

To get some general understanding read my IIS internals article, especially final parts about federated authentication.

Create some configuration section to put the collection of URLs in it, for which to skip federated and use windows authentication: