An application admin is basically the same as a system admin. He is responsible for ensuring the day-to-day operational success of the system, but does not have access to change security settings (add users/groups, view/clear the security event log, etc). Then we have security admins who can modify users, adjust security settings, and perform security audits, but do not necessarily have permission to perform other administrative tasks.
I did notice that the metabase.bin file was restricted to only admins. I might try changing these permissions to see if I can enable the IIS manager for other users, which would allow me to have Security admins that were not part of the local admin group.
Furthermore, we will likely have IIS deployed on client workstations. I know this sounds odd, but it's an operational necessity.
Unfortunately, our customer has control of our deployment environment, and while we can give recommendations, the ultimate decision is theirs, so I'm trying to come up with solutions that will work regardless of their decision.
I just attempted to try your idea of auditing changes to the metabase.bin file, and unfortunately it didn't work. You did give me some good ideas, though. I read somewhere that IIS also uses parts of the registry to store some settings, so I may see if auditing those registry entries will do what I need. I'm surprised that there is no built-in auditing functionality for IIS, though. I feel like a lot of people would like to have a record of when their web server is reconfigured. Adding windows audit requests to random files/registry entries seems a bet extreme for what I would expect to be a standard feature.
I really appreciate your responses. I will certainly look into IIS 7, and possibly try to recommend that to our customer, but as I said, it may not be an option. In the meantime, any other ideas about how to get the security events I need?
Thanks,
Mim