I've been running a Request Tracker instance for some years with a client of mine. It currently has about 27,000 tickets in the system, and functions as a sort of knowledge base / group memory as well as a helpdesk system. At various times it's been so popular that it partially escaped from IT and got used by the Office Management team (for calls about broken lights, water leaks etc.) and the people who organised office travel (to allow travel requests to be progressed by whichever team member was in on any given day).
I can't speak for AD integration, since you don't say what you mean by that. I have worked with an RT that did its web authentication using LDAP from an AD server. I have no idea what KnowledgeBase generation is; I fear from the CamelCase that it's some kind of proprietary thing.
So RT is great, no question about it. If I had to implement a new helpdesk system, things I'd look for (in no particular order) include:
- Must be able to interoperate with people using simple email; web is handy but should never be compulsory
- Can merge tickets (B is part of A), can establish dependencies (A is dependent on B, and B is dependent on C and D)
- Tickets can easily be passed from one person to another
- Tickets can be annotated in a way that the client doesn't see. Sometimes you really do need to write that the customer is an idiot.
- If tickets are annotated publicly, all relevant people are automatically notified
- Good, fast search interface
- URLs into the system remain valid forever
- If it authenticates for eg web access, as many different hooks as possible (LDAP/RADIUS/NIS/etc.)
- Queues to separate workflows, but the ability to throw tickets from one queue to another is most handy (eg, an office request relating to a leak that then turns into an IT request to replace a keyboard)