An id was a part of a particular user group. All of a sudden that id was removed from that group, because of which many things failed. How do I find out when/who modified the id settings?
With so little information given, there isn't much that we can say other than that someone who knows the appropriate password or has the appropriate privileges was logged in at the time the change was made. You say that many things started failing all of a sudden. That is the time at which it happened.
What manager is responsible for the group from which that user was removed? Did that manager ask/authorize that user to be removed from that group? Was that user transferred to a different group? Was that user fired?
Other than that user being unable to run jobs requiring the privileges of that group ID, is anyone other than that user unable to run any code that they need to run? If so, why? I.e., why are other users trying to run code as another user instead of using their own accounts? Why aren't their user IDs in the group if they need to run code that requires privileges to run code that affects projects owned by that group?
This is a part of systems administration which is called "auditing": security is to make sure only the right person/function is allowed to do things. Auditing is about documenting what he has done and when and why.
As with security the OS offers way to implement it but you have to actually implement it for it to be in place. You can run a system without any security and you can run it without any auditing in place - it might not be wise to do so, but it is possible. Finding out after the fact about what has happened is possible - to some degree, like Don Cragun already insinuated - but in a strict sense not possible. I suggest you take the lesson learned from that and put a system in place that will prevent you getting into the same situation. Thats the best you can do.
Notice that you should make a thorough plan for such an endeavour before implementing it. In most companies this is done on an ad-hoc basis ("we had this incident lastly so how do we prevent it") and usually by people not working the system. This is the reasons a lot of practically unworkable systems are in place. You need to get a tradeoff between practicality, performance impact, documentation needs a few other things. Otherwise the tendency is people search for (and find) shortcuts to circumvent the system to get their work done still in reasonable time and with reasonable effort.
If you have a room with valuable goods in it it makes sense to put a lock on the door. If you try to "enhance security" and put 10 locks on the door and everybody needing to get in there has only one key so that he needs to get 9 other people to convene to open the door chances are the things in this room will be placed outside of it just to avoid having to go through the hassle. This is exactly the opposite of what the door was supposed to do when the first lock was placed on it. Sadly enough i have seen such "solutions" proposed ad put into place times and again.
I hope this helps.
bakunin